Schnipsel

OS X Samba-Icon ändern

Um dem Samba-Server ein anderes Icon in OS X zu verleihen passen wir unter Debian die Datei /etc/avahi/services/smb.service wie folgt an:

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">

<service-group>
    <name replace-wildcards="yes">%h-SMB</name>
    <service>
        <type>_smb._tcp</type>
        <port>445</port>
    </service>
    <service>
         <type>_device-info._tcp</type>
         <port>0</port>
         <txt-record>model=Xserve</txt-record>
    </service>
</service-group>

Unter "model=Xserve" kann man dann das gewünschte Modell eintragen.

Ubuntu IPTables PPTP Pass Through

Es hat mich einige Zeit gekostet, IPTables auf einem Server so zu konfigurieren, dass er VPN PPTP Pass Through erlaubt. Letztlich bringt IPTables ein Modul mit, dessen Aktivierung das erlaubt:

sudo modprobe ip_nat_pptp

Dann sollte PPTP klappen.

Linux-Netzwerkschnittstellen werden nicht richtig benannt

Falls die Netzwerkschnittstellen auf einem neu installierten Linux nicht eth0 und eth1, sondern z.B. p4p1 heißen, liegt das daran, dass das Betriebssystem die BIOS-eigenen Namen verwendet. Das kann durch folgende Parameter in /etc/default/grub behoben werden:

GRUB_CMDLINE_LINUX_DEFAULT=”biosdevname=0”
GRUB_CMDLINE_LINUX=”biosdevname=0″

danach einmal

sudo update-grub

ausführen und den Rechner neu starten.

External Commands in Nagios3 ausführen

Nagios bringt eine Funktion mit, mit der sich z.B. Downtimes von überwachten Client über das Web eintragen lassen. Dies ist z.B. dann praktisch, wenn ein Client geplant länger nicht erreichbar ist. Standardmäßig ist diese Funktion zwar im Interface, aber nicht im Backend aktiviert (Fehler-Meldung: Error: Could not stat() command file /var/lib/nagios3/rw/nagios.cmd). Die Lösung ist auf [1] und [2] dokumentiert.

Änderungen in /etc/nagios3/nagios.cfg

check_external_commands=1
command_check_interval=15s
#command_check_interval=-1
command_file=/var/lib/nagios3/rw/nagios.cmd

Änderungen in /etc/nagios3/cgi.cfg

authorized_for_system_commands=*
authorized_for_all_service_commands=*
authorized_for_all_host_commands=*

(* steht hier für alle authentifizierten Benutzer. Alternativ können die htpasswd-Benutzer angegeben werden.)

Zusätzlich dazu müssen noch Dateirechte gesetzt werden:

service nagios3 stop
dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
service nagios3 start

Sollte das noch nicht klappen, muss der Apache-Benutzer noch in die Nagios-Gruppe aufgenommen werden:

service nagios3 stop
gpasswd -a www-data nagios
service nagios3 start

Fail2Ban IP entsperren

Zum ordentlichen Entsperren von versehentlich gesperrten IP-Adressen über Fail2Ban ist folgender Befehl auszuführen:

fail2ban-client set JAIL unbanip IP

Das JAIL bekommen wir entweder auf der Mail heraus oder über den Befehl

fail2ban-client status

RSyslog - Log-Empfang aktivieren

RSyslog bietet standardmäßig an, auch Logdateien von anderen Systemen zu sammeln. Das kann dann sinnig sein, wenn man viele Services auf verschiedenen Systemen hat und diese zentral loggen möchte. Das geht nach der Standard-Installation von Ubuntu ganz einfach über ein Editieren der Datei

vi /etc/rsyslog.conf

Hier müssen die Zeilen

# provides UDP syslog reception
#module(load="imudp")
#input(type="imudp" port="514")

# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")

geändert werden in

# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")

# provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")

OpenVPN Routing schlägt fehl

Ich hatte einen VPN-Server aufgesetzt, der IP-Adressen aus dem gleichen Netz verteilt wie das Gateway, auf dem er lief, aufgesetzt. Die Verbindung war da und wenn auf den Rechner im LAN hinter dem VPN-Server die Router für das Subnetz korrekt eingestellt war, ging auch alles glatt. Nur eben nicht, ohne die Routingtabellen auf allen Clients anzufassen. Letztlich war das Problem, dass die VPN-Adressen sich von den Rechnern im LAN unterscheiden müssen und zwar dürfen diese nicht nur nicht schon belegt sein, sondern müssen zudem aus einem anderen Subnetz kommen als schon im LAN durch die Subnetzmaske abgedeckt wird.

Konfigurationsbeispiel: Subnetz im LAN: 172.16.0.0/255.255.0.0

Erst hatte ich 172.16.41.0/255.255.255.0 als VPN-Netz eingestellt. Das klappte nicht.

Mit 10.8.0.0/255.255.255.0 als VPN-Netz klappt es ohne Probleme.

Dazu muss ipv4_forward in der sysctl aktiviert sein und push "route 172.16.0.0 255.255.0.0" in der server.conf von OpenVPN eingestellt sein.