Setting up an APT Repository
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 <PACKAGE>_<VERSION>_<ARCH> 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
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!
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
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
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
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”);
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.