Gibt es Bücher über Linux-Webserveradministration?
-
@nman,
Ok, danke. Kannst du das von nachtfeuer vorgeschlagene Buch ebenfalls empfehlen? Oder hättest du andere Vorschläge?Grüssli
-
Dravere schrieb:
Ok, danke. Kannst du das von nachtfeuer vorgeschlagene Buch ebenfalls empfehlen? Oder hättest du andere Vorschläge?
Die Sachen, die ich damals gelesen habe, sind alle uninteressant weil komplett veraltet. Spezifische Webserver-Literatur habe ich bis dato keine gelesen, der Amberg sieht als allgemeiner Admin-Einstieg ganz brauchbar aus.
Hiervon habe ich auch schon einige gute Sachen gehört:
UNIX and Linux System Administration Handbook | ISBN: 9780131480056Anfängertaugliche Bücher oder Tutorials habe ich in den letzten Jahren eigentlich keine mehr gelesen. Ab einem gewissen Wissensstand tut man sich außer mit viel Doku, diversen Artikeln und ein paar Blogs recht schwer, neue Sachen zu finden.
Weißt du schon irgendwelche Details zu dem System, das du aufsetzen wirst? Wenn das System halbwegs straightforward ist, wirst du dir vmtl. mit dem Setup auch nicht so schwer tun; die Distro-Defaults sind heutzutage meistens schon unheimlich gut und benutzbar.
Hol dir einfach eines der Bücher und spring in's kalte Wasser, das ist für technisch halbwegs versierte User wohl kein schlechter Einstieg. Für den Start vielleicht noch folgende Tips, die dir die Arbeit erleichtern könnten:
- Wenn du die Möglichkeit dazu hast, unbedingt auf irgendeine Art von out-of-band management achten. Das kann via Webinterface und SSH-Zugang zu einer seriellen Konsole oder via KVM-over-IP oä. sein; Hauptsache du hast auch dann noch Zugriff auf das System, wenn deine NIC gerade Schwierigkeiten macht, du dich via iptables ausgesperrt hast, der neue Kernel nicht sauber bootet oä.
- Für Server unbedingt LTS (Ubuntu) bzw. stable-Releases (Debian) verwenden. Bei Debian ist gerade die nächste stable Version (Wheezy) im Feature Freeze, dh. da ist die Entscheidung gerade nicht ganz so leicht wie sonst.
- Ganz am Anfang sofort mal man: etckeeper installieren (
sudo apt-get install git-core etckeeper
) und in die/etc/etckeeper.conf
sowas rein:
VCS='git' HIGHLEVEL_PACKAGE_MANAGER=apt LOWLEVEL_PACKAGE_MANAGER=dpkg
Damit wird dein /etc versionskontrolliert, dh. falls du irgendwas zerschießt, ist das Debuggen und ein Rollback leichter.
- Nach Möglichkeit keine Software am Paketmanager vorbeiinstallieren. Falls irgendwo die Distro-Version zu alt ist, suche dir eine geeignete Version aus den Backports für dein Distro-Release oder ein gut gepflegtes PPA oä. Ohne Paketmanager installierte Software ist auf Dauer einfach nicht wartbar und der häufigste Grund für irgendwelche dummen Sicherheitslücken.
- unattended-upgrades für sicherheitsrelevante Updates nutzen. (Und nach Möglichkeit nur für sicherheitsrelevante Updates; die anderen kannst du selbst einspielen.)
- Liste von unheimlich praktischen Tools für (fast) jeden Tag: Midnight Commander (mit mcedit ist da auch ein recht brauchbarer anfängertauglicher Editor dabei), tmux (besser als GNU screen), rsync, rdiff-backup. Zum alltäglichen Debuggen noch strace, lsof und tcpdump.
War jetzt recht unstrukturiert, aber vielleicht hilft dir das ja trotzdem ein bisschen.
-
Ich weiss jetzt genauer was ich habe. Ist ein Ubuntu 9.10. Heisst Support dafür ist seit über einem Jahr eingestellt. Jetzt darf ich zuerst mal rausfinden, wie ich hier am besten ein Upgrade auf 12.04 hinbekomme, ohne den laufenden Betrieb zu stark zu stören. Wobei mir auffiel, dass ich noch nie ein Upgrade nur über SSH Zugang gemacht habe, also ohne die Sicherheit zu haben, mit z.B. einer CD mich zu retten...
Kann man eigentlich eine Neuinstallation per SSH machen? Wohl kaum, oder? Dann muss ich also ein Upgrade auf 10.04 und dann ein weiteres auf 12.04 machen?
*seufz*
Das Wasser ist sehr kaltDanke für die bisherige Hilfe.
Grüssli
-
Dravere schrieb:
Kann man eigentlich eine Neuinstallation per SSH machen? Wohl kaum, oder? Dann muss ich also ein Upgrade auf 10.04 und dann ein weiteres auf 12.04 machen?
Doch, schon. Ist aber eher was für Fortgeschrittene und wird den Betrieb garantiert recht nachhaltig unterbrechen. Upgrade auf 10.04 und dann auf 12.04 klingt sinnvoll.
-
nman schrieb:
Dravere schrieb:
Kann man eigentlich eine Neuinstallation per SSH machen? Wohl kaum, oder? Dann muss ich also ein Upgrade auf 10.04 und dann ein weiteres auf 12.04 machen?
Doch, schon. Ist aber eher was für Fortgeschrittene und wird den Betrieb garantiert recht nachhaltig unterbrechen. Upgrade auf 10.04 und dann auf 12.04 klingt sinnvoll.
Wobei...
http://www.heise.de/open/news/foren/S-upgrade-Probleme-und-kaputte-software-nach-dessen-hat-bei-Ubuntu-System/forum-227378/msg-21793080/read/
und
http://www.youtube.com/watch?v=3zxxypeXvZY
-
Ubuntu 10.04 Desktop hat nur noch Support für wenige Monate, bis April 2013. Es wäre also ziemlich unklug, ein 10.04 System in den nächsten Monaten nicht zu aktualisieren, und noch unklüger wäre es, ein 10.04-System neu zu installieren.
Ubuntu 10.04 Server hat noch bis 2015 Support, das kann man also noch gut eine Weile verwenden. Aber die Software ist halt veraltet. Je nachdem, was man vorhat, kann es einfacher sein, gleich 12.04 zu nehmen.
Solange man sich an LTS-Releases hält, gibt es auch viel weniger Probleme.
Bei Ubuntu 12.04 hat diesmal sogar die Desktop-Version extra-langen Support bis 2017. Wer also mit Upgrades auf Kriegsfuß steht, dem würde ich immer zu 12.04 raten, dann hat man bis 2017 seine Ruhe.
-
nachtfeuer schrieb:
Ok, also _irgendein Heise-Forums-User_ mag 12.04 nicht. Was soll uns das jetzt sagen?
Ehrlich, wenn von Schwierigkeiten mit dem Update die Rede ist, wird es in der Regel um Desktop-Zeug gehen. Zum Beispiel um Unity oä.
Bei Upgrades von LTS zu LTS gibt es normalerweise einfach keine Probleme und bei den Zwischenversionen (die ich aber am Server normalerweise ohnehin auslassen würde) gibt es auch höchstens trivialen Kleinmist zu reparieren.
-
Ufff ... der Server.
Backup wurden bisher in/backup/data
gemacht. Auf die 10GB Root-Partition. Seit 10 Tagen gehen die Backups nicht mehr. Ratet mal wieso? Genau, die Partition ist voll.Ist sowas normal? 6 Partitionen?
Filesystem Size Used Avail Use% Mounted on /dev/md2 10G 10G 0 100% / udev 4.0G 252K 4.0G 1% /dev none 4.0G 0 4.0G 0% /dev/shm none 4.0G 92K 4.0G 1% /var/run none 4.0G 0 4.0G 0% /var/lock none 4.0G 0 4.0G 0% /lib/init/rw /dev/md3 15G 1.2G 14G 8% /usr /dev/md4 15G 11G 4.0G 72% /var /dev/md5 10G 179M 9.3G 2% /tmp /dev/md6 638G 11G 595G 2% /home /dev/md1 2.0G 97M 1.8G 6% /boot
Auch
/var
mit 15 GB, wo die MySQL DB drin liegt, erscheint mir irgendwie wenig sinnvoll und die 72% Use alarmierend. Erst recht wenn daneben im/home
ca. 600GB brach liegen. Kann man sowas auf einfache Weise resizen? Also nicht wegen der Root-Partition. Die Backups gehen in Zukunft anderswo hin. Ich meine ... Backups auf der gleichen Festplatte? Wirklich?Grüssli
-
Yay. fdisk like it's 1999.
Resizen ist in solchen Faellen (ohne LVM) unschoen.
Ein Backup auf die selbe Platte ist schon besser als gar keines; einfach weil du damit ein bisschen "rm -rf"-Schutz hast. Eine eigene Partition haette aber auch nicht mehr wehgetan, zumal du ja schon siebzehn andere hast.
Ist zwar haesslich, aber du musst wohl mit dem arbeiten, was du bekommst. Also einfach
/dev/md6
zur Root-Partition umwidmen. Moeglichst nicht im laufenden Betrieb.(
/home
kann ja weiterhin dortliegen, aber eben eine Verzeichnisebene tiefer.)
-
Hmmm, wäre eine Möglichkeit. Ich überlege mir allerdings auch, einfach ein paar Konfigurationen umzustellen. Zum Beispiel die MySQL DB in ihren eigenen Home-Folder zu schreiben. Auch das MySQL Binary Log in diesen Home-Folder umbiegen. Damit sollte viel Speicherplatz unter
/var
freigegeben werden.
Die Backups selbst habe ich temporär jetzt mal in meinen eigenen Home-Folder umgeleitet und ein paar alte Backups im Root freigegeben.Naja, irgendwie wird es schon gehen...
Und vielleicht irgendwann später (mehrere Jahre) einmal, könnte man den Server dann doch neu aufsetzen
Danke für die Hilfe.
Grüssli
-
Dravere schrieb:
Ich überlege mir allerdings auch, einfach ein paar Konfigurationen umzustellen. Zum Beispiel die MySQL DB in ihren eigenen Home-Folder zu schreiben. Auch das MySQL Binary Log in diesen Home-Folder umbiegen.
Wenn der Binary-Log viel Platz braucht, solltest du vielleicht an der Log-Expiration (also
expire_logs_days
) drehen.Und vielleicht irgendwann später (mehrere Jahre) einmal, könnte man den Server dann doch neu aufsetzen
Klar, genauso macht man das. Zuerst mal Brände löschen und sich dabei ansehen, was einfach unsauber ist und was wirklich im Betrieb Schwierigkeiten macht.
Und in ein paar Jahren wirst du sowieso den Server upgraden wollen, da kannst du dann den neuen einrichten, während der alte weiterläuft und irgendwann auf ein saubereres neues System umziehen.
-
Habe heute das von nachtfeuer empfohlene Buch erhalten. Nach einem ersten überfliegen, scheint es genau das zu sein, was ich gesucht habe. Daher nochmals vielen Dank!
Grüssli