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

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.

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/

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.

 

 

Mein ownCloud möchte ich nicht mehr missen. Leider sind die Updates in relativ großen Sprüngen, so dass man immer mit Problemen rechnen muss.  Das heutige Update auf 8.0.2 fand ich recht stressig.

Das Update startet wie immer aus ownCloud heraus. Das erste Problem taucht bei immer immer dann auf, wenn die Datenbank aktualisiert werden soll. Das Online-tool fordert zum Neuladen der Seite auf, das haut aber bei mir nie hin. Als Alternative kann man an der Konsole folgenden Aufruf starten:

sudo -u wwwrun php occ upgrade

Dann lief das Update durch. Danach ging aber gar nichts mehr, nur noch weiße Seiten. Ich hätte vorher irgendwo lesen müssen, dass die Apps calendar und contacts nicht mehr so richtig dazu gehören und hätten deaktiviert werden müssen. Das geht aber auch von der Konsole aus mittels:

sudo -u wwwrun php occ app:disable contacts
sudo -u wwwrun php occ app:disable calendar

Diese beiden Apps gibt es dann in einer neuen Version, überarbeitet für Version 8.0.2. Will man die aktivieren kommt einen Fehlermeldung „Das Verzeichnis existiert schon“. Man muss also erst im Verzeichnis apps die Ordner contacts und calendar löschen, bevor man die neue Version der Apps installieren kann. Entsprechend gilt das übrigens auch für die Apps:

  • documents
  • bookmarks
  • search_lucene

Sehr erfreut hat mich, dass nach der Aktivierung von calendar meine bisherigen Daten alle noch vorhanden waren. Einen Schreck habe ich dann bekommen, als Thunderbird plötzlich alle Termine verloren hatte. Aber nach einem Neustart von Thunderbird hat er sich die Termine neu geholt und soweit ich das beurteilen kann sind alle Termine wieder vorhanden.

Beim Umstellen älterer Typo3-Projekte (noch ohne Templavoila) auf 6.2 tauchte das Problem auf, die unbenutzten Spalten auszublenden.

Das ist eigentlich recht elegant gelöst. Man erstellt mit der Funktion Liste auf der Root-Seite eine neues Element vom Typ Backend-Layout. Rechts neben dem Feld „Konfiguration“ gibt es einen Button „Assistent“ den man nutzen kann. Zusätzlich muss man einen Titel angeben.

Dieses neue Element muss man dann mit der Funktion Seite über die Seiteneigenschaften der Root-Seite unter Erscheinungsbild als Backend-Layout setzen.

Der Eintrag mod.SHARED.colPos_list=0 im TSConfig der Root-Seite würde nur die Bearbeitung sperren, aber nicht den Platz nutzbar machen.

Manchmal muss man eine Extension per Hand entfernen, weil durch ihre einbundung nur noch weiße Seiten erscheinen. Es gibt mehrere Stellen, an denen man eventuell Veränderungen vornehmen muss:

  • typo3conf/PackageStates.php
  • typo3conf/LocalConfiguration.php
  • und notfalls auch typo3temp löschen

Bei der Website http://netzdurchblick.de arbeiten wir mit einem grafischen Menü, bei dem die Buttons für NO, RO und ACT aus dem Ressourcen-Feld der jeweiligen Rubriken Startseite entnommen haben.

temp.hauptmenue = HMENU
temp.hauptmenue {
   special = list
   special.value = 238,197,247,165,1197,901
   1 = GMENU
   1 {
      NO = 1
      NO {
        5 = IMAGE
        5 {
            file.import.field = media
            file.import = uploads/media/
            file.import.listNum = 2
        }
        ATagTitle.field = subtitle 
        XY = [5.w],[5.h]
        transparentBackground = 1
        wrap = |
      }
      RO < .NO
      NO.5.file.import.listNum = 4
      ACT < .NO
      ACT.5.file.import.listNum = 4
   }
}

Bei der neuen Version funktioniert das leider nicht mehr, da eine Abstraktionsebene vor das Dateisystem gelegt wurde. Nach vielen mühsamen Experimenten habe ich folgende Lösung für das gleiche Problem gefunden (mit Hilfe von http://www.typo3.net/forum/thematik/zeige/thema/118444/):

temp.hauptmenue = HMENU
temp.hauptmenue {
  special = list
  special.value = 238,197,247,165,1197,901
     
  1 = GMENU
  1 {
     expAll = 1
     noBlur = 1
     NO = 1
     NO {
       XY = [5.w],[5.h]
       format = png
       quality = 100
       backColor = transparent
       5 = IMAGE
       5 {
         file {
         format = png
         import.cObject = FILES
         import.cObject {
           references {
             table = pages
             uid.field = tsfe:id
             fieldName = media
           }
           maxItems = 1
           begin = 2
           renderObj = IMG_RESOURCE
           renderObj {
             required = 1
             file.import.data = file:current:publicUrl
           }
          }
         }
       }
       ATagTitle.field = subtitle // title
     } # ende NO

     RO < .NO
     NO.5.file.import.cObject.begin = 4

     ACT < .NO
     ACT.5.file.import.cObject.begin = 3
  }
}

Frustrierenderweise funktionierte dann der RO-Effekt trotzdem nicht. Erst der Hinweis unter http://www.typo3.net/forum/thematik/zeige/thema/114717/ hat mich dann darauf gebracht im Haupttemplate noch die folgende Zeile unterzubringen

page.jsInline.10 = TEXT
page.jsInline.10.value (
var version = "n3";
)

Ein paar Hinweise findet man unter:

  • http://wiki.typo3.org/File_Abstraction_Layer#How_can_I_access_the_typolink-field_from_the_meta-data_of_one_file.3F
  • http://wiki.typo3.org/File_Abstraction_Layer#How_to_use_.22levelmedia.22_with_6.x_.3F
  • https://www.merec.org/typo3/verwendung-von-fal-file-abstraction-layer-typo3-6-0-mit-templavoila

Beim Update auf Typo3 6.2 gibt es Probleme mit einigen Extensions, bei mir sind es vor allem die von Georg Ringer, die ich bisher gern benutzt habe. Für viele Extensions gibt es einfach keine Anpassung an die neue Typo3-Version. Ein Hauptbroblem sind wohl die Veränderungen im Zusammenhang mit dem Pfad t3lib, der nicht mehr exisitiert. Daher laufen alle Programme ins Leere, die hier nach Bibliotheken suchen.

Einnen Versuch wert ist es, die entsprechende Require-Zeile einfach auszukommentieren in der jewiligen Datei typo3conf/ext/<extension>/pi1/class.tx_<extension>_pi1.php:

#require_once( PATH_tslib . 'class.tslib_pibase.php' );

Geklappt hat das bei mir mit

  • macina_searchbox
  • rgtabs (weiter Probleme analog zu https://forge.typo3.org/issues/43834 und https://forge.typo3.org/issues/41632, Lösung hier unter #8 )
  • dropdown_sitemap
  • chgallery (eine angepasste Version ist unter https://github.com/derhansen/TYPO3.ext.chgallery und https://github.com/georgringer/TYPO3.ext.chgallery verfügbar)
  • rgmediaimages (zusätzlich in typo3conf/ext/rgmediaimages/class.tx_rgmediaimages_fe.php)
  • rgsmoothgallery (eine angepasste Version ist unter https://forge.typo3.org/issues/58818 verfügbar, funktioniert nur mit der Anpassung wie bei rgtabs)

Bei manchen Extensions kann die Zeile in mehreren Dateien auftauchen.

Bei manchen Extensions weiss ich überhaupt nicht mehr, ob sie in dem System benutzt werden. Ich kenne momentan nur einen Weg das zu ermitteln und zwar von phpMaAdmin aus mittels

SELECT * FROM `tt_content` WHERE `list_type` like "%flash%"

Hier auf der Suche nach dem st_flashplayer.

Nur damit es ich nicht vergesse, die unter https://forge.typo3.org/issues/41632, Lösung hier unter #8 vorgeschlagene Lösung sieht folgendermaßen aus:

function includeLocalLang()    {
  $llFile = t3lib_extMgm::extPath('td_calendar').'locallang.xml';

  $version =     class_exists('t3lib_utility_VersionNumber')
                    ? t3lib_utility_VersionNumber::convertVersionNumberToInteger(TYPO3_version)
                    : t3lib_div::int_from_ver(TYPO3_version);
 if ($version >= 4007000) {
    $object = t3lib_div::makeInstance('t3lib_l10n_parser_Llxml');
    $LOCAL_LANG =  $object->getParsedData($llFile, $GLOBALS['LANG']->lang);
 } else {
    $LOCAL_LANG =  t3lib_div::readLLXMLfile($llFile, $GLOBALS['LANG']->lang);
 }

 return $LOCAL_LANG;
}

DerHansen löst das bei chgallery folgendermaßen:

function includeLocalLang()     {
 $llFile = t3lib_extMgm::extPath('chgallery').'locallang.xml';
 return $GLOBALS['LANG']->includeLLFile($llFile, FALSE);
 }

Die zweite Lösung wirkt auf mich korrekter.