by ·2 Kommentare

Gruselige Benutzeroberfläche

Gruselige Benutzeroberfläche

Vor einigen Jahren habe ich mal nach einer Möglichkeit gesucht, einen USB-Stick zu bauen mit dem man mehrere Boot-Images starten kann. Leider ohne Erfolg.

Ideal fände ich eine Lösung bei der ich nur noch ISO-Files auf den Stick legen muss, meinetwegen noch mit einem Skript das die ISOs dann beim Bootloader anmeldet. So etwas scheint es aber nicht zu geben, und das scheint mit den gängigen Bootloadern auch nicht ohne weiteres möglich zu sein.

Jetzt habe ich mir aber ein Programm angesehen das der Lösung zumindest nahe kommt: mit Multisystem kann man sich einen Stick erstellen von dem mehrere Systeme gebooted werden können.

Größter Haken beim Bau des individuellen Sticks ist dabei die Benutzeroberfläche. Von weitem sieht die zwar nett aus, damit zu arbeiten ist aber wirklich eine Herausforderung. Und damit meine ich nicht dass es eine steile Lernkurve gibt weil das Programm komplex ist, sondern schlicht weil die Oberfläche nichts taugt. Dass man die Größe der meisten Fenster nicht verändern kann ist dabei das kleinste Übel…

Das Ergebnis zählt

Das Ergebnis zählt

Aber mit einem kleinen HowTo — wie es sich zum Beispiel im Ubuntu-Wiki findet — kommt man doch zum Ziel. So habe ich jetzt einen kleinen aber stabilen 8GB-Stick (SanDisk Cruzer Pop) im Portemonnaie von dem ich wahlweise Ubuntu, einen Debian-Installer oder mein bevorzugtes ich-muss-was-machen-ohne-von-CD-zu-booten-System Grml starten kann. Letzteres wird nicht aktiv von Multisystem unterstützt, das hat erst Probleme gemacht: die 96-Bit-Variante (ja, Grml hat sowas! :-D) tut’s nicht, stattdessen habe ich jetzt die 32- und die 64-Bit-Version auf dem Stick. Kommt am Ende auf’s gleiche raus.

Multisystem ‚weiß‘ wie es die einzelnen ISOs behandeln muss um sie mit einem zentralen Bootloader starten zu können. Dazu ist für jedes unterstützte ISO eine Konfiguration hinterlegt, man kann dem Programm also auch nicht beliebige Systeme vor werfen. Die Ubuntu-Images liegen jetzt einfach als ISO auf dem Stick, ich weiss nicht ob ich die einfach austauschen könnte. Grml wird wie ein ‚richtiges‘ Debian behandelt und komplett ausgepackt auf den Stick gelegt. Der Traum vom Stick mit mehreren bootfähigen ISOs ist also immer noch nicht erfüllt.

Alternativ habe ich mir übrigens auch MultiCD angesehen, aber nicht wirklich ausprobiert. Wenn ich das richtig verstehe kann man damit nur CDs oder DVDs bauen, keine Sticks.

Falls doch noch jemand eine Idee hat wie man den Stick so bestücken kann wie ich mir das vorgestellt hatte: immer her damit!

by ·5 Kommentare

Heute habe ich mich (unter anderem) mit einem Problem beschäftigt das auf den ersten Blick trivial aussieht. Ich zumindest habe bislang keine Lösung gefunden die mir wirklich gefällt. Mal sehen ob was dabei rauskommt wenn ich das hier ‚crowdsource’… :-)

Aufgabenstellung: Zähle, wie viele Prozesse eines bestimmten Programmes schon länger als 30 Minuten laufen.

Klingt einfach, oder?

Die Ausgaben von ps zu parsen erscheint mir dabei aber zu fehleranfällig. Da müsste man zu viel berücksichtigen: Prozesse die vielleicht länger als einen Tag laufen, Prozesse die über Mitternacht gelaufen sind… ich habe nicht getestet wie es aussieht wenn man an der Zeitzone rumspielt… Nein, das kann nicht der richtige Ansatz sein.

Meine erste echte Lösung sieht zwar hässlich originell aus, funktionierte aber im Test (zu Demozwecken suche ich mal nach meinem Firefox):

echo | killall -i --older-than 30m firefox 2> /dev/null | tr -cd '?' | wc -c

Mit -i ist killall ‚interaktiv‘, fragt also zu jedem gefundenen Prozess freundlich nach ob es zuschlagen soll. Mit dem reingepipten echo beantwortet es sich diese Frage immer negativ. Der Rest der Zeile zählt im Prinzip wie oft killall gefragt hat ob es töten soll.

Blöd ist, dass die auf einem etwas älteren RHEL laufen soll. Anders als bei Ubuntu kennt killall da die Option –older-than noch nicht.

Der zweite Lösungsansatz funktioniert leider nur auf den ersten Blick, dafür aber auch auf dem alten Red Hat:

find /proc/[0-9]* -maxdepth 1 -name status -mmin +30 | xargs egrep "^Name:\sfirefox$" | wc -l

Ich suche also alle Prozesse die schon länger als 30 Minuten laufen, und suche in deren status-Datei nach dem Namen meines Prozesses. Die Ergebnisse werden dann wieder gezählt. Alternativ könnte man statt in der status- auch in der cmdline-Datei suchen, in meinem echten Einsatz übersehe ich damit dann auch Zombies (die werden separat betrachtet). Leider funktioniert dieser Ansatz nicht wirklich zuverlässig. Es sieht so aus als ob der Kernel den Dateien im Proc-Verzeichnis bisweilen einen neuen Timestamp gibt — obwohl der Prozess nicht gestartet oder beendet wurde. Ein Schuss in den Ofen, also. :-(

Wie macht man sowas? Ich meine, wenn man eine zuverlässige Lösung mit Bordmitteln haben will? Gibt es da ein passendes Tool das ich noch nicht kenne? Oder hilfreiche Optionen für gängige Tools? Wenn ich die Suchmaschine meiner Wahl frage finde ich eine Menge Lösungen, aber die sind entweder auch wackelig, oder sie bestehen darauf direkt alles zu töten…

by ·2 Kommentare

Eigentlich ist es schade drum:

root:~# stat /var/log/installer.log.1 | grep Modify
Modify: 2002-12-03 21:03:20.000000000 +0100

Das Debian auf meinem Heimserver habe ich vor genau zehn Jahren, einem Monat, einem Tag und ein paar Stunden installiert. Vor einem halben Jahr habe ich das einem Arbeitskollegen erzählt, er hat es mir nicht geglaubt — vermutlich übersteigt das die wildesten Fantasien eines Windows-Admins… :-)
Wenn ich mich recht erinnere war das meine erste Debian-Installation überhaupt, vorher liefen da ein SuSE, ein Mandrake und ein Red-Hat Linux. Ich meine, mich auch noch dunkel an ein Halloween Linux erinnern zu können.
Damals müsste das eine Hardware in Pentium-Klasse gewesen sein, sicher nicht mehr als 166MHz. An den Speicher und die Festplatte kann ich mich nicht mehr erinnern.
Sicher ist es nicht weiter schwer, ein System zehn Jahre am Leben zu erhalten. Das Ding hat aber eine bewegte Geschichte hinter sich. Mal abgesehen davon dass es immer wieder auf neuere Hardware umgezogen ist hatte es im Laufe der Zeit schon folgende Funktionen:

  • Durchgehend hat es Basis-Dienste für mein Netz bereitgestellt: NFS, DNS (Bind), DHCP, Web (Apache)… sogar ein NIS lief da.
  • Kuriosester Einsatz war wohl der als Wecker: Weckzeit mit Barcode-Scanner programmiert, dann Wecken mit abwechseln MP3 und Zeitansage (Sprachsynthese mit Mbrola). :-D
  • Es war mal ein Fax-Server (Hylafax) und ein Drucker-Server (erst ohne, später mit Cups).
  • Es war mal ein Anrufbeantworter (Vbox3).
  • Es war mal ein Videorecorder (VDR). Seit der Server in den Keller gewandert ist habe ich im Wohnzimmer einen Festplattenlosen Rechner der per PXE vom Server booted.
  • Ursprünglich war nur eine Platte drin. Dann mal mehrere separate, dann RAID5, seit ein paar Jahren RAID1.
  • Da liefen mal Teile eines Konfigurationsvorschlags von der c’t, mit Virtualisierung einer Endian Firewall per UML (User Mode Linux).
  • Der nächste Virtualisierungsansatz hiess Xen, auch wieder mit einer Endian Firewall. Zusätzlich aber mit einer vierfach-Netzwerkkarte.
  • Irgendwann fand ich Endian doof, um das FreeBSD-basierte pfSense nutzen zu können habe ich Xen durch KVM ersetzt.
  • Und um die Sache spannender zu machen habe ich neben KVM auch Linux-Vserver eingesetzt.

Wohlgemerkt: alles ohne das Betriebssystem neu zu installieren! Das System habe ich Heute abgeschaltet, und so wie es aussieht endgültig. :-(

Nicht erschrecken: ich bin mit Debian als Serversystem mehr als zufrieden. Und nein, ich werde mein Heimnetz nicht abschalten. :-)

Aber die Grundlage wird eine andere. Ich hatte ja schon erwähnt dass mir Proxmox VE gut gefällt. Nicht zuletzt weil es auf Debian basiert. Hier und da gibt es Verbesserungspotential, aber im Moment scheint mir das für mich die beste Lösung zu sein.
Ich habe in den letzten zwei Wochen viel Zeit in den Umbau gesteckt. Proxmox auf der Umweltsau installiert, erst die KVM-Virtualisierten Systeme — zwei FreeBSD und ein Ubuntu — rübergeholt, dann die Vserver. Letztere mussten ja auch noch an OpenVZ angepasst werden.
Heute kam der finale Schritt: ich habe meinen Hauptserver virtualisiert. Also oben genanntes Debian-System. Das siecht jetzt erstmal als KVM vor sich hin. Noch macht es DNS, DHCP und Web, Backups der anderen Systeme, und ein paar andere Kleinigkeiten. Nach und nach werde ich es seiner Dienste berauben und dann wirklich entsorgen.
Aber vorher warte ich ein paar Tage ab ob die ganze Geschichte so auf dem neuen Server funktioniert. Wenn nicht kann ich die alte Kiste mit wenig Aufwand wieder anschalten. Wenn doch wird da auch ein Proxmox installiert, und ich migriere die ganzen virtuellen Maschinen zurück. Auf Dauer will ich die Umweltsau doch nicht 24/7 laufen lassen…

by ·Ein Kommentar

Antike Hardware

Antike Hardware

Heute war mir mal wieder nach Plotten. Zuletzt habe ich das Gerät — einen Oldtimer der nächstes Jahr dreißig Jahre alt ist — vor knapp drei Jahren benutzt, daher hatte ich kaum noch Reste des Plans wie das funktioniert hat. Damit ich den Weg beim nächsten Mal nicht schon wieder komplett neu entwickeln muss habe ich jetzt mal auf der Schatenseite zusammengeschrieben wie man den Plotter unter Linux benutzen kann.

by ·6 Kommentare

Es sind die kleinen Dinge im Leben, die Freude bereiten:

less +F /var/log/syslog

Das funktioniert erstmal ähnlich wie ein tail -f, nur dass nicht die letzten 10 Zeilen der Datei angezeigt werden sondern ‚der letzte Bildschirm voll‘. In der letzten Zeile verrät ein freundliches Waiting for data… (interrupt to abort) was passiert: neuer Inhalt in der Datei wird sofort dargestellt. Der große Vorteil gegenüber tail: nach dem geforderten Interrupt (also CTRL-C) hat man die Datei direkt ganz normal im less offen, kann also beliebig nach Inhalten suchen oder hoch und runter scrollen.

by ·8 Kommentare

Arch Linux

Arch Linux

Nein, ich nutze Arch Linux noch keine zehn Jahre. Aber sieben sind es jetzt doch schon. Das Projekt ist Vorgestern zehn Jahre alt geworden, und ich nutze die Gelegenheit mal um mich öffentlich zu bedanken.

Arch ist für mich die ideale Arbeitsplatzdistribution: schlank, aktuell und flexibel. Die eigentliche Distribution ist verhältnismäßig dünn mit Paketen ausgestattet. Dafür gibt es aber das Arch User Repository (AUR), und da findet man praktisch alles. In den sieben Jahren ist es mir nur einmal passiert dass ich etwas haben wollte was es da nicht gab, und an der Stelle freut man sich dann darüber wie einfach es ist, sich in Arch ein eigenes Paket zu bauen. Dafür sind keine komplizierten Spec-Dateien erforderlich, man schreibt lediglich einen kurzen Fetzen Shell.

Vor Arch hatte ich Gentoo auf meinem Arbeitsplatz, da ist mir aber irgendwann die ständige Compiliererei auf den Keks gegangen. Davor war es Debian Unstable. Das ist stabiler als der Name vermuten lässt, aber irgendwann bin ich in der bekannten Abhängigkeitshölle gelandet. Und das Debian Stable davor ist zwar immer noch meine erste Wahl auf Servern aller Art, macht aber auf dem Desktop keinen Spass wenn man auch mal aktuellere Software haben möchte.

Sicher ist Arch nicht jedermanns Sache. Ich würde das niemandem empfehlen der nicht die Absicht oder die Möglichkeit hat sich intensiv mit seinem System zu beschäftigen. In anderen Distributionen funktionieren viele Dinge ‚out of the box‘ für die man in Arch erstmal Doku und den Vi bemühen muss. Das mag nicht jeder, und das kann ich gut verstehen. Ich weiß aber dass ich gerade durch diese Eigenart eine Menge über mein System gelernt habe. Und ich werde durch ein System belohnt das ohne großen Paket-Overhead auskommt. Ich muss weder Gnome, noch KDE oder deren aufgeblähte Anwendungen installieren. Auch kein anderes Desktop Environment, das ich eh nicht brauchen würde. Dafür kann ich trotzdem auch exotischere Anwendungen benutzen ohne dafür meine Distribution verbiegen zu müssen. Und dank der Rolling Releases bin ich auch immer halbwegs auf dem Stand der Technik.

Ach ja, Releases: obwohl ich zwischendurch auch mal längere Zeit keine Updates eingespielt hatte, konnte ich meine Installation über mehrere Hardwaregenerationen weiterbetreiben, ohne alles neu aufsetzen zu müssen. Erst vor drei Monaten habe ich auf für mein neues Notebook Tabula Rasa gemacht: für 4GB RAM musste ich dann doch auf 64 Bit umsteigen, und das geht nur sinnvoll mit Neuinstallation.

Genug der Lobhudelei, ich bin weiterhin überzeugt dass Arch genau das richtige für mich ist, und ich dadurch in den Genuss einer Menge Vorzüge komme.

Und dafür danke ich dem Projekt: Danke! :-)

by ·4 Kommentare

Mal wieder ein versuchter Zugriff auf Euer Know-How: ich wurde gefragt ob es ein Tool gibt mit dem ich den CPU-Verbrauch eines Programmes messen kann. Also nicht beobachtend wie top oder als Momentaufnahme (das geht glaube ich irgendwie mit ps), sondern mehr so wie mit time: ich starte mein Programm mit $toolname $programmname, und nach Abschluss erhalte ich eine Angabe darüber wie viel CPU-Last das Programm tatsächlich erzeugt hat.

Die Laufzeit mit time zu messen ist zwar ein Ansatz, allerdings ist die Ausgabe wohl stark davon abhängig was sonst auf meiner Maschine los ist.

Nach einer kleineren Google-Orgie bin ich um folgendes schlauer, vielleicht ist das sachdienlich: der Kernel misst CPU-Zeit in sogenannten Jiffies. Ein Jiffy ist auf einem System immer gleich lang (typischerweise 1/100 oder 1/250 Sekunde) und stellt praktisch eine Zeitscheibe dar die der Kernel auf einen Prozess verwendet. Man kann im /proc-Dateisystem nachsehen wie viele Jiffies ein Prozess bis dato verbraucht hat. Allerdings nur so lange der Prozess auch noch läuft.

Was ich suche ist also praktisch ein Tool das mir nach Beendigung meines Programms sagt wie viele Jiffies es gebraucht hat. Oder so. Gibt es das irgendwo fertig? Oder suche ich eigentlich was völlig anderes?

by ·Keine Kommentare

Irgendwann will ich mal selbst eine Platine zusammenbraten auf der ein echtes Linux läuft. Ohne einen besonderen Einsatzzweck, einfach nur weil es geht. Inspiration in die Richtung bietet Gnublin. Im Prinzip ist das schon alles, und sogar komplett Open Source. Einschließlich des Schaltplans. Nur der ARM-Controller lässt sich nicht von Hand löten…