Archiv ‘Linux’

Mittwoch, 25. Mai 2011

Mein neuer PGP-Schlüssel

Link zu diesem Artikel

… lautet neu 2D1F94A8.

Als ich im Sommer 2007 meine Teilzeitanstellung bei der Liip AG antrat, war eine der ersten Aufgaben, einen PGP-Schlüssel zu erstellen.

Ich habe damals den Anfängerfehler begannen, für jede meiner E-Mail-Adressen ein neues Private/Public-Schlüsselpaar zu erstellen. Dieses Problem habe ich heute nun endlich behoben und alle meine E-Mail-Adressen mit einem einzigen universalen Schlüssel ausgestattet und die alten deaktiviert.

Bestehende Schlüssel löschen

Einmal in den Umlauf gebrachte öffentliche PGP-Schlüssel lassen sich nicht mehr löschen. Stattdessen muss der Besitzer diese mittels „revoke“ unbrauchbar machen.

Hierzu war es von Vorteil, dass ich im 2007 bereits bei der Erstellung der Schlüssel mittels gpg --gen-revoke 4A7347BE entschlessende Revoke-Zertifikate erstellt hatte. Diese konnte ich nun endlich einsetzen:

$ gpg --import revocation-4A7347BE.txt
$ gpg --send-keys 4A7347BE

Neue Schlüssel erstellen

Dies geschieht mit grosser Hilfe des GnuPG-Tools ganz einfach mit folgendem Befehl:

$ gpg --gen-key

Als nächstes erstellt man das Revoke-Zertifikat:

$ gpg --gen-revoke 2D1F94A8

Und nun endlich fügt man dem neuen Schlüssel weitere E-Mail-Adressen hinzu:

$ gpg --edit-key 2D1F94A8
> adduid

Sobald man alle E-Mail-Adressen erfasst hat, schickt man den öffentlichen Schlüssel an einen PGP-Keyserver:

gpg --send-keys 2D1F94A8

Um zu überprüfen, dass der Schlüssel beim Server angekommen ist und von anderen Benutzern gefunden werden kann, kann man diesen mittels einer Web-Oberflache abfragen:

pgp.mit.edu

Sonstige nützliche Befehle

Schlüssel vom Server abrufen und lokal speichern:

$ gpg --recv-keys DDB43876

Schlüssel für eine von mehreren E-Mailadresse ungültig machen:

$ gpg --edit-key 2D1F94A8
> uid 2
> revuid
$ gpg --send-keys 2D1F94A8

GUI-Tools für Mac OS X

Mittlerweile existiert für Mac OS X 10.6 ein Software-Paket, dass das Betriebsystem mit allen nötigen (GUI-)Tools ausstattet, die man so benötigt:

GPGTools

Da ich auf einem Rechner noch Mac OS X 10.5 einsetze, musste ich für das dort installierte Apple Mail eine ältere Version des MailBundle installieren.

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 21. Mai 2011

Kodierung von Windows-Dateinamen unter Linux anpassen

Link zu diesem Artikel

Heute hiess es ernst: Auf einem meiner Teilzeitstellen wurde der Dateiserver migriert: Die Nutzerdaten wurden von einem uralten Dell-Server auf einen neueren HP-Server kopiert. Auf der Dell-Kiste lief Samba 2.2, auf dem HP-Server Samba 3.2.

Wie es die Samba-Konfiguration des alten Server so wollte, waren alle Datei- und Ordnernamen mit der Windows-Codepage 850 abgelegt. Erst seit Version 3 legt Samba Dateien intern mit UTF-8-Kodierung ab (falls nicht anders eingestellt).

Zehntausende von Dateien von Hand umzubenennen wäre hirnverrückt gewesen — doch wofür gibt es das Tool convmv?

Installation

Nachdem der Quelltext heruntergeladen worden war, konnte ich das Tool folgendermassen installieren:

# wget "http://www.j3e.de/linux/convmv/convmv-1.14.tar.gz"
# tar xvzf convmv-1.14.tar.gz
# cd convmv-1.14
# make
# make install

Anwendung

Anschliessend startete ich das Tool unter /home/public:

# convmv -f cp850 -t utf8 -r .

Nachdem ich mich an Hand der Testausgabe abgesichert hatte, dass die Sonderzeichen in den Dateinamen tatsächlich korrekt nach UTF-8 übertragen wurden, führte ich den Befehl noch einmal aus — doch dieses Mal wurden die Dateinamen auch wirklich angepasst:

# convmv -f cp850 -t utf8 -r --notest .

Tags: , , , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Mittwoch, 18. Mai 2011

LDAP-Authentifizierung unter Apache funktioniert nach dem Upgrade auf Debian Squeeze nicht mehr

Link zu diesem Artikel

Heute entschloss ich mich, einen unserer produktiven Web-Server von Debian Lenny nach Squeeze zu migrieren, das seit März 2011 stabile Release 6 der Debian GNU/Linux-Distribution. Wie erwartet klappte beim Upgrade vorerst nicht alles wie am Schnürchen — doch schlussendlich obsiegte meine Wagemutigkeit.

Symptom

Eines der grössten Probleme war, dass die unter Apache 2.2.16 gegen LDAP authentifizieren beschriebene Authentifizierung gegen einen LDAP-Server nicht mehr funktionierte. Der Web-Browser zeigte bei jedem Login-Versuch die Meldung „500 — Internal Server Error“ an, ohne dass im Apache error.log irgendwelche Meldungen aufgeführt wurden.

Apache die exakte Fehlermeldung entlocken

Als erstes hiess es deshalb, in /etc/apache2/apache2.conf den LogLevel heraufzusetzen:

...
#LogLevel warn
LogLevel debug
...

Nach einem erneuten Login-Versuch fanden sich nun erleuchtende Einträge im Apache error.log:

...
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(982): [24124] auth_ldap url parse: `ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)', Host: ldap.domain.tld, Port: 636, DN: o=company,c=ch, attrib: uid, scope: subtree, filter: (gidNumber=1160), connection mode: using SSL
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [info] [client 192.168.1.2] [24124] auth_ldap authenticate: user maeby authentication failed; URI /admin [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server]
...

Das Kernproblem

Eine Google-Suche führte mich auf die richtige Spur:

To reenable my running lenny configuration in squeeze I had to add
LDAPTrustedGlobalCert.

Quelle: Bug#620398: Apache LDAP/S Authentication Causes

Offenbar fehlte dem Server nach dem Upgrade also ein GlobalCert, welches die Kommunikation mit dem LDAP-Server verschlüsselt. Wie konnte ich mir dieses beschaffen?

Wer bürgt für die Verschlüsselung?

Zuerst hiess es nun also, herauszufinden, mit welchem Zertifikat der IT-Dienstleister die Kommunikation verschlüsselte. Hierzu behalf ich mir mit folgendem Befehl:

$ openssl s_client -connect ldap.domain.tld:636 -showcerts
depth=2 /C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=CH/ST=Bern/L=Bern/O=Company/OU=Department - Security/CN=ldap.domain.tld
  i:/C=BM/O=QuoVadis Limited/OU=www.quovadisglobal.com/CN=QuoVadis Global SSL ICA
-----BEGIN CERTIFICATE-----
MIIFFjCCA/6gAwIBAgICKIcwDQYJKoZIhvcNAQEFBQAwazELMAkGA1UEBhMCQk0x
GTAXBgNVBAoTEFF1b1ZhZGlzIExpbWl0ZWQxHzAdBgNVBAsTFnd3dy5xdW92YWRp
...

Der Zertifikatsherausgeber war also QuoVadis, dessen QuoVadis Global SSL ICA von unserer IT-Abteilung zur Signierung der eigenen Verschlüsselungszertifikate verwendet wurde.

Gebt mir das Rootzertifikat!

Mit dieser Information bewaffnet konnte ich nun auf die Suche nach dem öffentlichen Zertifikat gehen. Jeder Zertifikatsanbieter bietet auf seiner Web-Site nämlich die firmeneigenen GlobalCerts zum Download an, so auch QuoVadis. Unter QuoVadis Root Download fand sich eine Liste, in welcher ich mich — aus offensichtlichen Gründen — für das QuoVadis Global SSL ICA entschied.

Installation des Zertifikats auf dem Server

Dieses Zertifikat kopierte ich von der Web-Site und fügte es auf dem Server in die Datei /etc/ldap/certs/qv_root.pem ein (Gratistipp: vim ist mit :set paste auf die Kopieraktion vorzubereiten).

Anschliessend musste ich noch /etc/apache2/mods-enabled/ldap.conf mit folgender Zeile ergänzen:

...
LDAPTrustedGlobalCert CA_BASE64 /etc/ldap/cacerts/qv_root.pem
...

Nach einem Neustart von Apache (/etc/init.d/apache2 restart) klappte der Login schlussendlich wieder.

Tags: , , ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Mittwoch, 23. Februar 2011

Ruby on Rails 3 unter Debian GNU/Linux installieren

Link zu diesem Artikel

Aus gegebenem Anlass habe ich mich heute Morgen das erste Mal seit langem wieder mit dem Web-Framework Ruby on Rails aus der Küche von David Heinemeier Hansson (einer der Partner hinter 37signals) auseinandergesetzt.

Nachfolgend habe ich zusammengefasst, wie ich das Framework auf meinem heimischen Entwicklungsserver zum Laufen gekriegt habe.

Installation Ruby

(Ich folge der englischen Anleitung Debian Lenny – Ruby on Rails von SliceHost)

Zuerst lädt man Debian-Pakete herunter und installiert diese:

# apt-get install ruby-dev ruby ri rdoc irb libreadline-ruby libruby libopenssl-ruby sqlite3 libsqlite3-ruby libsqlite-dev libsqlite3-dev

Anschliessend lädt man die Quellen von RubyGems herunter und kompiliert diese (man sollte auf das vorkompilierte Debian-Paket verzichten weil es mit Version 1.2.0 unglaublich veraltet ist):

# cd /tmp
# wget "http://rubyforge.org/frs/download.php/74234/rubygems-1.5.2.tgz"
# tar xvzfz rubygems-1.5.2.tgz
# cd rubygems-1.5.2
# ruby setup.rb

Nun noch die obligatorischen Update-Anweisungen, die man sich als Linux-Benutzer von vielen Paketmanagern kennt, und dann ist man bereit:

# gem update

Bei mir erhielt ich bei der Ausführung von gem update folgende Fehlermeldung zu Gesicht:

# gem -v
/usr/bin/gem:10: undefined method `manage_gems' for Gem:Module (NoMethodError)

Der Anleitung unter RubyGems: undefined method ‘manage_gems’ for Gem:Module (NoMethodError) – easy fix folgend wurde ein veraltetes Binary installiert, welches zuerst mit einer aktuellen Version ersetzt werden muss:

# mv /usr/bin/gem /usr/bin/gem-backup
# ln -s /usr/bin/gem1.8 /usr/bin/gem

Anschliessend aktualisiert man das System (nun hoffentlich erfolgreich):

# gem update
# gem update --system

Notabene: Bei mir wurden keine Updates nachgeladen, alles war bereits auf dem neuesten Stand …

Installation sqlite3

Damit Ruby mit der Datenbank sqlite3 sprechen kann, muss ein entsprechender Treiber bereitgestellt werden. Falls bei

# gem install sqlite3

die Fehlermeldung

Fetching: sqlite3-1.3.3.gem (100%)
Building native extensions.  This could take a while...
ERROR:  Error installing sqlite3:
	ERROR: Failed to build gem native extension.

        /usr/bin/ruby1.8 extconf.rb
extconf.rb:3:in `require': no such file to load -- mkmf (LoadError)
	from extconf.rb:3


Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/sqlite3-1.3.3 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/sqlite3-1.3.3/ext/sqlite3/gem_make.out

erscheint, hat man im obigen apt-get für die Grundinstallation vergessen, die Header-Pakete von Ruby zu installieren (via Stackoverflow). Dies holt man mit folgendem Befehl nach:

# apt-get install ruby-dev libsqlite3-dev

Installation MySQL-Treiber

Obwohl man Ruby (on Rails) natürlich auch mit sqlite3 benutzen könnte, ist der LAMP-Web-Entwickler primär mit MySQL vertraut — so kann diese Datenbank mit der ansprechenden GUI phpMyAdmin administriert werden und ist bei grösseren Datenmengen auch klar performanter als sqlite3.

Um den Treiber zu installieren, bemächtigt man sich folgender Debian-Pakete:

# apt-get install libmysql-ruby libmysqlclient-dev

Anschliessend ist

# gem install mysql

Problemlos möglich.

Installation Rails

Mit dem Ruby-Paketmanager gem kann man sich nun endlich Rails aus dem Netz herunterladen und installieren lassen:

# gem install rails

Fertig! Jetzt sollte man eine funktionierende Ruby on Rails-Installation auf dem Server liegen haben und man ist bereit, mit Bordmitteln das erste Projekt anzulegen. Wie dies genau vor sich geht, folgt in einem weiteren Artikel.

Tags: , , , , ,
Labels: Linux, Web

1 Kommentar | neuen Kommentar verfassen

Sonntag, 26. Dezember 2010

Netgear ReadyNAS Duo mit eigener FTP-Backuproutine sichern

Link zu diesem Artikel

Die Gründe hinter einem solchen Vorhaben können vielfältig sein — aber wer will es einem Linux-Hacker verübeln, wenn er sich des in einem ReadyNAS Duo werkelnde (aber völlig veraltete) Debian GNU/Linux‘ bemächtigen will?

Pakete nachinstallieren

Von der ReadyNAS-Web-Site lädt man sich zwei Binärpakete herunter, die mit der Installation über die Web-Oberfläche des Gerätes a) den Root-Zugang und b) apt-get nachrüsten:

Tipps

  • Falls die Download-Links nicht mehr funktionieren, schaut man am Besten unter Add-ons for RAIDiator 4.1.3+ nach. Klappt dieser Link auch nicht, hangelt man sich über die Web-Site via
    Support > Downloads > ReadyNAS Add-Ons > Add-ons for RAIDiator 4.1.3+
    durch.
  • Das Root-Passwort entspricht dem Administrator-Passwort, welches man zum Login auf der Web-Oberfläche verwendet.

lftp nachrüsten

Für das Backup der lokal auf dem NAS gespeicherten Daten auf einen entfernten FTP-Server habe ich mich für das Tool lftp entschieden:

# apt-get install lftp

Backup-Script einrichten

Damit man die Datensicherung automatisieren kann, sollte man unter /usr/local/bin/backup-emeidi.sh folgendes Script ablegen und gemäss seinen eigenem Gutdünken anpassen:

#!/bin/bash    

HOST="www.host.tld"
USER="user"
PASS="pass"
LCD="/c/"
RCD="/"

echo "---------------------------------------------------------------------"
echo "Backing up $LCD to $HOST/backup$RCD with user $USER"
echo "---------------------------------------------------------------------"
echo `date`
echo "---------------------------------------------------------------------"

lftp -c "
open ftp://$USER:$PASS@$HOST; 
lcd $LCD;
cd $RCD;
mirror --reverse \
       --verbose \
       --no-perms \
       --no-umask \
       --ignore-time"

echo "---------------------------------------------------------------------"
echo "Backup finished."
echo "---------------------------------------------------------------------"
echo `date`
echo "---------------------------------------------------------------------"
echo ""

exit 0

Die Variable LCD speichert das lokale Verzeichnis, die Variable RCD das entfernte (auf dem FTP-Server liegende) Verzeichnis.

Am Ende macht man das Script mittels folgendem Befehl ausführbar:

# chmod 755 /usr/local/bin/backup-emeidi.sh

Cron-Job einrichten

Damit das Script nun täglich einmal mitten in der Nacht ausgeführt wird, erstellt man sich unter /etc/cron.d/backup-emeidi einen entsprechenden Cron-Job:

...
0 1     * * *   root    /usr/local/bin/backup-emeidi.sh | mail -s "Backup ReadyNAS" -c syslog@server.tld syslog@customer.tld
...

Dieser Cron-Job wird täglich um 1 Uhr morgens gestartet und mailt das Ergebnis an syslog@customer.tld wie auch an syslog@server.tld. So kann der Sysadmin, wie auch der Kunde, täglich die Ergebnisse des Backuplaufes überprüfen.

Problem

Bei meinem Kunden werden lustigerweise gewisse Dateien in jeder Nacht gebackupt, obwohl diese nachweislich nicht verändert wurden. Ich vermute hier einen Bug in lftp.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 22. Dezember 2010

.bashrc wird beim Login nicht gelesen/ausgeführt

Link zu diesem Artikel

Da habe ich also all die nützlichen Anweisungen in meine ~/.bashrc eingefügt, damit beim Shellzugriff auf einen Linux-Server einerseits die Listings schön farbig ausgegeben werden, andererseits Nachfragen beim Löschen und Verschieben von Dateien erscheinen und so sicherstellen, dass ich aus Flüchtigkeit keine Dummheiten begehe:

...
export CLICOLOR=1
export LSCOLORS=DxGxcxdxCxegedabagacad
 
export LS_OPTIONS='--color=auto'
eval "`dircolors`"
alias ls='ls $LS_OPTIONS'
 
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'

Doch was ist los? Nach einem Login bleiben die Terminalfarben bei einem Listing eines Verzeichnisses … weiss auf schwarz!

Ein kurzer Test mittels

$ . ~/.bashrc

Quelle: Kurztipp: bash neustarten und .bashrc neu einlesen

zeigt dann aber rasch, dass die Farben wirklich erscheinen — wenn denn .bashrc auch beim Login geladen werden würde.

Ein Vergleich mit einem anderen, ordungsgemäss funktionierenden Debian GNU/Linux zeigt das Problem umgehend auf: Es fehlt die ~/.profile. Nachdem ich diese Datei erstellt und mit folgenden Zeilen gefüllt habe, funktioniert das Farbfernsehen per SSH dann auch ab dem ersten Login:

# ~/.profile: executed by Bourne-compatible login shells.

if [ -f ~/.bashrc ]; then
  . ~/.bashrc
fi

mesg n

Quelle: bashrc not getting read at login

Tags: , ,
Labels: IT, Linux

2 Kommentare | neuen Kommentar verfassen

Samstag, 11. Dezember 2010

realpath() des aktuellen Verzeichnisses in der Linux Shell

Link zu diesem Artikel

readlink -f .

Quelle: Bash equivalent for PHP realpath() | Andy Skelton

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 6. Dezember 2010

Debian Etch auf Lenny aktualisieren

Link zu diesem Artikel

Heute hatte ich es mit einer längst vergessen geglaubten Virtuellen Maschine zu tun, auf welcher noch ein Debian GNU/Linux mit einem 2.4er-Kernel installiert war. Im Grunde ging es nur darum, die aktuellsten VMware-Tools auf dieser Kiste zu installieren — doch wie immer zog dies umgehend einen riesigen Rattenschwanz an Debugging und sonstigen Upgrade-Arbeiten mit sich.

Nach etlichem Pröbeln und apt-get-Endlosschleifen hier die Kurzzusammenfassung, wie man Etch auf Lenny bringt:

sources.list

Zuerst einmal muss man Etch auf den letzten verfügbaren Stand aktualisieren. Da die Etch-Pakete von den Mirrors verschwunden sind, muss man alle vorhandenen Zeilen in der Datei /etc/apt/sources.list auskommentieren und folgende Zeilen einfügen:

deb http://archive.debian.org/debian-archive/debian/ etch main
deb-src http://archive.debian.org/debian-archive/debian/ etch main

Quelle: Debian (etch): sources.list

GPG

Natürlich funktioniert das apt-get update auf meiner Installation nicht sauber, weil mir einige PGP-Schlüssel fehlen. Da deren Fingerprint angegeben wird, kann ich diese ganz simpel mit folgendem Befehl mit meinem System bekannt machen:

# gpg --keyserver pgpkeys.mit.edu --recv-key  010908312D230C5F 
# gpg -a --export 010908312D230C5F | apt-key add -

Quelle: [Debian] Apt-get : NO_PUBKEY / GPG error

apt-get upgrade && dist-upgrade

Jetzt folgt das obligate

# apt-get update
# apt-get install apt aptitude
# apt-get upgrade
# apt-get dist-upgrade

um die neuesten Pakete zu installieren. Das System ist nun bereit, um auf einen neuen Kernel gehoben zu werden:

# apt-get install linux-image-2.6.18-6-686

Ist der Kernel installiert und GRUB angepasst (geschieht automatisch), sollte man den Server einmal neu starten (reboot).

sources.list

Frisch zurück im System mit Kernel 2.6, werden die oben hinzugefügten Zeilen nun wieder auskommentiert. Stattdessen fügt man nun folgende Repositories in /etc/apt/sources.list ein:

deb http://mirror.switch.ch/ftp/mirror/debian lenny main
deb-src http://mirror.switch.ch/ftp/mirror/debian lenny main

deb http://security.debian.org/ lenny/updates main

Quelle: Upgrading Debian Etch to Lenny stuck on kernel/libc issue

aptitude

ACHTUNG: Anstelle dieses kritische Kernel-Upgrade nun mit apt-get zu machen, hält man sich lieber an die Anweisungen der Debian-Maintainer und verwendet aptitude. Dieses kann viel besser mit Abhängigkeiten umgehen (Stichwort: libc6, dpkg (mit Breaks) etc.)

# aptitude update
# aptitude upgrade
# aptitude dist-upgrade

Quelle: Howto Upgrade Debian 4 Etch to Debian 5.0 Lenny

Dies bringt alle Pakete auf den neuesten Stand, die für das nun definitive dist-upgrade zwingend sind.

Kernel-Sourcen

Da die Kernel-Sourcen für Kernel 2.6.18 irgendwie nicht verfügbar sind, aktualisiert man kurzerhand auf Kernel 2.6.26:

# apt-get install linux-image-2.6.26-686
# reboot

Damit die VMware-Tools korrekt installiert werden können, lädt man sich nun auch noch die korrespondieren Quellen herunter:

# apt-get install linux-headers-`uname -r`

VMware-Tools

Anschliessend spielt man die VMware-Tools in gewohnter Manier ein. Fertig!

Tags:
Labels: IT, Linux

1 Kommentar | neuen Kommentar verfassen

Dienstag, 30. November 2010

Debian-Installation hängt mit 1% bei „Select and Install Software“

Link zu diesem Artikel

Heute konnte ich auf der Arbeit wieder einmal einen ausgemusterten PC mit Debian GNU/Linux versehen und zu einem Server (cups mit Samba inkl. Windows-Druckertreiber) umwandeln. Obwohl heuer, 2010, die Installation eines Linux-Betriebssystems kaum mehr grosse Mühe bereitet, fanden sich auch dieses Mal wieder Stolpersteine.

Konkret: Die Installation hing beim Aktualisieren der Pakete über den Internet-Mirror von SWITCH. Der Fortschrittsbalken im Dialog „Select and Install Software“ blieb bei 1% stecken und bewegte sich auch nach mehreren Minuten warten nicht weiter.

Nach etwas Googeln fand ich als erstes heraus, dass man mit Druck auf die Tasten Ctrl-Alt-F4 in die textbasierte Log-Ansicht der Installationsroutine schalten konnte. Dort stand etwas in der Form:

...
Nov 30 15:04:00 in-target:  To continue, enter "Yes"; to abort, enter "No"

Die Installation hing also, weil die Entwickler der Routine nicht vorhergesehen hatten, solche Eingabeaufforderungen automatisch mit „yes“ zu beantworten.

Als nächstes startete ich deshalb den Rechner neu, spielte die Installation durch, vermied es aber tunlichst, die Netzwerkkarte zu konfigurieren. So wurde die Internet-Aktualisierung zwar übersprungen und der Rechner bootete nach der Installation brav in die Shell — doch ich war danach aber schlichtweg nicht in der Lage, das Netzwerk zu laden (wahrscheinlich hätte ich das entsprechende Treibermodul laden müssen). Es trennt mich somit noch ein weiter Weg bis zum bombensicheren Linux-Admin.

Also hiess es ein weiteres Mal zurück zum Start. Dieses Mal initialisierte ich die Netzwerkkarte wieder von Beginn weg mit den benötigten Informationen. Als der Balken aber erneut hing, wechselte ich mittels Ctrl-Alt-F2 in ein interaktives Shell. Dort versuchte ich mich der brachialen Methode:

# ps ax | grep aptitude
 5760 ?        Ss     0:00 aptitude ...
# kill 5760

Der blockierte Prozess wurde so nullkommaplötzlich abgetötet. Mittels Ctrl-Alt-F1 ging es zurück in den Installationsbildschirm, wo mir eine rotgefärbte Fehlermeldung entgegenleuchtete und mir mitteilte, dass der wichtige Prozess verschwunden war.

Ich folgte den Anweisungen auf dem Bildschirm, drückte „Continue“, um die Installation trotz des Fehlers fortzusetzen und wählte aus der nun angebotenen Liste aus, dass nun der Bootloader grub in den MBR der Festplatte geschrieben werden sollte.

Die Installation lief durch, der Rechner startete neu — und sobald ich mich eingeloggt hatte, führte ich folgenden Befehl aus:

# apt-get update
...
# apt-get dist-upgrade

So hievte ich mein Debian GNU/Linux 5.0.6 auf 5.0.7 — und der Tag war gerettet.

Tags: ,
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Dienstag, 26. Oktober 2010

Darf ein Web-Entwickler seine geliebte Scripting-Sprache aufgeben?

Link zu diesem Artikel

How do you hire a programmer if you’re not one yourself? Some things to look for …

1. How opinionated are they?

Ask them about a juicy programming topic (e.g. Ruby or Python?). The tone and reasoning of the answer will reveal a lot. In our recent podcast on programming, Jeff said, “When people have strong opinions about things — when they can talk at length about something — it’s a good indication that they’re passionate about it.”

Quelle: How to hire a programmer when you’re not a programmer – (37signals)

Genau dies habe ich letzte Woche erlebt. Ich auf der Seite des Programmierers, auf der anderen Seite ein Headhunter, der für ein „internationales“ Unternehmen in Zürich einen Web-Entwickler suchte. Er war über Xing an meine Kontaktangaben gelangt.

Auf die Frage, ob ich Erfahrung in ASP.NET hätte, erwiderte ich ein klares Nein, um anzufügen, dass ich das letzte Mal im Jahr 2000 ASP programmiert hätte. ASP war damals mein erster Einstieg in webbasierte Scriptingsprachen. Innert weniger Monate wurde ich dann aber äusserst rasch auf die gute Seite der Macht gezogen — und entwickelte fortan auf den LAMP-Stack aufbauend.

Der Headhunter hakte nach: Ob ich es mir denn vorstellen könne, ASP.NET zu erlernen? Darauf erwirderte ich ein klares und dezidiertes „Nein“. Ich, der Mac OS X/Linux-Fan, der plötzlich in Visual Studio rumeiert? Das wäre wie wenn ein Kommunist zur SD überlaufen würde. Oder ein Wechselstromverfechter ins Camp der Gleichstromfreaks übertreten würde.

Ich habe mich noch ein/zwei Male gefragt, ob ich wirklich die richtige Antwort gegeben habe — doch mit obiger Bemerkung von Seiten der Web-Entwicklerprofis bin ich ein für allemal sicher, dass ich mich richtig entschieden habe.

Tags: , , , , , , ,
Labels: IT, Linux, Web

Keine Kommentare | neuen Kommentar verfassen

« Older Entries
Newer Entries »