Encrypt Your Root Filesystem
This key will be copied to the Flash disk later.
4) Create a dm-crypt device, encrypted using the key you just generated:
# cryptsetup -d /etc/root-key create root /dev/hda4
Accessing /dev/mapper/root now provides an encrypted layer on top of /dev/hda4. By default, cryptsetup creates an AES-encrypted dm-crypt device and assumes a keyspace of 256 bits.
5) Create an ext3 filesystem on /dev/mapper/root:
# mkfs.ext3 /dev/mapper/root
6) Mount the new filesystem:
# mkdir /mnt/encroot # mount /dev/mapper/root /mnt/encroot
7) Now that you have an encrypted filesystem, you must populate it with the contents of /dev/hda5 (the original root filesystem):
# cp -ax / /mnt/encroot
8) Finally, create an entry in /mnt/encroot/etc/crypttab so that various utilities know how the filesystem was configured:
root /dev/hda4 /etc/root-key cipher=aes
Now that we have our encrypted filesystem ready, it is necessary to understand a little more about the target architecture's boot process. Generally, computers have firmware that hands off execution to the software that will complete the system boot. Protecting firmware is beyond the scope of this article, so we assume that the system's firmware can be trusted. Most readers probably are familiar with the BIOS, the boot firmware used by the PC platform. I focus on Open Firmware, a boot system used by computer manufacturers such as Apple, Sun and IBM.
The installation instructions for NetBSD/macppc provide a good introduction to Open Firmware. We are interested in using Open Firmware's command-line interface to configure the computer to boot from a removable Flash disk. Open Firmware allows you to view the devices connected to a computer and view and set the value of firmware variables.
The Open Firmware prompt can be accessed by holding down option-command-o-f on a New World (G3 and later) Apple computer during the initial boot process.
The variable boot-device is used to determine what device the system should use to boot. The printenv command allows one to inspect its current value:
> printenv [...] boot-device hd:,\\:txbi hd:,\\:txbi
This essentially means “boot by executing the file of HFS type txbi on the first IDE disk.” The second : character (before txbi) causes the token to be interpreted as an HFS file type. Otherwise, txbi would be interpreted as the path to a file. In my case, the token hd is actually an alias to the more complicated /pci@f4000000/ata-6@d/disk@0. This string represents the path through various subsystems to the first IDE disk. You can see what device an alias resolves to using Open Firmware's devalias command.
To set the boot-device correctly we need to discover by what name Open Firmware knows our Flash disk. Examining the device tree printed by the ls command reveals the path to the Flash disk:
> dev / ls [...] /pci@f2000000 [...] /usb@1b,1 [...] /disk@1 [...]
Now that we know a little bit about the firmware's view of the computer, we must spend some time investigating the software the firmware initially executes: the bootloader. Generally, Linux systems that run on Apple's PowerPC architecture employ a program called yaboot to boot the system. yaboot is similar to LILO or GRUB and contains two key programs, ofboot.b and yaboot. ofboot.b provides the first stage of the bootstrap process. Essentially, it is ofboot.b's job to determine what operating system to boot. For example, if a system has both Mac OS X and Linux installed, ofboot.b executes Mac OS X or Linux's bootloader. If the user chooses to load Linux, ofboot.b executes yaboot, the second stage of the bootstrap process. yaboot then loads the Linux kernel and, in our case, an initrd. Figure 3 provides a illustration of how Linux boots using an encrypted root filesystem on the PowerPC architecture.
Our removable boot device requires the ofboot.b and yaboot programs, a Linux kernel and an initrd that contains the encryption key. Apple's current PowerPC-based architecture expects its boot media formatted using HFS.
1) Use the parted program to create the proper bootable partition on the Flash disk (mine is 64MB and is accessed using the device node /dev/sda):
# parted /dev/sda (parted) mklabel mac (parted) print Disk geometry for /dev/sda: 0.000-62.500 megabytes Disk label type: mac Minor Start End Filesystem Name Flags 1 0.000 0.031 Apple (parted) mkpart primary hfs 0.031 62.500 (parted) print Disk geometry for /dev/sda: 0.000-62.500 megabytes Disk label type: mac Minor Start End Filesystem Name Flags 1 0.000 0.031 Apple 2 0.031 62.500 untitled (parted) set 2 boot on (parted) name 2 Apple_Boot (parted) quit
2) Create an HFS on the boot partition:
# hformat /dev/sda2
3) Configure yaboot to boot off the appropriate device by modifying /mnt/encroot/etc/yaboot.conf. The following is a minimum configuration:
boot=/dev/sda2 ofboot=/pci@f2000000/usb@1b,1/disk@1:2 partition=2 install=/usr/lib/yaboot/yaboot magicboot=/usr/lib/yaboot/ofboot default=linux image=/vmlinux label=linux root=/dev/hda4 initrd=/initrd.gz read-only
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space