Testcase for libndp
libndp -Library for Neighbor Discovery Protocol

Neighbor Discovery Protocol (NDP) is a part of the Internet Protocol suite used with IPv6.
NDP Protocol make use of ICMPv6 messages and solicited-node multicast addresses for operating its core function, which is tracking and discovering other IPv6 hosts that are present on the other side of connected interfaces. Another use of NDP is address autoconfiguration.

IPv6 nodes on the same link use Neighbor Discovery protocol to discover each others presence, to determine each others link-layer addresses, to find routers, and to maintain reachability information
about the paths to active neighbors.

NDP defines five ICMPv6 packet type for the purpose of router solicitation, router advertisement, neighbor solicitation, neighbor advertisement, and network redirects

libndp package provides one library and one binary,
libndp.so :which provides a wrapper for IPv6 Neighbor Discovery Protocol and
ndptool :tool for sending and receiving NDP messages.

Approach for testing:

1. Check if libndp package is installed.
2. Installation check for utilities ip ,route and tcpdump.
3. Get active interface of the machine and assign to iface=eth0 .

-bash-4.2# ip -6 route show default
default via fe80::4e96:14ff:fe59:d7f0 dev eth0 proto ra metric 1024 expires 1787sec
4. Get the ipv6 address of system and extract link local address to variable ns_verify=fe80::e61f:13ff:feb4:fcb0.

-bash-4.2# ip addr show dev eth0 | sed -e's/^._inet6 ([^ ]_)\/._$/\1/;t;d' |grep fe80_
fe80::e61f:13ff:feb4:fcb0

5. Start the tcpdump with filter icmp6 to capture only ICMPv6 packet types.

   -bash-4.2# tcpdump -n -i eth0 icmp6

6. Monitor incoming NDP messages on specified interface i.e iface=eth0 using "ndptool monitor -i eth0"

-bash-4.2# ndptool monitor -i eth0
7. Send NDP message of type neighbor Solicitation (NS) messages using ndptool send -t ns -i eth0 and monitor it using "ndptool monitor -i eth0".
Neighbor Solicitation: Neighbor solicitations are used by nodes to determine the link layer
address of a neighbor, or to verify that a neighbor is still reachable via a cached link layer address.

-bash-4.2# ndptool send -t ns -i eth0
-bash-4.2# ndptool monitor -i eth0
NDP payload len 24, from addr: fe80::e61f:13ff:feb4:fcb0, iface: eth0
Type: NS
Verify if neighbor Solicitation messages is been received in "ndptool monitor -i eth0" as-well as in tcpdump output.
8. Now stop the tcpdump and ndptool monitor process .
9. Start "ndptool monitor" to monitor incoming NDP messages of type NS by using "ndptool monitor -i eth0 -t ns ".

Now send the Router Solicitation ad NS messages using "ndptool send -t rs -i eth0" and "ndptool send -t ns -i eth0"

Verify if the message received by "ndptool monitor -i eth0 -t ns " is only of type NS and it does
not contain messages of RS type.
10. Send NDP message of type RS and monitor it .
Stop "ndptool monitor" and start "ndptool monitor -i eth0".
Now send the Router Solicitation messages using " ndptool send -t rs -i eth0".
Verify if the message received by " ndptool monitor -i eth0 "is of type RS .

Testcase for python-backports-ssl_match_hostname

About the package:
Secure Socket Layer is secure when the hostname in the certificate returned
by the server matches to hostname thats being trying to be reached.
match_hostname() in ssl package in the Standard Library of Python 3.2 performs this check
instead of requiring every application to implement the check separately.

backport brings match_hostname() to users of earlier versions of Python.

Approach for testing:

• Create a self signed SSL certificate using openssl
• Create a server socket:
  - create a socket and bind the socket to a port
• Now as client, connect to the server and get the server's certificate using getpeercert()
  getpeercert() returns the certificate in decoded format.
• Verify the cert matches the hostname using match_hostname from backports.ssl_match_hostname
  ex: match_hostname(ssl_sock.getpeercert(), "hostname")

Example usage:

import socket, ssl, pprint
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ssl_sock = ssl.wrap_socket(s, ca_certs="server.crt", cert_reqs=ssl.CERT_REQUIRED)
ssl_sock.connect(('localhost', 1002))
from backports.ssl_match_hostname import match_hostname, CertificateError
match_hostname(ssl_sock.getpeercert(), "hostname")

2. check whether match_hostname gives mismatch for wrong hostname

from backports.ssl_match_hostname import match_hostname, CertificateError
cert = {'subject': ((('commonName', 'example.com'),),)}
match_hostname(cert, "example.com")
match_hostname(cert, "example.org")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/site-packages/backports/ssl_match_hostname/init.py", line 99, in match_hostname
% (hostname, dnsnames[0]))
backports.ssl_match_hostname.CertificateError: hostname 'example.org' doesn't match 'example.com'

Objective: To improve usage and maintenance of Linux package test cases.
In Linux Technology Center at IBM, we have test cases developed by IBMers which has been developed from last couple of years and which has been maintained internally. We also use test cases which are there in the source of Linux packages to test Linux OS. Year to year we have been investing effort in fixing bugs in those test cases picked from upstream.
Few months ago test team invested effort in using GPLv2 license for all the test cases developed internally within the IBM as well as right license for test cases in Linux Source packages.
Now idea is to make this test cases consumable from one point like Autotest, Autotest client has been enhanced by our remote interns to support linux tools testing under client/test/linux-tools/packages[1..10].
At present within our code repository we have testcases for around 320+ linux packages.
-First step is commit these test cases which are basically scripts under client/linux-tools/packages[1..220]-
-Then periodically synchronize test cases from upstream package to Autotest/client/test/linux-tools[packages[...]
-Test team in LTC IBM will be periodically sending patches to maintain these test cases in linux-tools.
-These test cases today will run on Fedora, RHEL and CentOS distribution. Eventually will be enabled for SLES and Ubuntu.

By making Linux package test cases available under one umbrella like Autotest will enable Linux test community to give back to the community what they have been developing also it will help in maintaining test cases by fixing bugs in test case sources of Linux packages. Hence end result is better maintenance of test sources.

About the package:
This is an LDAP driver for BIND. The dynamic LDAP back-end is a plug-in for BIND that provides an LDAP database back-end capabilities.

Package provides ldap.so library

Approach for testing

This includes configuring openldap and bind .
bind-dyndb-ldap is used as backend for Bind9 DNS to communicate to openldap
Two setups include:

• Configure LDAP connection using openldap by adding bind-dyndb-ldap schema
• Configure dynamic loading of the backend using named ( bind )

Setup openldap

1. Create slapd.conf with below contents

See slapd.conf(5) for details on configuration options.

This file should NOT be world readable.

include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
include /etc/openldap/schema/bind-dyndb-ldap.schema

Allow LDAPv2 client connections. This is NOT the default.

allow bind_v2

Do not enable referrals until AFTER you have a working directory

service AND an understanding of referrals.

#referral ldap://root.openldap.org

pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args

#######################################################################

ldbm and/or bdb database definitions

#######################################################################

loglevel 256
database bdb
suffix "dc=example,dc=com"
checkpoint 1024 15
rootdn "cn=test,dc=example,dc=com"

Cleartext passwords, especially for the rootdn, should

be avoided. See slappasswd(8) and slapd.conf(5) for details.

Use of strong authentication encouraged.

rootpw secret

rootpw {crypt}ijFYNcSNctBYg

rootpw {SSHA}KUS8va9cQ+UfW49PDSJ/clm

The database directory MUST exist prior to running slapd AND

should only be accessible by the slapd and slap tools.

Mode 700 recommended.

directory /var/lib/ldap
moduleload syncprov.la
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

Indices to maintain for this database

index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub

enable monitoring

database monitor

allow onlu rootdn to read the monitor

access to *
by dn.exact="cn=test,dc=example,dc=com" read
by * none

Create ldap password for “dc=example,dc=com”

2. Create password and edit “rootpw” entry in slapd.conf using:

slappasswd -h {SSHA}

Copy the schema to openldap schema directory

3. cp /usr/share/doc/bind-dyndb-ldap*/schema /etc/openldap/schema/bind-dyndb-ldap.schema

4. create user test and password

The slapd configuration is stored in a special LDAP directory(/etc/openldap/slapd.d)
Convert from old slapd configuration file located at (/etc/openldap/slapd.conf) to new directory:
Run slaptest to check validity of the configuration file and
specify the new configuration directory :

slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/

Start slapd:
slapd -h "ldap:/// ldapi:///"

Make sure the process is running using:
netstat -ltpn|grep 389

and check for slapd

7. After verifying openldap has started successfully , add the data.ldif as below:

Create data.ldif

<<>>>
dn: dc=example,dc=com
objectclass: dcObject
objectclass: organization
o: OpenLDAP Test
dc: example

dn: cn=test,dc=example,dc=com
objectclass: organizationalRole
cn: test
<<>>

Add using ldapadd

ldapadd -x -W -D "cn=test,dc=example,dc=com" -h localhost -f data.ldif
Enter LDAP Password:
adding new entry "dc=example,dc=com"

adding new entry "cn=test,dc=example,dc=com"

9. Verify it works using:

ldapsearch -D "cn=test,dc=example,dc=com" -W -b 'dc=example,dc=com'

ldapsearch -D "cn=test,dc=example,dc=com" -W -b 'dc=example,dc=com'
Enter LDAP Password:

extended LDIF

LDAPv3

base <dc=example,dc=com> with scope subtree

filter: (objectclass=*)

requesting: ALL

example.com

dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
o: OpenLDAP Test
dc: example

test, example.com

dn: cn=test,dc=example,dc=com
objectClass: organizationalRole
cn: test

search result

search: 2
result: 0 Success

numResponses: 3

numEntries: 2

10. To get ip for zone and records, create virtual interface and assign ip

Create virtual interface using:
ip link add veth0 type veth peer name veth1
ip link add veth2 type veth peer name veth3

Assign private ip using:
ifconfig veth0 192.168.122.2 netmask 255.255.255.0
ifconfig veth1 192.168.122.3 netmask 255.255.255.0
ifconfig veth2 192.168.122.4 netmask 255.255.255.0

11. Add zones and records using input file as below:

Create dns-domain.ldif

<<>>

Top container

dn: cn=dns, dc=example, dc=com
objectClass: top
objectClass: organizationalRole
cn: dns

Zone example.com

dn: idnsName=example.com, cn=dns, dc=example, dc=com
objectClass: top
objectClass: idnsZone
objectClass: idnsRecord
idnsName: example.com
idnsUpdatePolicy: grant EXAMPLE.COM krb5-self * A;
idnsZoneActive: TRUE
idnsSOAmName: server.example.com
idnsSOArName: root.server.example.com
idnsSOAserial: 1
idnsSOArefresh: 10800
idnsSOAretry: 900
idnsSOAexpire: 604800
idnsSOAminimum: 86400
NSRecord: example.com.
ARecord: 192.168.122.2

DNS records for zone example.com

dn: idnsName=server, idnsName=example.com, cn=dns, dc=example, dc=com
objectClass: idnsRecord
objectClass: top
idnsName: server
CNAMERecord: example.com

dn: idnsName=foo, idnsName=example.com, cn=dns, dc=example, dc=com
objectClass: idnsRecord
objectClass: top
idnsName: foo
ARecord: 192.168.122.3
ARecord: 192.168.122.4

dn: idnsName=bar, idnsName=example.com, cn=dns, dc=example, dc=com
objectClass: idnsRecord
objectClass: top
idnsName: bar
ARecord: 192.168.122.5
<<>>

Add using ldapadd:

ldapadd -H ldap://localhost -D "cn=test,dc=example,dc=com" -W -c -f dns-domain.ldif

LDAP confguration is complete.

Setup BIND

Setup named.conf, To configure dynamic loading of back-end, add a "dynamic-db" to named.conf
Specify library and ldap using arg options

Add this to /etc/named.conf

dynamic-db "my_db_name" {
library "ldap.so";
arg "uri ldap:///";
arg "base cn=dns, dc=example, dc=com";
arg "auth_method none";
arg "cache_ttl 300";
};

service named start

With this configuration, the LDAP back-end will try to connect to server .
It will then use RFC 4533 refresh&persist search in the "cn=dns,dc=example,dc=com"
base for entries with object class idnsZone and idnsRecord
For each idnsZone entry it will find, it will register a new zone with BIND

15. Setup is going to use localhost server,

mv /etc/resolv.conf /etc/resolv.conf.org

Setup for BIND is complete.

Testing the setup.

1. Verify /var/named/dyndb-ldap contains entry for my_db_name
2. Verify using nslookup

nslookup foo.example.com
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: foo.example.com
Address: 192.168.122.4
Name: foo.example.com
Address: 192.168.122.3

nslookup bar.example.com
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: bar.example.com
Address: 192.168.122.5

Add records:

Add record for baz.example.com

Create add-zones.ldif

<<>>
dn: idnsName=baz, idnsName=example.com, cn=dns, dc=example, dc=com
objectClass: idnsRecord
objectClass: top
idnsName: baz
CNAMERecord: bar
<<>>

Add using ldapadd:

-bash-4.2# ldapadd -H ldap://localhost -D "cn=test,dc=example,dc=com" -W -c -f add-zones.ldif
Enter LDAP Password:
adding new entry "idnsName=baz, idnsName=example.com, cn=dns, dc=example, dc=com"

Test if it is refreshed in the DNS data:

-bash-4.2# nslookup baz.example.com
Server: 127.0.0.1
Address: 127.0.0.1#53

baz.example.com canonical name = bar.example.com.
Name: bar.example.com
Address: 192.168.122.3

Delete records:

Create baz-delete.ldif

<<>>
dn: idnsName=baz, idnsName=example.com, cn=dns, dc=example, dc=com
changetype: delete
<<>>

nslookup baz.example.com
Server: 127.0.0.1
Address: 127.0.0.1#53

** server can't find baz.example.com: NXDOMAIN

Verify using dig

dig @localhost foo.example.com

; <<>> DiG <<>> @localhost foo.example.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42470
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;foo.example.com. IN A

;; ANSWER SECTION:
foo.example.com. 86400 IN A 192.168.122.2

;; AUTHORITY SECTION:
example.com. 86400 IN NS example.com.

;; ADDITIONAL SECTION:
example.com. 86400 IN A 192.168.122.4

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue Dec 29 11:26:00 UTC 2015
;; MSG SIZE rcvd: 90

Testcase for libteam

libteam - Library for controlling team network device

The purpose of the Team driver is to provide a mechanism to team multiple NICs (ports) into one logical one (teamdev) at L2 layer.
The process is called "channel bonding", "Ethernet bonding", "channel teaming", "link aggregation", etc.
This is already implemented in the Linux kernel by the bonding driver. libteam solve the same problem using a different approach

Approach for testing:

libteam provides library libteam and binary teamnl.

Package provides:
Binary: /usr/bin/teamnl
Library: /usr/lib64/libteam.so*

teamd, teamdctl, teamnl are the utilities which uses libteam. ( teamd is from libteam )
This library is to do userspace wrapping of Team Netlink communication.
So the testcase uses these utilities to test libteam

Setup:

1. Check if libteam is installed
2. Installation check for utilities teamd, teamdctl
3. For purpose of testing, create virtual network interfaces using ip command.
   For eg,

   ip link add veth0 type veth peer name veth1

This creates interfaces veth0 and veth1

Testing:

1. start the teamd daemon.
   #teamd -d
   This creates new interface team0. Default interface will be named team0. Verify this using "ip link " command

   Start daemon passing custom configuration file as well and check if interface is created using ip command.
   Example configuration file:
   <<>>
   {
   "device": "team2",
   "runner": {"name": "roundrobin"},
   "ports": {"veth1": {}, "veth0": {}}
   }
   <<>>

2. Using teamdctl communicate to the daemon.
   Add and delete multiple ports to the newly created teamdev.

   teamdctl team2 port add veth0
   teamdctl team2 port remove veth0

   Verify this using ip command.

   Check the state of the teamdev using
   teamdctl team2 state

3. Interact with the teamdev using teamnl command
   For example,

   teamnl team2 ports

   teamnl team2 getoption mode.

   For eg:
   teamnl team1 getoption mode
   roundrobin

   teamnl team3 monitor all -> This wil monitor the changes made to options, ports etc.

   change an option using "teamnl setoption" and verify if monitor will report this.
   

4. Using ifcfg files

   Create ifcfg-team4 with similar contents:

   <<>>

   DEVICE="team4"
   DEVICETYPE="Team"
   ONBOOT="yes"
   BOOTPROTO=none
   NETMASK=255.255.255.0
   IPADDR=10.0.0.1
   TEAM_CONFIG='{"runner": {"name": "roundrobin"}}'
   NM_CONTROLLED="no"

   <<>>

   These have to be placed under /etc/sysconfig/network-scripts.

   Create ifcfg-veth1 config file as well with :

   DEVICE="veth1"
   DEVICETYPE="TeamPort"
   ONBOOT="yes"
   TEAM_MASTER="team4"
   NM_CONTROLLED="no"

   Bring up teamdev with "ifup team4" and verify the expected results has team4 and interface veth1

Description : crontab.allow_cron.fail
kernel version: v5.2-rc5

os-release:

PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

crontab.allow_cron/debug

06/18 04:14:38 INFO | crontab:0077| Starting test Crontab with jobs.allow
06/18 04:14:38 ERROR| crontab:0126| Test:run-parts with jobs.allow
There were no new entries in log.
Job not executed inspite of jobs.allow entry.
Test time: 65
06/18 04:14:38 ERROR| test:0414| Exception escaping from test:
Traceback (most recent call last):
File "/lkp/benchmarks/autotest/client/shared/test.py", line 411, in _exec
_call_test_function(self.execute, *p_args, **p_dargs)
File "/lkp/benchmarks/autotest/client/shared/test.py", line 823, in _call_test_function
return func(*args, **dargs)
File "/lkp/benchmarks/autotest/client/shared/test.py", line 298, in execute
self.postprocess()
File "/lkp/benchmarks/autotest/client/tests/linux-tools/crontab/crontab.py", line 142, in postprocess
raise error.TestError('\nTest failed : %s ' % self.test)
TestError:
Test failed : allow_cron

Hi Ruda/Martin,

I am using ltp(ltplite) test from autotest.

After the ltp tarball is unpacked and compiled,

Existing lines:

grep chmod06 ./bin/runtest/ltplite
chmod06 cp -p $LTPROOT/testcases/bin/change_owner $TMPDIR;chmod06
fchmod06 cp -p $LTPROOT/testcases/bin/change_owner $TMPDIR;fchmod06 -D DEVICE -T DEVICE_FS_TYPE

Run with existing setup:

/local/0/autotest/tmp/ltp/src/bin/runltp -f ltplite -s chmod06 -q -l /local/0/autotest/results/default/ltp/results/ltp.log -C /local/0/autotest/results/default/ltp/debug/failcmdfile -d /local/0/autotest/tmp/ltp/src -S /local/0/autotest/tmp/site_tests/ltp/skipfile
Checking for required user/group ids

'nobody' user id and group found.
'bin' user id and group found.
'daemon' user id and group found.
Users group found.
Sys group found.
Required users/groups exist.
INFO: Test start time: Fri Jul 11 12:16:44 BST 2014
COMMAND: /local/0/autotest/tmp/ltp/src/bin/bin/ltp-pan -q -e -S -a 56810 -n 56810 -f /local/0/autotest/tmp/ltp/src/ltp-BFu9sHEnms/alltests -l /local/0/autotest/results/default/ltp/results/ltp.log -C /local/0/autotest/results/default/ltp/debug/failcmdfile
INFO: Restricted to chmod06
LOG File: /local/0/autotest/results/default/ltp/results/ltp.log
FAILED COMMAND File: /local/0/autotest/results/default/ltp/debug/failcmdfile
Running tests.......
chmod06 1 TBROK : you must specify the device used for mounting with -D option
chmod06 2 TBROK : Remaining cases broken
fchmod06 0 TINFO : Formatting /dev/loop0 with ext2 extra opts=''
mke2fs 1.41.12 (17-May-2010)
fchmod06 1 TPASS : fchmod: test EPERM success: TEST_ERRNO=EPERM(1): Operation not permitted
fchmod06 2 TPASS : fchmod: test EBADF success: TEST_ERRNO=EBADF(9): Bad file descriptor
fchmod06 3 TPASS : fchmod: test EROFS success: TEST_ERRNO=EROFS(30): Read-only file system
INFO: ltp-pan reported some tests FAIL
LTP Version: 20140115

After updating the ltplite command file with (-D DEVICE -T DEVICE_FS_TYPE)

grep chmod06 ./bin/runtest/ltplite
chmod06 cp -p $LTPROOT/testcases/bin/change_owner $TMPDIR;chmod06 -D DEVICE -T DEVICE_FS_TYPE
fchmod06 cp -p $LTPROOT/testcases/bin/change_owner $TMPDIR;fchmod06 -D DEVICE -T DEVICE_FS_TYPE

Running with updated command file:

/local/0/autotest/tmp/ltp/src/bin/runltp -f ltplite -s chmod06 -q -l /local/0/autotest/results/default/ltp/results/ltp.log -C /local/0/autotest/results/default/ltp/debug/failcmdfile -d /local/0/autotest/tmp/ltp/src -S /local/0/autotest/tmp/site_tests/ltp/skipfile
Checking for required user/group ids

'nobody' user id and group found.
'bin' user id and group found.
'daemon' user id and group found.
Users group found.
Sys group found.
Required users/groups exist.
INFO: Test start time: Fri Jul 11 12:17:05 BST 2014
COMMAND: /local/0/autotest/tmp/ltp/src/bin/bin/ltp-pan -q -e -S -a 57415 -n 57415 -f /local/0/autotest/tmp/ltp/src/ltp-UP7DUHGHNZ/alltests -l /local/0/autotest/results/default/ltp/results/ltp.log -C /local/0/autotest/results/default/ltp/debug/failcmdfile
INFO: Restricted to chmod06
LOG File: /local/0/autotest/results/default/ltp/results/ltp.log
FAILED COMMAND File: /local/0/autotest/results/default/ltp/debug/failcmdfile
Running tests.......
chmod06 0 TINFO : Formatting /dev/loop0 with ext2 extra opts=''
mke2fs 1.41.12 (17-May-2010)
chmod06 1 TPASS : chmod failed as expected: TEST_ERRNO=EPERM(1): Operation not permitted
chmod06 2 TPASS : chmod failed as expected: TEST_ERRNO=EACCES(13): Permission denied
chmod06 3 TPASS : chmod failed as expected: TEST_ERRNO=EFAULT(14): Bad address
chmod06 4 TPASS : chmod failed as expected: TEST_ERRNO=EFAULT(14): Bad address
chmod06 5 TPASS : chmod failed as expected: TEST_ERRNO=EFAULT(14): Bad address
chmod06 6 TPASS : chmod failed as expected: TEST_ERRNO=ENAMETOOLONG(36): File name too long
chmod06 7 TPASS : chmod failed as expected: TEST_ERRNO=ENOENT(2): No such file or directory
chmod06 8 TPASS : chmod failed as expected: TEST_ERRNO=ENOTDIR(20): Not a directory
chmod06 9 TPASS : chmod failed as expected: TEST_ERRNO=EROFS(30): Read-only file system
chmod06 10 TPASS : chmod failed as expected: TEST_ERRNO=ELOOP(40): Too many levels of symbolic links
fchmod06 0 TINFO : Formatting /dev/loop0 with ext2 extra opts=''
mke2fs 1.41.12 (17-May-2010)
fchmod06 1 TPASS : fchmod: test EPERM success: TEST_ERRNO=EPERM(1): Operation not permitted
fchmod06 2 TPASS : fchmod: test EBADF success: TEST_ERRNO=EBADF(9): Bad file descriptor
fchmod06 3 TPASS : fchmod: test EROFS success: TEST_ERRNO=EROFS(30): Read-only file system
INFO: ltp-pan reported all tests PASS
LTP Version: 20140115

Do you think this is fine?
Can this be merged in the autotest’s ltp test?

Package : xorg-x11-utils

Description : A collection of client utilities which can be used to query the X server for various information.

Binaries Provided:

/usr/bin/edid-decode
/usr/bin/xdpyinfo
/usr/bin/xev
/usr/bin/xlsatoms
/usr/bin/xlsclients
/usr/bin/xlsfonts
/usr/bin/xprop
/usr/bin/xvinfo
/usr/bin/xwininfo

xlsclient:Xlsclients is a utility for listing information about the client applications
running on a display. It may be used to generate scripts representing a snapshot
of the user's current session.

xev :Xev creates a window and then asks the X server to send it events whenever any‐
thing happens to the window (such as it being moved, resized, typed in, clicked
in, etc.). You can also attach it to an existing window. It is useful for see‐
ing what causes events to occur and to display the information that they contain;
it is essentially a debugging and development tool, and should not be needed in
normal usage.

xwininfo:Xwininfo is a utility for displaying information about windows. Various informa‐
tion is displayed depending on which options are selected. If no options are
chosen, -stats is assumed.

xlsfonts:xlsfonts lists the fonts that match the given pattern.

Approach for Testing:

1. Check for the existence of the binaries.

2.Start VNC Server on the host machine and export DISPLAY(export DISPLAY=:1) variable.

#vncserver :1 -SecurityTypes None > /dev/null
#export DISPLAY=:1

4.To check the functionality of the xlsfonts.

    #xlsfonts -display localhost:1 -l

5.To check the functionality of the xdpyinfo and check the exit status.

    #xdpyinfo -display localhost:1

6.To verify xlsclient:
a.start any xserver client application(xterm)
b.verify the client application is listed in the output of the xlsclient

    #xterm &
    #xlsclients -display localhost:1
    localhost  xterm

7.To verify the functionality of the xev and xwininfo.
a.create a window using xev
b.verify it using the xwininfo

    #/usr/bin/xev -display localhost:1 -name mywindow &
    #xwininfo -display localhost:1 -name mywindow

8.To verify the functionality of the xprop,to set/remove the property of the window.

Ex:
#/usr/bin/xev -display localhost:1 -name mywindow &

a.set the propery  _SURF_URL of the created
#xprop -id 0x1000001 -f _SURF_URL 8s -set _SURF_URL http://www.google.com
# xprop -id 0x1000001 | grep _SURF_URL
_SURF_URL(STRING) = "http://www.google.com"

b.remove the property
#xprop -id 0x1000001 -f _SURF_URL 8s -remove  _SURF_URL
# xprop -id 0x1000001 | grep _SURF_URL 

avahi-autoipd - IPv4LL network address configuration daemon

avahi-autoipd implements IPv4LL, "Dynamic Configuration of IPv4 Link-Local Addresses" (IETF RFC3927), a protocol for automatic IP address configuration from the link-local 169.254.0.0/16 range
without the need for a central server. It is primarily intended to be used in ad-hoc networks which lack a DHCP server

The package provides avahi-autoipd binary

Approach for testing

Setup:

• Create virtual interface using ip command .

  #ip link add veth0 type veth peer name veth1

This creates interface veth0 and veth1

Testing avahi-autoipd:
—————————-

1. Start avahi-autoipd on veth0

Example:

 #avahi-autoipd veth0
 Found user 'avahi-autoipd' (UID 170) and group 'avahi-autoipd' (GID 170).
 Successfully called chroot().
 Successfully dropped root privileges.
 Starting with address 169.254.8.223 
 Callout BIND, address 169.254.8.223 on interface veth0
 Successfully claimed IP address 169.254.8.223

Verify the results using ip command:

#ip addr show veth0 |grep -w inet
inet 169.254.8.223/16 brd 169.254.255.255 scope link veth0:avahi

Also try logging in with the ip and verify its working

2. option: -k kill running avahi-autoipd
   Kill the avahi-autoipd using -k
   Ex:

 #avahi-autoipd -k veth0

and verify address is removed from interface veth0 using:
#ip addr show veth0 |grep -w inet

3. option: -s --syslog ( Write log messages to syslog )

Start avahi-autoipd using -s:
#avahi-autoipd -s veth0

and verify /var/log/messages is populated with the data

4. Testing switches —D, c, -r ( needs daemon to be running )

-D --daemonize Daemonize after startup
-r --refresh Request a running daemon refresh its IP address
-c --check Return 0 if a daemon is already running

Start avahi-autoipd with -D option ( daemon mode )

#avahi-autoipd -D veth0

Verify veth0 is assigned IP using ip command:
#ip addr show veth0 |grep -w inet

Check if the daemon is already running using -c:

 #avahi-autoipd -c veth0
-bash-4.2# echo $?
0

Request daemon refresh IP address using -r:

Example:

# avahi-autoipd -r veth0

Logs will have:
<<>>
Reannouncing address
Successfully claimed IP address 169.254.8.223
<<>>

5. -S address Start with this address

start avahi-autoipd using -S and address option

Example:

#avahi-autoipd -S 169.254.8.224 veth0
Found user 'avahi-autoipd' (UID 170) and group 'avahi-autoipd' (GID 170).
Successfully called chroot().
Successfully dropped root privileges.
Starting with address 169.254.8.224
Callout BIND, address 169.254.8.224 on interface veth0
Successfully claimed IP address 169.254.8.224

Verify this address is assigned using ip command

 #ip addr show veth0|grep -w inet
inet 169.254.8.224/16 brd 169.254.255.255 scope link veth0:avahi

6. --force-bind Assign an IPv4LL address even if a routable address is assigned already

Assign a routable address to the interface :

      # ip addr add 192.168.122.2 dev veth0

Run avahi-autoipd which should not assign IP as already address is configured on the interface:
Example:

 #avahi-autoipd veth0
 Found user 'avahi-autoipd' (UID 170) and group 'avahi-autoipd' (GID 170).
 Successfully called chroot().
 Successfully dropped root privileges.
 Starting with address 169.254.8.224
 Routable address already assigned, sleeping.

Now using —force-bind:

 #avahi-autoipd --force-bind veth0
 Found user 'avahi-autoipd' (UID 170) and group 'avahi-autoipd' (GID 170).
Successfully called chroot().
Successfully dropped root privileges.
Starting with address 169.254.8.224
Callout BIND, address 169.254.8.224 on interface veth0
Successfully claimed IP address 169.254.8.224

—force-bind will assign the IP.
Verify using ip command:

#ip addr show veth0|grep -w inet
inet 169.254.8.224/16 brd 169.254.255.255 scope link veth0:avahi
inet 192.168.122.2/32 scope global veth0

time - time is a simple command,it gives resource usage.

The time utility runs the specified program/command with the given arguments. When program/command finishes, time writes a message to standard error giving timing statistics about the program/command run. These statistics consist of
(i) The elapsed real time between invocation and termination,
(ii) The user CPU time , and
(iii) The system CPU time .

Binaries Provided - /usr/bin/time

Approach For Testing:

1. Installation check for time rpm

2.To verify output format of time command with -p or --portability option
Example:

# /usr/bin/time -p sleep 2
real 2.00
user 0.00
sys 0.00

3.To verify the Exit Status of the command using the Time utility.
(i) If command is Invoked using time, the exit status is that of command invoked,otherwise it is 127 if command could not be found.

Example:

# /usr/bin/time -f "%x Exit status for %C" pwd
/home/basheer/
0 Exit status for pwd

# /usr/bin/time -f "%x Exit status for %C" pwd1
/usr/bin/time: cannot run pwd1: No such file or directory
127 Exit status for pwd1

4.To verify output file is created or not, using --output or -o option.

Example:

# /usr/bin/time -o time_out.txt sleep 2
The above statement should create a time_out.txt file

5.To verify the -append or -a option provided by time utility

Example:

# /usr/bin/time -v -a -o time_out.txt sleep 3
The output of the "sleep 3" command should be appended to time_out.txt

6.To verify the --format or -f option and verify the output pattren as provided.

Example:

# /usr/bin/time -f "%E real,%U user,%S sys,'%C' cmd-executed" sleep 2
0:02.00 real,0.00 user,0.00 sys,'sleep 2' cmd-executed

7.Create custom shell script dynamically and provide the same as input to the time utility and verify the output.

# /usr/bin/time <Shell-script>

Example:

# /usr/bin/time -v -o out ./custom-script.sh
# cat out | grep custom-script1.sh
Command being timed: "./custom-script.sh"

As a replacement for the lsb_dtk which will be removed, because of upstream deprecation.

This is a link to the deprecation activity:

https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=2812

And this is the main page for the new Dist Check test:

http://ispras.linuxbase.org/index.php/About_Distribution_Checker