Joseph Ruscio

Setting up an APT Repository

2010-08-19T00:00:00-07:00

I recently set out to create an APT repository to host publicly available packages for Librato’s Silverline. Our users install a tiny agent on their servers and a hosted APT repository provides those using Debian/Ubuntu a configuration management solution superior to manual downloads.

Our APT repository must support multiple distributions of both Debian (e.g. Etch, Lenny) and it’s popular derivative Ubuntu (e.g. Karmic, Lucid). The repository must support both the i386 and x86_64 architectures across all such distributions. A short google search reveals that reprepro is a tool designed for just such a purpose. There are also informative reprepro walkthroughs already online, but they all gloss over some subtle yet extremely important details.

So what follows is my attempt to minimally but comprehensively document the procedure assuming a familiarity with shell basics, but little or no experience with Debian packging past apt-get update/upgrade/install.

Host Environment

Our APT repository is hosted on a fresh installation of Ubuntu 10.04 Lucid, but the procedure should work on any recent version of Debian/Ubuntu.

Package Configuration

The most important detail that AFAIK isn’t covered in any of the tutorials had to do with package naming conventions. The naive assumption (at least on my part) is that you’ll have a different build of your package for each distro/arch combination, and import them into your repository as such. In other words reprepro should track the distro/arch of each import. In actuality, each build’s __ must be unique, even though you specify the distro during the includedeb operation.

To address this requirement there’s a common practice of appending the distro to the package version e.g. 1.0.7 becomes 1.0.7~lenny1 or 1.0.7+etch4. (There doesn’t appear to be a consensus on the joining character.) Adding the second version number after the distro string versions the package itself, enabling updates that only contain changes to the packaging itself.

If you do not build your packages to include the distro as part of the version, you will not be able to import a package for more than one distro. You can verify your package was built correctly by inspecting the Version field listed by dpkg -I:

ubuntu:~/lenny$ dpkg -I librato_silverline_debian_lenny_5.0.3.x86_64.deb
       new debian package, version 2.0.
       size 306916 bytes: control archive= 834 bytes.
       255 bytes,     7 lines      conffiles            
       277 bytes,    10 lines      control              
       991 bytes,    26 lines   *  postinst             #!/bin/sh
       Package: librato-silverline
       Version: 2.0.7~lenny
      ...

GnuPG

Assuming you want sign your debian packages to create a secure APT repository, you need a GPG key. If you already have a GPG key you can skip to the next section. Otherwise first ensure that GPG is installed:

ubuntu:~$ sudo apt-get install gnupg

Create a key with the --gen-key command. Select the defaults and be sure to record the key’s passphrase, you’ll need it each time you import a package into the repository:

ubuntu:~$ gpg --gen-key

Install and Configure reprepro

Armed with properly configured packages and a GPG key with which to sign them, we’re now ready to start constructing the repository itself. Start by installing reprepro:

ubuntu:-$ sudo apt-get install reprepro

Create a directory to serve as the base of the Debian repository. In our setup /var/packages/debian serves as the Debian repository base. In the future /var/packages/ubuntu will house the Ubuntu repository base. We’ll change ownership of these directories to the ubuntu user that owns the signing key.

ubuntu:~$ sudo mkdir /var/packages
      ubuntu:~$ sudo chown ubuntu:ubuntu /var/packages
      ubuntu:~$ mkdir /var/packages/debian

Each repository needs a top-level conf directory:

ubuntu:~$ mkdir /var/packages/debian/conf

Create a file named distributions in the conf directory. You’ll add a set of newline separated configuration blocks (one for each supported distro) to this file. In this example the repository supports etch and lenny. In the future squeeze support could be added with a third block:

Origin: Librato, Inc.
      Label: Librato, Inc.
      Codename: etch
      Architectures: i386 amd64
      Components: non-free
      Description: Librato APT Repository
      SignWith: yes
      DebOverride: override.etch
      DscOverride: override.etch
      
      Origin: Librato, Inc.
      Label: Librato, Inc.
      Codename: lenny
      Architectures: i386 amd64
      Components: non-free
      Description: Librato APT Repository
      SignWith: yes
      DebOverride: override.lenny
      DscOverride: override.lenny

Fill in the Origin, Label, and Description as you see fit. Codename identifies the distro the block describes and Architectures is self-explanatory (note that sources is a valid arch). Components lists the component of the packages in the repository e.g. for Debian main, contrib, or non-free. DebOverride and DscOverride exceed the scope of this posting, the reader may either research them on their own or set them as shown.

SignWith instructs reprepro that these packages should be signed. The yes is sufficient as the ubuntu user only has the one key generated above. If you have more than one key you can specify the ID of the signing key with this field.

Create empty override files:

ubuntu:~$ touch /var/packages/conf/override.etch
      ubuntu:~$ touch /var/packages/conf/override.lenny

Create a file named options in the conf directory and fill it with the following content. This file will store a set of options for reprepro to always run. We only use a few but there are more available on the reprepro manpage.

verbose
      ask-passphrase
      basedir .

The verbose option is self-explanatory. The ask-passphrase option instructs reprepro to ask us for a GPG key passphrase during the import (otherwise it’ll fail to sign the packages). The basedir . implies that we’ll be running all of our reprepro commands with the repository base as our working directory:

ubuntu:~$ cd /var/packages/debian

Import Packages

The repository base is completely configured and ready for package importing. Just use the includedeb command and specify the correct distro. In our case:

ubuntu:/var/packages/debian$ reprepro includedeb etch ~/librato_silverline_debian_etch_4.0r8.x86_64.deb
      ...
      ubuntu:/var/packages/debian$ reprepro includedeb lenny ~/ubuntu/librato_silverline_debian_lenny_5.0.3.x86_64.deb

Each reprepro includedeb operation should prompt for your GPG key passphrase and import the package.

Repository Access

We now have a proper Debian repository and all that remains is making it accessible for installations over the WAN. We just need to serve static files so we’ll use nginx to serve the packages over HTTP.

ubuntu:/var/packages/debian$ sudo apt-get install nginx

Configure the APT server in /etc/nginx/sites-available/vhost-packages.conf:

server {
        listen 80;
        server_name apt.librato.com;
      
        access_log /var/log/nginx/packages-error.log;
        error_log /var/log/nginx/packages-error.log;
      
        location / {
      root /var/packages;
      index index.html;
        }
      
        location ~ /(.*)/conf {
      deny all;
        }
      
        location ~ /(.*)/db {
      deny all;
        }
      }

Configure the hash bucket size by creating the file /etc/nginx/conf.d/server_names_hash_bucket_size.conf

server_names_hash_bucket_size 64;

Enable the APT server:

ubuntu:/var/packages/debian$ cd /etc/nginx/sites-enabled
      ubuntu:/etc/nginx/sites-enabled$ sudo ln -s ../sites-available/vhosts-packages.conf .
      ubuntu:/etc/nginx/sites-enabled$ sudo service nginx start

Enable Public Key Access

Our users will need our public key to validate the signed packages we’re providing. Placing it in the root of our nginx configuration above makes it accessible with a simple curl invocation:

gpg --armor --output /var/packages/packages.librato.key --export apt@librato.com

Installation Test

Now we can test our fully operational APT repository. On some candidate machine log in as root and add our repository to /etc/apt/sources.list:

deb http://apt.librato.com/debian/ lenny non-free

Import the repository’s public key:

lenny:# curl http://apt.librato.com/packages.librato.key | apt-key add -

Fetch the list of packages available at the new source:

lenny:# apt-get update

Install the hosted package!

lenny:# apt-get install librato-silverline

Increasing hard disk size with LVM on VMWare Fusion Linux guest

2009-12-08T00:00:00-08:00

I currently use VMware Fusion to maintain and run a Linux guest on my Macbook. When I originally installed the guest, I assumed that a 20 GB virtual disk would be more than enough space for my Linux hacking.

As you can probably infer from the title of this post, some recent developments invalidated that assumption and necessitated more disk space. What follows is a procedure I cobbled together from a bunch of disparate sources that works for my particular setup (VMware Fusion 2.0.4, Fedora 10 guest w/LVM and an ext3 filesystem). These instructions involve modifying physical partitions, logical volumes, and your filesystem so I advise you to read through them to the end before getting started.

The very first step is to use Fusion to increase the “physical size” of the virtual disk. This functionality is accessible through the Virtual Machine -> Hard Disk -> Hard Disk Settings menu item. The resulting dialog contains a Disk size slider. Note that this slider is not accessible unless the VM in question is shut down and (more annoyingly) all pre-existing snapshots are deleted. I just had one snapshot to delete, but it took a while, so be patient. After you’ve increased the disk size, probably wouldn’t hurt to take a new snapshot, just in case something goes wrong with the procedure below.

Now that we’ve increased the disk size (I increased mine from 20GB -> 50GB), let’s boot the VM and log into our guest. We’ll use the df command to examine our mounted file filesystems:

[root@fedora ~]# df -h
      Filesystem            Size  Used Avail Use% Mounted on
      /dev/mapper/VolGroup00-LogVol00
                 18G   15G  1.9G  89% /
      /dev/sda1             190M  163M   18M  91% /boot
      tmpfs                 502M   80K  502M   1% /dev/shm

Still shows 20 GB of total space and a filesystem device /dev/mapper/VolGroup00-LogVol00 that’s indicative of LVM, the default for Fedora. Use the venerable fdisk to examine the “physical” disk:

[root@fedora ~]# fdisk -l
      Disk /dev/sda: 52.6 GB, 52613349376 bytes
      255 heads, 63 sectors/track, 6396 cylinders
      Units = cylinders of 16065 * 512 = 8225280 bytes
      Disk identifier: 0x000f2b12
      Device    Boot      Start         End      Blocks   Id  System
      /dev/sda1   *           1          25      200781   83  Linux
      /dev/sda2              26        2610    20764012+  8e  Linux LVM

The physical disk has the capacity, but its in the form of unpartitioned/unformatted space. Before we can do anything, We need to create a new partition containing this space. First we’ll drop into parted and examine the existing partition table:

(parted) print
      Model: VMware, VMware Virtual S (scsi)
      Disk /dev/sda: 52.6GB
      Sector size (logical/physical): 512B/512B
      Partition Table: msdos
      Number  Start   End     Size    Type     File system  Flags
       1      32.3kB  206MB   206MB   primary  ext3         boot 
       2      206MB   21.5GB  21.3GB  primary               lvm

Create a new partition that uses up all of the new space on the physical device:

(parted) mkpart primary 21.4GB -1s 
      (parted) print
      Model: VMware, VMware Virtual S (scsi)
      Disk /dev/sda: 52.6GB
      Sector size (logical/physical): 512B/512B
      Partition Table: msdos
      Number  Start   End     Size    Type     File system  Flags
       1      32.3kB  206MB   206MB   primary  ext3         boot 
       2      206MB   21.5GB  21.3GB  primary               lvm  
       3      21.5GB  52.6GB  31.1GB  primary

Use partprobe to load the table:

(parted) quit
      [root@fedora ~]# partprobe

At this point we’ve got a new partition, /dev/sda3, that you could simply format with mke2fs and mount as its own filesystem e.g. /mnt/data. I personally chose to leverage LVM’s capabilities and incorporate the new partition into the existing logical volume mounted as /. Start by examining the set of existing physical volumes:

[root@fedora ~]# lvm pvs
        PV         VG         Fmt  Attr PSize  PFree 
        /dev/sda2  VolGroup00 lvm2 a-   19.78G 32.00M

Create a new physical volume with the new partition:

[root@fedora ~]# lvm pvcreate /dev/sda3
        Physical volume "/dev/sda3" successfully created
      [root@fedora ~]# lvm pvs
        PV         VG         Fmt  Attr PSize  PFree 
        /dev/sda2  VolGroup00 lvm2 a-   19.78G 32.00M
        /dev/sda3             lvm2 --   29.01G 29.01G

Add new physical volume to the volume group. If you recall from the initial df output above, the volume group in question is VolGroup0:

[root@fedora ~]# lvm vgextend VolGroup00 /dev/sda3
        Volume group "VolGroup00" successfully extended
      [root@fedora ~]# lvm pvs
        PV         VG         Fmt  Attr PSize  PFree 
        /dev/sda2  VolGroup00 lvm2 a-   19.78G 32.00M
        /dev/sda3  VolGroup00 lvm2 a-   29.00G 29.00G

Now extend the logical volume to include the physical volume we just added to the group. Use lvm vgdisplay to examine the group:

[root@fedora ~]# lvm vgdisplay VolGroup00
        --- Volume group ---
        VG Name               VolGroup00
        System ID
        Format                lvm2
        Metadata Areas        2
        Metadata Sequence No  4
        VG Access             read/write
        VG Status             resizable
        MAX LV                0
        Cur LV                2
        Open LV               2
        Max PV                0
        Cur PV                2
        Act PV                2
        VG Size               48.78 GB
        PE Size               32.00 MB
        Total PE              1561
        Alloc PE / Size       632 / 19.75 GB
        Free  PE / Size       929 / 29.03 GB
        VG UUID               8w2Wi9-T2lV-IKCV-fLRP-yTJl-teJM-LuGoNb

The Free PE/Size field shows the new physical volume as 929 free extents. Extend the logical volume to include all free extents:

[root@fedora ~]# lvm lvextend -l+929 /dev/VolGroup00/LogVol00
        Extending logical volume LogVol00 to 46.81 GB
        Logical volume LogVol00 successfully resized

Use resize2fs to extend our ext3 filesystem online. Note that many LVM tutorials online refer to the now deprecated ext2online command for this step, resize2fs now provides this functionality:

root@fedora ~]# resize2fs /dev/VolGroup00/LogVol00 
      resize2fs 1.41.4 (27-Jan-2009)
      Filesystem at /dev/VolGroup00/LogVol00 is mounted on /; on-line resizing required
      old desc_blocks = 2, new_desc_blocks = 3
      Performing an on-line resize of /dev/VolGroup00/LogVol00 to 12271616 (4k) blocks.
      The filesystem on /dev/VolGroup00/LogVol00 is now 12271616 blocks long.

Finally, use df again to verify that we have lots of free space:

[root@fedora ~]# df -h
      Filesystem            Size  Used Avail Use% Mounted on
      /dev/mapper/VolGroup00-LogVol00
                 47G   15G   29G  34% /
      /dev/sda1             190M  163M   18M  91% /boot
      tmpfs                 502M   80K  502M   1% /dev/shm

Aggregate statistics gem released!

2009-09-13T00:00:00-07:00

Finally got around to putting together a decent README (and a few last bugfixes) for my Aggregate statistics gem. With that out of the way, its ready for public consumption. Aggregate is an easy-to-use ruby implementation of a statistics aggregator that includes configurable histogram (binary or linear) support. Stats are aggregated in a streaming fashion that doesn’t record/store any of the individual sample values, enabling statistics tracking across a practically unlimited number of samples without any impact on your application’s performance or memory footprint.

Perhaps more importantly than the basic aggregate statistics (e.g. mean, standard deviation, max, min, etc) Aggregate also maintains a histogram of the sample distribution. For anything other than normally distributed data averages are insufficient at best and often downright misleading. 37Signals recently posted a terse but effective explanation on the importance of histograms. Here’s a second more detailed posting by Zed Shaw authored in his inimitable and entertaining style.

Full source code and a detailed README can be found on the project homepage and the gem is available on gemcutter.org. But just to whet your appetite, here’s a quick example:

require 'rubygems'
      require 'aggregate'
      
      # Create an Aggregate instance
      binary_aggregate = Aggregate.new
      linear_aggregate = Aggregate.new(0, 65536, 8192)
      
      65536.times do
        x = rand(65536)
        binary_aggregate >> x
        linear_aggregate >> x
      end
      
      puts "\n** Binary Histogram **\n%s" % [binary_aggregate.to_s]
      puts "\n** Linear Histogram **\n%s" % [linear_aggregate.to_s]

And the resulting output:

macbook:aggregate(master) jruscio$ ruby ./aggregate_example.rb 
      
      ** Binary Histogram **
      value |------------------------------------------------------------------| count
          1 |                                                                  |     1
          2 |                                                                  |     1
          4 |                                                                  |     2
          8 |                                                                  |    10
         16 |                                                                  |    24
         32 |                                                                  |    33
         64 |                                                                  |    71
        128 |                                                                  |   121
        256 |                                                                  |   258
        512 |@                                                                 |   497
       1024 |@@                                                                |  1061
       2048 |@@@@                                                              |  2004
       4096 |@@@@@@@@                                                          |  4186
       8192 |@@@@@@@@@@@@@@@@                                                  |  8257
      16384 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@                                 | 16345
      32768 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| 32665
        ~
      Total |------------------------------------------------------------------| 65536
      
      ** Linear Histogram **
      value |------------------------------------------------------------------| count
          0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ |  8269
       8192 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ |  8257
      16384 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ |  8302
      24576 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@   |  8043
      32768 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ |  8273
      40960 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@   |  8052
      49152 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|  8315
      57344 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@   |  8025
      Total |------------------------------------------------------------------| 65536

Feedback welcome and enjoy!

Installing git on CentOS 5.2

2009-07-29T00:00:00-07:00

CentOS for all intents and purposes is a community supported clone of Red Hat Enterprise Linux (RHEL). If you want to run RHEL without paying for support, CentOS is as good as it gets. One of the hallmarks of Enterprise Linux distributions is their rock-steady stability i.e. they only run really boring, old software. This risk-aversion has a downside in restricted access to the latest and greatest packages and tools. Case in point, since Red Hat released RHEL 5.0 in March 2007, Git has really matured from its origins as a custom kernel development tool into a version control world-beater. Unfortunately the base CentOS 5.2 repositories don’t appear to contain rpms for git. Or at least the CentOS 5.2 AMI I’m using (ami-e300e68a) doesn’t:

-bash-3.2# yum install git
      Loading "fastestmirror" plugin
      Loading mirror speeds from cached hostfile
      ... [snip] ...
      No package git available.
      Nothing to do

Not to fear, RPMforge maintains an RPM repository for CentOS full of goodies, including git (1.5.x as of this writing). The CentOS Wiki provides detailed instructions on configuring RPMforge access, but here’s the rapid-fire how-to.

Install priorities to avoid conflicts between packages in RPMforge and the Base CentOS repositories:

-bash-3.2# yum install yum-priorities
      ... [snip] ...
      Installed: yum-priorities.noarch 0:1.1.16-13.el5.centos
      Complete!

To configure priorities first edit /etc/yum.repos.d/CentOS-Base.repo and add a priority=N line to each entry. For [base], [updates], [addons], and [extras] set N to 1. For [centosplus] set N to 2. Also edit /etc/yum.repos.d/rpmforge.repo and for [rpmforge] set N > 2. (I chose 4 because its the next power of 2, and that’s how I roll).

Verify our access to RPMforge with a check-update:

-bash-3.2# yum check-update |grep forge
      * rpmforge: ftp-stud.fht-esslingen.de
      ... [snip] ...

Finally install git:

-bash-3.2# yum install git
      ... [snip] ...
      Complete!

Enjoy the tasty DVCS goodness!

KVM on Fedora 11 QuickStart Guide

2009-07-28T00:00:00-07:00

With the upcoming release of RHEL 5.4, Red Hat officially enters the virtualization fray with a KVM-based solution. Although KVM is exciting for several reasons, e.g. it’s free, fully supported by the Linux kernel community, doesn’t require any special hardware past the increasingly common Intel-VT or AMD-V extensions, etc, its also represents the next stage of virtualization evolution.

I’ll expound in a future post about how and why (admittedly with the benefit of hindsight) KVM represents a far more elegant model for virtualization, but after the jump today you’ll find a minimal set of instructions to rapidly get a Debian Lenny virtual guest up and running on a fresh out-of-the-box Fedora 11 server installation.

Lengthy instructions on Fedora virtualization suitable for KVM and/or Xen can be found at the Fedora wiki The following lists the minimal set of steps to get a guest running focusing soley on KVM to the exclusion of Xen.

Our setup comprises a freshly installed remote Fedora 11 server serving as the KVM target (bash prompt server) and a local Fedora 11 laptop (bash prompt laptop).

First we’ll shell into the remote server to install and configure all the necessary KVM software. Verify we’re using Fedora 11 with a Intel-VT or AMD-V processor:

[root@server ~]# uname -a && egrep '(vmx|svm)' /proc/cpuinfo | wc -l
      Linux server 2.6.29.4-167.fc11.x86_64 #1 SMP Wed May 27 17:27:08 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
      4

This server is running the modified 2.6.29 Linux kernel that comes stock with Fedora Core 11. It possesses 4 processing cores enabled with Intel-VT. Installing the basic tools required for KVM is our first task, luckily Fedora provides a convenient meta-package:

[root@server ~]# yum groupinstall 'Virtualization'

Alongside kvm/qemu, the Virtualization group also includes the libvirt toolset. Libvirt provides a common abstraction across several types of hypervisors. This abstraction includes simplified installation and remote graphical console access a la $VMW’s VirtualCenter. To access these features we must start the libvirtd daemon.

[root@server ~]# /etc/init.d/libvirtd start
      Starting libvirtd daemon:                                  [  OK  ]

Using the virsh command line tool, verify the currently guestless system is running and ready to accept commands:

[root@server ~]# virsh -c qemu:///system list
      Id Name                 State
      ----------------------------------

Now we’re ready to install our guest. We’ll need to download an ISO image to install our virtual machine. To keep things simple we’ll go with Debian Stable aka Lenny (as of this writing). We’ll create a top-level directory to store both the ISO image and the virtual machine disk image:

[root@server ~]# mkdir /kvm && cd /kvm
      [root@server kvm]# wget http://cdimage.debian.org/debian-cd/5.0.2/amd64/iso-cd/debian-502-amd64-netinst.iso
      ...
      [snip]
      ...
      Saving to: `debian-502-amd64-netinst.iso.1'
      100%[==================================================================================================>] 137,713,664 1.49M/s in 93s
      2009-07-27 19:10:24 (1.56 MB/s) - `debian-502-amd64-netinst.iso' saved [137713664/137713664]

Now armed with the KVM/libvirt tools and an ISO image for installation, we issue a single virt-install command to a) create a backing disk image and b) boot a newly created virtual guest off of the ISO:

root@server kvm]# virt-install --connect qemu:///system -n lenny0 \
      > -r 512 --disk path=/kvm/lenny0.qcow2,size=16 \
      > -c /kvm/debian-502-amd64-netinst.iso --noautoconsole --os-type linux \
      > --os-variant debianlenny --accelerate --hvm
      
      Starting install...
      Creating storage file...  |  16 GB     00:00
      Creating domain...        |    0 B     00:01
      Domain installation still in progress. You can reconnect to the console to complete the installation process.

The “domain” referred to in virt-install’s output is our new guest. We’ve created a single-core virtual server named lenny0 with 512 MB of RAM and a 16GB virtual disk housed on server at /kvm/lenny0.qcow2. Furthermore, lenny0 has been booted off of our Debian net-install ISO image.

Now we can use the graphical virt-manager tool locally from our laptop to connect to the virtual server’s graphical console (basically VNC) and kick off the Debian net-install process. In theory we should be able to run virt-manager locally on our laptop and connect over ssh to the libvirtd daemon on the remote server. In practice it’s still pretty shaky and has some onerous requirements. Notably that there’s no progress indicator informing how much longer remains before the connection initializes (and it takes a long time). So if you want to try it out, good luck, YMMV (hopefully someone at $RHAT puts some polish on this aspect soon).

I’ve personally chosen to avoid the whole debacle and just run virt-manager on the remote server and use X Forwarding over ssh to interact with it from the laptop. It’s slow, but sufficient for Debian’s curses-based installer (I actually did this across the continental US).

fedora:lm jruscio$ ssh -X root@server 'virt-manager' &
      [1] 20038

The virt-manager tool should show a single VM, lenny0, running on server. Double-clicking on the lenny0 entry brings up the VNC console, that should show the Debian net-install splash screen. Start the installation and for the most part select all the defaults (I removed Desktop from the additional packages).

After the installer finishes it leaves the machine in a halted state. Boot the machine with the Run button above the VNC console and log in as root. As a final step install ssh and use ifconfig to determine the IP address DHCP granted the virtual server:

lenny0:~# apt-get install ssh
      [snip]
      lenny0:~# ifconfig eth0 |grep inet
            inet addr:192.168.122.99  Bcast:192.168.122.255  Mask:255.255.255.0
            inet6 addr: fe80::5652:ff:fe46:6f93/64 Scope:Link

That was pretty easy and we’re now able to shell into our virtual guest from the physical server hosting it!:

server:~ jruscio$ ssh 192.168.122.99
      jruscio@192.168.122.99's password:
      Linux lenny0 2.6.26-2-amd64 #1 SMP Sun Jun 21 04:47:08 UTC 2009 x86_64

Securing your online identity

2009-07-16T00:00:00-07:00

This week a widely publicized security breach occurred at media darling Twitter. The cracker made off with a slew of internal company documents, most of which are now easily located at your technology news site of choice. It’s somewhat of a tempest in a teapot, given that most of the secret documents reveal such salacious details such as Twitter’s desire to make money and grow. Shocking, I know.

What should should concern the average net denizen (you, me, etc), is the attack vector used to compromise Twitter. In a similar fashion to what befell Sarah Palin during the last election, the cracker managed to compromise a personal web-based email account of a handful of Twitter employees or their family (Gmail in this case, Yahoo for Sarah Palin). After gaining access to Gmail accounts, the cracker was able to both access other online accounts, any attached documents, or Google Docs repositories.

You see, almost any website you log into will gladly email you everything you need to access your account through a simple click of the “Forgot my password” button. So even assuming you have a unique, strong password set on every account (and lets be honest, you don’t), once a cracker gains access to your favorite email account, its game over.

And what industrial strength security mechanism do email providers use to protect your online achilles heel? Some simple question that’s ridiculously susceptible to attacks. (What’s your mother’s maiden name? What town did you go to high school in? What kind of car do you drive?) So while IANASE (I Am Not A Security Expert), and you need to take responsibility for securing your identity online, there are a few simple things you can do to drastically increase your safety.

Even if you’re not going to use a unique, random password for each account (and you should), at least secure your online email accounts or any Single Sign-on (e.g. OpenID) with a unique, random password. Furthermore, if you have the opportunity to select your own security question (Gmail at least permits this), you should use a question along the lines of “What is the answer to my security question?” and supply as that answer a highly-randomized, secure password that you record and store somewhere safe. FYI, a post-it note affixed to your monitor is not such a safe location. Alternatively you could just answer one of the silly questions with your random password.

(For those looking for more ubiquitous protection, 1Password is a highly-touted, secure password manager that seamlessly integrates with your web-browser to maintain a full set of unique, bulletproof passwords.)

printf(“Hello World!\n”);

2009-07-15T00:00:00-07:00

Welcome to my blog. I’m only about 10 years behind the times, but better late than never I suppose. In my defense, the need for a place for musings and information too long for Twitter (@josephruscio) served as the main motivator. Look in this space for intermittent postings on software development, computer science, startupping, marathon training, food/drink, or whatever other shiny object has my attention.