Beakerlib fix #8

mrc0mmand · 2016-12-18T17:10:42Z

Currently released version of beakerlib doesn't contain an equivalent for function rlIsRHEL on CentOS. This causes unexpected fails on CentOS when this function is used for relevancy. I discussed this with beakerlib devels and the fix should be a part of the next release. Until then, I created a custom RPM with necessary patches, which can be used as a temporary workaround (this RPM is based on the released stable codebase).

To avoid mass-editing all tests to support rlIsRHEL along with rlIsCentOS, the test-runner.sh script adds a new function to the beakerlib library, which simply calls rlIsCentOS when rlIsRHEL is called (CentOS-exclusive).

This PR also disables CentOS 5 jobs, as they are slightly incompatible with this workaround (and these jobs were unused by tests so far).

If everything is all right, I'll rebase all branches of the remaining PRs, so we can get relevant test results.

Relevant bugs: BZ#1214190

mrc0mmand · 2016-12-18T20:36:47Z

.travis.yml

@@ -3,17 +3,17 @@ sudo: required
 env:
    matrix:
        # openssl tests
-        - COMP=openssl OS_TYPE=centos OS_VERSION=5
+        #- COMP=openssl OS_TYPE=centos OS_VERSION=5
        - COMP=openssl OS_TYPE=centos OS_VERSION=6
        - COMP=openssl OS_TYPE=centos OS_VERSION=7
        - COMP=openssl OS_TYPE=fedora OS_VERSION=24


Regarding the recent release of Fedora 25: do you prefer explicit version assignment (24, 25, etc.) or the latest tag would be sufficient? With the latest tag we would avoid bumping the version every ~6 months (source).

latest sounds like a good choice considering fast release cycle of Fedora. But we should consider running the tests on other supported Fedora versions, which would require bumping anyway..

Running tests on all supported Fedora versions definitely sounds like a good idea, but it also brings several issues, which need to be addressed (like nss in F25 not supporting SSLv3, etc.). Phase relevancy for specific Fedora releases will be necessary in these cases.

in general, for Fedora, we care only about latest

I think it's a bit too early to say and we have too little resources to run on multiple Fedora versions, the probability of regressions is highest in newest versions anyway

tomato42 · 2017-01-04T17:48:05Z

scripts/test-runner.sh

@@ -47,8 +47,13 @@ if [[ $OS_TYPE != "fedora" ]]; then
    $PKG_MAN -y install epel-release
 fi

+# TEMPORARY WORKAROUND
+# TODO: Remove when a fixed official beakerlib version is released
+yum -y install https://sumsal.cz/dev/beakerlib-1.11centos-99.fc23.noarch.rpm


I don't like dependency on external infrastructure, even temporary

aren't we using it just for one little function? couldn't we copy-paste it instead of that?

Even though we use only a one little function, which consist of 4 lines, there are several other patches, which need to be applied, so this function could work properly. I hate this solution as much as you, but without that, we have several other not-so-nice solutions:

Store the patches in this repo and apply them before testing

Store the built RPM in the repo instead of somewhere on an external infrastructure

As much as I'd like to avoid any of these options, we'll have to pick one of them, otherwise the incredibly slow release cycle of beakerlib would block our progress.

Hm, I just noticed, that this fix is included in the testing version of beakerlib (Fedora rawhide & epel-testing), so we could finally get rid of this workaround. Will look into that.

After a few hours of experimenting and debugging I have good news and bad news.

The good news is that for installing the latest version of beakerlib we can use repo epel-testing on CentOS and updates-testing on Fedora. Both repos contain the fixed version of beakerlib.

The bad news is that the new version fixes a bug in rlWaitForSocket function. This function now actually waits for socket to close when --close is specified. This would be great, but the way how it checks the socket is horrible:

local cmd="netstat -nla | grep -E '$grep_opt' >/dev/null"

This thing right here checks if the socket/port is listed in netstat's output, but this includes remote ports along with local ones, which is a problem. Many interoperability tests kill the server part, wait for its PID to disappear and then wait for the socket to close. But the nestat's output in this case contains client's socket as well. This thing worked before, because it grep'd only sockets in LISTEN state. Now it greps all sockets, even those in TIME_WAIT state, which is relevant for this case.

Long story short, each rlRun "rlWaitForSocket 4433 --close" now takes around 50 seconds to complete, because of this:

# netstat -nla Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State ... tcp6 0 0 ::1:56226 ::1:4433 TIME_WAIT

This means, that many interoperability test now take several to dozens of hours to complete, which is totally useless, especially in Travis. Fix for this issue is not complicated, but it can take another several months to propagate to testing repos. @tomato42, @ep69 any ideas?

@mrc0mmand I've just communicated with our beakerlib maintainer (dapospis) and he told me the -a argument was added there to address https://bugzilla.redhat.com/show_bug.cgi?id=1388422 . If you would be able to come up with a fix that satisfies needs of both the mentioned bugzilla and yours, we can get it to testing beakerlib in a matter of hours.

yes, this is not a good change to beakerlib, just commented on the BZ

Following Dalibor's recommendation, I filed a new bug where the progress on this issue can be tracked: BZ#1416014.

so, can we drop that change from this PR?

mrc0mmand · 2017-01-28T19:20:26Z

Regarding the conversations in this PR, I made following changes:

Travis/Docker now uses the latest version of Fedora, so manual bumping of its version is no longer necessary.
The patch for BZ#1388422, which was causing huge delays in the testing, was reverted (see BZ#1416014). That means we're no longer blocked by waiting for a fix.

As mentioned in one of the conversation threads, we're now using the testing version of beakerlib (updates-testing on Fedora, epel-testing on CentOS). Even though the testing sounds scary here, it'll ensure faster fixes for upcoming issues and it just works™.

Edit: Fedora 25 introduces a new issue - unsupported SSLv3 in NSS. I guess simple conditions in affected tests should be enough to mitigate this.

tomato42 · 2017-01-30T16:23:05Z

yes, testing if the code is not running on RHEL 5, 6 or 7 and expecting SSLv3 to fail is the correct solution

mrc0mmand · 2017-01-30T18:04:30Z

The Travis fails are now caused by two issues:

SSLv3 in gnutls/Interoperability/renegotiation-with-NSS

this is partially fixed by gnutls/renegotiation-with-NSS: Test extension #9
- I guess we'll need to explicitly enable DHE-DSS in GNUTLS to make it work on F25

Strange NSS DB fails in nss/Interoperability/Interoperability-with-OpenSSL

this test needs to be rewritten
it looks like the current fails are probably caused once again by expect (gen-rsaca.expect, etc.) as it passes when I run it manually
eg:

:: [  BEGIN   ] :: Generate RSA CA certificate :: actually running './gen-rsaca.expect'
spawn certutil -S -z ./random -n rsaca -s cn=RSA Testing CA -t C,C,C -m 1000 -Z SHA1 -k rsa -g 2048 -x -v 12 -d nss-certs -f password-is-test.txt --keyUsage digitalSignature,keyEncipherment,dataEncipherment,keyAgreement,certSigning,crlSigning,critical -2


Generating key.  This may take a few moments...

Is this a CA certificate [y/N]?
y
Enter the path length constraint, enter to skip [<0 for unlimited path]: > 0
Is this a critical extension [y/N]?
y
:: [   PASS   ] :: Generate RSA CA certificate (Expected 0, got 0)
:: [  BEGIN   ] :: Create a small random file :: actually running 'dd if=/dev/urandom of=random bs=1 count=40'
40+0 records in
40+0 records out
40 bytes copied, 0.000225753 s, 177 kB/s
:: [   PASS   ] :: Create a small random file (Expected 0, got 0)
:: [  BEGIN   ] :: Generate server RSA certificate :: actually running './gen-rsasrv.expect'
spawn certutil -S -z ./random -n rsasrv -s o=RSA Testing,cn=localhost -t u,u,u -m 2001 -Z SHA1 -k rsa -g 2048 -c rsaca -v 12 -d nss-certs -f password-is-test.txt --keyUsage digitalSignature,keyEncipherment,dataEncipherment,keyAgreement,critical -2 -8 localhost


Generating key.  This may take a few moments...

certutil: could not find certificate named "rsaca": SEC_ERROR_BAD_DATABASE: security library: bad database.
certutil: unable to create cert (security library: bad database.)
expect: spawn id exp3 not open
    while executing
"expect "Enter the path length constraint" { send "\r" }"
    (file "./gen-rsasrv.expect" line 5)
:: [   FAIL   ] :: Generate server RSA certificate (Expected 0, got 1)

Apart from that I'd say this branch is ready to merge. Then I'd continue with rebasing #5, fix its remaining issues with expect and merge it as well.

tomato42 · 2017-01-30T19:26:01Z

why we can't merge this PR with changes in #9

what's the point of CI if we merge known broken commits? If it takes more changes to keep Travis passing, then lets put more change in single bucket.

mrc0mmand · 2017-01-30T19:32:27Z

It's because the failing part of the gnutls/Interoperability/renegotiation-with-NSS was rewritten in #9, thus by fixing this issue in this PR we'd create a merge conflict.

Edit: maybe we could disable that test case in this PR to get rid of a known fail

tomato42 · 2017-01-31T12:24:27Z

ok, then let's disable it in this PR and reenable it in #9

mrc0mmand · 2017-01-31T17:34:49Z

So, after fixing the last blocking issues, I discovered another two. I've already fixed the first one in my testing branch (replacing 'latest' OS tag with the actual OS version), but the second one is giving me a headache.

These ciphersuites are failing on F25 when used with NSS:

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_DHE_DSS_WITH_RC4_128_SHA

After going through the supported ciphersuites list provided by NSS listsuites utility, I found out[0] that TLS_DHE_DSS_WITH_RC4_128_SHA is already disabled in NSS, so it shouldn't work. But the remaining RSA ones are 'enabled' and work when NSS is acting as a server. When NSS is a client, a strange error occurs:

# gnutls-serv --http -p 4433 --x509keyfile key.pem --x509certfile cert.pem --priority NORMAL:+ARCFOUR-128:+DHE-DSS:+SIGN-DSA-SHA1:+SIGN-DSA-SHA224:+SIGN-DSA-SHA256:+VERS-TLS1.2 &>server.log &
# /usr/lib64/nss/unsupported-tools/tstclnt -h localhost -p 4433 -d sql:nssdb -o -c :0004 -V tls1.0:
tstclnt: read from socket failed: SSL_ERROR_SSL_DISABLED: Cannot connect: SSL is disabled.

Explicitly enabling SSLv3 yields expected results:

tstclnt: error setting SSL/TLS version range : SSL_ERROR_INVALID_VERSION_RANGE: SSL version range is not valid.

Using selfserv with gnutls-cli (and the same settings) works as intended. Is this intentional or is it some strangeness/bug in tstclnt/strsclnt?

[0]

# ./listsuites | grep -A 1 TLS_DHE_DSS_WITH_RC4_128_SHA
TLS_DHE_DSS_WITH_RC4_128_SHA:
  0x0066 DHE   DSA   RC4      128 SHA1   Disabled      Domestic            
# ./listsuites | grep -A 1 TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_MD5:
  0x0004 RSA   RSA   RC4      128 MD5    Enabled       Domestic            
# ./listsuites | grep -A 1 TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_SHA:
  0x0005 RSA   RSA   RC4      128 SHA1   Enabled       Domestic

tomato42 · 2017-02-09T18:09:46Z

But the remaining RSA ones are 'enabled' and work when NSS is acting as a server.

No, that's a bug. The RC4 is disabled through Crypto Policy. If it affects only the client side then it's a bug how Crypto Policy is handled.

mrc0mmand · 2017-02-11T22:28:47Z

Thanks for pointing out the crypto policies, it looks like that's the culprit. As can be seen below, this issue 'fixes' itself, when a F24 version of the crypto-policies package is used:

Fedora 25

# rpm -q nss gnutls crypto-policies
nss-3.28.1-1.3.fc25.x86_64
gnutls-3.5.8-2.fc25.x86_64
crypto-policies-20160921-2.git75b9b04.fc25.noarch
### GNUTLS <-> NSS ###
# ./nss-repro.sh
...
+ gnutls-serv -p 4433 --x509keyfile key.pem --x509certfile cert.pem --priority NORMAL:+ARCFOUR-128:+DHE-DSS:+SIGN-DSA-SHA1:+SIGN-DSA-SHA224:+SIGN-DSA-SHA256:+VERS-TLS1.2
HTTP Server listening on IPv4 0.0.0.0 port 4433...done
HTTP Server listening on IPv6 :: port 4433...done
+ /usr/lib64/nss/unsupported-tools/strsclnt -p 4433 -d sql:nssdb -o -C :0004 -V tls1.0: localhost
strsclnt: PR_Send returned error -12268, OS error 0: Cannot connect: SSL is disabled.
Error in handshake
strsclnt: 0 cache hits; 0 cache misses, 0 cache not reusable
          0 stateless resumes

...
SERVER LOG:
+ cat server.log

* Accepted connection from IPv6 ::1 port 44388 on Sat Feb 11 17:04:18 2017
Error: The TLS connection was non-properly terminated.

### NSS <-> GNUTLS ###
# ./nss-repro-serv.sh
+ /usr/lib64/nss/unsupported-tools/selfserv -v -d sql:./nssdb/ -p 4433 -V tls1.0: -H 1 -n rsa -c :0004 -u
+ gnutls-cli --port 4433 --insecure --priority NORMAL:+ARCFOUR-128:+DHE-DSS:+SIGN-DSA-SHA1:+SIGN-DSA-SHA224:+SIGN-DSA-SHA256:+VERS-TLS1.2 localhost
Processed 0 CA certificate(s).
Resolving 'localhost:4433'...
Connecting to '::1:4433'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject `CN=localhost', issuer `CN=localhost', serial 0x00867f8e59236ddbbc, RSA key 2048 bits, signed using RSA-SHA256, activated `2017-02-11 22:05:38 UTC', expires `2027-
02-09 22:05:38 UTC', key-ID 
...
- Description: (TLS1.2)-(RSA)-(ARCFOUR-128)-(MD5)
...
- Handshake was completed

- Simple Client Mode:

SERVER LOG:
+ cat server.log
...
selfserv: About to call accept.
selfserv: HDX PR_Read hit EOF returned error 0:
Success

Fedora 25, crypto-policies from Fedora 24:

# rpm -q nss gnutls crypto-policies
nss-3.28.1-1.3.fc25.x86_64
gnutls-3.5.8-2.fc25.x86_64
crypto-policies-20151104-2.gitf1cba5f.fc24.noarch
### GNUTLS <-> NSS ###
# ./nss-repro.sh
...
+ gnutls-serv -p 4433 --x509keyfile key.pem --x509certfile cert.pem --priority NORMAL:+ARCFOUR-128:+DHE-DSS:+SIGN-DSA-SHA1:+SIGN-DSA-SHA224:+SIGN-DSA-SHA256:+VERS-TLS1.2
HTTP Server listening on IPv4 0.0.0.0 port 4433...done
HTTP Server listening on IPv6 :: port 4433...done
+ /usr/lib64/nss/unsupported-tools/strsclnt -p 4433 -d sql:nssdb -o -C :0004 -V tls1.0: localhost
No certificates found!
strsclnt: 0 cache hits; 1 cache misses, 0 cache not reusable
          0 stateless resumes
strsclnt: 0 cache hits; 1 cache misses, 0 cache not reusable
          0 stateless resumes

...
SERVER LOG:
+ cat server.log

* Accepted connection from IPv6 ::1 port 44382 on Sat Feb 11 17:01:13 2017
- Description: (TLS1.2)-(RSA)-(ARCFOUR-128)-(MD5)
...

### NSS <-> GNUTLS ###
# Same result as above

The F24 version of crypto-policies doesn't even contain a policy for NSS, so that may have some effect on this issue. Also, trying the scenario above with the latest version of crypto policies (rawhide) yields the same results as with the F25 package.

mrc0mmand · 2017-02-12T13:44:34Z

Also, the upstream version (3.30 Beta) has the same behavior as the 3.28.1 with older crypto-policies package, so I guess the handling of Crypto Policies has been fixed there.

tomato42 · 2017-02-21T17:39:44Z

Please rebase to get rid of the merge commit

I'm assuming that you'll continue to work on this to fix the errors reported by travis, won't you?

mrc0mmand · 2017-02-22T10:03:49Z

Rebased. And yes, I already included two fixes which should resolve some of the reported errors (393fa42 and 9638b90).

mrc0mmand · 2017-02-22T11:38:10Z

The (hopefully) last remaining issues:

gnutls/Interoperability/renegotiation-with-NSS should be disabled for now, as I've already rewritten it (I'll open PRs for the remaining gnutls tests soon).
gnutls/Interoperability/TLSv1-2-with-NSS fails on the latest Fedora as was discussed in previous comments. It's probably worth filing a bug.
This is a nice race condition - there's a one unexpected fail in gnutls testsuite, because it couldn't match GET / HTTP/1.0 thanks to this:

spawn /bin/sh -c /usr/lib64/nss/unsupported-tools/tstclnt -h localhost -p 4433 -d sql:./nssdb/ -n rsa-client -c :0004 -V tls1.0:

subject DN: CN=localhost

issuer  DN: CN=RSA CA

GE0 cache hits; 1 cache misses, 0 cache not reusable

0 stateless resumes

T / HTTP/1.0

This could be potentially fixed by tweaking the nss-client.expect script (again), as the issue is (probably) caused by sending GET / HTTP/1.0\r\r too early:

...
    "subject DN" {
        send "GET / HTTP/1.0\r\r";
        expect -timeout 5 "HTTP/1.0 200 OK" {
...

tomato42 · 2017-02-22T16:40:56Z

gnutls/Interoperability/TLSv1-2-with-NSS fails on the latest Fedora as was discussed in previous comments. It's probably worth filing a bug.

please do, and comment it out with the link to that bug as a reason for waiving

This is a nice race condition - there's a one unexpected fail in gnutls testsuite, because it couldn't match GET / HTTP/1.0 thanks to this:

yes, it does look like this

tomato42 · 2017-02-27T15:41:56Z

scripts/test-setup.sh

+FAILED_CHECKS=0
+FAILED_NAMES=()
+while read file; do
+    if ! grep -Pzoq "rlGetTestState.*$" "$file"; then


why -z option to grep? isn't -o useless with -q?

I don't know the Perl regular expressions, but usually $ specifies end of line, not end of file, and .* won't match newlines, so I'm not exactly sure that this makes sure that the rlGetTestState is "at their end"...

tomato42 · 2017-02-27T15:44:00Z

scripts/test-setup.sh

@@ -17,7 +18,7 @@ CERTGEN_PATH="openssl/Library/certgen"
 FAILED_CHECKS=0
 FAILED_NAMES=()
 while read file; do
-    if ! grep -Pzoq "rlGetTestState.*$" "$file"; then
+    if ! grep -Pzoq "rlGetTestState[[:space:]]*$" "$file"; then


that change should be in commit 31dcda2

tomato42

please state in 393fa4275129d03969514 why those tests are failing

tomato42 · 2017-02-27T15:51:47Z

scripts/test-runner.sh

+# version tag with the actual OS version
+# So far the 'latest' tag is used only for Fedora
+if [[ $OS_VERSION == "latest" ]]; then
+    OS_VERSION="$(awk '{ print $3; }' < /etc/fedora-release)"


that change should in the same commit as the change to .travis.yml

tomato42 · 2017-02-27T15:53:30Z

gnutls/Interoperability/TLSv1-2-with-NSS/runtest.sh

-            i=$(($i+1))
+            #
+            # Crypto Policy handling seems to be broken in NSS on F25 for RC4
+            # BZ#1426267


while it is broken, I don't think it is broken in a way that we can't enable those ciphers, is it?

I meant, can't we make NSS on Fedora enable those ciphers? i.e. override the Crypto Policy?

The idea of those tests it to verify that those ciphers are implemented the same way in both libraries under test, not that the sets of disabled ciphers/protocols are the same...

Fair point. This can be easily done by enforcing NSS to ignore the crypto policies entirely by setting the NSS_IGNORE_SYSTEM_POLICY env variable to 1.

mrc0mmand · 2017-03-01T20:26:54Z

Thanks for the feedback. I have updated the commits as follows:

if ! grep -Pzoq "rlGetTestState[[:space:]]*$" "$file"; then ... was moved into the correct commit and the -o option was dropped (see d56dd41).
The commit with the temporary workaround using an external site for a beakerlib package was dropped completely.
A brief informational message was added to the commit regarding (temporarily) disabled test cases, see 8ce1ae2.
The commit with the replacement of the latest tag with an actual Fedora version was squashed with commit b1a4b3d.

Regarding the last requested change - I disabled the problematic ciphersuites in 38e3a79 because they were causing Travis fails, and I thought we want to merge this request when, and only when, it is passing. Also, the mentioned ciphersuites are disabled only on Fedora 25 (and above). I guess I could drop the > from the condition, so they would be automatically enabled once the Fedora 26 is released.

tomato42 · 2017-03-07T15:44:38Z

scripts/test-setup.sh

+FAILED_CHECKS=0
+FAILED_NAMES=()
+while read file; do
+    if ! grep -Pzq "rlGetTestState[[:space:]]*$" "$file"; then


why -z option is used?
won't it also match the case when rlGetTestState is used inside rlRun, or in general, inside phase?

No, -z replaces all newlines with a NUL character (\0), so the $ anchor in this case matches the EOF.

$ echo -e "rlGetTestState\nrlRun 'echo'" | grep -Pzq 'rlGetTestState[[:space:]]*$' grep: unescaped ^ or $ not supported with -Pz

Hm, that's interesting, I've never seen this error on any distro I tested this on. However, it returns 0 even in case when it should fail (on RHEL/CentOS 6.8+ and 7.3+):

E.g.:

# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.8 (Santiago) # echo -e "rlGetTestState\nrlRun 'echo'" | grep -Pzq 'rlGetTestState[[:space:]]*$'; echo $? 0

Nevertheless, it can be easily fixed by replacing the $ anchor with \z, which matches the end of the input string, ignoring all line breaks (-z is still necessary to avoid reading input line by line).

# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.8 (Santiago) # echo -e "rlGetTestState\nrlRun 'echo'" | grep -Pzq 'rlGetTestState[[:space:]]*\z'; echo $? 1 # echo -e "rlGetTestState\n\n \t\t \n" | grep -Pzq 'rlGetTestState[[:space:]]*\z'; echo $? 0

Same results apply for RHEL/CentOS 7.3 and Fedora 25.

Thanks.

yes, \z works, thanks!

tomato42 · 2017-03-07T15:49:58Z

gnutls/Interoperability/TLSv1-2-with-NSS/runtest.sh

-            i=$(($i+1))
+            #
+            # Crypto Policy handling seems to be broken in NSS on F25 for RC4
+            # BZ#1426267


I meant, can't we make NSS on Fedora enable those ciphers? i.e. override the Crypto Policy?

The idea of those tests it to verify that those ciphers are implemented the same way in both libraries under test, not that the sets of disabled ciphers/protocols are the same...

Check if all tests have rlGetTestState command to prevent false-positives

Centos 6 - unsupported Centos 7 - there is a bug, which was fixed in RHEL/Centos 7.3 => re-enable this test when 7.3 docker image is available

CentOS 5 is incompatible with the beakerlib workaround. Also, no tests were running on RHEL/CentOS 5 anyway (which can change in the future).

All disabled test by this commit are going to be updated in the near future.

This is a temporary workaround for BZ#1426267.

mrc0mmand commented Dec 18, 2016

View reviewed changes

tomato42 reviewed Jan 4, 2017

View reviewed changes

This was referenced Jan 30, 2017

gnutls/renegotiation-with-NSS: Test extension #9

Merged

Fix several issues in CI/tests #5

Closed

tomato42 assigned mrc0mmand Jan 30, 2017

mrc0mmand force-pushed the beakerlib-fix branch from d82f6b1 to 9638b90 Compare February 22, 2017 09:59

mrc0mmand force-pushed the beakerlib-fix branch from 42b1888 to 2a4c4ce Compare February 25, 2017 17:01

tomato42 reviewed Feb 27, 2017

View reviewed changes

tomato42 requested changes Feb 27, 2017

View reviewed changes

tomato42 reviewed Feb 27, 2017

View reviewed changes

mrc0mmand force-pushed the beakerlib-fix branch 2 times, most recently from 01cf1f8 to a249677 Compare March 1, 2017 20:16

tomato42 requested changes Mar 7, 2017

View reviewed changes

mrc0mmand force-pushed the beakerlib-fix branch from a249677 to f578f4f Compare March 8, 2017 10:32

mrc0mmand and others added 12 commits March 8, 2017 14:29

test-setup.sh: Add test sanity check

0dae7e6

Check if all tests have rlGetTestState command to prevent false-positives

renego&resumption: Add missing rlGetTestState

5eb15aa

softhsm-integration: Disable on Centos 6 and 7

8fdd6cb

Centos 6 - unsupported Centos 7 - there is a bug, which was fixed in RHEL/Centos 7.3 => re-enable this test when 7.3 docker image is available

test-runner.sh: Preserve the environment

acbfa79

Send an EOF when it's actually expected

341f84e

Replace all rlIsRHEL calls with rlIsCentOS

375a4b5

Disable CentOS 5 jobs

dbddade

CentOS 5 is incompatible with the beakerlib workaround. Also, no tests were running on RHEL/CentOS 5 anyway (which can change in the future).

Install the latest version of beakerlib

95070ad

Temporarily disable failing tests

8f566e3

All disabled test by this commit are going to be updated in the near future.

Use the latest version of Fedora

b19f3a2

Temporarily disable this test until #9 is merged

339adc9

Force NSS to ignore crypto policies on F25+

339810b

This is a temporary workaround for BZ#1426267.

mrc0mmand force-pushed the beakerlib-fix branch from f578f4f to 339810b Compare March 8, 2017 13:30

tomato42 approved these changes Mar 8, 2017

View reviewed changes

tomato42 merged commit d1e394d into master Mar 8, 2017

mrc0mmand deleted the beakerlib-fix branch May 8, 2017 14:22

Beakerlib fix #8

Beakerlib fix #8

Uh oh!

Conversation

mrc0mmand commented Dec 18, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mrc0mmand Jan 19, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mrc0mmand commented Jan 28, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tomato42 commented Jan 30, 2017

Uh oh!

mrc0mmand commented Jan 30, 2017

Uh oh!

tomato42 commented Jan 30, 2017

Uh oh!

mrc0mmand commented Jan 30, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tomato42 commented Jan 31, 2017

Uh oh!

mrc0mmand commented Jan 31, 2017

Uh oh!

tomato42 commented Feb 9, 2017

Uh oh!

mrc0mmand commented Feb 11, 2017

Uh oh!

mrc0mmand commented Feb 12, 2017

Uh oh!

tomato42 commented Feb 21, 2017

Uh oh!

mrc0mmand commented Feb 22, 2017

Uh oh!

mrc0mmand commented Feb 22, 2017

Uh oh!

tomato42 commented Feb 22, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tomato42 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mrc0mmand commented Mar 1, 2017

Uh oh!

Choose a reason for hiding this comment

mrc0mmand Jan 19, 2017 •

edited

Loading

mrc0mmand commented Jan 28, 2017 •

edited

Loading

mrc0mmand commented Jan 30, 2017 •

edited

Loading