Beiträge von aziegler

  • Admin Session/Sitzung

    Zitat von stefanos

    Im Changelog stand es im Jahr 2017 sehr wohl bereits drin


    Genau das habe ich doch geschrieben, dass ich es nur wegen des Changelog gefunden habe?


    Zitat

    Auch im alten Handbuch stand es bereits auf Seite 91 (Seite 101 im PDF) drin.


    Und was haben mich 2017 die Handbücher von 2020 interessiert?


    Sorry, aber ich verstehe nicht warum du 2021 meinen Beitrag von 2017 ausgräbst und komplett falsch interpretierst.

  • PHP Version in Liveconfig für Kunden verstecken

    Zitat von kk

    Warten Sie einfach bis zum nächsten Update (v2.11), da kann man dann einzelne PHP-Versionen in der PHP-Verwaltung (Server-Verwaltung -> Web) aktivieren/deaktivieren. Und dann auch z.B. so, dass bestehende Domains weiter mit der eingestellten Version arbeiten, diese aber für neue Domains nicht mehr ausgewählt werden kann.


    Bisher hat mich auch gestört, dass ich nur den default definieren kann, aber nicht sagen kann "default für alle neu angelegten (Sub-)Domains" ohne bestehende sofort anzufassen

  • LiveConfig v2.10.2

    Zitat von ap24


    Ist das so korrekt? Der SSH-Zugriff ist für den Reseller bzw. Kunden eigentlich deaktiviert.


    Zitat aus dem Changelog:
    "Verwendung von /var/www/.skel (falls vorhanden) als sogenanntes “Skeleton-Verzeichnis” beim Anlegen neuer Webspace-Accounts"
    Gibt es das Verzeichnis bei Ihnen?

  • PHP 7.2.32, 7.3.20 und 7.4.8

    durch die neuen PHP Updates auf Debian Stretch ist libsodium18 überflüssig geworden - Absicht?


    EDIT: im changelog steht:
    "using libsodium 1.0.18-stable on Debian 8 / Debian 9"
    ist das nun "einkompiliert" ?

  • Charset Problem

    Zitat von mschweiger


    Hier mal meine Frage an die Foren Gemeinde oder auch Herrn K. : Technisch Umsetzbar ist dies ja scheinbar. Nur meine große Frage: Wie??? Hat das schon jemand im Einsatz?


    Genauso einfach umsetzbar wie alle PHP-Einstellungen:
    Den gewünschten Eintrag in den globalen PHP-Einstellungen von LiveConfig anlegen.

  • LiveConfig v2.8.0

    Zitat von kk

    Die von Debian/SpamAssassin verwalteten Verzeichnisse unterhalb von /var/lib/spamassassin/ müssen weiterhin debian-spamd:debian-spamd gehören (3.00*, compiled, sa-update-keys). Die Benutzerverzeichnisse (<Vertrag>_<PostfachID>) müssen spamd:spamd gehören und mode=0750 haben.


    LiveConfig macht das alles korrekt. Probleme gibt es nur, wenn SpamAssassin eben als Benutzer "debian-spamd" läuft (dann hat er keinen Zugriff auf die user_prefs). Umgekehrt hat SpamAssassin als Benutzer "spamd" aber Zugriff auf die Regeln, die "debian-spamd" gehören. Dieses Setup ist sicherer und deshalb so beabsichtigt.


    Code
    # ls -l /var/lib/spamassassin/
total 0
drwxr-xr-x 3 debian-spamd debian-spamd 71 May 14  2016 3.003001
drwxr-xr-x 3 debian-spamd debian-spamd 71 Oct 23  2018 3.003002
drwxr-xr-x 3 debian-spamd debian-spamd 71 Jan 15  2019 3.004000
drwxr-xr-x 3 debian-spamd debian-spamd 71 Aug 23 07:02 3.004002
drwxr-xr-x 3 debian-spamd debian-spamd 18 Oct 23  2018 compiled
drwx------ 2 debian-spamd debian-spamd 79 Aug 23 07:02 sa-update-keys
drwxr-x--- 2 spamd        spamd        57 Aug  2 18:34 web345_7


    so weit, so gut - aber bayes funktioniert damit noch nicht.
    Dazu müsste LC entweder "chgrp spamd /var/lib/spamassassin && chmod g+w /var/lib/spamassassin" machen. ( siehe https://www.liveconfig.com/de/…=8220&viewfull=1#post8220 )
    Oder aber proaktiv für jedes Postfach einen Ordner vorab anlegen, statt erst wenn es user_prefs gibt.


    Welchen Weg sollen wir gehen?

  • LiveConfig v2.8.2

    Zitat von bfal

    Das cron.php.sh Script setzt jetzt sudo vorraus. Daher sollte sudo jetzt zu den Abhängigkeiten gehören würde ich vorschlagen.


    dann update ich erstmal nicht und warte Doku dazu ab, das installieren von sudo reicht ja wohl eher nicht

  • LiveConfig v2.8.1

    Zitat von kk

    Ja, es hat eben alles Vor- und Nachteile. Wenn direkte DNS-Zugriffe möglich sind, dann nutzt LiveConfig diese um den TTL von DNS-Daten ignorieren zu können - wird ein externer Resolver verwendet, dann erhält LiveConfig ggf. Antworten aus dessen Cache (was im Normalbetrieb ja erwünscht ist, für Diagnosezwecke aber ungünstig ist).


    Bei Multi-Server-Setups genügt es, wenn der LiveConfig-Hauptserver DNS-Zugriff hat (die LiveConfig-Clients lösen keine DNS-Anfragen aus). Und wenn die DNS-Zugriffe lokal (iptables) gefiltert werden, kann man mittels "owner"-Modul einzelne Benutzer freischalten - wie z.B. den Benutzer "liveconfig". ;)


    Natürlich, alles kein Drama.
    Es fällt nur in die Kategorie "immer mehr Anwendungen machen DNS selbst", siehe auch Browser


    An anderer Stelle erschwert das Debugging, insbesondere wenn man nicht davon weiß oder nicht daran denkt, dass nicht alles über den lokalen Resolver geht.

  • LiveConfig v2.8.1

    Zitat von kk

    Keine. LiveConfig nutzt mit "libunbound" einen integrierten, validierenden DNS-Resolver - die jeweiligen Nameserver werden dann also direkt kontaktiert. Für Diagnosezwecke ist man damit flexibler als mit einem externen Resolver.


    aber der Betreiber und das OS hat dann weniger Kontrolle über die DNS-Tätigkeiten die vom System ausgehen ;)

  • LiveConfig v2.8.0

    Zitat von JHPC

    Danke für die hilfreiche Aufklärung. Es hat aber keiner behauptet, dass wir von einem aktiven System reden, das noch direkt am Internet hängt, sondern dass von einem Altsystem Daten importiert werden müssen. :rolleyes:


    ok, unwahrscheinliches Szenario, dass ein Altsystem seit vier Jahren offline ist, die Daten noch da sind und man diese jetzt erst braucht - aber OK, ich nehme das mal so hin :)