Skip to end of metadata
Go to start of metadata

Wie ich in Unveröffentlicht ... schrieb, ist das Ziel hier folgendes: 

Ziel – Eine eigene Cloud. Und damit das später auch andere machen können, wird das dokumentiert. Zu Einsatz kommen sollen so Sachen wie OpenStack, Ansible, Docker und einiges mehr an OpenSouce.

Nachdem ich einiges gelernt und umgesetzt habe, bin ich über DebOps gestolpert. Bisher bin ich in Sachen ansible schick durch die Gegend gestolpert, und über das Intro von Working With Playbooks bin ich im Prinzip noch nicht hinaus. Vieles von dem was ich nach und nach erarbeiten wollte, wurde in DebOps schon umgesetzt. Nachdem ich DebOps philosophy gelesen habe, stand der Entschluss fest DebOps auszuprobieren!

Vorbereitungen

  • Ich entscheide mich für die Installation des stable-1.1 in einer python virtualenv wie in DebOps installation beschrieben. Ich entscheide mich für eine eigene VM bei Hetzner Online um den "Ansible Controller"  zu installieren: die kleinstmögliche Maschine ist mehr als ausreichend.  Auf ein verschlüsseltes Volume, verzichte ich ausnahmsweise noch.
  • Ich kümmere mich um ipv4 und ipv6 DNS und rDNS Einträge für die VM.
  • Ich lege einen lokalen user an:
    • useradd -m -s /bin/bash -r xxxx – dieser sollte übrigens incl. gecocs angelegt werden. Ist in debops.slapd aufgefallen.
    • ssh-keygen -t rsa -b 4096 – ausnahmsweise ohne passphrase
  • Ich folge den Anweisungen in DebOps installation, und zwar der Variante  „Installation in a virtualenv Python environment“:   
    1. sudo apt update
    2. sudo apt install build-essential python3-dev libffi-dev libssl-dev libsasl2-dev libldap2-dev python3-pip virtualenv

    3. virtualenv -p /usr/bin/python3 venv/debops
    4. source venv/debops/bin/activate
    5. pip3 install debops[ansible]
    6. venv/debops/bin setze ich in vorn in meinen $PATH ein

    7. debops-init d # initilaisiere ein Projekt im Verzeichnis „d“.
  • Ich folgende den Anweisungen in Getting Started with DebOps um den Host selbst auf Vordermann zu bringen:
    • habe den Ansible Controller in ansible/inventory/hosts auskommentiert, denn dort stand: 

      # Your host is eligible to be managed by DebOps' common playbook. If you want
      # that functionality and more, then uncomment your hostname below.
      
      [debops_all_hosts]
      ac ansible_host=ac.3ischn.de ansible_connection=local
    • ansible/inventory/group_vars/all/netbase.yml habe ich die domain eingetragen. (netbase__domain)
    • ansible/inventory/group_vars/all/sshd.yml habe ich ein paar Netze eingetragen. (sshd__whitelist)
  • Dann habe ich debops bootstrap --limit ac --user root sowie debops --limit ac laufen lassen.

Zwischenergebnis

Ich musste eingreifen, weil der lokale user xxxx nicht ohne Passwort sudoen konnte. Da ich oben eine python3-only Umgebung eingerichtet habe, wurde etckeeper nicht eingerichtet (siehe hier). Also erstmal auch python2 nachinstallieren: in ansible/inventory/hosts ein python__v2=True hinter den ac geschrieben, gefolgt von debops -l ac --tags role::python und dann debops -l ac --tags role::etckeeper und dann war das Ding auch installiert .

Es hat mich etwas Zeit gekostet, dass ich weiterhin von überall via ssh auf die Kiste kam, bis ich verstanden habe, das sshd__whitelist (siehe oben), halt eine whitelist ist, die verhindert, das die Adresse ausgeschlossen werden, z.B. via ratemit. Wenn Zugriff via ferm einschränkt werden soll, muss man sshd__allow, sshd__group_allow oder sshd__host_allow nutzen!

Versehentlich habe ich verschiede sshkeys via debops.system_users in die .ssh/authorized_keys des Ansible Controller Users eingetragen. Hintergrund ist, dass alle via ssh-agent übermittelten Identitäten ausgewertet werden. Meine Umgehungslösung ist dem ssh beim Verbinden zu untersagen: Ein ForwardAgent no an passender Stelle in $HOME/.ssh/config und fertig.

Mail geht dank debops.nullmailer auch. Noch nicht so wie es mir passt, aber das hatte ich in Base-Mail auch noch nicht geschafft (smile) ..

Ein Dokuwiki läuft auch schon. Fehlt nur noch das mit den Zertifikaten:

X.509 Zertifikate

Wie ich in letsencrypt.org -> getting-started schrieb, sind funktionierende Zertifikate für die Verschlüsselung der Kommunikation ein wichtiger Punkt für eine Cloud. Sehr sympatisch bei DebOps war mir daher, dass dieser Punkt sehr prominent am Anfang der Dokumentation steht:

Nachdem ich die Dokumentation von debops.pki aufmerksam durchgelesen habe, hab ich erstmal in ansible/inventory/group_vars/all/pki.yml folgendes eingetragen: 

pki_ca_domain: '{{ ansible_domain }}'
pki_ca_organization: '3IschN'
pki_ca_root_dn: [ 'o={{ pki_ca_organization }} Certificate Authority' ]
pki_ca_domain_dn: [ 'o={{ pki_ca_organization }}', 'ou=Domain CA' ]
pki_ca_service_dn: [ 'o={{ pki_ca_organization }}', 'ou=Internal Services CA' ]
pki_authorities:
  - '{{ pki_authorities_ca_root }}'
  - '{{ pki_authorities_ca_domain }}'
  - '{{ pki_authorities_ca_service }}'

Und in inventory/host_vars/ac/pki.yml steht:

pki_realms:
  - name: 'ac.3ischn.de'
    acme: True
    #acme_domains: []
    acme_default_subdomains: []
    #acme_subdomains: []
    #acme_subject: []
    #acme_ca: 'le-staging-v2'


Nachdem ich erst mit der Test-Instanz von let's encrypt getestet habe, habe ich die Zertifikate vom Server gelöscht und das Playbook nochmal laufen lassen. Nun ist ein schickes Zertifikat online.


Fertig!

Als nächstes ...

... will ich mal sehen, wie lange ich brauche um einen weiteren Host identisch aufzubauen.



  • No labels