Aus alter Gewohnheit läuft man Arbeitsplatzrechner noch mit einem 32-Bit Ubuntu. Das möchte ich ändern und habe testweise ein 64-Bit Ubuntu 16.04 installiert.

Nun habe ich eine Anwendung, für die ich kein aktuelle Download-Verzeichnis kenne und für die ich keine 64-Bit Version bekommen kann. Diese Anwendung ist der PDF-Editor Cabaret Stage.

Im Prinzip lässt sich auch ein 32-Bit Java auf einem 64-Bit Linux installieren. Dazu holt man sich bei Oracle einfach die entsprechende Version, z.B. jre-8u102-linux-i586.tar.gz . Dieses Archiv kann man dann z.B. im Verzeichnis /opt entpacken. Ich habe das entstandene Verzeichnis dann etwas umbenannt, so dass mein Java unter /opt/jre32 erreichbar ist.

Im Startprogramm cabaretstage.sh habe ich dann die Zeile mit dem eigentlichen Programmaufruf erweitert zu:

/opt/jre32/bin/java -classpath "$MY_CLASSPATH" -Xms64m -Xmx256m com.cabaret.claptz.stage.main.StandardStage $*

Dadurch wird das systemweit installierte Java überhaupt nicht gestört.

Leider gibt es nun das Problem, dass im Zusammenhang mit dem Java AWT eine Reihe von 32-Bit Bibliotheken benötigt wird. Zum Glück kann man die auch auf einem 64-Bit System zusätzlich installieren.

sudo apt install libgtk2.0-0:i386 libxtst6:i386 libfreetype6:i386 libxrandr2:i386 libglib2.0-0:i386 libpulse0:i386 libgdk-pixbuf2.0-0:i386
sudo apt install libnspr4:i386 gtk2-engines-murrine:i386 libgail-common:i386 gnome-session-canberra:i386
sudo apt install libfreetype6:i386 unity-gtk3-module:i386 unity-gtk2-module:i386 atk-bridge2.0-0:i386 libcurl3:i386

Es werden dann noch einige Pakete aufgrund von Abhängigkeiten installiert.

dpkg-query -l *:i386

liefert bei mir als Ergebnis insgesamt 169 Pakete.

Dann noch

cd /usr/lib/i386-linux-gnuln -s libfreetype.so.6 libfreetype.so
Veröffentlicht unter linux.

Selbst in meiner Familie gibt es immer noch Menschen, die mit Windows-Systemen arbeiten. Unter Linux ist vieles einfacher, vor allem eine automatische Sicherung auf ein NAS wie das ReadyNAS. Ich habe dazu auf meinem NAS den rsync-Dienst laufen und kann dann mit einer Zeile wie:

rsync -azv --delete /home/debacher rsync://debacher@192.168.1.118:/Sicherungen/

meine Dateien regelmäßig per cron job sichern: http://www.debacher.de/wiki/Netgear_ReadyNAS_RN102 .

Etwas ähnliches wollte ich auch unter Windows 10 realisieren (natürlich in einer VirtualBox).

Sichern mit XCOPY

Im Prinzip geht das auch mit Windows-Bordmitteln. Dazu müsste man die Freigabe auf dem NAS als Laufwerk mounten und kann dann die Daten mit XCOPY sichern. Die folgende Beschreibung habe ich von Karsten Schultz übernommen:

xcopy /E /M C:\Benutzer\debacher\*.* Y:\Sicherungen\

C: ist das Quelllaufwerk
Y: ist die als Netzlaufwertk eingebunde Freigabe

Funktiom der Schalter
/E : Kopiert alle Unterverzeichnisse (leer oder nicht leer).
/M : Kopiert nur Dateien mit gesetztem Archivattribut,
     setzt das Attribut nach dem Kopieren zurück.

Das hat aber zwei Nachteile:
1. xcopy muss bei den Quell-Dateien nach dem sichern das Archiv-Bit setzen
   (das funktioniert automatisch mit dem Schalter /M).
2. das Verfahren funktioniert nur im lokalen Netz, da das Samba-Protokoll nicht geroutet wird.

Anmerkung: Bei Bedarf kann bei den Quelldateien das Archivbit mit attrib.exe gesetzt oder 
zurückgesetzt werden.

Das hat aber zwei Nachteile:

  1. xcopy muss bei den Dateien auf dem Rechner das Archiv-Bit setzen nach dem Sichern
  2. das Verfahren funktioniert nur im lokalen Netz, da das Samba-Protokoll nicht geroutet wird

Sichern mit RSYNC

Zum Glück gibt es über das Cygwin-Projekt rsync auch für Windows. Dazu habe ich die Seite http://www.it-em.net/rsync-fuer-windows/ gefunden. Hier ist ein Zip-Archiv mit rsync unter cygwin zu finden: http://www.it-em.net/wp-content/uploads/rsync.zip. Dieses Paket habe ich auf Laufwerk c: entpackt und kann dann aus dem Verzeichnis heraus synchronisieren mittels:

rsync.exe -azv --delete /cygdrive/C/Users/debacher  rsync://debacher@192.168.1.118:/Sicherungen/

Damit würde der Ordner, der in der grafischen Oberfläche unter c:\Benutzer\debacher zu finden ist gesichert. Man muss bei den von Windows selbst angelegten Ordnern immer etwas aufpassen, die heißen oft anders, als die grafische Oberfläche vorgaukelt. Der Ordner Bilder im Benutzerverzeichnis heißt z.B. in Wirklichkeit Pictures.

Shares-EinstellungenWill man den Zugriff auch von außerhalb des lokalen Netzes ermöglichen, so ist es wichtig einen Benutzer und ein Passwort anzugeben. Dazu muss man für die Freigabe unter Shares->Einstellungen den Lese/Schreib Zugriff erlauben und den Passwort-Schutz aktivieren. Wenn man dies per Apply bestätigt hat, dann kann man hier über das +-Zeichen Benutzer und Passwort für den Rsync-Zugriff festlegen. Die Benutzer haben nichts mit den Samba-Benutzern zu tun, selbst wenn die Benutzernamen identisch sind.

Nun leg man sich im Ordner mit rsync.exe noch eine Datei mit z.B. dem Namen pfile an, die das eben angegebene Passwort enthält. Danach kann man dann mittels

rsync.exe -azv --delete --password-file=pfile /cygdrive/C/Users/debacher  rsync://debacher@192.168.1.118:/Sicherungen/

gesichert auf den Rsync-Server zugreifen. Danach kann man das das Script backup.cmd aus dem Archiv anpassen:

@ECHO OFF
ECHO ***
ECHO *** Backupscript per rsync ***
ECHO *** Stand: 04.09.2015 ***
ECHO *** Fa. ITEM, Ing. Edenhauser ***
ECHO *** office@it-em.net ***
ECHO *** www.it-em.net ***
ECHO *
ECHO *** simples Beispiel... ***
ECHO *** angepasst von U.D. am 18.06.2016 ***
cd C:\scripte\rsync\          ***<Verzeichnis mit rsync> 
rsync.exe -azv --delete --password-file=pfile /cygdrive/C/Users/debacher  rsync://debacher@192.168.1.118:/Sicherungen/

Der Verzeichniswechsel hat den Vorteil, dass man sich keine Gedanken darüber machen muss, wie man den Pfad zur Passwortdatei angeben kann.

Automatisieren der Sicherung

Den folgenden Hinweis habe ich wieder von Karsten Schultz übernommen:

Ein backup beim Herunterfahren lässt sich nicht mit der Aufgabenplanung realisieren. Den Trigger „Beim Herunterfahren“ gibt es nicht.

Man kann die Aufgabe aber einfach mit einer Gruppenrichtlinie erledigen. Dazu:

 1. gpedit.msc starten
 2. Computerkonfiguration → Windows-Einstellungen → Skripts → Herunterfahren öffnen
 3. Skripts zum Herunterfahren für lokalen Computer hinzufügen  z.B. C:\scripte\rsync\backup.cmd
 4. Übernehmen

Jetzt muss ich noch folgende Dinge ausprobieren:

  1. Weiterleiten von Port 873 (rsync) über die FritzBox
  2. Automatisches Starten von rsync über Computer->Verwalten->Aufgabenplanung

Bei vielen Typo3-Seiten gibt es Einträge der Art

config.baseURL= http://<domain>/

im root-Template. Will man dem Benutzer die Wahl lassen zwischen http und https ist das ein Problem, weil dann bei einer sicheren Verbindung Inhalte unsicher nachgeladen werden. Firefox blockt diese Inhalte. Da das  dann oft CSS-Dateien oder ähnliches sind wird die Seite ziemlich verunstaltet.

Eine Lösung besteht darin das benutzte Protokoll zu erfragen. Dazu gibt man im Template unter Konstanten folgenden Code ein:

protocol = http
[globalString = IENV:TYPO3_SSL=1]
  protocol = https
[global]

Nun kann man im Setup darauf Bezug nehmen:

# Das Protokoll wird unter Constants ermittelt
config.baseURL= {$protocol}://<domain>/

Nun klappt das auch mit der sicheren Verbindung.

Veröffentlicht unter typo3.

Mit letsencrypt soll es für alle Webseiten einfach und erschwinglich werden eine Verschlüsselung zu ermöglichen.

Eine schöne Beschreibung findet sich unter https://lukasthiel.de/wiki/SSL-Zertifikate_mit_Let%27s_Encrypt

Installation

Die Installation erfolgt mittels:

cd /root
git clone https://github.com/letsencrypt/letsencrypt

Das Script lädt notwendige Pakete und Aktualisierungen beim ersten Aufruf nach, hier z.B. über den Aufruf der Hilfefunktion:

/root/letsencrypt/letsencrypt-auto -h

Dabei werden einige Pakete über die Paketverwaltung der Distribution ergänzt und zusätzlich einiger Python-Code nach /root/.local/share/letsencrypt/ gebracht.

Bootstrapping dependencies for openSUSE-based OSes...

The following 8 NEW packages are going to be installed:
  dialog libdialog11 libffi48-devel python-devel python-pip python-setuptools 
  python-virtualenv python-xml 

The following package is suggested, but will not be installed:
  terminfo 

8 neue Pakete zu installieren.
Gesamtgröße des Downloads: 5,8 MiB. Nach der Operation werden zusätzlich 26,8 
MiB belegt.
Fortfahren? [j/n/? zeigt alle Optionen] (j): j
Creating virtual environment...
Installing Python packages...
...

Am Ende wird der Hilfe-Text ausgegeben.

Das Tool legt an einer Reihe von Stellen Dateien ab:

  • /etc/letsencrypt/  hier liegen die Zertifikate und die zugehörigen Einstellungen
  • /root/.local/share/letsencrypt/ in diesem Verzeichnis liegen die benötigten Python Scripte
  • /var/log/letsencrypt hier liegt die Logdatei und die zugehörigen Archive
  • /var/lib/letsencrypt für Backups
  • /root/letsencrypt vom Benutzer festgelegtes Verzeichnis für das Programmpaket, denkbar z.B. auch /opt/letsencrypt

Zertifikats-Erzeugung im Dialog

Der Aufruf von

/root/letsencrypt/letsencrypt-auto --rsa-key-size 4096 certonly

erzeugt dann im Prinzip das Zertifikat. Bei mit (OpenSUSE) wollte das nicht funktionieren, weil das Tool das Verzeichnis /etc/apache2/sites-enabled vermisste. Nachdem ich das Verzeichnis angelegt hatte (das Verzeichnis selber kann leer bleiben) ließ sich das Zertifikat erzeugen.

Es startet ein fensterbasiertes Tool an der Konsole. Im ersten Schritt gibt man an, wie sich der Webserver gegenüber dem Zertifikats-Aussteller authentifizieren soll. Die einfachste Version besteht darin das Script eine Datei im Webroot der Seite plazieren zu lassen. Dazu muss das Script die Pfade kennen:

letsencrypt-1

letsencrypt-2

letsencrypt-3

letsencrypt-4

Wenn die Datei über den Webserver erreichbar war, dann kommt die Erfolgsmeldung:

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/elearn-server.de/fullchain.pem. Your cert will
   expire on 2016-09-14. To obtain a new or tweaked version of this
   certificate in the future, simply run letsencrypt-auto again. To
   non-interactively renew *all* of your certificates, run
   "letsencrypt-auto renew"
 - If you lose your account credentials, you can recover through
   e-mails sent to <admin>@<domain>.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Zertifikats-Erzeugung mit Parametern

Man kann sich den Ablauf auch etwas einfacher machen, vor allem, wenn man mehrere Domains betreut, indem man statt der Dialog orientierten Variante eine Parameter orientierte Variante benutzt (alles in einer Zeile):

/root/letsencrypt/letsencrypt-auto --rsa-key-size 4096 certonly --webroot -w /srv/www/vhosts/elearn-server.de/httpdocs/ -d elearn-server.de -d www.elearn-server.de

Für umfangreiche Nutzung kann es noch geschickter sein sich für jede Domain eine Konfigurationsdatei, z.B. letsencrypt.ini, anzulegen

# Wir nutzen 4096 bit RSA key statt 2048
rsa-key-size = 4096

# allgemeine Angaben
email = <admin>@<domain>
authenticator = webroot

# Domains fuer die wir Zertifikate beantragen, die erste in
# der liste legt den Hauptnamen fest. Alle Domains müssen beim
# Aufruf erreichbar sein
domains = elearn-server.de, www.elearn-server.de

# Dies ist das Verzeichnis zur Domain, wo letsencrypt seinen Hash in
# /.well-known/acme-challenge schreiben will. Der Pfad muss auf / enden
webroot-path = /srv/www/vhosts/elearn-server.de/httpdocs/

Aufgerufen wird letsencrypt-auto dann mittels (alles in einer Zeile):

/root/letsencrypt/letsencrypt-auto certonly --config /srv/www/vhosts/elearn-server.de/letsencrypt.ini

Aufpassen muss man aber unbedingt mit Subdomains. Letsencrypt lässt nämlich nur etwa 5 Aufrufe pro Domain und Woche zu. In dem Beispiel sind dann schon zwei Aufrufe verbraucht. Mehr als 5 Subdomains im gleichen Zertifikat sind wohl nicht möglich.

Im Laufe der Erzeugung legt letsencrypt in der Wurzel des angegebenen Servers ein Verzeichnis .well-known an. Das Zertifikat selber wird unter /etc/letsencrypt/live/<domain>/ abgelegt und besteht aus den vier Dateien

  • cert.pem
  • chain.pem
  • fullchain.pem
  • privkey.pem

dies sind Links auf die Dateien

  • /etc/letsencrypt/archive/<domain>/cert1.pem
  • /etc/letsencrypt/archive/<domain>/chain1.pem
  • /etc/letsencrypt/archive/<domain>/fullchain1.pem
  • /etc/letsencrypt/archive/<domain>/privkey1.pem

Diese Verlinkung soll vermutlich die Aktualisierung der Zertifikate vereinfachen.

Apache konfigurieren

Jetzt muss nur noch der Apache-Webserver von den neuen Möglichkeiten wissen. Die notwendigen Einstellungen für den Host sind in der Datei /etc/letsencrypt/options-ssl-apache.conf zu finden:

# Baseline setting to Include for SSL sites

SSLEngine on

# Intermediate configuration, tweak to your needs
SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder     on
SSLCompression          off

SSLOptions +StrictRequire

# Add vhost name to log entries:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" vhost_combined
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common

#CustomLog /var/log/apache2/access.log vhost_combined
#LogLevel warn
#ErrorLog /var/log/apache2/error.log

# Always ensure Cookies have "Secure" set (JAH 2012/1)
#Header edit Set-Cookie (?i)^(.*)(;\s*secure)??((\s*;)?(.*)) "$1; Secure$3$4"

Testen kann man das Zertifikat dann unter https://www.ssllabs.com/ssltest/

Weitere Informationen

Möchte man sein Zertifikat um weitere Subdomains erweitern, so ist das kein Problem. Hat man z.b. nur für <domain> und www.<domain> ein Zertifikat erstellt und möchte jetzt auch blog.<domain> mit aufnehmen, so erweitert man einfach die Liste der Domains entsprechend und löst die Erstellung des Zertifikats erneut aus. Es erscheint jetzt ein Dialog, der nachfragt, ob man das Zertifikat erweitern möchte. Hier klickt man auf Expand und wenn die Subdomain erreichbar ist, dann wir das Zertifikat neu erzeugt.
Laut https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769 gilt hierfür nicht das Limit von 5 pro Woche.

Unter /etc/letsencrypt/csr/ findet man die Key-signing-requests, ein Hinweis darauf, dass das Schlüsselpaar auf dem eigenen Server erzeugt wurde und der private Schlüssel auch letsencrypt nicht bekannt ist.

Bei owncloud gibt es einen Abschnitt in der .htacess, der die Überprüfung durch letsencrypt verhindert:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
RewriteRule ^\.well-known/carddav /remote.php/carddav/ [R=301,L]
RewriteRule ^\.well-known/caldav /remote.php/caldav/ [R=301,L] 
RewriteRule ^apps/calendar/caldav\.php remote.php/caldav/ [QSA,L]
RewriteRule ^apps/contacts/carddav\.php remote.php/carddav/ [QSA,L]
RewriteRule ^remote/(.*) remote.php [QSA,L]
RewriteRule ^(build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
RewriteRule ^(\.|autotest|occ|issue|indie|db_|console).* - [R=404,L] 
</IfModule>

Das Einfügen der Zeile

RewriteRule ^\.well-known/acme-challenge - [L]

löst das Problem. Mal sehen,  ob es Seiteneffekte gibt.

 

Löschen von Schlüsseln

Mit

/root/letsencrypt/certbot-auto certificates

kann man abfragen, wie die Zertifikate auf dem Server genau heißen und die zugehörigen Dateien dann mittels

/root/letsencrypt/certbot-auto delete --cert-name <gefundener Name>

vom eigenen Server entfernen.

Mit folgendem Kommando kann man abfragen, welche Domains im Zertifikat eingetragen sind:

openssl x509 -in /etc/letsencrypt/live/<domain-bezeichnung>/cert.pem -text -noout | grep DNS

Mit den Schritten ist das Zertifikat selber aber nicht gelöscht, das wäre dann erst nach einigen Tagen automatisch der Fall. Noch nicht getestet habe ich die Schritte:

certbot revoke --cert-path /PATH/TO/cert.pem --key-path /PATH/TO/key.pem

das müsste natürlich vor dem Löschen der lokalen Dateien erfolgen.

 

Links

Einige Provider haben Sender Policy Framework (SPF) aktiviert. Damit kann der empfangende Server erreichen, dass er nur noch Mails von Servern annimmt, die im SPF-Record der absendenden Domain eingetragen sind. Das sollte theoretisch SPAM verhindern. Mehr Informationen zu dem Problem unter https://www.heinlein-support.de/blog/news/gmx-de-und-web-de-haben-mail-rejects-durch-spf/ .

Leider verhindert das auch alle Weiterleitungen von Mails der absendenden Domain. Eine Lösung für dieses Problem ist ein Umschreiben der Absenderadresse bei der Weiterleitung mittels Sender Rewrite Schema (SRS). Da Postfix dafür von Haus aus keine Komponenten mitbringt braucht man zusätzliche Software.

Im Web finden sich mehrere Projekte für diesen Zweck, die in der Regel mit einem zusätzlichen Dämon arbeiten:

Ich habe mich für postsrsd entschieden und bin der Anleitung unter https://seasonofcode.com/posts/setting-up-dkim-and-srs-in-postfix.html gefolgt.

zipper -i cmake
cd /tmp
wget https://github.com/roehling/postsrsd/archive/master.zipunzip -e master.zip
cd postsrsd-master
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr ../
make
sudo make install

Der letzte Befehlt hat dann folgende Aktionen ausgelöst:

[100%] Built target postsrsd
Install the project...
-- Install configuration: ""
-- Installing: /usr/sbin/postsrsd
-- Installing: /usr/share/doc/postsrsd/README.md
-- Installing: /usr/share/doc/postsrsd/README_UPGRADE.md
-- Installing: /usr/share/doc/postsrsd/main.cf.ex
-- Chroot jail: /usr/lib/postsrsd
-- Installing: /etc/default/postsrsd
-- Installing: /etc/systemd/system/postsrsd.service
-- Generating secret key
-- Installing: /etc/postsrsd.secret

Danach waren die notwendigen Dateien vorhanden. Ein

service postsrsd status

liefert aber die Fehlermeldung:

systemd[1]: [/etc/systemd/system/postsrsd.service:13] Unknown lvalue 'RuntimeDirectory' in section 'Service'

Anscheinend gibt es den Wert RuntimeDirectory in der auf dem Server vorliegenden Version von Systemd noch nicht https://www.freedesktop.org/software/systemd/man/systemd.exec.html . Konsequenterweise startet des Dämon auch nicht, ich musste erst das Verzeichnis /run/postsrsd/ per Hand anlegen.

Danach muss man dann noch die Postfix-Konfiguration zu erweitern, dass der neue Dämon auch eingebunden wird:

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes= envelope_recipient,header_recipient

Ich muss das alles einmal in Ruhe testen.

Weitere Anleitungen, die ich testen will:

Ich bin jetzt zweimal auf ein Problem im Zusammenhang mit Typo3 und dem Nivo-Slider gestoßen. In beiden Fällen hat ein Browser die Bilder im Slider bei jedem Durchlauf neu geladen und damit eine gewisse Netzlast erzeugt, natürlich abhängig von der Internetanbindung des zugehörigen Rechners.

In einem ersten Durchlauf habe ich die zugehörige IP mit iptables blockiert und konnte anhand der IP den Verursacher erreichen. Im zweiten Fall ist das aber ein Ntuzer mit dynamischer IP, die sich täglich ändert. Das kann auf Dauer mühsam werden da am Ball zu bleiben, zumal der Verursacher keine weiteren Informationen bekommt.

Daher habe ich jetzt versucht per .htaccess der IP-Adresse eine andere Seite mit Probleminformationen zukommen zu lassen. Dazu habe ich die .htaccess von dem zugehörigen Typo3-System um folgende Zeilen erweitert:

RewriteCond %{REMOTE_ADDR} ^192\.168\.1\.1$  
RewriteCond %{REQUEST_URI} !^\/sorry\.html
RewriteRule $ /sorry.html [R=302,L]

Die IP-Adresse habe ich hier natürlich verändert.

Jeder Aufruf von dem Rechner aus wird also auf die Seite sorry.html umgeleitet, die Hinweise auf das Problem liefert.

Quellen:
http://www.the-art-of-web.com/system/rewrite/
http://www.modrewrite.de/mod-rewrite/beispiele/ip-bereiche-blocken/

Gelegentlich gibt es auch dem IServ-Schulserver mal Probleme mit dem Mailsystem. Da ist es erst einmal wichtig zu wissen, wo die Dateien liegen. IServ benutzt Cyrus Imap als Mailserver. Diese Software wäre sicherlich nicht meine erste Wahl.

Die Mails für einen Benutzer namens richard.linde liegen unterhalb von /var/spool/cyrus/mail/user/richard^linde/ . In dem Ordner gibt es dann für jede Nachricht eine Datei, deren Name aus einer Nummer und einem abschließenden Punkt besteht. Dann gibt es in dem Ordner und seinen Unterordner noch die Dateien:

  • cyrus.cache
  • cyrus.header
  • cyrus.index
  • cyrus.squat

Wenn man diese Dateien löscht, dann funktioniert das Mailsystem nicht mehr richtig. Man kann sie im Bedarfsfall aber neu erzeugen lassen mittels:

 su -c "/usr/lib/cyrus/bin/reconstruct -f -r user/richard^linde" cyrus

Dabei entstehen aber nur die ersten drei Dateien.

Die Bedeutung der Dateien ist in https://cyrusimap.org/docs/cyrus-imapd/2.4.9/internal/mailbox-format.php beschrieben.

 

Für die Weiterleitungen und die Spam-Sortierung wird Sieve benutzt.  Die Dateien für den Benutzer findet man in /var/spool/sieve/r/richard^linde/ . Die Datei system.script hat standardmäßig folgenden Inhalt:

require "include";
require "fileinto";
require "vacation";
# include user script
include "user";
# file spam into the Junk folder
if header :matches "X-Spam-Flag" "YES" {
 fileinto "INBOX/Junk"; stop; }

Bei einer aktivierten Weiterleitung kommen folgende Zeilen hinzu:

# redirection
redirect "richard.line@private-email.de";
keep;

Änderungen an dieser Datei haben aber nur dann einen Effekt, wenn sie anschließend in die binäre Darstellung system.bc übertragen werden.

Für Änderungen habe ich unter https://lists.andrew.cmu.edu/pipermail/info-cyrus/2006-March/021151.html gefunden:

- ermittle das Verzeichnis für die Sieve-Scripte: /var/spool/sieve/<1.Buchstabe>/<Benutzername>
- mkdir -p wenn das Verzeichnis nicht existiert
- Kopiere das Benutzerscript in dieses Verzeichnis (eg: user.script)
- sievec user.script user.bc
- ln -s user.bc defaultbc
- (wenn root) setze die Eigentumsverhältnisse auf cyrus.mail

 

Veröffentlicht unter IServ.

Sollen normale Nutzer die Möglichkeit haben den Seitencache zu löschen, so muss man im Benutzer TSConfig die folgende Einstellung vornehmen:

 ### Loescht den FE-Cache ###
 options.clearCache.pages = 1

Auch für Admin-Benutzer kann es nützlich sein alle Caches löschen zu können:

 ### Loescht FE-Cache und Cache in typo3conf ###
 options.clearCache.all = 1
Veröffentlicht unter typo3.

Das Modul Liste im Backend von Typo3 sieht eine Suche vor. Das Suchformular taucht recht oben auf und unter den einzelnen Inhalts-Angaben. Leider funktioniert die Suche nicht im Zusammenhang mit Erweiterungen wie tt_news und anderen.

Bei diesen Extensions muss man die Datei tca.php (im Ordner der jeweiligen Extension) anpassen. Für tt_news ist folgende Zeile sinnvoll:

$TCA['tt_news']['ctrl']['searchFields'] = 'title,keywords,bodytext,abstract';

Die Zeile wird direkt vor dem passenden Array platziert (Zeile 22):

$TCA['tt_news'] = Array (
        'ctrl' => $TCA['tt_news']['ctrl'], 
        'interface' => Array (
        ....

Danach wird auch in den angegebenen Felder gesucht.
Ähnlich bei anderen Extensions:

$TCA['tx_kesmallads_smallads']['ctrl']['searchFields'] = 'title,content,email';
$TCA["tx_kesmallads_smallads"] = Array (
        "ctrl" => $TCA["tx_kesmallads_smallads"]["ctrl"],
        "interface" => Array (
        ....

oder

$TCA['user_adressen_adresse']['ctrl']['searchFields'] = 'name,strasse,webdokumente,infos';
$TCA["user_adressen_adresse"] = Array (
        "ctrl" => $TCA["user_adressen_adresse"]["ctrl"],
        "interface" => Array (
        ...

 

 

Veröffentlicht unter typo3.

Im Zusammenhang mit Server-Aktualisierungen tauchte das Problem auf, dass es da noch ein paar alte Joomla-Installationen gab.

 

ab Version 2.5.x

ab dieser Version gibt es einen eingebauten Update-Mechanismus, den man nutzen kann. Er arbeitet aus dem Backend der Installation heraus.

 

Version 1.5

Da habe ich mir lange die Zähne daran ausgebissen, da die ganzen empfohlenen Tools bei mir nicht funktioniert haben. Ausprobiert habe ich jUpgrade und den redMigrator. Die updates blieben immer hängen.

Geklappt hat dann J2xml nach der Anleitung unter http://www.eshiol.it/joomla/j2xml/joomla-15-to-30.html

Auch hier werden nur die Daten exportiert und in einem aktuellen System wieder importiert, aber immerhin das hat geklappt.