Beiträge von kk

Bitte kein weiteres PHP4-Bashing - das bringt nichts.
Fakt ist, dass PHP4 bekanntermaßen veraltet ist, aber es gibt nunmal noch viele alte Anwendungen. Genauso gibt es auch noch unzählige COBOL-Anwendungen die >20 Jahre alt sind, aber ebenfalls aus verschiedensten Gründen nicht mal eben neu geschrieben werden können.
Da ein zusätzlich bereitgestelltes PHP4 auch nur per suPHP oder evtl. FastCGI erreichbar wäre und so mit den normalen Benutzerrechten läuft, ist das auch erst mal nicht unsicherer als jedes andere schlecht programmierte CGI-Script.
Die allermeisten Sicherheitsprobleme in PHP bestehen in schlampigem Code und mangelnder Eingabeprüfung - ob man seine SQL-Injections nun mit PHP4 oder PHP5 möglich macht, spielt also keine Rolle.

Zitat von Oliver

Kann ich das Migrationsscript auch nutzen wenn schon Kunden in LiveConfig angelegt sind oder
muss es eine "frische" Installation sein?

Nein, es stört nicht wenn schon Kunden angelegt sind - die Benutzernamen dürfen nur nich kollidieren.
(das Import-Script würde sich da aber ggf. beschweren)

Zitat

Gibt es eigentlich bzgl. PHP "Switcher" schon einen Status wann das in etwa kommen wird?
Mich interessiert hier Hauptsächlich die Möglichkeit zwischen PHP5 und PHP4 zu wechseln.

Bitte für jedes Thema einen eigenen Thread öffnen.
Vorab: in LiveConfig ist das noch nicht integriert - man kann aber auch jetzt schon (unabhängig von LiveConfig) auf dem Server ein PHP4 installieren und durch entsprechende .htaccess-Anweisungen einen anderen PHP-Handler (zB. eben für PHP4) einrichten.

Hallo,

eigentlich lässt sich eine Änderung der E-Mail-Accounts nicht vermeiden. Damit LiveConfig die Postfächer verwalten kann, wird zwingend auch ein Domainname benötigt.
Rein theoretisch wäre es zwar möglich, dass Sie in /etc/dovecot/passwd die entsprechenden Postfach-Benutzernamen umbenennen (von zB. web125p2@example.org in web125p2) - damit könnte sich der Kunde dann zwar am Mailserver anmelden, aber das Passwort und sonstige Einstellungen können nicht mehr in LiveConfig geändert werden.

Wir empfehlen also, die Kunden darüber zu informieren, dass einfach der Domainname an den bisherigen Postfach-Namen angefügt werden soll - das Passwort wird i.d.R. unverändert übernommen.

Viele Grüße

-Klaus Keppler

https://www.liveconfig.com/dev/issues/1

Ok... Touché.

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:

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.

Zitat von dicker

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

Zitat von bfal

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.:

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

Viele Grüße

-Klaus Keppler

Im LiveConfig als "admin" anmelden, dann den Kunden auswählen, Kunden-Session öffnen, dort auf "Benutzer" klicken und den gewünschten Benutzer löschen...

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.

Ah, ok... Das scheint ein Problem im Zusammenhang mit den Großbuchstaben im Benutzernamen zu sein.
Wir lassen uns da kurzfristig was einfallen...

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.).

Ist in Arbeit:
https://www.liveconfig.com/dev/issues/47

Eine erfolgreich gelöschte Subdomain sollte eigentlich wieder neu anlegbar sein.
Gibt es bei Ihnen auffällige Meldungen in /var/log/liveconfig/liveconfig.log?
Welche Distribution setzen Sie ein?

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

Wir haben nun eine ausführliche Anleitung zum Wechsel von SQLite auf MySQL bereitgestellt:
KB#15: Umstellung von SQLite auf MySQL

Wichtig ist vor allem, dass die Standard-Daten aus der MySQL-Datenbank erst alle gelöscht werden, bevor man die Daten aus SQLite übernimmt.

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