Beiträge von kk

Ok, dann scheint der Private Key in der sslcert.pem "kaputt" zu sein.
Entfernen Sie bitte den kompletten Abschnitt von "-----BEGIN PRIVATE KEY-----" bis "-----END PRIVATE KEY-----" daraus und fügen diesen noch mal neu ein (am besten kopieren Sie den aus dem Key-File, das Sie scheinbar mit Apache fehlerfrei nutzen können).
Anschließend prüfen Sie bitte noch mal mit dem o.g. Befehl ("openssl rsa ..."), ob dieser dann korrekt gelesen werden kann.

Bitte senden Sie keine Dateien an DoRob (das hat seine Gründe).

Der Fehlermeldung nach tritt ein Problem beim Laden des Private Key auf. Welche Meldung liefert folgender Befehl:

openssl rsa -in /etc/liveconfig/sslcert.pem -check -noout

Haben Sie Teile der Datei vielleicht unter Windows (bzw. mit einem Windows-Editor) bearbeitet?

Führen Sie bitte mal folgenden Befehl aus, um eventuelle Windows-Zeilenumbrüche zu korrigieren:

sed -i -e 's/\r//' /etc/liveconfig/sslcert.pem

DoRob: Sie sollten den Ball besser mal gaaaanz flach halten. Soweit ich weiß haben Sie heute einen Termin in Aachen.

Es gab einen kleinen GUI-Fehler, so dass beim Anlegen eines neuen Vertrages mit der Auswahl "- individuell -" eventuell die Einstellungen des ersten Angebots in der Angebot-Dropdown-Liste verwendet wurden. Ist dann mit r2766 beseitigt.

Wenn Sie den Vertrag noch mal neu einrichten (evtl. auf Basis irgendeines Angebots) und anschließend über "Bearbeiten..." auf den Typ "- individuell -" setzen, müsste es eigentlich klappen.

Ich tippe mal darauf, dass "RESELLER-KUNDE.conf" im o.g. Fall alphabetisch vor dem Wort "default" liegt.
In diesem Fall liest Apache dessen Konfigurationsdatei zuerst ein und verwendet die daher als Standard-Host.

Abhilfe könnte es schaffen, im Verzeichnis /etc/apache2/vhosts.d/ einen Symlink von "default.conf" auf z.B. "000_default.conf" zu erstellen:

cd /etc/apache2/vhosts.d
ln -s default.conf 000_default.conf

Ist in der aktuellen Preview bereits behoben ("Fehler in NGINX-Konfiguration beseitigt (eingeführt mit v1.7.0-r2666)")

Diskussion wurde in diesen Thread verlagert:
http://www.liveconfig.com/de/f…tivierbar?p=6717#post6717

Zitat von dicker

ich habe für meine Reseller SSH verboten. Dennoch kann der Reseller beim Anlegen seiner Kunden Verträge

SCponly/sftp und ja (bash) auswählen.

Wenn beim Kunden ja(bash) ausgewählt ist, kann der Kunde sich dann mit seinen Liveconfig Zugangsdaten viaPutty einloggen und kann alles sehen.

Soweit ich das im Code sehe, ist das seit r2557 (v1.7.0) nicht mehr möglich, da beim Speichern der Vertragseinstellungen geprüft wird, welche Rechte über den Resellervertrag maximal vorhanden sind.

In der Verwaltung von Angeboten kann ein Reseller nach wie vor alle Shell-Möglichkeiten auswählen. Beim Anlegen eines Vertrags auf Basis eines solchen Angebots werden aber automatisch die Shell-Rechte entsprechend limitiert. Ich habe das eben getestet - mein Test-Account hatte auf dem Zielsystem (wie erwartet) in /etc/passwd als Shell "/usr/sbin/nologin" eingetragen.
Beim Bearbeiten eines solchen Vertrags sowie beim Erstellen/Bearbeiten eines individuellen Vertrags wird gar keine Shell-Auswahl mehr angezeigt.

Wie genau gehen Sie vor, um in Ihrem Beispiel einen Vertrag mit Shell anzulegen (obwohl diese nicht erlaubt ist)? Hat dieser Benutzer dann tatsächlich eine gültige Shell in /etc/passwd stehen?

Bei diesen Aktionen wird ein Reload vom NGINX bzw. nginx-fcgi-starter durchgeführt; offenbar kommt es dann zu einem Problem. Welche Distribution setzen Sie ein? (CentOS 6 wenn ich mich richtig erinnere?)

Wenn die Glaskugel nichts sagt, dann hilft nur ein tcpdump auf dem Server.

tcpdump ip and not host #.#.#.#

(#.#.#.# durch die IP ersetzen, von der aus Sie per SSH auf dem Server sind, damit Sie nicht Ihre eigenen SSH-Pakete mit loggen...)

Die Meldung weist nur darauf hin, dass die standardmäßig von der Distribution installierte Konfigurationsdatei /etc/awstats/awstats.conf angepasst werden muss (Eintrag "SiteDomain" fehlt).

Fügen Sie also entweder dort einen "SiteDomain"-Eintrag hinzu (z.B. "SiteDomain=localhost" o.ä.), oder benennen Sie die Konfigurationsdatei um (z.B. in "awstats.conf.disabled").

Auf unserem Testsystem mit OpenSUSE 12.1 kann ich das o.g. Verhalten nicht bestätigen.

Führen Sie bitte (als root) mal folgenden Befehl aus:

apache2ctl -S -t

Was wird für "default server" angezeigt? Dort sollte stehen:

default server default (/etc/apache2/vhosts.d/default.conf:43)

Zitat

openSUSE 12.1 (x86_64)

Ich empfehle bei Gelegenheit mal auf 12.3 zu aktualisieren; 12.1 ist schon ziemlich veraltet.

Fehler ist mit v1.7.1-r2759 beseitigt, Update erscheint in ca. 2 Stunden im Preview-Bereich (kommende Woche soll das Release für 1.7.1 erfolgen).
siehe auch: #134
Betroffen war übrigens nur LiveConfig mit SQLite-Backend.

Eigentlich sollte es genügen, die SSL-Werte über "ssl-ca=..." usw. in der my.cnf zu setzen (im Abschnitt [mysqld]) und danach MySQL neu zu starten.
Falls es Probleme mit dem Zertifikat oder dem Key gibt (häufige Fehlerquelle: Key ist noch passwortgeschützt), dann sollte das im MySQL-Errorlog protokolliert werden.

Nachtrag: siehe auch https://dev.mysql.com/doc/refm…/configuring-for-ssl.html

Hallo,

SSL für MySQL muss ja in der my.cnf direkt in MySQL eingerichtet werden.
Wenn Sie sich mal als (MySQL-)"root" auf dem 2. Server (mit lcclient) am MySQL anmelden, was erscheint dann bei folgender Abfrage:

show variables like '%ssl%';

LiveConfig prüft, welcher Wert in "have_ssl" steht.
Dabei dürfte es keinen Unterschied machen, ob die MySQL-Datenbank über einen lcclient oder direkt über ein Standalone-LiveConfig verwaltet wird (in beiden Fällen läuft der selbe Programmcode ;))

Selbstverständlich wird LiveConfig ständig weiterentwickelt. Erst vor wenigen Tagen wurde eine neue Preview-Version bereitgestellt, wir reagieren umgehend auf ernste Probleme und sind für komplexere Fragen zu Bürozeiten auch direkt erreichbar.

Dass hier immer gleich so getan wird als ob gar nichts passieren würde, nur wenn keine Antwort auf die Frage "wann kommt Feature X" erfolgt...

Zitat von kenny_g

Immer wieder falsche DNS Einträge für den Mailserver. Statt im MX Eintrag die anglegte Domain einzutragen, trägt er immer wieder den Rootserver ein, also die Hauptdomain wo der Nameserver drauf läuft ein.

Dieser Eintrag ist vielleicht nicht der den Sie erwarten, aber er ist nicht falsch. Als MX wird derzeit einfach der Hostname des Servers verwendet.

Zitat

Änderung des Domainnamens im Zonenfile funktioniert nicht.

Welchen Domainnamen genau haben Sie im Zonenfile geändert?
Oder anders: im Zonenfile können Sie derzeit keine Änderungen vornehmen, da dieses durch LiveConfig bei Änderungen an den Daten (via GUI/API) jeweils komplett neu erzeugt (=überschrieben) wird.
Eine Verwaltung eigener ResourceRecords (via GUI/API) befindet sich noch in Arbeit.

Zitat

Mails können nicht empfangen und gesendet werden.

Welche Distribution verwenden Sie? Mit Ubuntu 12.04 LTS sind uns derzeit keine Konfigurationsprobleme bekannt.
Welche Fehlermeldung gibt's beim Versand?
Welche Fehlermeldung gibt's beim Empfang?
Was steht in den einschlägigen Log-Dateien?

Zitat

Eine Telnet verbindung ergab einen Fehler.

Telnet wohin?
Was für ein Fehler?

Zitat

Heute konnte ich mich nicht mehr als Benutzer einloggen

Wo einloggen? In LiveConfig?

Zitat

und die Domain war nicht mehr erreichbar, genauso wie die Subdomain.

Was heißt "nicht erreichbar"? Webserver? DNS? Fehlermeldung?

Zitat

Als Admin eigeloggt und Domain gelöscht, dann neu angelegt. Nach einigem Hick Hack lief die Domain wieder aber die ursprüngliche Subdomain weiterhin nicht mehr erreichbar. Danach eine neue Subdomain (neuer Name) angelegt und funktioniert.

Das klingt nach DNS-Problemen. Änderungen im DNS unterliegen immer einer gewissen Latenz (DNS TTL) und können bis zu 24 Stunden benötigen um durch alle Caches durch zu sein. Wenn nur eine Subdomain "nicht geht" wäre die genaue Ausgabe von "dig @<Authoritativer_Nameserver> <subdomain> ANY" dringend für nähere Diagnosen notwendig.

Zitat

Wenn man sein eigenes Zonefile anlegt, ergänzt LC am Ende dieses mit irgendeinem Blödsinn.

Was für ein "Blödsinn" genau meinen Sie?
LC überschreibt Zonendateien und ergänzt diese nicht.

Zitat

Also liebe Entwickler, wenn Sie mich als Kunden haben wollen und das wäre ich wirklich gerne, muss definitiv etwas im Bereich Zonefiile / DNS passieren. Am Besten wäre es, wenn man dieses wie bei Plesk (und dass war bei Plesk wiederum echt genial), im Backend einstellen kann, damit diese manuelle Konfiguration (direkt im Zoenenfil) keine Probleme verursacht.

Manuelle Änderungen im Zonenfile wird es nicht geben, da das (so hart das klingt) 99% der Controlpanel-Nutzer leider nicht auf die Reihe bekommen und sich dabei in der Regel ihre Zone zerschießen.
Gelöst wird das im ersten Schritt so, dass es unter "Hosting" -> "Domains" (wo man derzeit auf eine (Sub-)Domain klickt und dann ein Popup aufgeht) völlig frei für die jeweilige (Sub-)Domain eigene Resource-Records definieren kann.
Eine Klickibunt-Oberfläche mit einem Texteditor für Zonendateien halten wir für relativ sinnbefreit. Die Idee ist ja vielmehr, die im DNS benötigten Einträge automatisch und selbständig durch das Panel erzeugen zu lassen.
Sprich: Kunde klickt z.B. irgendwann mal auf "SPF aktivieren", und LC legt im Hintergrund einen SPF- und einen TXT-RR mit den gewünschten Einstellungen an.

Viele Grüße

-Klaus Keppler

Die Preview wurde eben aktualisiert (v1.7.1-r2756). Neu hinzugekommen sind:

• weitere Sprache (Serbisch - vielen Dank an Bojan Suzic!)
• Unterstützung von Ubuntu 13.10
• Unterstützung von OpenSUSE 13.1

sowie einige interne Kleinigkeiten/Verbesserungen.
So können nun u.a. auch Optionen für die LiveConfig-MySQL-Datenbank angegeben werden (z.B. abweichender TCP-Port oder Socket-Dateiname).

Viele Grüße

-Klaus Keppler

Welche Distribution nutzen Sie denn?
Bei einer normalen Installation sollten alle Berechtigungen stimmen - so lange Sie nicht manuell die Rechte für z.B. /var/www/ ändern.

Sie können folgendes Script ausführen, um die Dateirechte und -Besitzer korrigieren zu lassen:

/usr/lib/liveconfig/lcservice.sh fix-permissions

Viele Grüße

-Klaus Keppler