Beiträge von arnoldB

  • PHP: Schwerwiegende Bugs innerhalb von Configs in speziellen Fällen

    1)
    Standardmäßig sieht LC für die PHP-Einstellung error_reporting den Datentyp String/ Zeichenkette vor. Tatsächlich ist eines Bitmaske die PHP intern als Integer verarbeitet. Wir brauchen in LC einen neuen Datentyp "Bitmaske" und/ oder -weniger fehleranfällig- eine Auswahlliste mit definierten Optionen. Dies muss dann dennoch als Bitmaske/ ohne Quotes in die php.ini-Dateien geschrieben werden. Eventuell lassen sich beide Ansätze sinnvoll mergen.


    Gut möglich das die Einstellung error_reporting mit den aktuellen Quotes gar nicht von PHP beachtet wird.


    http://php.net/manual/de/error…n.php#ini.error-reporting


    Workaround: Einstellung via LC nicht setzen


    Fixed: https://www.liveconfig.com/de/…=8883&viewfull=1#post8883


    2)
    Wenn eine PHP-Einstellung in LC gesetzt ist, aber keine druckbare Zeichen enthält (NULL) schreibt LC in die php.ini Konfiguration jeweils None, was m.E.n. kein funktionierender Ersatz für NULL ist.


    Korrekt wäre etwas wie:


    Code
    geoip.custom_directory =


    statt


    Code
    geoip.custom_directory = None


    Habe ich das Verhalten von PHP richtig verstanden hat das auch für einige Crashes beim Starten von php-cgi durch Apache geführt.


    Workaround: Einstellung via LC nicht setzen oder validen Wert zuweisen


    3)
    Auf der Seite Domains bei den Einstellungen einer Domain enthält das Attribut value des <option>-Knotens der Standard-PHP-Version keinen Wert:


    Code
    <select name="phpversion">
  <option value="">Standard (5.5)</option>
  <option value="cBiy9BRyTGsa">5.3</option>
  <option value="cM5ura3E.fyW">5.4</option>
  <option value="cGf2YBaQMBtD">5.6</option>
</select>


    Das führt dazu, dass in der apache.lua beim Schreiben des vhosts ein hartkodierter Pfad zu einem PHP Binary verwendet wird, der in meinem Fall nicht funktioniert und in der PHP-Versionsliste eigentlich ausgeblendet wurde.


    Code
    -- use another PHP version?
      if php ~= 'php5' then
        fh:write("        FcgidWrapper ", opts.path, "/conf/", php, "/php-fcgi-starter .php\n")
        fh:write("        FcgidWrapper ", opts.path, "/conf/", php, "/php-fcgi-starter .php5\n")
      else
        fh:write("        FcgidWrapper ", opts.path, "/conf/php5/php-fcgi-starter .php\n")
        fh:write("        FcgidWrapper ", opts.path, "/conf/php5/php-fcgi-starter .php5\n")
      end


    Wäre es möglich für diese drei Problemstellungen kurzfristig ein Bugfix-Release zu erhalten?


    Workaround: Problem tritt nur mit meinem web.lua Patch auf. Ist dieser im Einsatz sollte beim Aufruf von addPHP() keine Prio angegeben werden, sodass dann die älteste PHP-Version Standard wird (Erste <option> im <select>). :(


    Das ist mir erst beim stracen aufgefallen..

  • [RFC] Konfigurierbare Kennwortrichtlinien in LiveConfig

    Es ist zwingend notwendig das die Kennwortrichtlinien optional verändert werden können.


    Es gibt User die für Ihr Kennwort drei bis vier Zeichen kurze Zeichenketten festlegen, die dazu auch noch sprechend sind und nur Buchstaben enthalten. Ich muss wohl kaum erwähnen wie schnell solche Kennwörter geknackt werden können und wurden(!).


    Soweit ich weiß sind die Richtlinien auch noch gar nicht im Handbuch o.ä. dokumentiert. Um hier eine Übersicht zu schaffen schlage ich vor das der Admin die Richtlinien _aller Kennwörter_ Kennwörter konfigurieren kann.
    Und damit keine Grundsatzdiskussionen entfacht werden könnte man als Format PCREs nehmen. Das wäre dynamischer als jede selbstgeschriebene DSL/ Syntax, schneller implementiert und einfach/ übersichtlich konfigurierbar.


    • LC-GUI User
    • MySQL-User
    • System-User
    • FTP-User
    • htpasswd-User
    • Webanwendung?
    • Mail-User


    Kommentare?

  • PHP 5.4.34, 5.5.18 und 5.6.2

    https://github.com/bechtoldt/l…e735da0522d00cc174207f576


    Von der custom.lua brauchst du L5-L43, in der web.lua den zusätzlichen Parameter prio (L1191) und das if-Konstrukt in L1199. Das if in L146 habe ich auskommentiert weil ich das Standard-PHP der Distro nicht benutze.


    Wenn das LC-Team ein Repo auf Github bereitstellen würde von dem man sauber forken und Pull-Requests stellen kann würde ich auch zusätzliche Änderungen veröffentlichen, damit sie in den Core kommen. Momentan macht das in meinem aktuellen Branch-Chaos keinen Spaß. Das Backporten ist auch ständig nervig, vor allem weil der LUA-Code nicht so sauber ist (trailing Whitespaces u.ä.). Momentan macht die Arbeit mit dem LUA-Code noch nicht so viel Spaß, obwohl hier sehr viel Potential steckt..



    Disclaimer: Meine Änderungen am LUA-Core sollten nicht ungeprüft in Produktion verwenden werden! Einige Änderungen beeinflussen das Standardverhalten.

  • SCP/SFTP Zugriff auf Web

    Zitat von kk

    Zum einen muss das Paket "scponly" auf dem Server installiert sein (werden wir am besten gleich mal mit ins meta-Package aufnehmen). Außerdem muss in /etc/ssh/sshd_config die Anmeldung per Passwort erlaubt sein (PasswordAuthentication Yes).


    Beim Test eben haben wir aber festgestellt, dass Debian das scponly-Binary unter /usr/bin/scponly ablegt, der passwd-Eintrag als Shell aber /bin/scponly verwendet. :-| Wir werden das gleich mal im dazugehörigen Lua-Script korrigieren.
    Die Passwd-Einträge können Sie mit folgendem Befehl korrigieren:

    Code
    sed -i -e 's/\/bin\/scponly$/\/usr\/bin\/scponly/' /etc/passwd


    Bitte mal den Status bei Wheezy prüfen. Hier gibt's scponly nämlich nicht mehr in den Standard-Repos. Außerdem will ich nicht das ein Reseller sich oder seinen Kunden /bin/bash als Shell genehmigen darf, wenn ich ihm lediglich scp/sftp erlaube. Bitte fixen!

  • Wunschliste

    Zitat


    - Dateimanager


    * FTP/ SFTP/ FTPS
    * http://elfinder.org
    * ajaxplorer


    Zitat


    - Service Neustarten über die GUI (Apache, MySQL, etc.)


    Webmin



    Zitat


    - Mailinglisten


    * Mailman http://www.liveconfig.com/de/f…s/1276-liveconfig-mailman
    * Sympa



    Zitat


    - eigene Error Seiten


    Global? => /etc/apache2/apache2.conf bzw. /etc/httpd/conf/httpd.conf o.a.
    Domain-spezifisch => hmm, macht in LC vielleicht Sinn



    Zitat


    - Globaler Webmail Client (webmail.*)


    Das schafft denke ich jeder selbst ohne extra GUI.



    Zitat


    - eigene Anwendungen


    Ja, ist bereits erwähnt worden.

  • Debian Package unter OS X entpacken

    Ist mir nun schon mehrmals auf einem OS X 10.9.4 (13E28) aufgefallen:







    Code
    $ port info binutils
binutils @2.24 (devel)

  • Wildcard bzw. Catchall-Weiterleitung einschränken.

    Die Idee hatte ich vor einiger Zeit auch schon. Weiterleitungen nach Extern machen m.E.n. die meisten Probleme, denn hier trage ich für den Versand des Spams die Verantwortung. Möchte der Kunde Catch-All ohne Weiterleitung nutzen kann er das ja gerne machen.


    Vielleicht könnte man hier anhand der Empfänger-Domain prüfen. Catch-All für Benutzer komplett deaktivieren zu können wäre denke ich auch nicht verkehrt..

  • Leerzeichen bei Domain eingaben automatisch löschen

    Ist das Risiko nicht höher das hier der Benutzer denn nicht einem Schreibfehler unterliegt?


    Man müsste denke ich auf jeden Fall noch eine Abfrage durchführen ob der Benutzer denn wirklich dieser (automatischen) Korrektur zustimmt. Nicht selten bringen einem solche automatischen Korrekturen auch Ärger (und Beschwerden :) ).