Archiv der Kategorie: Server Configuration

von Owncloud zu Nextcloud

Veröffentlicht am von
Antworten

Nur ganz kurz, weil es so einfach war… Anlässlich dieses Tweets

habe ich heute mal die Migration von Owncloud zu Nextcloud getestet. Im Blog Beitrag von Novatrend wird auf diese Help Seite von Nextcloud verwiesen. Die Anleitung da habe ich dann auch befolgt:

  1. Backup Config (nur zur Sicherheit)
  2. Alles ausser dem Config und Data Ordner löschen
  3. Nextcloud herunterladen und entpacken
  4. Update via Webbrowser oder OCC starten

That’s it, hat bei mir auf Anhieb geklappt, ich musste einzig ein paar Custom Plugins wieder aktivieren. Data Order war in meiner Installation sowieso an einem anderen Ort und daher im Config File angepasst, deshalb musste ich den original Data Ordner auch nicht beachten.

Was ich allerdings noch nicht weiss, ob ich zukünftig auf Nextcloud oder Owncloud setzen soll? Was denkt Ihr? Meine zweite Owncloud Installation lasse ich mal vorläufig noch und berichte dann später Mal, wie ich mich da entschieden habe.

Let’s Encrypt mit Reverse Proxy

Veröffentlicht am von
Antworten

Ihr kennt sicher Let’s Encrypt? Für einen Web Server in meinem Betrieb habe ich kürzlich eine Domain mit einem Let’s Encrypt Zertifikat ausgestattet. Der Web Server läuft bei uns via ein NGINX Reverse Proxy welcher alle Anfragen an einen internen Server weiterleitet. Damit die Let’s Encrypt Zertifikate erstellt werden können, muss folgendes beachtet werden:

Während der Zertifikat Erstellung prüft Let’s Encrypt, dass uns die Domain wirklich gehört, indem diverse Files auf dem Web-Server abgelegt werden, welche dann von Let’s Encrypt abgerufen und geprüft werden. Für genaue Details schaut euch doch mal diesen Beitrag an. Die Let’s Encrypt Zertifikate sind bei uns auf dem Reverse Proxy abgelegt, Verbindung zum Backend Server ist dann über ein Self-Signed Zertifikat gesichert. Damit die Let’s Encrypt Validierung funktioniert, dürfen nicht alle Anfragen an den Backend Server weitergeleitet werden. Mit der folgenden NGINX Konfiguration konnte ich die Let’s Encrypt Zertifikate ausstellen:

server {
 listen ipv4_address:80;
 listen [ipv6_address]:80;
 server_name domainname.tld www.domainname.tld

location /.well-known {
 root /var/www/html;
 }


 location / {

rewrite ^ https://$server_name$request_uri? permanent;
 }
}

Man beachte die /.well-known Location Directive welche für Let’s Encrypt verwendet wird. Darin werden die zu prüfenden Files für Let’s Encrypt abgelegt. (Siehe Let’s Encrypt Dokumentation)

Das Zertifikat wird dann mit:

./letsencrypt-auto certonly --webroot -w /var/www/html -d domainame.tld -d www.domainname.tld

erstellt.

Let’s Encrypt bietet alternativ auch ein Standalone Mode an, dafür muss aber kurzzeitig der bestehende NGINX Reverse Proxy gestoppt werden (deshalb habe ich das bei uns nicht so gelöst)

NGINX Cluster mit corosync + pacemaker

Veröffentlicht am von
Antworten

Für einen Reverse Proxy basierend auf NGINX habe ich kürzlich ein Cluster mit corosync und pacemaker erstellt. Das Setup läuft auf einem Ubuntu Server 14.04 LTS mit 2 Nodes.

Zuerst muss auf beiden Nodes corosync und pacemaker installiert werden:

apt-get install corosync pacemaker

Bei corosync habe ich mich für UDP Unicast Transport entschieden, möglich wäre auch ein Multicast Setup. Dazu habe ich die corosync Konfiguration wie folgt angepasst:

totem {
[...]
        crypto_cipher: none
        crypto_hash: none
        interface {
                # The following values need to be set based on your environment
                ringnumber: 0
                bindnetaddr: {ip des aktuellen Node}
                mcastport: 5405
        }
        transport: udpu
}
nodelist {
        node {
                ring0_addr:{ip oder hostname Node 1}
                nodeid: 1
        }
        node {
                ring0_addr: {ip oder hostname Node 2}
                nodeid: 2
        }
}
quorum {
        provider: corosync_votequorum
        two_node: 1
}

[...]

Anschliessend muss corosync und pacemaker auf beiden Nodes gestartet werden:

service corosync start
service pacemaker start

und dann kann mit crm_mon der Status des Clusters überprüft werden.

Last updated: Fri May 29 14:12:26 2015
Last change: Fri May 29 08:53:56 2015 via crm_resource on rproxy-node1

Stack: corosync
Current DC: rproxy-node1 (1) - partition with quorum
Version: 1.1.10-42f2063

2 Nodes configured

Online: [ rproxy-node1 rproxy-node2 ]

mit crm configure können dann entsprechend Ressourcen erstellt werden. In meinem Beispiel habe ich je eine IPv4 und eine IPv6 Ressource erstellt

primitive res_ipv6 ocf:heartbeat:IPv6addr params ipv6addr="{ipv6_addr}" cidr_netmask="{cidr_netmask}" nic="{nic}"

primitive res_ip ocf:heartbeat:IPaddr2 params ip="{ipv4_addr}" cidr_netmask="{cidr_netmask" nic="{nic}"

nach commit sind dann auf einem der beiden Nodes die VIP’s zugewiesen:

Last updated: Fri May 29 14:24:05 2015
Last change: Fri May 29 08:53:56 2015 via crm_resource on rproxy-node1
Stack: corosync
Current DC: rproxy-node1 (1) - partition with quorum
Version: 1.1.10-42f2063
2 Nodes configured
2 Resources configured

Online: [ rproxy-node1 rproxy-node2 ]
 Resource Group: rg_export
     res_ip     (ocf::heartbeat:IPaddr2):       Started rproxy-node1 
     res_ipv6   (ocf::heartbeat:IPv6addr):      Started rproxy-node1

Hier im Beispiel habe ich noch eine Resource Group erstellt, damit die beiden Ressourcen zusammen migriert werden, falls ein Node ausfällt.

Wichtig für die Konfiguration von nginx, damit auf eine nicht vorhandene (die IP ist nur auf dem aktuellen Node vorhanden) IPv4 Adresse gebinded werden kann muss:

net.ipv4.ip_nonlocal_bind=1

gesetzt werden werden. Die IPv6 VIP kann einfach auf den loopback Interface konfiguriert werden.

Man könnte einen NGINX auch direkt als Ressource definieren, ich hab das aber vorläufig mal nicht so gemacht sondern starte den NGINX Server normal als Service in Ubuntu:

service nginx start