Beiträge von kk

    Sehr gute Idee - das sollte wirklich die meisten Probleme lösen.
    Bei HISTFILE soll es aber vermutlich "~/priv/.bash_history" heißen (statt "~/.bash_history").

    Maybe you're using suPHP if your sites are slow?
    You can check the configured PHP mode quite simple:

    Code
    grep "PHP configuration" /etc/init.d/sites-available/*.conf


    However, using an opcode cache is always a good idea as long as you use mod_php or FastCGI. The most straightforward way to enable it is by creating a file named /etc/php5/conf.d/xcache.ini with all the required settings - this way is will work automatically for every subscription.

    ich bekomme bei folgenden App Anwendungen Fehlermeldungen. Apache wird mit Liveconfig verwaltet.


    Grundsätzlich: ohne weitere Hinweise aus den einschlägigen Log-Dateien (Apache errorlog, suphp.log, ...) oder zumindest dem Hinweis, welche Distribution genau eingesetzt wird, können wir auch nur raten.


    Wenn ich mich aber richtig erinnere, setzen Sie CentOS 6 ein? Die meisten der genannten Probleme treten dann auf, wenn PHP als Apache-Modul läuft - spricht, wenn suPHP nicht installiert/konfiguriert ist.
    Um die vielen Supportanfragen in dieser Richtung künftig zu reduzieren liest LiveConfig ab sofort selbständig die Liste der aktivierten Apache-Module aus und zeigt ggf. eine Warnmeldung an wenn etwas fehlt (Update steht in Kürze bereit). Außerdem wird der AppInstaller noch mal auf Kompatibilität mit mod_php überprüft (prinzipiell können Anwendungen auch so installiert werden, dass diese mit mod_php laufen, ein "Umschalten" zwischen mod_php und suPHP/FastCGI ist dann nur noch nicht ohne weiteres möglich, da jeweils Verzeichnisrechte angepasst werden müssen)


    Zitat

    Wie ist das mit den Aktualisierungen der APPs‘ gedacht? Joomla beispielsweise ist nicht die neueste Version.


    Joomla steht in v2.5.8 zur Verfügung - soweit ich weiß ist das die neueste Version, die für "normale" Anwender empfohlen wird. Eine Verwaltung verschiedener Versionen innerhalb einer Anwendung ist aber schon geplant (so dass z.B. auch verschiedene Typo3-Versionen gewählt werden können).


    Zitat

    Das Zufallspasswort beim Installieren zeigt stets nur Buchstaben an. Sicherer ist Buchstaben und Zahlen.


    a) Zahlen an sich machen ein Passwort nicht sicherer (ein häufig verbreiteter Irrglaube).
    b) Das zufällig generierte Passwort enthält ab und zu auch mal Zahlen oder Sonderzeichen (einfach öfter mal auf den "Zufall"-Button klicken)
    c) Auch wenn die Passwort-Erzeugung recht simpel wirkt - dahinter steckt ein recht aufwendiges Verfahren (FIPS-181), welches wirklich möglichst zufällige und dennoch halbwegs phonetisch sinnvolle Passwörter ausspuckt. Und das ist um ein Vielfaches sicherer als z.B. "emma7" oder "bayern2012". ;)


    Noch was zum Anwendungs-Installer: bei einigen Anwendungen (insbes. MediaWiki) kann die Installation - je nach Performance des Servers - eine ganze Weile dauern. Standardmäßig ist in der php.ini oft eine maximale Laufzeit von zB. 30 Sekunden angegeben, welche in solchen Fällen überschritten werden kann. Im nächsten Update hebelt der Application-Installer diese Limits aus, um zuverlässiger arbeiten zu können.
    Ich gebe dann an dieser Stelle noch mal Bescheid, sobald das Update getestet werden kann.


    Viele Grüße


    -Klaus Keppler

    Wir machen das ja auch nicht, weil wir die Benutzer übermäßig einschränken möchten, sondern weil es schlicht nicht anders geht ohne massiv in das System einzugreifen.
    Für eine sichere Hostingumgebung (suexec/suphp) ist es unumgänglich, dass das Home-Verzeichnis entweder dem Kunden oder "root" gehört. Dem Kunden kann man das nicht übereignen, da sonst o.g. Sicherheitsprobleme auftreten - bleibt also nur die Variante mit "root".
    Eine Alternative würde darin bestehen, die komplette Verzeichnisstruktur aufzudröseln und alle nicht Webspace-relevanten Daten (Logfiles, Statistikdateien, Konfigurationsdateien usw. - praktisch alles außer "apps" und "htdocs") in andere Verzeichnisse zu verschieben. Das bringt dann aber auch wieder andere organisatorische Nachteile mit sich.
    So bleibt es letztendlich also ein Kompromiss aus Sicherheit und Komfort, wie die Verzeichnisse organisiert sind.

    Die E-Mail-Passwörter sollten ausschließlich über LiveConfig geändert werden (E-Mail-Verwaltung).
    Gespeichert sind diese dann übrigens in /etc/dovecot/passwd, von manuellen Eingriffen dort raten wir aber dringend ab.


    Viele Grüße


    -Klaus Keppler

    Soweit ich sehe ist die einzige Möglichkeit den Besitzer des Webroot Ordners auf den dazugehörigen Vertragsuser zu ändern.


    NEIN - das sollten Sie besser nicht machen, da das erhebliche Sicherheitsrisiken mit sich bringt. Unter anderem kann der Benutzer dann direkt in der Apache-Konfiguration herumpfuschen indem er eine ~/.httpd.conf anlegt, er kann alle PHP-Einstellungen ändern (indem er ~/conf umbenennt und ein eigenes ~/conf/-Verzeichnis anlegt), usw...


    Damit einzelne Anwendungen im Home-Verzeichnis schreiben dürfen, legen Sie die entsprechenden Verzeichnisse/Dateien als "Dummy" an und geben dem Kunden dafür Schreibrechte, z.B.:

    Code
    touch .viminfo .vimrc
    chown web##:web## .viminfo .vimrc


    Viele Grüße


    -Klaus Keppler

    Es gibt im POP3/IMAP-Protokoll keine Möglichkeit ein Passwort zu ändern.
    Wenn irgendein Plugin das machen möche, dann geht das nur, indem es das Passwort im entsprechenden Backend (hier: LiveConfig) ändert.
    Für LiveConfig ist eine SOAP-Funktion zur Aktualisierung der Mailboxeinstellungen geplant, mit der man ein entsprechendes Roundcube-Plugin schreiben könnte. So lange es diese aber nicht gibt, gibt es auch keine andere Möglichkeit, das Passwort zu ändern.

    Roundcube ist genauso wie Thunderbird oder Outlook ein E-Mail-Client - und dieser hat naturgemäß keine Möglichkeit, das E-Mail-Passwort auf dem Server zu ändern.
    Wir arbeiten bereits daran, dass man sich in einer der nächsten Versionen mit seiner E-Mail-Adresse direkt im LiveConfig anmelden und dort dann z.B. Passwort ändern & sonstige Einstellungen bearbeiten kann (Autoresponder, Spam-Filter, etc.).

    Das ist alles so beabsichtigt. Zur Pflege "eigener" php.ini-Einstellungen kommt mit dem nächsten Update der Bereich "PHP-Einstellungen".
    Das mit den Schreibrechten ist ebenfalls so beabsichtigt - der Kunde soll diese Datei ja gerade nicht selber schreiben dürfen (da ja sonst alle Einschränkungen umsonst wären).


    Viele Grüße


    -Klaus Keppler

    Update (r2083) wurde eben bereitgestellt - Entschuldigung für die Unannehmlichkeiten!
    Wir werden wohl besser auch mal für die Previews ein eigenes Testprotokoll einführen...


    Viele Grüße & ein schönes Wochenende


    -Klaus Keppler

    Ab sofort steht die Preview für v1.6.1 (r2082) zum Download bereit.
    Hierbei handelt es sich in erster Linie um Bugfixes und Detailverbesserungen.


    Der Bereich "PHP-Einstellungen" (neu im Hauptmenü) ist noch nicht abgeschlossen - also bitte nicht wundern wenn man da noch nicht weiterklicken kann. ;) Sichtbar ist dieser Punkt übrigens auch nur für den "admin"-Benutzer.


    Viele Grüße


    -Klaus Keppler

    Einen genauen Zeitrahmen kann ich hierfür unmöglich nennen.
    Faktisch schaut es so aus, dass wir zuerst einmal die Zonenverwaltung mit BIND abschließen - sobald das fertig ist, können wir schauen welche Anpassungen für PowerDNS notwendig sind.
    Weitere News folgen also in den nächsten Tagen und Wochen.


    Viele Grüße


    -Klaus Keppler