Mir ist mal wieder ein Problem aufgefallen, welches mit Google und seinem Regulationanspruch zusammen hängt. Es ist nämlich so, dass manche WP-Systeme keine Mails an Google-Empfänger verschicken können. Man bekommt dann in der Logdateie eine Fehlermeldung wie:

<ein-user@gmail.com>: host gmail-smtp-in.l.google.com[142.251.175.26] said:
550-5.7.26 This mail is unauthenticated, which poses a security risk to the
550-5.7.26 sender and Gmail users, and has been blocked. The sender must
550-5.7.26 authenticate with at least one of SPF or DKIM. For this message,
550-5.7.26 DKIM checks did not pass and SPF check for
[h2412yxyz.stratoserver.ne 550-5.7.26 t] did not pass with ip:
[85.214.x.y]. The sender should visit 550-5.7.26
https://support.google.com/mail/answer/81126#authentication for 550 5.7.26
instructions on setting up authentication.
s24-20020a632158000000b0055acc7f8088si4258738pgm.301 - gsmtp (in reply to
end of DATA command)

Das hat schon eine gewisse Berechtigung, weil das WordPress-System hier keine sinnvolle Absenderadresse gesetzt hat, sondern www-data als Absender genommen hat. Das ergänzt das Mailsystem dann noch um den Servernamen. Damit schlagen dann die genannten Checks fehl.

Zur Beseitigung des Problems gibt es mehrere Möglichkeiten:

  1. Nutzung eines Plugins wie WP Mail SMTP/ 
  2. Anpassung der functions.php

Das vielgelobte Plugin hat mich genervet, weil es gleich eine Pro-Version anbietet. Ich habe also unter Design -> Theme-Datei-Editor die Datei functions.php (Theme-funktionen) um die folgenden Zeilen erweitert (einfach angehängt):

// Mail Hook mail_from
add_filter( 'wp_mail_from', function ( $original_email_address ) {
return 'testpress@meine-domain.de';
} );

// Mail Hook mail_from_name
add_filter( 'wp_mail_from_name', function ( $original_email_from ) {
return 'Testpress';
} );

//Action Hook phpmailer_init
add_action( 'phpmailer_init', 'my_phpmailer_init' );
function my_phpmailer_init( $phpmailer ) {
$phpmailer->Sender = $phpmailer->From;
}

Die beiden Mail-Hooks setzten die Absender-Adresse auf einen gewünschten Wert, wobei der Hook eigentlich eine funcion einbindet, die hier jeweils gleich integriert ist. In vielen Beschreibungen ist das auch getrennt (https://wordpress.org/support/topic/change-sender-name-and-email-address-wordpress/) .
Diese Einstellungen reichen aber nicht aus, weil damit die Adresse im Envelope (Umschlag) nicht geändert wird und das ist die entscheidende Stelle. Dafür gibt es einen Action-Hook, über den man die Initialisierung des Mailers vornehmen kann. Hier ändern wir nur den Wert für Sender und zwar auf den gerade davor gesetzten Wert von From.

Auch wenn innerhalb der WordPress Options, eventuelle durch eine Erweiterung,  eine Mailadresse gesetzt ist, wie z.B. wpmembers_email_wpfrom, so wird die erst durch die se Initialisierung aktiv.

Damit sollten jetzt auch Mails an z.B. Google-Adressen funktionieren, sofern der eingestellte Absender grundsätzlich entsprechende Mails verschicken kann.

Damit die Änderung nicht bei nächsten Update des Themes überschieben wird, sollte man ein Child-Theme anlegen, in dem diese Ergänzung realisiert wird.

Weitere Informationen:

https://developer.wordpress.org/reference/hooks/wp_mail_from/
https://developer.wordpress.org/reference/hooks/wp_mail_from_name/
https://developer.wordpress.org/reference/hooks/phpmailer_init/

 

Zurzeit bin ich dabei mit mehreren dieser kleinen Geräte Anwendungen zu realisieren. Dabei tauchen immer wieder Informationen auf, die ich nicht verlieren möchte. Dazu dient dieser Beitrag.

Raspis Temperatur

Der Raspi verfügt über einen eingebauten Temperatur-Sensor. Dieser Sensor lässt sich folgendermaßen abfragen:

cat /sys/class/thermal/thermal_zone0/temp

Dieser Aufruf liefert momentan konkret:

42345

Das ist als Temperatur von 42,3° zu interpretieren (einfach durch 1000 teilen).

Etwas direkter erhält man diese Temperatur mittels

vcgencmd measure_temp

Das liefert die Ausgabe

temp=42.3'C

 

In der letzten Zeit ist es nicht einfacher geworden PDF-Dokumente in einer Webseite darzustellen. Zwar beherrscht Firefox das problemlos, aber z.B. nicht die Android-Version. Auch auf verschiedenen Apfel-Geräten funktioniert das nicht von Haus aus.

Zum Glück gibt es das Projekt https://github.com/mozilla/pdf.js mit dessen Javascript die Einbindung auf sehr vielen Geräten identisch funktioniert. Ich habe mir die Software von https://mozilla.github.io/pdf.js/getting_started/ geladen und die ZIP-Datei in ein Verzeichnis /pdfjs entpackt.

Leider ist die Nutzung des Scripts etwas aufwendig. Eine einfache Lösung besteht darin die mitgelieferte Viewer-Seite aus dem Unterverzeichnis /pdfjs/web zu nutzen und über einen Iframe einzubinden:

<iframe id="pdf-js-viewer" 
        src="/pdfjs/web/viewer.html?file=/fileadmin/user_upload/netthelp.pdf" 
        title="webviewer" 
        frameborder="0" 
        width="500" 
        height="600">
</iframe>

Leider ist diese Lösung so nicht responsiv. Mit Hilfe von https://www.w3schools.com/ habe ich mir folgende Lösung erarbeitet (hier für eine Typo3 Installation):

<div style="position: relative;
            width: 100%;
            overflow: hidden;
            padding-top: 141%;
           ">
  <iframe id="pdf-js-viewer"
          src="/pdfjs/web/viewer.html?file=/fileadmin/user_upload/netthelp.pdf#zoom=auto"
          title="webviewer"
          frameborder="0"
          style="position: absolute;
                 top: 0;
                 left: 0;
                 bottom: 0;
                 right: 0;
                 width: 100%;
                 height: 100%;
                 border: none;
          ">
  </iframe>
</div>

Der Trick besteht darin ein DIV Element zu nutzen, das die ganze verfügbare Breite einnimmt und über padding-top eine darauf basierende Höhe bekommt. Bei den DIN Ax Dokumenten ist das Höhen-Breiten-Verhältnis 1,41:1 bei Portrait und 1:1,41=0,71:1 bei Landscape.

In dieses Element hinein wird dann der IFrame geladen und bekommt den vollständigen Platz zur Verfügung gestellt.

Mittels #zoom=auto wird erreicht, dass sich auch der PDF-Viewer an den zur Verfügung stehenden Platz anpasst. Hinter zoom=… könnten folgende Angaben stehen:

  •  200 (oder eine beliebige Prozentzahl)
  • page-width
  • page-height
  • page-fit
  • auto

Außer zoom gibt es noch den Parameter page=, damit kann angegeben werden, mit welcher Seite des PDFs die Darstellung startet. Weitere Möglichkeiten finden sich auf der Seite https://github.com/mozilla/pdf.js/wiki/Viewer-options.

Weitere Informationen:

Für den Austausch von Medien nutzt Talk das Protokoll WebRTC (Web Real-Time Communication), einen offenen Standard zur direkten Kommunikation zwischen Rechnern. Die aktuellen Browser unterstützen dieses Protokoll, sodass damit Videokonferenzen problemlos möglich sind, zumindest innerhalb eines lokalen Netzes.

Sind die beteiligten Rechner in verschiedenen Netzen, so taucht ein Problem auf. Die Browser müssen ihre eigene IP-Adresse und die IP-Adresse der Gegenstelle wissen. Dies ist leider oft nicht der Fall, wenn sie hinter einem NAT-Router sitzen, z.B. einer Fritzbox. Hier kennen die Geräte nur ihre netzinterne IP-Adresse, z.B. 192.168.1.52, aber nicht die offizielle IP-Adresse, die nur der Router kennt.

Dieses Problem lässt sich mit einem STUN-Server (Session Traversal Utilities for NAT) lösen. Bei dem STUN-Server melden sich die beteiligten Rechner, dabei lernt er ihre öffentlichen IP-Adressen kennen und kann sie an die Gesprächspartner weitergeben. Mit diesen Informationen können die Geräte dann direkt miteinander kommunizieren.

Der Betrieb eines STUN-Servers ist relativ problemlos, da nur sehr geringe Datenmengen anfallen. Es gibt daher auch öffentliche STUN-Server, z.B. bei Nextcloud stun.nextcloud.com:443 (Voreinstellung in Talk).

Leider langt der STUN-Server heutzutage nicht mehr. Ein Router, wie die Fritz!Box, macht nämlich nicht nur NAT, sondern stellt auch eine Firewall zur Verfügung. Verbindungen von außen, aus dem Internet, auf die Rechner innerhalb des lokalen Netzes sind so nicht möglich, ohne auf dem Router Ports freizugeben und auf den Zielrechner weiterzuleiten. Das wäre eine recht aufwändige Vorgehensweise. Es sind nur Verbindungen aus dem Inneren des jeweiligen Netzes zu öffentlich zugänglichen Rechnern möglich.

Hier kommt der TURN-Server ins Spiel (Traversal Using Relays around NAT), er ermöglicht es den Clients Daten ohne eine direkte Verbindung auszutauschen (Relay Server). Sämtlicher Datenverkehr läuft dann durch diesen Server.

Öffentliche TURN-Server wird man in der Regel nicht finden, da rechte hohe Datenvolumina anfallen. Für eine ordentliche Videoqualität werden 500 kbit/s angegeben. Bei 3600 Sekunden in einer Stunde macht das dann 500×3.600 = 1.800.000 kbit etwa 1.800 mbit, also schon ein erhebliches Datenvolumen.

 

Meine Ausgabe von dmesg war unbrauchbar geworden, da hier nur noch Zeilen der Art:

 [38929.065531] [UFW BLOCK] IN=enp1s0 OUT= MAC=01:00:5e:00:00:01:00:24:c0:ff:ee:38:08:00 SRC=192.168.1.14 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0x00 TTL=1 ID=0 DF PROTO=2

zu finden waren.

Das sind abgelehnte Multicast-Pakete von meinem SAT>IP Receiver. An der Konsole habe ich eingegeben:

sudo ufw allow in proto udp to 224.0.0.0/4
sudo ufw allow in proto udp from 224.0.0.0/4

und dann die Datei /etc/ufw/before.rules  am Ende, vor der COMMIT-Zeile,  etwas ergänzt:

# allow IGMP
-A ufw-before-input -p igmp -d 224.0.0.0/4 -j ACCEPT
-A ufw-before-output -p igmp -d 224.0.0.0/4 -j ACCEPT

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

Seit dem Neustart von UFW bleiben die Meldungen aus.

 

Schulen arbeiten meist mit Proxy-Servern. Einerseits um die Internetverbindung etwas schonen zu können, aber auch um die Internetzugriffe zu filtern.

In der Regel will man dafür aber nicht jeden Browser per Hand konfigurieren müssen. Daher gibt es Mechanismen, um die Konfigurationseinstellungen automatisch vornehmen zu können.

Dazu dient in der Regel eine Datei mit dem Namen wpad.dat (einige proprietäte Systeme erwarten den Namen proxy.pac).

Die Datei hat bei unserem IServ folgenden Inhalt:

function FindProxyForURL(url, host)
 {
  if (
   isPlainHostName(host)
   || dnsDomainIs(host, "local")
   || dnsDomainIs(host, "localhost")
   || dnsDomainIs(host, "schule-rlw.de")
   || isInNet(host, "127.0.0.1", "255.0.0.0")
   || isInNet(host, "10.0.0.0", "255.0.0.0")
  ) {
    return "DIRECT";
  } else {
   return "PROXY 172.27.16.2:3128"
  }
 }

Diese Datei kann man dem Client auf folgende Arten zukommen lassen:

1. Per DHCP

In der Konfigurationsdatei DES DHCP-Servers müssen sich die folgenden Zeilen finden:

option proxy-config code 252 = text;
option proxy-config "http://schule-rlw.de/wpad.dat";

Bei TFK-Boxen ist das im Schulrouter Plus unter Dienste -> DHCP-Server zu finden, dort erfolgt der Eintrag in das große Textfenster.

Der Bezeichner, hier proxy-config, ist frei wählbar, muss nur in beiden Zeilen gleich sein. Wesentlich ist die Code-Nummer.

2. Per DNS

Viele Systeme sind in der Lage Autokonfiguration aktiv zu suchen. Dazu rufen sie die URL http://wpad/wpad.dat auf. Es muss also nur ein entsprecchender Eintrag im Nameserver vorhanden sein und die wpad.dat im Wurzelverzeichnis des Webservers liegen. Als Port kommt übrigens nur 80 in Frage, ein Zugriff per https ist nicht konfigurierbar.

 

3. mozilla.cfg

Hat man Zugriff auf eine zentrale Konfigurationsdatei für den Mozilla firefox, so kann man hier die folgenden zeilen eintragen:

pref("network.proxy.autoconfig_url", "http://schule-rlw.de/wpad.dat");
pref("network.proxy.type",2);

Damit wird die automatische Konfiguration aktiviert und gleichzeitig auch der Pfad zur Konfigurationsdatei angegeben.

Meine Schülerfirma Netthelp betreut eine Reihe von Kunden, die ihre Domains bei Domainfactory liegen haben. Wenn bei Netthelp ein Serverwechsel ansteht, dann taucht immer wieder das Problem auf, dass wir die Zugangsdaten der Kunden brauchen. Der letzte Zugriff auf die Domainverwaltung ist dann zum Teil schon mehrere Jahre her und die Zugangsdaten sind nirgends mehr im Zugriff. Dieses Problem trat bei den aktuellen Umstellungen massiv auf, da DF die Regeln für gültige Passwörter geändert hat und ungültige Passwörter dann deaktiviert hatte.

Unser erster Ansatz dieses Problem zu Lösen war eine Cluster-IP bei Strato. Diese IP ist relativ teuer 9,99€ im Monat und für uns nahezu nutzlos, da sie an einen Server-Vertrag gebunden ist. Wenn wir diesen Server wechseln, dann ändert sich auch die Cluster-IP.

Der einzige Ansatz der uns (Dank an Lukas Thiel) jetzt noch einfällt ist eine Domain-Weiterleitung auf eine Netthelp-Subdomain. Dabei muss man ein kleines bisschen tricksen, weil der Grund-Eintrag für linux-diskless.de keine cname sein darf, sondern ein A-Record erwartet wird. Der Trick besteht darin den Eintrag auf Domainfactory zu belassen und dann dort eine Header-Weiterleitung auf www.linux-diskless.de einzurichten. Der Eintrag für „www“ und sogar der für „*“ darf dann ein cname sein.

Für den MX-Eintrag wird ebenfalls linux-diskless.netthelp.de genutzt und keine Subdomain der jeweiligen Domain. Ein MX-Record muss in erster Instanz auf einen A-Record und darf nicht auf einen cname-Record verweisen.

Der einzige Schönheitsfehler besteht in der zwingenden Weiterleitung auf www.

Als Beispiel soll hier die Domain linux-diskless.de dienen:

  1. Ich lege einen A-Record linux-diskless.netthelp.de an, der auf die gewünschte Server-IP zeigt
  2. Nun gehe Ich zur Domain-Verwaltung von linux-diskless.de und lege unter Domain-Einstellungen eine Weiterleitung auf www.linux-diskless.de an (http:// oder wenn konfiguriert besser https://.
  3. Dann folgen die Verweise auf die Netthelp-Subdomain:

Für zukünftige Serverwechsel müssen wir jetzt nur noch den Eintrag für die Netthelp-Subdomain ändern Ein Zugriff auf den DF-Account des Kunden ist nicht mehr notwendig.

Weitere Informationen unter:

Bei einem Serverwechsel taucht immer wieder das Problem auf, dass man auch vorhandene Mailman-Listen umziehen möchte. Der Vorgang ist eigentlich ganz einfach. Die Beschreibung geht davon aus, dass Mailman auf dem Zielrechner bereits eingerichtet und funktionsfähig ist.

Im ersten Schritt müssen die Listen-Verzeichnisse aus den Ordnern

/var/lib/mailman/archives/private/
/var/lib/mailman/lists/

kopieren. Für jede Liste gibt es in den Ordnern ein gleichnamiges Verzeichnis und in dem Archivordner noch jeweils eines mit der Extension .mbox. Diese Verzeichnisse werden einfach auf den neuen Server kopiert und dem richtigen Eigentümer übereignet. Unter Ubuntu gehören die Dateien in der Regel lists.list und die übergeordneten Verzeichnisse root.list.

Die Eigentümer müssen jeweils noch richtig gesetzt werden.

Dann geht es noch an zwei Dateien im Verzeichnis data:

aliases
virtal-mailman

Hier finden sich für jede Liste mehrere Zeilen mit den Weiterleitungen. Die benötigten Zeilen holt man sich vom alten Server und hängt sie an die Dateien auf dem neuen Server an. Am Ende müssen die entstandenen Dateien noch in das benutzte Datenbank-Format umgewandelt werden:

/usr/lib/mailman/bin/genaliases

oder man wartet bis mailman das selber macht.

Danach kann man dann vorsichtshalber mailman neu starten.

Falls es Probleme mit der URL für die Liste gibt, so ist wichtig zu wissen, dass die Listenkonfiguration in der Datei:

/var/lib/mailman/lists/<listenname>/config.pck

steckt. Diese Datei kann man z.B. mittels

withlist -l -r fix_url <listname> -u mailman.yyy.com

bearbeiten.

 

Weitere Hinweise unter:

Gelegentlich kann es sinnvoll sein die Passworteingabe beim SSH-Login zu vermeiden. Wenn man den SSH-Login z.B. aus einen Script heraus vornehmen will oder wenn andere Nutzer das Passwort auf dem Server ändern können.

In solch einem Fall kann man mit vorab ausgetauschten Schlüsseln arbeiten.

Dazu meldet man sich einmal normal per SSH- mit Passwort an:

ssh benutzer@server

Das kann auch schon lang vorher einmal geschehen sein. Dann erzeugt man sich sein Schlüsselpaar:

 ssh-keygen -t rsa

Auf eine Passphrase kann man verzichten, wenn man den Zugang für ein Script benötigt.

Es werden hiermit zwei Schlüsseldateien im Ordner .ssh erzeugt:

  • id_rsa
    das ist der private Schlüssel den man nicht weitergegeben darf
  • id_rsa.pub
    das ist der öffentliche Schlüssel, den wir auf den Zielrechner übertragen

An einfachsten kann man mit folgendem Befehl den Schlüssel in einem Rutsch übertragen:

 cat .ssh/id_rsa.pub | ssh benutzer@server 'cat >> .ssh/authorized_keys'
Veröffentlicht unter linux.

Auf meinem Server war die letzte Aktualisierung auf Version 8.1.x schon vor längerer Zeit. Mir war nicht klar, wie weit ich mit den Aktualisierungen kommen würde. Die Version 10.0.x läuft anscheinend nur noch mit PHP7.x.

Die Aktualisierung bis auf 9.1.5 habe ich mit folgenden Etappen vorgenommen:

  • Version 8.2.11
  • Version 9.0.9
  • Version 9.1.5

Bezogen habe ich die Archive von https://owncloud.org/changelog/ .

Der erste Schritt war relativ problemlos.

cd mein-onwncloud-verzeichnis
mv httpdocs httpdocs.81
tar xvfj owncloud-8.2.11.tar.bz2
cp -a httpdocs.81/config owncloud
mv owncloud httpdocs
chown -R wwwrun.www httpdocs
cd httpdocs
sudo -u wwwrun php occ upgrade

Das Update deaktiviert immer die Apps für Kalender und Kontakte.

Die weiteren Schritte erfolgen analog, aber ab 9.0 muss man wirklich aufpassen, das man nicht alte Daten im httpdocs-Verzeichnis liegen hat. Vorher hatte ich immer einfach die neuen Dateien in das Verzeichnis hinein kopiert, das lief dann aber nicht mehr. Der oben beschrieben Weg klappt aber weiterhin.

Ich musste auf meinem alten SuSE-System den erlaubten Speicher erhöhen in der

/etc/php5/cli/php.ini

Dann musste ich für MySQL die Blockgröße erhöhen in der /etc/my.cnf

max_allowed_packet=256M

Vorher brach das Upgrade-Tool von 9.0.9 immer wieder ab. Zusätzlich wurde über unzulässige Dateien gemeckert.

Es stellte sich heraus, dass vier Dateien gelöscht werden mussten, es war aber mein Ordner für die Owncloud-Dateien fast vollständig geleert worden. Das habe ich erst einmal ignoriert.

Das Upgrade auf 9.1.5 lief dann problemlos.

Zum Glück hatte ich das komplette Datenverzeichnis datadirectory gesichert, das Update hatte es mir gelöscht. Ich habe dann diese Dateien einfach wieder an ihren Platz kopiert und im Owncloud Web-Frontend neu prüfen lassen, danach war alles ok.

Was mir noch auffällt ist die Tatsache, dass Owncloud meldet, es hätte keine Internetverbindung. Auch zusätzliche Apps kann ich aus der Oberfläche heraus nicht installieren, auch Updates werden nicht angeboten.

Ich habe gelesen, dass das an einer defekten Curl-Version liegt. Naja, ich muss den kompletten Server sowieso mal aktualisieren.

Was mich etwas wundert ist die Tatsache, dass sich anscheinend die Kalender-Links etwas geändert haben, von caldav zu dav im Pfad. Meine Synchronisation klappt aber trotzdem, also werde ich das erst einmal nicht weiter verfolgen.