Owncloud geht sehr großzügig mit gelöschten Dateien um. Die werden in einen Papierkorb-Ordner verschoben und normalerwise nur dann gelöscht, wenn Speicherplatz knapp wird.
Man kann aber einen oder alle Papierkorb-Ordner von der Konsole aus löschen:
sudo -u wwwrun php occ trashbin:cleanup user
für einen bestimmten User oder
sudo -u wwwrun php occ trashbin:cleanup
für alle User.
Der Befehl occ ist im Wurzelverzeichnis der Installation zu finden.
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:
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'
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:
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.
Kürzlich hatten wir das Problem, dass in der Mail-Warteschlange sehr sehr viele Mail auftauchten. Da waren zum größten Teil fehlgelaufene Systemmeldungen von Arpwatch.
Da habe ich micht etwas mit dem Mailserver Exim beschäftigt.
Für die grundlegenden Befehle gibt es unter http://www.florian-fritsch.com/exim4-kleines-mailqueue-howto/ eine nettes HowTo.
Spannend finde ich auch die Informationen unter http://bradthemad.org/tech/notes/exim_cheatsheet.php, speziell der Befehl
exiqgrep
bietet ungeahnte Möglichkeiten.
Nun muss man nur noch das jeweilige Mailprogramm so konfigurieren, dass es die Verbindungen auch verschlüsselt anfordert. Auch hier gibt es wieder zwei Richtungen. Im Reiter Server-Einstellungen gibt man die Konfiguration an, die zum Abrufen der Mails notwendig ist.
Im Reiter Postausgangs-Server kommen dann die Einstellungen zum Versenden der Mails. In diesem Fall sind die Einstellungen identisch. Eigentlich hätte ich aber auch noch ein Zertifikat für smtp.debacher.de erzeugen können.
In der Logdatei /var/log/mail kann man erkennen, wenn die Mails verschlüsselt abgerufen werden:
2016-10-22T16:21:45.874680+02:00 h2366010 dovecot: imap-login: Login: user=<xxx@debacher.de>, method=PLAIN, rip=85.176.x.y, lip=81.169.xx.yy, mpid=30944, TLS, session=<vv7q4HQ/xABVsIAH>
Hier taucht dann TLS in der Zeile auf. Entsprechend für das Abliefern der Mails:
2016-10-22T18:17:17.327190+02:00 h2366010 postfix/smtpd[32315]: Anonymous TLS connection established from x5b087001.dyn.telefonica.de[85.176.x.y]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Da der Zugriff auf das Mailsystem auch immer häufiger mobil erfolgt scheint mir eine Verschlüsselung der Verbindung unvermeidlich. Dazu muss man in die Konfiguration von Postfix und Dovecot eingreifen. Ausgangspunkt für meine Konfiguration ist die Server-Beschreibung unter http://www.debacher.de/wiki/Root-Server_mit_OpenSuSE_13.2 .
Da mir das System von letsencrypt sehr zusagt möchte ich die zugehörigen Zertifikate auch für das Mailsystem nutzen. Dazu habe ich mir einen virtuellen Apache-Server eingerichtet, der auf http://imap.meine-domain.de hört und ansonsten keinen Inhalt zur Verfügung stellt. Der virtuelle Server ist nur für die Erstellung und Verlängerung der Zertifikate wichtig.
Hierfür habe ich mir eine letsencrypt.ini angelegt:
# Wir nutzen 4096 bit RSA key statt 2048 rsa-key-size = 4096 # allgemeine Angaben email = <name>@<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 = imap.debacher.de, smtp.debacher.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/imap.debacher.de/httpdocs/
Dann mittels
/root/letsencrypt/letsencrypt-auto certonly --config /srv/www/vhosts/imap.debacher.de/letsencrypt.ini
das Zertifikat erzeugt.
Für Dovecot müssen dann folgende Informationen in der Konfigurationsdatei stehen:
protocols = imap pop3 lmtp sieve ssl = yes ssl_cert = </etc/letsencrypt/live/imap.debacher.de/fullchain.pem ssl_key = </etc/letsencrypt/live/imap.debacher.de/privkey.pem
Nach einem Neustart greift Dovecot dann auf das Zertifikat zu.
Abfragen kann man das Zertifikat dann mittels:
openssl s_client -connect imap.debacher.de:pop3s
oder
openssl s_client -connect imap.debacher.de:imaps
oder
openssl s_client -connect imap.debacher.de:smtp -starttls smtp
Für Postfix muss etwas mehr gemacht werden. Wir haben ja zwei Richtungen zu beachten, Postix kann als Client und als Server dienen. Wenn er Mails an andere Rechner abliefert, dann ist er Client (smtp_…), ansonsten Server (smtpd_…).
Ich habe an die Konfigurationsdatei /etc/postfix/main.cf folgende Zeilen angehängt:
# tls config smtp_tls_note_starttls_offer = yes # eingehende Verbindungen smtpd_use_tls = yes smtpd_enforce_tls = no # Obiges kann zusammengefasst werden zu smtpd_tls_security_level=may smtpd_tls_key_file = /etc/letsencrypt/live/imap.debacher.de/privkey.pem smtpd_tls_cert_file = /etc/letsencrypt/live/imap.debacher.de/fullchain.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_tls_mandatory_protocols=!SSLv2, !SSLv3 #tls_random_source = dev:/dev/urandom #tls_random_prng_update_period = 3600s # ausgehende Verbindungen smtp_use_tls = yes smtp_enforce_tls = no # Obiges kann zusammengefasst werden zu smtp_tls_security_level=may smtp_tls_key_file = /etc/letsencrypt/live/imap.debacher.de/privkey.pem smtp_tls_cert_file = /etc/letsencrypt/live/imap.debacher.de/fullchain.pem smtp_tls_loglevel = 1 smtp_tls_mandatory_protocols=!SSLv2, !SSLv3
Nun muss noch in der Datei /etc/postfix/master.cf eine Zeile auskommentiert werden:
tlsmgr unix - - n 1000? 1 tlsmgr
Etwas mehr Aufwand bedeutet es den Nutzern der eMail-Domain die Konfiguration ihrer Mail-Clients zu beschreiben. Zumindest für Thunderbird gibt es eine genial einfache Lösung dafür, Danke an Lukas Thiel für den Hinweis.
Thunderbird unterstützt eine Autokonfiguration. Für die großen Anbieter greift es dazu auf eine eigene Datenbank zu, als kleiner Anbieter kann man die notwendigen Informationen nach folgender Anleitung erstellen: https://developer.mozilla.org/de/docs/Mozilla/Thunderbird/Autokonfiguration.
Der Anleitung folgend habe ich mir im Webserververzeichnis httpdocs meiner Domain eine Datei .well-known/autoconfig/mail/config-v1.1.xml angelegt mit folgendem Inhalt:
Thunderbird sucht beim Anlegen einer neuen Mailadresse nach dieser Datei in der zugehörigen Domain. Wenn die Datei gefunden wird, dann konfiguriert sich das Mailprogramm ganz automatisch nach diesen Einstellungen.
Für den Fall, dass die automatische Konfiguration nicht möglich ist findet sich eine Konfigurationsbeschreibung unter http://www.debacher.de/ublog/2016/10/thunderbird-konfigurieren/.
In der Logdatei /var/log/mail kann man erkennen, wenn die Mails verschlüsselt abgerufen werden:
2016-10-22T16:21:45.874680+02:00 h2366010 dovecot: imap-login: Login: user=<xxx@debacher.de>, method=PLAIN, rip=85.176.x.y, lip=81.169.xx.yy, mpid=30944, TLS, session=<vv7q4HQ/xABVsIAH>
Hier taucht dann TLS in der Zeile auf. Entsprechend für das Abliefern der Mails:
2016-10-22T18:17:17.327190+02:00 h2366010 postfix/smtpd[32315]: Anonymous TLS connection established from x5b087001.dyn.telefonica.de[85.176.x.y]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Bei den neuen Ubuntu-Versionen ist anscheinend kein Oracle-Java mehr dabei. Das ist nicht weiter schlimm, da das Oracle-Java nicht wirklich installiert werden muss, es langt, wenn man die Archive an einem geeigneten Ort entpackt.
Es mach aber Sinn diese Version in die alternatives Verwaltung einzubinden.
Hat man also das Oracle-Java im Pfad /opt/oracle/jre entpackt, dann muss man es noch in das System einbinden mittels:
sudo update-alternatives --install "/usr/bin/java" "java" "/opt/oracle/jre/bin/java" 1 sudo update-alternatives --install "/usr/bin/javaws" "javaws" "/opt/oracle/jre/bin/javaws" 1
Aktivieren kann man es nun mittels:
sudo update-alternatives --set "java" "/opt/oracle/jre/bin/java" sudo update-alternatives --set "javaws" "/opt/oracle/jre/bin/javaws"
oder über
sudo update-alternatives --config java
Hier kann man dann die gewünschte Version auswählen.
Weitere Hinweise unter:
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
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).
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:
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.
Will 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.
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
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.