Difference between revisions of "Test suite"
(→Known test suite issues) |
|||
| (21 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
[[Category:Lore]] |
[[Category:Lore]] |
||
| ⚫ | |||
| ⚫ | |||
| + | The following additional software (in addition to the requirements at [[Building]]) is needed to run "make check". As for the packages listed at [[Building]], the software packages are identified by their Debian / Ubuntu package names. |
||
| − | On Ubuntu or Debian systems, a number of packages need to be installed in order for "make check" to function. These include: |
||
| + | * csh (for some of the Berkeley DB tests) |
||
| − | |||
| + | * dejagnu (for many dejagnu-based tests) |
||
| − | * dejagnu |
+ | * expect (needed by dejagnu) |
| − | * |
+ | * g++ (for some API sanity checks) |
| − | * tcl |
+ | * tcl (needed by expect) |
| − | * tcl-dev ( |
+ | * tcl-dev (to build some kadm5 test programs) |
| − | * portmap (needed by lib/rpc-unit-test) |
||
| − | * csh (or maybe tcsh; needed by some of the libdb2 tests) |
||
== Known test suite issues == |
== Known test suite issues == |
||
| − | + | Prior to krb5-1.9, on Linux systems, sometimes the <code>--disable-rpath</code> option to <code>configure</code> is required in order to avoid problems with previously-installed versions of MIT krb5. Alternatively, you can run "make install" before "make check". |
|
| − | + | Prior to krb5-1.9, calls to krb5_c_random_os_entropy that pass the value 1 in the <code>strong</code> argument (which causes the library to read from the strong OS random number source) can cause stalls and timeouts in the test suite. Changing those calls to pass 0 instead will reduce the stalls. Starting in krb5-1.9, we disable the reading of strong random numbers during tests. This is primarily a problem on Linux systems. |
|
| + | |||
| + | Prior to krb5-1.9, the test suite tripped a bug where Dejagnu breaks the autoloading required by modern versions of Tcl. This manifests as errors such as: |
||
| + | |||
| + | <pre> |
||
| + | ERROR: (DejaGnu) proc "::tcl::tm::UnknownHandler ::tclPkgUnknown msgcat 1.4" does not exist. |
||
| + | </pre> |
||
| + | |||
| + | The Dejagnu maintainers are aware of this problem (http://lists.gnu.org/archive/html/dejagnu/2011-03/msg00002.html), but as of June 2011 there doesn't seem to be a release containing the fix. Since krb5-1.9, the offending piece of Tcl code (<code>clock format [clock seconds]</code>) is no longer used. A fix has been applied to the krb5-1.8 branch as well. ({{bug|6926}}) |
||
If an existing kdc.conf exists in the "installed" location, it can disrupt the automated tests, especially if it contains syntax errors. |
If an existing kdc.conf exists in the "installed" location, it can disrupt the automated tests, especially if it contains syntax errors. |
||
| − | On |
+ | On older Debian or Ubuntu systems, a bug in <code>expect</code> could cause stalls in the dejagnu parts of the test suite. It is documented at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421187<!-- -->. Current stable releases of Debian and Ubuntu no longer have an affected version of the <code>expect</code> package. |
| + | |||
| + | As of July 2012, portions of the test suite will fail if the current hostname does not properly resolve (e.g., if a hostname is set, but the IP address assigned via DHCP corresponds to a different name); setting explicit entries in <code>/etc/hosts</code> should be an effective workaround (an IPv6 entry may be needed in addition to an IPv4 entry). |
||
| − | The testing user's shell must be listed in /etc/shells or the gssftp tests will fail. This will cease to be a concern for the main krb5 test suite if and when the applications are unbundled into a separate package. |
||
| + | As of December 2015, on Fedora Linux, portions of the test suite will fail if the current hostname is not all lower-case and is not registered in the DNS. Our hostname canonicalization procedure (krb5_sname_to_principal()) downcases the result as the last step. Fedora uses nss-myhostname to ensure that the local hostname resolves, and (for reasons we're not completely certain of) nss-myhostname does not appear to work with a different case from the canonical one. |
||
| − | The rlogin and telnet dejagnu tests require root access; without it, the test suite will skip those tests. To run these tests, you can either run the test suite as root, or arrange for "rlogin <localhostname> -l root -x" to succeed. (The environment variables RLOGIN and RLOGIN_FLAGS can override the "rlogin" and "-x" parts of that command line.) This will also cease to be a concern for the main krb5 test suite if and when the applications are unbundled. |
||
| + | As of December 2015, running the test suite using the make flag -j9 causes the tests to fail, specifically in the kadm5 unit-test. There seems to be some issues with the test suite and parallel processing. For now make sure to run everything in sequence. |
||
Latest revision as of 09:47, 8 December 2015
Additional build requirements for running "make check"
The following additional software (in addition to the requirements at Building) is needed to run "make check". As for the packages listed at Building, the software packages are identified by their Debian / Ubuntu package names.
- csh (for some of the Berkeley DB tests)
- dejagnu (for many dejagnu-based tests)
- expect (needed by dejagnu)
- g++ (for some API sanity checks)
- tcl (needed by expect)
- tcl-dev (to build some kadm5 test programs)
Known test suite issues
Prior to krb5-1.9, on Linux systems, sometimes the --disable-rpath option to configure is required in order to avoid problems with previously-installed versions of MIT krb5. Alternatively, you can run "make install" before "make check".
Prior to krb5-1.9, calls to krb5_c_random_os_entropy that pass the value 1 in the strong argument (which causes the library to read from the strong OS random number source) can cause stalls and timeouts in the test suite. Changing those calls to pass 0 instead will reduce the stalls. Starting in krb5-1.9, we disable the reading of strong random numbers during tests. This is primarily a problem on Linux systems.
Prior to krb5-1.9, the test suite tripped a bug where Dejagnu breaks the autoloading required by modern versions of Tcl. This manifests as errors such as:
ERROR: (DejaGnu) proc "::tcl::tm::UnknownHandler ::tclPkgUnknown msgcat 1.4" does not exist.
The Dejagnu maintainers are aware of this problem (http://lists.gnu.org/archive/html/dejagnu/2011-03/msg00002.html), but as of June 2011 there doesn't seem to be a release containing the fix. Since krb5-1.9, the offending piece of Tcl code (clock format [clock seconds]) is no longer used. A fix has been applied to the krb5-1.8 branch as well. ([krbdev.mit.edu #6926])
If an existing kdc.conf exists in the "installed" location, it can disrupt the automated tests, especially if it contains syntax errors.
On older Debian or Ubuntu systems, a bug in expect could cause stalls in the dejagnu parts of the test suite. It is documented at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421187. Current stable releases of Debian and Ubuntu no longer have an affected version of the expect package.
As of July 2012, portions of the test suite will fail if the current hostname does not properly resolve (e.g., if a hostname is set, but the IP address assigned via DHCP corresponds to a different name); setting explicit entries in /etc/hosts should be an effective workaround (an IPv6 entry may be needed in addition to an IPv4 entry).
As of December 2015, on Fedora Linux, portions of the test suite will fail if the current hostname is not all lower-case and is not registered in the DNS. Our hostname canonicalization procedure (krb5_sname_to_principal()) downcases the result as the last step. Fedora uses nss-myhostname to ensure that the local hostname resolves, and (for reasons we're not completely certain of) nss-myhostname does not appear to work with a different case from the canonical one.
As of December 2015, running the test suite using the make flag -j9 causes the tests to fail, specifically in the kadm5 unit-test. There seems to be some issues with the test suite and parallel processing. For now make sure to run everything in sequence.
