Springe zum Inhalt

Mit Linux Mint 17 kommt auch Apache 2.4 auf den Rechner. Gegenüber der Version 2.2 gab es auch Änderungen bei der Vergabe von Zugriffsberechtigungen auf URLs. Leider bringt die Installation von Munin nur Einstellungen mit, die kompatibel mit der Apache Version 2.2 sind. Nach der Installation auf dem lokalen Host erscheint beim Zugriff auf http://localhost/munin nur ein "Forbidden".

Folgender Eintrag in der Datei /etc/apache2/conf-enabled/munin.conf innerhalb <Directory /var/cache/munin/www> schafft Abhilfe:

Require all granted
Options FollowSymLinks SymLinksIfOwnerMatch

Nach einem Neustart des Apache können dann wieder die Munin-Auswertungen angesehen werden.

Microsoft stellt mit der Library WinHTTP eine Schnittstelle zur Verfügung, mit der Programme Ressourcen per HTTP(S) abrufen können. Sollte das Programm keine Unterstützung für einen Proxy anbieten, so läßt sich mit Microsoft-eigenen Mitteln ein evtl. im Netzwerk erforderlicher Proxy für WinHTTP einstellen.

Systeme kleiner als Windows Vista verwenden dazu das Tool proxycfg, alle anderen netsh im winhttp-Kontext. Um z.B. die Proxy-Einstellungen aus dem Internet Explorer in die Registry für WinHTTP zu importieren, kann folgendes Kommando verwendet werden:

netsh winhttp import proxy source=ie

Die aktuellen Einstellungen lassen sich mit folgendem Kommando anzeigen:

netsh winhttp show proxy

Die Proxy-Einstellungen für WinHTTP können mit folgendem Kommando wieder gelöscht werden:

netsh winhttp reset proxy

32- und 64bit-Systeme

Auf 64bit-Windows ist die Registry zweigeteilt. Es gibt getrennte Einstellungen für 64bit- und 32bit-Programme in der Registry. Unter einem 64bit-Windows muss zum Ansprechen des 32bit-Teils der Registry netsh aus dem Verzeichnis C:\Windows\SysWOW64 aufgerufen werden.

C:\Windows\SysWOW64\netsh winhttp ...

Update

Anscheinend wurde das Problem mit unterschiedlichen Einstellungen für 32Bit- und 64Bit-Systeme unter Windows 8 behoben.

Seit pfSense 2.0 ist ein Zertifikatmanager in die Weboberfläche integriert, mit dem sich Zertifikate, z.B. für IPSEC, erzeugen und signieren lassen.

Bei der Verwendung der mit pfSense erstellten Zertifikate in Strongswan in Versionen kleiner als 4.6.2 kann der private Key nicht geladen werden. Folgende Fehlermeldung erscheint:

charon: 00[LIB] L1 - modulus: ASN1 tag 0x02 expected, but is 0x30
charon: 00[LIB] building CRED_PRIVATE_KEY - RSA failed, tried 8 builders

Ursache ist, dass Strongswan bis Version 4.6.2 nur private Keys im PKCS#1-Format lesen kann. Die aus pfSense exportierten privaten Keys liegen aber im PKCS#8-Format vor.

Mit folgendem Kommando kann der private Schlüssel vom PKCS#8- ins PKCS#1-Format konvertiert werden:

openssl rsa -in key8.pem -out key1.pem

Anschließend kann auch der Schlüssel wieder in Strongswan geladen werden.

1

IPv4 Adressen werden immer knapper und mittlerweile bekommt man bei vielen Hostern schon standardmäßig einen IPv6-Adressblock zum gemieteten Server dazu. Wer wie ich einen Debian-Server verwendet, bei dem die Root-Partition mit LUKS verschlüsselt ist und diese beim Bootvorgang über einen Dropbear-SSH-Zugang freigeschaltet werden muss, wird feststellen, dass nach dem Booten die Interfaces nicht die korrekte IPv6-Konfiguration haben.

Unter Debian kann die Netzwerkschnittstelle für Dropbear über die Datei /etc/initramfs-tools/initramfs.conf nur als IPv4 konfiguriert werden. Nach dem Booten stellen die Debian-Skripte fest, dass eth0 schon konfiguriert ist und verwenden die Einstellungen aus /etc/network/interfaces nicht mehr. Etwaige weitere Einstellungen in dieser Datei haben keine Wirkung, da sie nicht ausgewertet werden.

Abhilfe schafft ein

/sbin/ifdown --force eth0
/sbin/ifup --force eth0

in /etc/rc.local. Damit wird zuerst das Interface eth0 heruntergefahren und damit in einen definierten Zustand versetzt.  Anschließend wird das Interface wieder hochgefahren und die Einstellungen aus /etc/network/interfaces entsprechend angewendet.