Vor OS X 10.11 El Capitan konnte man recht bequem über die GUI ein ISO Image brennen.
Unter El Capitan scheint es die Funktion im Festplattendienstprogramm nicht mehr zu geben.
Glücklicherweise kann man eine ISO euch recht einfach mit dem Terminal Brennen
hdiutil burn /pfad/zu/meiner/datei.iso
Wer den weg über das Terminal nicht gehen mag, muss man wohl auf Drittanbieter Tools zurückgreifen.
Aktiviert man UFW auf Ubuntu schreibt UFW seine Logs nach:
/var/log/ufw.log /var/log/syslog
Will man die UFW Logfiles nicht im syslog haben, einfach in
vi /etc/rsyslog.d/20-ufw.conf
und dort ein „& stop“ nach „:msg,contains,“[UFW “ /var/log/ufw.log“ einfügen, das ganze Sieht da so aus:
# Log kernel generated UFW log messages to file :msg,contains,"[UFW " /var/log/ufw.log & stop # Uncomment the following to stop logging anything that matches the last rule. # Doing this will stop logging kernel generated UFW log messages to the file # normally containing kern.* messages (eg, /var/log/kern.log) #& ~
Speichern und
service rsyslog restart
UFW loggt nun nicht mehr nach syslog.
Ubuntu und die Deutschen Paketquellen mach hin und wieder Probleme, wie z.B. aktuell mal wieder dieses hier:
W: Herunterladen von http://de.archive.ubuntu.com/ubuntu/dists/trusty-updates/main/i18n/Translation-en fehlgeschlagen: Hash-Summe stimmt nicht überein E: Manche Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder durch alte ersetzt. E: Paket-Zwischenspeicher konnte nicht neu erzeugt werden
Da ich dies bei den de.* Paketquellen hin und wieder habe habe ich die de* Paketquellen nun auf all unseren Servern entfernt und durch die Standard Paketquellen ersetzt.
Das ganze geht wie gewohnt über
vi /etc/apt/sources.list
dort einfach die „de.“ bei allen Quellen entfernen und speichern
deb http://de.archive.ubuntu.com/ubuntu/ trusty main restricted
danach
rm -rf /var/lib/apt/lists/* aptitude update
Alternativ das ganze in einfach:
rm -rf /var/lib/apt/lists/* sed -i 's/de.archive.ubuntu.com/archive.ubuntu.com/g' /etc/apt/sources.list aptitude update && aptitude safe-upgrade
Hin und wieder bin ich genervt von unübersichtlichen outputs diverser Programme / Kommandos in der Shell. Dennoch kann man sich hier als Admin leicht weiterhelfen.
Der aktuelle Output von mount sieht in etwas so aus:
root@server ~ # mount /dev/md2 on / type ext4 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) udev on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755) none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880) none on /run/shm type tmpfs (rw,nosuid,nodev) cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,mode=755) /dev/md1 on /boot type ext3 (rw) /dev/md3 on /home type ext4 (rw)
Nicht wirklich übersichtlich, vor allem wenn man grade im stress ist.
Das ganze geht auch mittels column -t in schön und übersichtlich:
root@server ~ # mount | column -t /dev/md2 on / type ext4 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) udev on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755) none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880) none on /run/shm type tmpfs (rw,nosuid,nodev) cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,mode=755) /dev/md1 on /boot type ext3 (rw) /dev/md3 on /home type ext4 (rw)
Cloumn ist ein Tool das seinen input in mehrere Spalten aufteilen kann
Wer das ganze jetzt noch als Alias in der „.bashrc“ bzw. „.bash_aliases“ als alias für mount speichert, erhalt dann via mount immer einen übersichtlichen output.
Z.B.: Inhalt von /root/.bash_aliases für den root User
alias mount='mount | column -t'
Einmal aus der Shell ausloggen und neu verbinden, fertig!
Fail2ban sollte eigentlich jedem Admin der Linux/Unix Server ein begriff sein, vor allem wenn er Server administriert die am www hängen.
Mit Fail2ban kann man automatisiert mit diversen Filterregeln es einem Angreifer schwer machen. Dabei schaut Fail2Ban in die entsprechenden Logfiles und erstellt anhand von Filterregeln dann Firewall-Regeln um den Angreifer auszusperren.
Bei SSH schaut Fail2Ban in die /var/log/auth.log
Versucht jemand nun jemand via SSH das Passwort vom Root User herauszufinden (Brute-Force), kann Fail2ban den Angreifer nach 3 versuchen ihn für die nächsten 24 Stunden via Firewall Regel aussperren. Das erschwert natürlich eine solche Brute-Force-Attacke.
Grundsätzlich sollten SSH Root-Logins nie via Passwort möglich sein!
(Leider gibt es hin und wieder andere Kundenwünsche und Ansichten.)
Unter Debian / Ubuntu erfolgt die Installation mit einem
apt-get install fail2ban
Danach findet man die Konfigurationsdaten unter /etc/fail2ban/… . Wir kopieren uns jetzt das Original und legen uns eine local Konfiguration an mit der wir nun fortan arbeiten.
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Die Konfigurationsdatei jail.local ist hinreichend Dokumentiert, daher werde ich dies hier nicht im Detail erläutern.
Um fail2ban für z.B. SSH zu aktivieren muss enabled auf den wert true gesetzt werden
[ssh] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 3
Datei speichern und danach fail2ban neustarten.
service fail2ban restart
Danach prüfen ob die Jails angelegt wurden:
iptables -L
Und nach ein paar tagen wird man in seinen Jails schon geblockte IP-Adressen finden.
Wichte Tipps:
bantime so hoch wie möglich stellen z.B. auf 48 Stunden:
bantime = 172800
Was viele vergessen:
Fail2ban reagiert nur auf IP Adressen im authlog. Schreibt OpenSSH anstelle der IP-Adresse den Reverse-DNS in die Logfile wird Fail2ban nicht darauf reagieren, und selbst wenn man sich dafür einen eigenen regex baut, ist dies realativ unsicher.
Daher in OpenSSH folgende Option setzen:
UseDNS no
Somit macht OpenSSH keine Reverse-DNS und Fail2ban kann seine Arbeit machen.
Nie blind fail2ban vertrauen! Selbst ist der Admin.
Viel Erfolg ;) !
Neulich bei einem Kunden vor Ort, nachdem am Wochenende Elektriker im Haus waren.
Das verblüffende: Beide iMacs die ich so vorfand liefen noch!
Nachteil: Das Netzwerkkabel lässt sich nun nicht mehr entfernen und ist eins mit den iMacs.
Was macht man wenn man dem Kunden schon seit über 6 Monaten regelmäßig warnt:
das der 7 Jahre alte Mailserver dringend ersetzt werden muss weil, erstens, es schon seit Jahren keine Security Updates mehr gibt und zweitens, der Raid Controller einen hau hat und es zu erwarten ist das dass System komplett ausfällt. Dazu kommt das der Server mit dem heutigen Mail aufkommen nicht mehr klar kommt und die CPU einfach nur noch brennt!
… der Kunde nicht hören will, bzw. es einfach ignoriert?
Was macht man da?
Ich habe leider keine Antwort darauf!
Jedoch musste dieser Kunde schmerzhaft feststellen was es bedeutet wenn der Hardware-Raid Controller sich verabschiedet und dabei auch schön beide Raids zerstört!
Und wer musste das ganze wieder ausbaden?
Richtig, der Sysadmin!
Leider passierte das ganze dann auch noch vor meinen Urlaub, an einem Tag wo ich komplett anderweitig verplant war und leider auch grade an dem Tag wo der Kunde ein großes und wichtiges Mailing versenden musste.
Tja, Murphy’s Law!
Backups sind das mit wichtigste bei der Serveradministration. Linux Admins haben oft ihre eigenen Backupscripte, liegt wohl in der Natur eines Linux Admins alles selbst zu machen ;)
Es gibt jedoch auch nette Tools und Scripte um sich Zeit zu sparen, eines davon ist automysqlbackup und ist in den Debian und Ubuntu Paketquellen mit drin.
Automysqlbackup sichert dabei alle vorhandenen Datenbanken einzeln in täglichen, wöchentlichen und monatlichen Backups übersichtlich in einzelnen Unterordnern.
Ein einfaches
aptitude install automysqlbackup
installiert es. Die Konfiguration findet man unter
/etc/default/automysqlbackup
und sobald die wichtigsten Einstellungen wie „BACKUPDIR“ eingerichtet sind läuft das Script auch schon. Dabei sichert automysqlbackup nun täglich alle Datenbanken. Die Backups werden dann weiter in wöchentlichen und Monatlichen Backup-Verzeichnissen rotiert.
Das Script läuft täglich und wird über cron.daily gesteuert.
Backup backup backup! Leute macht Backups!
Ich kann es nicht oft genug sagen
while [ true ] ; do
echo „Macht Backups!!!“
done
So das sollte jetzt genug sein ;)
1. Ich halte es für einen ganz guten Einstieg in das neue Jahr um locker wieder mit dem Bloggen anzufangen und ein sehr wichtiges Thema anzuschneiden.
2. Zwischen den Jahren ist dazu eine menge passiert, dazu jetzt mehr
Eigentlich war dieses Jahr zwischen den Jahren eher Urlaub geplant, etwas entspannen und zwischen durch in der Firma die Sachen machen zu denen man sonnst nicht kommt. Die Feiertage lagen dieses Jahr so gut, dass grade unsere großen Kunden fast alle geschlossen hatten oder nicht wirklich gearbeitet haben.
Doch es die ruhe zwischen den Jahren war trügerisch…
Server im Rechenzentrum meldet sich mit „A Fail event had been detected on md device /dev/md/1“ alles klar. Festplatte im Arsch, kein Thema ist ja Raid1 und ich habe Backups! Plattentausch um RZ organisiert und Rebuild gestartet.
Kurz darauf musste ja – während des Rebuild – Platte 2 des gleichen Servers den Geist aufgeben (konnte wohl nicht verkraften das sein langjähriger Kumpel vor ein paar stunden entfernt wurde und hat sich gleich mit aufgehängt)
… alles weitere könnt ihr euch ja bestimmt denken.
Zum Glück hatte ich Backups und der Server war in wenigen Stunden wieder der alte.
Mitarbeiter von Firma xyz ruft an:
Mitarbeiter: Hey, sorry das ich jetzt anrufe. Aber ich brauch mal dringend deine Hilfe…. ich habe schon Stunden mit dem Apple Support Telefoniert und keiner kann mir helfen.
Ich: Was ist passiert?
Mitarbeiter: Mein privates MacBookPro startet nicht mehr und laut Apple ist die Festplatte defekt. Ich habe hier wichtige Daten drauf an denen ich schon seit Monaten Arbeite und die Daten liegen nicht auf dem Server … (omfg! Ich ahne es ja schon) … und das Projekt muss in 2 Wochen abgegeben werden.
Ich: Hast du ein Backup von deinem Laptop?
Mitarbeiter: Nein
Ich: … (kurze pause, Luft holen und ruhig bleiben) … nicht gut.
Mitarbeiter: Kannst du mir helfen
Ich: … (tief einatmen) … eigentlich nicht
Mitarbeiter: Es ist echt dringend, wir haben sonst ein echt großes Problem.
Ich: … (tief einatmen) … na gut, ich versuche es kann aber für nichts garantieren.
Nachdem ich dan den Mitarbeiter über Datenrettungsfirmen und die damit verbundenen Kosten sowie Backups aufgeklärt habe lag das Laptop dann kurzer hand nach den Feiertagen bei uns im Büro.
Ich konnte dann ca. 95% der Daten retten und wiederherstellen… Mitarbeiter war glücklich und erhielt einen Monolog bzgl. Backups von mir.
Kunde ruft an: Hey wir haben ein Problem, eine Festplatte ist defekt und die Daten sind echt wichtig! Wir haben kein Backup.
… echt jetzt … schon wieder … ihr wollt mich doch verarschen oder?
Das ende diesen Falles ist wohl ein elektronikschaden an der Festplatte, Daten konnten bisher nicht gerettet werden. Allerdings arbeite ich noch dran… Kunde will keine Professionelle Firma dafür beauftragen. Sollte ich erfolgreich sein poste ich das ganze natürlich.
Man! … was war das den für en Festplattensterben zwischen den Jahren?
Also macht Backups! Und wenn der Sysadmin euch immer wieder fragt ob ihr auch Backups macht schaut nicht so genervt… wir meinen es nur gut mit euch.
3 Jahre ist es nun her das hier der letzte Beitrag geschrieben wurde… die Gründe hierfür waren unter anderen diverse private Umstände. Jetzt ist es wieder an der Zeit diesen Blog weiter zu führen. Ich freu mich drauf und bin gespannt was daraus wird.
Seit meinem letzten Beitrag über die Verabschiedung von Apple aus dem Serverbereich ist viel passiert… Ich bin Apple immer noch treu geblieben, jedoch nur auf dem Desktop. Im Serverbereich bin ich wieder stark zu Linux gewandert, teilweise auch zu FreeBSD & co. . Das ganze wird dann auch hier im Blog Themenschwerpunkt.
Gleichzeitig zum wiederauferstehen wird hier auch das Design geändert. Es ist noch nicht final, aber es wird definitiv schlank und minimalistisch gehalten. Der Blog bekommt gleichzeitig eine neue Struktur, die alten Beiträge bleiben noch als Archiv erhalten.