Tag: Debian

Connecting to NFS shares at boot using fstab in Debian 9 Stretch

Note – this fix in principle should work on most systemd distributions.

Problem – trying to get a Debian 9 system to mount an NFS share at boot. This was declared in /etc/fstab in the normal way, but kept failing on boot. However, once the system was up you could log in and do a mount -a, which would work fine. Reading around, it looks like a case of the system trying to mount before the network is up (and in this case the network should be reliable, as it’s an internal one between a VM and it’s host…)

Tried using the bg option first, which should mount in the background and come up eventually, but still got error on boot.

192.168.45.1:/export  /hostshare  nfs  bg,rw,soft  0   0

There is another option that in theory should help: _netdev. I haven’t tried this yet.

What does work is adding an option x-systemd.automount. This, unsurprisingly, tells systemd to try and mount the share on demand. So changing the line in fstab to read:

192.168.45.1:/export  /hostshare  nfs  rw,soft,x-systemd.automount  0   0

works. Booting the system gives no errors (on the console anyway). The share does not show as mounted until the local mountpoint is accessed, and then it works without complaint.

Footnotes

  1. The context for this is a VM running under VirtualBox. The VM is Debian 9, the host is Ubuntu 17.10. The VM has one network interface with the default NAT setup to talk to the outside world, and a second interface to talk to a host-only network. This allows you to SSH into the the guest from the host, and also allows this NFS setup. You can use the VirtualBox shared folder setup to transfer files, but I figured as both the host and guest were Linux NFS would be easier (and not require the Guest Extensions to be installed on the guest).
  2. Debian 9 wouldn’t successfully install on the laptop, but I needed it for an easy install of LALSuite (Debian is a reference system for this, Ubuntu isn’t and has dependency issues). Hence this rather complicated setup. Fortunately LALSuite is entirely command line based…
  3. Yes, Docker or similar would be more efficient. I’m not so familiar with it and it’s a bit of a pain to get it talking to the host filesystem. I’d argue that running a full VM is slightly more portable, although you’d need to change how the filesharing is set up on a Windows or Mac host.

ResourceSpace cron and database notes

Ran into a couple of issues today:

Note: system setup is Debian 9 with standard options (Apache 2.4, PHP 7.0, MariaDB 10.1)

Cron

The documentation implies you should run cron_copy_hitcount.php as a cron job. However, the new correct way seems to be to run batch/cron.php, which runs a bunch of sub-jobs. I’ve got this set up in cron.daily as:

#!/bin/sh
wget -q -r http://localhost/resourcespace/batch/cron.php

We’ll see if this works. Certainly running it directly by browsing to it seems to work.

LDAP

Trying to activate the simpleldap plugin threw up two problems:

php-ldap wasn’t installed – easy enough. Note apache needs a restart after installing…

Second error was a problem with the database – the plugin couldn’t create a table, with error

Specified key was too long; max key length is 767 bytes

This seems to be because when I created the database the character set used was utf8mb4_general_ci, which in the worst case uses 4 bytes per character. If you try to create a index key with 255 characters you run into this limit.

The solution was to change the database to use utf8_general_ci. This allowed the plugin to create the simpleldap_groupmap table with utf8_general_ci. The rest of the database is still utf8mb4_general_ci, but as it has been created already without an issue we should be ok.

Notes on getting Ubuntu 16.04 to work with NIS

Note – this only sets up the system to use user and group logons, not automounting home directories. I haven’t figured out how to make this work in Ubuntu 16.

Install package nis

Probably a good idea to set network address statically in /etc/network/interfaces (NetworkManager should recognise this and then leave it alone)

Probably also a good idea to check that /etc/hosts has the domain name for the system, i.e.

127.0.1.1 domain.name.machinename machinename

Add yp server to /etc/yp.conf

Edit /etc/nsswitch.conf to add nis for passwd, group and shadow. Note that compat should include nis by default.

Add a dependency to make the rpcbind service start at boot

systemctl add-wants multi-user.target rpcbind.service

(See this Debian bug report or this Ubuntu one)

Note that this is not a complete fix – it is reported that if the network does not come up fast enough things still break.

For users that need to log on to the system, create home directories

mkhomedir_helper <username>

Remember to reboot to check everything is working:

yptest

if that fails check if the bind services are running

systemctl status rpcbind
systemctl status ypbind

Installing Jekyll on Debian 8 (Jessie)

Install ruby-full:

sudo apt-get install ruby-full

Install ruby-ffi

apt-get install ruby-ffi

Install Jekyll

gem install --http-proxy http://wwwcache.gla.ac.uk:8080 jekyll

install node.js

apt-get install nodejs

Should then work for normal user.

Quick test – (from https://www.digitalocean.com/community/tutorials/how-to-deploy-jekyll-blogs-with-git)

jekyll new awesomeblog

This will create an awesomeblog directory containing the configuration files, posts directory and other required bits.

cd awesomeblog
jekyll serve

Jekyll will build your blog, and after a few seconds you should be able to visit http://host:4000 in your browser. Or skip the serve bit and check in the _site subdirectory.

To get git working with this create the git repository, go into the hooks subdirectory and create a post-receive script like this (again from https://www.digitalocean.com/community/tutorials/how-to-deploy-jekyll-blogs-with-git)

#!/bin/bash -l
GIT_REPO=$HOME/repos/awesomeblog.git
TMP_GIT_CLONE=$HOME/tmp/git/awesomeblog
PUBLIC_WWW=/var/www/awesomeblog

git clone $GIT_REPO $TMP_GIT_CLONE
jekyll build --source $TMP_GIT_CLONE --destination $PUBLIC_WWW
rm -Rf $TMP_GIT_CLONE
exit

or /var/www/html/awesomeblog for apache on Debian 8.

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

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.

Debian 6 (squeeze) to 7 (wheezy) upgrade notes

Networking (firewall related)

Some of the older debian servers are firewalled using a command in the ”/etc/network/interfaces” file to load the iptables rules. For some reason this breaks the file on upgrade to Debian wheezy and the network interfaces don’t come up on boot. To fix, comment or remove the line:

pre-up iptables-restore < /etc/iptables.conf

and use the iptables-persistent package instead.

Also gives an error on

INPUT -i ! lo

Need to change to

INPUT ! -i lo

(To be fair, this has been deprecated for a while now)

Suhosin

php5-suhosin has been removed from wheezy. The upgrade sort of removes it, but it hangs around as a remove candidate package. Following http://pc-freak.net/blog/how-to-get-rid-of-php-warning-php-startup-unable-to-load-dynamic-library-usrlibphp520090626suhosin-so-on-debian-gnu-linux/ we check the package status with

dpkg -l | grep -i suhosin

and remove with

dpkg --purge php5-suhosin

This seems to fix the problem (don’t get emailed every so often by cron about it missing)

For next upgrade should remove it first.

Kernel

Make sure the generic kernel package is installed – have tended to choose the specific one in the past for no good reason.

apt-get install linux-image-amd64

This should ensure the 3.2 kernel is installed as part of the upgrade.