general - 2

In this article we will show you how you can leverage grml-autoconfig to create a Grml ISO which will automatically start an ssh server and use your own ssh keys instead of the traditional password based login. This allows Grml to be used not only for interactive rescue operations but also for remote or automated setups.

Starting with Grml 2009.05 we streamlined the support of hooking into our boot-process in grml-autoconfig thanks to the patches from Marc 'Zugschlus' Haber. Now it is possible to execute arbitrary scripts, unpack archives or install packages at startup not only directly from the Live CD but also from partitions. This allows you to create customized Grml Images with ease without the need to modify the squashfs image (usually known as remastering). In this example we will add the necessary files directly onto the ISO image but you can also use a USB stick instead. Please make sure you read the grml-autoconfig manpage

The first step is to create a directory which will contain all the additional files to be copied onto the ISO image. In this example we use /tmp/grml_overlay/

mkdir /tmp/grml_overlay

The next step is to create an archive containing the ssh keys. For this step you need either fakeroot or run the commands as root.

TMPDIR="/tmp/grml_config"
cd "$TMPDIR" || mkdir "$TMPDIR" && cd "$TMPDIR"
fakeroot 
mkdir --parent root/.ssh home/grml/.ssh
chmod 0700 root/.ssh home/grml/.ssh
cp /home/uli/.ssh/id_rsa.pub  root/.ssh/authorized_keys
cp /home/uli/.ssh/id_rsa.pub  home/grml/.ssh/authorized_keys
chown -R 1000:1000 home/grml
tar --numeric-owner -j -c -f /tmp/grml_overlay/config.tbz .

This will create an archive named /tmp/grml_overlay/config.tbz containing all the files we created in our directory. Please make sure to replace the cp command with your own ssh keys. As we used fakeroot in this example you can manipulate file permissions without the need to run these commands as root.

Now we have everything what's needed prepared and can just run grml2iso and specify the additional boot parameters as well as the overlay directory.

grml2iso -b "config ssh" -c /tmp/grml_overlay -o my-grml.iso ./grml64_2011.12.iso

This will create a modified Grml ISO named my_grml.iso and add the bootparameters config ssh to all the existing boot-entries and copy all files from the /tmp/grml_overlay directory onto your modified ISO image. With the config parameter grml-autoconfig will automatically unpack config.tbz at bootup which contains our ssh keys. The ssh parameter will automatically start the ssh server and set a random password for the grml user. But as we deployed our ssh keys we don't care about the password anyway. For a list of all boot parameters have a look at the Grml cheatcodes.
During startup of Grml you will notice some additional log messages indicating the unpacking of your created archive. This shows that everything works like intended.

Combining different boot parameters in Grml like config and ssh allows you to create customized and tailored distributions for your own needs without having to dig into the remastering process. With the availability of tools like grml2usb and grml2iso you can easily create customized tools based on Grml without the need to develop everything from scratch. We showed how you can leverage grml2iso to create a Rescue CD based on Grml with ssh keys for remote login.

The upcoming Grml 2011.12 will have some changes in the accessibility features shipped with Grml. Until Grml 2011.12 it was possible to start brltty automatically via the bootoption brltty. The problem with this approach was that it was never clear when you had to enter the bootoptions as there was no sound to indicate boot menu. We also do not have the necessary hardware to test the releases with brltty. With that in mind and the integration of speakup in the kernel we decided to remove the additional accessibility boot-parameters for Grml 2011.12 as we never tested them anyway.

But we added some important changes to improve the accessibility. Starting with Grml 2011.12 the bootloader will either beep once (if you use the default syslinux one) or will play 3 beeps (grub) to indicate the boot menu. Afterwards you can easily change the boot parameters if you press TAB (syslinux) or e (Grub). After the bootup Grml will play some tunes to indicate the finished boot. As per default Grml starts a text based menu you will have to press enter after the beep to enter the commandline

We think with the additional sound indicators in the boot-menu as well as the default sound to indicate the finished boot-process, Grml 2011.12 will be more accessible then ever.

I would like to thank Richard Hartmann for creating the different sound indicators for the upcoming Release

In our last Blog entry about remastering Grml 2011.12 we described a method remastering Grml with grml-live, the tool used to generate the official Grml ISOs.

Often you don't need all the power and flexibility of grml-live but just want to add or change some default boot parameters and use this as your default image. For example you may want to have an ISO image which automatically starts sshd and sets the password to a specific value or downloads an executable and run it at startup. This can easily be done with grml2iso a tool based on grml2usb which allows you to create customized iso images.

Grml will automatically start sshd and set the password for the grml user if you specify the ssh boot-parameter. This allows you to remotely control your Grml CD. To create such a CD just run:

grml2iso -b "ssh=grml-password" -o my_grml.iso ./grml64_2011.12.iso

This will create a modified Grml ISO named my_grml.iso and add the bootparameter ssh=grml-password to all the existing boot-entries.

grml2usb does not offer the same flexibility as grml-live but grml2usb/grml2iso is often good enough to help you to achieve what you want without the need to modify the squashfs file.

In our latest blog entry about grml-debootstrap we described how to leverage grml-debootstrap for automated installations of Debian into virtualized systems. Unfortunately sometimes this is not enough and you need to run commands after the installation. This post will describe some customization methods of grml-debootstrap. For more information on this topic also look at the manpage of grml-debootstrap

One quite common task is to execute scripts after the installation like for example gathering the ssh host key or adding your own CA to the host. grml-debootstrap supports the execution of scripts after the machine is successfully installed.

To execute scripts after the installation we first need a directory containing all the scripts. This directory will be afterwards specified as a parameter to grml-debootstrap. In this example we are using ./scripts as the directory name.

mkdir ./scripts

After we create the directory we also need to create a script for our post-processing task. For this example we'll create a script which will examine the fingerprints of the ssh hosts keys. To be able to access and modify the image all the scripts executed by grml-debootstrap will have an environment variable specified called MNTPOINT which will point to the directory used for installing the system. Then we have to create a script inside the directory and make it executable:

$ cat >./scripts/89_print_sshkeys <<EOF
#!/bin/bash
set -e
if [ -z "\$MNTPOINT" ] ; then
  echo "Please run \$0 inside grml-debootstrap or export MNTPOINT" >&2
  exit 1
fi

for key in "\$MNTPOINT"/etc/ssh/ssh_host_*_key.pub ; do
  chroot "\$MNTPOINT" ssh-keygen -l -f \${key##\$MNTPOINT}
done
EOF
$ chmod +x ./scripts/89_print_sshkeys

This script will iterate over all ssh host keys and print the fingerprint of them.

After we created the directory and the script we can now point grml-debootstrap to the directory and it will run all executable files in it. If we extend the command-line from our last example we have to specify the --scripts parameter and point it to the created directory:

$ sudo grml-debootstrap --scripts ./scripts/ --password root-pw --vmsize 3G --vmfile --target ./qemu.img
....
Finished chroot installation, exiting.
 * Executing script ./scripts/89_print_sshkeys
1024 9e:d9:18:1d:47:ae:26:9f:53:5e:63:3c:bd:37:ea:2b /etc/ssh/ssh_host_dsa_key.pub (DSA)
2048 c1:5e:27:a3:2f:7d:30:a0:ab:75:a2:86:e7:bb:8a:e2 /etc/ssh/ssh_host_rsa_key.pub (RSA)
....

This shows how easy it is to customize and extend grml-debootstrap to your own needs. You can easily create customized scripts and run arbitrary commands on the target to do whatever you want. grml-debootstrap is of course available within Grml but also in Debian.

The upcoming Grml release 2011.12 as well as Debian/testing and unstable ship an updated grml-debootstrap version supporting the installation of Debian not only into directories or hardisks but also into virtual images.

grml-debootstrap is designed to help you install complete Debian Systems. Typically if you install a Debian system with debootstrap you have to install the kernel, bootloader, /etc/fstab, ssh server, … yourself. grml-debootstrap automates this boring tasks and allows you to install Debian systems from within a running system within minutes.

Nowadays physical installations get less and less important but virtual installation gain importance. New servers are often run inside virtual environments like Xen, KVM or VMware. grml-debootstrap supports the automated installation of Debian into a virtualized environment without the need to use a preseeded installation medium. You can create a raw image with grml-debootstrap which boots per default with KVM and Xen. To boot the image file with other virtualization solutions you may have to convert the generated image with qemu-img

To install a plain Debian System into a raw image you just have to run

grml-debootstrap --password root-pw --vmfile --vmsize 3G --target ./squeeze.img

This will set the root pasword to root-pw, install openssh and the latest kernel package, create /etc/fstab with the necessary entries and configure the bootloader for your virtualized system.

If you want to customize or extend grml-debootstrap have a look at the manpage or look at the scripts and package definitions in /etc/debootstrap