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

FTP Server auf Ubuntu 16.04.1 (vsftpd)

Installation

sudo apt install vsftpd

Das standard-Directory ist /srv/ftp, welches für den User ftp bei der Installation eingerichtet wird.

Konfiguration

In File /etc/vsftpd.conf folgendes Konfig anpassen (reboot nicht vergessen):

write_enable=YES
anonymous_enable=NO
ftpd_banner=Willkommen zu ftp.intelli.ch.
use_localtime=YES
chroot_local_user=YES
#Port nicht 21 sondern 345
listen_port=345

Grundsätzlich erlaubt vsftpd allen Systemusern den Zugriff über FTP. Nun soll aber nicht allen Systemusern der Zugriff erlaubt werden. Dafür modifizieren wird das file /etc/vsftpd.chroot_list. Die in diesem File enthaltenen User können  zugreifen:

chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list

User erstellen

Einen User erstellen, der auf FTP Zugriff erhalten soll

sudo adduser ftpuser

Verschlüsselung

Ich erstelle die Möglichkeit über FTPS zu kommunizieren. Dazu in /etc/vsftpd.conf folgende Zeilen erfassen:

ssl_enable=Yes
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key

Mit Filezilla verbinden

Referenzen

Update ESXi Patch-Bundle

  1. ESXi 5.5 in Maintenance-Mode wechseln / alle VMs stoppen
  2. Upload ESXi Patch-File auf ESXi host (zip)
  3. Schauen, welche Profile im Zip-File vorhanden sind:
    esxcli software sources profile list -d /vmfs/volumes/53ce978d-fa434b02-5512-d43
    d7e942aae/ESXi550-201510001.zip

    Resultat

    Name                             Vendor        Acceptance Level
    -------------------------------  ------------  ----------------
    ESXi-5.5.0-20151004001-no-tools  VMware, Inc.  PartnerSupported
    ESXi-5.5.0-20151004001-standard  VMware, Inc.  PartnerSupported

    „no-tools“ ist das Profile ohne die VmWare-Tools, „standard“ ist das Update mit allem drum und dran. Es kann auch sein, dass ein Profilname mit „s“ endet (z.B. ESXi-5.5.0-20151004001s-standard). Dieser Patch würde dann nur die Security-Updates beinhalten.

  4. Jetzt kann das Upate durchgeführt werden
    esxcli software profile update --depot=/vmfs/volumes/53ce978d-fa434b02-5512-d43
    d7e942aae/ESXi550-201510001.zip -p ESXi-5.5.0-20151004001-standard
  5.  Jetzt den ESXi-Host durchstarten.
  6. Wichtig: Beim esxcli-Befehl die update Option, NICHT die install-Option verwenden. Die Update-Option esetzt die bereits vorhandenen Pakete auf dem ESXi-Host mit neuen Versionen aus dem Bundle. Vorhandene Pakete auf dem ESXi-Host, welche nicht im Bundle vorhanden sind werden nicht gelöscht.
    Die Install-Option würde Pakete, des ESXi-Hosts, welche nicht im Bundle vorhanden sind, löschen (komplette „reinstallation“).

Referenzen:

ESXi Embedded Host-Client

VmWare Host-Client, der den mittlerweile ziemlich veralteten vSphere Client ablösen soll:

https://labs.vmware.com/flings/esxi-embedded-host-client

Einmal auf dem ESXi-Host installiert kann man den HTML5 Host-Client über https://<host:port>/ui/ abrufen.

Einzelne VMs kann man z.B. über vmrc://192.168.2.30/?moid=41 aufrufen. Dazu muss natürlich auch erst „VmWare Remote Client“ vmrc auf den lokalen System installiert werden.

Leider funktioniert bei mir der Embedded Host-Client bzw. der HTML5-Client im zusammenspiel mit meinem ESXi 5.5 Host nicht wirklich. Der Host und die VMs können toll eingesehen werden. Aktionen wie Herunterfahren, etc. können aber nicht durchgeführt werden. Geschweige denn kann eine Konsole zu den VMs geöffnet werden.

Fazit: Aktuell bleibt einem ESXi (free) User immer noch nichts anderes übrig als den alten verstaubten vSphere Client zu benutzen.,..

 

Let’s encrypt

letsencrypt ist eine Zertifizierungsstelle, welche es erlaubt Zertifikate vollautomatisch und GRATIS zu generieren. Damit entfällt endlich die müsahme manuelle Erstellung von Zertifikaten. Und so geht es:

Ich installiere letsencrypt auf einem Ubuntu 16.04 System mit installiertem Apache:

    1. Letsencrypt installieren
      sudo apt install letsencrypt python-letsencrypt-apache
    2. Zertifikat generieren
      Bevors mit dem Zertifikate erstellen losgeht, muss ich zuerst den Apache-Dienst stoppen, weil letsencryp einen standalone Server auf port 80 verwendet:

      sudo service apache2 stop

      Nun generiere ich das Zertifikat mit „certonly“. Damit modifiziert mir letsencrypt nicht das Apache-Config File. Dieses möchte ich selber modifizieren… Für jede Domain kann dieser Befehl wiederholt werden:

      sudo letsencrypt certonly --agree-tos --email postmaster@yourdomain.ch -d www.yourdomain.ch

      Und voilà:

      IMPORTANT NOTES:
       - Congratulations! Your certificate and chain have been saved at
         /etc/letsencrypt/live/nextcloud.domain.ch/fullchain.pem. Your cert
         will expire on 2017-01-23. To obtain a new version of the
         certificate in the future, simply run Let's Encrypt again.
       - Some rewrite rules copied from /etc/apache2/conf-
         enabled/nextcloud.conf were disabled in the vhost for your HTTPS
         site located at /etc/apache2/conf-enabled/nextcloud-le-ssl.conf
         because they have the potential to create redirection loops.
      

      Nun den Apache wieder starten:

      sudo service apache2 start
    3. Das Script erstellt vollautomatisch die benötigten Zertifikate und legt diese ab unter
      /etc/letsencrypt/live/your.domain.zz/

      Das Zertifikat kann nun am conf-File des Apachen eingetragen werden

      SSLCertificateKeyFile /etc/letsencrypt/live/your.domain.zz/privkey.pem
      SSLCertificateFile /etc/letsencrypt/live/your.domain.zz/cert.pem
      SSLCertificateChainFile /etc/letsencrypt/live/your.domain.zz/chain.pem

    Renewal

    Letsencrypt stellt Zertifikate aus, welche 90 Tage gültig sind. Es wird empfohlen, dass alle 60 Tage ein renewal durchgeführt wird. Dies kann am einfachsten über einen cron-job erledigt werden, der monatlich ausgeführt wird:

    sudo vi /etc/cron.monthly/letsencrypt-renew
    #!/bin/bash
       echo "Stop Apache2 Service"
       service apache2 stop
       echo "Renew letsencrypt certificates"
       letsencrypt --standalone renew
       echo "Restart Apache2 Service"
       service apache2 start
    exit 0
    sudo chmod +x /etc/cron.monthly/letsencrypt-renew

     

Löschen

Mal erstellte Zertifikate, welche nicht mehr benötigt werden, können gelöscht werden:

sudo letsencrypt delete -d xx.domain.xx

 

Alfresco Upgrade Prozedur von Version 5.1 auf Version 5.2 (Alfresco Community Edition 201612 GA)

Dieses Howto beschreibt meine Schritte um eine Alfresco 5.1 Installation nach Alfresco 5.2 (Alfresco Community Edition 201612 GA) zu erhöhen.

Aktuelle Alfresco Installation

Mein Alfresco-System wird nicht im produktiven Umfeld sondern lediglich privat genutzt. Die Anforderungen an das System sind entsprechend niedgrig (keine Skalierung, geringe Performance).

Alfresco
2 Server 1 VM-Server für die Alfresco Installation, DB und Index (45 GB Festplatte)
1 VM-Server für Daten (350 GB Festplatte)
Alfresco Home /opt/alfresco-community
Installation Default installations-Routine
Postgres-SQL Ja, Installiert über die normale Installations-Routine von Alfresco
Index SOLR4
Alfresco Service Ja. Servicename „alfresco“, Installiert über die normale Installations-Routiene von Alfresco
alf_data Das alf_data Verzeichnis befindet sich ausgelagert auf einem NFS-Server (VM für Daten und Index). Das alf_data Verzeichnis wird dann auf dem Alfresco-Server nach /opt/alfresco/alf_data gemounted.
Ugrade Prozedur Die Upgrade Prozedur richtet sich grundsätzlich nach der Alfresco-Doku: Link

Neue VM erstellen

Bei einem Alfresco-Update (welches ja nicht so häufig vorkommt) erstelle ich meist eine neue VM mit aktuellstem Ubuntu-Betriebssystem (LTS):

  1.  Neue VM erstellen (ESXi 5.5, VM mit Ubuntu-Linux, 4 CPUs, 8GB RAM)
  2. Alfresco benötigt einige Libs als Voraussetzung. Die Installationsroutine meckert, wenn diese nicht vorhanden sind (siehe hier).
    Auf Ubuntu folgendes ausführen:

    sudo apt-get install libice6 libsm6 libxt6 libxrender1 libxext6 libfontconfig1 libcups2 libglu1-mesa libcairo2 libegl1-mesa libxinerama1

    Achtung: Die Installationsroutine zeigt nach der Installation aller notwendigen Libs immer noch an, dass diese Fehlen (Stand 3.1.2017, Ubuntu 16.04). Das scheint aber ein Bug der Installationsroutine von Alfresco zu sein.

  3. Alfresco auf der neuen VM installieren.
    1. Für die Installation verwende ich die default Installations-Routine von Alfresco.
    2. Die Ports Ändere ich auf 80 bzw. 443.
    3. Den Service installiere ich auch mit der Alfresco Installations-Routine.
  4. Memory anpassen: Link
  5. Max Open Files anpassen: Link
  6. Anschlissend überprüfen ob die neue Installation sauber funktioniert (z.B. LibreOffice).

Konfigurationen/Customizing der neuen Installation anwenden

Ich habe auf meinem Alfresco einige „customs“ eingebaut:

Custom Datalists

Custom Share Header

Custom Web-Extensions

  1. Zwei eigene Listen (Inventar und Bibliothek). Hier zeige ich nur die Bibliotheksliste. Das selbe auch für Inventar machen.
  2. Die neuen Datalists registrieren
    cp /opt/alfresco-alt//tomcat/shared/classes/alfresco/extension/customDatalist-model-context.xml /opt/alfresco-neu//tomcat/shared/classes/alfresco/extension/customDatalist-model-context.xml

    Datalist-Model erstellen/kopieren

    cp /opt/alfresco-alt/tomcat/shared/classes/alfresco/extension/bibliothekDatalistModel.xml /opt/alfresco-neu/tomcat/shared/classes/alfresco/extension/bibliothekDatalistModel.xml

    Das web-extensions File erweitern mit den Erweiterungen aus der alten Instanz

    /opt/alfresco-community/tomcat/shared/classes/alfresco/web-extension/share-config-custom.xml
  3. Download Buttons entfernen: Link
  4. Header-Icons ausblenden, welche nicht gebraucht werden: Link
  5. Download-Button nur wenn Schreibrecht vorhanden: Link

Alte Alfresco-Instanz backupen

  1. Alte Alfresco-Instanz stoppen
  2. Ganze DB backupen
    1. Postgres starten
      sudo /opt/alfresco-community/alfresco.sh start postgresql
    2. Die gesamte Alfresco-Datenbank dumpen
      cd /opt/alfresco-community/postgresql/bin/
      ./pg_dump -h localhost -U alfresco alfresco > /tmp/alfrescodbdump
    3. Postgres stoppen
      sudo /opt/alfresco-4.2.d/alfresco.sh stop postgresql
  3. alf_data Verzeichnis der alten Alfresco-Instanz backupen. => Darauf achten, dass der Alfresco-Service nicht läuft!
    Ich kopiere dazu einfach das gesamte alte alf_data Verzeichnis nach alf_data_alt.

Daten auf neuer Alfresco-DB Instanz restoren

  1. Die neue Alfresco-Instanz stoppen.
  2. Nun die Postgresql-Datenbank der NEUEN Installation starten:
    sudo /opt/alfresco-community/alfresco.sh start postgresql
  3. Die Datenbank „alfresco“ der neuen Installation löschen:
    cd /opt/alfresco-community/postgresql/bin/
    ./dropdb -U alfresco alfresco -h localhost -i
    Database "alfresco" will be permanently removed.
    Are you sure? (y/n) y
    Password:
    
  4. Die gelöschte Datenbank wieder erstellen
    $ sudo ./createdb -U postgres -T template0 alfresco -h localhost
    Password:
    
  5. Nun den Alfresco-Dump der alten Instanz auf der neuen einspielen:
    $ sudo ./psql -U alfresco alfresco -h localhost < /tmp/alfrescodbdump
    Password:
    (...)
    ALTER TABLE
    ALTER TABLE
    REVOKE
    REVOKE
    GRANT
    GRANT
    $ exit
  6. Die Postgres-DB der neuen Installation wieder stoppen.
    sudo /opt/alfresco-community/alfresco.sh stop postgresql

Content-Store und Idexe restoren

Content-Store und Index habe ich auf einem NFS-Server.

  1. Wichtig, nicht das postgres-Datenverzeichnis der neuen Installation löschen!!!!!! Das ganze alf_data Verzeichnis der neuen Alfresco-Instanz nach ~/alf_data_backup verschieben. Dies, weil sich auch das postgres-Datenverzeichnis hier befindet. Die DB mit den Daten wird wegkopiert.
    sudo mv /opt/alfresco/alf_data ~/alf_data
  2. Jetzt den mount-Punkt „alf_data“ des NFS-Servers auf die neue Alfresco-Instanz mounten.
  3. Nun die postgres Daten wieder zurück kopieren
    sudo rm -r
    sudo cp ~/alf_data/postgresql/* /opt/alfresco/alf_data/postgresql/
  4. Reindexierung von SOLR4:
    Ich initialisiere Solr4 nach jeder Installation neu gem. Alfresco-Dokumentation: Link