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).

Memcached unter Centos (via EPEL)

Das EPEL Repository hatte ich ja schon mal gepostet. Hier kurz die Pakete um memcached für PHP unter Centos zu installieren:

yum install memcached php-pecl-memcache
/etc/init.d/memcached start
/etc/init.d/httpd restart

memcached läuft dann mit 64MB auf dem Port 11211.

Fedora EPEL

Für Pakete welche von RHEL/Centos nicht direkt vertrieben werden: fedoraproject.org/wiki/EPEL.

„Extra Packages for Enterprise Linux (EPEL) is a volunteer-based community effort from the Fedora project to create a repository of high-quality add-on packages for Red Hat Enterprise (RHEL) and its compatible spinoffs such as CentOS or Scientific Linux. Fedora is the upstream of RHEL and add-on packages for EPEL are sourced from the Fedora repository primarily and built against RHEL.“

ich nutze von dort z.B. puppet und syslog-ng.

Centos neben Ubuntu, Launchpad & Co.

Langsam stehen einige Major-(Web-)Serverupdates an und ich überlege mittlerweile ernsthaft von Centos/RHEL auf Ubuntu Longterm umzusteigen. Auf dem Desktop habe ich Ubuntu schon lange, aber auch im Serverbereich möchte ich es mittlerweile an einigen Stellen nicht mehr missen. Nicht das ich besonders unzufrieden mit Centos/RHEL wäre. Eigentlich gar nicht. Es sind nur so ein paar Dinge die mich immer wieder zum Nachdenken bewegen:

Releasezyklus. Centos 5 ist bei Kernel 2.6.18, php 5.1, mysql 5.0. Klar, in den Centos Kernel werden viele wichtige Features gebackported. Wie z.B. letztens bei Centos 5.4 die virtio-Unterstützung für KVM. Nativ gab es diese aber schon im 2.6.24 (Januar  2008). Wann Centos 6 kommt steht noch in den Sternen (sehr wahrscheinlich jedoch dieses Jahr). Ubuntu hat einen festen Releasezyklus und ich wusste schon seit vielen Monaten dass Ende April die neue Long-Term Version erscheint. Also zumindest gut planbar.

Major-Relase Updates. Mit yum als Paketmanager gibt es (meines Wissens) keinen offiziellen Weg. Apt hat kein Problem damit.

Support. Vorteil Centos: Viele große Hardwarehersteller unterstützen RHEL mit Treibern. Da Centos Binary-Compatible ist profitiert man also davon. Docs/Community: Mag lächerlich klingen: Meistens muss ich doppelt googlen: Erst nach „centos“ dann nach „rhel“. Ubuntu hat eine gebündelte Community. Launchpad tut das übrige (s.u.).

Externe Repositories. Klar, für Centos gibt es auch irgendwo alles. Sei es neuere snmpd-Versionen oder syslog-ng. Aber halt meistens an verschiedenen Stellen. Was ich an Ubuntu sehr genial finde ist Launchpad. Launchpad hat mit Sicherheit einen großen Anteil am Erfolg Ubuntus. Es ist quasi alles in einem: Bugtracker, Mailingliste, Build-System und vor allem Repository. Und am Rande erwähnt: Mit einer vorbildlichen Usability und Optik ;). BTW: Launchpad lässt sich nicht nur für Ubuntu-Projekte nutzen.

Eines ist mir wohl bewusst: Einen klaren Sieger gibt es niemals. Es ist immer nur eine Abwägung und letztendlich eine eher subjektive Entscheidung. Wie schon anfangs erwähnt laufen einige Management-Maschinen unter Ubuntu. Sei es iSCSI, drbd oder das neueste von KVM – es hat schon Vorteile problemlos mit aktuellen Versionen arbeiten zu können…

Ob dieser Schritt letztendlich auch für die Masse der Webserver genommen wird ist noch nicht entschieden. Denn eines ist auch klar: Centos hat dort noch nie enttäuscht und das neueste vom neuen brauche ich dort eigentlich nicht. Aber eine neuere PHP oder MySQL Version wäre andererseits doch schön… So ist es halt: Never ending story…

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

udev: ungeplanter Namenswechsel bei NICs

Merkwürdig: Nach einem reboot wechseln die beiden Netzwerkkarten im Server regelmäßig ihren Namen zwischen eth0 und eth1. Blöd, wenn man nur ein Interface angeschlossen hat.

Schuld daran scheint das mittlerweile fast bei allen Distributionen eingesetzte „udev“ zu sein. Je nach Laune des Schedulers wird mal das eine, mal das andere Interface zuerst erkannt und erhält seinen Namen.

Das ganze hat mich ein wenig an die udev-Eskapaden mit XEN unter Debian erinnert – erste Abhilfe somit auch bei Centos 5: In den in /etc/sysconfig/network-scripts/ gelegenen Dateien „ifcfg-eth0“ und „ifcfg-eth1“ trägt man die zugehörige MAC-Adresse mit ein.

# /etc/sysconfig/network-scripts/ifcfg-eth0
# Intel Corporation 82566DM-2 Gigabit Network Connection
DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.1.1
NETMASK=255.255.255.0
HWADDR=00:15:17:00:00:00

Die MAC-Adressen kann man z.B. mit „ifconfig“ auslesen. Ob das auf Dauer hilft wird sich zeigen. Erste reboots sind jedenfalls erfolgreich. In einigen Threads habe ich gelesen, dass man evt. auch noch die udev-Konfiguration ändern muss – bisher noch nicht nötig…

Centos: Source RPMs installieren

Manchmal benötigt man auch das Source-RPM zu einem Paket um z.B. einen Patch einzuspielen. Folgende Schritte sind nötig (in diesem Beispiel um das PHP Source-Paket herunterzuladen):

yum install yum-utils
yumdownloader --source php

Damit die Quellen auch gefunden werden, müssen in der YUM-Konfiguration auch die entsprechenden Source-Repositories eingetragen werden (hier für Centos):

„Centos: Source RPMs installieren“ weiterlesen