Jump to content
Froxlor Forum

Leapfrog

Members
  • Posts

    12
  • Joined

  • Last visited

Leapfrog's Achievements

Rookie

Rookie (2/14)

  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. 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)
  2. 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 ­čśë
  3. 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
  4. 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
  5. 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
  6. 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.
  7. 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
  8. 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.
  9. 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
  10. 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
  11. 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
  12. 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
×
×
  • Create New...