aptitude install curlftpfs

Mehr ist garnicht nötig und anschließend ist es möglich mittels

curlftpfs USER:PASSWORT@IP/HOSTNAME /mnt/backup_ftp/

den FTP-Server ganz normal zu mounten. Alle gängigen Filesystemkommandos zum verschieben, anlegen und bearbeiten von Dateien funktionieren.

/usr/bin/varnishlog -a -w /var/log/varnish/varnish.log -D -P /var/run/varnishlog/varnishlog.pid

/usr/bin/varnishncsa -a -c -w /var/log/varnish/varnishncsa.log -D -P /var/run/varnishncsa/varnishncsa.pid

Aber Achtung, je nach Traffic und Auslastung wächst das Logfile sehr schnell an.

varnishadm -T 127.0.0.1:6082 -S /etc/varnish/secret

purge.url ^.*DATEINAME$

quit

Und schon wird die Datei beim nächsten Abruf wieder vom Backend geholt.

Bei 2 Rechnern von uns war es der Fall, dass nach dem anschließenden Reboot kein Programm mehr funktioniert hat.
Erst eine Deinstallation von Avast hat Abhilfe geschaffen. Sehr sehr ärgerlich. Ob andere Betriebssysteme oder Neuinstallationen auch betroffen sind kann ich leider nicht sagen. Vielleicht weiß der eine oder andere mehr. Auf Twitter steht noch recht wenig.

Update:
Auch Neuinstallation von Avast gibt die gleichen Probleme. Herrlich.

Deinstallation habe ich nur gesfchafft indem ich das Setup erneut heruntergeladen habe und dieses dann ausgeführt. Deinstallation über Systemsteuerung war nicht möglich.

Update2:

Lösung des ganzen so wie es aussieht ist es wenn man noch ein zusätzliches Verhaltensschutzprogramm (in unserem Fall Threatfire) nutzt den Verhaltensschutz von avast wegzulassen, oder eben auf den 2ten Verhaltensschutz zu verzichten und diesen zu deinstallieren.

In unserem Falle war das Logfile schon auf über 12GB angewachsen. Die Datenbank selber mit 50MB dagegen absolut winzig. Über Sinn oder Unsinn kann man hier natürlich streiten. Ich will nun einen relativ einfachen Weg aufzeigen das Logfile ohne Offline Zeit zu verkleinern.

Wir benötigen dazu das SQL Management Studio Express.
Die erste Hürde ist der richtige Servername. Hier muss folgende Verbindung gewählt werden.
Wobei die Authentifizierung natürlich abweichen kann.

Danach kopieren wir uns den Namen der Config Datenbank

Dieser wird benötigt um die einzelnen SQL Befehle auszuführen

Im einzelnen führen wir jetzt folgende Befehle nacheinander, oder auch in einem Zug aus.
Hier muss natürlich der Name der Datenbank angepasst werden innerhalb der [].

BACKUP LOG [SharePoint_Config_ad568963-5033-41a9-9033-8fb30239fdbe] TO DISK=’E:\Backup\SBS2008\MSSQL\configLogBackup.bak’
GO

BACKUP LOG [SharePoint_Config_ad568963-5033-41a9-9033-8fb30239fdbe] WITH TRUNCATE_ONLY
USE [SharePoint_Config_ad568963-5033-41a9-9033-8fb30239fdbe]
GO

DBCC SHRINKFILE (N’SharePoint_Config_ad568963-5033-41a9-9033-8fb30239fdbe_log’ , 50)
GO

Die einzelnen Befehle sichern erstmal die Datenbank auf das Filesystem, löschen danach die Einträge und verkleinern das LDF File.

Am Ende sollte wieder genug Speicher freigegeben werden.

Oftmals soll für jeden einzelnen Benutzer schon an dieser Stelle die Zugriffe eingeschränkt werden, weitab von Logins und Zugängen innerhalb der im Netzwerk bereitgestellten Applikationen.

OpenVPN bietet hier leider keine Möglichkeit das ganze auf den sich verbindenden Benutzer (z.B. Common Name im Zertifkat) zu beziehen und hier gleich versch. Regeln zu hinterlegen.

Das ganze muss auf der Routingebene abgehandelt werden.
In unserem Fall sollten die Zugriffe für externe Mitarbeiter und Dienstleister stark eingeschränkt werden, während normale Mitarbeiter weitaus mehr Freiheiten haben sollen.

Um das umzusetzen sind für die versch. Zugriffe leider 2 Instanzen des OpenVPN Servers notwendig, die unabhängig voneinander konfiguriert werden müssen.
Das ganze kann bequem über die server.conf erfolgen.Wichtige Einstellungen die sich in beiden Instanzen unterscheiden müssen sind hier:

#Our Server IP
ifconfig 192.168.222.1 255.255.255.0

#dynamic clients from 10.0.0.2-10.0.0.254
ifconfig-pool 192.168.222.100 192.168.222.150

# Port
port 1194

Danach eben den Server mit den entsprechenden Configs starten.

/usr/sbin/openvpn –writepid /var/run/openvpn.server.pid –daemon ovpn-server –status /var/run/openvpn.server.status 10 –cd /etc/openvpn –config /etc/openvpn/server.conf

/usr/sbin/openvpn –writepid /var/run/openvpn_extern.server.pid –daemon ovpn-server –status /var/run/openvpn_extern.server.status 10 –cd /etc/openvpn_extern –config /etc/openvpn_extern/server.conf

In unserem Fall eben eine Instanz für die Mitarbeiter und eine für die externen Dienstleister.

Nun haben aber beide Netze noch die vollen Zugriffsrechte und könnten alle Server im LAN erreichen.
Hier kommt nun IPTABLES und entsprechende Regeln ins Spiel.

Erstmal suchen wir, welches Interface die VPN Connections von extern bearbeitet

tap1      Link encap:Ethernet  Hardware Adresse 00:ff:87:b9:13:c8
inet Adresse:192.168.223.1  Bcast:192.168.223.255  Maske:255.255.255.0

In unserem Fall also tap1.
Wir wollen jetzt erstmal den Zugriff auf das komplette LAN abschalten, und auch auf den OpenVpN Server

iptables -A FORWARD -i tap1 -p all -j DROP
iptables -A INPUT -i tap1 -d 192.168.223.0/24 -j DROP

Der Client kann jetzt keinerlei Verbindungen mehr ins Netzwerk aufbauen, kann sich aber weiterhin verbinden.
Jetzt wollen wir den Zugriff auf eine einzelne Applikation (z.B. SBS Intranet Webseite) freischalten. Der SBS hat bei uns die IP 192.168.1.1. Die Regel muss unbedingt vor der DROP Regel stehen, da IPTABLES Sequentiell von oben nach untern vorgeht. Deswegen setzen wir sie mit -I 1 nach vorne!

iptables -I FORWARD 1 -p tcp -i tap1 -d 192.168.1.1 –dport 80 -j ACCEPT

Das sollte den Zugriff ermöglichen.
So kann man jetzt einzelne Applikationen nach und nach freischalten.

i915.modeset=1

Um das ganze danach im System permanent zu machen helfen folgende Zeilen:

echo options i915 modeset=1 | sudo tee /etc/modprobe.d/i915-kms.conf
sudo update-initramfs -u

Ein PAC Script das mit dem IE tadellos funktioniert und unter XP auch noch mit dem Firefox verweigert seinen Dienst.

Das ganze liegt an der DNS Implementation im Zusammenspiel mit Ipv6. Stellt man im Firefox die IPV6 Unterstützung aus, so klappt das ganze wieder.

about:config den Wert network.dns.disableIPv6 von false auf true

Die Frage ist nur, wie lange kann man auf IPV6 noch verzichten.

Als Ergänzung hier mal noch mein PAC Script:

function FindProxyForURL(url, host)
{
if (
isInNet(host, “10.0.0.0″, “255.0.0.0″) ||
isInNet(host, “172.16.0.0″, “255.240.0.0″) ||
isInNet(host, “192.168.0.0″, “255.255.0.0″) ||
isPlainHostName(host) ||
localHostOrDomainIs(host, “127.0.0.1″) ||
dnsDomainIs(host, “.company.local”)
)

return “DIRECT”;

else if (
isInNet(myIpAddress(), “10.1.0.0″, “255.255.0.0″) ||
isInNet(myIpAddress(), “10.2.0.0″, “255.255.0.0″) ||
isInNet(myIpAddress(), “10.3.0.0″, “255.255.0.0″) ||
isInNet(myIpAddress(), “10.4.0.0″, “255.255.0.0″) ||
isInNet(myIpAddress(), “10.7.0.0″, “255.255.0.0″) ||
isInNet(myIpAddress(), “10.9.0.0″, “255.255.0.0″) ||
isInNet(myIpAddress(), “10.10.0.0″, “255.255.0.0″) ||
isInNet(myIpAddress(), “169.254.0.0″, “255.255.0.0″) ||
isInNet(myIpAddress(), “192.168.0.0″, “255.255.255.0″)
)

return “PROXY 192.168.0.1:800;”

else return “DIRECT”;
}

Eine Methode die mir dabei sehr geholfen hat ist folgende.

Entpacken der ganzen Logs (Achtung: Auf genügend Speicher achten)
gunzip *.gz

Mergen der Logdateien zu einer Datei mit sortiertem Datumsstempel (Kann ewig dauern J )
logresolvemerge.pl * > access.log

Erstellen der Webalizer Statistik

Das logresolvemerge.pl Script steht bei Debian z.B. im Paket “awstats” zur Verfügung und kann dann von dirt bequeem kopiert werden, um es via Direktaufruf nutzen zu können

mv /usr/share/doc/awstats/examples/logresolvemerge.pl /usr/local/bin