Installing MATLAB 2015b on Debian Jessie

Ran into a couple of problems here:

Default Debian behaviour is to mount cd’s with noexec option. Thus you get permission denied even as root when you try to run the install script. Solution; remount cd:

sudo mount -o remount,exec,ro /media/cdrom0

or whatever path the cd is mounted at. You need the ro otherwise it complains.

Other more general problem: sudo ./install just results in Installing... Finished and a silent fail. In the old days using gksudo fixed this but apparently it’s deprecated now. It does work when running as normal user, so tried:

sudo -E ./install

this worked correctly.

Using custom Diffie-Hellman parameters with Apache 2.2.22 and OpenSSL 1.0.1e (Debian 7 Wheezy)

See https://weakdh.org for the problem – 1024 bit Diffie-Hellman keys are potentially breakable (the ‘logjam’ vulnerability). This can be fixed in Apache 2.4 by pointing it at a custom key, but up to recently ver 2.2 was vulnerable. The issue was fixed in apache 2.2.22-13+deb7u5, which allows a custom DH key to be appended to the server certificate. To use this in Debian 7:

Update to apache 2.2.22-13+deb7u5 or higher.

Generate a new Diffie-Hellman group using

openssl dhparam -out dhparams.pem 2048

Find where the appropriate server certificate file is – standard debian setup specifies this in

/etc/apache2/sites-available/default-ssl

Append the DH group to the server certificate

cat dhparams.pem >> server_certificate.pem

The resulting file should look like

-----BEGIN CERTIFICATE-----
stuff
-----END CERTIFICATE-----
-----BEGIN DH PARAMETERS-----
more stuff
-----END DH PARAMETERS-----

Restart Apache.

Checking this using the https://www.ssllabs.com/ssltest/ shows DH 2048 bits

Proxmox clustering and multicast (also, DNS)

After much problems with getting a new Proxmox cluster up and running two things have helped:

Putting the SAN IP addresses in the hosts file, avoiding DNS dependancies (especially when one of the systems isn’t in there yet…). This put me on track: http://blog.rhavenindustrys.com/2013/04/curious-proxmox-clustering-fix.html

Important bit:

127.0.0.1 localhost.localdomain localhost
169.254.0.1 proxmox1.local proxmox1 pvelocalhost
169.254.0.2 proxmox2.local proxmox2

10.10.5.101 proxmox1.example.com
10.10.5.102 proxmox2.example.com

This associates the short aliases with the network used by corosync, while leaving the long addresses to the outside world.

Then tried tests detailed at: https://pve.proxmox.com/wiki/Troubleshooting_multicast,_quorum_and_cluster_issues

The multicast test failed – i.e. running

omping -c 10000 -i 0.001 -F -q <list of all nodes>

on both nodes at the same time resulted in 100% loss. Fixed this by disabling IGMP snooping on the SAN VLAN. ExtremeOS command is:

disable igmp snooping <vlanname>

Hey presto, after getting the second node to join properly:

pvecm add 192.168.xxx.xxx -force

it gets quorum immediately. I suspect this issue was causing a lot of the historical issues with getting quorum to work on this switch.

Configuring Proxmox hosts (and other postfix installs) to send email via smarthost V2

In this post suggested using the Satellite system option. However, this seems to do the same as the mail sent by smarthost; no local mail option in exim – i.e. even local mail to root tries to go via the smarthost, which then complains. The Internet with smarthost option is probably the better choice (equivalent to exim’s mail sent by smarthost; received via SMTP or fetchmail).

N.B. Normal proxmox setup seems to be for postfix to use /etc/aliases directly. Double check this file!

RAID Monitoring: PERC H710 Mini and Debian

Debian 7 works with the PERC H710 Mini in a Dell R520 out of the box. To monitor this however you need a binary from LSI. Helpfully, this comes in a packaged form from http://hwraid.le-vert.net/wiki/DebianPackages

http://blog.mattandanne.org/2012/01/hardware-raid-controllersrequire.html pointed me in the right direction. To install, add the repo in a .list file:

deb http://hwraid.le-vert.net/debian wheezy main

and then add the key:

wget -O - http://hwraid.le-vert.net/debian/hwraid.le-vert.net.gpg.key | apt-key add -

Update the repository lists, and then install the relevant package:

apt-get install megaclisas-status

Running megaclisas-status should then give the status of the array(s). The script is set up by default to email root every two hours if there is a problem. These defaults can be overridden using a defaults file:

/etc/default/megaclisas-statusd

You need to create this if necessary. The defaults are:

MAILTO=root # Where to report problems
PERIOD=600 # Seconds between each check (default 10 minutes)
REMIND=7200 # Seconds between each reminder (default 2 hours)
RUN_DAEMON=yes

(can be found in)

/etc/init.d/megaclisas-statusd

If you have the system set up to divert root email to you then it should just work.

A nice way of configuring linux system-wide login notifications using PAM

There are several ways to have a linux box email you when someone logs in to it. Most of these use a script in either the local profile files (for individual users) or the system-wide profile (and/or in sshrc). Another nice way is to use the pam authentication system to do the job. A setup is given at:

http://blog.stalkr.net/2010/11/login-notifications-pamexec-scripting.html

Brief setup

Assuming Debian here.

Make sure the system is set up to talk to an email server and has some way of sending emails from the command line. The script here assumes the mailx package is installed.

Quick test:

echo "test" | mail -s "test" user@example.com

Create a script somewhere sensible (e.g. /usr/local/bin) and make it executable.

#!/bin/sh
[ "$PAM_TYPE" = "open_session" ] || exit 0
{
echo "User: $PAM_USER"
echo "Ruser: $PAM_RUSER"
echo "Rhost: $PAM_RHOST"
echo "Service: $PAM_SERVICE"
echo "TTY: $PAM_TTY"
echo "Date: `date`"
echo "Server: `uname -a`"
} | mail -s "`hostname -s` $PAM_SERVICE login: $PAM_USER" user@example.com

replacing user@example.com with the required email address. Note that you could send the email to root or another local account if you have that aliased to an external address.

edit /etc/pam.d/common-session to add at the end:

session optional pam_exec.so /usr/local/bin/login_notify

and test it by logging in with an ssh session (terminal or winscp etc.)

Sudo uses common-session-noninteractive – not sure whether it would be best to put this in /etc/pam.d/sudo as well…

Wireless problems with Ubuntu 13.10 and self-signed certificates

Ubuntu 13.10 (and possibly 13.04) seem to have a problem with self-signed certificates when authenticating to wireless radius servers (i.e. the GUPHYSICS wifi). This is discussed in a variety of places:

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1104476

The problem seems to be that the Network Manager setup is adding the line:

system-ca-certs=true

to

/etc/NetworkManager/system-connections/GUPHYSICS

even if you tick ignore when the system asks about certs the first time. Changing the value of the setting to false seems to fix this, although there is a possibility that it might get changed back by NM. (or delete the setting entirely, which seems to have happened on this laptop. Hmmm)

There is apparently a bugfix in place and rolled out to other distributions, but Ubuntu doesn’t have it yet…

Another way to fix this would be to get the certificate (probably in .pem format) and point the settings to it.

updatedb.mlocate hangs on stale NFS mounts (Proxmox)

After properly configuring postfix on the Proxmox hosts to send email, emails to root were noticed daily:

/etc/cron.daily/mlocate:
 /usr/bin/updatedb.mlocate: `/var/lib/mlocate/mlocate.db' is locked (probably by an earlier updatedb)
 run-parts: /etc/cron.daily/mlocate exited with return code 1

After logging on to one of the boxes, killing (-9) the updatedb process and running it with verbose on:

updatedb.mlocate -v

The output indicated it was hanging on one of the ”/mnt” directories. Looking at the output of ”mount” a couple of old nfs shares were noticed, that should have been deleted (and didn’t appear in the GUI). Unmounting these shares made updatedb run happily.

If the unmount complains the device is busy, check the updatedb.mlocate process has been killed.