seeseekey.net - Invictus Deus Ex Machina

Mein vor einiger Zeit aufgesetzter Proxyserver startete nicht mehr. Stattdessen bekam ich von Polipo nur noch die Meldung:

Starting polipo: Couldn't open log file /var/log/polipo: Permission denied

Allerdings ließ sich das ganze relativ problemlos aus der Welt schaffen:

touch /var/log/polipo
chmod 640 /var/log/polipo
chown proxy:proxy /var/log/polipo

Danach konnte der Dienst mittels:

service polipo restart

wieder gestartet werden.

Wenn man ein Init-Skript schreibt, kann man natürlich jedesmal von Neuem beginnen. Einfacher ist es wenn man sich eines Templates bedient. Felix H. Dahlke stellt ein solches bereit. Bei diesem Template muss nur noch das Verzeichnis der Anwendung, der Nutzername und das Kommando selbst definiert werden. Der Rest wird vom Template bereitgestellt. Nachdem man sich auf Basis des Templates ein passendes Skript unter /etc/init.d/ definiert hat, muss das ganze nur noch mit den passenden Attributen versehen werden und, auf Wunsch zu den defaults hinzugefügt werden:

chmod a+x /etc/init.d/newservice
update-rc.d newservice defaults

Lizenziert ist das Template unter der MIT-Lizenz und damit freie Software. Denn passenden Template-Quellcode findet man auf GitHub.

Vor einigen Tagen war ich auf der Suche nach einem Kommando um die Netzwerkaktivität eines Rechners nach Protokollen separiert anzeigen. Wie nicht anderes zu erwarten bin ich dann bei Netstat gelandet. Mittels:

netstat -s

kann man sich einen Report aufgeteilt nach Protokollen anzeigen lassen. Das könnte dann z.B. so aussehen:

Ip:
    20715767 Pakete insgesamt empfangen
    0 weitergeleitet
    0 eingehende Pakete verworfen
    20713510 eingehende Pakete ausgeliefert
    12353060 Anforderung gesendet
Icmp:
    720 ICMP-Meldungen empfangen
    0 Input-ICMP-Meldung fehlgeschlagen.
    ICMP-Eingabehistogramm:
        Ziel unerreichbar: 304
        Echo Anfragen: 416
    9238 ICMP Nachrichten gesendet
    0 ICMP Nachrichten fehlgeschlagen
    ICMP-Ausgabehistogramm:
        Ziel unerreichbar: 8822
        Echo Antworten: 416
IcmpMsg:
        InType3: 304
        InType8: 416
        OutType0: 416
        OutType3: 8822
Tcp:
    364 aktive Verbindungsöffnungen
    298756 passive Verbindungsöffnungen
    6285 fehlerhafte Verbindungsversuche
    57555 Verbindungsrücksetzungen empfangen
    1 Verbindungen aufgebaut
    10493162 Segmente empfangen
    15405980 Segmente ausgesendet
...

Wenn man einen OpenVPN-Server in der Standardkonfiguration betreibt, wird man sich unter Umständen wundern, an welcher Stelle ist das OpenVPN Log zu finden ist. Das liegt daran das der OpenVPN-Server das ganze in /var/log/syslog speichert. Möchte man nun die OpenVPN betreffenden Punkte filtern so sollte man auf der Konsole folgendes eingeben:

grep VPN /var/log/syslog

Alternativ kann man auch die OpenVPN-Konfiguration anpassen. Dazu muss die Datei /etc/openvpn/server.conf bearbeitet werden. Dort gibt es eine Option log-append, welche wie folgt angepasst wird:

log-append /var/log/openvpn.log

Nach einem Neustart des Service mittels:

service openvpn restart

wird die neu eingestellte Logdatei genutzt.

Unter Ubuntu gibt es neben den halbjährlichen Versionen auch solche welche über einen längeren Zeitraum unterstützt werden. Diese sogenannten Long Term Releases erscheinen dabei alle zwei Jahre und werden fünf Jahre lang unterstützt. Bei Ubuntu kann man das System nun so konfigurieren das nur LTS Versionen oder jedes Release zum Upgrade angeboten wird. Möchte man diese Einstellung ändern, so muss man im Terminal:

nano /etc/update-manager/release-upgrades

eingeben. Im Editor öffnet sich dann folgende Datei:

# Default behavior for the release upgrader.

[DEFAULT]
# Default prompting behavior, valid options:
#
#  never  - Never check for a new release.
#  normal - Check to see if a new release is available.  If more than one new
#           release is found, the release upgrader will attempt to upgrade to
#           the release that immediately succeeds the currently-running
#           release.
#  lts    - Check to see if a new LTS release is available.  The upgrader
#           will attempt to upgrade to the first LTS release available after
#           the currently-running one.  Note that this option should not be
#           used if the currently-running release is not itself an LTS
#           release, since in that case the upgrader won't be able to
#           determine if a newer release is available.
Prompt=lts

Dort kann man unter Prompt die gewünschte Einstellung festlegen und bekommt damit vom System nur noch Hinweise wenn die gewünschten Versionen erscheinen.

Für einen Server hatte ich vor einigen Tagen unter Ubuntu 14.04 LTS eine Netzwerkbrücke eingerichtet. Die /etc/network/interfaces Datei sah danach in etwa so aus:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto br0
iface br0 inet dhcp
bridge_ports eth0

Nach einem Neustart gab es dann allerdings ein Problem. Der Server war nicht mehr erreichbar. Der Grund dafür war simpel — es fehlte das Paket bridge-utils — nach der Installation desselben mittels:

apt-get install bridge-utils

funktionierte die Netzwerkbrücke wieder ohne Probleme.

Bei einer Aktualisierung eines Ubuntusystems mittels des Paketmanagers wurde der Vorgang am Ende mit der Zeile:

The link /vmlinuz.old is a damaged link
Removing symbolic link vmlinuz.old 
 you may need to re-run your boot loader[grub]

abgeschlossen. Die Lösung für das Problem ist dabei relativ unkompliziert. Es reicht auf der Konsole:

update-grub

einzugeben. Damit wird die menu.lst erneut geschrieben.

Um die Versionsnummer eines installierten Postfix zu ermitteln, reicht es im Terminal folgendes einzugeben:

postconf -d mail_version

Anschließend erhält man eine Ausgabe nach dem Schema:

mail_version = 2.11.0

Da die Parameter aus der main.cf ausgelesen werden, ist es wichtig den Parameter –d anzugeben. So werden nicht die überschriebenen Werte zurückgegeben, sondern die Standardwerte, in diesem Fall die korrekte Versionsnummer.

Da sitzt man vor seinem Ubuntu-Upgrade und eine unbedachte Handbewegung später hat man das Upgrade abgebrochen. In einem solchen Fall sollte man das Upgrade natürlich fortsetzen, wer möchte schon gerne ein halbfertiges System. Wurde die SSH Verbindung unterbrochen, muss sich im ersten Schritt mit dem Server verbunden werden. Anschließend gibt man im Terminal folgendes ein:

dpkg --configure -a
apt-get dist-upgrade
apt-get autoremove
apt-get autoclean
reboot

Danach sollte der Server auf dem aktuellsten Stand sein und das Upgrade durchgeführt sein. Sollte man das Upgrade vor dem Umstellen der Paketlisten abgebrochen haben, dürfte ein einfaches „do-release-upgrade“ genügenum den Upgrade-Vorgang erneut zu starten.