[0:00] Herzlich willkommen zum Anwendungsentwickler-Podcast, dem Podcast rund um die Ausbildung zum Fachinformatiker

[0:10] für Anwendungsentwicklung. In dieser Episode geht es um die Konfiguration deines Linux-Servers.

[0:16] Viel Spaß!

[0:20] Hallo und herzlich willkommen zur 91. Episode des Anwendungsentwickler-Podcasts.

[0:26] Mein Name ist Stefan Macke und heute beende ich hoffentlich meine kleine Reihe zum Einrichten deines eigenen Linux-Servers.

[0:34] Hoffentlich, weil ich wie immer kaum glaube, dass ich die Zeit einhalten werde.

[0:38] Habe ich zumindest in den letzten Episoden ja auch fast nie geschafft.

[0:41] Aber heute versuche ich es einfach mal, diese Episodenreihe so ein bisschen zu beenden.

[0:45] Denn ich glaube, wir haben noch ein paar andere Themen, die wir als Anwendungsentwickler auch so drauf haben müssen.

[0:49] Ich finde es zwar wichtig, dass du deinen eigenen Server einrichtest.

[0:51] Aber ich glaube, so langsam könnten auch mal wieder ein paar andere Themen hier durchsprechen.

[0:55] Deswegen gebe ich mal ein bisschen Gas und wir schauen mal, dass wir heute diese erste Reihe zum Thema eigener Linux-Server abschließen.

[1:03] Ich habe noch ein paar Sachen auf der Agenda, deswegen lehnen wir gleich los.

[1:06] Aber bevor wir mit dem Inhalt anfangen, sage ich einmal ganz vielen Dank in Richtung Robin.

[1:10] Das ist einer meiner Zuhörer und der hat zu den vergangenen Linux-Server-Episoden einiges an Kommentaren geschrieben.

[1:17] Vielen, vielen Dank dafür!

[1:18] Unter anderem kann ich da noch zwei Nachträge liefern zu meinen vorherigen Episoden.

[1:23] Denn er hat mich auf zwei ganz tolle Sachen hingewiesen.

[1:26] Und zwar einmal auf die Möglichkeit, die Debian-Updates nächtlich auch automatisch durchführen zu lassen.

[1:32] Also komplett installieren zu lassen, ohne manuell eingreifen zu müssen.

[1:35] Und sogar den Server automatisch neu zu starten, falls das notwendig ist.

[1:40] Das Ganze nennt sich Unattended Upgrades und den Link dazu habe ich in den Shownotes auf der Seite hinterlegt.

[1:47] Du kannst wie immer darauf zugreifen unter anwendungs-entwickler-podcast.de-91 für die 91. Episode.

[1:54] Und das Zweite, was er mir auch empfohlen hat, ist der ETC-Keeper.

[1:59] Das ist ein kleines Skript, was es etwas schöner ermöglicht, das ETC-Verzeichnis mit Git zu versionieren.

[2:06] Mein persönlicher Tipp war ja genau das zu tun, damit du nach Updates oder vor Konfigurationsänderungen, vor Experimenten usw.

[2:14] Deinen Stand sichern kannst und danach wieder auf einen lauffähigen Stand zurück kannst.

[2:17] Aber zu Recht hat mich Robin darauf hingewiesen, dass dabei natürlich auch einige Sachen in Git versioniert werden,

[2:24] die normale Benutzer vielleicht nicht unbedingt sehen sollten.

[2:26] Wie z.B. die Passwortdatei, etc.passwd bzw.shadow.

[2:31] Und über Git wäre es dann möglich, dass eventuell nicht autorisierte Benutzer da reinschauen könnten.

[2:38] Das war mir bewusst. Ich mache das allerdings seit langer Zeit manuell,

[2:43] indem ich bestimmte Dateien in die .gitignore-Datei eintrage, damit die gar nicht erst versioniert werden.

[2:49] Aber damit man das nicht alles händisch machen muss, gibt es halt diesen netten ETC-Keeper und der macht das Ganze viel, viel einfacher.

[2:56] Vielen Dank für die beiden Tipps. Ich habe beides in den Shownotes verlinkt.

[2:59] Wie gesagt, schau doch mal rein und wenn du magst, sag dem Robin auch nochmal Danke von mir.

[3:04] Finde ich super klasse, dass ich Feedback kriege, auch zu den Inhalten hier.

[3:08] Wenn du noch irgendwas dazu beitragen kannst, dass die Server da draußen noch sicherer werden,

[3:13] dann schreib mir gerne einen Kommentar zur Episode.

[3:16] Ich freue mich immer über deine Rückmeldung und ich würde das auch ganz sicherlich in einer der nächsten Episoden einbauen,

[3:22] wenn noch was Schönes von dir kommt. Also, würde mich freuen, wenn du dich meldest.

[3:27] So, dann kommen wir jetzt aber zu den Inhalten, die ich vorbereitet habe für die heutige Episode.

[3:32] Und zwar, nachdem wir jetzt beim letzten Mal ja unsere ganzen Pakete aktualisiert haben und auf den neuesten Stand gebracht haben,

[3:40] abgesichert haben, Sachen runtergeschmissen haben, die wir nicht brauchen und so weiter,

[3:43] geht es jetzt weiter mit dem nächsten Schritt in Richtung sicherer Server.

[3:46] Und das ist auf jeden Fall die Installation und Konfiguration einer Firewall.

[3:51] Das ist eine sehr wichtige Komponente, die du sicherlich auf deinem Server betreiben solltest.

[3:56] Wie du hoffentlich schon weißt aus der Ausbildung oder woanders her, blockiert die Firewall unerwünschte Zugriffe über das Netzwerk auf deinen Server.

[4:05] Und genau so würde ich die Firewall auch erstmal konfigurieren.

[4:08] Nämlich, erstmal so Daumenregel, alles explizit ausschließen, was nicht erwünscht ist.

[4:14] Das heißt, wir machen, wie gesagt, erstmal alles dicht, damit auf keinen Fall irgendwo was reinkommt, was wir eventuell vergessen haben.

[4:21] Und wir machen nur das auf, was wir wirklich haben wollen.

[4:24] Im Zweifel sind das nur die Sachen, die du wirklich benutzt, also SSH, HTTP, IMAP, was auch immer du auf deinem Server da betreibst.

[4:30] Und alles andere wird erstmal kategorisch ausgeschlossen, damit da niemand irgendwie über irgendeinen Dienst,

[4:36] der eventuell doch noch läuft, den du vergessen hast oder wie auch immer, da irgendwie reinkommt.

[4:40] Und selbst wenn es dann vielleicht noch irgendeine Schadsoftware gibt, die sich auf deinem Server einnistet,

[4:44] dann hoffen wir mal, dass die Firewall eventuelle Kommunikationsversuche mit diesem Teil dann unterbindet,

[4:51] weil sie einfach alles abblockt, was nicht explizit freigeschaltet ist.

[4:54] Das ist auch eine gute Idee grundsätzlich bei Sicherheitseinstellungen.

[4:57] Gehen wir mal so ein bisschen auch in den Bereich wieder prüfungsrelevantes Wissen.

[5:01] Es gibt ein sogenanntes Whitelisting und ein Blacklisting.

[5:05] Blacklist, das ist eine Liste, auf der die bösen Buben stehen.

[5:09] Das heißt, da würde dann zum Beispiel die Firewall draufgucken und sagen,

[5:12] oh, alle Ports, die auf dieser Blacklist stehen, die lasse ich nicht durch.

[5:15] Das Whitelisting wäre genau das Gegenteil.

[5:18] Darauf stehen dann zum Beispiel die Ports, die erlaubt sind.

[5:21] Und grundsätzlich, würde ich jetzt einfach mal so pauschal behaupten,

[5:24] ist ein Whitelisting erstmal immer sicherer als ein Blacklisting.

[5:28] Denn ein Blacklisting bedeutet, dass du explizit alles aufführen musst, was du nicht haben willst.

[5:33] Und ein Whitelisting, da musst du das aufführen, was du haben willst und alles andere ist erstmal pauschal blockiert.

[5:38] Und das ist ähnlich wie bei Spam-Inhalten.

[5:41] Anstatt zu sagen, ich vertraue erstmal dem Internet und schließe einfach diese 1000 Server aus,

[5:47] die potenziell Spam versenden, dann wäre das eine Blacklist.

[5:51] Aber da diese 1000 Server wahrscheinlich jeden Tag um hunderte zusätzlicher Server anwachsen,

[5:56] kommst du mit dem Pflegen dieser Blacklist einfach nie hinterher.

[5:59] Viel einfacher ist es, wenn du eine Whitelist machst und sagst,

[6:02] das sind meine bekannten Server, die erlaube ich für die Kommunikation

[6:05] und alles andere ist erstmal komplett blockiert.

[6:08] Und genau so würde ich auch die Firewall einrichten.

[6:10] Also eine Whitelist für alle Ports oder alle Verbindungen, die du haben möchtest

[6:14] und alles andere wird erstmal ausgeschaltet.

[6:16] Das ist immer erstmal die sichere Variante, weil du heute vielleicht noch gar nicht weißt,

[6:20] was es morgen und übermorgen vielleicht für Angriffe gegen deinen Server gibt oder gegen irgendwelche Ports.

[6:25] Oder du probierst irgendwas aus und dann öffnet ein Programm doch irgendwie einen Port,

[6:29] an den du nicht gedacht hast und so weiter und so fort.

[6:31] Da kommst du mit dem Pflegen gar nicht mehr hinterher.

[6:33] Ich würde immer sagen, alles blockieren und nur wenn du etwas Neues da hinzufügst,

[6:38] zum Beispiel jetzt doch deinen FTP-Server aufmachst, weil du ihn betreiben möchtest,

[6:41] dann musst du diesen einen zusätzlichen Port in die Firewall eintragen und dann ist Feierabend.

[6:46] Unter Linux gibt es eigentlich eine schöne eingebaute Firewall, die ich auch absolut empfehlen kann,

[6:50] die ich auch selber betreibe, die heißt IP-Tables.

[6:53] Die ist sehr verbreitet, da gibt es super viele Tutorials zu und auch ganz viele tolle Anleitungen,

[6:58] vor allem im Internet und auch sehr schöne detaillierte Beschreibungen für das Scripting der Firewall,

[7:03] denn die muss zum Beispiel auch automatisch gestartet werden, wenn dein System hochfährt und so weiter.

[7:07] Das kannst du alles kostenfrei natürlich im Internet nachlesen.

[7:10] Ich habe auch einige passende Links dazu in den Shownotes hinterlegt.

[7:14] Da gibt es zum Beispiel 20 konkrete Beispiele, gerade für neue Sys-Admins und auch mit Erklärungen,

[7:20] wie die denn funktioniert und worauf man achten sollte und was die komischen,

[7:24] wie heißen die? Das weiß ich selber schon gar nicht mehr, wie die heißen.

[7:27] Die Queues heißen sie, glaube ich, die Forward und die Inbound oder Input und Output Queue und so weiter.

[7:33] Nein, sorry, jetzt muss ich doch nachgucken. Die heißen nicht Queues, die heißen Chains

[7:38] und die heißen bei IP Table die Input, Forward und Output Chain.

[7:42] Es gibt aber noch weitere, je nachdem, ob du zum Beispiel NAT benutzen willst,

[7:45] das Network Address Translation, wenn du zum Beispiel VMs auf deinem Server betreibst,

[7:49] wobei das wahrscheinlich nicht funktioniert wird, weil du ja auf einer VM arbeitest.

[7:53] Aber für meinen Server zum Beispiel, ich habe einen echten Server im Internet stehen,

[7:56] wo ich dann quasi selber VMs drauf betreibe und wenn die auch mit dem Internet kommunizieren sollen,

[8:02] dann brauchst du vielleicht so einen Network Address Translation.

[8:05] Aber für den Einstieg auf deinem eigenen V-Server, da willst du keine anderen virtuellen Maschinen drauf betreiben,

[8:11] reicht es also völlig aus, die Input und Output Chain zu berücksichtigen.

[8:15] Ich will hier aber auch nicht zu sehr ins Detail reingehen, denn das kann man im Audioformat einfach schlecht rüberbringen.

[8:20] Da gibt es tausende Websites und wahrscheinlich auch Videos ohne Ende online, die du dir reinziehen kannst zu dem Thema.

[8:25] Oder du guckst halt einfach mal in den CoFloor, das Buch, was ich jetzt schon seit drei Wochen empfehle dazu.

[8:30] Da gibt es auch ein umfassendes Kapitel zum Thema Firewall-Konfiguration.

[8:35] Und als Beispiel wird da auch tatsächlich IP-Tables benutzt.

[8:38] Also ein Grund mehr, das Ding zu verwenden.

[8:41] Denn es ist wirklich sehr weit verbreitet und auch, wenn man es einmal verstanden hat,

[8:44] relativ einfach zu konfigurieren und vor allem auch zu skripten.

[8:47] Also ich habe auch die komplette Firewall einfach in ein paar Shell-Skripts ausgelagert.

[8:52] Dann kann ich die mit einem Kommandozeilenbefehl starten, stoppen, umkonfigurieren und so weiter.

[8:56] Okay, das soll es jetzt erstmal zu Firewall gewesen sein.

[8:59] Also grundsätzlicher Tipp, alles dicht machen, Sachen explizit freischalten.

[9:02] Dann kann dir da erstmal relativ wenig passieren.

[9:05] Und IP-Tables ist eine sehr stabile, gute Firewall.

[9:07] Die sollte deinen Server erstmal sehr gut absichern von draußen.

[9:11] Sodass du jetzt eigentlich schon sehr, sehr sicher unterwegs bist mit deinem Server.

[9:15] Du hast dein SSH-Port umgelegt.

[9:17] Du hast nur noch die Ports offen, die wirklich nötig sind.

[9:19] Du hast auch nur noch die Dienste laufen, die nötig sind.

[9:21] Ich denke, das ist erstmal schon eine sehr gute Absicherung deines Servers.

[9:25] Aber als nächstes nochmal ein wichtiger Hinweis.

[9:29] Alle Dienste, die du jetzt nach außen hin freigibst, sollen mit einem hochsicheren Passwort geschützt werden.

[9:35] Ich hatte schon mal in einer der früheren Episoden darauf rumgeritten, wie ich meine Passwörter verwalte.

[9:40] Und dass ich also mir gar keine Passwörter mehr merke, sondern die alle in so einem Passwort-Safe habe.

[9:44] Und das würde ich hier auch absolut empfehlen.

[9:46] Gerade für so kritische Sachen wie zum Beispiel den SSH-Zugang.

[9:49] Den haben wir zwar eh mit dem Public Key abgesichert.

[9:52] Aber zum Beispiel so etwas wie deine MySQL-Datenbank, solltest du eine betreiben.

[9:56] Oder heute wäre es ja eher die MariaDB zum Beispiel.

[9:59] Oder meinetwegen Postgres, ist mir ganz egal.

[10:01] Aber wenn du da irgendeine Datenbank laufen hast, dann solltest du die auf jeden Fall auch mit einem sicheren Kennwort absichern.

[10:06] Denn wenn jemand auf deinen Server kommt und er möchte gerne deine Daten ausspähen.

[10:11] Keine Ahnung, vielleicht hast du irgendwelche E-Mail-Adressen oder sowas auf dem Server laufen.

[10:15] Oder was weiß ich, du betreibst einen Shop, da sind Kreditkarteninformationen drin.

[10:18] Solltest du nicht speichern, aber davon mal abgesehen.

[10:21] Dann hat derjenige vielleicht Zugriff auf deinen Server, wenn er dein Passwort erraten kann.

[10:25] Was nur drei Zeichen lang ist oder vielleicht sogar noch leer in der Standardinstallation.

[10:29] Also wenn du solche Sachen installierst, sei es FDP-Server oder eine Datenbank oder irgendwas.

[10:34] Wo Angreifer potenziell Zugriff drauf bekommen könnten von draußen.

[10:38] Die musst du unbedingt mit einem sicheren Passwort absichern.

[10:41] Auf keinen Fall die Standard-Passwörter eingestellt lassen oder sogar ein leeres Passwort vergeben.

[10:46] Das sind auf jeden Fall die Dinge, die Angreifer sofort ausprobieren werden.

[10:50] Und es gibt im Internet Listen ohne Ende mit bestimmten Standard-Passwörtern von beliebter Software.

[10:56] Sodass man nicht mal groß nachdenken muss.

[10:58] Ich kann einfach ein bisschen googeln und finde raus, was das Standard-Passwort für MySQL zum Beispiel ist.

[11:02] Und dann probe ich das aus und wenn du es nicht geändert hast, dann bin ich in deinem System.

[11:06] Das wäre also sehr, sehr unklug.

[11:08] Deswegen unbedingt sichere Passwörter vergeben.

[11:11] So, dann kommen wir jetzt mal zu so ein bisschen Optimierungen auf deinem Server.

[11:16] Was ich immer ganz gerne auch als eine der ersten Aktionen mache auf meinem Server ist, ein paar Optimierungen in der bashrc vornehmen.

[11:23] Es gibt eine schöne kleine Datei, die heißt .bashrc.

[11:27] Kleiner Ausflug zum Thema Prüfungswissen.

[11:30] Alle Dateien unter Linux, die mit einem Punkt im Namen beginnen, sind automatisch versteckt.

[11:36] Die Geschichte dazu ist ganz witzig, wie ich herausgefunden habe vor nicht allzu langer Zeit.

[11:43] Und zwar gab es damals einen Bug in dem Kommandozeilenbefehl zum Auflisten von Verzeichnisinhalten.

[11:49] Und unter Linux, wie auch übrigens unter Windows, wieder kleiner Ausflug in Richtung Prüfungswissen,

[11:54] ist immer das aktuelle Verzeichnis mit einem Alias mit Punkt belegt.

[11:59] Und das darüber liegende Verzeichnis, also mein Eltern- oder Basisverzeichnis, ist immer Punkt, Punkt.

[12:06] Also zwei Punkte hintereinander.

[12:08] Du wunderst, was diese Dinger heißen bei der Ausgabe, wenn du zum Beispiel dio unter Windows machst oder ls unter Linux.

[12:13] Das sind halt die Verzeichnisse. Das aktuelle ist Punkt und das übergeordnete ist Punkt, Punkt.

[12:19] Und da hat man sich damals dazu entschieden, dass man die nicht jedes Mal aufgelistet haben möchte, wenn ich zum Beispiel ls eingebe.

[12:25] Dann hat der Programmierer einfach eingebaut, wenn die Datei mit Punkt beginnt, dann zeigt sie nicht an.

[12:31] Das ist also quasi ein Bug, denn normalerweise wollte er eigentlich nur diese beiden Verzeichnisse ausschließen.

[12:36] Aber das führte dazu, dass insgesamt alle Dateien, die mit einem Punkt beginnen, nicht angezeigt wurden.

[12:42] Und über die Jahre hat sich das tatsächlich nicht als Bug, sondern als Feature etabliert, sodass jetzt also Leute wirklich davon ausgehen,

[12:49] wenn ich Dateien mit einem Punkt im Namen zu Beginn benenne, dann werden die halt nicht angezeichnet.

[12:55] Das ist also quasi der Standard, um unter Linux Dateien zu verstecken.

[12:59] Ich packe einfach einen Punkt zu Beginn des Namens rein und dann werden sie nicht angezeigt.

[13:04] Deswegen ist die Datei, die ich jetzt beschreibe, auch die bashrc mit einem Punkt vor dem Namen,

[13:10] denn die soll man erstmal standardmäßig nicht sehen, die will ich nicht immer angezeigt bekommen,

[13:13] weil das so eine Standardkonfigurationsdatei ist.

[13:15] Die muss da zwar liegen und soll verarbeitet werden, aber die will ich nicht jedes Mal sehen, wenn ich in meinem Home-Verzeichnis mir was angucke.

[13:20] Es geht also um die .bashrc in deinem Home-Verzeichnis.

[13:24] Dein Home-Verzeichnis ist das Verzeichnis, wo deine Dateien drin liegen.

[13:27] Das ist quasi vergleichbar mit deinem Benutzerverzeichnis unter Windows.

[13:30] Unter Windows liegt es halt unter C, Benutzer und dann dein Benutzername.

[13:35] Und unter Linux liegt das standardmäßig unter Slash, Home, Slash und dann dein Benutzername.

[13:39] Der Alias für dein Home-Verzeichnis ist übrigens die Tilde.

[13:42] Wenn du also sowas machst wie cd, Leerzeichen, Tilde, dann landest du automatisch in deinem Home-Verzeichnis.

[13:47] Wobei das geht noch kürzer, wenn du einfach nur cd, Enter machst, dann wechselt die bash zumindest automatisch in dein Home-Verzeichnis.

[13:53] Und da liegt die .bashrc und das ist die Datei oder sagen wir mal eine Datei, die die Bash automatisch aufmacht, durchliest und quasi ausführt, wenn du dich an dem Server anmeldest.

[14:07] Beziehungsweise noch allgemeiner, wenn du eine Bash, eine neue Shell startest.

[14:12] Ich will jetzt gar nicht im Detail darauf eingehen, wann du denn vielleicht mal eine Shell startest und wann nicht.

[14:16] Grundsätzlich kriegst du erstmal eine Shell gestartet, wenn du dich an deinem Server anmeldest.

[14:20] Und somit kannst du also dort Sachen hinterlegen, die quasi automatisch ausgeführt werden, sobald du dich am Server anmeldest.

[14:26] Dafür kannst du die .bashrc benutzen.

[14:28] Wie gesagt, es gibt noch andere Dateien, mit denen das möglich ist, aber die .bashrc ist so der Klassiker.

[14:34] Und da gehe ich als allererstes mal rein.

[14:36] Da ist unter so einem Standard-Linux auch schon so ein bisschen was vorkonfiguriert, was du an- oder ausschalten kannst, wenn du es haben willst oder nicht.

[14:42] Und ich gehe mal so ein paar Sachen durch, die ich immer ganz gerne als erstes mache, damit ich einfach ein bisschen schneller mit der Konsole arbeiten kann.

[14:49] Insbesondere ist es für mich immer wichtig, so ein paar Aliase zu definieren.

[14:53] Wie du mitbekommen hast, geht unter Linux nichts ohne die Kommandozeile.

[14:58] Und da tippt man sich teilweise zu Tode, wenn man sich die ganzen Befehle immer komplett hinschreiben müsste.

[15:04] Deswegen kann man einfach für bestimmte Befehle, die man häufig benutzt, ein Alias vergeben.

[15:08] Und sobald du dann diesen Alias eintippst, wird im Hintergrund der komplette Befehl, den du dahinter definiert hast, ausgeführt.

[15:14] Und das allererste, was ich immer mache, ist zum Beispiel den Alias L wie Ludwig zu definieren, anstatt LS-LA eingeben zu müssen.

[15:24] Denn das LS, das listet dir den Verzeichnisinhalt auf.

[15:27] Und die Parameter L und A, die führen dazu, dass du jede Datei in einer Zeile angezeigt bekommst und auch mit mehr Informationen außerdem Dateinamen.

[15:36] Also zum Beispiel auch die Größe, die Rechte und so weiter.

[15:39] Und außerdem werden auch die versteckten Dateien angezeigt.

[15:42] Das macht das A, glaube ich, wenn ich es noch richtig weiß.

[15:45] Sodass du also immer quasi ähnlich zu dem Dir unter Windows eine komplette Liste aller Inhalte inklusive Dateigröße und so weiter angezeigt bekommst.

[15:54] Und das mache ich eigentlich so gut wie immer, wenn ich in irgendein Verzeichnis wechsle, wenn ich mir nicht mehr sicher bin, was da rumliegt.

[15:59] Und anstatt immer LS-LA einzugeben, mache ich einfach L, Enter und sehe sofort den Inhalt.

[16:05] Ich habe es mir zum Beispiel schon so angewöhnt, wenn ich ein Verzeichnis wechsle, dann mache ich CD, Enter, L, Enter.

[16:11] Das L liegt ja, wenn du Zehnfingersystemen beherrschst, direkt unter deinem rechten Ringfinger.

[16:16] Du kannst also sofort L, Enter machen.

[16:18] Das geht ratzfatz und du siehst sofort auf dem Bildschirm die Inhalte des aktuellen Verzeichnisses.

[16:23] Ohne das Ding kann ich eigentlich schon fast nicht mehr leben, weil mir alles andere viel zu langsam ist.

[16:27] Ich habe mir sogar unter Windows den gleichen Alias definiert für L.

[16:30] Sodass ich also auf allen Betriebssystemen nach der Eingabe eines einzigen Buchstabens und Enter sofort den Verzeichnisinhalt mir anzeigen kann.

[16:38] Weitere nette Aliasse, die sogar von Debian schon vorgeschlagen werden, zumindest in der letzten Version, die ich gesehen habe.

[16:44] Wenn du bestimmte gefährliche Befehle benutzt unter Linux, wie zum Beispiel den RM-Befehl für Remove,

[16:51] damit kannst du theoretisch, wenn du root bist, mit einem einzigen Befehl deine gesamte Festplatte löschen.

[16:56] Nämlich mit RM, Leerzeichen, Slash, Leerzeichen, Minus, Rf.

[17:00] Das Rf steht für Rekursiv und Force.

[17:04] Das heißt, es wird ohne Nachfragen alles gelöscht, und zwar rekursiv.

[17:09] Und wenn du das auf Slash anwendest, Slash steht in diesem Fall für das root-Verzeichnis.

[17:13] Das ist das Basisverzeichnis deiner Festplatte, beziehungsweise nicht deiner Festplatte, sondern deines gesamten Dateisystem-Baums.

[17:19] Darunter können sogar mehrere Festplatten ja hängen.

[17:22] Die werden unter Linux ja nur so reingemountet an einen bestimmten Teil deines Verzeichnis-Baums.

[17:27] Und Slash ist halt der oberste aller deiner Verzeichnisse, das es so gibt.

[17:32] Und wenn du darauf einen RM absetzt, dann wird rekursiv quasi alles gelöscht, was es auf deinem System so gibt.

[17:38] Und wenn du root bist, kommt dann nicht mehr eine Nachfrage, sondern es fängt direkt an zu löschen.

[17:42] Und das könnte eventuell ein bisschen in die Hose gehen,

[17:45] vor allem, weil man sich bei dem RM auch teilweise ein bisschen ins Bein schießen kann.

[17:49] Das ist mir selber schon mal passiert.

[17:50] Wenn man einmal an der falschen Stelle ein Leerzeichen einfügt, dann ist es leider ein bisschen mehr gelöscht, als das, was man eigentlich haben will.

[17:57] Insbesondere bei diesen versteckten Punkt-Dateien muss man ganz, ganz, ganz doll aufpassen.

[18:02] Denn wenn man zum Beispiel sowas macht wie RM Punkt Sternchen,

[18:06] und man hat aus Versehen zwischen dem Punkt und dem Sternchen ein Leerzeichen,

[18:09] dann löscht er einfach alle Dateien im aktuellen Verzeichnis.

[18:12] Denn Punkt ist das aktuelle Verzeichnis und Sternchen wird dann interpretiert als alle Dateien darin,

[18:17] sodass sein ganzes Verzeichnis auf einmal leer ist.

[18:19] Und das kann man auch leider nicht ganz so einfach wieder rückgängig machen unter Linux.

[18:23] Und er fragt dann halt noch nicht mal nach im Standard.

[18:25] Deswegen könnte man, gerade wenn man so Anfänger ist, diesen gefährlichen RM-Befehl so ein bisschen entschärfen.

[18:31] Der hat nämlich einen Parameter, den man setzen kann, der das RM einfach immer zwingt nachzufragen, ob du wirklich löschen willst.

[18:39] Für mich als jemand, der das jetzt schon länger benutzt, ist das natürlich super nervig, jedes Mal gefragt zu werden.

[18:44] Aber gerade wenn du Einsteiger bist und noch nicht so hundertprozentig vielleicht mit den Befehlen klarkommst

[18:48] oder dich ab und zu auch mal vertippst, dann kann man zum Beispiel einen Alias definieren,

[18:52] der RM dazu zwingt quasi, immer den Parameter zu benutzen, um dich nachzufragen.

[18:58] Du könntest also den Alias RM so setzen, dass im Hintergrund RM minus I für Interactive heißt das, glaube ich,

[19:07] nämlich für die Nachfrage, ob wirklich gelöscht werden soll, ausgeführt wird.

[19:11] Und so kannst du, auch wenn du aus Versehen mal irgendwie ein bisschen zu viel oder zu wenig hinter RM angibst,

[19:15] sicher sein, dass er nicht einfach munter drauf loslöscht, sondern dich erst mal jedes Mal fragt.

[19:20] Und da gibt es noch ein paar mehr Befehle, die man vielleicht entschärfen sollte.

[19:25] Und in so einem Standard Debian, wie gesagt, sind, ich glaube, zwei oder drei Befehle drin angegeben.

[19:29] Die anderen fallen mir jetzt gar nicht mehr ein.

[19:30] Aber RM ist halt schon ganz gefährlich, denn ohne Rückfrage wird gelöscht.

[19:34] Und es gibt auch nicht so was wie einen Papierkorb, wo du dann was wieder herstellen kannst, wie unter Windows,

[19:38] sondern die Dinger sind dann weg, die du da gelöscht hast.

[19:41] Also könnte ganz nett sein, den vielleicht zu entschärfen, den Befehl.

[19:45] Außerdem kann man in der BashRC sowas machen wie eine farbige Ausgabe.

[19:49] Das LS zum Beispiel, das gibt Dateien und Verzeichnisse aus, eventuell aber sogar in Farbe, wenn du das entsprechend setzt.

[19:56] Dann würden zum Beispiel Verzeichnisse anders farbig dargestellt oder Dateien, die ausführbar sind, werden anders dargestellt.

[20:02] Das heißt, es gibt dir eine gewisse visuelle Hilfe, wenn du auf so einem weißen Schrift, auf schwarzem Hintergrund, Monitor oder Terminal, besser gesagt, arbeitest.

[20:11] Dann siehst du vielleicht einige Sachen gar nicht sofort und die fallen dir nicht ins Auge,

[20:14] dass du zum Beispiel gerade eine ausführbare Datei vor dir hast.

[20:17] Und wenn du so eine farbige Ausgabe aktivierst, dann ist das etwas offensichtlicher

[20:21] und du kannst vielleicht ein bisschen weniger Fehler machen, aus Versehen irgendwas tun, was du nicht tun möchtest.

[20:26] Was ich außerdem immer mache, gleich zu Beginn so eines Aufsetzens meines

[20:31] Linux-Servers ist, die History-Size zu erhöhen, denn alle Befehle, die du auf

[20:36] der Kommandozeile eingibst, die merkt sich die Bash. Die kannst du auch alle mit

[20:40] Pfeiltaste nach oben durchlaufen oder wenn du weißt, wie der Befehl anfängt,

[20:45] brauchst du nicht so auf die Pfeiltaste drücken, du kannst einfach Ctrl-R, also

[20:48] Steuerung Richard drücken und dann anfangen zu tippen und dann durchsucht er

[20:53] die gesamte History deiner Befehle nach Befehlen, wo diese

[20:58] Zeichenkette, die du gerade eingegeben hast, drin ist und dann kannst du mit wenigen

[21:01] Tasten drücken, Befehle, die du schon mal eingegeben hast, nochmal wiederholen

[21:05] quasi. Und diese History ist aber standardmäßig in der Länge so ein

[21:09] bisschen begrenzt und ich mache als allererstes immer sowas, diese History

[21:12] ganz ganz hoch zu setzen, zum Beispiel auf 100.000 oder sowas, sodass also alle

[21:16] Befehle, die ich jemals eingegeben habe, auf meinem Server dort gespeichert werden.

[21:19] Ist auch eine ganz nette Sache, wenn dein Server mal gekapert wird, dann kannst du

[21:23] nämlich in der History nachschauen, was die Leute denn da so gemacht haben.

[21:25] Das hilft dir vielleicht nicht unbedingt, um deinen Server wieder zu, wie soll man

[21:30] sagen, von Schadsoftware zu befreien, aber du weißt oder du siehst zumindest Ansätze,

[21:35] was die Leute da gemacht haben. Falls sie denn nicht so intelligent waren, um die

[21:38] History zu löschen, die ist einfach in der Datei gespeichert, wie so ziemlich

[21:41] alles unter Linux, das heißt, ich kann die History natürlich auch manipulieren,

[21:44] aber da gehen wir jetzt mal nicht von aus. Ich denke jetzt erst mal so den

[21:48] Happy Path und das ist jetzt, du möchtest deine eigenen Befehle, die du schon mal

[21:51] eingegeben hast, wiederholen und dazu werden sie in der History gespeichert.

[21:54] Aber nur, wenn du diese History-Größe auch erhöhst, sonst ist nach, ich habe

[21:58] keine Ahnung, irgendwie was mit 200 Befehlen oder so vielleicht Schluss und

[22:01] wenn du den Server länger betreibst, dann sind halt alle alte Befehle

[22:05] nicht mehr aufrufbar. Was ich außerdem gerne zusätzlich gleich mache, wenn ich

[22:08] eh schon dabei bin, es gibt auch einen kleinen Befehl, der es dir ermöglicht, die

[22:12] Befehle aus mehreren Shells, die du vielleicht parallel zusammen auffasst, in

[22:18] der History zu speichern. Sonst ist es nämlich immer so, dass die Shell, die du

[22:22] zuletzt zumachst, quasi gewinnt und die Befehle in die History schreibt und

[22:27] während du zum Beispiel mit drei, vier, fünf Putty-Sitzungen gleichzeitig auf

[22:30] deinem Server bist, überschreiben die sich also alle gegenseitig die History und

[22:33] dann sind vielleicht die interessanten Befehle nicht mehr in der History drin,

[22:36] weil die aus Versehen in einem Fenster eingegeben wurden, was als erstes

[22:40] zugemacht wurde zum Beispiel. Deswegen gibt es da einen einzigen Eintrag, den du

[22:44] vornehmen musst in der Bash-RC, damit alle diese Shell-Geschichten gemerged

[22:49] werden in die History, sodass du also keine Kommandos verlierst. Ein Artikel,

[22:54] wo genau beschrieben ist, wie du das konfigurieren musst, wie der Befehl dazu

[22:57] heißt, habe ich dir in die Show Notes gepackt, auf jeden Fall. Und als letztes

[23:02] zur Shell kann ich noch sagen, du könntest noch deinen Prompt konfigurieren,

[23:06] da der Prompt, wenn du das noch nicht weißt, ist alles das, was vor deinem

[23:10] Cursor quasi steht und da steht auf so einem normalen Linux-System jetzt

[23:14] nicht so ganz so viel Spannendes. Du kannst es aber zum Beispiel so

[23:16] einrichten, dass da der Server-Name drin steht, der Benutzer, der du gerade bist,

[23:20] das aktuelle Verzeichnis könnte da drin stehen und das hilft dir vielleicht ein

[23:23] bisschen bei der Navigation, gerade wenn du mit mehreren Shells unterwegs bist

[23:26] und auf dem einen bist du irgendwie als Root angemeldet, auf dem anderen als

[23:30] normaler Benutzer und du siehst noch nicht mal das Verzeichnis in dem Prompt.

[23:33] Das wird dann vielleicht ein bisschen schwierig, immer hin und her zu

[23:35] switchen, wo du gerade bist. Und wenn du nicht ständig mit pwd für Print Working

[23:40] Directory und whoami für wer bin ich, also Anzeigen des aktuellen Benutzers,

[23:45] nachgucken willst, wo du gerade bist und wer du gerade bist, ist es vielleicht

[23:48] sinnvoll, das einfach in den Prompt einzubauen. Und auch dafür gibt es ein

[23:52] paar einfache Befehle. Habe ich auch in den Shownotes verlinkt. Wie gesagt, schau

[23:55] doch mal rein. Ich habe meinen Prompt zum Beispiel so

[23:57] konfiguriert, dass tatsächlich da der Server-Name steht, dann ein Adzei… nee,

[24:01] andersrum. Ich habe erst den Username, dann kommt ein Adzeichen, dann kommt der

[24:04] Server-Name und dahinter steht dann tatsächlich auch das Verzeichnis, in dem

[24:07] ich gerade bin. Sodass ich also mit einem Blick immer sehe, wer bin ich, wo bin ich

[24:12] und auf welchem Server bin ich. So, in Anbetracht der Zeit gebe ich jetzt mal

[24:16] ein bisschen Gas. Es gibt noch viele andere Dinge, die man in der Bash-RC

[24:19] konfigurieren könnte. Ich höre jetzt hier aber mal auf. Lass dich mal einfach

[24:22] inspirieren. Es gibt viele Leute da draußen, die zum Beispiel bei GitHub

[24:25] einfach ihre .files einstellen. .files deswegen, weil die mit Punkt

[24:30] anfangen, . auf Englisch. Und das sind genau diese Config-Dateien. Die gibt es

[24:34] nicht nur für die Bash, die gibt es zum Beispiel auch für Vim. Das wäre das, was

[24:37] ich jetzt als nächstes durchgehe. Aber du kannst einfach mal ein bisschen die

[24:40] Google-Suche anschmeißen und nach .files suchen und Bash und so weiter. Und

[24:44] dann kriegst du von ganz ganz vielen Leuten da draußen sicherlich ein paar

[24:46] schöne Beispiel-Dateien, wie die so ihre Bash oder ihren Vim oder was auch immer

[24:51] konfigurieren. Nur so als Tipp für dich. Und das ist auch genau das Nächste, was

[24:55] ich jetzt machen will, nämlich den Vim konfigurieren. Ich gehe nicht davon aus,

[24:58] dass du irgendeinen anderen Editor benutzt. Wie könntest du… ja, es gibt ja

[25:02] den Vim. Wieso sollte man irgendeinen anderen Editor benutzen, wenn es doch den

[25:05] Vim schon gibt? Nein, das ist dir natürlich völlig freigestellt. Du kannst

[25:08] irgendeinen Editor benutzen. Aber solltest du den Vim benutzen, was ich dir doch

[25:12] ans Herz legen würde, denn ich glaube nicht, dass man mit irgendeinem anderen

[25:15] Editor irgendwie schneller arbeiten kann. Aber ich möchte mich nicht auf

[25:18] irgendwelche Grabenkämpfe mit Emacs oder vielleicht sogar Nano-Junghorn einlassen.

[25:23] Ich kann dir nur sagen, der Vim ist ein toller Editor und der ist auf allen

[25:27] Linux-Systemen, auf allen Unix-Systemen quasi vor… nicht nur quasi, der ist da

[25:30] vorinstalliert, sodass du also auf allen Systemen damit arbeiten kannst. Und es

[25:34] gibt ihn natürlich selbstverständlich auch für Windows, aber das habe ich hier

[25:37] im Podcast schon mehrfach erwähnt. Ich finde den also wirklich klasse.

[25:39] Ich benutze sogar inzwischen im Firefox und in anderen IDEs, zum Beispiel in

[25:44] Java… ach, in Eclipse zum Beispiel benutze ich die Vim Keybindings, weil man

[25:48] damit einfach so schnell und so toll navigieren kann. Aber das nur am Rande.

[25:52] Wenn du den Vim benutzt, dann würde ich dir empfehlen, ein paar kleine

[25:55] Einstellungen vorzunehmen, damit du mit dem auch vernünftig arbeiten kannst, als

[25:58] nur, sage ich mal so, als kleinen Hinweis. Ich will jetzt nicht die gesamte

[26:01] Konfig durchgehen. Ich habe ein ganzes Buch in die Shownotes gepackt, was sich

[26:05] nur mit dem Vim auseinandersetzt, mit Konfig-Einstellungen für die wildesten

[26:09] Dinge, die man sich da vorstellen kann. Das ist das Practical Vim von Drew Neal.

[26:13] Ein absolut tolles Buch, wenn du mit dem Vim noch wirklich ein, sage ich mal, ein

[26:18] Experte werden willst. Dann guck dir das mal an. Der hat auch eine ganz tolle

[26:21] Webcast-Reihe zum Thema Vim gemacht und also das ist einfach ein toller Editor.

[26:26] Das Buch dazu kann ich absolut empfehlen. Von daher kann ich jetzt nicht

[26:29] alle Inhalte dieses Buches hier durchgehen, aber so ein paar Sachen, die

[26:32] man noch nicht mal irgendwie lernen muss oder so. Die stehen eigentlich in der

[26:37] Konfig-Datei schon drin. Die musst du nur anschalten, weil die auskommentiert sind.

[26:40] Das sind zum Beispiel die farbige Ausgabe und das Syntax-Highlighting.

[26:44] Der Vim kann von sich aus die Daten, die er da liest, interpretieren. Der kennt zum

[26:49] Beispiel, oh, das ist eine HTML-Datei und dann erkennt er ein paar Keywords. Der

[26:52] weiß, dass spitze Klammern notwendig sind für die Tags und so weiter und der

[26:56] kann das dann auch entsprechend farbig darstellen, damit man es ein bisschen

[26:58] netter lesen kann. Und er kann zum Beispiel auch ein Syntax-Highlighting

[27:02] dann machen. Also der erkennt auch dann Bestandteile von Programmiersprachen zum

[27:05] Beispiel und hebt die entsprechend hervor. Und das sind zwei Sachen, die

[27:09] musst du einfach nur aktivieren in der Konfigurations-Datei. Standardkonfig ist

[27:13] zum Beispiel .etc, .vim und dann .vimrc oder die kann auch woanders

[27:19] liegen, je nachdem, was für eine Distribution du hast. Auf jeden Fall ist

[27:21] die Datei .vimrc. Es gibt auch eine .vimrc in deinem Home-Verzeichnis.

[27:25] Also es gibt tausend Möglichkeiten, wo man das irgendwo konfigurieren kann. Ich

[27:28] gehe jetzt mal von der Standard-Vim-Konfig aus und die liegt unter .etc, .vim, .vimrc

[27:33] und da musst du einfach nur zwei Zeilen oder eine sogar nur auskommentieren und

[27:37] dann hast du eine farbige Ausgabe. Wunderbar! Ansonsten kannst du noch so

[27:41] was machen wie Zeilennummern zum Beispiel aktivieren. Insbesondere hilfreich, wenn

[27:44] du nach irgendwelchen Fehlern suchst. In Fehlermeldungen stehen häufig

[27:47] Zeilennummern. Wenn du die dann nicht sehen kannst in deinem Editor, das wäre

[27:49] irgendwie doof. Außerdem ist es ganz nett, wenn man eine

[27:52] Case-Insensitive-Suche anschaltet. Sonst musst du nämlich bei der Suche in

[27:57] Vim ständig auf Groß- und Kleinschreibung achten. Das ist meistens

[28:00] nicht so toll, gerade wenn man nicht weiß, wie das Wort geschrieben wurde im

[28:03] Log-File zum Beispiel. Das sollte man anschalten, dass eben also die

[28:07] Groß- und Kleinschreibung nicht berücksichtigt wird. Also Case-Insensitive

[28:11] gesucht wird. Und als letzten kurzen kleinen Tipp, um dich zu zwingen, den Vim

[28:16] richtig zu benutzen, schalte auch die Pfeiltasten aus. Das ist tatsächlich

[28:20] etwas, was ich in meiner Config aktiviert habe. Ich kann im Vim nicht mehr mit den

[28:23] Pfeiltasten navigieren. Denn, was soll das Ganze? Du bist viel viel schneller, wenn

[28:28] du die Standard-Navigation im Vim benutzt. Die liegt nämlich passenderweise

[28:31] genau auf der Home-Row. Das heißt, du kannst mit den Buchstaben H, J, K, L

[28:35] wunderbar hoch und runter und links und rechts navigieren im Vim. Und genau

[28:39] dafür ist es auch gedacht. Du musst die Home-Row mit deiner rechten Hand nicht

[28:42] verlassen, um navigieren zu können. Wenn du dir aber angewöhnt hast, weil du es

[28:46] aus anderen Editoren kennst, immer mit der rechten Hand zu den Pfeiltasten

[28:49] zu springen, dann bist du deutlich deutlich langsamer, weil du halt immer

[28:53] hin und her springen musst. Und der Vim lässt sich out of the box mit den

[28:56] Tasten H, J, K, L navigieren. Bloß die meisten Leute sind es halt gewohnt und

[29:01] nutzen die Pfeiltasten. Und auch, ich gebe es zu, bei mir war es genauso. Deswegen

[29:05] habe ich irgendwann gesagt, okay, ich habe die Pfeiltasten einfach auf No-Op

[29:09] gesetzt. Das heißt, die machen nichts. Ich kann die drücken, aber es passiert

[29:12] einfach nichts. Der Cursor bewegt sich nicht, sodass ich quasi gezwungen werde,

[29:16] die richtigen Tasten für die Kombination, für die Navigation zu

[29:20] benutzen. Das fand ich eigentlich einen richtig coolen Einsteigertipp, weil du

[29:23] dadurch wirklich gezwungen wirst, den Vim vernünftig zu bedienen.

[29:28] Ja, was heißt vernünftig? So, wie es gedacht war, nämlich ohne die Home-Row zu

[29:31] verlassen. Das gebe ich dir noch als kleinen Tipp mit. Und für alles Weitere

[29:35] guck einfach mal in das Buch von Juniel. Absolute Leseempfehlung meinerseits. Und

[29:41] da wir jetzt gleich die 30-Minuten-Marke knacken werden, mache ich die letzten

[29:45] beiden Punkte nur noch mal kurz im Überblick. Und zwar, meine letzten beiden

[29:50] Punkte sind, richte das Backup deines Servers ein und richte auch ein

[29:54] Monitoring deines Servers ein. Fangen wir vielleicht mit dem Backup an. Du bist

[29:59] jetzt an einem Punkt angelangt, wo du einiges schon konfiguriert hast auf deinem

[30:02] Server. Du hast vielleicht den Vim konfiguriert, deine Bash-SE, du hast

[30:05] vielleicht deine Firewall eingerichtet und irgendwas geskriptet und und und und.

[30:09] Und wenn das jetzt alles weg ist, weil dein Server die Grätsche macht oder weil

[30:13] du tatsächlich gehackt wirst, ich hoffe nicht, kann eigentlich kaum noch

[30:16] passieren bei der ganzen Sicherheitsgeschichte, die wir hier schon

[30:19] eingestellt haben, aber man ist ja nie hundertprozentig sicher. Und wenn das

[30:22] dann alles weg sein sollte, dann ist halt deine ganze langwierige Arbeit irgendwie

[30:26] für die Katz gewesen. Deswegen solltest du als einen der ersten Schritte, nachdem

[30:31] du vielleicht deinen Server ans Laufen bekommen hast und abgesichert hast,

[30:35] ein Backup einrichten. Und das sollte so oft wie möglich laufen.

[30:39] Meistens, sagt man ja vielleicht einmal am Tag, sollte vielleicht der ganze

[30:42] Server gesichert werden. Deine wichtigen Dateien vielleicht auch mehrfach am Tag,

[30:45] aber das kannst du auch selbst entscheiden. Wichtig ist nur, du brauchst

[30:48] ein Backup und zwar ein regelmäßiges und das muss durchautomatisiert sein.

[30:52] Du darfst nicht manuell auf deinem Server Dateien sichern müssen, denn wenn du das

[30:57] machen musst, sind wir ganz ehrlich, dann wirst du es irgendwann nicht mehr machen,

[31:00] weil es einfach total nervig ist. Und dieser Backup-Prozess, der muss

[31:03] automatisiert erfolgen. Das Schöne unter Linux ist, du kannst das alles

[31:07] automatisieren, denn alles was du dafür tun musst, ist ein kleines Skript zu

[31:10] schreiben. Zum Beispiel dein ETC-Verzeichnis, dein Home-Verzeichnis,

[31:13] dein was auch immer Verzeichnis, wird zum Beispiel mit TAR, also mit T-A-R,

[31:18] in ein Archiv gepackt und dann zum Beispiel auf einen Backup-Server kopiert.

[31:23] Das geht zum Beispiel per FTP oder per SCP oder wie auch immer. Und viele

[31:28] Hoster bieten auch automatisch so einen Backup-Server an. Ich bin bei Hetzner,

[31:32] die haben automatisch für mich einen Backup-FTP-Server eingerichtet, auf dem

[31:37] ich, ich weiß nicht, mehrere hundert Gigabyte, glaube ich, an Speicher zur

[31:41] Verfügung habe, quasi im Preis mit drin. Und da kann ich dann halt jede Nacht oder

[31:45] wenn ich will, noch öfter halt die Sicherung meines Servers einfach hin

[31:48] kopieren und dann liegen halt Daten außerhalb meines eigenen Servers. Und

[31:52] wenn der mal abrauchen sollte, bei mir ja sogar noch wahrscheinlicher, weil ich ein

[31:56] echtes Stück Hardware da stehen habe, dann kann ich die Daten auf jeden Fall

[31:59] von diesem FTP-Server wiederherstellen. Wichtig dabei ist natürlich, wenn das

[32:03] jetzt außerhalb deines Hosters vielleicht liegt, weil du das was ich bei

[32:06] Microsoft in die Cloud packen willst oder weiß der Geier wo, dann solltest du

[32:10] immer daran denken, Konfigurationsdateien und Passwörter und so, das ist vielleicht

[32:14] nicht ganz so gut, wenn andere Leute das einsehen können. Ich würde zum Beispiel

[32:17] auch meinem eigenen Hoster nicht vertrauen. Ich packe meine Dateien auch

[32:21] nicht einfach so bei Hetzner auf den Backup-Server, ohne die vorher zu

[32:24] verschlüsseln. Das ist ein ganz wichtiger Punkt, den ich dir mitgeben möchte. Wenn

[32:28] du so einen Backup einrichtest, denk von Anfang an daran, dass dieses Backup

[32:32] vernünftig verschlüsselt sein muss. Dazu gibt es zum Beispiel PGP, Pretty

[32:38] Good Privacy, ist ein Kommandozeilen-Programm unter Linux, was du

[32:41] benutzen kannst, um auch wieder mit Public und Private Key zum Beispiel

[32:44] deine Datei einfach zu verschlüsseln, sodass die niemand außer dir wieder

[32:48] entschlüsseln kann. Und die kannst du dann auch gefahrlos auf einem externen

[32:51] FTP-Server oder in der Cloud oder weiß der Geier wo ablegen, weil da halt dann

[32:55] niemand mehr drankommt. Wichtig ist bei der Geschichte nur, dass du auch das

[33:00] Restore mal testen musst. Denn das beste Backup bringt dir nichts, wenn du das

[33:04] Backup nicht wieder einspielen kannst. Von daher mach mal einen Probelauf und

[33:08] es bietet sich absolut an, das zu Beginn deiner ganzen Geschichte hier zu machen.

[33:11] Denn wenn bei dem Restore irgendwas schief gehen sollte und du dir

[33:15] aus Versehen den ganzen Server schrottest damit, was ja durchaus mal

[33:18] vorkommen kann, dann ist es nicht ganz so schlimm, denn du hast ja noch nicht so

[33:21] viel eingerichtet. Wenn du das Backup einrichtest und dann nach drei Jahren

[33:24] mühsamer Arbeit mal irgendwann gezwungen bist, ein Restore zu machen und dann

[33:28] feststellst, dass es nicht funktioniert, das wäre wirklich, wirklich, wirklich bitter.

[33:32] Also schau unbedingt, dass du das Backup von Anfang an, am besten jeden Tag einmal

[33:38] automatisch laufen lässt, es unbedingt verschlüsselst, damit keiner reingucken

[33:42] kann und probier auch mal die Daten aus dem Backup wieder herzustellen, um ganz

[33:46] sicher zu sein, dass das auch funktioniert. Denn gerade wenn du die

[33:49] Daten verschlüsselt ablegst, dabei kann theoretisch so viel schief gehen, dass

[33:53] du selber die Datei irgendwann nicht mehr öffnen kannst. Rein theoretisch. Und

[33:58] das wäre natürlich der Super-GAU. Du hast die Daten wunderbar gesichert, liegen

[34:01] alle auf dem FTP-Server, ganz toll verschlüsselt, aber leider kommst du nie

[34:04] wieder dran, weil du, keine Ahnung, den Schlüssel irgendwie falsch eingegeben

[34:06] hast oder irgendwas. Also unbedingt das gesamte Backup-Restore einmal

[34:11] ausprobieren, ob das wirklich funktioniert. Aber glaub mir, du wirst

[34:16] dir wünschen, ein Backup gehabt zu haben, wenn du das erste Mal gehackt wurdest

[34:21] und halt dann kein Backup hast. Also aus eigener Erfahrung, das ist super, super

[34:26] wichtig. Mach dir einmal die Mühe, richte das vernünftig ein, skripte das

[34:30] durch. Ja, das ist Arbeit, aber die zahlt sich definitiv aus. Denn irgendwann, glaub

[34:35] es mir einfach, wirst du das brauchen. Und das Allerletzte, wenn du jetzt einen

[34:40] Server betreibst, der auch quasi dauerhaft online sein soll und auch

[34:43] erreichbar sein soll und du das auch sicherstellen möchtest, dann empfehle ich

[34:46] dir auch ein Monitoring einzurichten. Viele Hoster haben das in ihrem Paket

[34:50] mit drin. Ich kann jetzt wieder nur von Hetzner sprechen. Da ist es einfach so,

[34:52] die haben so einen Monitoring-Dienst. Dem kann ich sagen, guck bitte alle fünf

[34:57] Minuten, ob auf der IP-Adresse XY noch der Mail-Server läuft oder der

[35:01] Web-Server läuft oder oder oder. Und das habe ich auch für meine wichtigsten

[35:04] Dienste eingerichtet, sodass ich also immer von draußen geprüft werde, ob der

[35:08] Server noch erreichbar ist auf diesem Port zum Beispiel oder der IP-Adresse

[35:11] oder unter der Domain, wie auch immer. Und wenn der mal nicht erreichbar ist,

[35:15] dann kriege ich eine Mail. Dazu gleich vielleicht als Tipp aus eigener

[35:19] Erfahrung auch wieder, lass die Mail, die dann kommt, nicht an deinen eigenen

[35:23] Mail-Server schicken. Denn wenn dein Mail-Server down ist und die Mail dich

[35:27] darüber informieren soll, an diesen Mail-Server geschickt wird, ja dann wirst

[35:31] du leider nichts davon mitbekommen. Es gibt aber heutzutage natürlich genug

[35:34] Web-Mail-Angebote von Google, Gmail oder Web.de oder Gmx oder weiß der Geier, wo

[35:40] du dir vielleicht einfach eine Zweit-E-Mail anlegen solltest und an die

[35:43] solltest du dann diese Nachrichten zusätzlich schicken zu deinem

[35:49] eigenen Mail-Server, falls du den betreibst. Ich habe es also genauso

[35:52] gemacht, wenn zum Beispiel mein Web-Server ausfällt, dann kann ich

[35:56] natürlich wunderbar auch auf meinem eigenen Mail-Server darüber

[35:58] benachrichtigt werden. Das kriege ich dann ja auch mit. Aber wenn halt der Mail-Server

[36:01] weg ist, dann kriege ich halt keine Mails mehr. Deswegen versende ich das

[36:04] nicht nur an meinen eigenen Mail-Server, sondern halt auch an so einen Drittanbieter

[36:08] im Netz und den kann ich natürlich auch bei meinem Handy abrufen. Das

[36:11] heißt, wenn irgendwas passiert, kriege ich sofort einen Push auf mein Handy und

[36:14] ich bekomme gleich mit, dass halt irgendwas nicht funktioniert. Ist

[36:18] vielleicht für deinen privaten Blog, den du jetzt am Anfang betreibst, nicht

[36:21] ganz so wichtig, wenn der mal down ist. Aber wenn du vielleicht eine

[36:24] große Website hast oder vielleicht sogar irgendwann damit Geld verdienst,

[36:28] weil du da irgendwelche Werbung schaltest oder keine Ahnung was, dann wäre es

[36:31] natürlich doof, wenn das Server nicht erreichbar ist. Gerade wenn du auch einen

[36:33] eigenen Mail-Server betreibst und deine gesamten Mails darüber laufen und dein

[36:37] Mail-Server ständig ausfällt und du Mails nicht mehr bekommst. Das wäre

[36:40] natürlich, jetzt mal unabhängig von irgendwie Geld verdienen, wäre das

[36:43] natürlich auch irgendwie doof, wenn du auf einmal nicht mehr erreichbar bist

[36:46] von draußen. Von daher schau einfach, dass du informiert wirst, wenn dein

[36:50] Server nicht mehr läuft und die meisten Hoster haben das halt eh kostenfrei im

[36:54] Paket mit drin. Du musst es halt nur einmal zusammenklicken und dann läuft

[36:58] das Ganze. Es ist also auch wieder nur ein bisschen mehr Aufwand für dich, aber

[37:02] du hast dann auf jeden Fall die Sicherheit, dass wenn irgendwas nicht

[37:04] mehr läuft, du das auch mitbekommst. Denn man glaubt gar nicht, wie wenig man

[37:09] mitbekommt, wenn man auf solche Dinge nicht achtet. Du rufst deine Mails ab und

[37:13] kriegst einfach nur die Nachricht, ja, keine neuen Mails vorhanden zum Beispiel.

[37:16] Wenn, keine Ahnung, irgendwas mit dem Server nicht läuft und dein Mail-Programm

[37:21] ist vielleicht nicht so toll konfiguriert oder kriegt die Fehler nicht mit oder wie

[37:24] auch immer. Das heißt, du merkst vielleicht den ganzen Tag nicht, dass dein Server gar

[37:26] nicht mehr läuft und das wäre natürlich sehr doof. Deswegen würde ich dir

[37:29] empfehlen, dieses Monitoring auch einzurichten.

[37:32] Okay, so jetzt bin ich durch, habe schon wieder ein bisschen überzogen, aber ich

[37:36] mache für heute jetzt auf jeden Fall Feierabend. Ich gehe noch mal kurz durch,

[37:38] was ich heute so vermitteln wollte und womit ich dann jetzt diese Server-

[37:42] Episoden-Reihe beenden möchte. Richte dir auf jeden Fall eine Firewall ein.

[37:46] Blockiere erstmal alles und erlaube nur das, was du wirklich brauchst. Dann achte

[37:51] auf die Vergabe sicherer Passwörter für alle deine Dienste, die irgendwie nach

[37:55] draußen freigegeben werden, aber natürlich auch für die, die nicht nach

[37:58] draußen freigegeben werden. Gilt grundsätzlich für alles. Immer sichere

[38:01] Passwörter benutzen. Dann kannst du dein System ein bisschen optimieren, auf der

[38:04] Bash zum Beispiel mit der .bashrc. Da kannst du Aliase definieren oder

[38:08] gefährliche Befehle entschärfen oder oder oder. Dann kannst du deinen

[38:11] Text-Seeder konfigurieren, zum Beispiel den Vim, dass er ein bisschen farbig wird.

[38:14] Oder du kannst zum Beispiel die Pfeiltasten ausschalten, wenn du dich

[38:17] zwingen möchtest, den Vim vernünftig zu benutzen. Und die beiden letzten Punkte

[38:21] habe ich gerade noch erzählt. Richte auf jeden Fall von Anfang an ein Backup ein

[38:25] und teste auch das Restore und richte auch ein Monitoring ein, damit du

[38:29] informiert wirst, wenn dein Server mal irgendwie nicht mehr läuft. So, damit wäre

[38:35] ich jetzt für heute auch durch. Ich hoffe, ich habe dir ein bisschen den Mund

[38:40] wässrig gemacht, dafür deinen eigenen Server aufzusetzen. Die letzten vier

[38:44] Episoden hatten das jetzt zum Thema. Würde mich freuen, wenn du das als

[38:47] Motivation nimmst und tatsächlich selber mal aktiv wirst und was machst. Wie gesagt,

[38:52] du lernst es nicht besser, als wenn du deinen eigenen Server betreibst. Ich kann

[38:56] das absolut weiterempfehlen und meine eigenen Azubis machen das ja auch. Und ich

[39:00] habe übrigens auch diese Woche, habe ich schon meinem Newsletter verschickt, den

[39:03] Link zum Blog meines Azubis, denn der hat jetzt auch gerade seinen ersten

[39:08] Fachartikel geschrieben für seinen privaten Blog. Den verlinke ich natürlich

[39:11] auch noch mal einmal in den Shownotes. Von daher, nimm das als Motivation. Auch

[39:16] andere Azubis können das und du kannst das ganz sicher auch, wenn du in der IT

[39:20] unterwegs bist. Und mit den paar Tipps, die ich dir gegeben habe, kannst du

[39:23] vielleicht ein bisschen einsteigen. Ansonsten kauf dir ein vernünftiges

[39:26] Buch, lese dich da ein und versuche es einfach. Und wenn was nicht läuft, dann

[39:30] löscht das Ding halt einfach und setzt es neu auf. Es ist ja nichts

[39:33] lebenswichtiges, aber damit kannst du halt den Umgang mit einem

[39:37] Betriebssystem wie Dinox zum Beispiel vernünftig lernen und du lernst auch so

[39:41] viel mehr noch darüber, über das ganze Internet, wie das funktioniert und das

[39:44] Betreiben eines Web-Servers, Mail-Servers und und und. Du hast so viele Möglichkeiten

[39:47] mit deinem eigenen Server. Ich würde dir absolut raten, das einfach mal auszuprobieren.

[39:52] Und wenn du da irgendwie keinen Bock drauf hast, das Ding kannst du normalerweise innerhalb von ein paar Monaten, wenn überhaupt, kündigen.

[39:59] Das ist ja auch nicht so teuer. Was hatte ich gesagt? 5 Euro oder sowas im Monat, wenn du zum Beispiel mit EinsBlue das machst.

[40:04] Vielleicht findest du sogar noch billigere Angebote, ja. Von daher, es ist eine sehr kleine Investition, aber was du dadurch lernst, ist, glaube ich,

[40:12] wirklich enorm. Und du kannst auch vieles davon in der Prüfung anwenden. Von daher, ja,

[40:17] gib dir einen Ruck und probiere es einfach mal aus. Wenn du es ausprobieren möchtest und du meiner Empfehlung folgen möchtest,

[40:22] zum Beispiel mit EinsBlue das Ganze zu machen, unter anwendungsentwicklerpodcast.de

[40:27] slash EinsBlue, also die Zahl 1 und dann BLU ausgeschrieben,

[40:30] findest du den Link zu dem V-Server, den ich hier die ganze Zeit empfehle. Findest du auf jeden Fall auch in den Shownotes.

[40:36] Ich wiederhole es nochmal, anwendungsentwicklerpodcast.de slash 9 1 für die 91. Episode.

[40:41] Und da findest du auch noch einen ganzen Haufen mehr Links, wenn du jetzt noch tiefer einsteigen willst.

[40:46] Ich habe zum Beispiel noch einen netten Artikel mit so häufigen Kommandozeilenbefehlen verlinkt oder ein paar Shortcuts für die Kommandozeile, wenn du zum Beispiel

[40:53] zum Beginn der Zeile oder zum Ende der Zeile springen willst und so weiter. So Steuerung,

[40:59] Kommandozeilenbefehle, die habe ich da auch nochmal verlinkt und halt alles, was ich auch in der Episode erwähnt habe. Von daher, guck doch einfach mal rein und

[41:06] vertiefe das Ganze und werde zum Linux-Experten. Denn Linux ist eigentlich ein super cooles Betriebssystem.

[41:12] Alles komplett kostenfrei. Du kannst damit so viele coole Dinge tun und kannst auch wirklich richtig was dabei lernen.

[41:18] Meine beiden Literatur-Empfehlungen diese Woche hatte ich schon erwähnt. Das ist einmal das Buch von Drew Neill zum Thema Vim.

[41:25] Practical Vim heißt das. Und dann, wie die letzten Wochen auch, der CoFloor Linux, das umfassende Handbuch von

[41:32] Michael CoFloor. Über 1000 Seiten dick und ich glaube, da ist alles drin, was du wissen musst. Also wirklich eine gute Investition,

[41:38] wenn du im Bereich Linux noch ein bisschen aktiver werden möchtest.

[41:42] Zuletzt, wie immer, mein Angebot. Trag dich gerne in meinen Newsletter ein unter anwendungsentwicklerpodcast.de

[41:48] slash Newsletter. Kannst du einmal die Woche von mir alle Informationen zur Website

[41:52] bekommen und in letzter Zeit auch ganz, ganz, ganz viele Links, die dir hoffentlich auch bei der Ausbildung weiterhelfen.

[41:58] Unter anderem auch die Links meiner Azubis, die die für sich raussuchen und die denen geholfen haben,

[42:03] verschicke ich da teilweise mit. Von daher, wenn dich das interessiert, melde dich einfach an. Kostet nichts und du kriegst halt einmal die Woche eine hoffentlich

[42:10] spannende Mail von mir. Wenn es dich nicht mehr interessiert, trage dich einfach aus.

[42:13] Und außerdem, was du auch noch kriegst, ist Zugriff auf meine Checklisten rund um die Projektarbeit, Projektdokumentation,

[42:19] Präsentation und so weiter. Mit über 100 Punkten, die du durchgehen kannst, bevor du deine Doku abgibst. Und deine Präsentation und dein Fachgespräch und und und.

[42:26] Da gibt es einen ganzen Haufen Zeug. Außerdem informiere ich dich auch ab und an mal über irgendwelche Rabattaktionen für meine

[42:31] Word-Vorlage zum Beispiel, zur Projektdokumentation oder für meine Hörbücher und so weiter.

[42:36] Also, wenn du möchtest, trage dich einfach ein.

[42:38] Und wenn du auch noch möchtest, dann gib mir noch ein Feedback zu den Episoden hier. Wenn dir das gefallen hat, die

[42:44] Geschichte hier mit dem Server, das ist ja etwas sehr praxisbezogenes. Ich habe es auch immer ab und zu mal so ein bisschen

[42:49] Prüfungsinhalte untergebracht, aber

[42:51] Fokus war natürlich schon irgendwie das Machen und selber aktiv werden. Und wenn du in Zukunft mehr von solchen Sachen hören möchtest, dann gib mir

[42:58] doch einfach mal ein Feedback. Und wenn dich das total angeödet hat, freue ich mich auch über ein Feedback. Dann weiß ich wenigstens, was ich anders machen muss.

[43:05] Also, schreibe mich irgendwie an. Du kannst mich auf allen Social-Media-Kanälen

[43:08] erreichen oder per E-Mail oder per Kontaktformular. Du findest sicherlich einen Weg. Und ich würde mich ganz toll, ganz doll

[43:15] darüber freuen, wenn du mir sagst, ob dich das hier weiterbringt oder nicht. Dann kann ich in Zukunft noch mehr Inhalte anbieten, die dir vielleicht

[43:23] gefallen. In diesem Sinne sage ich für diese Woche erstmal vielen Dank fürs Zuhören.

[43:28] Und bis zum nächsten Mal. Tschüss!