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

 

Dualboot System mit Ubuntu und Windows – Zeit nicht korrekt

Auf meinen Dualboot-System ist Ubuntu und Windows installiert.

Die beiden Betriebssysteme interpretieren die Hardware-Clock nicht gleich. Linux interpretiert die Hardware-Clock als UTC. Windows aber als “Local-Time”. Daraus resultiert, dass in dem einen Betriebssystem die Zeit korrekt gesetzt wird und im anderen falsch angezeigt wird.

Ich korrigiere dies, indem ich Ubuntu beibringe die Local-Zime zu verwenden:

  1. Im Bios die HW-Clock auf die aktuelle Local-Zeit einstellen
  2. Dann im Linux die Local-Zeit konfigurieren
    sudo timedatectl set-local-rtc 1

Man könnte dies auch so korrigieren, indem man Windows beibringt, die UTC zu verwenden. Aber umständlicher als die Korrektur über Linux.

Links

https://askubuntu.com/questions/169376/clock-time-is-off-on-dual-boot

test

Ubuntu 18.4: Default Klang-Wiedergabegerät setzen

Mein Ubuntu setzt nach einem Reboot immer das falsche Klang-Wiedergabegerät. Das Default Wiedergabegerät kann folgendermassen gesetzt werden, so dass es auch nach einem Reboot noch gesetzt ist:

Als erstes die vorhandenen Wiedergabegeräte auflisten:

pacmd list-sinks

Dies listet die “Indexe” der Wiedergabegeräte auf. Der mit * markierte Index ist das aktuell als Default gesetzte Wiedergabegerät.

Nun den Index des gewünschten Default Wiedergabegerätes merken (bei mir ist es die “2”) und eintragen in

sudo vi /etc/pulse/default.pa
### Make some devices default
set-default-sink 2

Nach einem Reboot ist das Wiedergabegerät Nr. 2 automatisch gesetzt.

Links

https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/DefaultDevice/

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