Beiträge von kk

Prinzipiell sollte das reibungslos funktionieren; bitte posten Sie mal die Ausgabe von "liveconfig --diag" (der Apache-Abschnitt mit allen Modulen & PHP-Versionen genügt)

Übrigens: wenn der Kunde König ist, dann würde ich diesem als sein Dienstleister empfehlen FastCGI zu nutzen, weil das deutlich schneller & ressourcenschonender ist. suPHP hatte seine besten Zeiten als Arbeitsspeicher extrem knapp war und Shared Hosting Server seeeeeehr viele Webspaces gleichzeitig hosten sollten. Man kann mit suPHP auch keinen OpCode-Cache verwenden, etc...

Viele Grüße

-Klaus Keppler

Danke für den Hinweis. Diese Datei ist beim Website-Relaunch leider unter die Räder gekommen
Steht nun wieder online - sorry für die Unannehmlichkeiten!

Viele Grüße

-Klaus Keppler

Äh, sorry, ich meinte nicht die suphp.log sondern die suexec.log (/var/log/apache2/suexec.log)

Tauchen Meldungen in /var/log/suphp/suphp.log auf?
Wenn nein: bitte auch das PHP-Errorlog aktivieren (in LC über Hosting -> Webspace -> php.ini-Einstellungen -> dort "log_errors" auf "on" stellen)
Das PHP-Log landet dann in ~/logs/priv/php_errors.log (kann auch über den Log-Viewer in LiveConfig angezeigt werden)

Zitat von Roman

Guten Abend!

Nach einer Installation von LC auf Debian 8 erhalte ich bei der Installation der PHPMyAdmin-App den Fehler 500. Wo kann ich hier ansetzen?

Wenn ein Error 500 kommt, dann tritt der Fehler i.d.R. noch "vor" PHP auf.
Aktivieren Sie bitte im LiveConfig das Fehlerprotokoll (Hosting -> Webspace -> Fehlerprotkoll aktivieren). Nach ca. einer Minute rufen Sie dann die phpMyAdmin-URL erneut auf - es sollte dann einen Eintrag in der error.log geben (die können Sie sich ebenfalls über LiveConfig "live" anzeigen lassen)

Wenn es sich um einen allgemeinen Fehler handelt ("Premature end of script headers...") dann wäre wichtig, ob Sie PHP mit suPHP oder mit FastCGI ausführen.
In allen Fällen müssen natürlich die Pakete "php5-cgi" und "apache2-suexec" installiert sein, bei FastCGI zudem noch "libapache2-mod-fcgid". Wichtige Log-Dateien sind dann die /var/log/suphp/suphp.log und /var/log/apache2/error.log

Viele Grüße

-Klaus Keppler

Kurzes Update: der Issue Tracker (Redmine unter https://www.liveconfig.com/dev/) sowie das Übersetzungsportal "Pootle" (https://www.liveconfig.com/pootle/) laufen derzeit noch nicht - hier macht die Umstellung von lighttpd auf NGINX leider deutlich mehr Probleme als erwartet.

Wir werden das im Laufe der kommenden Woche angehen - bis dahin bitte um um Verständnis und etwas Geduld.
Die "normale" Website, das Forum, Lizenzportal und SOAP-API laufen aus unserer Sicht soweit reibungslos. Die neue Website wurde für mobile Darstellung verbessert, insgesamt aufgeräumt & entrümpelt und die meisten Inhalte nun auch auf Englisch bereitgestellt. Die Wissensdatenbank (Knowlede Base) wurde durch ein Wiki abgelöst (Verlinkung und KB-Redirects folgen noch). Außerdem fehlen noch Handbuch & Shop auf Englisch.

Viele Grüße

-Klaus Keppler

Hallo,

kurz zur Information: in den nächsten zwei Stunden stellen wir auf eine komplett neue Website um. Das Forum und der Issue Tracker laufen auf getrennten Systemen, da wird es daher eine Zeit lang zu Darstellungsfehlern kommen bis das CSS entsprechend aktualisiert und die Templates ausgetauscht sind.

Wenn die Umstellung abgeschlossen ist und keine Fehler mehr auftreten sollten, werde ich hier noch mal kurz Bescheid geben.

Viele Grüße

-Klaus Keppler

Zitat von Umbriel

Hab heute morgen zu meiner letzten Idee noch eine .dpkg-old Datei gefunden, die anscheinend von LC irgendwann man überschrieben wurde.

Eine .dpkg-old wird dann erzeugt, wenn Sie z.B. das Apache-Paket aktualisieren und die von LiveConfig erzeugte Konfiguration mit der vom Debian-Paket überschreiben (also genau anders herum). Wenn es Änderungen an Konfigurationsdateien gibt, wird bei einem Update nachgefragt, ob Sie die bestehende Konfiguration beibehalten oder überschreiben wollen - Standard ist "beibehalten" - Sie haben dann vermutlich "überschreiben" gewählt (so wurde die bestehende (LiveConfig-)Konfiguration in die .dpkg-old weggesichert).

Zitat

Allerdings,
/var/www/web01/htdocs/unterordner/kundenzugriff1 (protected2: User1, User2) (domain: kunde1.example.com)
/var/www/web01/htdocs/unterordner/kundenzugriff2 (protected3: User1, User3) (domain: kunde2.example.com)

funktioniert auch weiterhin nicht für User1.

Die von LC erstellten <Directory> Einträge aus meiner web01.conf:

Da ist etwas falsch - wenn User1 auch Zugriff auf "kundenzugriff1" bzw "kundenzugriff2" haben soll, dann muss der bei "Require user" auch mit drin stehen.
Prüfen Sie bitte noch mal in LiveConfig, ob Sie User1 wirklich zum jeweiligen Ordner hinzugefügt haben. Das sollte dann so aussehen:
forum.liveconfig.com/cms/attachment/13/

Hallo,

Zitat von Umbriel

/var/www/web01/htdocs (domain: example.com)
/var/www/web01/htdocs/unterordner (protected1: User1)
/var/www/web01/htdocs/unterordner/kundenzugriff1 (protected2: User1, User2) (domain: kunde1.example.com)
/var/www/web01/htdocs/unterordner/kundenzugriff2 (protected3: User1, User3) (domain: kunde2.example.com)

Ich habe mal genau diese Struktur auf einem Debian 8 eingerichtet und kann keinerlei Probleme feststellen.
User1 kann beide Websites (kunde1.example.com, kunde2.example.com) öffnen, die anderen beiden User nur jeweils eine (User2 -> kunde1, User3 -> kunde3).

Vielleicht hatte Ihr Browser noch irgendwelche Zugangsdaten gespeichert, was zu Fehlern führte? Ggf mal Cache leeren bzw. mit einem Browser im Privat-Modus oder einem anderen Browser testen.
(wir testen sowas übrigens immer mit curl oder lynx auf der Konsole)

Zitat

Was mir heute morgen noch aufgefallen ist:
In sites-available existiert eine Konfiguration "000-default", die offensichtlich von liveconfig zuletzt bearbeitet wurde, aber nicht aktiviert ist (ich gehe mal davon aus, dass liveconfig diese normalerweise aktivieren würde).

Das ist definitiv ein Fehler. Diese Datei sollte unter Debian 8 "000-default.conf" heißen und aktiviert sein.
Haben Sie den Rechner neu aufgesetzt oder von einer früheren Debian-Version aktualisiert?
Benennen Sie diese Datei bitte um (in 000-default.conf) und aktivieren Sie diese (a2enmod 000-default).

Zitat

Möchte ich diese nun manuell aktivieren, stürzt Apache2 mit der Fehlermeldung ab, dass Port 443 nicht zugewiesen werden konnte.

Dann läuft auf Port 443 wohl noch irgendein anderer Dienst. Was liefert "netstat -tlpn | grep 443"?

Viele Grüße

-Klaus Keppler

Natürlich, allerdings müssen Sie das aktuell noch "von Hand" einrichten.
(mit v1.9.0 macht LiveConfig das dann automatisch, wenn im jeweiligen Zertifikat eine OCSP-URL angegeben ist).

Bei Debian wäre /etc/apache2/conf.d/ssl.conf der richtige Ort für globale Einstellungen (die genauen Einstellungen habe ich gerade nicht auswendig da).

Zitat von antondollmaier

LC speichert das Postfach-Passwort nicht in der (My)SQL-Datenbank, sondern nur in der passwd-Datei? Wie kommt das Passwort denn aus der GUI raus und da rein? ..

Quantenphysik und Feenstaub.

Spaß beiseite: sobald der Eintrag in die passwd erfolgreich geschrieben wurde, löscht LC das (nur temporär gespeicherte) Passwort aus seiner Datenbank (nach dem Prinzip: sobald wir das Passwort nicht mehr brauchen, wollen wir es da auch nirgendwo mehr gespeichert haben).
Wir planen aber, das mittelfristig zu ändern, dass die Passwörter (mit starker Krypto, also mehr als nur ein Blowfish) trotzdem im LiveConfig bleiben, um z.B. so Passwort-Dateien neu generieren zu können, oder auch den Export/Import von Postfächern inklusive Passwort zu ermöglichen. So lange das Krypto-Konzept dafür aber nicht abgeschlossen ist, speichern wir keine ungehashten Passwörter.

Zitat

Rsync dürfte übrigens die deutlich einfachste Methode sein, die Mails zu übertragen. Da braucht es kein IMAP-Passwort.

rsync betrifft nur den Kopiervorgang - so oder so muss trotzdem aus der alten und der neuen /etc/dovecot/passwd das Quell- bzw. das Zielverzeichnis herausgesucht werden.

Oha... danke für den Hinweis. Das betrifft in die "non_smtpd_milters" in Postfix - wird also bei lokal per sendmail eingereichten Mails ausgelöst.

Es gibt da nun zwei Möglichkeiten:
- (a) entweder wir verlagern den OpenDKIM-Socket nach /var/spool/postfix/opendkim/, oder
- (b) wir deaktivieren OpenDKIM komplett für lokal erzeugte Mails.
Variante (c) wäre, OpenDKIM auf einem IP-Socket (127.0.0.1:xxxxx) laufen zu lassen - bei Shared-Hosting-Systemen ist das aber eher ein Risiko, da jeder lokale User somit Zugriff darauf hat.

Nach einer kurzen Besprechung hier tendieren wir eher zu (b), da mit DKIM bestätigt wird, dass die unterzeichnete Mail tatsächlich vom angegebenen Server stammt. Da aber jeder lokale User eine beliebige Absenderadresse verwenden kann, wäre es auch möglich, Mails von einer auf dem selben Server gehosteten fremden Domain inklusive DKIM-Signatur zu erzeugen.

Andererseits ist ja gerade für PHP-Massenmail-Scripte usw. DKIM interessant, um Newsletter etc. besser durch Spamfilter ins Ziel zu bekommen. So lange Mailings nicht hauptsächlich per SMTP-Auth an ein "ordentliches" SMTP-Relay eingeliefert werden, wäre das also eher wieder ein Rückschritt.

Ich würde mich also auf ein kurzes Feedback freuen, was unsere Anwender bevorzugen würden.

Ah, ok. Das ist seit v1.9.0-r3595 bereits behoben (die Preview wird - wenn alles glatt läuft - heute Abend wieder aktualisiert; es gab ziemlich viele weitere Änderungen darin).

Es ist derzeit nicht möglich, die Einstellungen mit vertretbarem Aufwand innerhalb der LiveConfig-Datenbanken zu kopieren (das Datenschema für die Postfächer verteilt sich auf die Tabellen MAILBOXES, MAILFORWARDS, MAILALIASES, MAILSERVER, POP3IMAPSERVERS und SERVERS).

Bei 30-40 Postfächern wäre das einfachste Vorgehen, die Postfächer auf dem neuen System im LiveConfig anzulegen (das Passwort ist dabei erst mal egal, kann ein Zufallspasswort sein).
Dann für jede angelegte Adresse auf dem *neuen* Server in /etc/dovecot/passwd das Zielverzeichnis herausfiltern, und dort die Inhalte aus dem Verzeichnis vom alten Server (dort ebenfalls in /etc/dovecot/passwd gucken) kopieren. Zum Schluß noch den Passwort-Hash aus der "alten" dovecot/passwd in die neue dovecot/passwd kopieren - fertig.
Mit 'nem kleinen Perl-Script lässt sich das sicher stark vereinfachen (ich würde den kompletten Ordner /var/mail sowie die alte /etc/dovecot/passwd auf den neuen Server in ein temporäres Verzeichnis kopieren und dort dann mit 'nem Script in die neuen Verzeichnisse umsortieren lassen).
Noch eine Alternative: die alte /etc/dovecot/passwd wegsichern, alle Mailpasswörter zurücksetzen (kann man z.B. auch direkt in der passw mittels sed auf 'nen Klartext-Wert setzen), dann mit imapsync alles auf den neuen Server kopieren (dort beim Anlegen der Postfächer natürlich immer ein temporäres Standardpasswort angeben). Wenn alles abgeschlossen ist, die Passwörter aus der gesicherten dovecot/passwd-Datei wiederherstellen.

Wichtig ist eben nur, dass sich die Verzeichnisse für die einzelnen Postfächer auf dem alten und dem neuen Server unterscheiden können (/var/mail/<Vertrag>/<Nummer>, die Nummer wird fortlaufend nach Reihenfolge der Postfach-Erstellung vergeben)

Viele Grüße & viel Erfolg

-Klaus Keppler

Könnten Sie das bitte etwas konkreter beschreiben?
Welche Tabelle genau hatten Sie offen (also welche LiveConfig-Seite), und was genau meinen Sie mit "wird garnichts angezeigt" - ist die Tabelle dann leer, die Seite leer, ...?
Zudem: welchen Browser haben Sie verwendet? Gibt es eine JavaScript-Fehlermeldung?

Leeren Sie ggf. mal den Browser-Cache (bei Preview-Versionen kann es sein, dass die JS/CSS-Dateien bei Änderungen nicht automatisch im Cache aktualisiert werden).

Zitat von Umbriel

Für diesen habe im Punkt "Webspache" einen Unterordner mit einem Verzeichnischutz versehen ("User1", "****"). In diesem Ordner befinden sich dann weitere Unterordner, denen die ich auch mit einem Verzeichnisschutz versehen habe ("User2", "****"). Zusätzlich habe ich diesen Verzeichnissen User1 als Login hinzugefügt. Problem: Das wird ignoriert.

Habe ich das richtig verstanden, dass Ihre Struktur etwa so aussieht:
/pfad1/ => User1
/pfad1/pfad2 => User1, User2

?

Zitat

Der "# password-protected directories:" block steht noch dazu in jedem "<VirtualHost>" Block - tut das Not?

Ja, tut es - damit wird verhindert, dass man mit Aliasen, Symlinks, Proxy-Regeln o.ä. in einem anderen VirtualHost einen Passwortschutz umgeht.

Zitat

Als weiteres Problem tritt dabei auf, dass anscheinend bei jeder x-beliebige, nicht zugewiesene Subdomain bei diesem Vertrag und bei weiteren Verträgen nun diesen Verzeichnis-Login für User2 abfragt, obwohl der Unter-Unterordner gar nicht zu diesen Verträgen gehört ...

Bitte bringen Sie ein genaues Beispiel, wie Ihre Verzeichnissstruktur aussieht und geschützt ist - ich verstehe das nicht so ganz (z.B. was Sie mit einer "nicht zugewiesenen Subdomain" meinen). Alternativ schicken Sie uns Screenshots der Passwortschutz-Einstellungen an support@liveconfig.com - wir schauen uns das gerne mal an.

Viele Grüße

-Klaus Keppler

Welche main.conf meinen Sie?
Und um welche Distribution geht es?

Unter Debian/Ubuntu wäre z.B. für globale Einstellungen das Verzeichnis /etc/apache2/conf.d/ bzw. conf-enabled der richtige Ort; für Module ggf. /etc/apache2/mods-enabled/<Modul>.conf

Einfachste Lösung wäre dann, dem Vertrag CGI zu erlauben (Vertragseinstellungen oder Angebot im LiveConfig bearbeiten).

Über den Sinn des ganzen reden wir an dieser Stelle besser mal nicht...

<FilesMatch "\.html$">
    Options +ExecCGI
    SetHandler fcgid-script
</FilesMatch>
FcgidWrapper /var/www/web1/conf/php5/php-fcgi-starter .html

Im Grunde also das konfigurieren, was bislang für .php in der vHost-Konfiguration steht.

Zitat von antondollmaier

In der Liste fehlt Debian Wheezy

Ups... Stimmt natürlich. Danke für den Hinweis, werde ich gleich aktualisieren.

Zitat

Gibt es dann für jeden Dienst eigene DH-Parameter oder werden die für jeden Host berechnet und dann bei allen Services deployed?

Letzteres fände ich interessanter.

Wir werden pro Dienst einzelne DH-Parameter erzeugen. Sooo gigantisch ist der Aufwand ja auch wieder nicht.

Zitat

Kriegen wir in dem Zusammenhang dann auch automatische Updates der von LC verwalteten Config-Dateien hin? In der Vergangenheit gab es ja einige Verwirrungen, beispielsweise bei aktualisierten Ciphern, geänderten SSL-Zertifikaten oder Änderungen, die in einer neuen LC-Version mitgebracht wurden.

Ja, das ist etwas kniffliger. Ob das in diesem Update schon mitkommt kann ich noch nicht versprechen, ist aber so geplant. Konkret hängt da die Sache mit dem Versand von Infomails durch LiveConfig mit dran (wir möchten nämlich nach einer Config-Aktualisierung zumindest mal eine Mail an den Admin zur Info senden).
Noch eleganter wäre es, wenn der Admin entscheiden kann, ob er anstehende Änderungen an der Konfiguration automatisch übernehmen oder nur darauf hingewiesen werden möchte.

Viele Grüße

-Klaus Keppler