Ubuntu/Centos: /bin/sh Unterschiede

Mal wieder Zeit verplempert: Wenn man Shell-Scripts programmiert sollte man wissen welchen Interpreter man verwendet. Etwas achtlos verwendet man meist den Shebang „#!/bin/sh“. /bin/sh ist meist nur ein Link auf die jeweilige Default-Shell der Distribution.

Unter Centos/RedHat ist /bin/sh ein Link auf /bin/bash (die Bourne-Again-Shell):

[root@centos ~]# ls -la /bin/sh
lrwxrwxrwx 1 root root 4 Apr 28  2010 /bin/sh -> bash

Unter Ubuntu/Debian hingegen verlinkt /bin/sh auf /bin/dash (Debian-Almquist-Shell).

root@debian:~# ls -la /bin/sh
lrwxrwxrwx 1 root root 4 2010-11-02 16:47 /bin/sh -> dash

Aufgefallen ist mir der Unterschied beim Verwenden der Bash-Variable $UID. Die dash enthält diese Variable nämlich nicht. Weitere Unterschiede sind mir bisher nicht bekannt (habe aber auch nicht danach gesucht).

NFS und symbolische Links (symlinks)

Ein NFS-Client interpretiert auf dem NFS-Server erstellte symbolische Links wie lokale Links: Er wendet sie auf das lokale Dateisystem an. Möchte man auf dem Server z.B. per Symlink bestimmte Verzeichnisse über eine einzige Freigabe exportierten, funktioniert diese Methode also u.U. nicht.

Ein Workaround ist es, die Verzeichnisse auf dem Server per „mount –bind /quelle /ziel“ zu „verlinken“ bzw. zu mounten. Damit diese Mounts permanent sind, müssen sie in die /etc/fstab eingetragen werden:

/mnt/capture /data/video/capture bind bind 0 0

Allerdings exportiert der NFS-Server (Ubuntu/Debian Paket nfs-kernel-server) nicht die gemounteten Verzeichnisse von sich aus – man muss diese noch zusätzlich in der Datei /etc/exports angeben. Diesmal mit der Option „nohide“ (detaillierte Erklärung hier):

/data/video/ 192.168.23.10(rw,async,no_subtree_check,no_root_squash)
/data/video/capture 192.168.23.10(rw,async,no_subtree_check,no_root_squash,nohide)
/data/video/movies 192.168.23.10(rw,async,no_subtree_check,no_root_squash,nohide)

Insgesamt eine etwas umständliche Lösung. Leider ist mit nichts besseres eingefallen…

Jeder erste Sonntag im Monat

Wer sich wundert, warum er am ersten Sonntag im Monat ganz früh morgens aus dem Bett geklingelt wird, hat vermutlich ein Debian oder Ubuntu System und Probleme mit dem Soft-Raid.

Auf diesen Systemen führt cron um 00:57 (wie gesagt nur am ersten Sonntag im Monat) einen Check der Soft-Raid Partitionen durch. Eine wichtige Maßnahme – werden dadurch doch recht früh Fehler am IO-System (Bad Blocks etc.) aufgedeckt (und nicht erst wenn es zu spät ist).

md: data-check of RAID array md0
md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
md: using 128k window, over a total of 48829440 blocks.

BTW: Bei RedHat/Centos wird der gleiche Check über cron.weekly (jeden Sonntag 4:22) ausgeführt. Manuall triggert man einen solchen Check über:

echo check > /sys/block/md0/md/sync_action

Wo bin ich?

Um schnell herauszubekommen was genau für ein OS bzw. welche Version auf einer Remote-Maschine läuft schreibe ich jetzt mal die zugehörigen Befehle auf…

Quick and dirty:

# Funktioniert zumindest mit Centos, Redhat, Fedora, Ubuntu, Debian
cat /etc/issue
Ubuntu 8.04.3 LTS \n \l

(/etc/issue ist ein Template welches vom System für den Login-Prompt verwendet wird. Je nach Distribution werden dort z.B. noch Kernelversion und Architektur angezeigt, daher werden auch u.U. noch ein paar Platzhalter ausgegeben…)

„Wo bin ich?“ weiterlesen

Ubuntu aufräumen

Nach diversen apt-sessions (z.B. dist-upgrade) sammeln sich allerhand Restbestände von alten Paketen an. Folgendes mache ich immer um ein wenig aufzuräumen. Nutzung auf eigene Gefahr!

# Folgende Kommandos als Superuser
sudo su
 
# Paketdownloads entfernen
apt-get clean
 
# Nicht benötigte Pakete entfernen
apt-get autoremove
 
# Reste (z.B. Konfigurationsdateien) von bereits deinstallieren Paketen entfernen
dpkg -l | grep ^rc | cut -d ' ' -f3 | xargs dpkg -P

Das ganze sollte auch unter Debian klappen…

/tmp overflow

Debian: Soeben kam beim Entpacken der Kernel-Sourcen „No space left on device“. Kein Problem, einfach ein paar nicht benötigte Logs etc. gelöscht und weiter entpackt. Soweit kein Thema.

Beim Kompilieren des eigentlichen Moduls kamen Meldungen wie „error writing to /tmp/ccM6zKcD.s: No space left on device“. Hmm, schon wieder? Laut „df“ habe ich mehr als genug Platz. Schnell mal in /tmp geschaut: Alles leer.

Beim ausführen von „mount“ kam folgendes:

home:~# mount
/dev/md1 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)
...
overflow on /tmp type tmpfs (rw,size=1048576,mode=1777)

/tmp extra gemounted? Overflow? Nie gehört…

Etwas Recherche ergab, dass beim booten das Script „/etc/init.d/mountoverflowtmp“ überprüft ob /tmp genug Platz hat – und falls nein, wird /tmp in eine 1MB große RAM-Disk gemounted. Das muss man erst mal wissen 😉

Jetzt habe ich Platz geschafft. Beim nächsten Booten wird das Script erneut prüfen und dann keine Unregelmäßigkeit feststellen.

IMON LCD Display (neues VDR-Plugin imonlcd)

imonlcd_small

Vor ein paar Tagen habe ich im VDR-portal ein neues Plugin für die Ansteuerung meines Displays entdeckt: imonlcd (Thread). Das geniale: Es ist genau auf das neue Imon LCD Display abgestimmt und benötigt kein installiertes LCDproc. Sonderzeichen (UTF8) funktionieren und die vielen Symbole auf dem LCD werden endlich auch mal angesteuert.

Da ich schon wie hier beschrieben lirc mit LCDproc laufen hatte, musste ich also nur die Pakete vdr-plugin-lcdproc und lcdproc deinstallieren und das neue Plugin installieren.

Solange e-Tobi noch kein Paket erstellt hat, habe ich mit der Hilfe seiner Anleitung ein provisorisches Paket erstellt. Mit eTobis VDR Paketen 1.6.0-2 läuft das bei mir ohne Probleme.

Download vdr-plugin-imonlcd_0.0.1-1_i386.deb

Folgend die Schritte zur Installation und Abhängigkeiten:

„IMON LCD Display (neues VDR-Plugin imonlcd)“ weiterlesen

Debian 5.0

1234567890 war es dann (ja, nicht ganz pünktlich) soweit: Debian 5 ist erschienen. Wenn die /etc/apt/sources.list so aussieht wie meine, ist ein „apt-get dist-upgrade“ normalerweise kein Problem. Dafür liebe ich Debian!

#  /etc/apt/sources.list
 
deb     http://ftp.debian.org/debian      stable main contrib non-free
deb-src http://ftp.debian.org/debian/     stable main contrib non-free
deb     http://www.debian-multimedia.org  stable main
 
deb     http://security.debian.org/ stable/updates  main contrib non-free
deb-src http://security.debian.org/ stable/updates  main contrib non-free
apt-get update
apt-get dist-upgrade

Den neuen Kernel (2.6.26) aktiviert man mit

apt-get install linux-image-2.6-686

Es gibt auch einen 2.6.26 XEN-Kernel. Witzigerweise steht in dessen Bezeichnung „oldstyle Xen support“. Wie passend 😉.

Auf Produktivsystemen ist natürlich mehr Vorsicht angebracht – auf meinem VDR lief das Update problemlos!

PHP: $_ENV leer

Wenn man mit PHP-Scripten auf der Kommandozeile arbeitet, kann man normalerweise über das globale $_ENV Array auf die Umgebungsvariablen zufreifen.

Jedoch bietet längst nicht jede PHP-Distribution die gleichen Voraussetzungen. Ist in der php.ini z.B.

variables_order = "GPCS" # (GET, POST, COOKIE, SESSION)

gesetzt (ohne „E“), wird das $_ENV Array nicht befüllt. Folgende Einstellung füllt das $_ENV Array wieder entsprechend:

variables_order = "EGPCS" # (ENV, GET, POST, COOKIE, SESSION)

Für die Verwendung von PHP in Verbindung mit Webservern ist die Standardeinstellung (bei manchen Distributionen) sicherlich nicht ganz falsch: Die Einstellung verhindert dann, dass sämtliche Umgebungsvariablen jedem PHP-Script zum Auslesen zur Verfügung stehen. Daher ist es sinnvoll, PHP für die Kommandozeile eine eigene php.ini mitzugeben:

php -c /etc/php.ini_cli script.php

Debian hat von vornherein eine eigene php.ini (in /etc/php5/cli/php.ini)  für das CLI (sehr vorbildlich).