Announcement

Collapse
No announcement yet.

License Expiration/License Invalid messages after upgrade to CentOS 6.8

Collapse
This is a sticky topic.
X
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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:

    Code:
    ~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:

    Code:
    [root@server]# curl https://www.google.com
    Illegal instruction
    [root@server]#
    If you are experiencing this issue, please submit a support ticket.

  • #2
    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.
    Last edited by Justec; 05-26-2016, 11:26 AM. Reason: New Information
    [ JUSTIN ]
    [ OFF unit ]
    [ WEB DESIGN / DEVELOPMENT, GRAPHIC DESIGN, OTHER STUFF
    ]

    Comment


    • #3
      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

      Comment


      • #4
        Originally posted by d2d4j View Post
        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
        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.
        [ JUSTIN ]
        [ OFF unit ]
        [ WEB DESIGN / DEVELOPMENT, GRAPHIC DESIGN, OTHER STUFF
        ]

        Comment


        • #5
          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.

          Comment


          • #6
            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

            Comment


            • #7
              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

              Comment


              • #8
                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&...OtGN8Qfs-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&amp;...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

                Comment

                Working...
                X