Beiträge von kk

Zitat von aziegler

Wir wünschen uns dringend anpassen zu können, was dem User für die PHP-Version angezeigt wird.

Kein Problem, lässt sich einrichten. Wir nehmen das einfach als zusätzlichen (optionalen) Parameter in die addPHP-Funktion (Lua) auf. Dürfte es sogar noch in die 1.7.4 schaffen.

Zitat

1) Besteht die Möglichkeit, den Subject-Rewrite ganz wegzulassen und stattdessen nur entsprechende Header zu setzen?

Wenn der Warn-Schwellwert auch auf 999 gesetzt wird, werden nur die Header hinzugefügt.

Zitat

2) Kann man einstellen, dass dies standardmäßig aktiv ist? (was ja bei Greylisting leider auch nicht geht... evtl. siehe unten)

Ein Fall für LCDEFAULTS. Wird in die ToDo-Liste aufgenommen.

Zitat

eine GUI ist hierfür wirklich nicht wichtig, aber eine Liste der möglichen Einstellungen!

Im nächsten Handbuch ist eine solche Liste enthalten.

Zitat

Ist hiermit auch einstellbar, dass Werte nicht von Kunden überschrieben werden dürfen? Das würde auch einiges an Support-Arbeit ersparen.

An sich wären diese Einstellungen ohnehin nur durch den "admin"-Account änderbar (wichtig z.B. für "Managed Server"). Werden wir mal im Auge behalten.

Viele Grüße

-Klaus Keppler

Hallo,

pro Vertrag ist leider nur ein Systembenutzer möglich. Das hängt mit der Absicherung der Zugriffsrechte zusammen: die Webspace-Verzeichnisse "gehören" dem Kunden, der Webserver hat nur Leserechte darauf (Eigentümer also z.B. web1:www-data, Mode=0750). So ist sichergestellt, dass keine fremden Accounts da hinein dürfen.
Würde man das htdocs-Verzeichnis nun einer Kundengruppe übereignen, dann müsste als Besitzer der Webserver eingetragen werden (also www-data:web1). Das bringt aber erhebliche Sicherheitsrisiken mit sich, suPHP/suexec funktioniert nicht mehr, u.v.m.

Es gibt verschiedene theoretische Workarounds:
- den Webserver Mitglied jeder Kundengruppe werden lassen (Anzahl der Gruppenmitgliedschaften ist aber begrenzt, außerdem ist das wieder ein Sicherheitsproblem)
- Verwendung von erweiterten Attributen bzw. ACLs (wird nicht mit jedem Filesystem unterstützt)

Mir ist derzeit kein Berechtigungsschema bekannt, bei dem mehrere Benutzer einer Gruppe sicher Zugriff auf einen Webspace bekommen könnten, ohne dass andere User auch dort "hinein können", gleichzeitig aber der Webserver dort Leserechte hat.
Die Variante mit ACLs wäre wohl noch am vernünftigsten - vielleicht ließe sich das ja optional einrichten.

Viele Grüße

-Klaus Keppler

Am einfachsten ist es, wenn er sich hierfür einen Cron-Job einrichtet.
Folgender Befehl löscht z.B. alle Dateien die älter als 24 Stunden sind:

find /var/www/web###/tmp -mtime +1 -delete

Die Preview wurde eben auf v1.7.4-r2995 aktualisiert. Die Änderungen sind hauptsächlich Bugfixed und Verbesserungen. Im Bereich "Rundmail" kann nun eine Testmail (an die angegebene Adresse) versendet werden, Massenversand geht noch nicht.

Unter anderem wird nun auch eine abweichend eingestellte PHP-Version für HTTPS berücksichtigt. Außerdem wurde ein Problem mit fehlenden Berechtigungen nach dem Anlegen von Verträgen via SOAP-API beseitigt.
Last but not least hatte lclogparse manchmal die Rotation von beobachteten Logs nicht mitbekommen; daher wurde manchmal der Mailtraffic ab einem bestimmten Zeitpunkt nicht mehr aktualisiert.

v1.7.4 hat inzwischen "Feature Freeze", d.h. es kommen keine neuen Funktionen mehr hinzu, die begonnenen Bereiche werden abgeschlossen. Bis Ende dieser Woche möchten wir v1.7.4 für den Produktiveinsatz fertig haben.

Viele Grüße

-Klaus Keppler

Auf die Termindiskussion gehe ich nicht mehr ein. Sie können aber versichert sein, dass wir hier nicht Däumchen drehen. Wenn ein Update nicht gleich herauskommt, dann garantiert nicht deshalb, weil die Anziehungskraft des Biergartens die Nachfragen im Forum übertrifft.

So, nun zum Thema:

Zitat

Wenn nur eine angegeben ist werden zumindest im vhost noch ein falscher FcgidWrapper Pfad ('php5' / Standard) hinterlegt.

Können Sie den Fehler genauer beschreiben? Bei FastCGI sieht die vHost-Config etwa so aus:

[...]
        FcgidWrapper /var/www/web1/conf/php5/php-fcgi-starter .php
        FcgidWrapper /var/www/web1/conf/php5/php-fcgi-starter .php5
[...]

Sieht für mich soweit normal aus.

Zitat

Der Info-Text scheint im "Subdomain bearbeiten"-Dialog noch undefiniert zu sein:

Ist im nächsten Update mit drin.

Viele Grüße

-Klaus Keppler

Um die Zertifikate zu aktualisieren, unter "Serververwaltung" -> "Mail" jeweils bei Postfix & Dovecot die Einstellungen erneut speichern.
Wir prüfen derweil mal, warum LC die nicht schon beim Neuspeichern der Zertifikate (in der Zertifikatsverwaltung) austauscht.

Danke für den Hinweis - hier steckte ein Fehler im WSDL (es wurde hier fälschlicherweise die Beschreibung der Funktion HostingMailboxAdd() ausgegeben; tatsächlich verwendet wurden aber die Parameter so wie sie auch in der Dokumentation stehen).
Ist mit v1.7.4-r2993 beseitigt (steht ab heute Abend als Preview bereit).

Danke für den Hinweis - bei SSL-Webspace wurde tatsächlich nur die PHP-Standard-Version genutzt.
Ist mit v1.7.4-r2988 erledigt, das Preview-Update erscheint heute im Laufe des Tages.

Zitat von arnoldB

Bug beim Bericht Top10-Verträge:

Hier hatte die Umstellung unseres Translation-Systems für einen Fehler gesorgt (die erste Übersetzung in einer .po-Datei enthielt fälschlicherweise auch noch den .po-Header). Ist inzwischen gefixed, Update der Preview erscheint im Laufe des Tages.

Hmm, ein Cronjob zum LC-Neustart ist schon eine harte Waffe... eigentlich sollte es gar nicht so weit kommen
Ich schätze mal dass die LC-Oberfläche zwar erreichbar ist, aber keine Aktionen auf dem Server durchgeführt werden? Das deutet darauf hin, dass die Client-Threads irgendwo hängen geblieben sind.

Sie erwähnten, dass Sie dann jeweils Ihren Anbieter kontaktieren. Falls es sich um einen gemanagten Server handelt (auf den Sie also keinen root-Zugriff haben), dann können Sie leider nichts tun - hier wäre es am besten, wenn sich der Anbieter direkt mit uns in Verbindung setzt (einfach anrufen oder Mail an support@liveconfig.com). Wir bräuchten mindestens einen Einblick in die LiveConfig-Logdatei (/var/log/liveconfig/liveconfig.log).

Perfekt wäre es, einen Blick direkt auf einen hängenden LiveConfig-Prozess werfen zu können. Was wir da genau brauchen ist:
- die Liste aller Prozesse, die dem LiveConfig-Client-Prozess untergeordnet sind (also ein Ausschnitt aus "ps auwfx", bei dem alle Childs von "liveconfig [client]" zu sehen sind)
- die Liste aller Client-Threads zu diesem Zeitpunkt: "ps aux -L | grep liveconfig"
- die Liste aller offenen Dateideskriptoren des Client-Prozesses (siehe /proc/<PID>/fds)

Wenn Sie möchten können wir uns das auch direkt anschauen - wir brauchen dazu keine Passwörter, sondern lediglich einen vorübergehenden SSH-Zugang, siehe https://www.liveconfig.com/de/ssh

Mit freundlichen Grüßen

-Klaus Keppler

Zitat von Ackermann-EDV

Nur wenn ich nun auf Kunde gehe fehlen da die Daten, finde einfach die Zuordnung zu den Kunden nicht

Entschuldigen Sie bitte wenn ich da so pingelig nachfragen muss, aber was genau meinen Sie mit "da fehlen die Daten": werden Ihnen als admin gar keine Kunden angezeigt?
Falls da doch Kunden aufgelistet werden, haben diese keine Verträge zugeordnet?
Was passiert, wenn Sie in der Schnellsuche (ganz links, unterhalb der Navigationspunkte) einfach mal "res1" oder den Vertragsnamen eines Endkunden (web###) angeben?

Zitat von Ackermann-EDV

aber auf dem Livecofnig Server sehen ich keine Kunden oder Accounts

Wo genau sehen Sie keine Accounts? Im LiveConfig? Oder keine Systemaccounts?

Wenn Sie sich als "admin" anmelden, sollten Sie nach dem Import einen Kunden finden, der den Vertrag "res1" besitzt. Wenn Sie sich wiederum als "res1" anmelden (bzw. eine Session öffnen), dann sollten Sie bei diesem alle Endkunden finden.

Ein zweiter Import wird genauso wie ein manuelles Anlegen fehl schlagen, wenn die Daten bereits erfolgreich importiert wurden.

Die Preview wurde eben aktualisiert (v1.7.4-r2986). Die wichtigsten Änderungen sind:

• Übersetzungen wurden aktualisiert (mehr dazu gleich noch in einem separaten Thread)
• die Spamfilter-Einstellungen können nun auch direkt durch Mail-User bearbeitet werden (also wenn man sich mit der E-Mail-Adresse im LiveConfig anmeldet)
• ebenso werden die Spamfilter-Einstellungen nun auch in der SOAP-API (HostingMailboxAdd/HostingMailboxEdit) berücksichtigt
• es gibt nun systemweite Voreinstellungen: in der Tabelle LCDEFAULTS können einige Standardwerte hinterlegt werden (z.B. die hier häufig gewünschten Schwellwerte für SpamAssassin). Im ersten Schritt werden nur einige Maileinstellungen dort verwaltet, wird nun aber stückweise ausgebaut (u.a. dann für Passwort-Policies Längerfristig sollen diese Einstellungen dann auch über die GUI bearbeitbar sein.
  Ach ja, nach Änderungen in LCDEFAULT muss LC derzeit noch neu gestartet werden (wird nur beim Programmstart eingelesen).
• die Maske für E-Mail-Rundschreiben an alle Kunden ist fertig (gerne mal anschauen) - der Versand ist aber noch nicht implementiert (sollte bis nächste Woche abgeschlossen sein).

Viele Grüße

-Klaus Keppler

Which distribution do you use?

APC macht mit suPHP keinen Sinn, da bei suPHP zwangsweise bei jedem Aufruf eine neue ("frische") PHP-Instanz ausgeführt wird - Caching ist da nicht möglich.

Zur .user.ini bitte das Handbuch lesen: http://php.net/manual/de/configuration.file.per-user.php
Eine gültige Einstellung wäre also z.B. ".user.ini", und nicht ein vollständiger Name zu einer php.ini-Datei.

In der phpinfo-Ausgabe bekommen Sie im ersten Abschnitt ja angezeigt, welche php.ini-Datei konkret verwendet wurde ("Loaded configuration file"). Prüfen Sie dann einfach mal, was dort drin steht.

Spontan kann ich mir vorstellen, dass Sie noch eine "manuell" gepflegte php.ini-Datei haben (~/.php5/php.ini). Falls das so ist, löschen Sie diese Datei einfach und speichern die Webspace-Einstellungen bzw. den Vertrag im LiveConfig einfach noch mal neu ab.

Um das kurz klar zu stellen: LiveConfig löscht eine vHost-Konfiguration nur dann, wenn keine einzige Domain mehr damit effektiv konfiguriert ist. Das kann meines Wissens nur dann vorkommen, wenn Sie in der default-IP-Gruppe alle IPs deaktivieren.
"Von alleine" fasst LiveConfig diese Dateien jedenfalls nicht an.

Um diese neu schreiben zu lassen, nehmen Sie einfach irgendeine Änderung an den IP-Gruppen vor - danach werden alle betroffenen vHosts neu geschrieben.

Viele Grüße

-Klaus Keppler

Zitat von PatrickGreger

Nur seit heute nach einem System Update will der "Lcsam" nicht mehr und begründet das mit der folgenden Fehlermeldung:

warning: connect to Milter service unix:/var/run/lcsam.sock: No such file or directory

Das klingt danach dass lcsam nicht läuft. Können Sie das bitte mal in der Prozessliste prüfen? Mit "/etc/init.d/lcsam restart" sollten Sie diesen ggf. (neu) starten können. Falls der Prozess nicht hoch kommt, müsste es Log-Meldungen in /var/log/mail.log o.ä. geben.

Hallo Herr Groh,

ich habe das inzwischen mal auf einem System mit Debian 6 nachgespielt, hier klappt alles.
Wenn Sie als "Endkunde" im LiveConfig angemeldet sind und unter "Hosting" -> "Domains" eine Domain bearbeiten - ist dort auch die exklusiv zugewiesene IP-Gruppe ausgewählt und SSL für den Webspace aktiviert?
forum.liveconfig.com/cms/attachment/12/

Zitat von WebOscar

Bei dem Versuch die Seite via https aufzurufen kommt der Fehler "Fehlercode: ssl_error_rx_record_too_long".

Dieser Fehler tritt dann auf, wenn man per HTTPS versucht auf einen Port zuzugreifen, auf dem nur HTTP läuft.
In diesem Fall also klingt es so, als ob Apache auf dem Port 443 zwar erreichbar ist, dort aber kein SSL aktiviert/konfiguriert ist.

Auch die nachfolgende Beschreibung, dass keinerlei Zertifikate in /etc/ssl abgelegt sind usw. deutet auf fehlende SSL-Anweisungen hin.
Ich prüfe das eben mal in der beschriebenen Reseller-Konstellation und gebe gleich eine Rückmeldung.