Beiträge von a_kemper

    Wir hatten kürzlich Mitgliederversammlung in unserem Sportverein mit rund 70 aktiven Teilnehmern.


    Zum Einsatz kam ein VPS 4000 G9 mit vorkonfiguriertem Debian Buster Jitsi Image. Das ist prinzipiell sofort einsatzbereit, entsprechend der Anleitung sollte im Wesentlichen noch ein LetsEncrypt-Zertifikat generiert werden.

    Um OpenSlides installieren zu können werden auf dem Server zusätzlich mindestens noch die Pakete git, docker.io und docker-compose benötigt. Zudem sollte postfix installiert werden, um einfach Mails aus OpenSlides versenden zu können. Ferner bietet sich eine zusätzliche (Sub-) Domain, etwa openslides.<mein-verein>.de, für die Veranstaltungssoftware an. Entsprechend wird später in dem durch Jitsi ohnehin installierten Nginx ein ReverseProxy-Eintrag für diese zusätzliche Domain auf den aktiven Port des localhost angelegt und ebenfalls via LetsEncrypt-Zertifikat abgesichert.

    Zuvor müssen in der docker-compose.yml noch eine Handvoll Einträge zur Konfiguration gemacht und anschließend die OpenSlides Container deployed werden. Sollen Mails mit den Zugangsdaten der Teilnehmer versendet werden, ist es zudem notwendig Postfix lokales Docker Subnet zu mynetworks in der Postfix main.cfg auf dem Host hinzuzufügen. Empfehlenswert resp. notwendig ist es noch Postfix auf dem Host robust ggü. einer möglichen Spamklassifikation der versendeten Mails zu machen. Eine aktuelle Anleitung findet sich dazu u.a. im Blog von Thomas Leister.


    Insgesamt lief das System sehr gut bei einer moderaten Auslastung des Servers. Jitsi lieferte dabei vorrangig die Plattform für die Audiokonferenz, wobei zusätzlich nur der jeweils aktive Sprecher ein 720p-Videobild gestreamt hat.

    Da der Snapshot Export bei einer gut gefüllten HD nicht funktioniert und ich leider auch keine (Offline-) Möglichkeit kenne das komplette QCOW-Image auf dem FTP-Server zu sichern, habe ich nach einer Alternative zum temporären Zwischenspeichern der Partitionen gesucht.

    Empfehlenswert ist es hierzu das Rettungssystem zu verwenden, da hier bereits ein vorkonfigurierter SSH-Zugang enthalten ist. Zudem braucht man das Paket NcFTP. Darin enthalten sind die Binaries "ncftpput" resp. "ncftpget". Nach dem lokalen Entpacken in GRML kann man exemplarisch wie folgt einzelne Partitionen, alternativ die komplette virtuelle HD, sichern:


    dd if=/dev/sda3 bs=1M | ./ncftpput -c -u xxx -p yyy 46.38.225.190 image/sda3.raw


    Anschließend sollte mit einem


    md5sum /dev/sda3


    sowie einem


    ./ncftpget -c -u xxx -p yyy 46.38.225.190 image/sda3.raw | md5sum


    geprüft werden, ob der Upload korrekt und vollständig war.


    Die Datenrate für den Up- und Download lag bei einem aktuellen vServer exemplarisch jeweils bei gut 50 MB/s.


    Grüße

    Andreas

    Ich werde das in den kommenden Tagen mal weiter beobachten. Ein kurzer Test mit den auf https://www.lifewire.com/free-and-public-dns-servers-2626062 gelisteten DNS ergab, dass die Mehrzahl meine beiden *.net Domains auflösen kann. Neben Google haben inbesondere jedoch die DNS von Verisign und Cloudfare ebenfalls eine leere Antwort ohne IP(v4) mit dig geliefert. Dabei frage ich mich, ob es da ggf. einen Zusammenhang zum DeCIX-Ausfall in der letzten Nacht gibt.

    Ich habe da tatsächlich zwei Dinge vermischt, wobei ich mich mit der ganzen Thematik am Wochenende erstmalig genauer beschäftigt hatte.


    Zumindest primär ging es mir um den ersten Teil der Frage. Konkret also, wie ich die zu meinen Letsencrypt-Zertifikaten gehörenden TLSA-Records in den NetCup DNS automatisch aktualisieren könnte. Analog zu dem Haken zum Aktivieren von DNSSEC hatte ich gehofft z.B. eine CLI für den automatisierten Upload zu finden. Soweit ich das bislang sehe würde das aber nur mit einem selbst gehosteten DNS-Paar funktionieren.


    Die Aktualisierung der nächsthöheren Ebene hatte ich bislang gar nicht auf dem Schirm, sondern war einfach davon ausgegangen, dass der TLSA-Record wie auch die anderen Einträge automatisch propagiert werden.


    Grüße,
    Andreas

    Hallo,


    nach der tollen Anleitung zum Erstellen / Einpflegen entsprechender DNS-Keys würde ich gerne wissen, ob / wann es ggf. eine Möglichkeit gibt die betreffenden DNS-Records auch automatisch zu aktualisieren?


    Grüße,
    Andreas

    Hallo zusammen,


    ich habe kürzlich meinem vServer mit Ubuntu 14.04 zusätzlich eine statische IPv6-Adresse gegeben, so wie das hier im Wiki beschrieben wird. Die IPv4 bezieht der Server dabei nach wie vor via DHCP.


    Mein Problem ist nun, dass mit dem Aktivieren der IPv6 beim Booten im kurzen Abstand zwei dhclient Prozesse gestartet werden. Das hat zwar keine direkt erkennbaren Auswirkungen auf die Adressvergabe für eth0, jedoch stört sich zumindst chkrootkit an diesem doppelten Prozess mit exakt gleichen Aufrufparametern.


    Kann mir jemand sagen wie ich diesen redundanten Aufruf verhindern kann? Ich nehme an das dieses Verhalten nicht normal ist.


    Besten Dank,
    Andreas

    So, ich habe mein Problem zwischenzeitlich gelöst und die Sache sieht wie folgt aus:


    * Eine automatische Anpassung der Imagegröße durch den VCP beim Ex- oder Import erfolgt nicht
    * Das persönliche Verzeichnis auf dem FTP-Server kann leider nicht via NFS im vServer gemountet werden


    Die Vorgehensweise ist demnach wie folgt:


    1. QCOW2 Image nach dem Defragmentieren und Herunterfahren des Servers auf den FTP-Server kopieren. Der Snapshot wird dabei zunächst in dem Diskimage angelegt, d.h. man darf weniger als die Hälfte der virtuellen Platte tatsächlich belegt haben. Der Transfer vom/zum FTP-Server erfolgt mit rund 80 MByte/s.
    2. Den neuen Server mit der Standardinstallation booten und "qemu" (nach-) installieren. Anschließend das Image vom FTP-Server auf den neuen (größeren) Server kopieren und mit "qemu-img resize" entsprechend vergrößern. Es darf dabei nicht größer sein als das vom neuen vServer festgelegte Limit und es muss zudem ein Vielfaches der Blockgröße (512 Bytes) sein.
    3. Die äußerlich praktisch unveränderte Datei zurück auf den FTP-Server kopieren.
    4. Den neuen Server mit dem neuen Image vom FTP-Server installieren.

    Hallo,


    ich möchte in den kommenden Tagen ein Sidegrade von meinem bisherigen vServer mit 100GB HD auf den aktuellen vServer mit 240GB HD machen. Geplant ist dabei das QCOW2 HD-Image auf den FTP-Server zu exportieren und anschließend auf dem neuen vServer zu importieren.


    Wie kann ich dabei die Größe des QCOW2-Image an den neuen Server anpassen?


    Folgende Möglichkeiten sind mir in den Sinn gekommen, wobei ich gerne wüsste, wie dies tatsächlich läuft bzw. realisiert werden kann:


    1.) Während des Import im VCP wird automatisch die Imagedatei an die Größe des jeweiligen Server angepasst
    2.) Nach dem Booten des Rettungssystems kann ich die auf dem FTP-Server liegende Image-Datei via NFS-Share mounten und dann im Rettungssystem selbst ein "qemu-img resize" ausführen?
    3.) Die Größenänderung kann nur der Kundensupport durchführen?


    Falls Option (2) zutrifft, was sind IP/Pfad/Credentials fuer den NFS-Server und wie groß darf/muss die Imagedatei letztlich genau sein?


    Besten Dank,
    Andreas