Partition online mit parted vergrößern

Ubuntu installiert das Physical Volume bei der Erstinstallation in eine separate (zweite) Partition, da die erste Partition ohne LVM für /boot eingerichtet wird:

Hat man bei der Ersteinrichtung zu knapp gedacht, kann es passieren, dass die root-Partition vollläuft:

Wenn man jetzt für die VM die Festplatte vergrößert, ändert das leider nichts am Dateisystem, da die Partition und damit das LVM Physical Volume gleich groß geblieben ist:

Jetzt also der große Moment, die benutzte Partition online zu vergrößern, ohne dass die vorhandenen Daten Schaden nehmen. Dazu eignet sich hervorragend parted (auch ohne GUI = gparted). Dazu kann man den dialoggesteuerten Modus starten und sich erst mal ein paar Informationen anzeigen lassen:

Wenn standardmäßig ein anderes, als die gewünschte Partition verwendet wird, muss man mit select erst in die entsprechende wechseln. Mit unit kann man mit unterschiedlichen Speichergrößen arbeiten. Wer jetzt versucht die Partition mit resizepart zu vergrößern, wird meistens scheitern, weil die Umrechnungen der Anzeige zu ungenau sind, um sie in den Änderungsangaben zu verwenden:

Also erst einmal die Einheiten auf absolute Werte wie Sektoren einstellen und noch einmal versuchen. Da man sich diese auch so anzeigen lassen kann, kann man sich den Wert prima kopieren:

Zeigt man sich dann das Ergebnis mit den vorherigen Einheiten an, erkennt man auch die Vergrößerung und kann das Programm verlassen:

Jetzt nur noch das LVM Physical und Logical Volume und das Dateisystem der gewünschten Partition vergrößern und fertig:

Ergebnis: root-Partition vergrößert, ohne das System offline zu nehmen und ohne Daten zu verlieren.

 

IPFire Webseite zeitweise auf red freischalten

Ich benutze gerne IPFire, um mal schnell ein Testnetz aufzusetzen. Das red-Interface kommt dann ins vorhandene Gästenetz und das green-Interface stellt das Testnetz dar. Da das Testnetz aber noch keine Computer hat, habe ich nach der Installation keine Oberfläche, um ipfire konfigurieren zu können, da diese standardmäßig nur vom green-Interface aus erreichbar ist. Das kann man aber über einen Einzeiler zeitweise (bis zum nächsten Neustart) ändern, um die Konfiguration über die Management-Oberfläche vornehmen zu können.

Dazu muss man:

  • die IP seines eigenen PCs oder Netzwerkes (hier: 192.168.1.77) und
  • die IP des red-Interfaces der IPFire-Installation (hier: 192.168.0.101) wissen.

Seine eigene IP-Adresse bekommt man über den Befehl ipconfig in einer Kommandozeile unter Windows heraus:

Dann kann man sich mit dem bei der IPFire-Installation vergebenen Root-Kennwort an der Konsole anmelden und einen iptables-Eintrag vornehmen, der die https-Managment-Webseite auf dem red-Interface freischaltet.

warnung Das sollte man natürlich nur bei internen Netzwerken machen! Wer ipfire als Internet-Zugangsrouter verwendet, schaltet das Management damit in das Internet frei!

Erklärung der Parameter:

  • iptables = das Firewall-Programm
  • -A INPUTFW = die Firewall-Kette, in die diese Ausnahme eingetragen wird (werden muss)
  • -s 192.168.1.77/32 = der eine Host (/32) mit der IP 192.168.1.77, der diese Ausnahme nutzen darf (alternativ schaltet man das ganz Sub-Netz frei: -s 192.168.1.0/24)
  • -d 192.168.0.101/32 = die IP-Adresse des red-Interfaces der ipfire-Installation
  • -p tcp -m tcp = es wird das TCP-Protokoll benutzt
  • –dport 444 = der Port, der auf dem red-Interface freigeschaltet wird (standardmäßig verwendet ipfire für das Management per https diesen Port)
  • -j ACCEPT = Datenpakete auf einer Verbindung mit diesen Einschränkungen zulassen.

infoDa diese Konfiguration live vorgenommen und nicht abgespeichert wird, ist diese nach einem Neustart nicht mehr vorhanden! Das ist so gewollt, da die vollständige Konfiguration danach über das Web-Interface erfolgen kann.

T-SQL Array-Variablen deklarieren

Manchmal braucht man mehr als einen Wert in einer Variable. Dann kann man diese auch als Tabelle definieren:

Die Variablen kann man dann über Standard-Statements befüllen und abfragen:

Verwendung der Variable in WHERE-Klausel:

Veröffentlicht in MSSQL

apt-get / aptitude

Steuerung über die APT-Konfiguration

Wie der lokale Paket-Manager funktioniert kann man nicht nur per Script und Cronjobs sondern auch über die umfangreiche APT-Konfigurations-Syntax steuern. Die wichtigsten Parameter sind direkt im standardmäßig angelegten Cronjob „/etc/cron.daily/apt“ beschrieben.

Konfiguration eines Apt-Proxys

Dazu einfach unter

eine Konfigurations-Datei anlegen:

und in diese den folgenden Inhalt schreiben:

Hier z.B. die Konfiguration wenn lokal der apt-cacher installiert wurde:

Automatische Installation von Sicherheits-Updates

Dafür ist erst einmal das zusätzliche Paket „unattended-upgrades“ notwendig.

Mit der Installation wird die notwendige Konfigurationsdatei „/etc/apt/apt.conf.d/50unattended-upgrades“ (beschrieben für Debian)

installiert. Hier wird bestimmt, welche Pakete automatisch installiert bzw. von der automatischen Installation ausgenommen werden. Man kann sich auch per Email bei Fehlern benachrichtigen lassen.

Damit sind die automatischen Updates aber noch nicht aktiv!

Dafür müssen erst die folgenden drei Zeilen

in die Datei „/etc/apt/apt.conf.d/10periodic“ geschrieben/angehängt werden. Durch diese zwei Zeilen werden die Paket-Listen einmal täglich aktualisiert und die Pakete, die in „/etc/apt/apt.conf.d/50unattended-upgrades“ konfiguriert sind, installiert.

Für die Benamung der Datei habe ich bisher noch keine Beschreibung gefunden. Da diese für die Funktion aber ohne Bedeutung ist, habe ich mich nach dem Eintrag im Ubuntu-Wiki gerichtet, in dem ich diese Konfiguration auch gefunden habe.

Die Ausführung erfolgt dann durch das vorhandene APT-Script „/etc/cron.daily/apt“, das täglich ausgeführt wird.

Update-Download

Wer möchte kann sich die anstehenden Updates ja bereits downloaden. Dann braucht es bei der Installation nicht so lange. Dazu muss man einfach eine Zeile der umfangreichen APT-Konfiguration aktivieren, in dem man sie in eine Datei unterhalb von „/etc/apt/apt.conf.d/“ schreibt.

Hat man es z.B. wie oben bei den automatischen Updates eingerichtet, kann man die folgende Zeile in die Datei „/etc/apt/apt.conf.d/10periodic“ eintragen:

Damit werden die anstehenden Update-Dateien einmal täglich heruntergeladen, aber nicht installiert.

Cache aufräumen

Damit das standardmäßig vorhandene Script „/etc/cron.daily/apt“ auch das Aufräumen übernimmt, braucht man nur eine Zeile aktivieren.

Damit wird „apt-get autoclean“ alle 7 Tage ausgeführt.

Logs rotieren

Ich richte immer noch eine erweiterte Konfiguration für logrotate ein.

Fehlerbehebung

Wer seine anstehenden Linux-Updates per Nagios/Icinga überwacht, kann nach dem manuellen Neuanlegen der o.g. Dateien auf folgenden Fehler treffen:

Beim Testen des angezeigten Befehls treten wie immer keine Fehler auf. Man ist ja root. Also sollte der Befehl als der Benutzer ausgeführt werden, unter dem die Monitoring-Software läuft:

Der Parameter -s für die Shell ist optional, aber bei Systembenutzern ohne Shell notwendig. Danach sieht man dann erst den eigentlichen Fehler:

Einfach Leseberechtigungen für „Others“ auf die gemeldete Datei setzen und schon klappt’s mit dem Nachbarn ;-). Bei mir war die Ursache die restriktiv gesetzte UMASK im Profil.

logrotate Konfiguration unattended-upgrades

Diese Konfiguration nutze ich für die automatischen Updates unter Debian/Ubuntu. Dabei liegen die angelegten Logfiles standardmäßig unter „/var/log/unattended-upgrades/“. Die Konfiguration des Speicherortes passiert in der APT-Konfigurationsdatei „/etc/apt/apt.conf.d/50unattended-upgrades“ über den Parameter „APT::UnattendedUpgrades::LogDir“. Der Pfad ist in der Logrotate-Konfiguration also entsprechend zu setzen:

Die Konfiguration sollte vor dem ersten Einsatz getestet werden:

Dabei kommt dann in etwa so etwas heraus:

awk – Auswertung von Textdateien

Was Awk ist, kann man auf Wikipedia nachlesen. Ich schreibe mir hier Zusammenstellungen auf, die mir merkenswert erscheinen.

Deinstallations-Liste aus Paketmanager dpkg erstellen

Manchmal muss man auch mal aufräumen. Dann hilft es schon, wenn man sich die Liste seines lokalen Paketmanagers (dpkg) für sein Online-Paketverwaltungstool (apt-get, aptitude) aufbereiten kann.

Damit wird mit dpkg eine Liste der installierten Programme erzeugt und diese auf den Begriff lxde gefiltert. Das Ergebnis wird an awk per Pipe weitergegeben. Awk verarbeitet aus allen Zeilen die Spalte 2 ($2) und speichert diese zusammen mit einem Leerzeichen in der Variable progs. Zum Schluss (END) wird die Variable progs ausgegeben.

Jetzt kann man noch die Paketverwaltung seiner Wahl mit dem entsprechenden Deinstallations-Befehl (remove, purge) davorsetzen und die Programme werden entfernt.

Ein erweitertes Suchergebnis erhält man mit egrep, so dass man auch nach mehreren Begriffen suchen kann:

Hier muss man nur beachten, dass die Regular Expressions in Anführungszeichen stehen müssen. Im hier gezeigten Beispiel werden von alle Zeilen an awk übergeben, die „lxde“ oder „gnome“ oder „gdm“ enthalten.

Konfiguration rkhunter

Automatische DB-Aktualisierung nach Paketinstallation/-Upgrade

Ab der Version 1.3.8, die z.B. auf Ubuntu 12.04 LTS eingesetzt wird, kann man rkhunter automatisch seine DB aktualisieren lassen, damit man beim Einsatz von automatischen Aktualisierungen hinterher keine False-Positive-Emails von rkhunter kommen. Dazu den Wert APT_AUTOGEN in der /etc/default/rkhunter auf true setzen. Den Rest erledigt dann die APT-Konfiguration aus /etc/apt/apt.conf.d/90rkhunter, welche automatisch bei der Installation angelegt wurde.

Wer noch mit der Version 1.3.6 arbeitet, z.B. auf Debian Squeeze und Ubuntu 10.04 LTS, kann sich diese Funktion aber sehr einfach aktivieren. Dazu einfach die folgenden Konfigurationen und ein Script aus Ubuntu 12.04 LTS auf die Konsole kopieren und ab geht’s.

Semiaktuelle Software-Versionen bestätigen

Debian legt standarmäßig mehr Wert auf Stabilität und Minimalismus, als auf Aktualität. Zumindestens, wenn man sich auf den STABLE-Zweig beschränkt. Benutzt man dann z.B. den RootKit-Hunter, kommt es zu Meldungen, dass einige Applikationen, wie z.B. openSSL, GPG, PHP, SSH-Server, die bekannte Ziele für Sicherheitsattacken sind, zu alt sind.

Man hat jetzt zwei Möglichkeiten, diesen Warnungen zu begegnen. Zum einen die aktuell eingesetzten Versionen per Konfigurationsoption in der /etc/rkhunter.conf auf eine Whitelist zu setzen:

Damit werden z.B. die o.g. Applikationen mit der aufgeführten Version als o.k. angesehen. Man muss diese Versionen bei einem Update allerdings manuell nachpflegen.

Alternativ, kann man auch das Scannen aller Applikationen per Konfiguraitonsoption ausschalten. Dafür muss man die „apps“ unter „DISABLE_TESTS“ mit aufnehmen:

Meines Erachtens ist das aber nicht der wirklich gute Weg.

Neuerungen in Debian Squeeze und rkhunter 1.3.6

Mit der Version 1.3.6 werden einige neue Punkte gemeldet. So z.B.:

Im Einzelnen dazu Folgendes:

No MAIL-ON-WARNING option has been configured

Ist keine „MAIL-ON-WARNING“ Email-Adresse angegeben, wird die Ausgabe standardmäßig an root gesendet. Hat man keine Weiterleitung aktiviert, bekommt man auch keine Meldungen. Hat man eine Weiterleitung eingerichtet, bekommt man alle Ausgaben per Email unverschlüsselt zugesendet. Beim Transport durch das Internet kann das auch ein Sicherheitsrisiko bedeuten, da man lesen kann, welche Sicherheitsrisiken bestehen.
Also sollte man lieber eine Email-Adresse eintragen. Dann bekommt man nur eine Info über eine mögliche Infektion und man muss das lokale Log kontrollieren.

Warning: Checking for possible rootkit strings

Durch die Umstellung in Debian squeeze auf den Abhängigkeits-Boot-Modus geht die Datei /etc/init.d/.depend.boot in Ordnung. Zusätzlich wird auch die Datei /etc/init.d/hdparm gemeldet, die aber nur das Festplattenmonitoring darstellt.

Beide und weitere kann man wie folgt von der Überprüfung ausnehmen:

Warning: Hidden directory found

Squeeze hat auch ein paar neue versteckte Ordner unterhalb von /dev erzeugt, die natürlich potentiell gefährlich sein können. Nach manueller Kontrolle, kann man die bereits vorbereiteten Optionen einfach inder /etc/rkhunter.conf auskommentieren:

Lokale Konfigurationsdatei aber Version 1.3.6

Ab Version 1.3.6 kann rkhunter mit einer lokalisierten Konfigurationsdatei betrieben werden, was Updates wesentlich erleichtert. Die Datei muss zwingend rkhunter.conf.local heißen und im selben Verzeichnis liegen wie die Konfigurationsdatei des Betreuers (rkhunter.conf). Bei Debian liegen beide Dateien also unter /etc.

Sie enthält einfach alle geänderten Variablen. Da sie nach der Standard-Datei eingelesen wird, werden alle vorher konfigurierten Optionen überschrieben.

NTP Network Time Protocol

Manuelle Synchronisation

Die manuelle Synchronisation unter Linux erfolgt über ntpdate. Dementsprechend muss dieses Paket überhaupt erst einmal installiert werden. Danach kann über

seine eigene Computer-Zeit mit der des angegebenen Servers einmalig abgleichen. Falls bereits ein NTP-Daemon läuft, muss der vorher angehalten werden.

Unter Windows kann man seine Zeit über die Kommandozeile einmalig wie folgt abgleichen:

Automatische Synchronisation

Soll die Zeit automatisch und regelmäßig abgeglichen werden, muss ein entsprechender Dienst laufen.

Unter Linux installiert man dafür das Paket ntp, dass einen NTP-Daemon enthält. Dieser wird über die Datei /etc/ntp.conf konfiguriert und enthält bereits einige Server, die sich je nach OS unterscheiden. Hier ein Beispiel für Debian:

Mit einer weiteren Zeile „server <Eigener Zeitserver>“ kann man eigene Zeitserver hinzufügen oder die vorhanden ersetzen.

Damit der Dienst nur als NTP-Client läuft, sollten Zugriffe von außen nicht zugelassen werden:

Unter Windows wird die Zeit automatisch aktualisiert. Standardmäßig mit dem Server „time.windows.com“. Wer hier einen eigenen Server einstellen möchte kann dies unter Windows 7 (auch Server 2008 R2) über die Systemsteuerung -> „Datum und Uhrzeit“ -> Register „Internetzeit“ -> „Mit einem Internetzeitserver synchronisieren“ -> „Server:“ einstellen. Der eigene Server ist manuell in dem Auswahlfeld einzugeben.

Eigenen Zeitserver unter Linux einrichten

Da der Linux NTP-Daemon ntpd sowieso läuft, kann man ihn für sein eigenes Netz auch als Zeitserver freigeben. Dazu müssen nur der Zugriff auf den Zeitserver aus dem lokalen Subnetz (hier 192.168.1.0) freigegeben werden:

Wer eine Firewall auf seinem Rechner betreibt, muss dafür noch den UDP-Port 123 freigeben. Bei IP-Tables sieht das wie folgt aus:

logrotate Konfiguration Apache2

Diese Konfiguration nutze ich für Apache2 VirtualHosts. Dabei liegen die von Apache angelegten Logfiles unter „/var/log/apache2/<vhostName>/“. Die Konfiguration des Speicherortes passiert in der VirtualHost-Konfiguration.

 

Die Konfiguration sollte vor dem ersten Einsatz getestet werden:

Dabei kommt dann in etwa so etwas heraus: