Afox Posted June 29, 2019 Posted June 29, 2019 hi, wollte mal fragen ob es bereits Planungen zu einem Buster Release gibt, also ob es nach dem Erscheinen am 06.07.2019 mit Froxlor-Paketen zu rechnen ist bzw. wie lange es in etwa dauern wird bis Froxlor kompatibel ist. LG, Afox
d00p Posted June 29, 2019 Posted June 29, 2019 Wir sind im Release candidate Zyklus. Buster config templates sind bereits eingefügt und müssen noch getestet werden. Es wird aber definitiv keinen stable Release von froxlor zum Release von Buster geben.
Afox Posted June 29, 2019 Author Posted June 29, 2019 Danke für die Antwort. Ich gehe mal davon aus dass es auch Pakete mit dem stable Release geben wird (so wie bisher nur etwas zeitversetzt). LG
Afox Posted September 8, 2019 Author Posted September 8, 2019 hi nochmal, kommt eigentlich noch ein rc Release vor dem stable Release oder wäre die nächste dann schon die stable Version? Werden noch weitere Pull requests einfließen (z.B. OpenDKIM) oder bleibt der Umfang so wie er aktuell auf github zu sehen ist? VG
d00p Posted September 9, 2019 Posted September 9, 2019 Ein umfangreicher und vorallem nur halbfertiger PR wie Domainkey wird nicht mehr in 0.10.0 einfließen
Afox Posted September 9, 2019 Author Posted September 9, 2019 also könnte die nächste Version schon stable werden?
d00p Posted September 9, 2019 Posted September 9, 2019 Möglich ja, im Moment ist nur leider Zeit der entscheidende Faktor, denn die fehlt mir hoch zehn
s20 Posted July 30, 2019 Posted July 30, 2019 Gibt es bezüglich Buster schon einen neuen Stand? Welche Version wird damit laufen? Danke
d00p Posted July 30, 2019 Posted July 30, 2019 0.10.0 wird config templates haben, Laufen tut aber auch 0.9.x problemlos...ist ja nur PHP geht nur um die configs
caroman Posted November 12, 2019 Posted November 12, 2019 Hallo, verabschiede mich gerade von Strech und stelle um auf Buster. Auf Stretch habe ich das Update auf die letzte Version durchgeführt, ohne Probleme. Die Froxlor Datenbank habe ich gesichert und auf den BusterServer kopiert. Die Froxlor Installation auf dem BusterServer iss sauber durchgelaufen, hab die mit der Installation angelegte Datenbank gesichert und dann die Datenbank aus Stretch zurück kopiert. Auch das zurück kopieren der Datenbank klappte auch ohne Probleme, alles wird angezeigt. Muss danach noch schnell die IP's ändern, alles kein Problem. Wer ahnt's, es zwickt an einer anderen Stelle: Die User müssten aus der Froxlor Datenbank dem System bekannt gemacht werden, das scheint noch nicht zu klappen: Wenn ich die webs aus der tgz extrahiere, werden die owner in Zahlen ausgegeben. Außerdem jammert der Apache herum: "bad user name ImmoService" könnte sein, dass das mit den ownern zusammenhängt, das Log-File gibt noch nichts sinnvolles her. Da muss ich noch forschen. Ist bekannt, dass ein einfaches kopieren des customers-Verzeichnis von mit seinen UnterverzeichnissenStretch nach Buster nicht reicht? Danke für die Antwort schon mal im Voraus !!!! und danke für die super Software in den vergangenen Monaten !!!!!!
d00p Posted November 13, 2019 Posted November 13, 2019 Hattest du denn auf dem alten Server libnss-mysql/libnss-extrausers verwendet? Das wäre die Schnittstelle zwischen Datenbank und System was die User angeht. Ebenso hast du bei den Datenbanken hoffentlich auch an die mysql-Datenbank gedacht in der sich die ganzen Datenbankbenutzer und Passwörter verstecken, sonst sind zwar die Kundendatenbanken da, aber die Rechte dafür nicht.
caroman Posted November 13, 2019 Posted November 13, 2019 Jup, extrausers kommt zum Einsatz. Hab mal nachgesehen, wie es auf dem BusterServer mit den Datein /var/lib/extrausers/passwd /var/lib/extrausers/group /var/lib/extrausers/shadow ausssieht. Die waren leer, wie am Anfang, erkllärt alles. Hab dann einen DemoKunden und hierfür eine Domain angelegt, plötzlich waren alle Einträge da, auch nach dem Extrahieren der Customers stimmten die Owner. Was ich außen vor ließ ist, dass neue Passwörter für MySQL root, MySQL froxlor uns das Admin-Passwort vergeben wurden, das dürfte jedoch nicht ursächlich sein. Natürlich ist klar, dass die Anpassung in den Configurationsdateien erfolgen muss, soweit erforderlich.
d00p Posted November 13, 2019 Posted November 13, 2019 ja dann lief da vllt nur der entsprechende cron nicht, der schreibt dateien ja nur wenn was geändert wurde, also wenn du da eine installation komplett wegziehst macht es durchaus sinn da den cron manuell mit --force --debug auszuführen um alles wieder anzulegen
s20 Posted July 30, 2019 Posted July 30, 2019 Kann ich das Distributions Update einfach machen oder muss ich etwas am froxlor 0.9.40.1-1 anpassen?
d00p Posted July 30, 2019 Posted July 30, 2019 An froxlor selbst nicht nein, ggfls halt configs - vorallem mail
d00p Posted July 31, 2019 Posted July 31, 2019 ??? es ist alles open source...https://github.com/Froxlor/Froxlor nimm was da ist und was du brauchst - möglicherweise funktionieren die stretch configs da noch zu 99%
Leapfrog Posted February 4, 2020 Posted February 4, 2020 Hallo Forum, ich habe mich prophylaktisch schonmal hier angemeldet, weil ich gerade etwas Verwegenes ausprobiert habe und bestimmt noch ein paar Schwierigkeiten auf mich warten: Habe in den letzten Tagen meinen lange vernachlässigten froxlor vserver von Debian Wheezy zunächst auf Jessie, dann Stretch und schließlich Buster hochgezogen! Da ich nur einen "Kunden" drauf hatte, mich :), waren die Anforderungen vielleicht nicht sehr anspruchsvoll. Trotzdem bin ich positiv überrascht, daß es nach leichten Querelen im Wesentlichen wieder läuft. Spricht für Debian und Froxlor gleichermaßen, grosser Respekt! Ein paar meiner Stolpersteine möchte ich einfach lose mal hier nennen, bin nicht so der Webserver-Held und vielleicht ist es für irgendwen gut: * Hatte am Ende zwei php-Versionen (5 und 7) auf dem System und damit arbeitete die GUI nur teilweise (z.B. der Customer-Bereich war blank page). Habe dann php5 komplett runter geschmissen und mit php7 wird nun alles wieder korrekt angezeigt. * Die Inhalte der Datenbank scheinen bei der Migration nach mariadb alle erhalten geblieben zu sein. Top. Kehrseite scheint bisher einzig zu sein, daß manche alten Einträge natürlich noch nichts von systemd wissen konnten. Voreingestellte Startscripte sollte ich jetzt wohl ändern, oder? bspw. /etc/init.d/cron reload zu systemctl restart cron. * Die wichtigen, zyklischen cronjobs von froxlor (z.B. 5 min config refresh) haben nicht mehr funktioniert, weil /usr/bin/php5 benutzt wurde. Habe alle auf /usr/bin/php geändert (zeigt auf php7) und dann ging das auch wieder. Ich hoffe mal der typische Aufruf " /usr/bin/nice -n 5 /usr/bin/php -q" ist weiterhin froxlor-konform. * Apache habe ich von 2.2 auf 2.4 angepasst, musste wegen Syntax-Änderungen etwas an der apache2.conf schrauben. * ssh und apache2 hatten Probleme nach dem Booten. So kam ssh erst wenige Minuten nach der ping-Antwort hoch und apache lief in einen seltsamen timeout und blieb dann failed. Ein Nachstarten von Hand mit systemctl start apache war dann aber trotzdem immer möglich. Habe mich erinnert, daß ich ein ähnliches Problem schonmal hatte, wenn die Entropieerzeugung eines Systems nicht richtig klappte. Die Installation von haveged schaffte auch diesmal Abhilfe gegen das Boot-Problem der beiden Dienste. Mehr fällt mir jetzt gerade nicht mehr ein. Es bleibt derzeit etwas Verunsicherung, welche alten Einträge in der Datenbank in einem frisch installierten froxlor unter Debian 10 heutzutage vielleicht anders aussehen sollten, siehe obiges Beispiel mit den Startscripten unter systemd. - Vielleicht noch andere Tips in der Richtung? Mein Vertrauen in Froxlor hat jedenfalls einen riesen Schub bekommen, nachdem es diese Tour de Force über drei Distributions-Upgrades praktisch schadlos überstanden hat! Danke
d00p Posted February 5, 2020 Posted February 5, 2020 12 hours ago, Leapfrog said: * Hatte am Ende zwei php-Versionen (5 und 7) auf dem System und damit arbeitete die GUI nur teilweise (z.B. der Customer-Bereich war blank page). Habe dann php5 komplett runter geschmissen und mit php7 wird nun alles wieder korrekt angezeigt. Korrekt, zum einen durch die Upgrade-Pfade wure das frühere Standard-PHP, nämlich 5.6 nicht entfernt und zusätzlich 7.x installiert, was in späteren Versionen default war. Die weiße Seite hast du gesehen, da es vermutlich einen PHP Fehler gab, da froxlor seit 0.10.0 eben auch php-7.0 als Mindestanforderung hat, ich nehme an zu der Zeit war noch php-5.6 aktiv für den Webserver. 12 hours ago, Leapfrog said: Die Inhalte der Datenbank scheinen bei der Migration nach mariadb alle erhalten geblieben zu sein. Top. Kehrseite scheint bisher einzig zu sein, daß manche alten Einträge natürlich noch nichts von systemd wissen konnten. Voreingestellte Startscripte sollte ich jetzt wohl ändern, oder? bspw. /etc/init.d/cron reload zu systemctl restart cron. Also ich kann unter buster immer noch /etc/init.d/cron restart ausführen - aber ja, nicht für alle Dienste stehen diese init-Scripts mehr zur Verfügung, das ist korrekt. Aber sichersten fährst du bei Debian mit "service [service] restart" oder eben mit "systemctl restart [service]" 12 hours ago, Leapfrog said: * Die wichtigen, zyklischen cronjobs von froxlor (z.B. 5 min config refresh) haben nicht mehr funktioniert, weil /usr/bin/php5 benutzt wurde. Habe alle auf /usr/bin/php geändert (zeigt auf php7) und dann ging das auch wieder. Ich hoffe mal der typische Aufruf " /usr/bin/nice -n 5 /usr/bin/php -q" ist weiterhin froxlor-konform. Dafür ist das ja eine entsprechende Einstellung in froxlor um, solche Dinge anzupassen 12 hours ago, Leapfrog said: Apache habe ich von 2.2 auf 2.4 angepasst, musste wegen Syntax-Änderungen etwas an der apache2.conf schrauben. Echt? die hat apt nicht aktualisiert? Also, froxlor-seitig machen wir an der apache2.conf NICHTS, du musst allerdings für die vhosts, damit die konform bleiben, in froxlor natürlich angeben, dass du nun apache-2.4 nutzt 12 hours ago, Leapfrog said: Es bleibt derzeit etwas Verunsicherung, welche alten Einträge in der Datenbank in einem frisch installierten froxlor unter Debian 10 heutzutage vielleicht anders aussehen sollten Eigentlich sind die alle plusminus gleich geblieben, einzig halt Vorkommen von expliziter php5 Angabe, das sollte aber auch nicht viel sein. 12 hours ago, Leapfrog said: siehe obiges Beispiel mit den Startscripten unter systemd. - Vielleicht noch andere Tips in der Richtung? Also default z.B. für apache ist auch in froxlor immer noch /etc/init.d/apache2 reload und das funktioniert auch weiterhin bei buster wunderbar. Ich habe da auch bei mir auf den servern, ob nun mehrfach aktualisiert oder neuinstalliert, an den Pfaden zu reload-scripten nie groß was angepasst 12 hours ago, Leapfrog said: Mein Vertrauen in Froxlor hat jedenfalls einen riesen Schub bekommen, nachdem es diese Tour de Force über drei Distributions-Upgrades praktisch schadlos überstanden hat! Das freut mich sehr zu hören Soviel Spaß für so wenig Geld was
Leapfrog Posted February 5, 2020 Posted February 5, 2020 2 hours ago, d00p said: Quote Korrekt, zum einen durch die Upgrade-Pfade wure das frühere Standard-PHP, nämlich 5.6 nicht entfernt und zusätzlich 7.x installiert, was in späteren Versionen default war. Die weiße Seite hast du gesehen, da es vermutlich einen PHP Fehler gab, da froxlor seit 0.10.0 eben auch php-7.0 als Mindestanforderung hat, ich nehme an zu der Zeit war noch php-5.6 aktiv für den Webserver. Yep. Steht ja sogar in den release notes / einem announcement als Mindestanforderung, hatte ich leider erst zu spät entdeckt. Quote Also ich kann unter buster immer noch /etc/init.d/cron restart ausführen - aber ja, nicht für alle Dienste stehen diese init-Scris mehr zur Verfügung, das ist korrekt. Aber sichersten fährst du bei Debian mit "service [service] restart" oder eben mit "systemctl restart [service]" Ja ist bei mir auch so, Buster ist erfreulicherweise bislang noch abwärtskompatibel zu SysV-init geblieben. Ich werde jetzt aber mal auf systemctl umstellen. Quote Dafür ist das ja eine entsprechende Einstellung in froxlor um, solche Dinge anzupassen ... das gefällt mir auch sehr! Etwas unsicher war ich nur, ob die ganze Befehlskette mit nice, -q, usw. noch so geblieben war (generell funktioniert hat sie ja). Ich finde es immer sehr hilfreich, wenn die aktuellen "Standard-Werte" neben dem Eingabefeld stehen. An vielen Stellen ist das ja auch so, z.B. bei der SSLCipherSuite. Quote Echt? die hat apt nicht aktualisiert? Also, froxlor-seitig machen wir an der apache2.conf NICHTS, du musst allerdings für die vhosts, damit die konform bleiben, in froxlor natürlich angeben, dass du nun apache-2.4 nutzt Per default überschreibt das update die apache2.conf nicht. Ich habe mir dann anschließend die diffs angesehen und kontrolliert gemerged. Waren nur wenige Stellen (überflüssige mpm Optionen, neue Directory Statements, neue syntax im htaccess). Ausserhalb der apache2.conf hatte mich insbesondere die Umstellung von Debian auf Documentroot /var/www/html/ irritiert. Froxlor setzt weiterhin /var/www/ voraus und ich hatte das dann auch umgestellt. Bin mir allerdings noch nicht ganz sicher, ob das weitere Implikationen im Bezug auf Sicherheit hat. Debian hat sich dabei ja auch etwas gedacht. Momentan scheint das aber nicht der Fall zu sein, ich habe meine Seiten unter /var/www/ derzeit alle mit htaccess oder eben dem froxlor-login unter Kontrolle (bin ich zumindest der Meinung Quote Eigentlich sind die alle plusminus gleich geblieben, einzig halt Vorkommen von expliziter php5 Angabe, das sollte aber auch nicht viel sein. Das klingt gut! Quote Das freut mich sehr zu hören Soviel Spaß für so wenig Geld was 🙂 Und der Spaß geht jetzt noch weiter. Ich muß mein letsencrypt jetzt noch anpassen. Hatte das damals immer per cronjob aktualisiert und quasi an froxlor vorbei (bis auf die eingetragenen Pfade für die drei .pems) gemanaged. Das certificate ist aber nur noch bis April gültig und ich möchte das in Zukunft gerne sauber mit Froxlor abwickeln. Da fehlt mir noch die grobe Strategie, aber das wird dann vielleicht noch ein neues Thema ... Vielen Dank
d00p Posted February 7, 2020 Posted February 7, 2020 On 2/5/2020 at 10:16 AM, Leapfrog said: . Froxlor setzt weiterhin /var/www/ voraus und ich hatte das dann auch umgestellt. Voraussetzen ist das falsche wort Du kannst froxlor woauchimmer du willst hininstallieren so lange der webserver drauf zeigt ist das wurscht. Nur das debian-paket installiert es halt nach /var/www/ weil es einfach schon immer so war und das jetzt zu ändern ggfls viele installationen kaputtmacht bei einem update
Leapfrog Posted February 7, 2020 Posted February 7, 2020 5 hours ago, d00p said: Voraussetzen ist das falsche wort Du kannst froxlor woauchimmer du willst hininstallieren so lange der webserver drauf zeigt ist das wurscht. Nur das debian-paket installiert es halt nach /var/www/ weil es einfach schon immer so war und das jetzt zu ändern ggfls viele installationen kaputtmacht bei einem update Ist wohl ein kleines Dilemma. Alte Installationen sollen nach einem Update nicht "gebrochen" werden, sehe ich persönlich auch so. Andererseits wäre es natürlich auch hübsch, wenn auf einem taufrischen Debian Buster der apache 2 und froxlor gleich harmonieren würden. Man kann wohl nicht beides haben. Bei der Gelegenheit aber vielleicht meine ersten feedbacks zum Migrationsversuch von letsencrypt anno 2016. Zunächst wollte ich den froxlor vhost wieder über letsencrypt absichern, diesmal mit ACMEv2 unter froxlor. Ich hatte erstmal alle Pfade (/etc/letsencrypt/*) zu meinen alten SSL-Zertifikaten in froxlor ausgetragen. "Let's Encrypt verwenden" musste aktiviert werden. Gilt also offenbar doch nicht nur für Kunden, wie in der Beschreibung, sondern auch für den froxlor admin. In gewisser Weise ist der aber wohl auch Kunde. Eine /etc/apache2/conf-enabled/acme.conf, wie in der entsprechenden Option voreingestellt, existiert in meinem Buster nicht. Habe diese Einstellung aber erstmal gelassen. (Fragezeichen...) Danach habe ich mich dann lange mit dem debugging des letsencrypt handshakes beschäftigen dürfen Irgendwann war ich so weit, daß das .well-known token zwar verhandelt wurde, aber die Gegenstelle es am Ende nicht auf meinem Webserver finden konnte. Anscheinend suchte die Gegenstelle .well-known immer unter me.myserver.de/ und nicht in meinem korrekten Pfad me.myserver.de/froxlor/. Ich habe dann zumindest einen workaround gefunden, indem ich "Froxlor direkt über den Hostnamen erreichbar machen" aktiviert habe. Damit wurde der froxlor Pfad direkt über me.myserver.de/ zugänglich (intern wird der Documentroot von /var/www/ auf /var/www/froxlor verrückt). Das erste erfolgreiche Zertifikat war dann allerdings auf den Hostname in den Systemeinstellungen ausgestellt worden. Dieser enthielt bis dahin noch den ursprünglichen hostname meines Hosters (der bis heute auch noch in meiner /etc/hostname steht). Da ich froxlor aber über meine eigene Domain erreichen will, habe ich die Option Hostname auf www.myserver.de umgestellt, das erstellte Zertifikat gelöscht und nochmal neu erzeugen lassen. Bin sehr happy, daß es jetzt schonmal für dir froxlor-GUI geklappt hat! Kleiner Wermutstropfen allenfalls, daß www.myserver.de einem Besucher nun als erstes ein Froxlor-Login entgegenschleudert. Ich hätte das lieber wieder in einem Unterverzeichnis www.myserver.de/froxlor/ oder irgendwo anders verborgen gehabt. Auf HTTP2 Unterstützung habe ich jetzt mal umgestellt, allerdings ohne zu wissen, ob es für mich irgendeinen Benefit hat. Bin mal gespannt, ob sich der einzige Customer auf dem System jetzt auch noch erfolgreich über das letsencrypt-feature von Froxlor einrichten lässt ... Grüsse
Leapfrog Posted February 8, 2020 Posted February 8, 2020 Nachtrag: Mein workaround mittels "Froxlor direkt über den Hostnamen erreichbar machen" ist nun nicht mehr nötig. Wie sich erfreulicherweise in einem anderen Thread soeben herausgestellt hat, fehlte auf meinem apache 2.4 die acme.conf, welche einen festen Pfad für die acme-challenge setzt. Kriegt man zu sehen, wenn man im Konfiguration-Fenster die passende Auswahl trifft. Hier: Debian Buster (10.x) » Webserver (HTTP) » Apache 2.4 Grüsse PS: Achso, eines noch schnell. Kann mir bitte einer sagen, was der System-Default bei der SSL-Option "Let's Encrypt Schlüssel wiederverwenden" ist? Kurzes Ja oder Nein reicht.
d00p Posted February 8, 2020 Posted February 8, 2020 19 minutes ago, Leapfrog said: PS: Achso, eines noch schnell. Kann mir bitte einer sagen, was der System-Default bei der SSL-Option "Let's Encrypt Schlüssel wiederverwenden" ist? Kurzes Ja oder Nein reicht. default nein
Leapfrog Posted February 8, 2020 Posted February 8, 2020 danke Mit dem heutigen Debian update hat sich übrigens auch die boot-Problematik von ssh und apache wieder erledigt. Funktioniert jetzt wieder ohne das Paket haveged. Start-Date: 2020-02-08 17:38:52 Commandline: apt-get dist-upgrade Install: linux-image-4.19.0-8-amd64:amd64 (4.19.98-1, automatic) Upgrade: libpython3.7-minimal:amd64 (3.7.3-2, 3.7.3-2+deb10u1), libcomerr2:amd64 (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), postfix:amd64 (3.4.7-0+deb10u1, 3.4.8-0+10debu1), e2fsprogs-l10n:amd64 (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), libcom-err2:amd64 (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), libcups2:amd64 (2.2.10-6+deb10u1, 2.2.10-6+deb10u2), linux-libc-dev:amd64 (4.19.67-2+deb10u2, 4.19.98-1), postfix-mysql:amd64 (3.4.7-0+deb10u1, 3.4.8-0+10debu1), libsystemd0:amd64 (241-7~deb10u2, 241-7~deb10u3), libglapi-mesa:amd64 (18.3.6-2, 18.3.6-2+deb10u1), mariadb-common:amd64 (1:10.3.18-0+deb10u1, 1:10.3.22-0+deb10u1), postfix-sqlite:amd64 (3.4.7-0+deb10u1, 3.4.8-0+10debu1), e2fsprogs:amd64 (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), sudo:amd64 (1.8.27-1+deb10u1, 1.8.27-1+deb10u2), mariadb-server-core-10.3:amd64 (1:10.3.18-0+deb10u1, 1:10.3.22-0+deb10u1), python3.7:amd64 (3.7.3-2, 3.7.3-2+deb10u1), openssh-sftp-server:amd64 (1:7.9p1-10+deb10u1, 1:7.9p1-10+deb10u2), gnutls-bin:amd64 (3.6.7-4, 3.6.7-4+deb10u2), udev:amd64 (241-7~deb10u2, 241-7~deb10u3), e2fslibs:amd64 (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), libpq5:amd64 (11.5-1+deb10u1, 11.6-0+deb10u1), libpython3.7-stdlib:amd64 (3.7.3-2, 3.7.3-2+deb10u1), libudev1:amd64 (241-7~deb10u2, 241-7~deb10u3), python3.7-minimal:amd64 (3.7.3-2, 3.7.3-2+deb10u1), mariadb-server-10.3:amd64 (1:10.3.18-0+deb10u1, 1:10.3.22-0+deb10u1), proftpd-mod-mysql:amd64 (1.3.6-4+deb10u2, 1.3.6-4+deb10u3), libss2:amd64 (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), libext2fs2:amd64 (1.44.5-1+deb10u2, 1.44.5-1+deb10u3), libboost-iostreams1.67.0:amd64 (1.67.0-13, 1.67.0-13+deb10u1), linux-image-amd64:amd64 (4.19+105+deb10u1, 4.19+105+deb10u3), systemd-sysv:amd64 (241-7~deb10u2, 241-7~deb10u3), proftpd-doc:amd64 (1.3.6-4+deb10u2, 1.3.6-4+deb10u3), libpam-systemd:amd64 (241-7~deb10u2, 241-7~deb10u3), systemd:amd64 (241-7~deb10u2, 241-7~deb10u3), openssh-server:amd64 (1:7.9p1-10+deb10u1, 1:7.9p1-10+deb10u2), libgl1-mesa-dri:amd64 (18.3.6-2, 18.3.6-2+deb10u1), openssh-client:amd64 (1:7.9p1-10+deb10u1, 1:7.9p1-10+deb10u2), mariadb-client-10.3:amd64 (1:10.3.18-0+deb10u1, 1:10.3.22-0+deb10u1), libnss-systemd:amd64 (241-7~deb10u2, 241-7~deb10u3), mariadb-client-core-10.3:amd64 (1:10.3.18-0+deb10u1, 1:10.3.22-0+deb10u1), libtimedate-perl:amd64 (2.3000-2, 2.3000-2+deb10u1), libmariadb3:amd64 (1:10.3.18-0+deb10u1, 1:10.3.22-0+deb10u1), libgnutls30:amd64 (3.6.7-4, 3.6.7-4+deb10u2), libgnutls-dane0:amd64 (3.6.7-4, 3.6.7-4+deb10u2), proftpd-basic:amd64 (1.3.6-4+deb10u2, 1.3.6-4+deb10u3), base-files:amd64 (10.3+deb10u2, 10.3+deb10u3), libglx-mesa0:amd64 (18.3.6-2, 18.3.6-2+deb10u1), libboost-system1.67.0:amd64 (1.67.0-13, 1.67.0-13+deb10u1) End-Date: 2020-02-08 17:41:50
Question
Afox
hi,
wollte mal fragen ob es bereits Planungen zu einem Buster Release gibt, also ob es nach dem Erscheinen am 06.07.2019 mit Froxlor-Paketen zu rechnen ist bzw. wie lange es in etwa dauern wird bis Froxlor kompatibel ist.
LG,
Afox
25 answers to this question
Recommended Posts
Archived
This topic is now archived and is closed to further replies.