AWStats 6.95 – Externe Links (Referrer) wegen Spams im Report anonymisieren

Es ist hinlänglich bekannt, dass der Browser (in der Standardkonfiguration) Brotkrümmel in Form von Referrer im ganzen Web hinterlässt und kann für die eigene Analyse sehr nützlich sein. Nicht zuletzt greifen die Spammer genau diesen Trick auf, um ihre Webseite oder als Dienstleister anderer Webseiten in den Logdateien zu verewigen. Der User wird im Report dazu verleitet auf den externen Link zu klicken, um zu sehen wer denn da auf seine Webseite verlinkt hat. Oft ist man hinterher ziemlich verärgert, weil da überhaupt kein Gegenlink vorhanden ist und der Spammer hat in diesem Fall schon gewonnen. Ich gebe zu, dass ich ebenfalls auf den Leim gegangen bin, weil der Link einfach zu plausibel klang. :roll:

Es kommt öfter vor, dass man den Webserver mit all seinen Webstatistiken nicht alleine nutzt, somit gehen auch andere User in die Falle und verraten sich durch den Browser die Herkunft seines Besuches. Die Spammer könnten ihre eigene Logdateien analysieren, um zu sehen wer die Seite besucht hat und bombardieren dann die ertappten „Webmaster“ mit ihren Referrer-Links zu.

In diesem Fall kann es ganz nützlich sein den Referrer-Link über anonym.to zu anonymisieren, um die Herkunft über die Domain bzw. Webstatistik zu verschleiern und habe hierzu einige Ergänzungen im Skript …/cgi-bin/awstats.pl veranlasst. Hier wird zu jedem externen Link noch um den notwendigen Link erweitert: http://anonym.to/?(referrerlink)

Hierzu habe ich einen Patch vorbereitet und man kann ihn sich hier herunterladen.
Download: awstats-6.95-anonym-referer.patch
SHA1: awstats-6.95-anonym-referer.patch.sha1

Der Patch muss ins gleiche Verzeichnis kopiert werden, in der auch das Skript awstats.pl liegt und anschließend wie folgt ausführen:

patch <awstats-6.95-anonym-referer.patch

Danach ist die Welt ein bisschen besser geworden und macht sich auch in der Statistik bemerkbar. :-)

openSUSE 11.2 – proprietären Grafik-Treiber ATI Catalyst 10.2 als RPM installieren

Hinweis: Dieser Artikel ist veraltet. Ein neuer Artikel befindet sich hier: openSUSE 11.2 – proprietären Grafik-Treiber ATI Catalyst 10.3 als RPM installieren

Es gibt 2 Wege den Bau des RPM-Packages durchzuführen.

  1. das RPM mit dem Skript makerpm-ati-10.2.sh bauen (empfohlen)
  2. das RPM manuell bauen (für Fortgeschrittene)

Der Vorteil zu Punkt 1: man muss sich nicht um die nötigen Packages für den Bau kümmern und man spart sich die Tipparbeit, die Zeit und die Nerven. ;-)

Wichtig: Bevor ihr irgendwelche Fragen an mich richtet, lest euch bitte sorgfältig diesen Artikel durch und achtet auch auf eure Eingaben in der Konsole wegen mögliche Tippfehler. Falls es Probleme geben sollte, schaut bitte unter Troubleshooting nach, ob euer Problem dort schon dokumentiert wurde.

Alle genannten Schritte müssen in der Konsole im Root-Modus ausgeführt werden. Die Installation des RPM-Package „fglrx“ kann im Runlevel 3 oder auch im Runlevel 5 durchgeführt werden. Danach ist ein Neustart des Computers auf jeden Fall erforderlich.

Vorhandene fremde fglrx-Treiber sind auf jedenfall zu deinstallieren, sonst kommt es zu Konflikten bei der Installation dieses selbstgebauten RPM-Package.

RPM mit dem Skript bauen

Das Skript makerpm-ati-10.2.sh habe ich stark erweitert, ist sehr robust und läuft jetzt vollautomatisch. Der ATI-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Auf dem System werden nach den nötigen Entwicklungspakete geprüft und ggfs. installiert. Auf Wunsch wird nach dem Bau des RPM-Packages dieses ebenfalls installiert.

Folgende Argumente können dem Skript übergeben werden:
-b – Nur das RPM-Package bauen (Standard)
-c – Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten)
-d – Nur den ATI-Installer downloaden
-i – Das RPM-Package bauen und installieren bzw. updaten
-h – Die Hilfe anzeigen lassen
-V – Version des Skript anzeigen

Downloads:

Empfohlene Vorgehensweise:

Optional: Das System im Runlevel 3 starten oder wechseln:
Beim Booten: Im Bootmenü den Eintrag von openSUSE 11.2 selektieren und auf der Tastatur die Zahl „3“ und Enter drücken und als „root“ einloggen
Im laufenden System: STRG+ALT+F1 drücken und sich als „root“ einloggen. Danach mit folgendem Befehl in den Runlevel 3 wechseln:

init 3

1. Das Skript herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.2.sh

2. Die Prüfsummendatei herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.2.sh.sha1

3. Die Prüfsummendatei gegen das Skript prüfen:

sha1sum -c makerpm-ati-10.2.sh.sha1

Idealerweise sollte folgende Ausgabe erscheinen, andernfalls stimmt etwas mit dem heruntergeladenen Skript nicht:

makerpm-ati-10.2.sh: OK

4. Die Rechte des Skriptes ändern und ausführbar machen:

chown root:root makerpm-ati-10.2.sh && chmod 744 makerpm-ati-10.2.sh

5. Das Skript mit dem Argument -i ausführen. Das RPM-Package wird im Anschluß automatisch installiert.

./makerpm-ati-10.2.sh -i

7. Den Rechner neustarten:

reboot

Troubleshooting (RPM mit dem Skript bauen):

– Wenn man nach dem Booten die Konsole anstatt den Desktop sieht, dann kann es evtl. an einer fehlerhaften Konfiguration des X-Servers liegen. In diesem Fall bitte als „root“ in die Konsole einloggen und das Skript mit folgendem Parameter ausführen lassen.

Vorher noch in den Runlevel 3 wechseln:

init 3

Bei einem Monitor (Single-Modus):

./makerpm-ati-10.2.sh -c single

Bei zwei Monitore (Dual-Modus):

./makerpm-ati-10.2.sh -c dual

Danach den Rechner neustarten. Mit etwas Glück funktioniert alles wieder.

RPM manuell bauen

Das ist der etwas schwierigere Teil. Aber nicht unmöglich. :-)

Für den Bau des RPM-Packages werden folgende Entwicklungswerkzeuge bzw. -packages benötigt

  • gcc
  • make
  • patch
  • linux-kernel-headers
  • kernel-source
  • kernel-{default,desktop,pae,rt,vanilla,xen}-devel

Beim Kernel-Entwicklungspackage ist zu beachten, dass man die richtige installiert hat. Welchen Kernel zur Zeit auf dem System läuft, kann man in der Konsole abfragen:

uname -r

Bei mir ergibt beispielsweise diese Ausgabe:

2.6.31.12-0.1-default

Also muss im o.g. Fall der Kernel-Entwicklungspackage kernel-default-devel installiert sein.

Folgende Schritte werden auf einem 32bit openSUSE-System durchgeführt:
(64bit openSUSE-System weiter unten)

1. Den Installer des proprietären Treiber von ATI herunterladen:
http://support.amd.com/us/gpudownload/Pages/index.aspx

Optional: Das System im Runlevel 3 starten und als „root“ einloggen oder per init 3 wechseln.

2. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-2-x86.x86_64.run --buildpkg SuSE/SUSE112-IA32

3a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx_7_4_0_SUSE112-8.702*.rpm

3b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx_7_4_0_SUSE112-8.702*.rpm

4. Den Rechner neustarten:

reboot

Folgende Schritte werden auf einem 64bit openSUSE-System durchgeführt:

1. Den Installer des proprietären Treiber von ATI herunterladen:
http://support.amd.com/us/gpudownload/Pages/index.aspx

Optional: Das System im Runlevel 3 starten und als „root“ einloggen oder per init 3 wechseln.

2. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-2-x86.x86_64.run --buildpkg SuSE/SUSE112-AMD64

3a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx64_7_4_0_SUSE112-8.702*.rpm

3b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx64_7_4_0_SUSE112-8.702*.rpm

4. Den Rechner neustarten:

reboot

Troubleshooting (RPM manuell bauen):

– Wenn man nach dem Booten die Konsole anstatt den Desktop sieht, dann kann es evtl. an einer fehlerhaften Konfiguration des X-Servers liegen. In diesem Fall bitte als „root“ in die Konsole einloggen und folgende Schritte durchführen.

1. X-Server-Konfiguration verschieben, falls vorhanden:

mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup

2. Von SaX2 eine neue Konfigurationsdatei erzeugen lassen:

sax2 -a

3. Die Konfigurationsdatei von aticonfig für die Nutzung des fglrx-Treibers modifizieren lassen.

3a. Bei einem Monitor (Single-Modus):

aticonfig --initial --input=/etc/X11/xorg.conf

3b. Bei zwei Monitore (Dual-Modus):

aticonfig --initial=dual-head --input=/etc/X11/xorg.conf

Wie immer würde ich mich für Feedbacks sehr freuen. :-)

openSUSE 11.2 – proprietären Grafik-Treiber ATI Catalyst 10.1 als RPM installieren

Hinweis: Dieser Artikel ist veraltet. Ein neuer Artikel befindet sich hier: openSUSE 11.2 – proprietären Grafik-Treiber ATI Catalyst 10.2 als RPM installieren

Es gibt 2 Wege den Bau des RPM-Packages durchzuführen.

  1. das RPM mit dem Skript makerpm-ati-10.1.sh bauen (empfohlen)
  2. das RPM manuell bauen (für Fortgeschrittene)

Der Vorteil zu Punkt 1: man muss sich nicht um die nötigen Packages für den Bau kümmern und man spart sich die Tipparbeit, die Zeit und die Nerven. ;-)

Alle genannten Schritte müssen in der Konsole im Root-Modus ausgeführt werden. Es wird empfohlen, die Installation des RPM-Package „fglrx“ im Runlevel 3 durchzuführen.

Vorhandene fremde fglrx-Treiber sind auf jedenfall zu deinstallieren, sonst kommt es zu Konflikten bei der Installation dieses selbstgebauten RPM-Package.

RPM mit dem Skript bauen

Das Skript makerpm-ati-10.1.sh habe ich stark erweitert, ist sehr robust und läuft jetzt vollautomatisch. Der ATI-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Auf dem System werden nach den nötigen Entwicklungspakete geprüft und ggfs. installiert. Auf Wunsch wird nach dem Bau des RPM-Packages dieses ebenfalls installiert.

Folgende Argumente können dem Skript übergeben werden:
-b – Nur das RPM-Package bauen (Standard)
-c – Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten)
-d – Nur den ATI-Installer downloaden
-i – Das RPM-Package bauen und installieren bzw. updaten
-h – Die Hilfe anzeigen lassen
-V – Version des Skript anzeigen

Downloads:

Empfohlene Vorgehensweise:

1. Das System im Runlevel 3 starten oder wechseln (Alternativ kann man auch diesen Punkt nach Punkt 4 durchführen, falls das Netzwerk in Runlevel 3 nicht verfügbar ist):
Beim Booten: Im Bootmenü den Eintrag von openSUSE 11.2 selektieren und auf der Tastatur die Zahl „3“ und Enter drücken und als „root“ einloggen
Im laufenden System: STRG+ALT+F1 drücken und sich als „root“ einloggen. Danach mit folgendem Befehl in den Runlevel 3 wechseln:

init 3

2. Das Skript herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.1.sh

3. Die Prüfsummendatei herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.1.sh.sha1

4. Die Prüfsummendatei gegen das Skript prüfen:

sha1sum -c makerpm-ati-10.1.sh.sha1

Idealerweise sollte folgende Ausgabe erscheinen, andernfalls stimmt etwas mit dem heruntergeladenen Skript nicht:

makerpm-ati-10.1.sh: OK

5. Die Rechte des Skriptes ändern und ausführbar machen:

chown root:root makerpm-ati-10.1.sh && chmod 744 makerpm-ati-10.1.sh

6. Das Skript mit dem Argument -i ausführen. Das RPM-Package wird im Anschluß automatisch installiert.

./makerpm-ati-10.1.sh -i

7. Den Rechner neustarten:

reboot

Troubleshooting (RPM mit dem Skript bauen):

– Wenn man nach dem Booten die Konsole anstatt den Desktop sieht, dann kann es evtl. an einer fehlerhaften Konfiguration des X-Servers liegen. In diesem Fall bitte als „root“ in die Konsole einloggen und das Skript mit folgendem Parameter ausführen lassen.

Bei einem Monitor (Single-Modus):

./makerpm-ati-10.1.sh -c single

Bei zwei Monitore (Dual-Modus):

./makerpm-ati-10.1.sh -c dual

Danach den Rechner neustarten. Mit etwas Glück funktioniert alles wieder.

RPM manuell bauen

Das ist der etwas schwierigere Teil. Aber nicht unmöglich. :-)

Für den Bau des RPM-Packages werden folgende Entwicklungswerkzeuge bzw. -packages benötigt

  • gcc
  • make
  • patch
  • linux-kernel-header
  • kernel-source
  • kernel-{default,desktop,pae,rt,vanilla,xen}-devel

Beim Kernel-Entwicklungspackage ist zu beachten, dass man die richtige installiert hat. Welchen Kernel zur Zeit auf dem System läuft, kann man in der Konsole abfragen:

uname -r

Bei mir ergibt beispielsweise diese Ausgabe:

2.6.31.8-0.1-default

Also muss im o.g. Fall der Kernel-Entwicklungspackage kernel-default-devel installiert sein.

Folgende Schritte werden auf einem 32bit openSUSE-System durchgeführt:
(64bit openSUSE-System weiter unten)

1. Den Installer des proprietären Treiber von ATI herunterladen:
http://support.amd.com/us/gpudownload/Pages/index.aspx

2. Das System im Runlevel 3 starten und als „root“ einloggen oder per init 3 wechseln.

3. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-1-x86.x86_64.run --buildpkg SuSE/SUSE112-IA32

3a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx_7_4_0_SUSE112-8.69*.rpm

3b. Das RPM-Package installieren (Update). Bedauerlicherweise muss man das Argument –force mitgeben (bedankt euch bei ATI), denn der RPM-Paketmanager geht hier sonst von einem veralteten Package aus und verweigert die Installation bzw. das Update:

rpm -Uhv --force fglrx_7_4_0_SUSE112-8.69*.rpm

4. Den Rechner neustarten:

reboot

Folgende Schritte werden auf einem 64bit openSUSE-System durchgeführt:

1. Den Installer des proprietären Treiber von ATI herunterladen:
http://support.amd.com/us/gpudownload/Pages/index.aspx

2. Das System im Runlevel 3 starten und als „root“ einloggen oder per init 3 wechseln.

3. Den Bau des RPM-Packages anstoßen:

sh ./ati-driver-installer-10-1-x86.x86_64.run --buildpkg SuSE/SUSE112-AMD64

3a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx64_7_4_0_SUSE112-8.69*.rpm

3b. Das RPM-Package installieren (Update). Bedauerlicherweise muss man das Argument –force mitgeben (bedankt euch bei ATI), denn der RPM-Paketmanager geht hier sonst von einem veralteten Package aus und verweigert die Installation bzw. das Update:

rpm -Uhv --force fglrx64_7_4_0_SUSE112-8.69*.rpm

4. Den Rechner neustarten:

reboot

Troubleshooting (RPM manuell bauen):

– Wenn man nach dem Booten die Konsole anstatt den Desktop sieht, dann kann es evtl. an einer fehlerhaften Konfiguration des X-Servers liegen. In diesem Fall bitte als „root“ in die Konsole einloggen und folgende Schritte durchführen.

1. X-Server-Konfiguration verschieben, falls vorhanden:

mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup

2. Von SaX2 eine neue Konfigurationsdatei erzeugen lassen:

sax2 -a

3. Die Konfigurationsdatei von aticonfig für die Nutzung des fglrx-Treibers modifizieren lassen.

3a. Bei einem Monitor (Single-Modus):

aticonfig --initial --input=/etc/X11/xorg.conf

3b. Bei zwei Monitore (Dual-Modus):

aticonfig --initial=dual-head --input=/etc/X11/xorg.conf

Ich hoffe, dass ich das Thema komplett abgedeckt und nicht doch noch irgendetwas vergessen habe. Ich würde mich für Feedbacks sehr freuen. :-)

openSUSE 11.2 – Ein NTP-Dienst (Network Time Protocol Version 4) konfigurieren

In diesem Artikel gehe ich heute auf den NTP-Dienst unter openSUSE ein. Dieser Dienst ist bereits vorinstalliert, aber noch nicht aktiviert bzw. abschließend konfiguriert. Dieser Dienst synchronisiert die Systemzeit mit der Atomuhr bzw. Funkuhr. Die Besonderheit dieses NTP-Dienstes ist es, dass die Uhrzeit der Atomuhr schonend mit der Systemzeit abgleicht. Hier mal ein Beispiel: Für den Betrieb mit Dovecot ist die schonende Synchronisierung sehr wichtig. Denn bei größerer Abweichung der Systemzeit quittiert Dovecot seinen Dienst und beendet sich selbst. Da kommt man schon in Erklärungsnot, weshalb die lieben Menschen keine Post mehr abrufen können und kommt daher nicht besonders gut an. ;-)

Veraltete NTP-Programme wie ntpdate sollte man nicht mehr verwenden, da diese richtig hart die Systemzeit stellen und das mögen manche Dienste aus den oben genannten Gründen nicht.

Nun kommen wir zur Konfiguration und fügen ausserdem noch weitere NTP-Server für den deutschen Sprachraum hinzu, um mögliche Latenzzeiten aus dem Weg zu gehen. Falls man in einem anderen Land ist, sollte man möglichst einen NTP-Server wählen, der in dem eigenen Land steht. Mehr Infos dazu gibt es unter www.pool.ntp.org oder www.ptb.de/de/org/q/q4/q42/ntp/ntp_main.htm.

1. Starte das YaST-Kontrollzentrum

2. Starte dann „NTP-Einrichtung“ im Abschnitt „Netzwerkdienste“

3. Wähle bei „NTP-Daemon starten“ => „Jetzt und beim Systemstart“ aus

4. Auf „Hinzufügen“ klicken

5. Die Auswahl „Server“ wählen und auf „Weiter“ klicken

6. Die NTP-Server Adresse eingeben: 0.de.pool.ntp.org

7. Mit „Okay“ bestätigen.

8. Die Schritte 4 – 7 wiederholen für weitere NTP Server:

  • 1.de.pool.ntp.org
  • 2.de.pool.ntp.org
  • 3.de.pool.ntp.org
  • ptbtime1.ptb.de
  • ptbtime2.ptb.de
  • ptbtime3.ptb.de

9. Mit „Okay“ die Einrichtung des NTP-Dienstes bestätigen.

Wieso verwenden wir hier mehrere Pools und nicht ein einzigen wie z.B. de.pool.ntp.org? Die Antwort hatte ich eben schon teilweise vorgegeben. ;-) Es ist die Latenzzeit und die Erreichbarkeit der jeweiligen NTP-Server. Der NTP-Dienst pingt die jeweiligen NTP-Server an und entscheidet selbst, welcher Dienst am besten erreichbar und vorallem nutzbar ist.

Abschließend können wir in der Konsole überprüfen, wie der NTP-Dienst arbeitet:

rcntp status

Somit dürfte das System ohne Funkuhr sehr genau ticken. ;-)

openSUSE 11.2 – Splash-Screen beim Starten und Herunterfahren ausschalten

Standardmäßig wird beim Starten oder Herunterfahren des openSUSE-Systems der Splash-Screen vorgeschaltet. Man kann mit der ESC-Taste in der aktuellen Sitzung das Splash-Screen ausschalten und man erhält so die direkte Boot-Ausgabe. So kann man nach möglichen Fehlermeldungen beim Booten oder Herunterfahren sehen, die über den Schirm wandern. Wer möchte, kann diesen Splash-Screen auch dauerhaft ausschalten.

Hier die Anleitung:

1. Starte das YaST2-Kontrollzentrum

2. Starte den „Editor für /etc/sysconfig“  im Abschnitt „System“ vom YaST2-Kontrollzentrum

3. Im Editor auf der linken Seite den Pfad folgen:
System / Boot / SPLASH

4. Im DropDown-Feld „no“ wählen und auf „OK“ klicken. (Evtl. die Änderung nochmal bestätigen lassen)