Wichtiges bei Server-Installation

[Christoph 'Mehdorn' Weber]

Hallo!

Ich tippere gerade in unser internes Wiki, was man so alles nach
einer Installation von Debian GNU/Linux auf einem Server noch
umstellen sollte (quasi als Checkliste für zukünftige
Installationen), und das kommt mir noch unvollständig vor:

* bootlogd einschalten
* ggf. cron und logrotate[0] installieren
* smartd einrichten und einschalten
* einen Mailserver für Warnmails einrichten (z. B. von cron und
smartd)
* ntpd einrichten
* screen und ssh installieren
* unnötige Konsolen aus der inittab werfen
* automatische Reparatur beim fsck einschalten
* wichtige Locales einrichten

Es geht mir also nur um eine Grundinstallation. Man gehe also
von der Debian-Minimalinstallation aus und überlege sich, wie man
daraus eine Server-Grundinstallation macht. D. h. unnötige Dinge
entfernen (außer der Konsolen ist mir da nichts eingefallen), ein
wenig Systemüberwachung (smartd), nützliche Automatismen, wenn man
selten die Konsole sieht (bootlogd, fsck), ...

Was macht ihr bei euren Server noch so?

Christoph

[0] Neulich blieb hier ein System liegen, weil es nur eine große
Partition gab und mangels Logrotate das irgendwie vollgeloggt
war.

--
Anzeige Mainzer Hauptbahnhof: "Zug haelt nicht bis Mannheim"
Wie darf ich mir das vorstellen?
Faellt er etwa auf der Hoehe von Worms auseinander?
(Manuel Fuchs)

[Ralph Aichinger]

Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de> wrote:
> Was macht ihr bei euren Server noch so?

Natürlich muß man das gegen das (geringe?) Sicherheitsrisiko
abwägen, aber ich installiere fast immer gleich als erstes
diverse Netzwerkutilities, z.B.: tcpdump, nmap, nslookup (oder
dig oder sowas). Ich weiß jetzt nicht auswendig, was man
davon händisch dazuinstallieren muß, aber meinem Gefühl nach
ist das einiges (wenn es auch unproblematisch ist).

/ralph

[Sven Hartge]

Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de> wrote:

> Ich tippere gerade in unser internes Wiki, was man so alles nach
> einer Installation von Debian GNU/Linux auf einem Server noch
> umstellen sollte (quasi als Checkliste für zukünftige
> Installationen), und das kommt mir noch unvollständig vor:

> * bootlogd einschalten
> * ggf. cron und logrotate[0] installieren
> * smartd einrichten und einschalten
> * einen Mailserver für Warnmails einrichten (z. B. von cron und
> smartd)
> * ntpd einrichten
> * screen und ssh installieren
> * unnötige Konsolen aus der inittab werfen
> * automatische Reparatur beim fsck einschalten
> * wichtige Locales einrichten

* ssh-pub-key vom Admin nach /root/.ssh/authorized_keys bzw.
/home/$adminuser/.ssh/authorized_keys schreiben
* logcheck installieren
* korrekten Alias für System-Mails in /etc/aliases einrichten
* portmap und nfs-common entfernen
* aptitude purge ~c am Ende durchführen
* System zwei Mal rebooten und prüfen, ob das auch funktioniert
* os-prober entfernen (braucht auf einem Server kein Mensch)
* memtest86 bzw. memtest86+ installieren, man weiss nie, wann man es
braucht (entfällt bei virtuellen Servern)
* apticron installieren
* apt-listbugs installieren
* apt-listchanges installieren, dabei darauf achten, dass man nicht nur
NEWS.Debian sondern auch die Changelogs angezeigt bekommt.
* Screensaver der Text-Konsole abschalten
In /etc/kbd/kbd-config einstellen:
BLANK_TIME=0
BLANK_DPMS=on
# (ja, das heißt _wirklich_ BLANK_DPMS=on!)
POWERDOWN_TIME=0
* syslog konfigurieren, dass *.* nach /dev/tty8 geloggt wird
(in gesharten Hosting-Situationen überdenken, z.B. bei Hetzner oder
Strato)
* sofern vorhanden: syslog mit zentralem Logging-Aggregator
konfigurieren
* debconf auf "low" umstellen: dpkg-reconfigure -plow debconf
* etckeeper installieren
* "quiet" aus /etc/default/grub entfernen und dann update-grub
* VERBOSE=yes in /etc/default/rcS setzen
* FSCKFIX=yes in /etc/default/rcS setzen
* bei virtuellen Servern: Support-Tools installieren, also open-vm-tools
bei VMware, etc.
* "apt-get clean" laufen lassen, um heruntergeladene Pakete zu entfernen

Grüße,
Sven.

--
Sigmentation fault. Core dumped.

[Christoph 'Mehdorn' Weber]

Hallo!

* Sven Hartge <sh-...@svenhartge.de>:

> * ssh-pub-key vom Admin nach /root/.ssh/authorized_keys bzw.
> /home/$adminuser/.ssh/authorized_keys schreiben

Stimmt. Da ein ssh-copy-id immer der Erste Schritt nach der
Installation ist (und noch dazu auf einem anderen Rechner
passiert, vergesse ich den gern zu erwähnen.

> * logcheck installieren

> * sofern vorhanden: syslog mit zentralem Logging-Aggregator
> konfigurieren

Ich benutze seit einiger Zeit bevorzugt tenshi, wenn ich es mir
ressourcenmäßig[0] leisten kann. Im Zweifel aber als zentrales
System und nicht pro Host. Sowohl lokal als auch zentral lohnt
sich IHMO nicht und erhöht nur den Verwaltungsaufwand, besonders,
wenn verschiedene Tools am Werk sind und man somit Konfigdateien
nicht übernehmen kann.

> Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de> wrote:
>> * einen Mailserver für Warnmails einrichten (z. B. von cron und
>> smartd)

> * korrekten Alias für System-Mails in /etc/aliases einrichten

Ok, das war bei mir mit Mailserver einrichten gemeint. Bei der
Installation selbst muß man sonst selten mehr als maximal einen
Smarthost eingeben.

> * portmap und nfs-common entfernen

> * os-prober entfernen (braucht auf einem Server kein Mensch)

Bei einer Minimalinstallation sind die nicht dabei. Glaube, da
muß man mindestens "Standard" bei Tasksel oder dem Äquivalent im
Installer auswählen.

> * aptitude purge ~c am Ende durchführen

Ich purge üblicherweise gleich, statt einfach zu deinstallieren.
Es sei denn, ich will die Konfiguration wirklich behalten -- bei
einer Neuinstallation kommt das aber quasi nicht vor.

> * System zwei Mal rebooten und prüfen, ob das auch funktioniert

Stimmt. Wieder etwas, was ich zwar gemacht, aber nicht
dokumentiert habe.

> * Screensaver der Text-Konsole abschalten

Da geht es dir darum, daß man den Oops noch sieht, wenn die
Tastatur nicht mehr zum Aufwecken genügt? Oder gibt es Probleme
mit KVM-Geräten, die mir noch nicht aufgefallen sind?

> * syslog konfigurieren, dass *.* nach /dev/tty8 geloggt wird

Mache ich auch gern, wobei ich inzwischen bei *.notice (und bei
syslog-ng bei zusätzlichen Filtern) angekommen bin.

> * etckeeper installieren

Hatte ich mir bisher noch nicht angesehen, da ich mit dem
bisherigen Verhalten bei Debian zufrieden war (nachfragen und
ggf. neue Datei erst einmal danebenlegen) und hinterher mit
vimdiff durch /etc wusele. In Kombination mit wöchentlichem
Backup hatte ich da bisher keine Probleme. Oder geht es gar
nicht um plattgebügelte Konfigs?

> * "quiet" aus /etc/default/grub entfernen und dann update-grub
> * VERBOSE=yes in /etc/default/rcS setzen

Stimmt, ein etwas eigenwilliger Default seit Squeeze. Und
üblicherweise setze ich auch gleich "CONCURRENCY=none" --
wesentliche Geschwindigkeitsvorteile hatte ich bei "makefile"
bisher nicht, aber den Nachteil, daß man Fehlermeldungen
teilweise schwerer zuordnen konnte.

>> * automatische Reparatur beim fsck einschalten

> * FSCKFIX=yes in /etc/default/rcS setzen

Das war damit gemeint.

Christoph

[0] Logcheck wird regelmäßig von cron aufgerufen, durchsucht die
Logfiles und verschickt nicht-uninteressante Meldungen per
E-Mail. Tenshi läuft ständig und hängt per tail auf den Logs,
kann also bestimmte Meldungen ggf. sofort verschicken. Zudem
kann es Aggregieren und Schwellwerte (konnte logcheck beim
letzten Angucken noch nicht) -- kostet natürlich permanent
Speicher, umso mehr je mehr nichtgefilterten Meldungen im
Berichtszeitraum anfallen.

--
Er meint Leute, die den Webserver auf der Linuxkiste laufen
haben und die X-Box zum Spielen verwenden, anstatt Wochen
ihres Lebens dafuer zu investieren, dass es umgekehrt geht.
(Thomas Themel)

[Sven Hartge]

Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de> wrote:
> * Sven Hartge <sh-...@svenhartge.de>:

>> * ssh-pub-key vom Admin nach /root/.ssh/authorized_keys bzw.
>> /home/$adminuser/.ssh/authorized_keys schreiben

> Stimmt. Da ein ssh-copy-id immer der Erste Schritt nach der
> Installation ist (und noch dazu auf einem anderen Rechner passiert,
> vergesse ich den gern zu erwähnen.

Ich habe $hier für bestimmte Schritte, unter anderem den obigen, ein
kleines Shell-Script, dass dieses durchführt und noch ein paare andere
Dinge treibt.

Zu puppet oder cfengine konnte ich mich bisher nicht durchringen.

>> * portmap und nfs-common entfernen
>> * os-prober entfernen (braucht auf einem Server kein Mensch)

> Bei einer Minimalinstallation sind die nicht dabei. Glaube, da
> muß man mindestens "Standard" bei Tasksel oder dem Äquivalent im
> Installer auswählen.

Ich nutze meist "Standard" und "SSH Server", da ich aus eigener
Erfahrung fast alle Pakete aus Standard eh nachinstalliere, mit Ausnahme
der beiden oben genannten. In Wheezy sind diese dann auch nicht mehr
dort enthalten, IIRC.

>> * aptitude purge ~c am Ende durchführen

> Ich purge üblicherweise gleich, statt einfach zu deinstallieren.
> Es sei denn, ich will die Konfiguration wirklich behalten -- bei
> einer Neuinstallation kommt das aber quasi nicht vor.

>> * System zwei Mal rebooten und prüfen, ob das auch funktioniert

> Stimmt. Wieder etwas, was ich zwar gemacht, aber nicht
> dokumentiert habe.

>> * Screensaver der Text-Konsole abschalten

> Da geht es dir darum, daß man den Oops noch sieht, wenn die
> Tastatur nicht mehr zum Aufwecken genügt? Oder gibt es Probleme
> mit KVM-Geräten, die mir noch nicht aufgefallen sind?

Ja und ja. Teilweise spacken manche KVMs (nicht-reproduzierbar) ab, wenn
der Host via DPMS den Schirm abschaltet und leiten dann auch keine
Tastendrücke mehr durch.

>> * etckeeper installieren

> Hatte ich mir bisher noch nicht angesehen, da ich mit dem bisherigen
> Verhalten bei Debian zufrieden war (nachfragen und ggf. neue Datei
> erst einmal danebenlegen) und hinterher mit vimdiff durch /etc wusele.
> In Kombination mit wöchentlichem Backup hatte ich da bisher keine
> Probleme. Oder geht es gar nicht um plattgebügelte Konfigs?

Auch. Und um Änderungen, selbst gewollte, nachvollziehen zu können.

>> * "quiet" aus /etc/default/grub entfernen und dann update-grub
>> * VERBOSE=yes in /etc/default/rcS setzen

> Stimmt, ein etwas eigenwilliger Default seit Squeeze. Und
> üblicherweise setze ich auch gleich "CONCURRENCY=none" -- wesentliche
> Geschwindigkeitsvorteile hatte ich bei "makefile" bisher nicht, aber
> den Nachteil, daß man Fehlermeldungen teilweise schwerer zuordnen
> konnte.

"quiet" und "VERBOSE=no" kann ich bei Desktop-Systemen ja durchaus
nachvollziehen und damit auch den Default von Debian. Bei Servern will
man aber normalerweise sehen, was das Ding treibt.

S°

[Christoph 'Mehdorn' Weber]

Hallo!

* Sven Hartge <sh-...@svenhartge.de>:

> Ich habe $hier für bestimmte Schritte, unter anderem den obigen, ein
> kleines Shell-Script, dass dieses durchführt und noch ein paare andere
> Dinge treibt.

Ich noch nicht. Aber ich überlege, ob ich mir mal ein
Konfig-Paket baue.

Andererseits habe ich bereits einen Installer auf Basis von
debootstrap, der automatische den lokalen Mirror nimmt,
Wunschlocales baut, Postfix einrichtet, bootlogd und aptitude
vorkonfiguriert und diverse Pakete installiert, die ich immer
haben will. Möglicherweise sollte ich den einfach aktualisieren
(baut derzeit noch ein Lenny) und generalisieren.

> Zu puppet oder cfengine konnte ich mich bisher nicht durchringen.

Ich hatte beides mal angetestet und dann stattdessen ein
Subversion gebaut, wo ich Dateien in /etc, die über mehrere
Rechner verfügbar werden sollen, dann einfach hinlinke. Das
reicht bisher für meine Bedürfnisse.

> Teilweise spacken manche KVMs (nicht-reproduzierbar) ab, wenn
> der Host via DPMS den Schirm abschaltet und leiten dann auch
> keine Tastendrücke mehr durch.

Interessant. Ich notiere mir mal, das bei der Problem-KVM im
Verein zu testen.

>>> * "quiet" aus /etc/default/grub entfernen und dann update-grub
>>> * VERBOSE=yes in /etc/default/rcS setzen
>> Stimmt, ein etwas eigenwilliger Default seit Squeeze.

> "quiet" und "VERBOSE=no" kann ich bei Desktop-Systemen ja durchaus
> nachvollziehen und damit auch den Default von Debian. Bei Servern will
> man aber normalerweise sehen, was das Ding treibt.

IHMO bei Workstations auch. Sonst ist das fast wie bei Windows,
wo man vor dem Startbildschmirm sitzt und nicht weiß, warum man
Däumchen dreht oder ob etwas schiefläuft.

Neulich hatte ich den Fall, wo ein Tool beim Initvorgang ein
neues SSL-Zertifikat gebaut[0] hat, weil das alte abgelaufen war.
Als Anwender wartet man dann eine halbe Stunde vor dem Schirm, bis
endlich genug Entropie zusammen ist, und wundert sich, was seit
gestern so plötzlich anders ist.

Wird die Meldung nicht versteckt, sieht man wenigstens, worauf
man gerade warten muß.

Christoph

[0] Zugegeben, hätte man ein richtiges Zertifikat eingeworfen
statt self-signed zu nehmen, wäre das nicht passiert.

--
Was zum Geier ist Stochastik? --
Schaetzen lernen.

[Sven Hartge]

Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de> wrote:

> Hallo!

> * Sven Hartge <sh-...@svenhartge.de>:

>> Ich habe $hier für bestimmte Schritte, unter anderem den obigen, ein
>> kleines Shell-Script, dass dieses durchführt und noch ein paare andere
>> Dinge treibt.

> Ich noch nicht. Aber ich überlege, ob ich mir mal ein Konfig-Paket
> baue.

> Andererseits habe ich bereits einen Installer auf Basis von
> debootstrap, der automatische den lokalen Mirror nimmt, Wunschlocales
> baut, Postfix einrichtet, bootlogd und aptitude vorkonfiguriert und
> diverse Pakete installiert, die ich immer haben will. Möglicherweise
> sollte ich den einfach aktualisieren (baut derzeit noch ein Lenny)
> und generalisieren.

Das steht bei mir auf der Liste. Eine Preseed-Datei, die nötige Dinge
vorab schon konfiguriert. Wie üblich: aus Zeitmangel bisher nicht
gemacht.