Hey,
da ich meine vServer per nagios überwache, wäre es hilfreich zu erfahren wenn es größere Updates gibt. Auf reiner linux-Ebene funktioniert das ja problemlos (apt), aber für mailcow?
Bislang prüfe ich unregelmäßig via ssh und /update.sh, ob sich da was getan hat. Aber selbst dann weiß man vorher nie, wieviele Änderungen anstehen. Heute z.B. massenhaft.
Gibt es da eine Möglichkeit das vorher abzufragen (apt bietet ja z.B. die Möglichkeit abzufragen was zu aktualiseren wäre)?

Und wenn, wäre es möglich, z.B. wöchentlich nachts ein automatisches Update fahren zu lassen? Hat das schonmal praktisch realisiert?

Vielen Dank

Frank

  • Ich kann das auch nur 1:1 so wiederholen. Updates automatisch durchzuführen hat überall die gleichen Nebenwirkungen. Eine Garantie dafür, dass alles durchlief, kann dir nur der Output des Updates geben. Meiner Meinung nach nicht empfohlen, aber möglich.

    Updates: Commits durchschauen, mailcow.email lesen. Am besten das Repo “watchen”/abonnieren.

    Wenn du immer nur garantiert stabile Updates haben möchtest, solltest du den Weg des offiziellen Supports gehen und dich dort informieren lassen, ob es derzeit kritische Änderungen gibt/gab oder das Update durch uns ausführen lassen. Der “master” Branch ist zwar in der Regel stabil. Es gibt jedoch Zeiten, in denen wir größere Änderungen pushen und dann dazu raten zu abzuwarten. Wir freuen uns trotzdem sehr, wenn der Code von vielen frühst-möglich gegengeprüft wird.

    \o/

Have something to say?

Join the community by quickly registering to participate in this discussion. We'd like to see you joining our great moo-community!

ach ja,
ich liebe diese Forumsantworten. Man stell eine konkrete fachliche Frage und bekommt persönliche Meinungen um die Ohren gehauen.
Du kannst Deine Reputation bei mir noch retten, wenn Du mir zumindest einen Hinweis gibst wie ich mit nagios via github aktuelle Neuerungen zum Iststand abfrage.

Zum Thema automatische Updates hast Du anscheinend nichts beizutragen. Warum antwortest Du dann überhaupt? Geltungssucht?

Sorry, wenn ich bissel überreagiere. Aber diese Rechhaberei kotzt mich an.
ciao Frank

  • MAGIC

    • Forum Staff
    • volunteer
    Moolevel 48
  • Post #4
  • This post is in German

Hallo,

ansich hat pkernstock schon recht, dass automatische Updates etwas kaputt machen können. Habe allerdings bei mir noch nie so richtig geschaut was verändert worden ist bevor ich geupdated habe, und bis jetzt ist auch noch nix kaputt gegangen.
Du kannst allerdings etwas mit git diff <masterbranch_path> <remotebranch_path> basteln und dann dein lokales repo mit dem auf GitHub vergleichen. Bin mir aber nicht sicher ob und wie Nagios das kann.

    • diekuh

      • Community Hero
      • volunteer
      Moolevel 110
    • Post #5
    • This post is in German
    • Best Answerset by diekuh

    Ich kann das auch nur 1:1 so wiederholen. Updates automatisch durchzuführen hat überall die gleichen Nebenwirkungen. Eine Garantie dafür, dass alles durchlief, kann dir nur der Output des Updates geben. Meiner Meinung nach nicht empfohlen, aber möglich.

    Updates: Commits durchschauen, mailcow.email lesen. Am besten das Repo “watchen”/abonnieren.

    Wenn du immer nur garantiert stabile Updates haben möchtest, solltest du den Weg des offiziellen Supports gehen und dich dort informieren lassen, ob es derzeit kritische Änderungen gibt/gab oder das Update durch uns ausführen lassen. Der “master” Branch ist zwar in der Regel stabil. Es gibt jedoch Zeiten, in denen wir größere Änderungen pushen und dann dazu raten zu abzuwarten. Wir freuen uns trotzdem sehr, wenn der Code von vielen frühst-möglich gegengeprüft wird.

    \o/

      Das Thema interessiert mich auch. Das heißt also, wenn ich nicht ständig nachschauen möchte, muss ich das Repo watchen. Dann bekomme ich doch aber jeden Commit mit und muss selbst entscheiden, wann ich update. Das kann doch nicht so gemeint sein, oder?! Ich weiß doch gar nicht, an was ihr da gerade arbeitet, ob das schon fertig implementiert ist usw.

      Warum denn nicht einfach in Github Releases machen? Dann könnt ihr der Community signalisieren, dass ihr “fertig” seid, und man muss nicht auf gut Glück updaten und jeden einzelnen Commit mitverfolgen.

      • diekuh

        • Community Hero
        • volunteer
        Moolevel 110
      • Post #7
      • This post is in German

      Es ist ein Rolling Release. Wir pushen nicht unstable ins Repo. Was ich meinte, sind frische Änderungen, die eventuell noch Fehler beinhalten könnten. Könnten.

      Was sollen wir denn noch machen, als alles kostenfrei zu Verfügung zu stellen? Kostenfrei und komplett quell-offen. Irgendwo hat der Spaß auch seine Grenzen.

      Selbes “Problem” hast du auch bei Releases. Neue Features, neue Probleme.

      In den Issues auf GitHub werden die Fehler meist Minuten nach dem Push reportet.

      • diekuh

        • Community Hero
        • volunteer
        Moolevel 110
      • Post #8
      • This post is in German

      Das mit dem “auf gut Glück” ist daher Unsinn. Das möchte ich hiermit nochmal ganz klar betonen…

      Hmm aber du schreibst doch selbst, dass man „garantiert stabile Updates“ nur über ein Support-Paket bekommt. Oder darunter:

      diekuh Der “master” Branch ist zwar in der Regel stabil. Es gibt jedoch Zeiten, in denen wir größere Änderungen pushen und dann dazu raten zu abzuwarten. Wir freuen uns trotzdem sehr, wenn der Code von vielen frühst-möglich gegengeprüft wird.

      „In der Regel“ klingt für mich schon irgendwie ein bisschen nach „auf gut Glück“. Ich verstehe das ja, natürlich möchtet ihr Support-Pakete verkaufen ;-) Und kostenlose Tester sind auch immer nice.
      Es hat schon aber auch seinen Grund, dass die meisten quelloffenen, kostenfreien Server-Distros in den Stable-Branches eben nicht auf ein reines Rolling Release setzen. Und ich hätte schon gerne, dass eine kritische Anwendung wie ein Mailserver rund läuft. Features brauche ich da nicht alle paar Wochen, sondern Stabilität. Kostenlos und quelloffen hin oder her.

        • diekuh

          • Community Hero
          • volunteer
          Moolevel 110
        • Post #10
        • Edited
        • This post is in German

        Ich mache das nicht, um Support-Pakete zu verkaufen. Ich gebe schon mein Bestes, dass dort kein Unsinn im Repo landet.
        Aber soll ich jetzt auch noch eine Garantie geben, dass der Branch immer zu 100% stable ist?

        Das passiert bei Releases genauso, also verstehe ich den Sinn nicht so ganz.

        Ich finde es schon anmaßend zu schreiben, dass ich Support-Pakete verkaufen möchte und deshalb nicht so genau hinschaue, was in “master” landet. 😉

        Wenn du jemanden brauchst, der dir eine Garantie gibt, dass der Mailserver läuft, dann ist das eine Dienstleistung dieser Person.

        Ergo: Die mailcow läuft stabil, auch als Rolling-Release. Automatische Updates sind immer gefährlich. Immer. Zuletzt hat es mir mein Windows (ja, ich benutze Windows, Schande über mich) zersäbelt, weil es sich automatisch aktualisiert hat. Ich habe nicht bei Microsoft angerufen und mich beschwert, warum die Releases nicht stabil sind. Shit happens. Bei Microsoft, SAP, Boeing, Oracle und - in gleicher Größenordnung, selbstverständlich - auch bei einer mailcow.
        Kritische Fehler im Repo sind meist MINUTEN im Repo, bis sie gefixt sind. Ich finde das enorm. Die Community funktioniert fantastisch, dafür bin ich sehr dankbar.

        @DONARfr
        Mal im Ernst - es ist verdammt gute Software. Es ist und bleibt aber Software, die von Menschen erstellt wird - ja, federfuehrend ist hier @diekuh, richtig. Aber auch Andere sind an der Software beteiligt. Menschen machen Fehler, das ist voellig normal. Fehler werden und wurden aber immer umgehend behoben, kurz nach dem der jeweilige Fehler gemeldet wurde - so war es und so bleibt es auch. Ich kenne @diekuh sehr sehr gut, privat. Ich weiss, wie sehr er fuer seine Sache brennt - und wie sehr es ihn fuxt, wenn mal was schief laeuft.

        In Sachen Support-Pakete: Hat ein Kunde ein wie auch immer geartetes Interesse, dass sein Mailserver unter Wartung steht und immer den direkten Draht zu den Experten hat, so muss man halt ein Support-Paket kaufen. So ist das nun mal - schon mal bei MS versucht anzurufen ohne dort wirklich einen Vertrag mit denen zu haben? Viel Spass!

        Und mal auf Boeing geschaut - die haben sich Bugs in einer Software geleistet - ja, passiert. Bei denen hat das aber massive Auswirkungen auf das weitere Leben (oder auch nicht Leben) von Menschen. Du willst doch hier nun niemanden erzaehlen, dass Dein vmtl. privater Mailserver mit dem Leben von Menschen auf einer Stufe oder gar darueber steht - oder?! Wenn Du ihn nicht privat einsetzt und nicht dafuer zahlen moechtest - das ist fein! Aber wenn man mehr Ansprueche stellt, muss man sich halt den Dienstleister einkaufen. Ist doch auch ganz normal.

        Diese “Geiz ist geil”-Mentalitaet ist ein Unding unserer Gesellschaft - und im Bereich IT und vorallem OpenSource tritt diese Mentaelitaet noch mehr zu Tage. Da sollten mal Alle drueber nachdenken.

        Keine Ahnung ob @tkorves jetzt mich angesprochen hat, ich vermute es aber mal. Also: Ich habe weder von Boeing, Microsoft o.ä. geredet. Ich habe auch nicht gesagt, dass ich kostenlose Wartung oder Support haben möchte. Von Geiz ist geil kannst du also nicht reden.

        Alles, was ich mir wünschen würde, ist ein etwas strukturierteres Release-System. Schau doch mal ins Github rein, z.B. den Commit mailcow/mailcow-dockerized20e289c. Wenn ich jetzt als Admin die Commits verfolge, wüsste ich nur, dass jemand nen “stupid mistake” gefixt hat. Ich weiß weder, was der Fehler ist, noch ob er mich betrifft. Muss ich jetzt also updaten? Ist der Fehler am Ende kritisch? Ich glaube nicht, dass ich damit “Ansprüche stelle”, die soo ungewöhnlich sind - selbst im Open-Source-Bereich.

        Und an @diekuh: Ich habe nicht gesagt, dass du nicht genau hinschaust. Ich glaube dir sogar, dass du das gut machst. Genau deshalb habe ich für meine private Mailcow auch mehrere stay-awesome-Lizenzen erworben. Für einen seriöseren Einsatz ist mir das aber ehrlich gesagt zu frickelig. Ich möchte bei einem Mailserver nicht Commits lesen und verstehen müssen. Und wenn ich ein Support-Paket kaufen muss, um das nicht zu müssen, dann kann ich auch gleich zu einem Profi gehen, der mir dann gleich alles abnimmt. Teurer wäre das definitiv nicht.

        Und falls das Argument gegen einen strukturierteren Release die fehlende Manpower ist, dann unterstützt das leider nur mein mulmiges Gefühl bei der Sache. Ich kenne zu viele One-Man-Shows im Open-Source-Bereich, die genau wegen sowas von heute auf morgen untergegangen sind.

        • diekuh

          • Community Hero
          • volunteer
          Moolevel 110
        • Post #13
        • This post is in German

        Der IT’ler, der für 29 € brutto im Monat arbeitet: Schickst du ihn mir? Den stelle ich direkt ein.

        Nein, ernsthaft. Du musst keinen Support kaufen und es ist kein Gefrickel, lass bitte diese Unterstellungen. Der master Branch ist stable und der “stupid mistake” wäre in einem Release genauso drin gewesen. Verstehst du das?
        Releases können genauso Fehler enthalten, das ist einfach kein korrekter Standpunkt. Es ist einfach das, was du möchtest, weil du es kennst, glaube ich. 🙂

        Kannst dich ja einbringen, dann ist es noch eine Person mehr, die an mailcow arbeitet. 😉 Ich glaube nicht, dass wir untergehen, weil wir dir keine Releases auf den Tisch legen, auch wenn du unbedingt möchtest. mailcow ist weiterhin stable im master branch, so sehr dich diese Aussage auch zu triggern scheint. Es wird auch nicht untergehen. Die Funktionen werden immer mehr, die Contributer und Supporter ebenfalls. Die Community wächst und die Kuh wird immer stabiler. Geht genau in die andere Richtung. 😉

        Würden wir Releases einführen, gäbe es keine Änderung. Es wäre genau der gleiche Code, der gepusht wird. Die gleichen Fehler. Es würde Sub-Releases geben, um die Fehler vom vorherigen Release zu patchen. Einfach nicht der Weg, den wir mit mailcow gehen.

        Sorry, das war schlecht ausgedrückt. Nen ITler bekommt man natürlich nicht für 29€ (zumindest keinen, den man haben will). Aber ein gutes Mailhosting schon. Auch aus DE und mit gutem Track-Record.

        Ich glaube, du bist getriggert, nicht ich. Ich sage doch nicht, dass sowas wie der “stupid mistake” nicht passieren darf. Darf und tut es selbstverständlich! Ich möchte nur nicht selbst entscheiden müssen, ob jeder Commit für mich relevant ist und ob ich updaten muss oder nicht. Also warum dann nicht einfach Releases machen, wenn es für den normalen Mailcow-User was zu tun gibt? Ist doch nicht so schwer, oder?

        Aber du bist hier der Boss, es ist dein Produkt. Das respektiere ich, aber mitarbeiten möchte ich da bitte nicht (bist du vielleicht auch ganz froh drum, oder?). Für nen simplen Mailserver wäre mir das zu stressig. Dann mal noch viel Erfolg und viel Spaß damit 👍

        Hallo,
        irgendwie ist die Diskussion in eine Richtung abgedriftet, der ich nicht folgen möchte. Irgendwelche Kritik am Entwickler war absolut nicht mein Ziel.
        Vlcht. um mein Ansinnen nochmal besser zu erklären:
        Ich bin bei Linux old school, mit dem Docker-Zeugs kann ich mich nicht so richtig anfreunden. Muss ich vlcht. auch in meinem Alter nicht mehr. Bislang habe ich via apt check eine Mail bekommen wenn Updates bereitstehen und konnte selbst entscheiden wie kritisch die sind. So habe ich meinen alten Mailserver (mit altem mailcow) immer sehr aktuell gehalten.
        Wenn ich jetzt update.sh aufrufe, weiß ich vorher weder wie umfangreich die Änderungen sind (also welche Komponenten), und auch den Erfolg (Misserfolg hatte ich noch nicht, insofern also Lob an den Entwickler) sehe ich erst hinterher. Angesichts dessen halte ich für meinen Teil (jeder mag das für sich anders beurteilen) das Risiko eines missglückten Updates relativ gering. Wenn es schief ging, merke ich das dann schon… Zumal der Server regelmäßig via duplicity nach HiDrive gesichert wird.
        Grundsätzlich bin ich auch skeptisch was automatische Tasks angeht (z.B. shutdown/restart bei DB-Backups), aber ich möchte das nicht pauschal verurteilen wie manche hier meinen mitteilen zu müssen. Muss man halt jeweils einschätzen.
        Ich habe mir das Update-Script noch nicht angeschaut. Vlcht. kann man das so abändern, dass es einen ausführlicheren Testmodus gibt, der vorher ausgibt was passieren würde. Muss ich mich vlcht doch noch weiter mit dem Docker Thema beschäftigen.
        Danke und close.
        Frank.

        MAGIC locked the discussion .

        • MAGIC

          • Forum Staff
          • volunteer
          Moolevel 48
        • Post #17

        closed by request

        No one is typing