Solaris checkinstall script did not complete successfully

This is another post about the usefulness of reading man pages and READMEs.
The other day I was patching a Solaris box and was greeted with the following error:

This appears to be an attempt to install the same architecture and version of a package which is already installed. This installation will attempt to overwrite this package.

/some_long_path_to/install/checkinstall: /some_long_path_to//install/checkinstall: cannot open
pkgadd: ERROR: checkinstall script did not complete successfully
Dryrun complete.
No changes were made to the system.

I was beating my head against the wall for quite a while before I decided to give “man patchadd” a try. Thankfully, the helpful paragraph was found in a wink of an eye:

pkgadd is invoked by patchadd and executes the installation scripts in the pkg/install directory. The checkinstall script is executed with its ownership set to user install, if there is no user install then pkgadd executes the checkinstall script as noaccess. The SVR4 ABI states that the checkinstall shall only be used as an information gathering script. If the permissions for the checkinstall script are changed to something other than the initial settings, pkgadd may not be able to open the file for reading, thus causing the patch installation to abort with the following error:

pkgadd: ERROR: checkinstall script did not complete successfully.

There is no need to tell, that after the patch was moved to another directory where user noaccess (didn’t have user install) had enough permissions the problem had gone.

Have safe and flawless patching!

OpenSSL TLS 1.1 and wrong version number

If you, like myself, have been living under a rock you’d be also surprised to know that OpenSSL didn’t support TLSv1.1 and TLSv1.2 until version 1.0.1 .
Found out that accidently by trying to disable TLSv1 in Nginx which was running on a RHEL5 box with OpenSSL 0.9.8e. Below is how TLS handshake looked when TLSv1.1 was deliberately requested:

$ openssl s_client -host some_host_name_here -port 443 -tls1_1 -state -msg
CONNECTED(00000003)
SSL_connect:before/connect initialization
>>> TLS 1.1 Handshake [length 0096], ClientHello
    01 00 00 92 03 02 54 e6 ea 6b bc f9 c7 bc 47 4e
    da a9 74 2e c8 27 c4 90 18 94 eb cf 21 40 ef 11
    fe 09 a0 38 bf 2a 00 00 4c c0 14 c0 0a 00 39 00
    38 00 88 00 87 c0 0f c0 05 00 35 00 84 c0 13 c0
    09 00 33 00 32 c0 12 c0 08 00 9a 00 99 00 45 00
    44 00 16 00 13 c0 0e c0 04 c0 0d c0 03 00 2f 00
    96 00 41 00 0a 00 07 c0 11 c0 07 c0 0c c0 02 00
    05 00 04 00 ff 01 00 00 1d 00 0b 00 04 03 00 01
    02 00 0a 00 08 00 06 00 19 00 18 00 17 00 23 00
    00 00 0f 00 01 01
SSL_connect:SSLv3 write client hello A
>>> TLS 1.0 Alert [length 0002], fatal protocol_version
    02 46
SSL3 alert write:fatal:protocol version
SSL_connect:error in SSLv3 read server hello A
140075793618760:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.1
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1424419435
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Linux pptp stumbling blocks that I was hit by

While configuring a pptp on a Linux box I bumped into the several smalish issues which I’d like to blog about.

  1. Make sure that your network engineers have enabled traffic inspection on all intermediate firewalls between tunnel’s endpoints. Otherwise LCP won’t be able to finish its configuration negotiation phase even if the control channel on TCP port 1723 was successfully established before that.
  2. All you would get is the admonitions similar to the ones listed below:

    pppd call connection_name debug nodetach
    using channel 5
    Using interface ppp0
    Connect: ppp0 <--> /dev/pts/2
    sent [LCP ConfReq id=0x1    ]
    sent [LCP ConfReq id=0x1    ]
    sent [LCP ConfReq id=0x1    ]
    sent [LCP ConfReq id=0x1    ]
    sent [LCP ConfReq id=0x1    ]
    sent [LCP ConfReq id=0x1    ]
    sent [LCP ConfReq id=0x1    ]
    Modem hangup
    Connection terminated.
    Script pptp xxx.xxx.xxx.xxx --nolaunchpppd finished (pid 10385), status = 0x0
    

    Just remember, that without working LCP there will be no ppp connection. Period.

  3. If your are running Redhat Linux distro or any of its derivatives and want to start pptp tunnel using ifup command just do the following:
    • Create a configuration file /etc/sysconfig/network-scripts/ifcfg-your_connection_name
    • In my case the content of the file is rather ascetic and depending on your requirements yours might have different options:

      DEVICE=ppp0
      ONBOOT=yes
      USERCTL=yes
      DEFROUTE=no
      PEERDNS=no
      
    • Make sure that your_connection_name part of /etc/sysconfig/network-scripts/ifcfg-your_connection_name filename matches exactly with the one you have under /etc/ppp/peers/. Otherwise ifup simply won’t fly.
  4. Now you should be able to fire ip “ifup your_connection_name” and a just moment after you should have your tunnel up and running.

Have a stable connection!

Don’t forget to apply Solaris Live Upgrade patch or …

One day you might find yourself in a similar situation as I did when I wasn’t able to create a new boot environment:

# lucreate -n SolarisFeb16
Analyzing system configuration.
Comparing source boot environment  file systems with the
file system(s) you specified for the new boot environment. Determining
which file systems should be in the new boot environment.
Updating boot environment description database on all BEs.
Updating system configuration files.
The device  is not a root device for any boot environment; cannot get BE ID.
Creating configuration for boot environment .
Source boot environment is .
Creating boot environment .
Cloning file systems from boot environment  to create boot environment .
Creating snapshot for  on .
Creating clone for  on .
Setting canmount=noauto for  in zone  on .
ERROR: The boot environment name  does not have a boot device defined in .
ERROR: Root slice device  does not have a boot device defined in .> for BE  was not found: .
Population of boot environment  successful.
Creation of boot environment  successful.

Even the last two lines say that population and creation were successful luactivate would disagree:

# luactivate SolarisFeb16
ERROR: Unable to determine the configuration of the current boot environment .

The root case was an outdated 121430-xx patch. What is more important is that this patch is not part of the Recommended Patch Cluster:

Live Upgrade patch 121430-XX is included in the patches/ directory of the patchset, but this patch will not be applied during patchset installation. The decision to apply the Live Upgrade patch is left to the user, this is done to accommodate users who wish to independently manage the version of the Live Upgrade patch on their system. Where a user wishes to apply the Live Upgrade patch, this needs to be done manually with the patchadd command.

After installing the latest 121430-93 (as of this writing) the problem has happily disappeared.

A good reminder to myself to always check README(s).