Skip to content

Mit Servern beginnen ...

Ausgangspunkt ist dieses Posting auf Google+, in dem Stefan auf einen etwas älteren Artikel hinweist, in dem es darum geht, dass man ohne Vorwissen besser keinen root-Server (oder vServer) betreiben sollte.

Auch wenn der Ton im Artikel falsch ist, gebe ich dem Autoren in der Sache Recht.

Heutzutage kann jeder dank Virtualisierung auf einem halbwegs aktuellen Rechner Gehversuche mit Servern machen und Erfahrungen sammeln bevor er sich an ein Gerät wagt, was im Internet vielen "Gefahren" ausgesetzt ist. Man bekommt das Wissen nicht alleine durch das Lesen von Artikeln im Internet, man muss es auch anwenden. In dem Zusammenhang weise ich gerne mal wieder auf die Diktatur des schönen Scheins hin.

Als Einstieg in die Servermaterie empfehle ich folgende beide Bücherdoppel:

Addison-Wesley:
Linux 2012
Linux-Administrationshandbuch

Analog dazu bei Galileo Computing:
Linux. Das umfassende Handbuch
Linux-Server. Das Administrationshandbuch

Grundlagenwissen veraltet nicht so schnell, es kann sich lohnen, auch mit älteren gebrauchten Büchern zu beginnen. Danach kommen dann Fachbücher zu spezifischen Themen.

Synchronisation von Installationen ...

linux Was ich an Debian basierten Distributionen so mag, ist die einfache Möglichkeit, Installationen synchron zu halten. Dieses Feature haben sich Ramon und ich auch bei unserer Session auf der Ubucon 2010 zu Nutze gemacht.

Auf dem Quell-System kann man sich mit dpkg --get-selections die Paketliste ausgeben lassen. Die entstehende Datei kopiert man auf das Zielsystem.

dpkg --get-selections > installation.lst


Auf dem Zielsystem erledigen dann die folgenden beiden Befehle die Arbeit.

dpkg --set-selections < installation.lst
apt-get dselect-upgrade


Damit habe ich gestern innerhalb von rund dreissig Minuten auf einem Atom-Prozessor rund 500 Megabyte an Paketen heruntergeladen und installiert.

Bei Sabayon kann etwas ähnliches mit equo query installed und ewtas Shell-Magie erreicht werden, allerdings dauerte die Installation einer vergleichbaren Menge an Software auf dem Netbook rund zweieinhalb Stunden.

SFTP chroot mit Bordmitteln ...

linux Nachdem ich ein bisschen mit scponly und scponly-full wie auch rssh herumgespielt habe, habe ich mich entschieden, den Dateizugriff mit Bordmitteln unter Linux zu bewerkstelligen. Mir haben die anderen Lösungen nicht gefallen.

In Anlehnung an scponly habe ich eine Gruppe sftponly angelegt. In diese habe ich alle User gesteckt, die nur per sftp auf den Server zugreifen sollen.

In der /etc/ssh/sshd_config habe ich die betehende Subsystem-Zeile auskommentiert und eine neue Zeile mit Hinweis auf internal-sftp hinzugefügt.
# Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp


Ene chroot-Umgebung für die Gruppenmitglieder der Gruppe sftponly wird wie folgt eingerichtet:
Match group sftponly
        ChrootDirectory /home/%u
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp


Die ChrootDirectory-Option sagt, dass /home/USERNAME für den Benutzer zum root-Directory wird. Das Homeverzeichnis in der /etc/passwd gilt ab diesem Verzeichnis.

Das kann nervig sein, da im Standard, OpenSSH nach der authorized_keys-Datei im Verzeichnis .ssh des Homeverzeichnisses sucht. Das ist natürlich konfigurierbar, aber ich wollte daran nichts ändern.
AuthorizedKeysFile     %h/.ssh/authorized_keys


Daher sieht bei mir das Konstrukt ein wenig "eigenwillig" aus.

Unter /home/USERNAME/.ssh/authorized_keys sind die erlaubten öffentlichen Schlüssel des Benutzers zu finden. Das Verzeichnis /home/USERNAME gehört jetzt dem User root. Das Verzeichnis, in das der User schreiben darf liegt unter /home/USERNAME/home/USERNAME. Sieht komisch aus, macht aber nichts kaputt. :-)

Tage zwischen Daten ...

linux Mal schnell "wegbloggen", weil ich es gerade gebraucht habe.

Das klappt meiner Meinung nach nur mit dem date aus den GNU Coreutilities.

Wenn jemand andere Lösungen kennt, die auch in eine Zeile passen und mit Standard-Tools auskommen, dann bitte her damit.

echo $(( ($(date +%s --date=20121122) - $(date +%s))/24/60/60 ))
139

Sublime Text 2.0 für Linux ...

linux Durch Christophs Blog wurde ich erneut auf Sublime Text aufmerksam gemacht, der mittlerweile in der Version 2.0 vorliegt. Eine frühere Beta hatte ich erstaunlicherweise sogar noch auf der Platte.

Sublime Text 2 ist ein kommerzieller Texteditor (leider keine Open-Source-Software), der einfach nicht "im Weg" steht und eine grosse Menge sehr guter und interessanter Features bietet, noch dazu sieht er einfach gut aus.

Bestrebungen einen ähnlich guten Editor aufzubauen gibt es mit Scribes für Gnome auch. Sublime Text ist aber auf den drei grossen Plattformen Linux, Mac OS X und Windows (auch in einer portablen Version) verfügbar.

Ich suche schon länger nach einem guten Editor, den es auf jeder Plattform gibt, nicht erst seit meiner Odysee von Eclipse über Geany zurück zu vim. Unter Windows fand ich in meinem letzten Job in Deutschland Ultraedit ziemlich klasse und bin ziemlich überrascht zu sehen, dass es den jetzt auch plattformübergreifend gibt.

Der Editor ist Shareware, man kann ihn uneingeschränkt testen, muss aber bezahlen, wenn man ihn regelmässig benutzt. Eine Lizenz kostet 59 USD, die Lizenz erlaubt es, den Editor auf beliebig vielen Rechnern und Betriebssystemen mit dem lizensierten Nutzer einzusetzen. Eingeschlossen sind alle Updates innerhalb der 2er-Serie, für eine Version 3 werden wieder Lizenzkosten fällig.

Wir sind gerade im Endspurt für die zweite Auflage unseres Buchs, damit habe ich auch gleich den Härtetest. Tatsächlich habe ich schon viele Editoren gesehen und auch ausprobiert, aber tatsächlich kam bis jetzt keiner an diesen heran, daher überlege ich ernsthaft, das Geld auszugeben.

Rolling releases ...

linux Je öfter ich damit konfrontiert werde, desto häufiger denke ich, dass viele das Konzept einer Rolling-Release-Distribution nicht verstanden haben.

Rolling Release bedeutet, dass eine Distribution regelmässig Updates erfährt und dass man nicht nach einem Release-Wechsel von Version A auf Version B etwas besonderes machen muss. Wenn man also regelmässig auf dem normalen Weg Updates einspielt, ändert sich das Release auf dem Rechner automatisch von A auf B.

Jetzt mal "Bullshit"-tauglich:

Rolling release is not bleeding edge

Rolling Release bedeutet nicht, dass zu jedem Zeitpunkt die aktuellste Version einer Software auf einem Rechner läuft.

Als Beispiel möchte ich einmal drei Linux-Distributionen mit
Rolling-Release-Modell nennen:
  • Arch Linux ist wohl eine der aktuellsten Linux-Distributionen derzeit. Wenn man Rolling Release und sehr aktuelle Software möchte, ist das der Weg, den man einschlagen kann.
  • Linux Mint Debian Edition basiert auf Debian testing mit der Einschränkung, dass Updates zu Bundles zusammengefasst werden, dafür aber auch sehr gut funktionieren. Wenn man Rolling Release und Endbenutzertauglichkeit - gerade auch in Bezug auf Multimedia - möchte, ist das eine gute Wahl.
  • Sabayon basiert auf Gentoo und kann deshalb auch nicht schneller als Gentoo sein. Wenn man auf der Suche nach einer kleinen Distribution ist, die nicht so weit verbreitet ist, wird man hier fündig.

Audio unter Linux ...

podcast Die sechste Folge des Datenkanals beschäftigt sich mit Audio unter Linux und ist meines Erachtens nach ein Volltreffer und damit eine echte Empfehlung. Jens Kubieziel und Jörg Sommer haben Adrian Knoth zu Gast, der eine Menge zu Audio unter Linux, verschiedene Soundsysteme, Audiobearbeitung und Latenzen zu erzählen weiss.

Kommandozeilen-Anwendungen ...

Meine private Top 10 oder der Anwendungen für die Kommandozeile, vielleicht sollte ich eher sagen, dass das meine Lieblingsanwendungen sind und nicht unbedingt die, die ich am häufigsten benutze (dann müsste wenigstens sudo noch dazu).

Taskwarrior finde ich gut und dass sage ich nicht nur, weil ich im Core Team bin, sondern eher andersherum, ich bin im Core Team, weil Taskwarrior klasse ist. Taskwarrior zeigt, dass auch Kommandozeilenprogramme durch sinnvollen Einsatz von Farbe und durch übersichtliche leicht zu erlernbare Befehle sehr mächtig und nützlich sein können. Das lohnt sich auch für Leute, die die Kommandozeile "eigentlich" nicht mögen.

rsync macht, anders als Unison, nur Synchronisationen in eine Richtung. Dafür bringt rsync aber auch einen grossen Haufen an (mehr oder weniger) sinnvollen Optionen mit. Selbst lokal kopiere ich grössere Dateien nicht mehr mit cp, sondern mit rsync, da rsync auch eine Fortschrittsanzeige hat (rsync -Pha quelle ziel)

OpenSSH ist für mich eine Sammlung von universellen Werkzeugen, was Verbindung zu oder über andere Rechner angeht. rsync kann über OpenSSH laufen, Tunnel können gebaut werden, ein einfacher Proxy ist möglich und die Administration anderer Systeme wäre ohne OpenSSH kaum denkbar.

htop und vielleicht Iotop, was ich aber sehr selten nutze. htop ist ein hervorragender Ersatz für top, der einige hilfreiche Optionen mitbringt und zum Teil Funktionen von ps bzw. pstree obsolet macht.

SYSSTAT ist eine Sammlung von Werkzeugen, die bei der Analyse eines laufenden Systems helfen. Grafische Auswertungen sind mit kSar möglich. Schaut auch mal in den Beitrag zu Sysstat in den Adminstories.

Git ist für mich das Versionskontrollsystem, es hat so viele Vorteile und eine unglaublich reichhaltiges Umfeld an Werkzeugen, dass alles hier den Rahmen sprengen würde. CRE130 möchte ich immer noch als beste Einführung in das Thema verteile Versionskontrollsysteme im Allgemeinen und Git im Speziellen empfehlen.

SoX ist das "Schweizer Taschenmesser" der Audiobearbeitung auf der Kommandozeile. Bis auf Schnitt gibt es kaum etwas, was nicht möglich ist und kaum ein Format, das nicht unterstützt wird.

ack! ist wie die URL schon sagt "better than grep", schnell und vielseitig, es macht einfach Spass.

Perl hier zu nennen ist mir echt schwer gefallen, aber als ich mich vor die Wahl gestellt hatte, Perl oder awk hier zu nennen, ist die Wahl nicht schwer gefallen. Perl ist eine einfach zu lernende und sehr mächtige Programmiersprache, die auch sehr nützlich auf der Kommandozeile ist, wie Perl One Liners und Hot Perl Oneliners beweisen

cURL ist die eierlegende Wollmilchsau, was Dateiübertragungen angeht, die Features sind lesenswert und, wenn man sich einmal die Vergleichstabelle anschaut, sieht man schnell, dass es das stärkste Download- UND Upload-Werkzeug für eine Vielzahl von Protokollen ist.

Vim; sudo; host aus den Utilities von bind; whois - als Client für das Whois-Protokoll; rename (perl-rename in Sabayon); GNU screen nutze ich regelmässig und finde ich nützlich (ist aber weit entfernt von "toll"; awk; sudo; ... sind weitere gute Anwendungen, die ich auch mehr oder weniger regelmässig nutze, es aber nicht in die "Top 10" geschafft haben.

Kristóf Kovács: A little collection of cool unix terminal/console/curses tools

GMail als Relay mit Postfix ...

linux Nur, um das mal eben "wegzubloggen" und um es danach vergessen zu können.

Wenn man Monitoring macht, ist es nicht sinnvoll, Mails, die das Monitoring betreffen, über die zu überwachende Infrastruktur zu senden. Da kann es von Vorteil sein, die Monitoring-Mails via Google zu schicken.

Hier die kurze Anleitung für Debian Squeeze.

Zunächst Postfix installieren und die notwendigen Pakete für die Verschlüsselung.
aptitude install postfix libsasl2-2 ca-certificates libsasl2-modules

Meiner Meinung nach, ist es egal, was Ihr bei der Installation von Postfix eintragt, weiter unten kommen wir zur main.cf.

Eine Datei /etc/postfix/sasl_passwd mit folgendem Inhalt erstellen (natürlich sollte da Euer User und Euer Passwort stehen):
smtp.gmail.com meinuser@gmail.com:passwort

Korrektur wegen diesem Artikel.
smtp-relay.gmail.com meinuser@gmail.com:passwort

Und eine Hashmap erstellen:
postmap /etc/postfix/sasl_passwd

Die Dateien müssen nur durch den User Postfix lesbar sein:
chown postfix:postfix /etc/postfix/sasl_passwd*
chmod 600 /etc/postfix/sasl_passwd*


Folgende main.cf kann verwendet werden, schöner ist es mit "richtigen" Zertifikaten, aber die Datei tut es auch. Bitte an den richtigen Stellen anpassen und die GMail-Teile einfach übernehmen.

# See /usr/share/postfix/main.cf.dist for a commented, more complete version

# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=no
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

# Anpassen
myhostname = my.fqdn.net
# /Anpassen
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = FQDN, localhost.yawnrz.net, localhost
# GMail
# relayhost = smtp.gmail.com:587
relayhost = smtp-relay.gmail.com:587
# /GMail
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = loopback-only
default_transport = smtp
relay_transport = smtp
inet_protocols = all

# GMail
smtp_use_tls=yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
# /GMail


Zu letzt muss Postfix neu gestartet werden.
service postfix restart


Ein Test darf natürlich nicht fehlen:
< /etc/hosts mail -s Testmail EureMail@provider.tld
(Die Mail muss nicht an eine GMail-Adresse gehen).

Prüfen, ob alles gut war:
tail -20 /var/log/mail.log

Logs ...

linux Meine wenig rühmlichen Versuche mit logwatch habe ich in den Adminstories dokumentiert. Sven Hartge hat in den Kommentaren zu scponly das Programm logcheck empfohlen und ich muss sagen, dass ich schwer begeistert bin.

Logcheck wird stündlich per Cronjob aufgerufen und informiert über Dinge, die in der letzten Stunde vorgefallen sind. Dabei kann man definieren, welche Logmeldungen man nicht mehr sehen möchte.

Grossartig! Und: Vielen Dank für den Tipp, Sven!

paste ...

Es gibt ja Befehle, die ich immer mal wieder brauchen könnte, aber noch nie gefunden habe. Heute habe ich per Zufall den Befehl paste aus den GNU core utilities gefunden (ausgerechnet jetzt brauche ich ihn nicht, aber später bestimmt).

paste fügt Zeile für Zeile zwei Textdateien zusammen. Es nimmt die erste Zeile aus der ersten Datei, schreibt ein (das ist veränderbar) und dann die erste Zeile aus der zweiten Datei, dann wieder ein und die Inhalte der weiteren Dateien.

Beispiel:
$ cat a.txt
a1
a2
a3
a4

$ cat b.txt
b1
b2
b3
b4

$ paste a.txt b.txt
a1      b1
a2      b2
a3      b3
a4      b4


paste kann das auch in Spalten.
$ paste -s a.txt b.txt
a1      a2      a3      a4
b1      b2      b3      b4

scponly-full ...

linux Zusätzlich zu scponly gibt es auf Debian basierten Systemen auch das Paket scponly-full, dass man ganz analog zu scponly einrichten kann. Die volle Variante bietet auch Unterstützung für rsync, unison und svn.

Für mich war die rsync-Unterstützung wichtig, allerdings funktioniert die (leider) nur, wenn man als Protokoll die Version 29 auswählt. Das hat mich ein bisschen Sucherei gekostet.

rsync -Phae 'ssh -c arcfour256' --protocol=29 meinverzeichnis/ user@server:/incoming/


Das obige synchronisiert meinen Kram in meinverzeichnis mit dem Verzeichnis incoming auf dem Server.

Das "P" sorgt dafür, dass unterbrochene Transfers wieder aufgenommen werden (lohnt sich gerade für sehr grosse Dateien).

Das "h" macht die Grössenangaben "human readable" und "a" steht für "-rlptgoD" und diese Bedeutung kann man in der Handbuchseite (manpage) nachlesen, ich merke mir "a" für "alles".

Das "e" läutet die Remote Shell (bei mir ssh) ein, der Cipher "arcfour256" gehört bei mir zu den schnellsten.

scponly ...

linux Für den Fall, dass es mal gebraucht wird. Ich war heute in der Not, einem User scp-Kopierrechte auf einen Server zu geben. Mit der Shell sollte sich der Benutzer nicht anmelden können. Genau dafür gibt es scponly, das Tool ist in gängigen Distributionen direkt in den Paketquellen.

Die Installation ist einfach, man braucht aber nicht nur das Paketmanagement.

aptitude install scponly


Und die Frage, ob man chroot einsetzen möchte ("Install the chrooted binary /usr/sbin/scponlyc SUID root?"), mit "Yes" oder "Ja" beantworten. Mit chroot wird ein User in einem bestimmten Verzeichnis eingesperrt, ohne dass er in den Verzeichnissen "wildern" kann.

cd /usr/share/doc/scponly/setup_chroot
gzip -cd setup_chroot.sh.gz > setup_chroot.sh


Mit disem Shellskript kann man einen User anlegen, der ins "Gefängnis" gesperrt wird.

bash setup_chroot.sh


Ich nenne den User mal "a":

Next we need to set the home directory for this scponly user.
please note that the user's home directory MUST NOT be writeable
by the scponly user. this is important so that the scponly user
cannot subvert the .ssh configuration parameters.

for this reason, a writeable subdirectory will be created that
the scponly user can write into.

Username to install [scponly]a
home directory you wish to set for this user [/home/a]
name of the writeable subdirectory [incoming]

creating  /home/a/incoming directory for uploading files

Your platform (Linux) does not have a platform specific setup script.
This install script will attempt a best guess.
If you perform customizations, please consider sending me your changes.
Look to the templates in build_extras/arch.
 - joe at sublimation dot org

please set the password for a:
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
if you experience a warning with winscp regarding groups, please install
the provided hacked out fake groups program into your chroot, like so:
cp groups /home/a/bin/groups


Ohne die folgenden beiden Befehle wird aber nichts daraus, da kommt es sonst zu Problemen.

cp -av /lib/libnss_* /home/a/lib/
cp -av /lib64/libnss_* /home/a/lib64/


Jetzt gibt es den User "a", dem es nur erlaubt ist per scp oder sftp Dateien hoch- und runterzuladen.

Silvia auf Fedora ...

linux Meine bessere Hälfte hat ihren Haupttrümmer gestern auf Fedora mit LXDE umgestellt. Die Werbung lügt nicht, der Desktop ist wirklich flott unterwegs.

Allerdings ist das Paketmanagement doch deutlich langsamer als bei Debian basierten Systemen.

sudo yum install yum-plugin-fastestmirror


Die obige Zeile beschleunigt das schon deutlich, aber langsamer ist es in Summe dennoch. Da das Leben nicht nur aus Installation besteht, ist das aber vermutlich kein Problem.

Einzig die Tatsache, dass nach jedem Neustart aufs Neue das Schweizerdeutsche Keyboard eingestellt werden muss, nervt. Die Konfigurationsdateien, die hier im Wiki benannt werden, enthalten die richtigen Werte. Da brauchen wir noch eine Lösung.

Serienmail mit Claws-Mail ...

linux Gerade habe ich die Mails mit den Überweisungsinformationen zur Buch-Aktion versendet und ich mag Linux einmal mehr. :-)

Die Leute, die bereit waren etwas zu geben, hatte ich in einer LibreOffice-Tabelle. Von dort habe ich die Spalten Name, E-Mail-Adresse und Betrag in eine Textdatei kopiert (copy'n'paste).

Dann habe ich die Mail als einfache Textdatei geschrieben:
To: EMAIL
Subject: S9y-Spendenaktion

NAME,

Du hast Dich vor einiger Zeit dazu bereit erklärt, EURO Euro zur Rettung des
Serendipity-Buchs zu spenden.
[...]
Danke für Deine Unterstützung.

Grüsse aus dem Grüt

Dirk


In der Textdatei mit den Empfängern habe ich alle Tabulatoren durch je ein Semikolon ersetzt:
sed 's/\t/;/g' l.txt > liste.txt


Und zum Schluss die Mails versendet:
IFS=";" ; cat liste.txt | while read name email euro ; do sed "s/EMAIL/$email/ ; s/NAME/$name/ ; s/EURO/$euro/" mailtext.txt > /tmp/claws.txt ; claws-mail --compose-from-file /tmp/claws.txt ; done


Jede Mail einmal kurz diagonal gelesen und versendet. Schön, dass so etwas in 10 Minuten machbar ist.