Beiträge von kk

Die Installation von MediaWiki dauert ziemlich lange (großer Download von vergleichsweise "langsamen" Server, Entpacken des großen Archivs, ...) - unserer Erfahrung nach wird daher meist das PHP-Script vorzeitig beendet, weil die max_execution_time aus der Standard-PHP.INI überschritten wird.
Wir arbeiten bereits an einer Lösung (sieht dann so aus, dass diverse Limits wie zB. max_execution_time und memory_limit explizit auf höhere Werte eingestellt werden, wenn das Installations-Script aufgerufen wird).
Das Löschen nicht erfolgreich installierter Anwendungen ist hier in einer Testumgebung schon behoben, wir werden diese Funktion in den nächsten Tagen in die Preview-Version übernehmen (anders gesagt: voraussichtlich am Montag gibt es ein Update, mit dem das dann möglich sein sollte)

Viele Grüße

-Klaus Keppler

Das Joomla-Team hatte offenbar ein Update der deutschen Version (2.5.8-2) herausgebracht und dabei den Download-Link der "alten" Version gelöscht. Daher konnte der Application-Installer die benötigte Datei gar nicht erst herunterladen.
Wir haben den Installer entsprechend aktualisiert; nach einem LiveConfig-Neustart oder nach max. 24 Stunden ist das neue App-Repository verfügbar.

Viele Grüße

-Klaus Keppler

Ebenfalls ein fröhliches und gesundes Neues Jahr!

In der Tat ist "nur" Urlaubszeit - nacheinander waren/sind alle Leute von uns im wohlverdienten Urlaub, ab Montag (07.01.) ist wieder Normalbetrieb.
Ich selbst bin aus familiären Gründen (es gab Nachwuchs :)) noch einige Zeit tagsüber nur eingeschränkt erreichbar, auf die Entwicklung hat das aber keine Auswirkungen.

Das nächste Update (Preview) mit den neuesten Funktionen ist bereits für Ende kommender Woche eingeplant (u.a. Warn-Mails bei Erreichen der Postfach-Quota, viele Detailverbesserungen und einige Bugfixes) - es geht also stetig voran.

Viele Grüße & einen tollen Start ins neue Jahr!

-Klaus Keppler

Zitat von dicker

Ausgabe auf dem Master mit repquota -ag
[...]

Bitte führen Sie "repquota -ag" auf dem Slave (also dem virtuellen Container) aus, nicht auf dem Master (dort spielt das keine Rolle).

Die Funktion gibt es schon seit einer ganzen Weile, offenbar ist das aber noch nicht im Handbuch dokumentiert

Sie müssen eine custom.lua anlegen und dort folgenden Befehl einbauen:

apache.CONFIGMODE='rewrite'

(siehe Kopf-Bereich in der apache.lua - dort ist das grob beschrieben)

Viele Grüße

-Klaus Keppler

Zitat

Niemals auf Terminangaben von kk verlassen.

Wo oder für wann genau war noch mal das WHMCS-Plugin versprochen? Ich weiß dass ein paar Nutzer ungeduldig darauf warten, wir hatten jedoch auch einige Kommunikationsprobleme mit den Jungs von WHMCS (längere Geschichte, inzwischen sind die wichtigsten Fragen geklärt).

Wenn wir ein Feature zu einem bestimmten Termin versprechen, dann wird das auch zu diesem geliefert (von minimalen Verzögerungen mal abgesehen).

Zitat von noez

Es geht hier aber auch teilweise um ganz simple einfache Mails, die im Oktober verschickt wurden, telefonisch als "offen Bestätigt wurden" und dann bis heute niemals beantwortet wurden.

Ich habe mir Ihre Mails eben noch mal hergeholt. Welche Probleme sind bei Ihnen noch ganz konkret offen?
Seit dem 20.10.2012 gab es keine einzelne weitere Mail von Ihnen - daher bin ich von diesem Posting und der plötzlichen Dringlichkeit doch etwas überrascht.

Zitat

Würde ich, wenn ich könnte wieder von LiveConfig weg ziehen? Ja.

Warum können Sie denn nicht von LiveConfig wegziehen? Die meisten Daten können problemlos über die SOAP-API ausgelesen werden, die Eingriffe in die Serverkonfiguration sind äußerst zurückhaltend und vollständig umkehrbar. Wir möchten, dass LiveConfig-Kunden aus Überzeugung bei uns bleiben, und nicht weil es "nicht anders geht" (das wäre eine ziemlich schlechte Basis).

Und: zu welcher Software möchten Sie denn wechseln, und aus welchem Grund? (rein interessenhalber).

Zitat

Was bringt mir die tollste Software, wenn mich der Chef anlügt? Nein Danke.

Das finde ich schon eine ziemlich dreiste und heftige Unterstellung.
Vielleicht darf ich Sie an den Support am 02.-04. Oktober erinnern, wo wir Sie mit aller Energie bei der Lösung eines Problems binnen kürzester Zeit und völlig unbürokratisch unterstützt haben.

Inwiefern habe ich Sie belogen?

Mit freundlichen Grüßen

-Klaus Keppler

Das Problem ist weniger die SQL-Abfrage als vielmehr die Tatsache, dass Verträge nicht direkt was mit den Kunden zu tun haben, die in der Liste angezeigt werden (und das Suchfeld bezieht sich eigentlich nur auf die in der Liste angezeigten Daten).

Was spricht gegen die Nutzung der Schnellsuche? Die ist genau für sowas gedacht...

Ach so... Geben Sie den Suchbegriff einfach links (unterhalb des Navigationsbereichs) in das Suchfeld ein - so wird auch der Vertrag gefunden.
Eine Suche nach Vertragsnamen in der Kundenliste ist bislang nicht vorgesehen, da ein Kunde ja auch mehrere Verträge haben kann.

Öh - nicht dass wir da nun aneinander vorbei reden: was im Bericht "Kunden-Verträge" in der ersten Spalte ("Vertrag") angezeigt wird, das kann auch in der Schnellsuche gesucht werden.
Falls das bei Ihnen nicht klappt, schicken Sie mir bitte eine genauere Beschreibung, wie bei Ihnen der betroffene Vertrag angelegt ist (also welchem Reseller der ggf. gehört, mit welchem Account Sie suchen, usw.), damit wir das hier evtl. reproduzieren können.

Was genau meinen Sie mit "Vertrags-ID"? Den Vertragsnamen?
Nach dem kann bereits gesucht werden.

Jepp, macht Sinn, wird kurzfristig umgesetzt (voraussichtlich morgen Vormittag).

Viele Grüße

-Klaus Keppler

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.