Since last 5.5.12 update for php-fpm you might find you cannot run php webs on your host and you might find messages similar to this on your logs:

connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied) while connecting to upstream

Fixing bug #67060 they changed the default behaviour for FPM when creating its sockets. You probably used to have in you config file two lines like this:

user = www-data
group = www-data

While this created both the process and the socket file with that user and group, now it does it only for the process, and the socket file is created by default with root as an owner.

Now you have to add this, changing to the appropriate user if needed:

listen.owner = www-data
listen.group = www-data

And restart your php-fpm process.

Thanks!

The VPN client Checkpoint has for their products is a royal pain in the ass to run, so probably you’ve found that the easier way to connect one of those systems is using their command line client (snx): it doesn’t rely on java or activex (yikes), it’s faster to install, it doesn’t nag you every other connection to update, you can open and close you browser without worries…

But if you’ve been updating your Ubuntu Linux to 14.04 or your Mint Linux to 17, you might have found this error:

~  snx
snx: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

This is because snx is compiled using gcc 3, instead of the very common version 4 right now, so you need to install libstdc++5. But that’s not enough, lets check its dependencies:

~  sudo ldd /usr/bin/snx
    linux-gate.so.1 =>  (0xf774d000)
    libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf75f3000)
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf75d7000)
    libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xf75be000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf75b9000)
    libpam.so.0 => /lib/i386-linux-gnu/libpam.so.0 (0xf75aa000)
    libnsl.so.1 => /lib/i386-linux-gnu/libnsl.so.1 (0xf7591000)
    libstdc++.so.5 => not found
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf73e1000)
    libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf73bf000)
    /lib/ld-linux.so.2 (0xf774e000)
    libaudit.so.1 => /lib/i386-linux-gnu/libaudit.so.1 (0xf739a000)
    libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf7396000)
    libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf738f000)

As you can see, all the dependencies are 32 bit (i386), so, you need to install the specific 32 bit version of that library, this way:

~ apt-get install libstdc++5:i386

Then, said message should go away and let you connect. In case you are missing any other library, remember installing the 32 bit version appending the ‘:i386’ part to the name of the package.

Good luck!

Did you ever end up with a bunch of PEM files from your SSL certificates? Don’t you know which one corresponds to which domain, or where do they expire?

Decode them as simple as this command:

openssl x509 -in certificate.crt.pem -text -noout

Do you wanna verify the configuration for your certificate in your IMAP server? It’s as easy as this:

openssl s_client -connect imap.csic.es:143 -starttls imap -CApath /etc/ssl/certs

Substitute ‘imap.csic.es’ with your server hostname or IP address.

The route for your root certificates (/etc/ssl/certs), which is necessary for verifying them, might vary depending on your linux distro. That route should be fine for debian and ubuntu based distros.

Do you wanna verify the configuration for your certificate in your SMTP server? It’s as easy as this:

openssl s_client -connect smtpin.csic.es:25 -starttls smtp -CApath /etc/ssl/certs

Substitute ‘smtpin.csic.es’ with your server.

The route for your root certificates (/etc/ssl/certs), which is necessary for verifying them, might vary depending on your linux distro. That route should be fine for debian and ubuntu based distros.