Calendar
QuicksearchArchivesCategoriesBlog AdministrationPowered byLizenz/LicenseDer Inhalt dieses Blogs ist © Copyright 2009 Ralf Ertzinger. Jegliche Reproduktion und Wiederverwertung nur mit schriftlicher Genehmigung des Autors. The content of this blog is © Copyright 2009 Ralf Ertzinger. |
Sunday, July 15. 2012Creating a throwaway browserOnce every other while it's useful to have a browser that's not connected to the normal browsing profile (I know. Don't say it. I've been here a while). These are two shell scripts that create a new profile for Firefox and Chrome in a temporary directory, start the browser using that profile and remove the directory afterwards. Chrome#!/bin/bash trap cleanup EXIT die() { echo $@ exit 1 } cleanup() { [ -d ${CHROMETMP} ] && rm -rf ${CHROMETMP} } CHROMETMP=$(mktemp -d) [ -d ${CHROMETMP} ] || die "Could not create temp dir" chromium-browser --user-data-dir="${CHROMETMP}" Firefox#!/bin/bash trap cleanup EXIT die() { echo $@ exit 1 } cleanup() { [ -d ${FIREFOXTMP} ] && rm -rf ${FIREFOXTMP} } FIREFOXTMP=$(mktemp -d) [ -d ${FIREFOXTMP} ] || die "Could not create temp dir" export HOME=${FIREFOXTMP} firefox -no-remote -CreateProfile 'throwaway' || die "Could not create profile" firefox -no-remote -P 'throwaway' Sunday, July 1. 2012Installing CentOS 6 from a rescue systemI recently accquired a root server hosted by Manitu. It was planned to run Centos 6 on that server, but unfortunately that is not in the list of operating systems that can be preinstalled (or reinstalled) via the management web page. There is, however, a rescue system, an option to remotely boot the server into a bare bones Linux system via the network. Since an OS is basically a bunch of bits on a hard disk it should be possible to get said bits onto the hard disk from the rescue system. Now, there are some things to consider. First of all, this is not for someone new to Linux or CentOS. There are lots of ways for things to go wrong or not end up as expected. The usual failure mode for this is the remote system not booting, which is kind of hard to debug without any further information. Also, this will erase all data on the hard disks in the system. The partitioning scheme is what I needed for my system. Adjust as needed. If you don't know how that's the first clue that you should not be doing this in the first place. PreconditionsSome of the things needed for this to work:
It is further assumed that a tmpfs file system is mounted at Install planThe hardware in question here has two SATA HDDs on AHCI compatible controllers without any hardware RAID. The final hard disk layout will be as follows:
The PV is part of a volume group which contains an LV holding the root file system. Prepare the Live CDThe rescue system usually has no CentOS specific tools (like RPM) which are needed to install the OS packages. In order to get a usable install environment we'll commandeer the CentOS 6 live CD. It contains a complete root file system image.
mkdir /loop1 /loop2 /sysroot
mount -o ro /dev/shm/CentOS-6.2-x86_64-LiveCD.iso /loop1 mount -o ro /loop1/LiveOS/squashfs.img /loop2 mount -o ro /loop2/LiveOS/ext3fs.img /sysroot
mount -o bind /dev /sysroot/dev mount -o bind /proc /sysroot/proc mount -o bind /sys /sysroot/sys Now chroot into The image mounted at mount -t tmpfs tmpfs /tmp rsync -a /etc /tmp mount -o bind /tmp/etc /etc Ignore the Prepare for installationLeave the chroot again (working with LVM does not work within it). Remove and stop any existing volume groups and software raids. Then partition the hard disks according to the new scheme and create the new software RAIDs and LVMs. fdisk -u -c /dev/sda sfdisk -d /dev/sda | sfdisk --force /dev/sdb mdadm --create /dev/md0 -n 2 --level 1 --metadata=0.90 /dev/sda1 /dev/sdb1 mdadm --create /dev/md1 -n 2 --level 1 /dev/sda2 /dev/sdb2 pvcreate /dev/md1 vgcreate -s 64M vg_tara_root /dev/md1 lvcreate -n lv_swap -L 8G vg_tara_root lvcreate -n lv_c6_root -L 16G vg_tara_root mkfs.ext3 /dev/md0 mkfs.ext4 /dev/mapper/vg_tara_root-lv_c6_root tune2fs -c0 -i0 -r32000 -L boot /dev/md0 tune2fs -c0 -i0 -r32000 -L lv_c6_root /dev/mapper/vg_tara_root-lv_c6_root It's probably a good idea to wait for the RAID resync, that should not take long. The metadata version on
mkdir /tmp/sysroot mount /dev/mapper/vg_tara_root-lv_c6_root /tmp/sysroot mkdir -p /tmp/sysroot/{boot,dev,proc,sys} mount /dev/md0 /tmp/sysroot/boot mount -o bind /dev /tmp/sysroot/dev mount -o bind /proc /tmp/sysroot/proc mount -o bind /sys /tmp/sysroot/sys Installation
rpm --root /tmp/sysroot --rebuilddb
rpm --root /tmp/sysroot -ihv /tmp/centos-release-6-2.el6.centos.7.x86_64.rpm
yum --installroot=/tmp/sysroot groupinstall base
yum --installroot=/tmp/sysroot install grub openssh-server
umount /tmp/sysroot/{boot,dev,proc,sys,} /etc /tmp
umount /sysroot/{dev,proc,sys,} umount /loop2 umount /loop1
mount /dev/mapper/vg_tara_root-lv_c6_root /sysroot mount /dev/md0 /sysroot/boot mount -o bind /dev /sysroot/dev mount -o bind /proc /sysroot/proc mount -o bind /sys /sysroot/sys
ln -s /proc/mounts /etc/mtab
grub-install /dev/md0
LABEL="lv_c6_root" / ext4 defaults 1 1 LABEL="boot" /boot ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0
NETWORKING=yes NOZEROCONF=yes HOSTNAME=tara.example.org
DEVICE=eth0 BOOTPROTO=static IPADDR=192.168.0.100 GATEWAY=192.168.0.1 PREFIX=24 ONBOOT=yes
default=0 timeout=5 title CentOS (2.6.32-220.23.1.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-220.23.1.el6.x86_64 ro root=LABEL=lv_c6_root LANG=en_US.UTF-8 \ SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=de-latin1-nodeadkeys initrd /initramfs-2.6.32-220.23.1.el6.x86_64.img
cp /etc/skel/.* /root
ln -s grub.conf /boot/grub/menu.lst ln -s /boot/grub/grub.conf /etc/grub.conf
umount /sysroot/{boot,sys,dev,proc,} Now, usually this ought to result in a bootable system which can be accessed via SSH. Only one way to find out. Sunday, August 21. 2011Installing RedHat 1.1 (Mother's Day + 0.1)Just to see what life was like in the dark ages of Linux distributions I ventured to install the earliest RedHat release I could get my hands on in a QEMU virtual machine. It turns out that this is easier said than done. RedHat does have an archive of old versions (available at http://archive.download.redhat.com), but this is quite incomplete for the earliest version. Fortunately there's an installable version of Mother's Day 1.1 on ibiblio (the 1.0 release is incomplete as well), which I used. To make an installable version out of this it's recommened to make a local copy of the complete tree, which is easily done with $ rsync -rv --progress www.ibiblio.org::pub/historic-linux/distributions/redhat/mothers-day-1.1 . This will create a local directory called The installer will need to access the files via a CDROM or a NFS share. I opted for the CD method, so let's create a CD image: $ chmod +x mothers-day-1.1/bin/* $ mkisofs -J -R -o mothers-day-1.1.iso mothers-day-1.1 This makes all the files in The installer will boot from a floppy disk. The release contains a whole bunch of these, for different hardware configurations (a kernel containing all supported configs would not have fitted on one floppy, so one has to choose the right one). For QEMU we'll need standard IDE support (easy) and AMD PCnet support for networking (also easy). The boot image supporting these is located in $ cp mothers-day-1.1/images/1211/boot0066.img boot.img $ qemu-img resize boot.img 1440k Image resized $ cp mothers-day-1.1/images/rootdisk.img . This copies the correct boot image to All that's missing now is a hard disk image to install to. This should not be too large, as the IDE driver in the kernel has some problems handling this. Fortunately this is the deep past, so 768MB will be plenty. $ qemu-img create -f qcow2 disk1.img 768MB Deep past or not, the installer needs memory, and an amazing (for the time) amount of it. 4MB will not be enough, 8MB will do fine. So, let's go. $ qemu -M pc -m 8 -fda boot.img -drive file=disk1.img,if=ide,media=disk,cache=writeback \ -cdrom mothers-day-1.1.iso -net nic,model=pcnet -net user -boot a (This adds the hard disk image in writeback cache mode. This is not recommended from a data security standpoint, as data written by the virtual machine is not immediately committed to host storage, but since this is just a for fun exercise and EXT2 formatting takes ages with the default cache strategy I'll pass on data security here) At the LILO prompt, just press Enter to boot with default options. When prompted, change the floppy to the root disk ( Select an Express install, say "No" to the default package list question, and select CD as the install media. The installer ought to find the CD image on There will be no OS/2 on this install, so skip the reboot at the next question. The hard disk will need to be partitioned. The installer should find a hard disk at Confirm On the package selection screen select whatever needed (or just everything, it does not really matter :) I'd recommend at least the Net Utils, everything X and Utils+. And there's Doom (but more on that later). When asked for the type of video card select SVGA, and enter a hostname for the machine. The installer will then format swap and file system, which might take a few seconds. Or even minutes. If you did not change the default caching strategy in the QEMU call above it will definitely take minutes. Or hours. After the formatting the package installation phase begins. This will also take a few minutes, but at least it has a progress bar. The installer may complain about XF86_SVGA being already installed in the end, this can be ignored. Then the boot kernel is copied from the boot floppy. For the mouse, select The X configuration is a bit wonky (and this would not really change for the next decade or more). Decline autoprobe, select Configure networking, entering a host name, domain name and fully qualified host name. Select Select no modem, your keymap, local time and your time zone (the list is sorted upside down, for whatever reason). Select to install LILO in Create a user account (if you want) and select a root password. After that, the installation is finished. Select reboot. The system will be unable to actually reboot, so stop QEMU after the installer has terminated and start it again: $ qemu -M pc -m 8 -drive file=disk1.img,if=ide,media=disk -net nic,model=pcnet -net user -serial msmouse This invocation is missing the floppy and CD images (they are not needed anymore) and adds a serial mouse. At the boot prompt press Enter, and wait until the system has bootet to the login prompt (which will take all of a few seconds). Look around. If you're used to RedHat based systems (or Fedora) most things should look familiar. Next up: getting X to actually work. Sunday, March 21. 2010Building a multi OS USB boot stick, Part 1 (Windows)Among the things I carry around is always a collection of USB sticks, for various purposes. One of those is usually dedicated to a Linux rescue system, in order to get somehow broken systems back on their feet. While it is possible these days to access non Linux systems from a booted Linux system any repair work beyond simple text file editing and file copying usually requires OS specific tools to get the job done. Thus it would be nice not only to have a Linux rescue system at hand, but a Windows one as well. And Solaris, while we're at it. And possibly some more. USB sticks are cheap, at least in this part of the world. 10EUR will get you 4GB off the shelf in almost any electronics store, a little more money will get you 8GB ordered online. So space is not really an issue. Actually installing an operating system in a way that allows it to boot off a removable media requires some specific preparations and tools in each case. This means that a running instance of that specific OS is needed to prepare the installation. This means that to get Windows to boot of an USB stick a running Windows installation is needed. The same goes for Solaris and Linux. PreparationsThe USB stick used for this exercise is a 4G Sandisk. This procedure will delete all data currently on the stick, so either make sure there is nothing of any interest on it, or just get a new one. The initial plan is to have Windows, Linux and Solaris boot off the stick. Each OS will get it's own partition, to keep possible clashes between the files of each system to a minimum (and because Solaris wants and UFS partition, but more on that later). Installing Windows on USBThe standard Windows installer does not allow for installation on USB devices. The standard tool for those tasks is BartPE, a free tool to create so-called Preinstalled Environments. Those are actually a Microsoft supported way to preinstall an operating system on a PC, which is used by system builders to deliver machines with the OS already installed but not registered. The Microsoft tools to create these environments are not easily available, though, and this is where BartPE came in a few years ago. It's original purpose was to create Live CDs of Windows, but booting from USB was added (experimentally) later. While BartPE is a very valuable tool there is an even better one for this special purpose: The Ultimate Boot CD for Windows, which is basically a BartPE with a lot of useful tools already tacked to the side, and a completely reworked USB installer. To use UBCD the following is needed:
The last point is especially interesting. UBCD will take all drivers whichare contained in the Windows XP install CD, which, as everyone knows who tried to install XP on a reasonably recent machine, is not exactly much. While the USB installed will boot (hopefully), access to hard disk drives on the machine or access to network interfaces may be severely limited due to missing drivers. UBCD already comes with a largeish selection of updated drivers for mass storage, LAN and WLAN, so simply building an image with the default settings has a good chance of working on a large number of modern machines (although the WLAN drivers are disabled by default). Install procedure
![]() The UBCD main screen This will start a build process with the default settings, which are reasonable for a first build. UBCD is very customizable, most of the options are available by clicking the "Plugins" button on the main screen. Describing the various things that can be done here is beyond this text, but the UBCD home page has details on this. After the build has finished plug in the USB stick and start
![]() UBUSB main screen Clicking "Go" will start the process of repartitioning, formattingand copying of data to the USB stick. This may take a while. After the process has finished (hopefully successful) the resulting USB stick can immediately be tested, because UBCD comes with a copy of qemu, which can emulate a PC. Just click the "Test USB" button, and a virtual PC will try to boot off the USB stick just created. ![]() USB boot menu ![]() Windows booted off the USB stick in qemu One down, two to go.
Posted by Ralf Ertzinger
in Computer, Linux, Software, Solaris, Windows
at
17:23
| Comment (1)
| Trackbacks (0)
Wednesday, November 18. 2009Resetting SATA devices under LinuxNote: this was tested only on SATA attached optical drives, not on hard disks. Removing a hard disk with mounted partitions on it (directly or indirectly) is probably not a very smart idea. A device name of
# readlink /sys/block/sr0 ../devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 The interesting part if the answer is
# echo 1 > /sys/block/sr0/device/delete This will remove the device from the bus (logically). Look in
# echo "- - -" > /sys/class/scsi_host/host1/scan
Tuesday, March 24. 2009iSCSI: Opensolaris target, Fedora initiator, with CHAPFor some reason or another finding instructions on how to actually configure iSCSI for a rather simple and common use case (one target on Solaris, one initiator on Fedora, CHAP authentication) seems to be pretty hard. Either my google-fu is seriously broken today, or everyone except for me considers this to be so easy and obvious that it does not warrant documentation. Which, having done this for the last three hours, I seriously doubt. The Solaris side is actually documented quite well (I primarily used this blog entry by alasdair), the Linux side is lacking. It does not help matters that both sides use identically named tools that work in completely different ways. So, the deal is as follows: One OpenSolaris system, acting as iSCSI target (that is the system presenting the storage space). One Fedora Linux system, acting as iSCSI initiator (that is the system that wants to use the storage space) Create 100GB storage space on the target and let the initiator connect to this storage space and create a filesystem on in. The connection has to be authenticated one way (the initiator presents credentials to the target). h3. The Solaris side The system is running Nevada, the configuration here was done with build snv_110. First, the iSCSI target software needs to be installed and enabled: # gkp.pl -d /mnt/Solaris_11/Product SUNWiscsitgtu # svcadm enable iscsitgt:default # The backing store for the iSCSI volumes shall be provided by ZFS: # zfs create -o canmount=off tank/iscsi # zfs create -V 100G -o shareiscsi=on tank/iscsi/vol001 # iscsitadm list target -v Target: tank/iscsi/vol001 iSCSI Name: iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8 Alias: tank/iscsi/vol001 [...] # The # iscsitadm create tpgt 1 # iscsitadm modify tpgt -i 212.51.12.90 1 # iscsitadm list tpgt -v 1 TPGT: 1 IP Address: 212.51.12.90 # iscsitadm modify target -p 1 tank/iscsi/vol001 # iscsitadm list target -v Target: tank/iscsi/vol001 [...] TPGT list: TPGT: 1 [...] # In order to secure access to this volume some more the initiator is required to authenticate itself using CHAP before access is granted. To do this three pieces of information are needed:
The initiator used here has an iqn of # iscsitadm create initiator -n iqn.2005-03.com.max:01.cb5c4c lain # iscsitadm modify initiator --chap-name lain lain # iscsitadm modify initiator --chap-secret lain [...] # iscsitadm list initiator -v Initiator: lain iSCSI Name: iqn.2005-03.com.max:01.cb5c4c CHAP Name: lain CHAP Secret: Set # iscsitadm modify target --acl lain tank/iscsi/vol001 # iscsitadm list target -v Target: tank/iscsi/vol001 [...] ACL list: Initiator: lain [...] # This concludes the Solaris side of things. h3. The Fedora side The system is running Fedora Rawhide, close to the Fedora 11 Beta release at the time of this writing. On the Linux side iSCSI is handled by the open-iscsi toolchain, packaged as # yum install iscsi-initiator-utils [...] # Since the system in question is a notebook, and the iSCSI target may not be available at all times, the iSCSI service must be instructed not to connect to configured devices automatically: # perl -pi -e 's/node.startup.*/node.startup = manual/' /etc/iscsi/iscsid.conf # The initiator name mentioned in the Solaris section above can be configured freely on the system. A random value is created during package installation and saved in # cat /etc/iscsi/initiatorname.iscsi InitiatorName=iqn.2005-03.com.max:01.cb5c4c # Be sure the name configured there matches the name defined in the initiator on the Solaris side. Even though a username/password pair was defined on the target credentials are not needed for target discovery (the process by which an initiator asks a target which iSCSI volumes are available): # iscsiadm -m discovery -t st -p 212.51.12.90 212.51.12.90:3260,1 iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8 # iscsiadm -m node 212.51.12.90:3260,1 iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8 # The discovery process has found a single volume exported by the target and added it to the local node list. The iqn matches the value shown above in the Solaris section. Now the CHAP credentials have to be added to the node so the initiator can actually connect to the volume: # iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' \ --name 'node.session.auth.authmethod' -v 'CHAP' # iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' \ --name 'node.session.auth.username' -v 'lain' # iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' \ --name 'node.session.auth.password' -v 'iscsipassword' # iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' node.name = iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8 node.tpgt = 1 node.startup = manual [...] node.session.auth.authmethod = CHAP node.session.auth.username = lain node.session.auth.password = ******** [...] # Now the volume can finally be accessed: # iscsiadm -m node --target 'iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8' --login Logging in to [iface: default, target: iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8, portal: 212.51.12.90,3260] Login to [iface: default, target: iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8, portal: 212.51.12.90,3260]: successful # After some seconds a device node for this volume should appear in # ls /dev/disk/by-path/ ip-212.51.12.90:3260-iscsi-iqn.1986-03.com.sun:02:218c35e0-0881-cb4f-d6bd-80e08bdc98d8-lun-0 [...] # The disk is ready to be used.
Posted by Ralf Ertzinger
in Computer, Linux, Software, Solaris
at
00:16
| Comments (0)
| Trackbacks (0)
Wednesday, March 11. 2009Building an OpenSolaris storage - Software, Part 6Since I tend to forget these things, here's a short list showing various package management tasks. |_. Task |_. RPM |_. pkg (Solaris) |
| List all installed packages |
Posted by Ralf Ertzinger
in Computer, Linux, Software, Solaris
at
19:50
| Comments (0)
| Trackbacks (0)
Sunday, January 25. 2009Reading OSX install media under LinuxIf you ever tried to take a look around an OSX install DVD unter Linux you may have been surprised by the marvelous compression algorithms that Apple uses, because there seems to be preciously little data on those disks: $ du -sh /media/OSX86DVD/ 132K /media/OSX86DVD/ There is no magic here, as seen by the fact that the same disk inserted into a running OSX system shows a completely different file structure with more than 4GB of data. The explanation for this is that there are two filesystems on the DVD: First, a normal ISO9660 CD file system, which contains some bootloader files, and not much else. This filesystem is the one that Linux (and Windows) see by default. Behind the ISO9660 filesystem there is another one, which spans the rest of the disk. This is a complete hard disk image with it's own partition table, and which contains the real installer data. As Linux does not expect this it does not try to access this filesystem, and the files remain invisible. In order to get at the files in the second part of the disk some command line magic is necessary. You will need root privileges for the following operations. I assume that the DVD device is The Linux kernel has a nice block device mapping layer which allows us to take a slice out of an existing block device and present this slice as a new device. Even more, there is a helper tool that inspects a block device, looks for partitions and automatically creates such a mapping for each partition. This tool is called So we use # kpartx -a /dev/sr0 device-mapper: reload ioctl failed: Invalid argument create/reload failed on sr0p1 device-mapper: reload ioctl failed: Invalid argument create/reload failed on sr0p2 # That did not work too well. For some reason the device mapper does not like CDROM/DVD devices. So we'll have to get a bit inventive. We create a loop device which is backed by the DVD device, and use that. # /sbin/losetup /dev/loop0 /dev/sr0 # /sbin/kpartx -av /dev/loop0 add map loop0p1 (253:5): 0 63 linear /dev/loop0 1 add map loop0p2 (253:6): 0 9178688 linear /dev/loop0 448 # The command found and created two partitions. The first partition is the ISO9660 file system at the beginning of the disk, the second one is the partition we are interested in. Let's look what's in it. # file -s /dev/mapper/loop0p2 /dev/mapper/loop0p2: Macintosh HFS Extended version 4 data last mounted by: '10.0', created: Tue Oct 30 00:32:01 2007, last modified: Wed Dec 19 16:45:14 2007, last checked: Tue Oct 30 00:32:01 2007, block size: 4096, number of blocks: 1147336, free blocks: 192685 # That looks good. We could now mount the filesystem and look around. # mount /dev/mapper/loop0p2 /mnt # ls /mnt Applications Desktop DB dev Install Mac OS X.app mach_kernel sbin tmp vanilla Volumes bin Desktop DF etc Library private System usr var # To get rid of all this again we have to unmount the file system, destroy the mappings and release the loop device: # umount /mnt # kpartx -d /dev/loop0 # losetup -d /dev/loop0
(Page 1 of 1, totaling 8 entries)
|