Motorola Moto X4 – Installation Lineage OS

Heute wurde mein neues Telefon angeliefert, das Motorola Moto X4. Die Gründe für das Moto X4 waren:

  • Nicht zu gross (5.2″)
  • Dual-Sim
  • Akku 3000 mAh
  • Preis unter CHF 300.00
  • NFC vorhanden
  • Offizieller Build-Release von Lineage OS

Ich möchte das Telefon nicht mit dem Stock-Release von Motorola benutzen. Das Moto X4 soll mit Lineage OS beglückt werden. Dieser Blog-Post basiert auf dem Post von eines Pro-Linux Artikels sowie einem Install-Video und beinhaltet zusätzlich Änderungen aufgrund meinen eigenen Erfahrungen mit dem Moto X4 (Installation TWRP, etc.).

Installation

Mein Installations-Ablauf:

  • Developer-Modus einschalten
  • Handy über adb-Tools (Android Debug Bridge – kurz ADB) starten
  • Bootloader OEM-Sperre entfernen
  • Team Win Recovery Project (TWRP) flashen (Recovery-Modus)
  • Backup des Stock-ROMS erstellen
  • Firmware für Moto X4 aufspielen
  • LineageOS auf SD-Karte aufspielen

Siehe auch

Link

Developer-Modus einschalten

  • Das Telefon beim ersten Start ohne Sim-Karte und ohne Speicher-Karte starten.
  • Durchbooten bis zum Desktop
  • Einstellungen > Über das Telefon aufrufen
  • 7x auf die Build-Nummer Tippen => Das Telefon meldet nun, dass Sie nun “Entwickler” sind => Developer-Modus ist damit aktiviert.
  • Nun erscheint unter den Einstellungen zusätzlich der Eintrag “Entwickleroptionen”
  • Unter den Entwickleroptionen folgende Optionen aktivieren:
    • OEM Entsperrung und
    • USB Debugging

Nun ist das Telefon soweit bereit um es verändern zu können.

Handy über adb-Tools (Android Debug Bridge – kurz ADB) starten

Mit der Android Debug Bridge – kurz ADB – kann man ein Android-Smartphone verwalten. Es ist grundsätzlich für Entwickler gedacht und bietet ein paar coole Funktionen. Ich verwende die adb unter Ubuntu-Linux. Die adb kann folgendermassen installiert werden:

sudo apt-get install android-tools-adb
sudo apt-get install android-tools-fastboot

Nun das Telefon mit dem Linux-Rechner verbinden:

  • Per USB3-Kabel das Telefon mit dem Linux-Rechner verbinden
  • Auf dem Telefon nochmals kurz USB-Debugging de- und wieder aktivieren
  • Nun können über die Linux-Konsole Befehle an das Telefon gesendet werden. Damit das aber funktioniert, muss der Linux-Rechner noch autorisiert werden. Dies geschieht indem ein Befehl an das Telefon gesendet wird.
  • adb reboot bootloader
  • Auf dem Telefon erscheint automatisch die Anfrage ob der Rechner autorisiert werden soll. Hier nun die Genehmigung erteilen:
  • Ein Reboot des Bootloaders zeigt nun folgendes Bild, wobei ersichtlich ist, dass das Gerät “oem_locked” ist:
  • Um Lineage OS aufspielen zu können, muss der auf dem Bootloader der oem-lock entfernt werden.

Bootloader OEM-Sperre entfernen

Motorola bietet Entwicklern die Möglichkeit, den oem-lock zu entfernen. Damit einher geht, dass die Garantie entfällt. Und so geht es:

  • Link zu Motorola aufrufen > Unlock your bootloader > Get started > Next
  • Nun muss man sich anmelden. Das geht entweder mit einem Google-Account oder aber mit einem Motorola-Konto. Ich habe weder noch. Ich verwende deswegen den Link “Mit Motorola ID anmelden”. Hier werde ich aufgefordert eine Motorola-ID zu erstellen.
  • Nun eine Motorola-ID erstellen und anschliessend anmelden. Nach dem Login wird angezeigt, wie man das Device unlocked:
    • fastboot oem get_unlock_data
      ...
      (bootloader) Unlock data:
      (bootloader) 3AasdfaSDddasdf1#5asdd232344839
      (bootloader) 434E5A006DASDFASD678340000#3F14
      (bootloader) BF2C22D54C36CD73EB12C31DF400F1A
      (bootloader) 55769#FE0D752201561568645130000
      (bootloader) 0000000
      OKAY [  0.013s]
      finished. total time: 0.013s

      Daraus muss ein einzeiliger String erstellt werden, den man auf der unlock-Seite von Motorola eingibt:

    • Nun erscheint am Ende der Motorola-Site ein Unlock-Button:
    • Nun wird ein Mail mit dem Unlock-Key zugestellt:
    • Mit dem Key kann nun der Bootloader unlocked werden. Anstelle “UNIQUE_KEY” muss der im Mail zugestellte Key verwendet werden:
    • fastboot oem unlock UNIQUE_KEY
    • Der Befehl muss nun nochmals zwecks Bestätigung wiederholt werden. Anschliessend ist das Gerät offiziell unlocked! 🙂
    • Um zu überprüfen ob der Unlock wirklich geklappt hat, kann das Telefon nochmals gerebooted werden und dann nochmals in den Bootloader gebooted werden:
    • adb reboot bootloader
    • Voilà. “flashing_unlocked” bestätigt dies:

Team Win Recovery Project (TWRP) flashen (Recovery-Modus)

Team Win Recovery Project (TWRP) ist ein Custom-Recovery-System für Android-Geräte. Es wird über unseren unlocked Bootloader in die Recovery-Partition des Telefons geschrieben. Anschliessend kann TWRP über den Bootloader unabhängig vom System gestartet werden. Mit TWRP können wir unser System Backupen, Restoren aber auch ein anderes OS (Custom-Roms) aufspielen:

  • Die TWRP-Version für Moto X4 auf twrp.me suchen und downloaden => https://twrp.me/motorola/motorolamotox4.html
  • Bei einer Erstinstallation müssen zwei Files heruntergeladen werden (twrp-installer-payton-3.2.3-1.zip und twrp-3.2.3-1-payton.img)
  • Nun temporär TWRP auf dem Telefon starten. Das kann durch folgenden Befehl ausgelöst werden:
  • fastboot boot Downloads/twrp-3.2.3-1-payton.img

    Nun kann das ZIP-File auf das Telefon bzw. auf die sdcard kopiert werden:

  • adb push Downloads/twrp-installer-payton-3.2.3-1.zip /sdcard
    [100%] /sdcard/twrp-installer-payton-3.2.3-1.zip

    Nun kann im TWRP über “Installieren” das Installer-ZIP ausgewählt und installiert werden. Damit wird TWRP fix auf der Recovery-Partition installiert:

  • Nun das Telefon neu starten. Dabei installiere ich die TWRP-App als Systemapplikation, so dass zukünftige TWRP-Updates über die App installiert werden können:
  • Das Telefon Startet nun neu.
  • Ab sofort kann beim Aufstarten des Telefons mittles gleichzeitigem Drücken von  “Power Button” und “Lautstärke Down” in den Bootloader gebootet werden.
  • Im Bootloader kann nun mittles Lautstärken-Buttons der Recovery-Mode ausgewählt und bestätigt werden (Power Button). Anschliessend wird in TWRP gebootet:
  • Nun können diverse Funktionen mit TWRP verwendet werden. 🙂

Backup des Stock-ROMS erstellen

Mittles TWRP erstellen wir nun ein Backup unseres Stock-ROMs. Dies, damit wir im “Worst Case” Fall das System wieder in den Ursprungs-Zustand versetzten können:

  • In TWRP booten
  • Löschen/Wipe auswählen
  • Erweitertes Löschen auswählen
  • Optionen auswählen
    • Dalvik / ART Cache
    • Interner Speicher
  • Löschen bestätigen
  • Zurück
  • Diesen Löschvorgang zweimal durchführen => Soll teilweise nötig sein…
  • Zurück zum TWRP Start-Screen gehen.
  • Sichern / Backup auswählen und folgende Partitionen auswählen:
    • Boot (64MB)
    • Data (ohne /data/media)
    • System (2690MB)
  • Name des Backup-Files benennen
  • Speicher auswählen (ich verwende den internen Speicher)
  • Sicherung erstellen
  • In meinem Falle hat das nicht funktioniert (Fehler 255), deswegen hab ich diesen Schritt übersprungen – No Risk No Fun

Firmware für Moto X4 aufspielen

  • Download https://www.androidfilehost.com/?fid=890278863836292604
  • Entpacken und flash-all.sh ausführen. Dies kopiert die Images von Slot A nach Partition B. Das ist notwendig um Lineageos auf Partition B installieren zu können.
  • $ ./flash_all.sh 
    target reported max download size of 536870912 bytes
    sending 'abl_a' (1024 KB)...
    OKAY [  0.024s]
    writing 'abl_a'...
    OKAY [  0.062s]
    ...
    ...
    ...
    OKAY [  0.039s]
    finished. total time: 0.121s

    Jetzt mit fastboot das twrp-image auf das Telefon pushen und booten:

  • fastboot boot twrp-3.2.3-1-payton.img

    Es wird nun TWRP gestartet.

  • Nun das TWRP-ZIP auf das Telefon kopieren
  • adb push twrp-installer-payton-3.2.3-1.zip /sdcard/

    Nun im TWRP über Install das kopierte TWRP auswählen und installieren (swipe to install).

  • Dies installiert das TWRP sowohl auf Slot A als auch auf Slot B.
  • Nun rebooten (keine twrp-Apps installieren). Wenn das Stock Rom wieder sauber bootet, hat alles funktioniert.
  • Wieder in den bootloader booten und Recovery Mode auswählen > Es wird nun TWRP gestartet.
  • Nun das LineageOS Rom und die GApps auf das Telefon kopieren
  • adb push lineage-15.1-20181002-nightly-payton-signed.zip /sdcard/
    [100%] /sdcard/lineage-15.1-20181002-nightly-payton-signed.zip
    ralwet@Z97X-Gaming-5:~/Schreibtisch/Moto X4 Work$ adb push MindTheGapps-8.1.0-arm64-20180808_153856.zip /sdcard/
    [100%] /sdcard/MindTheGapps-8.1.0-arm64-20180808_153856.zip

    Nun im TWRP > Install

  • LineageOs auswählen
  • Add more ZIP auswählen und
  • das TWRP-ZIP File mit auswählen (gem. Video)
  • Dann Swipe to Install
  • Nachdem die Installation abgeschlossen ist, nicht rebooten sondern
  • Wipe Cache auswählen
  • Dann Reboot > Recovery => Dies bootet wieder nach TWRP
  • Nun über Install die GApps mit installieren (Minde the Gapps ZIP)
  • Nun Reboot System

IRedMail: Unban IP Adresse

Nach einigen “Modifikationen” auf meinen Mail-Server schlug fail2ban zu und blockierte meine IP mit

reject-with icmp-port-unreachable

Nach einem kurzen Check auf iptables war auch klar wieso:

> sudo iptables -L -n

Chain fail2ban-dovecot (1 references)
target     prot opt source               destination         
REJECT     all  --  1.2.3.4              0.0.0.0/0            reject-with icmp-port-unreachable

Um die IP wieder freizuschalten geht man folgendermassen vor:

Ermitteln des fail2ban jails

> sudo fail2ban-client status

Status
|- Number of jail:	5
`- Jail list:		ssh-iredmail, roundcube-iredmail, w00tw00t-scans, dovecot-iredmail, postfix-iredmail

Dabei erkennt man, dass der Jail-name dovecot-iredmail mit der  iptables chain fail2ban-dovecot korrespondiert. Das ist also die jail, um welche es sich dreht.

Nun die Ip wieder freischalten

> sudo fail2ban-client set dovecot-iredmail unbanip 1.2.3.4

Ein weiterer check mit iptables zeigt, dass die Freischaltung funktioniert hat:

> sudo iptables -L -n

Chain fail2ban-dovecot (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

Referenz

Serverfault: Fail2ban – unpan ip

Alfresco Loging reduzieren: AccessLogValve in server.xml

Meine Alfersco-Installation “flutet” den Server mit sehr grossen “localhost_access_log” Files. Hauptsächlich mit SOLR-Requests dieser Sorte:

GET /alfresco/service/api/solr/transactions?fromCommitTime=1352137016770&toCommitTime=1352144216770&maxResults=2000 HTTP/1.1" 200 115

Also jedesmal wenn Solr mit Alfresco kommuniziert, wird ein Log-Eintrag erstellt.

“Lösung” nach Holzhacker-Methode:

  • Deaktivieren der Tomcat-Valves
sudo vi tomcat/conf/server.xml

Und deaktivieren bzw auskommentieren des Valves:

<!--<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="localhost_access_log" suffix=".txt"
               pattern="%h %l %u %t &quot;%r&quot; %s %b" /> -->

 

docker / docker-compose Befehle

Container stoppen

docker-compose down

Container aktualisieren

docker-compose down
docker-compose pull
docker-compose up -d

Volumes anzeigen / löschen

Achtung! Dies entfernt einerseits die Container, aber inklusive die statischen Files bzw. Volumes (wordpress_files & db_data)

docker volume ls                # Listet alle Docker-Volumes auf
docker-compose down ––volumes   # löscht ein Container inkl. Volumes (!)

Aktive Containers anzeigen

docker container ls              # Listet alle aktiven container auf

Bash eines Containers öffnen

Es ist möglich über den Docker-Host auf eine Container-Bash zuzugreifen.
Syntax:

docker exec -i -t <docker-id> /bin/bash

Docker Logs anzeigen

Wenn Docker-Containers im “detached-mode” (-d) laufen, werden keine Logs angezeigt. Die Logs können folgendermassen sichtbar gemacht werden:

# Zeigt das Log
docker logs <ContainerName/ContainerID>  
# Zeigt das laufende Log (tail -f)
docker logs --follow <ContainerName/ContainerID>
# Zeigt  die letzen 2500 Zeilen des Logs
docker logs --tail 2500 <ContainerName/ContainerID>
# Zeigt das Log seit dem 28.12.2018 10:00
docker logs --since 2018-12-28T10:00 ContainerName/ContainerID

Auch docker-compose bietet die Möglichkeit auf die Docker-Logs zuzugreifen:

docker-compose logs <service-name>

Entferne nicht benutzte Docker Images

Folgender Befehl entfernt alle aktuell nicht benutzen Images und Volumes

docker system prune

 

MySQL Root Login ohne Passwort

Auf meinem lokalen mysql Server (Enticklungsmaschine) möchte ich einen root user ohne passwort:

1 connect mit sudo mysql

sudo mysql -u root

2 aktive mysql users anzeigen

SELECT User,Host FROM mysql.user;
+------------------+-----------+
| User | Host |
+------------------+-----------+
| admin | localhost |
| debian-sys-maint | localhost |
| magento_user | localhost |
| mysql.sys | localhost |
| root | localhost |

3 Den aktuellen root-user löschen

mysql> DROP USER 'root'@'localhost';
Query OK, 0 rows affected (0,00 sec)

4 Neuen Root-User erstellen

mysql> CREATE USER 'root'@'%' IDENTIFIED BY '';
Query OK, 0 rows affected (0,00 sec)

5 Alle Berechtigungen an Root vergeben

mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
Query OK, 0 rows affected (0,00 sec)

6 Flush druchführen

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0,01 sec)

7 Exit und reconnect ohne sudo

Nubia Z11 mini Root & GApps

Aktuellste Version des Original-China ROMS installieren

Achtung, es existieren zwei ROM-Versionen für das Nubia Z11 mini nx529j. Eines für die China-Version mit 64GB Speicher und eines für die Internationale Version mit 32GB Speicher. Ich besitze die China-Variante.

  • Als erstes unter http://www.needrom.com/category/zte/serial-nubia/z11-mini/ das original China Rom herunterladen und auf die SD-Disk speichern. Für die Internationale Version kann das ROM hier herunter geladen werden: http://www.nubia.com/de/support.php?a=phone&pid=9
  • Nubia ausschalten und mit + und Power-Button in das Nubia Recovery gehen.
  • Hier nun das ROM auf der SD-Disk auswählen und das ROM installieren
  • Das sollte so ohne Probleme durchlaufen

Telefon Rooten und TWRP installieren

Das Rooten und Installieren von TWRP habe ich nach folgenden Instruktionen durchgeführt http://www.nubiamobileshop.com/blog/nubia-z11-mini-how-to-root/

TWRP wird so auf chinesisch installiert. Die sprache kann man dann im TWRP einfach ändern: https://www.youtube.com/watch?v=KOhR92EKD7A

Google-Apps installieren

Unter http://opengapps.org/ kann man die Google-Apps zusammenklicken => ARM64, Android 5.1, Nano-Variante

Auf die SD Herunterlanden und mittels TWRP installieren.

China-Apps deinstallieren

  • Links
    http://www.nubiamobileshop.com/blog/nubia-z11-mini-how-to-root/
    http://www.needrom.com/category/zte/serial-nubia/z11-mini/ => Original China ROM
  • http://opengapps.org/
  • https://translate.googleusercontent.com/translate_c?act=url&depth=2&hl=hr&ie=UTF8&prev=_t&rurl=translate.google.com&sl=auto&sp=nmt4&tl=en&u=https://4pda.ru/forum/index.php%3Fshowtopic%3D803370&usg=ALkJrhgDB93aDkasaOZpte9lwOjD04HuPQ
  • https://www.kuketz-blog.de/your-phone-your-data-teil1/

Subversion neues Projekt anlegen

Ich betreibe einen Subversion-Server. Meine Projekte liegen alle unter dem SVN-Home Verzeichnis

/home/svn

Hin und wieder kommt es vor, dass darauf ein neues Projekt angelegt werden muss.

  1. Projekt-Vezeichnis erstellen
    cd /home/svn
    sudo mkdir myproject
  2. SVN-Projekt anlegen
    sudo svnadmin create /home/svn/myproject
  3. Berechtigungen korrekt setzen
    cd /home/svn
    sudo chown -R www-data:subversion myproject
    sudo chmod -R g+rws myproject
  4. SVN-Verzeichnisse tag, branches und trunk erstellen.
    Dazu Checke ich das Projekt aus und erstelle anschliessend die Verzeichnisse in der “Working Copy”

    cd /home/user/myprojectWorkingCopy
    svn co file:///home/svn/myproject
    svn mkdir trunk
    svn mkdir tag
    svn mkdir branches
  5. Nun die Verzeichnisse einchecken
    cd /home/user/myprojectWorkingCopy
    svn commit -m"Creating basic directory structure"

Und “schon” kann man loslegen mit dem schönen neuen SVN-Projekt 🙂

Subversion auf Ubuntu 16.04 installieren/migrieren

Dieser Beitrag dient mir um meine durchgeführten Schritte später nachvollziehen zu können.

Ich installiere einen Subversion-Server und migriere meine alten Repositories aus Subversion Version 1.6 nach Version 1.9.

Subversion und Apache installieren

sudo apt install subversion apache2 libapache2-svn

Subversion-Gruppe erstellen

sudo addgroup subversion

Eigener User sowie Apache User der Subversion-Gruppe hinzufügen

sudo adduser www-data subversion
sudo adduser <eigenerUser> subversion

Anschliessend aus- und wieder einloggen. Erst dann werden die Änderungen aktiv.

Nun das SVN-Home und Projekt-Verzeichnis anlegen

sudo mkdir /home/svn
cd /home/svn
sudo mkdir myproject

Nun das Subversion-Repository für das Projekt erstellen

sudo svnadmin create /home/svn/myproject

Berechtigungen setzen

cd /home/svn
sudo chown -R www-data:subversion myproject
sudo chmod -R g+rws myproject

WebDAV für Subversion konfigurieren

Config-File /etc/apache2/mods-available/dav_svn.conf anpassen

  <Location /svn>
     DAV svn
     SVNParentPath /home/svn
     SVNListParentPath On
     AuthType Basic
     AuthName "Subversion Repository"
     AuthUserFile /etc/subversion/passwd
     Require valid-user
     LimitXMLRequestBody 0
  </Location>

Apache restarten

sudo service apache2 restart

User-File für Zugang auf WebDAV erstellen
die -c Option nur beim erstellen verwenden. Bei Modifikationen eines bestehenden Files den Befehl ohne -c ausführen.

sudo htpasswd -c /etc/subversion/passwd user_name

Jetzt kann das vorhin erstellte Projekt über WebDAV ausgecheckt werden. Versuchen wir’s:

svn co http://hostname/svn/myproject myproject --username user_name

Migrieren der Repositories des alten Servers in den neuen Server

Dazu exportieren ich das alte Repository in ein Dump-File:

svnadmin dump --quiet /home/svn/myproject > myproject.dump

Es besteht nun auch die Möglichkeit aus diesem Dump-File spezielle Verzeichnisse weiter zu exportieren:

cat myproject.dump | svndumpfilter include trunk/subproject > subproject.dump

Nun kann das Dump-File auf dem neuen Server importiert werden

svnadmin load --quiet /home/svn/myproject < subproject.dump

Achtung: Wenn man ein Subfolder importiert, müssen die Parent-Folder exsistieren, sonst gibts einen Fehler “svnadmin: E160013: Datei nicht gefunden: »/trunk/myproject«
In diesem Falle muss also noch “trunk” als Folder im neuen “myproject” erstellt werden.

 svn mkdir http://localhost/svn/pvs2/trunk -m "Create the trunk folder" --username=ralph

svndumpfilter3

Es kann vorkommen, dass das extrahieren von tags mit dem Fehler “svndumpfilter: Ungültiger Quellpfad einer Kopie” fehlschlägt. Das kann offenbar auftreten, wenn man Files/Order im Repository kopiert/verschoben hat. Selbstverständlich habe ich das 🙂
Die Lösung bietet eine Erweiterung von svndumpfilter, svndumpfilter3. Gefunden hier. Dieses Phyton-Script herunterladen und folgendermassen starten:

cat svn-projects.dump | ./svndumpfilter3 --untangle=/var/svn-repos/projects tags/pvs2 > pvs2-tags.dump

Die –untangle Option zeigt auf das lokale SVN-Repository Root. Svndumpfliter3 benutzt dieses Repository um die Probleme auzulösen bzw. zu convertieren.

Reverse Proxy

Meinen Subversion-Server betreibe ich hinter einem Apache2 Reverse Proxy. Damit dies auch sauber funktioniert muss der redirect auf dem ReverseProxy angepasst werden. Anosten kann es zu 405-Fehlern kommen “Method not allowed”. Dazu definiere ich im VirtualHost folgende Location:

<Location / >
   <Limit OPTIONS PROPFIND GET REPORT MKACTIVITY PROPPATCH PUT CHECKOUT MKCOL MOVE COPY DELETE LOCK UNLOCK MERGE>
      Order Deny,Allow
      Allow from all
      Satisfy Any
    </Limit>
</Location>

Referenzen

Nextcloud Sync mit Ftp-Server

Hier habe ich beschrieben, wie man auf Nextcloud einen FTP-Server als externen Speicher konfigurieren kann. Mit einem kleinen Hack ist es damit möglich Files von einem FTP-Server auf Nextcloud zu “pushen”. Wirklich funktioniert hat das bei mir nicht zufriedenstellend. – Das wird so von Nextcloud/Owncloud auch nicht offiziell supported. Zeit für einen zweiten Anlauf, der nun seit einem knappen Jahr für mich zufriedenstellend funktioniert:

Der Use-Case ist immer noch derselbe:

  • Mein Drucker kann auf einen FTP-Server scannen, nicht aber in ein Webdav Verzeichnis
  • Ich möchte die gescannten Dokumente aber direkt in Nextcloud haben und mich nicht noch zusätzlich mühsam auf den FTP-Server connecten um die Dokumente abzuholen.

Meine Lösung:

  • Ich betreibe einen eigenen FTP Server.
  • Statt in Nextcloud diesen FTP Server als externen Speicher hinzuzufügen, mounte ich auf dem FTP-Server selber das Nextcloud-Verzeichnis mittels davfs2 (also mit WebDav):
  • Dazu richte ich auf Nextcloud einen speziellen User (Scan) ein, der nur für das Scanning verwendet wird. Dieser Nextcloud-User hält das Verzeichnis in welches gescannt wird.
  • Dieses Verzeichnis wird dann mit allen  Nextcloud-Usern geteilt, welche über das “Scan-Feature” verfügen möchten (über Verzeichnis teilen).
  • Auf dem  FTP Server mounte ich das Nextcloud Scan-Verzeichnis des Users “Scan” mittels davfs und konfiguriere das Ziel-Scanverzeichnis des FTP Servers auf eben dieses Verzeichnis des Scan-Users. Damit verwende ich das offiziell von Nextcloud unterstützte WebDav Protokoll um vom FTP Server nach Nextcloud zu speichern.

Und los geht’s:

davfs2 installieren

Auf dem FTP-Server “webdav” installieren:

sudo apt-get install davfs2

Nextcloud Webdav als root mounten

Der mount kann folgendermassen durchgeführt werden:

sudo mount -t davfs https://nextcloud/remote.php/webdav/  /home/user/nextcloudScan/ -o uid=<userid>,gid=<groupid>,file_mode=775,dir_mode=775

Damit dies automatisch beim Systemstart passiert, trage ich dies in /etc/fstab ein. Bitte beachten, dass ich zusätzlich die Option “noauto” hinzufüge. Ein direktes mounten beim booten (auto) schlägt fehl, weil das Netzwerk zu diesem Zeitpunkt noch nicht aufgebaut ist. Das automatische mounten kommt später.

https://nextcloud/remote.php/webdav/  /home/user/nextcloudScan/ davfs noauto,uid=<userid>,gid=<groupid>,file_mode=775,dir_mode=775 0 0

Nun wird jeweils noch der Webdav-User inkl. Passwort abgefragt. Diese Infos kann man im file /etc/davfs2/secrets hinterlegen:

/home/user/nextcloudScan <nextcloudUser> <nextcloudPasswort>

Nun sollte ein mount automatisch funktionierten:

sudo mount /home/user/nextcloudScan

Der Trick liegt nun dabei, dass das der FTP-Server in das Verzeichnis nextcloudScan schreibt. Meinen FTP Drucker konfiguriere ich entsprechend. Damit schreibt der Drucker indirekt nach Nextcloud.

Automatisch beim booten mounten

Das file /etc/rc.local wird nach dem booten ausgeführt. Hier hinterlege ich nun noch meinen mount-Befehl:

vi /etc/rc.local

mount /home/user/nextcloudScan

…Voilà, jetzt werden alle Einträge in der fstab gemounted.

Alternative: Das lokale FTP-Verzeichnis mit rsync nach nextcloud synchen

Ansonsten könnte man auch das FTP-Verzeichnis auf dem FTP-Server mit rsync synchronisieren. Das ist aber mit obiger Lösung so nicht mehr nötig.

rsync -rutv --inplace scan/ nextcloudScan/

Referenzen