Beiträge von jbr27

    Hallo an die Selfhoster!


    Ich finde in r/selfhosted nicht das was ich brauche. Ich suche eine, obviously, selbstgehostete Alternative zu M$ todo. Das Konzept von links einfache Listen und rechts die Aufgaben finde ich super. Keine Erinnerungen, keine "smarte" Sortierung oder sonstige Wünsche. Nice to haves immer gern gesehen. Mobilinterface sollte auch dabei sein (manche Mobilepages sehen aus wie Schwein). Sollte kein NodeJS Krams sein, eher LEMP Stack fähig. Kennt da jemand was?


    EDIT: Mit Dark Mode.

    Ich suche ebenfalls seit Jahren eine vernünftige (selbst gehostete) Lösung als Alternative für MS Todo (oder in meinem Fall für Todoist). Ich habe schon fast alle bestehenden Projekte ausprobiert und bin zu dem Entschluss gekommen, dass leider bisher keine Open Source Lösung an die Funktionalität (und das UI) von den kommerziellen Produkten herankommt.


    Mittlerweile habe ich aber mein Todoist-Premium gekündigt und setzte auf simple Aufgaben, die ich mittels einer Groupware-Lösung (mailcow, SoGo) auf meinen Geräten synchron halte.

    Leider ist das ja aber nicht für mich selber (sondern für eine eher technisch-unaffine Freundin) und auch nur einmalig vonnöten, hatte gehofft dass es eventuell eine einfache und schnelle Möglichkeit gibt. Falls sich die bis Mittwoch nicht finden lässt schau ich mir das mal genauer an! :)

    Die einfachste Möglichkeit wäre die Berechnung der Histogramme auf Grundlage der Rohdaten (siehe: https://de.wikipedia.org/wiki/Histogramm).

    Anschließend können die Daten dann mit jedem beliebigen Tool (Excel, Origin, LaTeX/PGFplots, Python/Matplotlib) dargestellt werden.

    [...]
    Warum greift man nicht auf ressourcensparsame Audiochats wie den guten alten TeamSpeak Server zurück? Läuft lokal auf dem Rechner oder per App auf dem Smartphone. Für Screensharing von einer oder zwei Parteien kann man dann ja immer noch auf andere Tools zurückgreifen.

    [...]

    Du wirst lachen - wir kommunizieren seit 2 Wochen nur noch über meinen Teamspeak-Server, den ich eigentlich vor Monaten schonmal offline nehmen wollte.


    Sogar eine Verteidigung einer Abschlussarbeit (wir sind ein Forschungsinstitut) wurde schon darauf durchgeführt.


    Bei Präsentationen (oder Screensharing) nutzen wir BigBlueButton nur für den Videostream. Der Ton läuft weiterhin über TeamSpeak, da wir subjektiv die Audioqualität besser finden.


    P.S. Animal Crossing New Horizons hat mich momentan auch im Griff :‘D.

    Vor 30 Minuten wurde ein weiterer Server von mir neugestartet (Zwischenstand: 2 von 6).


    Beides waren sanfte Shutdowns per ACPI. Die laufenden LXC-Container hatten genug Zeit um sauber herunterzufahren (nach 30-45 Sekunden hatten beide Server ihren Shutdown bereits abgeschlossen). Nach weiteren 20 Minuten wurden beide Server ohne Probleme wieder hochgefahren.


    Ich habe die Vermutung, dass die Server nach Preismodell oder Bestelldatum abgearbeitet werden. Nach meinem RS2000 (gestern Abend um 23 Uhr) wurde heute um 16 Uhr mein RS1000 neugestartet. Meine VPS10, VPS20, VPS50 usw. wurden noch nicht beachtet.

    Entweder beanspruche ich die plötzlich stärker, oder die mit neuem Logo halten weniger aus… :D


    Bei meiner Netcup-Tasse von der letzten Aktion an Ostern hatte ich nach einem Monat normaler Benutzung auch bereits den Henkel einzeln in der Hand :D. Habe leider keine alte Version der Tasse als Vergleich.

    Gesagt, getan. Heute angeschrieben und wenig später hat man mir schon geholfen. :thumbup:
    Nun liegen die Zugriffszeiten auf die Platte wieder im grünen Bereich.


    Ich habe gestern Abend ebenfalls mal den Support angeschrieben. Mir wurde mitgeteilt, dass keine Störung an meinem Node vorliegt, ich aber einmalig auf ein anderes System migriert werden könnte. Dieses habe ich aber abgelehnt, da ich den Fehler zuerst noch genauer analysieren will.


    Nunja, auf wundersame Weise hat sich die Disk-Latenz direkt nach meiner Korrespondenz mit dem Support drastisch verbessert und liegt nun wieder bei den Werten vor der Störung. Ich habe euch ein paar Munin-Graphen angehängt.


    Da der Support angeblich nichts gemacht hat, bin ich jetzt etwas verwundert ?(.

    Hol dir doch die 19 cent Krücke und bau da dein Monitoring hin und gut ist, meinet wegen kann ich mir auch die 2,49€ Kiste mieten und Check_Mk drauf schmeissen und dir einen Zugang geben. Alles besser als das was momentan bei dir läuft ;) Natürlich kannst du auch Felix seinen Rat folgen das Uneffiziente Zeug nehmen und auf Hardware schmeissen das Uneffizient schnell macht...
    https://www.netcup.de/bestellen/produkt.php?produkt=1539


    Vielen Dank für's Angebot! Habe selbst noch einen VPS50 von der damaligen Aktion, den ich momentan nur als sekundären Nameserver (keine Sorge ohne LXC und BTRFS) verwende. In der nächsten freien Zeit werde ich die Munin-Instanz darauf umziehen und schauen, ob er das noch zusätzlich packt.

    Mein zusätzliches Logging mit atop hat ebenfalls ein paar "Schuldige" hervorbringen können.


    Zuallererst muss ich Skulduggery Recht geben, dass der Treiber vermutlich nicht mit den LXC-Containern auf einem bereits virtualisierten Hostsystem zurecht kommt. Ebenfalls mit der Ausführung des Monitorings auf dem zu überwachenden Server, lag er richtig.
    Die hohe Disk-Latenz tritt ausschließlich dann auf, wenn alle LXC-Container (natürlich gleichzeitig :D) ihre Prozesse ausführen und dann noch zusätzlich die jeweiligen Graphen in einem weiteren Container erzeugt werden. Ja, nicht gerade schlau von mir gelöst, aber aus der Mangel an einem weiteren Server, zurzeit nicht anders möglich.
    Ebenfalls erzeugt Spamassassin während seines Trainings (sa-learn) eine recht hohe Festplattenauslastung.


    Zusammengefasst treten die Spitzen über den Tag verteilt vielleicht für 20-30 Minuten auf und Munin verschafft sich zu seinen Messzeitpunkten selbst eine hohe Disk-Latenz.

    • BTRFS als Dateisystem Unterbau verwenden
    • Ich klink mich raus.


    BTRFS läuft auf meinem Testsystem mit LXC-Containern seit einem halben Jahr ohne Probleme. Hätte ich jetzt hunderte an Kunden oder eine große Firma, würde ich sicherlich auch konservativer an die Sache herangehen. Für unser Familienunternehmen (< 10 Mitarbeiter) hält sich das Risiko (mit Backups) in Grenzen.


    Hätte ich jetzt bereits BTRFS auf dem Produktivsystem, wären die Container schon längst auf einen neuen Server migriert und das Problem damit behoben.

    Falls einer mir einen trifftigen Grund nennen kann, sowas machen zu wollen mit wohlgemerkt produktiven Zeug, dann lasse ich mich da gerne eines besseren belehren.


    Auf meinem Server laufen zurzeit jeweils in einem einzelnen LXC-Container:
    - DNS (bind)
    - Git (gogs)
    - Mail (Mailcow (dovecot, postfix, nginx, php5-fpm))
    - munin
    - sharelatex (docker, mongodb, redis-server)
    - GPS-Tracking für Flottenmanagement (traccar)
    - web (nginx, php7.0-fpm, mysql-server)


    Für jeden Container sind nur die benötigten Ports per iptables freigeben. Die Kommunikation untereinander erfolgt in einem internen Netz.
    Für die Zukunft ist noch der Umstieg auf BTRFS geplant, womit die Container besser schneller gesichert werden können.
    Bei kritischen Updates kann der Container geklont oder ein Snapshot angelegt werden. Läuft etwas schief, kann ohne merkliche Downtime alles zurückgespielt werden.


    Wenn BTRFS jeweils auf dem Haupt- und Backupsystem vorhanden ist, können die Container in Sekunden umgezogen werden (Wartungsarbeiten, neuer Server, usw.)


    Zumindest für meine Bedürfnisse habe ich mit meinem Lösungsweg bisher nur gute Erfahrungen sammeln können. Schöner wären natürlich einzelne vServer oder ein richtiger dedizierter Server. Das alles würde aber deutlich mehr als 12,99€ im Monat kosten.

    Nochmal zurück zum eigentlichen Thema:


    Eine Defragmentierung hat leider auch keine Verbesserung der Disk Latency bewirkt. Zur Zeit logge ich mit atop mal alle Prozesse mit, habe aber zu den "Spitzenzeiten" noch keinen Schuldigen gefunden.
    Da es ein Produktivsystem ist, kann ich leider erst nächstes Wochenende nachts mal das Rettungssystem booten und die Disk Latency überprüfen.

    Ich habe seit dem 19. November ähnliche Probleme mit meinem Server (RS2000 G7 SE). Ohne irgendetwas verändert zu haben, hat sich die Disk Latency drastisch erhöht. Auch ein Neustart oder das Stoppen aller LXC-Container hat zu keiner Verbesserung geführt. Wahrscheinlich beansprucht ab dem 19. November ein anderer Kunde sehr viel "Festplattenleistung" auf dem Node. Ich beobachte dieses Verhalten noch eine Weile. Momentan sind mir noch keine längeren Ladezeiten für meine Anwendungen aufgefallen. Daher sieht es nur auf dem Papier besorgniserregend aus.


    Anbei mal einige Munin-Diagramme von meinem betroffenen System.