"Borrowing" A Screen Session

GNU Screen is a tool that most everyone reading this will be aware of.  In a nutshell, it's a terminal multiplexer, that is, it allows multiple virtual terminals to be brought up in one screen session.  Very useful when you're on the terminal.

Another purpose that is used quite often is to allow long running scripts to run on a remote server, without having to worry about your SSH session getting disconnected.  One would simply start a screen session, run their script, and detach from the screen session, leaving the script to do it's work.

This can occasionally be a problem when one system administrator has started a long running process, and for whatever reason, another system administrator needs to get into the screen session, when it's owner isn't present.  Attempting to su user, then attach to the screen session will lead to the following error:


[14:43:06] [peter@server ~]$ sudo su user
[sudo] password for peter: 
[14:43:45] [user@server /home/peter]$ screen -l
Cannot open your terminal '/dev/pts/2' - please check.
[14:43:53] [user@server /home/peter]$

A quick check of the permissions of /dev/pts/2 reveals the problem:


[14:43:53] [user@server /home/peter]$ cd /dev/pts/
[14:51:42] [user@server /dev/pts]$ ls -lsa 2
0 crw--w---- 1 peter tty 136, 2 2012-11-04 14:51 2

As we can see, the terminal I'm connected to is owned by my user, not effective user that we assumed with su user.  One solution would be to chmod +w /dev/pts/2, but allowing other users to connect to our pts device poses a security risk.  Enter script.

Script is used to create a typescript recording of everything that happens in a terminal, as long as script is running.  It will connect to a new tty device when it is called:

[15:00:20] [user@server ~]$ script test

Script started, file is test

[15:00:25] [user@server ~]$ tty

/dev/pts/3

[15:00:32] [user@server ~]$ ls -lsa /dev/pts/3

0 crw--w---- 1 user tty 136, 3 2012-11-04 15:00 /dev/pts/3

As you can see, by calling script, we have obtained a new pts device, and it's owned by user, not by peter.  This means that we can now screen -d -r to attach to user's screens, even in his absence.

One last note:  If you don't have a purpose for the typescript file that is generated by script, just give it /dev/null as an output file:  script /dev/null, which will throw away the typescript.

Loopback Filesystems Revisited

In a post quite some time ago, I discussed loopback filesystems.  Well, lo and behold, a few weeks ago, I had the opportunity to play with them again.  Xen, a Linux VM Hypervisor (http://www.xen.org) mounts up its disk images as loopbacks.

I found out rather quickly, that the default number of loopback devices available to the Kernel is 8.  When you have one image for disk, and one for swap on each domU (virtual guest), that means you can only cram 4 machines onto a single hypervisor by default...  That's just unacceptable.

I found two methods that worked, although one is a bit more painful than the other:

Hypervisor with Guests running in Production:

When you can't reboot the machine for whatever reason (in my case, it was running VM's that I didn't have any space to migrate, and couldn't shut down), you can modprobe the loop module again and pass it a parameter:

# modprobe loop max_loop=128

This is all fine and good, really, except for the fact that you don't get nodes created for the loop devices in /dev automatically, so you have to do some lovely work with mknod before you can use your new devices, even though the kernel is aware of them:

# mknod -m660 /dev/loop8 b 7 8

Loop devices have a major number of 7, so make sure to change both 8's to the appropriate value for your system.  The defaults on the systems I've been working with (Debian Lenny, Debian Squeeze, and Ubuntu Precise (12.04 LTS)) are to have 8 loop devices, loop0 - loop7.

Of course making 120 new loop devices by hand isn't exactly fun... Time for bash-fu!

# for x in `seq 8 128`; do mknod -m660 /dev/loop$x b 7 $x; done;

This gives us our 128 loopback devices (assuming you had 0-7 OOTB), with the nodes created in /dev.  If you reboot, they're gone, so make sure to add the options to /etc/modules.conf or wherever your flavor decided to keep the module options.

Hypervisor without Guests (or can be rebooted):

If the machine can be rebooted, the situation is much easier.  My solution was to pass the parameter to the kernel at boot time via GRUB.

Simply set the following in /etc/default/grub (for Debian based distros):

GRUB_CMDLINE_LINUX_DEFAULT="max_loop=128 quiet"

Then rebuild your GRUB config and reboot:

# update-grub && shutdown -r now

When the machine comes back up, GRUB will have passed the max_loop option to the kernel at boot, and the kernel will have automatically created all of your loopback devices for you.

Obviously, this is a significantly simpler operation than creating the nodes in place, and if you have the option to reboot, I would say go for it.

Part I

Several failed attempts...

Apparently, in order to compile textutils, you need to have textutils installed...  Naturally (to me anyway), my first thought was Busybox.  I tried to compile it, no joy (unmet dependancies), I tried the appropriate binaries for my VM, also no joy... insta-segfault.

Fine, let's get the real sort util, and copy it over, perfect!  So I spend the next 20 minutes configuring another (32bit) VM to support SSH1 on the internal network (since, of course, the version of SSH with Dettuxx is ancient), and get scp working.  Copy the binary over, and it crashes complaining about libraries. File confirmed that it was dynamically linked, with libs that weren't installed in Dettuxx, no doubt.  Fine...

export CFLAGS="-static -O2 -g"
./configure --with-prefix=/home/peter/textutils_build
make
make install

This process went along nicely, and generated a statically linked set of textutils bins (the old textutils package wasn't exactly fun to find, mind you).  I scp these binaries over, and get:  "FATAL:  Kernel too old"

As we speak, I have RH7.1 installing in a VM, running a 2.4 kernel out of the box...  Wish me luck...

Loopback Filesystem

Ok, so it took quit a bit of expirimentation and FM reading, but here's the lowdown on creating loopback filesystems:

Create a file to hold the system, in my case, it's gonna be 10 megs:

peter@slacktop:~$ dd if=/dev/zero of=/home/peter/fsfile bs=1k count=10240
10240+0 records in                                                     
10240+0 records out                                                    
10485760 bytes (10 MB) copied, 0.0606135 s, 173 MB/s

Next set up the loopback system and point it at your spiffy new file:

peter@slacktop:~$ sudo /sbin/losetup /dev/loop0 /home/peter/fsfile

From here you can create and mount your filesystem:

peter@slacktop:~$ sudo /sbin/mkfs.ext2 /dev/loop0
mke2fs 1.41.8 (11-July-2009)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
2560 inodes, 10240 blocks
512 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=10485760
2 block groups
8192 blocks per group, 8192 fragments per group
1280 inodes per group
Superblock backups stored on blocks:
        8193

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 37 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

peter@slacktop:~$ sudo mkdir /mnt/lo

peter@slacktop:~$ sudo mount /dev/loop0 /mnt/lo

Tada... loopback filesystem.

Part II

dd

Not that anyone really needs to see how the dd command works across all 8 disks, but here you go.

hackserv:~# dd if=./dettuxx_disk01.img of=/dev/fd0
2847+1 records in
2847+1 records out
1458144 bytes (1.5 MB) copied, 101.165 seconds, 14.4 kB/s
hackserv:~# dd if=./dettuxx_disk02.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 101.119 seconds, 14.6 kB/s
hackserv:~# dd if=./dettuxx_disk03.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 101.119 seconds, 14.6 kB/s
hackserv:~# dd if=./dettuxx_disk04.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 102.521 seconds, 14.4 kB/s
hackserv:~# dd if=./dettuxx_disk05.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 101.321 seconds, 14.6 kB/s
hackserv:~# dd if=./dettuxx_disk06.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 101.518 seconds, 14.5 kB/s
hackserv:~# dd if=./dettuxx_disk07.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 101.314 seconds, 14.6 kB/s
hackserv:~# dd if=./dettuxx_disk08.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 101.516 seconds, 14.5 kB/s
hackserv:~#

And for thoes who don't know... A short excerpt from "man dd" (RTFM!)

NAME
dd - convert and copy a file

SYNOPSIS
dd [OPERAND]...
dd OPTION

DESCRIPTION
Copy a file, converting and formatting according to the operands.