Remaster Knoppix without Remastering
Here's an example of a tweaked knoppix.sh file that I made to turn Knoppix into an instant Webcam server. I first created a webcam directory on the CD-ROM and put a basic HTML file there that pointed to an image at /var/www/webcam.jpg. Then, I created a knoppix.sh script and put it in the KNOPPIX/ directory on the CD. Here is the script:
#!/bin/sh echo Configuring Apache cp /cdrom/webcam/index.html /var/www/index.html /etc/init.d/apache start echo Configuring Cron echo '* * * * * root gqcam -d /var/www/webcam.jpg > /dev/null' >> /etc/crontab /etc/init.d/cron start
As you can see, there isn't much to this script. I copy the HTML file to the default Apache document root, start Apache, and then add a job to the global crontab and start cron. The cron command will run gqcam every minute, which will capture an image and store it in /var/www/webcam.jpg. Now, I can just burn the CD and boot it on any machine with a Webcam and Knoppix will take care of the rest.
In addition to the saveconfig script, Knoppix provides an even more advanced script that creates a persistent disk. The main problem with a live CD is that all of your changes are erased whenever you reboot. Traditionally, the persistence script created a loopback filesystem on a USB key or hard drive of a specified size and then copied your entire home directory to it. On the next boot, if you selected it with a cheat code, Knoppix would then mount the filesystem and point your entire home directory to it. That meant any changes you made to your home directory were kept through all of your reboots.
The main limitation to that script (as with legacy Knoppix discs) was that you could write only to certain directories. Beginning with Knoppix 3.8, Knoppix added UnionFS (now replaced with AuFS). This tool essentially allows you to merge filesystems on top of each other, even if one is read-only and the other is read-write. If you wrote to the filesystem, UnionFS/AuFS transparently took care of putting the writes on the correct filesystem. With Knoppix, this now meant the ramdisk that was traditionally used for /home and /etc could now be merged on top of the entire filesystem. You now could essentially write anywhere you wanted, install programs using the standard Debian package management, and basically treat the system like any other installed Linux distribution, limited only by your ramdisk size.
With the addition of AuFS, Knoppix changed its persistence script. Now when you click K→Knoppix→Configuration→Create a persistent Knoppix disk image, Knoppix creates a complete copy of the entire ramdisk. This is a copy of all of the changes you have made to the system since you have booted. Within the script, you can choose the maximum size of the filesystem, where to store the image, and even whether to use encryption. The next time you boot, if the USB or local hard drive is present, Knoppix automatically detects it and prompts you with a few options:
Home: use only your persistent home directory.
System: replace the entire /ramdisk mountpoint with the persistent disk image.
Overwrite: off by default, but it will replace the /etc directory on your persistent image if you also enable the System option. You might want to do this if your system-wide graphics or network settings from a previous machine interfere with your current one.
Init: start any persistent init scripts.
If you don't select any of these options, Knoppix will boot normally. It's also possible that you might have multiple knoppix.img files on different drives (or multiple files on the same drive in different directories). This actually is a good way to create custom Knoppix settings that are stored in different directories on a USB key. Say I have a security-focused persistent image in the security directory on my USB key (which Knoppix detects as /dev/sda1), I could then boot Knoppix with the home=/dev/sda1/security/knoppix.img cheat code.
The saveconfig and knoppix.sh tweaks provide a lot of functionality, but their main downside is that they execute at the end of the boot process. Sometimes you want to change Knoppix settings sooner than that—whether it's the default screen you see at boot time or Knoppix's default cheat codes. These options and more are stored in the boot/isolinux/ directory on the disc and can be changed without much effort. Below I cover some of the more important files and what you can change with them.
Boot messages: the boot.msg, f2 and f3 files are text files that define what shows up at the boot prompt, when you press F2 and F3, respectively. If you want to add special help or even change the text completely, you can do so in these files.
isolinux.cfg: this is one of the most useful files in this directory, as it defines all the different kernels that can be loaded, along with their default boot options. For instance, here is the section of the file that defines the default Knoppix settings and cheat codes if you let the boot prompt time out or just press Enter:
LABEL knoppix KERNEL linux APPEND ramdisk_size=100000 init=/etc/init lang=us apm=power-off vga=791 initrd=m inirt.gz nomce loglevel=0 quiet BOOT_IMAGE=knoppix
For instance, you can see here that the default language is English, but if you wanted to change it to Spanish, you would change lang=us to lang=es. If you scroll down farther in the file, you can not only see other Knoppix types you can boot, but also listings for memtest and dos.
Kyle Rankin is a director of engineering operations in the San Francisco Bay Area, the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- KDE Reveals Plasma Mobile
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python