Leapfrog

Just for the record: Because I already have an existing /etc/iptables/rules.v4 and the package iptables-persistent is installed, opening a few ports more is easy, example: # iptables -A INPUT -p udp --dport 10000 -j ACCEPT # iptables -A INPUT -p tcp --dport 5349 -j ACCEPT (activates both rules) # netfilter-persistent save (saves the running iptables to /etc/iptables/rules.v4 and the new rules are bootfix then) (This command is documented in /usr/share/doc/iptables-persistent/README) # iptables -nvL ... 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:10000 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5349 ... (success control after reboot)

Yes, these saves and restores are done by the script ... /usr/share/netfilter-persistent/plugins.d/15-ip4tables ... from the debian package iptables-persistent. But this is no explanation, where the contents of the rules.v4 initially came from (which match so wonderful the requirements of a froxlor installation). Some intelligent entity must have created those rules - and that hasn't been me 😉

Ok, I thought froxlor has been responsible for the /etc/iptables/rules.v4, sorry. That froxlor was not, is a very important info for me, thank you very much! I have to find out now, where those existing iptables came from. My only candidates at the moment are * the existing rules are a default in the OS Linux image of my Hoster? * the existing rules were generated during a Wordpress Installation? Anyway, it is good to know, that froxlor cannot overwrite those persistent rules. Kind regards

Froxlor (0.10.22-1) is running nicely on my server (Debian 10 Buster). But now I plan to install a service on this public server, which needs a few ports more opened in iptables. I am not sure how to create some rules that do not conflict with froxlor? What is the recommended way to install a few persistent rules, that do not disturb froxlor? Status: iptables is running and is showing some rules, example: [code] # iptables -nvL ... 152 7784 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 513 25024 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 ... [/code] I find these active rules persistent in /etc/iptables/rules.v4 [code] # Generated by xtables-save v1.8.2 on Mon Feb 10 20:44:30 2020 *filter ... -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT ... # Completed on Mon Feb 10 20:44:30 2020 [/code] As far as I've seen these rules are loaded at boottime by systemd's netfilter-persistent.service. Installed Debian packages: [code] ii iptables 1.8.2-4 amd64 administration tools for packet filtering and NAT ii iptables-persistent 1.0.11 all boot-time loader for netfilter rules, iptables plugin ii netfilter-persistent 1.0.11 all boot-time loader for netfilter configuration [/code] Has Froxlor generated the /etc/iptables/rules.v4? How can I add a few more rules to rules.v4? For example allowing incoming ports 10000/udp and 5349/tcp? Kind regards

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

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.

Halleluja d00p, jetzt klappt auch die Zertifizierung der Kunden-Domain!! Ursache war die fehlende acme.conf. Die tiefere Ursache für deren Fehlen wiederum war mein Missverständnis der Konfiguration-Page. Ich habe die immer umgangen, weil ich der Annahme war sie diene nur der Erstkonfiguration eines frischen Systems. Gleichzeitig war meine Befürchtung, sie würde mein System mit default-Konfigurationen überschreiben/löschen. In diese bedrohliche Richtung hatte ich dann natürlich auch die Beschreibung des Handstarts interpretiert: "Alternativ, führe den folgenden Befehl als root-Benutzer auf der Shell aus, um die Dienste automatisch zu konfigurieren." Auf dein Anraten hatte ich es jetzt einfach mal gewagt und zu meiner Freude feszgestellt, daß dort nur fehlende Konfigurationshinweise (u.a. zur acme.conf) standen Großartig, vielen Dank für deine Hilfestellung, d00p! Problem gelöst! Grüsse

Bin mir nicht ganz sicher, was du meinst. Eine Konfiguration unter dem Reiter System->Konfiguration habe ich nach den Upgrades auf Debian 10 nicht durchgeführt. Dort habe ich den Hinweis ""Das System ist bereits konfiguriert". "Konfigurations-templates" sagt mir gerade auch nichts. Alles, was ich damit in Verbindung bringen könnte, sind folgende System SSL-Einstellungen bei mir: Verzeichnis für Let's Encrypt challenges -> /var/www/froxlor Pfad zu acme.conf -> /etc/apache2/conf-enabled/acme.conf Jene acme.conf existiert auf meinem Server jedoch nicht, ich weiß auch nicht, wo die herkommen sollte. Und jenes challenge-Verzeichnis wird bei dem Handshake bereits benutzt, wie ich in den Logs sehe. Mir ist nicht klar, was der Soll-Zustand ist, ob die Gegenstelle das Token unter /var/www/froxlor/.well-known/acme-challenge verifizieren soll (und wo das Token real ja auch liegt) oder unterhalb der Kunden-Domain /var/customers/webs/kunde/ .well-known/acme-challenge.

Im Zuge eines dist-upgrade auf Debian 10 Buster versuche ich jetzt erstmalig letsencrypt unter Froxlor (0.10.13-1) in Betrieb zu nehmen. Für die Froxlor-GUI selbst hat das jetzt auch schon mit einigen Mühen geklappt. Im zweiten Schritt soll nun aber auch die Customer Domain SSL mittels letsencrypt Zertifikat erhalten. Das scheitert bislang aber beharrlich. Soweit ich das im debug erkennen kann, kann der Validierungs-Server von letsencrypt.org das erzeugte Token auf meinem Webserver nicht finden und somit auch nicht erfolgreich verifizieren. Das Zertifikat wird deshalb auch nicht erzeugt. (anonymisiert) php /var/www/froxlor/scripts/froxlor_master_cronjob.php --force --debug [...] [Sat Feb 8 10:06:03 CET 2020] kunde.myserver.de:Verify error:Invalid response from http://kunde.myserver.de/.well-known/acme-challenge/pEqRmsnXbBJFyNuDRxOmol1sdzioPAMZ_FsUueBajH [X.X.X.X]: [Sat Feb 8 10:06:03 CET 2020] Debug: get token url. [Sat Feb 8 10:06:03 CET 2020] GET [Sat Feb 8 10:06:03 CET 2020] url='http://kunde.myserver.de/.well-known/acme-challenge/pEqRmsnXbBJFyNuDRxOmol1sdzioPAMZ_FsUueBajH' [Sat Feb 8 10:06:03 CET 2020] timeout=1 [Sat Feb 8 10:06:03 CET 2020] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header -g --connect-timeout 1' [Sat Feb 8 10:06:03 CET 2020] ret='0' [Sat Feb 8 10:06:03 CET 2020] Debugging, skip removing: /var/www/froxlor/.well-known/acme-challenge/pEqRmsnXbBJFyNuDRxOmol1sdzioPAMZ_FsUueBajH ... [error] kunde.myserver.de :: empty certificate file! Cannot create ssl-directives ... Im Access log meines apache sehe ich auch den vergeblichen Versuch das Token zu finden: kunde-kunde.myserver.de-access.log: ... 64.78.149.164 - - [08/Feb/2020:10:06:01 +0100] "GET /.well-known/acme-challenge/pEqRmsnXbBJFyNuDRxOmol1sdzioPAMZ_FsUueBajH HTTP/1.1" 404 454 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" Wie es für mich aussieht, passen da in der Tat auch die Pfade des Tokens nicht richtig zusammen. Das Token entsteht ursprünglich unter /var/www/froxlor/.well-known, aber dann versucht die Gegenstelle es unter http://kunde.myserver.de/.well-known bei mir zu verifizieren. Diese Adresse zeigt aber auf den DocumentRoot des Kunden /var/customers/webs/kunde/ und nicht /var/www/froxlor/. Wer macht nun den Fehler? Sucht letsencrypt.org das Token an der falschen Stelle oder versäumt Froxlor das Token irgendwo unterhalb von /var/customers/webs/kunde/ zu platzieren? Ich komme an dieser Stelle nicht mehr weiter Grüsse

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

Yep. Steht ja sogar in den release notes / einem announcement als Mindestanforderung, hatte ich leider erst zu spät entdeckt. 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. ... 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. 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 Das klingt gut! 🙂 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

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