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").
Beiträge von kk
-
-
Maybe you're using suPHP if your sites are slow?
You can check the configured PHP mode quite simple: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)ZitatWie 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).
ZitatDas 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. -
-
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.:
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 MySQLWichtig 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
-
Aargh! Danke für den Hinweis. Wird sofort korrigiert, Update kommt gleich...

-
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
-
Danke für den Hinweise - wurde mit v1.6.1-r2082 beseitigt (#68).
Update wird in den nächsten 2-3 Stunden online gestellt. -
Ja, das ist in dem gestern erstellten Update berücksichtigt; sobald die vsftpd-Konfiguration erzeugt/aktualisiert wird, wird künftig auch die passwd.db angelegt falls diese noch nicht vorhanden ist.