I’m using SSH for many years, but I never really had to look up the fingerprint of a (public) SSH key, and by searching the web I just found the solution:

ssh-keygen -lf filename-of-rsa.pub

(First char is a lowercase L, directly followed by lowercase F)

That easy.

NEIN! Wir haben keinen Urlaub gemacht. Aber irgendwie wollte der Server am vergangenen Freitag nicht mehr so wie wir es sonst gewohnt waren. Angefangen mit sehr hohen Delay hat es im Bereich Mail Virtualisierung. Den Host hat es kurz darauf mit gezogen, eine Load jenseits von gut und böse. Letztendlich half nur ein Reboot per serieller Konsole.

Während des Reboots schien alles soweit in Ordnung. Wie nach jedem Reboot eben noch ein paar Updates installiert. Dann noch eben das Crypto mounten und dann eben das Startscript anstoßen.
Soweit der Plan.
Die Gegenwart hat uns aber eingeholt, das Crypto Device wollte nicht mehr…-v not available…es lies sich nicht mounten, zwar war cryptsetup der Meinung das Device eingebunden zu haben, jedoch konnte es nicht gemountet werden. “Grausame” 48h folgten, der Raid1 hat sich synchronisiert und ein Deepscan nach superblöcken für das FS Recovery standen an. Ja die Sonne hat draußen auch geschien, so hat man mir berichtet….aber wenn man einmal dran ist, kann man sich auch nur sehr schwer wieder trennen und schon gar nicht mit dem Gedanken vertraut machen, daß der Fall eintritt den man NIE haben möchte, Datenverlust.

Auch am Sonntag abend war die Lage nicht wesentlich entspannter…zwischenzeitlich kamen Pläne auf eine 19″ 2HE Maschine startklar zu machen und bei free.de ins Rack zu schrauben.
Am Sonntag abend nach dem Tatort sah es nicht besser aus oder sagen wir, es sah genauso bescheiden aus wie auch in den letzten 48h….

Neuer Tag neues Glück und vor allem neue Gedanken!

Montag abend gegen 20:30 dann der erlösende Hinweis, man hat im hause Debian vor einiger Zeit anscheinend das crypt-mount Verfahrne/script wohl geändert, dem System war ein cryptsetup -y create crypto /dev/bla nicht mehr bekannt, aber das init Script im /etc/init.d/cryptdisks-early und der zugehörigen config im /etc/default liessich dann plötzlich das eine mit dem anderen verbinden.
Schnell noch das Passphrase eintippen und *zittern*warten* da war es…es lies sich sogar mounten…

Geschafft. Nach kurzem Check der Sachlage, gingen schon die ersten vServer wieder in Betrieb, angefangen mit dem mx2.hackerlab.de gefolgt von diversen anderen.
Der primäre MailServer hatte noch seine Probleme.
Ein Problem mit dem LDAP, wie die Fehlermeldung verlauten lies…aber ohne nähere brauchbare Informationen.
Nach weiteren 24h kamen dann birdcage und mir (darkhawk) die Erleuchtung. Der LDAP lief im superduper debug mode…und spuckte jeden Müll aus den wir mit ihm machten, naja fast jeden…und dann stand da dieser Fehler mit dem SSL: bla…Exception …da war uns schnell klar, es liegt vermutlich ein Fehler im Bereich Zertifikat vor…UND dann kam es mir wie ein Geistesblitz…das Zertifikat ist abgelaufen….denn der Server läuft nun so ziemlich genau seit 2 Jahren….ein kurzer Check verriet das GESTERn Morgen gegen 11:42 das mail.hackerlab.de Zertifikat abgelaufen ist….

Nein, es war keine versteckte Kamera-Show….und Murphy hat auch nicht mit gearbeitet. Aber mal unter uns…das hat uns auf gut deutsch den Arsch gerettet und jede Menge Arbeit ersparrt.
Das Hackerlab Team hat sich in dieser Zeit (rund 84h ohne Mails) sehr tapfer geschlagen.
Jetzt wo alles wieder online ist, nutzt den UrlShortener mod4.cc
Danke an birdcage, jsilence, sinned, wall-e.

Dazu geht man in den Einstellungsdialog, wechselt auf die Account-Einstellungen und wählt dort unter “URL Kürzung” den Eintrag “Benutzerdefinierte…” ganz unten in der Liste. Als API Endpunkt gibt man folgendes an:

http://mod4.cc/api.php?url=%@

Dann noch den Eintrag mit einem Klick auf “Fertig” speichern, und schon werden die URLs über mod4.cc gekürzt.

Config file:
[codesyntax lang="python" lines="normal"]
[setup]
# Quota percentage above which a notification will be sent
breach_level=90

# Parameters of the account to check the quota for
imap_host=imap.host.tld

# Login with IMAPS
use_ssl=yes

# output on console?
verbose=yes

# Email address to send notifications to
send_address=user@domain.tld

# SMTP Parameters
smtp_host=smtp.host.tld
smtp_authentication = 0  # set to 1 if your SMTP server requires authentication, 0 if not
# Following used only when authentication is set to 1
smtp_user=username
smtp_pass=password

[accounts]
user1@domain.tld: imap1_password
user2@domain.tld: imap2_password

[/codesyntax]

Script:
[codesyntax lang="python" ]
#!/usr/bin/python

“”"
imapQuotaChecker.py 1.1
Last updated: May 27, 2011
Copyright (c) 2006 http://www.broobles.com/
Website: http://www.broobles.com/scripts/imapquotachecker/

Description:
===========
Checks the quota of an IMAP account and sends an email notification if the
specified quota warning level has been breached.

Usage:
=====
- Modify the IMAP and SMTP parameters in /etc/imapQuotaChecker.conf
- Upload the script and the config file into a non-public location on your webserver
- Create a cron job to invoke the script as often as you wish

History:
=======
1.1. (May 27, 2011, jsilence AT hackerlab DOT de):
- Read configuration and accounts from config file
- Can now check multiple IMAP accounts
- Verbose mode prints quota usage on console
1.0  (June 8, 2006):
- Initial Release

Licence:
=======
This script is free software; you can redistribute it and/or modify it under the terms of
the GNU Lesser General Public License as published by the Free Software Foundation;
either version 2.1 of the License, or (at your option) any later version.
Please visit http://www.gnu.org/copyleft/lesser.html for more information.

“”"

import imaplib, smtplib, re, ConfigParser
from email.Utils import formatdate

def main():
config = ConfigParser.RawConfigParser()
config.read(‘/etc/imapQuotaChecker.conf’)

breach_level=config.get(‘setup’,'breach_level’)
imap_host=config.get(‘setup’,'imap_host’)
use_ssl=config.getboolean(‘setup’, ‘use_ssl’)

verbose=config.getboolean(‘setup’,'verbose’)

send_address=config.get(‘setup’,'send_address’)

smtp_host=config.get(‘setup’,'smtp_host’)
smtp_authentication=config.get(‘setup’,'smtp_authentication’)
smtp_user=config.get(‘setup’,'smtp_user’)
smtp_pass=config.get(‘setup’,'smtp_pass’)

userlist=config.options(‘accounts’)

for imap_user in userlist:
# Error “command LOGIN illegal in state LOGOUT” if I create the imap
# object outside the for loop. Strange, but this works.
if use_ssl:
imap = imaplib.IMAP4_SSL(imap_host)
else:
imap = imaplib.IMAP4(imap_host)

imap_pswd=config.get(‘accounts’, imap_user)
imap.login(imap_user, imap_pswd)
quotaStr = imap.getquotaroot(“INBOX”) [1][1][0]
p = re.compile(‘\d+’)
r = p.findall(quotaStr)
fQuota = (float(r[0])/float(r[1])) * 100
if verbose:
print(“%s %4.2f%%” % (imap_user, fQuota))
if fQuota > breach_level:
emailNotification(fQuota)
imap.logout()

def emailNotification(quota):
“”" Email the notification “”"
# Form the message
headers =  “From: %s\r\n” % send_address
headers += “To: %s\r\n” % send_address
headers += “Date: %s\r\n” % formatdate()
headers += “Subject: IMAP Quota Check WARNING [%4.2f%%]\r\n” % quota
body = “Account %s” + ” on %s is above the warning limit, the quota is currently at %4.2f%%” % (imap_user, imap_host,quota)
fullMessage = headers + “\r\n” + body + “\r\n.\r\n”

# Send it
smtpsession = smtplib.SMTP(smtp_host)
try:
if smtp_authentication:
smtpsession.login(smtp_user,smtp_pass)
smtpresult = smtpsession.sendmail(“%s” % send_address, “%s” % send_address, fullMessage)
finally:
try: smtpsession.quit()
except: pass

if __name__ == ‘__main__’: main()

[/codesyntax]

Call the script from crontab.
Have fun!

RCS steht für “Revision Control System” und bietet eine lokale Versionsverwaltung für Dateien. Hierbei werden mehrere Versionen einer Datei archiviert.

Wofür ist RCS sinnvoll?

RCS kann für die Versionierung von Konfigurationsdateien, Dokumenten oder beliebigen anderen Dateien eingesetzt werden. Zwar können auch Binärdateien verarbeitet werden, aber seine Stärken spielt RCS bei textbasierten Dateien aus, wo ein Vergleich (Diff) zwischen verschiedenen Versionen möglich ist.

Terminologie

• Datei – eine beliebige Datei, bevorzugt im Textformat
• Revision – eine Version einer Datei
• Check-In – Vorgang des Archivierens einer Datei in RCS
• Check-Out – Wiederherstellen einer Datei aus RCS

Wie funktionierts?

1. Anlegen des Ordners RCS an der Stelle, an der Dateien versioniert werden sollen, falls ein solcher Ordner noch nicht existiert.
2. Check-In einer oder mehrerer Dateien zum Archivieren
3. Check-Out einer Datei zum Bearbeiten
4. Erneuter Check-In der bearbeiteten Datei

Die wichtigsten Befehle im Überblick

ci [filename]

Check-In der angegebenen Datei, entfernt die aktuelle Datei

ci -l [filename]

Check-In der angegebenen Datei, läßt weiteres Bearbeiten an der aktuellen Datei zu

ci -u [filename]

Check-In der angegebenen Datei, lockt die aktuelle Datei (Schreibschutz)

co [filename]

Check-Out der angegebenen Datei, lockt die aktuelle Datei (Schreibschutz)

co -l [filename]

Check-Out der angegebenen Datei, läßt Änderungen an der aktuellen Datei zu, lockt die letzte Revision für andere Benutzer

rcsdiff [filename]

Zeigt die Unterschiede zwischen der aktuellen Version und der zuletzt archivierten Datei an

rcsdiff -r[rev] [filename]

Zeigt die Unterschiede zwischen der aktuellen Version und der angegebenen Revision (z.B. 1.1) an

rcsmerge -r[rev] [filename]

Führt die Unterschiede zwischen der aktuellen Version und der angegebenen Revision zusammen, erzeugt gegebenenfalls einen Konflikt in der Datei, der mit

Was sonst noch?

Wenn ci zur Eingabe eines Kommentares auffordert, diesen angeben und mit einem Punkt in einer neuen Zeile quittieren.

Empfehlenswert: die Benutzung von “ci -l” und “co -l”, da das Ergebnis am ehesten dem entspricht, was man erwarten würde (Datei verschwindet nicht und ist editierbar).

Weitere Infos gibts in den man-pages von ci, co, rcsdiff sowie auf der RCS-Webseite http://www.cs.purdue.edu/homes/trinkle/RCS/

If you have a Virtualbox VM running headless and would like to attach the host DVD drive without having to boot into the Virtualbox GUI, use VBoxManage:

VBoxManage storageattach "VM-Name" --storagectl "IDE Controller" --port 1 --device 0 --type dvddrive --medium Host:/dev/cdrom


Port 1, device 0 ist secondary master. If you configured the DVD drive of the VM to be secondary slave, you’d have to use port 0, device 1.

The command line tool debootstrap allows you to install a Debian based Linux system while keeping running an already installed Linux system, which need not be from the Debian family.

So you can install a new system, while the current system is running.
Why would you want to do that?

• Maybe you installed a new hard disk in your server and want to move the OS to this disk with minimum downtime.
• Or you would like to dry run a critical update without risking to break your installed system. Therefore you clone your current system to a separate disk.
• Or maybe just because you can.

Training with Virtualbox

The reason why I went down this path was because I wanted to reconfigure the four disks in one of our servers into a different RAID configuration. But before laying my hands on our real server, I examined the whole procedure with a Debian Squeeze virtual machine on Virtualbox. The different aha! effects on the way made me write this article.

I generated a new disk image and attached it to the VM, partitioned it with one primary  partition (/dev/sdb1) for the root system and a logical partition (/dev/sdb5) for swap. So my virtual machine had two disks with four partitions: /dev/sda1, /dev/sda5, /dev/sdb1, /deb/sdb5. First steps are to install the disk, partition and format it and to turn on swap. Then mount the new disk to a mountpoint. /mnt/debinst for example.

[codesyntax lang="bash" lines="normal"]

hostname:~# mount
/dev/sda1 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
hostname:~#

hostname:~# ls /dev/disk/by-uuid
insgesamt 0
lrwxrwxrwx 1 root root 10 15. Nov 2010  4051fed5-17fe-493c-af96-cc3df5cd6229 -> ../../sdb1
lrwxrwxrwx 1 root root 10 15. Nov 2010  409a1d6b-a668-4b96-9ae9-22975e5debb4 -> ../../sda1
lrwxrwxrwx 1 root root 10 15. Nov 2010  6dc8fa2f-744c-47a9-b64f-05e8c9c318c2 -> ../../sda5
lrwxrwxrwx 1 root root 10 15. Nov 2010  8eaf21d0-c7b4-45cf-9e59-35187eac7939 -> ../../sdb5
hostname:~#

hostname:~# mkfs.ext4 /dev/sdb1
mke2fs 1.41.12 (17-May-2010)

[ mkfs output ]

hostname:~# mkswap /dev/sdb5
hostname:~# sync; sync; sync
hostname:~# swapon /dev/sdb5

hostname:~# mkdir /mnt/debinst/
hostname:~# mount /dev/sdb1 /mnt/debinst
hostname:~#
[/codesyntax]

After that I installed debootstrap. On a Debian based system this can simply be done with aptitude or apt-get:

[codesyntax lang="bash" lines="normal"]
hostname:~#
hostname:~# aptitude install debootstrap
hostname:~#
[/codesyntax]

For other Linux derivates see the article mentioned above.

Using debootstrap to install a minimal system into a directory

debootstrap can download the required files directly from the net and will install a minimal Debian system into a directory. Substitute ARCH with the required architecture, choosing from alpha, amd64, arm, armel, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, or sparc. You can use a mirror that is closer to your location of course.

[codesyntax lang="bash" lines="normal"]
hostname:~#
hostname:~# debootstrap  –arch ARCH squeeze  /mnt/debinst http://ftp.de.debian.org/debian
hostname:~#
[/codesyntax]

After that I changerooted into the directory and continued configuring the new system.

[codesyntax lang="bash" lines="normal"]
hostname:~#
hostname:~# LANG=C chroot /mnt/debinst /bin/bash
hostname:~# <- Note that this probably looks
hostname:~# just like your normal root prompt
[/codesyntax]

To make it less likely to confuse the new system with the already running system I changed the prompt by editing my .bashrc in the chrooted system and exported PS1 with something I could easily recognize. I added the following lines which include one of my favourite bash magic snippets with the PWD function. This prompt always displays the last two directory levels, no matter how deep you are into the rabbit hole.

[codesyntax lang="bash" lines="normal"]

function PWD {
tmp=${PWD%/*/*};
[ ${#tmp} -gt 0 -a "$tmp" != "$PWD" ] &&
echo ${PWD:${#tmp}+1} || echo $PWD;
}

export PS1=”\[\033[0;31m\]CHROOTED:\[\033[0;31m\]\$(PWD 3)\[\033[0m\]::>~ “;

[/codesyntax]

Creating device nodes

Section D.3.4.1. of the cited article is a bit sparse on the topic. It recommends using MAKEDEV or leaving it to udev, but does not go into the details. For me there are two possibilities, a quick and dirty one and a cleaner solution which I prefer.
The problem is that you can not yet boot into the new system, upon which udev would populate your /dev section with the required device nodes. In order to easily install grub and stuff you need these devices now, without a reboot.

If you take the quick and dirty approach with MAKEDEV, the tool will complain that udev is obviously in use and will abort. You can trick MAKEDEV by temporarily moving /dev/.udev aside and moving it back later:

[codesyntax lang="bash" lines="normal"]

CHROOTED:~::>~ cd /dev
CHROOTED:/dev::>~ mv .udev .udev-begone
CHROOTED:/dev::>~ MAKEDEV generic
[lot of stuff happening]
CHROOTED:/dev::>~ mv .udev-begone .udev

[/codesyntax]

This way you will end up with a lot of static device nodes, old school style, while actually using the dynamic udev mechanism which is meant to generate the device nodes upon system startup. This will probably work fine, but might be a source for confusion and problems if you plan on using this system for a while.

A cleaner way is to get udev to generate the device nodes without a reboot. udev relies on information from sysfs and proc, so these have to be mounted first. Restarting the udev demon will populate the device section with some device nodes. If the disk nodes don’t show up, use the udevadm tool.

[codesyntax lang="bash" lines="normal"]
CHROOTED:/dev::>~ ls /sys/ # these two
CHROOTED:/dev::>~ ls /proc/ # come up empty
CHROOTED:/dev::>~ mount -t sysfs sysfs /sys
CHROOTED:/dev::>~ mount -t proc proc /proc
CHROOTED:/dev::>~ /etc/init.d/udev restart
CHROOTED:/dev::>~ ls /dev/disk
ls: cannot access /dev/disk: No such file or directory
CHROOTED:/dev::>~
CHROOTED:/dev::>~ udevadm test /sys/block/sda
[ lot of stuff rushes by ]
CHROOTED:/dev::>~ ls /dev/disk
by-id by-path
CHROOTED:/dev::>~ ls /dev/sda*
/dev/sda
CHROOTED:/dev::>~
CHROOTED:/dev::>~ udevadm trigger
CHROOTED:/dev::>~ ls /dev/sda*
brw-rw—- 1 root disk 8, 0 Nov 17 16:15 /dev/sda
brw-rw—- 1 root disk 8, 1 Nov 17 16:15 /dev/sda1
brw-rw—- 1 root disk 8, 2 Nov 17 16:15 /dev/sda2
brw-rw—- 1 root disk 8, 5 Nov 17 16:15 /dev/sda5
CHROOTED:/dev::>~
[ rinse and repeat for sdb ]
[/codesyntax]

If all this fails you can also simply copy the /dev/disk directory from the host to the chrooted environment.

[codesyntax lang="bash" lines="normal"]
hostname:~#
hostname:~# cd /dev; cp -a disk /mnt/debinst/dev
hostname:~#
[/codesyntax]

Follow the original article

Editing the fstab as well as reconfiguring tzdata, locales and console-data and all the other steps described in the original article worked just fine.
Copy /etc/network/interfaces and any other required configuration file to the new system. Or take a peek and follow the “migrating data” section of this article.

Install a kernel

As described in the original article.

If you are already running a Debian based system you can easily recreate all the packages you have installed in the new system. This will of course include a kernel and grub.

Debian allows to save the installed package list and the package configurations to a file and to install and configure the packages from this list, allowing you to clone whatever software packages you have installed.
The tools are aptitude-create-state-bundle and
aptitude-run-state-bundle.

Create the package and configuration state on the running host:

[codesyntax lang="bash" lines="normal"]
hostname:~#
hostname:~# aptitude-create-state-bundle /mnt/debinst/var/backups/aptitude_state
hostname:~#
[/codesyntax]

By using this file the packages can be reproduced in the chrooted system.
The packages file and bzip2 need to be pre-installed for the restore.

[codesyntax lang="bash" lines="normal"]
CHROOTED:~::>~
CHROOTED:~::>~ aptitude install file bzip2
[ aptitude does its job ]
CHROOTED:~::>~ aptitude-run-state-bundle /var/backups/aptitude_state
CHROOTED:~::>~ aptitude update
CHROOTED:~::>~ aptitude install
[ stuff rushes by and configuration panels pop up. for example the grub config ]
CHROOTED:~::>~
[/codesyntax]

Note that it is not easily possible to sort of upgrade your operating system on the fly like this. Taking the package state and replaying it on the fresh system will only work when your are on the same major release. If you host is on Lenny and your fresh system on Squeeze, then aptitude-run-state will choke a lot an will eventually abort, leaving you with a mess.

If you wish to transfer your packages with this method, it is recommended to install the same major release with debootstrap, transfer the package state and perform a dist-upgrade after that.

BTW, a nice overview over the apt and dpkg system state files can be found here.

If your curently running system is not Debian based, you’ll have to find a way to recreate your packages. YMMV.

Installing grub

The last step also installed the grub package and came up with a configuration panel. It was not be able to completely determine the disk devices and asked where grub should be installed. I installed grub onto /dev/sdb.

It is a good idea to check /boot/grub/grub.cfg and take a close look at the disk IDs that are used, since you might be swapping the hard drives or changing the RAID configuration, resulting in a change of the sda and sbd naming schema. UUIDs will stay the same, no matter whether the disk is primary master oder secondary slave. Using UUIDs reduces confusion.

If you find any occurrance of /dev/sda or /dev/sdb, you might want to change that into the respective UUIDs. Note that grub.cfg is being generated by update-grub, so your changes will be lost. But that is okay, since everything should be fine with the disk device symlinks by udev once you boot into the new system.

If you want to keep the current disk, but would like to boot from the fresh system, you can run update-grub on the host. It will recognize the new system on the fresh disk and will generate a grub entry for this system as well. Again, check whether UUIDs are being used in /boot/grub/grub.cfg and correct if neccessary.

Migrating data

This step obviously depends a lot on what software you have installed and how this data needs to be transferred. Using rsync -avR might be a good idea. Good candidates for directories that should be copied are /home, /var/www, /var/mail, /var/spool, /srv, /etc, /usr/local/bin, but as said, this really depends on what you have installed on your machine. Be aware that trailing slashes are significant with rsync and that rsync -avR /sourcedir /targetdir is different from rsync -avR /sourcedir/ /targetdir. Also when telling rsync to do deletes on the target it is recommended to --dry-run and check whether it is doing the right thing.

I have the habit of versioning my config files with rcs. The Revision Control System is pretty simple and only works locally on single files. No remote distributed mumbo jumbo. Simply mkdir a RCS directory and ci -l file.conf to make a revision. I am using two scripts to manage my versioned files and to make backups of those.

If you copy the backup over to the chrooted directory /mnt/debinst/var/backups/rcs and unpack into your chrooted system, you can easily recall your configurations and settings.

If you do not migrate the user accounts and leave /etc/passwd the way debootstrap set it up, then you should set the root password of your chrooted system, otherwise you will not be able to log into the new system.

Reboot

Before the first reboot into the new system it might be a good idea to deactivate certain services. For example if you are using fetchmail, I would deactivate that via /etc/defaults/fetchmail.

Just in case.
“In case of what?”, you ask?
JUST IN CASE!

Chances are you forgot something or some stupid error makes you want to repeat the whole procedure from scratch. If your system processed some real life data after the first experimental boot, you might have a tough time repairing this.
The reason why you chose debootstrap over the default debian installer was the required uptime of a real life system, right?
Be careful. Think twice. Don’t hurry.

Now it is time to reboot into your fresh and shiny new system. If you kept the old disk, you should select the additional grub entry the update-grub script entered into your grub.cfg. Carefully watch the boot process for failures. These are pointers to chunks of data and configurations which have not been migrated correctly.

I deliberately swapped the two disk images from primary slave to primary master and vice versa simply to make sure the grub installation on the new system really works (compare with above):

[codesyntax lang="bash" lines="normal"]
CHROOTED:~::>~ ls -l /dev/disk/by-uuid/
insgesamt 0
lrwxrwxrwx 1 root root 10 18. Nov 2010 409a1d6b-a668-4b96-9ae9-22975e5debb4 -> ../../sdb1
lrwxrwxrwx 1 root root 10 18. Nov 2010 6dc8fa2f-744c-47a9-b64f-05e8c9c318c2 -> ../../sdb5
lrwxrwxrwx 1 root root 10 18. Nov 2010 8eaf21d0-c7b4-45cf-9e59-35187eac7939 -> ../../sda5
lrwxrwxrwx 1 root root 10 18. Nov 2010 a246d75a-d8e4-41c7-984c-0e4d3bead43f -> ../../sda1
CHROOTED:~::>~
[/codesyntax]

Cleanup

After the new system is running, it is a good idea to invoke aptitude update and aptitude safe-upgrade to make the APCI work.

If neccessary, mount the old disk read only and copy the files and data you were missing.

Copy the root directory, change the hostname and your prompt, cleanup.

[codesyntax lang="bash" lines="normal"]
CHROOTED:~::>~ mkdir /mnt/oldsystem
CHROOTED:~::>~ mount -o ro /dev/sdb1 /mnt/oldsystem
CHROOTED:~::>~
[/codesyntax]

Comments, corrections and additions are welcome.

Wobei “Anstrich” in aller Bescheidenheit stark untertrieben ist. Bis auf das Datenbank-Schema, das aus Gründen der Abwärtskompatibilität von urlShort stammt, ist alles durch eine in PHP realisierte Eigenentwicklung ersetzt worden. Neben der API-Kompatibilität zu urlShort gibt es natürlich zahlreiche innere und äußere Erweiterungen.

So ist z.B. die Implementierung objektorientiert umgesetzt werden. Dies schafft mehr Möglichkeiten für zukünftige Anpassungen. Zudem ist über die API nun möglich, die “Lang-URL” in verschiedenen Ausgabeformaten wie JSON und XML zu bekommen, was die Integration in eigene Projekte erleichtert. Und als kleines Schmankerl kann man sich sogar einen QR-Code für die Short URL generieren lassen. Für die Vorsichtigen gibt es zudem eine Preview-Funktion, über die die “Lang-URL” zuerst angesehen werden kann, wenn man eine Short URL aufruft.

Eine Übersicht über alle Features findet Ihr direkt auf der URL Short Webseite http://mod4.cc/

Alle, die sich für den Quellcode interessieren, mögen sich noch ein bisschen gedulden, da das Ganze immer noch in einer Testphase ist, und evaluiert wird, ob und wie eine Veröffentlichung der Quelltexte machbar ist.