License Expiration/License Invalid messages after upgrade to CentOS 6.8

We’ve had reports of license issues after automatic upgrades to CentOS 6.8 on some servers. This presents itself by showing a message in NodeWorx stating that the license is set to expire. If 24 hours passes, the license will expire.

To reproduce this issue, from the command line, run the following:

~iworx/cron/license.pex --sync

An error stating “Illegal Instruction” appears if this is the same issue.

To confirm this issue using curl, run the following command:

[root@server]# curl https://www.google.com
Illegal instruction
[root@server]# 

If you are experiencing this issue, please submit a support ticket.

Is anyone else having any issues with the NodeWorx Dashboard? I can’t expand (+) the Service Status, Server Info, or Server At A Glance. Also, the left side menu doesn’t work either (although it does work from interior pages).

This is using Chrome on PC. I’ve tried restarting Chrome, running in incognito window, as well as check the console for any javascript or other errors.
Not sure if this is related to the 6.8 update or just a fluke.

EDIT: If anyone else runs into this, support fixed this issue by just running InterWorx permission fix tool.

Hi Jenna

I think I must be behind the time, there were no centos update this morning but after running update, it found 6.8 updates

I have installed these in the DNS server only, and no issues over curl

Interestingly though, it’s shows curl 7.19 but the latest is 7.49 I think from memory, which hopefully on our new server which runs latest curl, these updates will not be present for curl, but we will only do the 6.8 update after full server transfers

Justec, good post but I think your on centos 7, and I found it was easier to permfix on a monthly cron when we were testing centos 7

Many thanks

John

My post from the other day was me getting the latest PHP 5 version to my CentOS 6.x server. I was on 6.7 and now this morning I am on CentOS release 6.8.
So I have a feeling something in this 6.7>6.8 upgrade broke something with iworx permissions.

I haven’t yet rebooted after the upgrade, but will probably do that late tonight.

Hi,

the problem comes from this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1249426

Interworx support told me a workaround by changing the crontab entry:

30 12,18,0,6 * * * cd /home/interworx/cron ; ./iworx.pex --quad_daily

to

30 12,18,0,6 * * * export NSS_DISABLE_HW_GCM=1 ; cd /home/interworx/cron ; ./iworx.pex --quad_daily

using:

$ crontab -e -u iworx

This solves the license issue, but this is still a bigger issue, as wordpress installations report errors and still “curl https://www.google.at” does not work.

Hi arusa

Please could I ask what NSS version you are using

On our DNS only server (the only server we updated to centos 6.8 so far) our NSS is 3.21

A check on some production servers show we are not using NSS

I seem to remember coming across NSS and curl with our billing platform, on payment gateways which require to use TLS only (now most require specific TLSv1.2), but I would need to find my notes to remember fully.

Many thanks

John

Hi,

in dmesg I see error messages like:

curl[458] trap invalid opcode ip:7fa67ee02d60 sp:7ffdcb2a8ed8 error:0 in libfreeblpriv3.so[7fa67edb0000+72000]
php[8814] trap invalid opcode ip:7feefcf4ad60 sp:7ffdd8bc9268 error:0 in libfreeblpriv3.so[7feefcef8000+72000]

So I assume the problem is with nss-softokn-freebl. Installed packages with “nss” are:

nss-softokn-freebl-3.14.3-23.el6_7.x86_64
nss_compat_ossl-0.9.6-2.el6_7.x86_64
nss-sysinit-3.21.0-8.el6.x86_64
nss-util-3.21.0-2.el6.x86_64
nss-tools-3.21.0-8.el6.x86_64

Hi Arusa
Many thanks, and I think you maybe correct.
Please coudl I ask if you get a connect using the following
curl -v --TLSv1.2 https://google.com
Below is my test from DNS only server, with NSS, and below that a failed connection from an earlier server, whilst trying to resolve a gateway connection.
If it fails, what OpenSSL versions do you have on system (rpm -qa | grep openssl)
I am sorry though, my thinking maybe nothing to do with this issue, so I apologise in advance, but I do seem to remember having to upgrade NSS a few years ago, just cannot remember why sorry
Many thanks
John
Good Connection
[root@ns4 ~]# curl -v --TLSv1.2 https://google.com

  • About to connect() to google.com port 443 (#0)
  • Trying 216.58.208.174… connected
  • Connected to google.com (216.58.208.174) port 443 (#0)
  • Initializing NSS with certpath: sql:/etc/pki/nssdb
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt
    CApath: none
  • SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • Server certificate:
  •   subject: CN=*.google.com,O=Google Inc,L=Mountain View,ST=California,C=US
    
  •   start date: May 18 11:14:54 2016 GMT
    
  •   expire date: Aug 10 10:46:00 2016 GMT
    
  •   common name: *.google.com
    
  •   issuer: CN=Google Internet Authority G2,O=Google Inc,C=US
    

> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.21 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: google.com
> Accept: /
>
< HTTP/1.1 302 Found
< Cache-Control: private
< Content-Type: text/html; charset=UTF-8
< Location: https://www.google.co.uk/?gfe_rd=cr&ei=Z0JIV-jtOtGN8Qfs-ZL4Aw
< Content-Length: 262
< Date: Fri, 27 May 2016 12:49:43 GMT
< Alternate-Protocol: 443:quic
< Alt-Svc: quic=":443"; ma=2592000; v=“34,33,32,31,30,29,28,27,26,25”
<
<HTML><HEAD><meta http-equiv=“content-type” content=“text/html;charset=utf-8”>
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF=“https://www.google.co.uk/?gfe_rd=cr&ei=Z0JIV-jtOtGN8Qfs-ZL4Aw”>here</A>.
</BODY></HTML>

  • Connection #0 to host google.com left intact
  • Closing connection #0
    [root@ns4 ~]#
    FAIL CONNECTION
    [root@7 ~]# curl -v https://sandbox.redacted.url
  • About to connect() to sandbox.redacted.url port 443 (#0)
  • Trying nnn.128.115.nnn… connected
  • Connected to sandbox.redacted.url (nnn.128.115.nnn) port 443 (#0)
  • Initializing NSS with certpath: sql:/etc/pki/nssdb
  • CAfile: /etc/pki/tls/certs/ca-bundle.crt
    CApath: none
  • NSS error -5938
  • Closing connection #0
  • SSL connect error
    curl: (35) SSL connect error