Entries by Ulrich Dangel

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

Update on 2011-12-20 by Grml team: while iscsitarget isn't available any longer on Grml the new iSCSI implementation of the Linux kernel 3.1 is available and open-iscsi, targetcli and tgt are shipped with Grml. We don't have any finished documentation for that yet, but if you know how to use targetcli (or optionally open-iscsi and tgt) you should have everything you need to provide a iscsi target with Grml 2011.12.

The upcoming Grml Release 2011.12 (check the changelog for our new Grml 2011.12-rc1) will not have any iSCSI support integrated due to build issues with dkms. Instead Grml 2011.12 will provide all the necessary tools to provide and access a ATA over Ethernet Device.

ATA over Ethernet, also known as AoE, is a protocol designed to access Block devices via Ethernet. Compared to iSCSI it does not work with IP but with Ethernet. Unfortunately this means that AoE is error-prone against Ethernet attacks like ARP spoofing. Do not use it in hostile enviornments. That being said AoE is quite simple to use.

Export a blockdevice

On the server side use vblade to export a block device:

vblade -m 11:22:33:44:55:66 160 2 eth0 /dev/sdb1

This will allow the host with the MAC 11:22:33:44:55:66 to access /dev/sdb1 via eth0, using the shelf and slot numbers 160 and 2. These numbers are arbitrary but should be unique within the network.

Access a blockdevice

On the client load the module "aoe", or do

aoe-discover

You should find the device shared above as /dev/etherd/e160.2

I would like to thank to Christoph Biedl for providing this short and comprehensive documentation

Several Grml team members will be present at Linuxdays in Graz on Saturday, April 9th 2011. If you ever had any questions - this is the time to contact us in real life! :-)

Grml developer Christian Hofstaedtler will give a talk about Bare-metal deployment with Grml, as deployment is nowadays still an issue even in virtualized environments. Michael Prokop, project leader and founder of Grml, will give a talk about Opensource project management with some insights and hands on-stories about Open-source development and how to make a good Open-source project. Gerfried Fuchs, also a Grml developer, will talk about the Resources of Debian and provides an overview about several services for users of Debian as well as for users of other Distributions. Grml developer Ulrich Dangel will talk about DevOps, the DevOps movement, tools for DevOps and how Developer and Admins fit together .

Make sure to visit us, grab special Grml USB pens and Grml cups, and share your experience with Grml. We would really like to get in contact with you.

If you ever wanted to to get in contact with team members and users of Grml, learn something about console tools, simply meet interesting people or just listen to informative talks visit us and the other projects at Linuxdays in Graz and have a good time.

Ever wanted to install Debian with an encrypted home directory but you didn't get along with the Debian installer? Grml to the rescue! Oliver Herold of F!XMBR wrote a nice article (in German) about using Grml to install Debian.