Piwik – Umgehen von Ad Blockern

Ad Blocker beeinflussen nicht nur das Anzeigen von nerviger Werbung auf Webseiten, sondern sie blockieren ebenfalls die Analyse Skripte auf den Seiten wie Piwik oder Google Analytics.

Sie blockieren diese Skripte, um bspw. Marketing-Tracking von Drittanbieter-Werbetreibenden, z. B. Google, einzudämmen. Wenn man Piwik Analytics oder eines der meisten anderen selbst gehosteten Systeme verwendet, kann man diese Blockierung allerdings umgehen, indem man die URL umschreibt.

Adblocker suchen auf Webseiten nämlich bspw. nach Keywords in diesen URLs wie http://…/piwik/piwik.js

Diese werden dann an der Ausführung gehindert.

Umschreiben der URL

Zunächst wird die Haupt URL via .htaccess oder Seitenkonfiguration geändert:

RewriteEngine On
RewriteRule ^wieauchimmerdieneueurlheissensoll/(.*) /piwik/piwik.$1 [L]

Der neue Pfad kann nach Belieben geändert werden. Der zweite Pfad muss die eigentliche Installation von Piwik beinhalten.

Ändern Piwik Tracking Code

Anschließend muss der Tracking Code in den Seiten so angepasst werden, dass er auch den neuen Pfad verweist, damit die Ad Blocker nicht mehr anschlagen.

So sollte der Code vor der Änderung aussehen:

<!-- Piwik -->
<script type="text/javascript">
 var _paq = _paq || [];
 /* tracker methods like "setCustomDimension" should be called before "trackPageView" */
 _paq.push(['trackPageView']);
 _paq.push(['enableLinkTracking']);
 (function() {
 var u="//www.example.com/piwik/";
 _paq.push(['setTrackerUrl', u+'piwik.php']);
 _paq.push(['setSiteId', '1']);
 var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
 g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'piwik.js'; s.parentNode.insertBefore(g,s);
 })();
</script>
<!-- End Piwik Code -->

Und so sollte der Code mit den geänderten Werten aussehen:

<!-- Piwik -->
<script type="text/javascript">
 var _paq = _paq || [];
 _paq.push(['trackPageView']);
 _paq.push(['enableLinkTracking']);
 (function() {
 var u="//www.example.com/wieauchimmerdieneueurlheissensoll/";
 _paq.push(['setTrackerUrl', u+'php']);
 _paq.push(['setSiteId', 2]);
 var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
 g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'js'; s.parentNode.insertBefore(g,s);
 })();
</script>
<!-- End Piwik Code -->

Zeile 7: Hier muss die URL auf die geänderte URL angepasst werden, wie sie in der Rewrite-Regel definiert wurde.

Zeile 8,11: Hier wird “piwik.” entfernt. Manche Ad Blocker blockieren piwik.[php language=”/js”][/php] oder einfach das ganze Wort wie durch ABP.

Nach diesen Änderungen sollte Piwik auch Informationen sammeln können, wenn Ad Blocker verwendet werden. Tracker wie Ghostery listen Piwik bspw. nicht mehr als Tracker auf der Seite:

 

 

 

Advertisements

Nextcloud Kontakte Icon deaktivieren

Nextcloud zeigt über das Kontakte Icon in der Menüleiste alle Benutzer der Serverinstanz an. Auch, wenn die Kontakte App deaktiviert ist. Das kann ein Problem darstellen, wenn man mehrer Gruppen verwaltet, die sich untereinander nicht sehen sollen.

Eine Einstellung zur Deaktivierung dieser Funktion oder einer genaueren Festlegung des Verhaltens ist bisher nicht implementiert.

Es gibt zwei Möglichkeiten.

  1. Man deaktiviert in den Einstellungen die Möglichkeit zur Autovervollständigung der Namen. Dann werden keine Kontakte in der Liste angezeigt. Allerdings ist dann eben auch keine Vervollständigung im Teilen Dialog vorhanden.
  2. Man bearbeitet die Datei /core/templates/layout.user.php und kommentiert den Bereich für das Icon aus. Dann hat man keine Möglichkeit mehr auf das Icon zuzugreifen. Allerdings besteht dann immer noch die Möglichkeit, über den Teilen Dialog alle Benutzer zu finden, indem man Teile seines Namens eingibt.

[html]

</div> [/html]

DHCP Migration von Server 2008 R2 zu Server 2016

Die DHCP Migration von Server 2008 R2 zu Server 2016 sollte via netsh oder Powershell durchgeführt werden. Die Migration über die GUI der DHCP Konsole wirft einen Fehler und funktioniert u.U. nicht.

Zunächst muss die aktuelle DHCP Datenbank exportiert werden:

Anmeldung auf dem DHCP Server und Start einer administrativen CMD.

Netsh
DHCP
Server \<DHCP Server IP Addresse>
Export c:tempserver_dhcp-db all

Dadurch wird eine Datei namens c:tempserver_dhcp-db erstellt, welche auf den neuen DHCP Server kopiert werden muss.

Net stop DHCPserver
Del c:windowssystem32DHCPDHCP.mdb
Net start DHCPserver
Netsh
DHCP
Server \<DHCP Server IP Addresse>
Import c:tempserver_dhcp-db
Exit
Net stop DHCPserver
Net start DHCPserver

Danach kann der alte DHCP Server abgeschaltet werden. Die alte Datenbank mit allen Reservierungen sollte nun auf dem neuen Server vorhanden sein.

Import und Export via Powershell

Das Vorgehen kann auch via Powershell durchgeführt werden.

Der alte DHCP Server muss dazu mindestens unter Server 2008 laufen.

Auf dem Zielsystem öffnet man eine administrative Powershell. Darin wird nun das neue DHCP Server Modul genutzt.

Export-dhcpserver –computername ALTER.DHCP.SERVER –leases –file c:tempdhcp.xml –verbose

Nun kann man den alten DHCP Server abschalten und die Einstellungen in den neuen Server einspielen.

Import-dhcpserver –computername NEUER.DHCP.SERVER –leases –file c:tempdhcp.xml –backuppath C:tempBackup -verbose

Der Parameter backuppath ist zwingend. Dort wird die aktuelle DHCP Konfiguration zur Sicherung abgelegt.

SYSVOL Replikation – Migration von FRS zu DFS Replikation

Der Begriff SYSVOL (%SystemRoot%SYSVOL) bezieht sich auf einen Satz von Dateien und Ordnern, die auf der lokalen Festplatte jedes Domänencontrollers in einer Domäne gespeichert sind und durch den Dateireplikationsdienst (File Replication Service/FRS) repliziert werden. Netzwerkclients greifen über die folgenden freigegebenen Ordner auf den Inhalt der Struktur SYSVOL zu:

  • NETLOGON
  • SYSVOL

Der Dateireplikationsdienst (File Replication Service, FRS) synchronisiert Ordner mit Dateiservern, die den Dateireplikationsdienst anstelle der neueren DFS-Replikationstechnologie verwenden.

DFS-Replikation ermöglicht das Synchronisieren von Ordnern auf mehreren Servern über LAN- oder WAN-Netzwerkverbindungen. Dieser Dienst verwendet das RDC-Protokoll (Remote Differential Compression), um nur die Teile der Dateien zu aktualisieren, die seit der letzten Replikation geändert wurden.

In den alten Windows Server Verionen < 2003 R2 wurde FRS für die Replikation des SYSVOL Ordners auf andere Domain Controller verwendet. Ab Server 2008 wird primär DFS für die Replikation verwendet. FRS wird allerdings immer noch unterstützt.

Für die Migration von FRS zu DFS wird das Tool “Dfsrmig.exe” genutzt. Damit die Migration funktioniert muss die Domäne mindestens auf dem Funktionslevel von Server 2008 sein.

Ob FRS genutzt wird oder nicht findet man via Powershell

dfsrmig /getglobalstate

heraus.

Die Ausgabe sagt aus, dass die DFS-Replakations-Migration noch nicht eingeleitet wurde.

Die Migration an sich hat vier verschiedene Stati:

  1. Status 0 – Starten
  2. Status 1 – Vorbereitet
  3. Status 2 – Umgeleitet
  4. Status 3 – Entfernt

Status 0

Hierbei wird der Sysvol Ordner auf alle Domain Controller repliziert, um einen konsistenten Status auf allen Systemen zu erreichen.

Status 1

FRS repliziert weiterhin den Ordner. Zusätzlich legt DFS eine Kopie an, die sich unter %SystemRoot%SYSVOL_DFRS befindet. Allerdings ist dieses Verzeichnis inaktiv. FRS ist weiterhin der primäre Dienst.

Status 2

Hier ist es andersherum. DFS antwortet auf die Anfragen und FSR ist inaktiv, repliziert sich allerdings weiterhin.

Status 3

Hier wird der FSR Dienst gestoppt und Windows entfernt den Original Sysvol Ordner. Ab diesem Punkt ist kein Rollback mehr möglich.

Migration

Die Migration wird hier unter Powershell durchgeführt. Man muss Mitglied der Rolle Domänen- oder Enterprise Admin sein.

Wurde die DFSR-Migration noch nicht initialisiert, kann dies mit dem Befehl

dfsrmig /setglobalstate 0

gestartet werden.

Anschließend wird in den Status Vorbereitet gewechselt:

dfsrmig /setglobalstate 1

Durch Eingabe von

dfsrmig /getmigrationstate

kann man sich den aktuellen Status der Migration anschauen.

Wenn der Stand konsistent ist, kann weiter gemacht werden.

dfsrmig /setglobalstate 2

dfsrmig /setglobalstate 3

Abschließend sollte nun nicht nur der FRS Dienst gestoppt und deaktiviert sein, sondern ebenfalls die Sysvol Shares auf das neue Verzeichnis gemappt sein.

Durch

net share

werden die Netzlaufwerke angezeigt.

Subversion SVN Migration Dump Autoimport

Bei der Migration von Subversion auf einen neuen und aktuelleren Server steht irgendwann auch die Migration der Repositories an. Je nach Umfang und Anzahl kann das einige Zeit und Handarbeit in Anspruch nehmen.

Um den Ablauf zu vereinfachen und zu automatisieren, kann man folgendermaßen vorgehen:

Migration der Dumps

Die Repositories können als Dump abgespeichert werden und dienen als Container, um sie auf dem neuen System wieder einspielen zu können. Ich gehe jetzt hier davon aus, dass die Dumps regelmäßig auf dem Produktivserver erstellt werden und sich immer am gleichen Platz befinden.

Hier liegen die Dumps unter /data/backups/svn liegen. In meinem Fall mit Datumsangaben und “_dump_” Bezeichnung im Namen:

Die Struktur des neues Subversion Systems ist die selbe. Die Pfade unterscheiden sich also nicht.

Um die Dumps vom alten System auf das neue zu migrieren, wird folgendes Rsync-Kommando als Cronjob abgesetzt.

rm /data/backups/copy-from-svn.log && sshpass -p "***" rsync -ru --delete-after --progress root@subversion-server:/data/backups/svn /data/backups  >> /data/backups/copy-from-svn.log 2>&1

Hierbei wird zunächst das Log des letztes Kopiervorgangs entfernt und sich dann via SSH auf dem alten System angemeldet. Mittels sshpass werden die notwendigen Anmeldedaten mitgegeben. Es wird der Ordner “/data/backups/svn” vom alten System nach “/data/backups” auf das neue System kopiert. Ebenfalls werden alte Dumps, die in der Quelle nicht mehr vorhanden sind, auf dem Zielsystem entfernt

Die Resultate werden nach “/data/backups/copy-from-svn.log” geschrieben:

[...]
1,767,145,472 99% 30.51MB/s 0:00:00
1,767,177,519 100% 17.95MB/s 0:01:33 (xfr#4, to-chk=47/133)
svn/XXX_dump_20170220_221113_164.svn

0 0% 0.00kB/s 0:00:00
16,252,928 12% 11.18MB/s 0:00:10
31,162,368 23% 12.36MB/s 0:00:08
34,308,096 25% 9.59MB/s 0:00:09
44,269,568 33% 9.53MB/s 0:00:09
51,085,312 38% 7.96MB/s 0:00:09
58,490,880 44% 6.28MB/s 0:00:11
62,095,360 46% 6.17MB/s 0:00:11
63,143,936 47% 4.20MB/s 0:00:16
64,192,512 48% 2.81MB/s 0:00:23
64,978,944 49% 1.29MB/s 0:00:50
66,289,664 50% 839.52kB/s 0:01:18
68,648,960 51% 1.07MB/s 0:00:58
108,888,064 82% 9.26MB/s 0:00:02
132,429,452 100% 8.32MB/s 0:00:15 (xfr#5, to-chk=6/133)
0 files...
100 files...
deleting svn/XXX_dump_20170217_202748_150.svn
deleting svn/CCC_dump_20170112_204550_269.svn
deleting svn/AAA_dump_20170216_202115_2703.svn
deleting svn/BBB_dump_20170219_200018_4552.svn
deleting svn/VVV_dump_20170125_200906_990.svn

Nachdem der neue Server damit auf dem neusten Stand ist, kann das Import Skript ausgeführt werden.

Import der Dumps

cd /tmp
nano restore-all-dumps.sh (Inhalte rein und speichern)
chmod +x restore-all-dumps.sh

Inhalt des Skripts:

#!/bin/bash
rm /tmp/dumps
find "/data/backups/svn" -type f | sort >> "/tmp/dumps"
COUNT=1
SVNROOT="/data/srv/svn-parent"

sed -i -e '1d' "/tmp/dumps" # Wegschneiden der ersten Zeile
NUMBEROFDUMPS=$(cat /tmp/dumps | wc -l)

while read p; do
#String ohne _dump...
NEW=$(echo $p | sed s/"_dump.*"/""/)
#anfang pfad abschneiden
REPO=${NEW:18}
echo "### $COUNT von $NUMBEROFDUMPS###"
#kompletter Pfad
echo "Backupfile: $p"
#Pfad ohne das Ende _dump...
#echo $NEW
#Pfad vorne abgeschnitten, also nur Name des Repos
echo "Repository: $REPO"

echo "Pruefe aktuelles Repository gegen den letzten Copy Job"
for fn in `cat /data/backups/copy-from-svn.log | grep "svn/" | grep -v "deleting"`; do
        if [[ $fn == *"svn/$REPO"* ]]; then
                echo "* Aktuelles Repository in der Liste gefunden!"
                echo "* String im Log:        $fn"
                echo "* Passendes Repository: $REPO"
                echo "* Repository muss neu erstellt werden, loesche die alte Version"
                rm -R $SVNROOT/$REPO
                if [ ! -d "$SVNROOT/$REPO" ]; then
                        echo "* Alte Version geloescht"
                fi
        fi
done

if [ -d "$SVNROOT/$REPO" ]; then
        echo "Der Pfad zum aktuellen Repository besteht. Es gibt keine neuere Version."
fi

#Wenn Pfad vom Repo nicht vorhanden, dann direkt erstellen
if [ ! -d "$SVNROOT/$REPO" ]; then
        echo "Repository noch nicht vorhanden, starte Import"
        svnadmin create $SVNROOT/$REPO
        chown www-data:www-data -R $SVNROOT/$REPO
        gunzip -c  $p | svnadmin load $SVNROOT/$REPO > restore_log.log
        cp $SVNROOT/pre-commit_ $SVNROOT/$REPO/hooks/pre-commit
        chmod +x $SVNROOT/$REPO/hooks/pre-commit
        chown www-data:www-data -R $SVNROOT/$REPO
fi

((COUNT++))
done < /tmp/dumps
echo "Durchlauf abgeschlossen"

Was passiert hier?

  • Zeile 2-3: Die alte Datei, die die Auflistung der Dumps enthält wird gelöscht und anschließend wird sie neu erstellt (Liste aller Dateien, die im Verzeichnis gefunden wurden)
  • Zeile 6: Die erste Zeile der Datei wird entfernt, da dort das Verzeichnis an sich aufgeführt wird, was allerdings kein Repository wiederspiegelt.
  • Zeile 8-53: Loop über die erstellte Datei
  • Zeile 9-19: Bearbeiten der Zeilenrückgaben, die den Pfad und Namen des Dumps beinhalten, sodass am Ende nur der Name des Repositories erreicht wird
  • Zeile 21-34: Das aktuelle Repository $REPO wird mit den Inhalten des RSYNC Logs abgeglichen, wenn ein Repository vorhanden ist, welches allerdings einen neuen Dump besitzt, wird es gelöscht.
  • Zeile 40-50: Wenn das Verzeichnis des aktuellen Repositories nicht vorhanden ist, wird der Dump importiert.

So werden bestehende Repositories übersprungen, neue angelegt und aktualisierte Dumps, die auf dem alten Server in neuer Version vorliegen und kopiert wurden, neu angelegt, damit der Stand nach dem Durchlauf auf beiden Systemen gleich ist.

Seit den neusten SVN Versionen muss der Apache Dienst nach einem Dump-Import neu gestartet werden, da es sonst zu diversen Fehlern im Repository kommt.
Diese könnten sein:

  • Corrupt node-revision
  • Corrupt representation
  • svnadmin: E160004: r1516’s root node’s predecessor is r1514 but should be r1515
  • filesystem corrupt

service apache2 restart

Nach dem Ausführen des Skripts sieht es in etwa so aus:

bzw.

Jira Umstellung auf SSL unter Linux

Um Jira auf SSL umzustellen, benötigt man im Grunde nur ein valides SSL Zertifikat und muss eine Anpassung in der server.xml vornehmen.

Die nachfolgende Durchführung ist Linux bezogen.

Die Jira-Pfade lauten:

  • Java Home: /opt/atlassian/jira/jre/bin/keytool
  • Jira Home: /var/atlassian/application-data/jira
  • Jira Install: /opt/atlassian/jira/

Erstellen des SSL Zertifikat (selbst signiert)

Jira speichert die Zertifikate im eigenen Java Keystore.

/opt/atlassian/jira/jre/bin/keytool -genkey -alias jira -keyalg RSA -keystore /var/atlassian/application-data/jira/jira.jks

Hier wird anschließend das Passwort des Zertifikatsspeichers hinterlegt sowie die Informationen, welche im Zertifikat hinterlegt sein sollen.

Wer sein Zertifikat von einer CA signieren lassen will, findet hier weitere Infos.

Anschließend kann man verifizieren, dass das Zertifikat vorliegt:

/opt/atlassian/jira/jre/bin/keytool -list -alias jira -keystore /var/atlassian/application-data/jira/jira.jks

Der Eintrag sollen einen “PrivateKeyEntry” beinhalten.

jira, 17.02.2017, PrivateKeyEntry,
Zertifikat-Fingerprint (SHA1): FF:09:6F:4D:CA:B4:2D:D3:EF:F8:D9:CC:51:AA:66:F8:22:B9:97:CA

Tomcat Anpassungen (server.xml)

Die Konfiguration des Tomcat Webservers befindet sich in folgender Datei: <JIRA_INSTALL>/conf/server.xml

<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
maxHttpHeaderSize="8192" SSLEnabled="true"
maxThreads="150" minSpareThreads="25"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true"
keyAlias="jira" keystoreFile="<JIRA_HOME>/jira.jks" keystorePass="changeit" keystoreType="JKS"/>

Anschließend kann Jira neu gestartet werden und die sichere Verbindung unter https://jira.domain.whatever:8443 abgerufen werden.

Anpassungen des ReverseProxys

Da Jira unter Linux nicht auf den bekannten http-Ports 80 und 443 laufen kann, wird im Normalfall ein Proxy vorgeschaltet.

Dieser muss für die neue Konfiguration angepasst werden:

<VirtualHost *:80>
ServerName jira.domain.de
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
</VirtualHost>
<VirtualHost *:443>
ServerName jira.domain.de

ErrorDocument 502 /502/index.html
ErrorDocument 503 /503/index.html

SSLEngine On
SSLProxyEngine On
SSLCertificateFile /etc/myssl/cert.pem
SSLCertificateKeyFile /etc/myssl/cert.key
SSLCertificateChainFile /etc/myssl/intermediate.crt

ProxyPreserveHost on
ProxyPass /503 !
ProxyPass /502 !
<Location />
Deny from all
Allow from 172.30
ProxyPass https://172.30.18.51:8443/
ProxyPassReverse https://172.30.18.51:8443/
</Location>
<Location /servicedesk>
ProxyPass https://172.30.18.51:8443/servicedesk
ProxyPassReverse https://172.30.18.51:8443/servicedesk
</Location>
</VirtualHost>

Die HTTP-Verbindungen werden mit o.g. Konfiguration auf HTTPS umgeleitet, sodass kein direkter, unverschlüsselter Zugriff mehr möglich ist. Ebenfalls werden eigene Error-Dokumente für die Fehler 502 und 503 hinterlegt, welche direkt auf dem Proxy liegen und daher nicht umgeleitet werden sollen. In meinem Fall wird der Zugriff auf die Haupt-Jira-Instanz nur aus einem bestimmten IP-Subnet zugelassen. Die Servicedesk-Seiten sollen allerdings von überall aus erreichbar sein.

Apache Dienst neustarten und fertig.

Powershellverbindung mit Exchange Online / Office365

Die neben der GUI weitaus mächtigere Möglichkeit seinen Exchange zu administrieren bietet die Powershell. Die aus lokalen Exchange Installationen bekannte Powershell Remote Session funktioniert ebenfalls für Office365 Exchange Umgebungen.

Zunächst hinterlegt man seine Anmeldeinformationen,

$UserCredential = Get-Credential

um anschließend eine Session mit Exchange Online herzustellen:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Mit

Import-PSSession $Session

wird die Session gestartet und mit

Remove-PSSession $Session

wieder beendet.

Die ab jetzt verfügbaren Cmdlets werden temporär zwischengespeichert:

Über den Befehl

Get-Command | ? {$_.source -eq "NAME"}

lassen sich alle neuen Funktionen anzeigen (wobei “NAME” in dem Fall für  “tmp_4e4tlvte.bjc” steht.