From: Planet-Lab Support Date: Wed, 30 Nov 2005 19:00:44 +0000 (+0000) Subject: This commit was manufactured by cvs2svn to create tag 'BOOTCD_V_3_1'. X-Git-Tag: BOOTCD_V_3_1^0 X-Git-Url: http://git.onelab.eu/?a=commitdiff_plain;h=4833c7351dc53a721d958946b6a2b6e9503fafe2;p=bootcd.git This commit was manufactured by cvs2svn to create tag 'BOOTCD_V_3_1'. --- diff --git a/bootcd.spec b/bootcd.spec deleted file mode 100644 index 45c4f84..0000000 --- a/bootcd.spec +++ /dev/null @@ -1,77 +0,0 @@ -%define name bootcd -%define version 3.2 -%define release 1.planetlab%{?date:.%{date}} -# XXX Get this from /etc/planetlab -%define configuration default - -Vendor: PlanetLab -Packager: PlanetLab Central -Distribution: PlanetLab 3.2 -URL: http://cvs.planet-lab.org/cvs/bootcd_v3 - -Summary: The PlanetLab Boot CD -Name: bootcd -Version: %{version} -Release: %{release} -License: BSD -Group: System Environment/Base -Source0: %{name}-%{version}.tar.gz -BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root - -AutoReqProv: no -%define debug_package %{nil} - -%description -The PlanetLab Boot CD securely boots PlanetLab nodes into an immutable -environment. - -%prep -%setup -q - -%build -./build.sh build %{configuration} - -%install -install -d $RPM_BUILD_ROOT/var/www/html/download -pushd build/%{configuration} -bzip2 -c PlanetLab-BootCD-%{version}.iso > \ - $RPM_BUILD_ROOT/var/www/html/download/PlanetLab-BootCD-%{version}.iso.bz2 -bzip2 -c PlanetLab-BootCD-%{version}.usb > \ - $RPM_BUILD_ROOT/var/www/html/download/PlanetLab-BootCD-%{version}.usb.bz2 -md5sum PlanetLab-BootCD-%{version}.{iso,usb} >> \ - $RPM_BUILD_ROOT/var/www/html/download/PlanetLab-BootCD-%{version}.md5 -cd $RPM_BUILD_ROOT/var/www/html/download/ -md5sum PlanetLab-BootCD-%{version}.{iso,usb}.bz2 >> \ - PlanetLab-BootCD-%{version}.md5 -popd - -# If run under sudo, allow user to delete the build directory -if [ -n "$SUDO_USER" ] ; then - chown -R $SUDO_USER . -fi - -%clean -rm -rf $RPM_BUILD_ROOT - -# If run under sudo, allow user to delete the built RPM -if [ -n "$SUDO_USER" ] ; then - chown $SUDO_USER %{_rpmdir}/%{_arch}/%{name}-%{version}-%{release}.%{_arch}.rpm -fi - -%post -cat < - -- Initial build. - diff --git a/build.sh b/build.sh index a51797c..325506f 100755 --- a/build.sh +++ b/build.sh @@ -8,7 +8,7 @@ CONFIGURATIONS_DIR=configurations/ # where built files are stored BUILD_DIR=build/ -BOOTCD_VERSION="3.2" +BOOTCD_VERSION="3.1" FULL_VERSION_STRING="PlanetLab BootCD" OUTPUT_IMAGE_NAME='PlanetLab-BootCD' @@ -29,9 +29,7 @@ INITRD_BYTES_PER_INODE=1024 # make sure the boot manager source is checked out in the same directory # as the bootcd_v3 repository -for BOOTMANAGER_DIR in ../bootmanager-* ../bootmanager ; do - [ -d $BOOTMANAGER_DIR ] && break -done +BOOTMANAGER_DIR=../bootmanager/ if [ ! -d $BOOTMANAGER_DIR ]; then echo "the bootmanager repository needs to be checked out at the same" @@ -77,57 +75,16 @@ function build_cdroot() echo "initialize rpm db" mkdir -p $CD_ROOT/var/lib/rpm rpm --root $CD_ROOT --initdb - - # XXX Should download yum.conf from the boot server? - echo "generate yum.conf" -cat >yum.conf <>yum.conf <BootCD<\/name>/,//{ s/.*\(.*\)<\/packagereq>/\1/p }') + packages=`cat yumgroups.xml | grep packagereq | sed 's#<[^<]*>##g'` set +e for package in $packages; do echo "checking for package $package" - /usr/sbin/chroot $CD_ROOT /bin/rpm -qi $package > /dev/null + chroot $CD_ROOT /bin/rpm -qi $package > /dev/null if [[ "$?" -ne 0 ]]; then echo "package $package was not installed in the cd root." echo "make sure it exists in the yum repository." @@ -142,7 +99,7 @@ EOF echo "setting up non-ssh authentication" mkdir -p $CD_ROOT/etc/samba - /usr/sbin/chroot $CD_ROOT /usr/sbin/authconfig --nostart --kickstart \ + chroot $CD_ROOT /usr/sbin/authconfig --nostart --kickstart \ --enablemd5 --enableshadow echo "setting root password" @@ -155,12 +112,6 @@ EOF mv $CD_ROOT/var/lib/rpm $CD_ROOT/usr/relocated/var/lib/ (cd $CD_ROOT/var/lib && ln -s ../../usr/relocated/var/lib/rpm rpm) - # get /var/cache/yum out, its 100Mb. create in its place a - # symbolic link to /usr/relocated/var/cache/yum - mkdir -p $CD_ROOT/usr/relocated/var/cache/ - mv $CD_ROOT/var/cache/yum $CD_ROOT/usr/relocated/var/cache/ - (cd $CD_ROOT/var/cache && ln -s ../../usr/relocated/var/cache/yum yum) - # get /lib/tls out mkdir -p $CD_ROOT/usr/relocated/lib mv $CD_ROOT/lib/tls $CD_ROOT/usr/relocated/lib/ @@ -280,7 +231,7 @@ function build_initrd() $module_dep_file $pci_map_file $pci_table $CD_ROOT/etc/pl_pcitable dd if=/dev/zero of=$INITRD bs=1M count=$RAMDISK_SIZE - /sbin/mkfs.ext2 -F -m 0 -i $INITRD_BYTES_PER_INODE $INITRD + mkfs.ext2 -F -m 0 -i $INITRD_BYTES_PER_INODE $INITRD mkdir -p $INITRD_MOUNT mount -o loop,rw $INITRD $INITRD_MOUNT @@ -315,7 +266,7 @@ function build() USB_IMAGE=${ISO%*.iso}.usb # leave 1 MB of free space on the filesystem USB_KB=$(du -kc $ISO $CD_ROOT/usr/isolinux | awk '$2 == "total" { print $1 + 1024 }') - /sbin/mkfs.vfat -C $USB_IMAGE $USB_KB + mkfs.vfat -C $USB_IMAGE $USB_KB mkdir -p $INITRD_MOUNT mount -o loop,rw $USB_IMAGE $INITRD_MOUNT diff --git a/documentation/bootcd-flowchart.png b/documentation/bootcd-flowchart.png deleted file mode 100644 index 815177f..0000000 Binary files a/documentation/bootcd-flowchart.png and /dev/null differ diff --git a/documentation/bootcd-flowchart.vsd b/documentation/bootcd-flowchart.vsd deleted file mode 100644 index 8d0038e..0000000 Binary files a/documentation/bootcd-flowchart.vsd and /dev/null differ diff --git a/documentation/bootcd-tech-doc.pdf b/documentation/bootcd-tech-doc.pdf deleted file mode 100644 index 8565b63..0000000 Binary files a/documentation/bootcd-tech-doc.pdf and /dev/null differ diff --git a/documentation/bootcd-tech-doc.xml b/documentation/bootcd-tech-doc.xml deleted file mode 100644 index 71ba44d..0000000 --- a/documentation/bootcd-tech-doc.xml +++ /dev/null @@ -1,327 +0,0 @@ - - -
- - BootCD v3.x Technical Documentation - - - Aaron - - Klingaman - - alk@absarokasoft.com - - - - Princeton University - - - - - 1.0 - - November 17, 2005 - - AK - - - Initial draft. - - - - - -
- Overview - - This document describes in detail how the PlanetLab boot CD is built - and operates when running on a node. Older boot CDs, including 2.x cds, - are not the focus of this document, and are no longer being deployed on - production systems. -
- -
- Background - - Since the early days of PlanetLab, all production nodes are - configured during setup to only start up off of the cdrom, with a - PlanetLab boot cd always left in the drive. The intention is to allow a - machine to be able to restart into a known environment, for debugging - system problems, or as a way to still access the machine but not have any - potentially compromised code to run if the system is believed to be - compromised. -
- -
- Soure Code - - All 3.x boot cd source code is located in the repository 'bootcd_v3' - on the PlanetLab CVS system. For information on how to access CVS, consult - the PlanetLab website. Unless otherwise noted, all file references refer - to this repository. -
- -
- Basic Operation - - The operation of the boot cd, when a machine is started off of one, - is fairly straightforward. Essentially, it loads a Linux kernel, - configures the hardware and network, and fetches a signed script to - execute. This generic operation allows for the boot cds to be used for any - number of operations, whether they are installing machines or debug - problems. - - The full operation of a boot cd, from the moment it is booted, is - described in the following diagram. - -
- BootCD Operation Flowchart - - - - - - -
-
- -
- Security - - Ensuring that the boot cd provided a secure node boot mechanism was - a primary concern during its development. The following requirements we - used: - - - - The boot cd should be immutable. At any point, a PlanetLab - administrator should be able to reboot a machine into a known safe - environment to inspect or debug the node. - - - - The cd should verify that the servers it contacts for executable - scripts should be PlanetLab Central servers, and not someone posing as - one. - - - - The scripts executed are to be signed by PlanetLab - Central. - - - - Accomplishing 1. is fairly easy: simply require the cds to be burned - onto a write once media. Once that is accomplished, it is up to local site - administrators to ensure physical security of the node so the cd is not - switched out. Further work may be done by executed scripts to validate a - boot cd, if necessary (though not currently implemented). - - Number two is accomplished through the use of SSL certificates. The - PlanetLab Central boot server, running Apache at the time of this writing, - uses a self signed SSL certificate. The boot cd, for each server it is to - contact (a primary server, and a backup server), contains the CA - certificates for those servers. Using the URL downloading tool curl, the - scripts on the cd can ensure they are contacting a PlanetLab boot server, - and not someone attempting to spoof one. - - Number is accomplished through the use of GPG public and private - keys. There exists at PlanetLab Central a GPG private key that is used to - sign the scripts downloaded and executed by the cd. The public key is - located on the cd, and used to validate the signatures of the packages - before execution. -
- -
- Hardware Detection - - After the Linux kernel is loaded, the first operation is to load the - applicable hardware modules for devices on the system, including network - drivers, disk drivers, and any others. This process is nearly identical to - the process the BootManager uses. During the initial boot cd build - process, the script sources/merge_hw_table.py from the bootmanager - repository is invoked to create a lookup table to map PCI ids onto kernel - modules. For more information about how this script operates, consult the - BootManager technical documentation. -
- -
- Building A BootCD - - Previous PlanetLab boot cds were essentially boot cds from other - projects, modified for use with PlanetLab. With the introduction of - version 3.0 of the boot cd, they are now built from scratch. By doing - this, we can ensure that the packages contain on the cd are fully up to - date, only the packages we need for booting operations are installed (thus - reducing the cd size), and the hardware detection mechanisms match that of - the node installer (BootManager). - - Though the cds are built from scratch, the process to build a cd is - relatively simple, and are as follows: - - - - The build process is currently only tested with and known to - work with Fedora Core 2. You'll need root access on a FC2 - machine. - - - - Check out the boot cd repository from PlanetLab CVS: - - cvs -d :pserver:anon@cvs.planet-lab.org:/cvs co bootcd_v3 - - - - Initiate the build by running, from the bootcd_v3 - directory: - - ./build.sh build default - - - - When complete, the resultant iso image will be located in - configurations/default/ - - - - The default configuration built above produces a boot cd that is - configured to contact the primary PlanetLab boot servers. To build a - custom boot cd that contacts a different server, with a different SSL - certificate and GPG key, you will need to create a custom - configuration: - - - - Change into the bootcd_v3/configurations directory: - - cd bootcd_v3/configurations - - - - Copy the entire default directory, creating a new one with a - short name for the custom configuration. The name is only used during - the build process, and is not part of the actual cd. - - cp -r default mycustomcd - - - - Edit the configuration file in the new directory. That file - contains various fields that allow for the cd operation to be - customized, see the section, Build Configuration Options for more - information. - - - - Once complete, the custom cd can be built with: - - ./build.sh build mycustomcd - - - -
- Build Configuration Options - - The configuration file for builds (the default being located at - configurations/default/configuration, contains the following values that - can be modified to result in a custom build boot cd: - - - - EXTRA_VERSION - - Set this to add extra version information to this cd. This - will be added to the result ISO name, and on the cd. By doing so, - you will be able to differentiate the cds from PlanetLab Boot cds - (which have no extra version. - - - - DESCRIPTION - - A simple text description, one line, of the boot cd. - - - - ROOT_PASSWORD - - The encrypted password to use for the root account on the - boot cd. Only applies to the boot cd, not the root account on an - installed and fully running node. - - - - PRIMARY_SERVER / BACKUP_SERVER - - The hostname of the server to attempt to contact first, and - a backup server if that one fails. - - - - PRIMARY_SERVER_PORT / BACKUP_SERVER_PORT - - Which SSL port on the server we should contact (default SSL - port is 443). This rarely will need to be changed. - - - - PRIMARY_SERVER_PATH / BACKUP_SERVER_PATH - - The path containing the script this cd should download and - execute. Can either be a path to an exact file, like - /boot/bootscript, or, can be a directory or dynamically executed - file, like /boot/index.php or just /boot. In this case, the - resultant output of that file/directory should be a signed and - executable script. - - - - PRIMARY_SERVER_CERT / BACKUP_SERVER_CERT - - The SSL CA certificate(s) for the above server(s). This is - used to validate that the server we are contacting has not been - spoofed. - - - - PRIMARY_SERVER_GPG / BACKUP_SERVER_GPG - - The GPG public key(s) of the private key(s) that was used to - sign the script that will be returned by PRIMARY_SERVER_PATH or - BACKUP_SERVER_PATH - - - - NODE_CONFIGURATION_FILE - - If this cd is to be used exclusively by a single node, that - node's network configuration file can be placed on the cd. This is - the path on the local system to that configuration file, which - will be copied to a known location on the cd and used during boot - up. - - - - With regard to file paths: for the locations of the keys, - certificates, and optionally node configuration files, it is easiest to - place these files inside the directory with the bootcd configuration - file, and simply use the name of the file for the value. See the default - configuration file for an example. -
- -
- Build Package Sources - - The packages installed during the build process are - downloaded from the boot server specified by the - PRIMARY_SERVER variable, described - above. The build script installs the packages defined by the - BootCD yum group. This group should be - defined in a yumgroups.xml file located at - install-rpms/planetlab/yumgroups.xml in the - document root of the boot server. -
-
-
diff --git a/yum.conf b/yum.conf new file mode 100644 index 0000000..8c71cc5 --- /dev/null +++ b/yum.conf @@ -0,0 +1,17 @@ +[main] +cachedir=/var/cache/yum +debuglevel=2 +logfile=/var/log/yum.log +pkgpolicy=newest + +[FedoraCore2Base] +name=Fedora Core 2 Base -- PlanetLab Central +baseurl=http://boot.planet-lab.org/install-rpms/stock-fc2/ + +[FedoraCore2Updates] +name=Fedora Core 2 Updates -- PlanetLab Central +baseurl=http://boot.planet-lab.org/install-rpms/updates-fc2/ + +[BootCDRepo] +name=PlanetLab Boot CD +baseurl=http://boot.planet-lab.org/install-rpms/bootcd/ diff --git a/yumgroups.xml b/yumgroups.xml new file mode 100644 index 0000000..1007527 --- /dev/null +++ b/yumgroups.xml @@ -0,0 +1,58 @@ + + + + + + bootcd + BootCD + true + BootCD Image + + dhclient + bash + coreutils + iputils + kernel + bzip2 + crontabs + diffutils + logrotate + openssh-clients + passwd + rsh + rsync + sudo + tcpdump + telnet + traceroute + time + vixie-cron + wget + yum + curl + gzip + perl + python + tar + pciutils + kbd + authconfig + hdparm + lvm + lvm2 + kexec-tools + gnupg + nano + parted + pyparted + openssh-server + openssh-clients + ncftp + dosfstools + dos2unix + bind-utils + sharutils + + + +