christiansaga.de

Having build my own NAS system recently, I realised I do not have any monitors or keyboards at home anymore. Hence installing Debian will be hard. I looked around and the solution would be a headless install via ssh.

This post is based on some work from S.G. Vulcan’s post Installing Debian using only SSH His post was a good start, but I only could make it work for a Debian Jessie netinstall image after some changes.

So what is the solution

Download the latest netinstall image from Debian, I used debian-8.3.0-amd64-netinst.iso

Mount the ISO to a folder

mkdir isoorig
sudo mount -o loop -t iso9660 debian-8.3.0-amd64-netinst.iso isoorig

Copy to new folder called isonew

mkdir isonew
rsync -a -H --exclude=TRANS.TBL isoorig/ isonew/

Change the menu to load SSH on boot by default, edit isonew/isolinux/txt.cfg remove (if existing) menu default from label install and add:

label netinstall
  menu label ^Install Over SSH
  menu default
  kernel /install.amd/vmlinuz
  append auto=true vga=788 file=/cdrom/preseed.cfg initrd=/install.arm/initrd.gz locale=en_US console-keymaps-at/keymap=us

default netinstall

Create isonew/preseed.cfg file. I adapted the locale and keyboard settings for Germany and added the selection of the keyboard-configuration. This would otherwise be an open question during the install and we won’t reach the SSH startup.

Also I added a check for non-free firmware, which popped up on one of my machines which had wireless.

#### Contents of the preconfiguration file
### Localization
# Locale sets language and country.
d-i debian-installer/locale select de_DE
# Keyboard selection.
d-i console-keymaps-at/keymap select de
d-i keyboard-configuration/xkb-keymap select de
### Network configuration
# netcfg will choose an interface that has link if possible. This makes it
# skip displaying a list if there is more than one interface.
d-i netcfg/choose_interface select auto
# Any hostname and domain names assigned from dhcp take precedence over
# values set here. However, setting the values still prevents the questions
# from being shown, even if values come from dhcp.
d-i netcfg/get_hostname string newdebian
d-i netcfg/get_domain string local
# If non-free firmware is needed for the network or other hardware, you can
# configure the installer to always try to load it, without prompting. Or
# change to false to disable asking.
d-i hw-detect/load_firmware boolean true
# The wacky dhcp hostname that some ISPs use as a password of sorts.
#d-i netcfg/dhcp_hostname string radish
d-i preseed/early_command string anna-install network-console
# Setup ssh password
d-i network-console/password password install
d-i network-console/password-again password install

Recreate the isonew/md5sum.txt, it is read only, so you need to change this. Also I had better luck with creating the md5sum.txt with the changed commands below.

chmod 666 md5sum.txt
find -follow -type f -exec md5sum {} \; > md5sum.txt
chmod 444 md5sum.txt

Create ISO file to burn with xorriso. If you do not have it installed use apt-get install xorriso.

xorriso -as mkisofs -D -r -J -joliet-long -l -V "Debian headless" -b isolinux/isolinux.bin -c isolinux/boot.cat -iso-level 3 -no-emul-boot -partition_offset 16 -boot-load-size 4 -boot-info-table -isohybrid-mbr /usr/lib/syslinux/isohdpfx.bin -o ../debian-8.3.0-amd64-netinst-headless.iso ../isonew

xorriso is creating a correct partition table, which is for some reason not done with mkisofs only. The original command would work in VMs, maybe even on a cd-rom, however not for USB sticks.

The ISO can be burned to an USB stick and used to boot. It will automatically configure the network with DHCP (yes, you need to have a way to find the IP, e.g. on your router) and start SSH. The user for the ssh connection is installer the password is install.

After the upgrade of Wheezy to Jessie, Spamassassin is not added to the startup services. Hence if you were using it before in your mail setup, you will run into the following error in /var/log/syslog

spamc: connect to spamd on ::1 failed, retrying (#1 of 3): Connection refused
spamc: connect to spamd on 127.0.0.1 failed, retrying (#1 of 3): Connection refused

Debian has a similar bug filed (#764438), even after a fresh reinstall.

So what is the solution

Simply activate Spamassassin via systemctl enable spamassassin

If you have a firewall, you probably have 99% of the entires in your syslog filled with iptables denied info. So there are two options to get rid of that. Turn of the logging of iptables or move it out of the syslog.

As I want to have the logging, I need to move it. You will find a lot of explanations on RSyslog in the official documentation, however I found that the simple case I was looking for was not described.

I am using the following to create the syslog entries:

iptables -I INPUT 5 -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

So what is the solution

You might have more logging or similar ones in your configuration. The important part here is the --log-prefix as we will sort via this.

To create a filter, create /etc/rsyslog.d/iptables.conf and add the following

# Proper file permissions
$FileCreateMode 0600
# Ruleset for sorting
if $msg contains 'iptables denied: ' then {
    # new destination
    /var/log/iptables.log
    # stop processing message, otherwise it will carbon to syslog
    stop
}

After restarting rsyslogd, this will now divert the iptables entries to the new logging location identified by the prefix.

The stop is particularly important, as the rule above diverts the logging, but without the stop it would still end up in syslog. If you google setups like this you will often find a ~ instead of the stop. Which is deprecated and cause a warning in the log, however works as well.

Sidenote: Remember to put the stop in brackets for the if/then clause, otherwise you stop all logging to syslog.

As a last step you should create a logrotation for the new log. I did it very simple by creating the file /etc/logrotate.d/iptables and added

/var/log/iptables.log {
  rotate 5
  monthly
  compress
  missingok
  notifempty
}

Logrotate is started via cron and will read the new config in the next run. Alternatively you can run the config directly via logrotate -f /etc/logrotate.d/iptables

I am using duplicity with duply to do PGP encrypted backups to Amazon S3. As there are enough guides around for the basic setup (i used Backup unter Linux mit duply), I won’t go into details of that.

However if you are planning to use the new EU (Frankfurt) location called eu-central-1 you will run into problems as this location only supports the V4 authentication. You might encounter the following error when using duply (even if the config worked on other locations before)

The authorization mechanism you have provided is not supported. Please use AWS4-HMAC-SHA256

So what is the solution

This is a bit tricky, as the Debian packages are not up to date and you need to mix backports and unstable versions. To solve this you will need to upgrade your duplicity and boto framework packages as following:

• duplicity needs version 0.7.02-1 This version is available within the backport branch of Debian. I used package pinning to get this package. You can easily find articles for this via Google, I found APT Pinning helpful. Be careful to understand pinning, as you might confuse APT with a wrong configuration. You should always use sudo apt-cache policy [packagename] and the -s parameter on upgrades first to check what will happen. Currently I am using duplicity 0.7.06-1~bpo8+1.

• python-boto needs version 2.36.0 Previously this was only available via PyPi, however a newer version is now available in the unstable branch. Hence again you can install this via pinning. Currently I am using python-boto 2.40.0-1

• duply did not need additional changes, I am using version 1.9.1-1 out of the regular stable branch.

SQLGrey itself will not be updated during the upgrade towards Jessie, however the change to Systemd will result in a stub automatically created by Systemd around the original init. The problem I encountered was, that SQLGrey would start before my database (MySQL). Hence you receive something like the following in /var/log/syslog

sqlgrey: dbaccess: can't connect to DB: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock’

The problem here is, that the generated stub is not obeying the init scripts dependencies and not having any Systemd ones, hence the services are starting in a “wild” order.

So what is the solution

We need to create at least the SQLGrey unit file and add the dependency into it. Create /etc/systemd/system/sqlgrey.service and add:

[Unit]
Description=SQLgrey Postfix Grey-listing Policy service
After=syslog.target network.target mysql.service
[Service]
Type=forking
PIDFile=/var/run/sqlgrey.pid
ExecStart=/usr/sbin/sqlgrey -d
[Install]
WantedBy=multi-user.target

Note the mysql.service in the After line. This is the needed dependency.

As you might have noticed, there is no mysql.service unit file existing, as the package maintainers have deprioritized to create one (there are two bugs #765425 and #742900.

However you can reference the stubs as well. If you need to adapt this for other services: To find the name of the stub you can use systemd-analyze blame. It gives you a list of the services started. Details you can get with systemctl, e.g. systemctl status mysql.service. The details will tell you in the Loaded line if it is a real unit file or just a init script stub.