Heute wurden noch einige Tests eingebaut und viele Bugfixes/Verbesserungen übernommen; morgen Mittag wird die Preview dann aktualisiert. Wenn nichts mehr dazwischen kommt, sollte die Freigabe dann am Montag (19.11.) erfolgen.
Alle weiteren Details dazu dann morgen in einem neuen Thread.
Viele Grüße
-Klaus Keppler
Sehr merkwürdig...
Läuft dieser Server auch unter CentOS 6.x?
Wissen Sie noch, welche Version von LiveConfig (bzw. lcclient) Sie dort ursprünglich installiert haben? (findet sich evtl. noch in den ersten Einträgen in /var/log/liveconfig/lcclient.log)
Hoppla... 
Ja, das Datenbankfeld ist nur für 32bit unsigned ausgelegt, was für max. 4GB Datenbankgröße reicht.
Wir speichern nun einfach den Wert statt in Bytes in Kilobytes ab, was für bis zu 4 TB reichen wird.
Beim nächsten Update dieser Tabelle wird das Feld dann in eine 64bit-Zahl umgewandelt.
Bugfix ist in v1.6.0-r2013 enthalten und somit im nächsten Update verfügbar.
Wie groß ist die Datenbank denn tatsächlich?
Ich kann mir vorstellen, dass es hier irgendwo zu einem 32bit-Overflow kommt.
SELECT SUM(DATA_LENGTH + INDEX_LENGTH) AS DBSIZE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA <> 'information_schema' AND TABLE_SCHEMA = 'web2db1'
GROUP BY TABLE_SCHEMA;Ja, da das "offizielle" CentOS-Repo kein NGINX enthält, wurde dieser bislang noch nicht berücksichtigt.
Ist aber keine große Sache, weil ja praktisch nur nach dem RPM gesucht werden muss; wir erweitern die Erkennungsfunktion gleich mal entsprechend.
Update wird kurzfristig bereitgestellt, ich gebe dann an dieser Stelle noch mal Bescheid.
Viele Grüße
-Klaus Keppler
Da vorhin diese Frage bei Twitter kam: die verfügbare Webserver-Software wird praktisch durch die verfügbaren IP-Gruppen definiert. Derzeit kann ein Kunde/Wiederverkäufer alle "gemeinsamen" IP-Gruppen sowie natürlich alle ihm exklusiv zugewiesenen IP-Gruppen nutzen. Die Rechteverwaltung (intern) ist bereits so vorbereitet, dass Verträge auch so eingestellt werden könnten, dass neben den exklusiv zugewiesenen Gruppen auch nur eine bestimmte "shared"-Gruppe oder gar keine gemeinsamen Gruppen ausgewählt werden dürfen.
Ich denke mal, dass das in rund zwei Wochen auch in der Oberfläche einstellbar sein dürfte (an diesem Bereich wird derzeit eh gearbeitet um die php.ini-Einstellungen verwaltbar zu machen).
Viele Grüße
-Klaus Keppler
Das "Kundenverzeichnis" muss definitiv dem root-User gehören, somit kann ein Kunde da auch keine eigene .httpd.conf anlegen.
Diese Möglichkeit der "Spezialeinstellungen" ist inzwischen auch schon teilweise im neuen Handbuch dokumentiert (ich weiß gerade nicht ab welcher Revision, aber das neue Kapitel nennt sich "Fortgeschrittene Konfiguration"); wir werden das Anfang nächster Woche auch im Lab-Bereich aktualisieren.
Zu den httpd_special-Einstellungen: alles was mit PHP zu tun hat gehört dort eigentlich nicht rein - hierfür gibt es nun eine eigene php.ini-Verwaltung innerhalb LiveConfigs (Details dazu dann auch nächste Woche). Dort können alle Einstellungen bequemer und sicherer verwaltet werden (z.B. ob ein User einzelne Einstellungen überschreiben darf, wenn ja welche min/max-Werte gelten, für welche PHP-Version welche Einstellungen gelten, und vieles vieles mehr).
Alle restlichen Spezial-Einstellungen (z.B. besondere Apache-Module etc.) sind dann am besten in der .httpd.conf aufgehoben.
Viele Grüße
Klaus Keppler
Hallo,
für FTPS gibt es bereits ein Ticket, das wird auch in Kürze in Angriff genommen (sollte in max. 2 Wochen vom Tisch sein).
Zu scponly: leider gibt es nur bis CentOS5 ein entsprechendes Paket bei rpmforge. Die Alternative hierzu ist offenbar das Paket "rssh" (ebenfalls via rpmforge). Wir werden die Lua-Scripte entsprechend anpassen, so dass - falls vorhanden - rssh statt scponly verwendet wird.
Manuell können Sie die Shell für einen User vorerst mit "usermod -s /usr/bin/rssh username" ändern. Ich denke, die notwendigen Anpassungen sollten auch bis Anfang kommender Woche drin sein.
Viele Grüße
-Klaus Keppler
Öh - das ist ein Bug. Allgemein fehlt derzeit die Möglichkeit, beim Bearbeiten eines Vertrags die Shell festzulegen (bzw. zu ändern). Wird kurzfristig in Angriff genommen...
(PS: derweil können Sie die Shell z.B. mit "usermod -s /bin/bash username" ändern - LiveConfig wird das nicht überschreiben)
Ja, steht hier schon länger auf der Ideen-Liste.
Es gibt sogar schon einen (etwas älteren) Mock-Up (s.u.) - damit wird vielleicht klar wir wir uns das etwa ausgedacht haben: es soll eine Liste definierbarer Mail-Vorlagen geben, welche dann für die verschiedenen Events verwendet werden.
So kann man als Anbieter dann z.B. beim Erreichen des Quotas ganz dezent darauf hinweisen, wo/wie der Kunde mehr Speicherplatz buchen kann. 
Im Mock-Up fehlen noch einige Optionen, u.a. die Internationalisierung.
Vom Zeitplan her steht das Thema direkt nach dem Abschluss der DNS/php.ini-Verwaltung an.
Viele Grüße
-Klaus Keppler
Kurz und knackig: ist bereits in Arbeit (nennt sich bei uns übrigens ".ngaccess" und dient insbesondere auch der Verwendung von per AppInstaller installierten Anwendungen mit NGINX)
Details folgen in Kürze.
Viele Grüße
-Klaus Keppler
Hi,
this is a very good point, thank you.
We improved SSL security for LiveConfig itself at short notice today (see issue #42) and will add the required configuration options for Apache/NGINX the next 2-3 days.
Best regards,
Klaus Keppler
Nein, tut mir leid.
Wenn die Kunden damit nicht zurecht kommen: KB#2.
Naja, der Browser "verbessert" die Domain ja eigentlich nicht, letztendlich findet immer irgendwo eine Weiterleitung durch den Server statt.
Eventuell ist die Weiterleitung noch in Ihrem Browser gecached - rufen Sie xyz2.de einfach mal von einem anderen Browser aus auf. Wenn die Weiterleitung dort auch auftritt, liegt im Webspace vielleicht noch eine .htaccess-Datei, welche für die Weiterleitung verantwortlich ist.
Viele Grüße
-Klaus Keppler
Es wird beim Anlegen des ersten FTP-Accounts schlicht gar kein Passwort gesetzt - der FTP-Account hat mit dem LiveConfig-Accounts nichts zu tun (da man z.B. mit einem LiveConfig-Login mehrere Verträge und somit auch mehrere FTP-Hauptbenutzer verwalten kann).
Rein technisch wird ja auch erst der Kunde im LiveConfig angelegt (mit Login/Passwort für LiveConfig), und irgendwann später wird dem Kunden ein Vertrag hinzugefügt. Da wäre es für LiveConfig unmöglich, für den FTP-Account auch das LiveConfig-Passwort zu verwenden (im Gegensatz zu anderen Control Panels speichert LiveConfig diese Passwörter irreversibel als Hash).
Es gibt in Kürze die Möglichkeit, automatisch eine E-Mail durch LiveConfig versenden zu lassen, wenn ein Vertrag hinzugefügt wurde - dort steht dann standardmäßig auch die Information drin, dass der Kunde sich in LiveConfig anmelden und sein FTP-Passwort einrichten kann.
Vom Klartext-Versand eines FTP-Passworts per E-Mail sind wir nicht so recht begeistert.
Viele Grüße
-Klaus Keppler
Ich glaube nun muss ich hier mal eingreifen.
Ganz persönlich frage ich mich, was für Kunden das sind, die bei einer Login-Maske "verwirrt" sind. :confused:
Das LiveConfig-Logo zeigt lediglich, um was für eine Software es sich hier handelt, nicht um welchen Provider es hier geht. Ein Kunde, der nicht weiß, wie er auf eine Anmeldemaske gelangt ist, sollte dort besser überhaupt keine Daten eingeben (Phishing) - egal welches Logo angezeigt wird.
Zudem ist - wie suppenuser schon sagte - von diesen Seiten aus kein Link auf irgendeine externe URL gesetzt.
Wir haben natürlich Verständnis dafür, dass Provider gerne die Anmeldeseite "customizen" möchten - dafür gibt es aber eine viel elegantere und besser integrierte Lösung: siehe KB#2: Integration der LiveConfig-Anmeldung in eigene Webseiten. Ein Musterbeispiel hierzu ist die Integration der LiveConfig-Demo unter http://www.liveconfig.com/de/demo
Es ist jedenfalls keine Lösung, einfach das von einem "admin"-Account hochgeladene Anbieterlogo dort anzuzeigen, denn dann stehen gleich die Reseller auf der Matte, die nicht möchten, dass das Logo von deren Lieferanten dort angezeigt wird.
Gleichzeitig freut es mich, wenn für manche Interessenten die Logo-Anzeige ein "kritisches" Feature ist - demnach scheint der Rest soweit vollständig zu sein. Wir arbeiten seit über einer Woche non-stop an der Verwaltung von DNS-Zonen und der Bearbeitung von php.ini-Einstellungen - da setzen wir eben andere Prioritäten.
Fazit: ich habe einen Feature Request zur optionalen (!) Anzeige eines Anbieter-Logos auf der Startseite erstellt - in den nächsten zwei Wochen wird das aber sicher nicht umgesetzt werden, da noch wichtigere Dinge auf der Warteliste stehen.
Viele Grüße
Klaus Keppler
Hallo Herr Groh,
es gibt auch Kunden/Nutzer, welche zwingend die SSL-Ports verwenden möchten (IMAPS/POP3S) - meist aufgrund irgendwelcher Sicherheitsrichtilinien, da diese Ports implizit eine SSL-Verschlüsselung nutzen und so nicht die "Gefahr" besteht, unverschlüsselte Passwörter zu übertragen.
Wir werden das nun folgendermaßen lösen:
Dieser Ansatz stellt unserer Meinung nach die sauberste Lösung dar - weitere Ideen sind aber herzlich willkommen.
Außerdem möchte ich hiermit noch mal die Option "nur SSL-Verbindungen erlauben" hervorheben, bei der zur Anmeldung am POP3/IMAP-Server erst ein STARTTLS erfolgen muss.
Die Änderungen werden kurzfristig umgesetzt und sind voraussichtlich ab Donnerstag verfügbar.
Viele Grüße
-Klaus Keppler
Unknown MySQL server host 'MySQLServername' (1)
Das hat nichts mit LiveConfig zu tun.
Gibt man die Fehlermeldung einfach mal in Google ein, so enthält gleich der erste (!) Treffer alle nötigen Hinweise.
ZitatWelche Logs benötigt man noch? Übrigens bekomme ich auch diese Meldung:
Code[Tue Nov 06 05:17:14 2012] [notice] cannot use a full URL in a 401 ErrorDocument directive --- ignoring! [Tue Nov 06 05:17:16 2012] [warn] [client MEINEIP] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server, referer: http://... [Tue Nov 06 05:17:16 2012] [error] [client MEINEIP] Premature end of script headers: db_structure.php, referer: http://... [Tue Nov 06 05:17:19 2012] [error] (12)Cannot allocate memory: fork: Unable to fork new process
Das lustige ist, das der Memory überhaupt nicht voll ist. Das wundert mich ein wenig sehr.
Der Fehler ("Cannot allocate memory") ist eigentlich ziemlich eindeutig. Falls auch hier OpenVZ zum Einsatz kommt, dann kann eventuell eine "Überbuchung" des Arbeitsspeichers des Host-Systems eine Ursache sein. (auch diese Fehlermeldung lässt sich hervorragend bei Google suchen ;-))
Viele Grüße
-Klaus Keppler
Ich habe das eben noch mal auf einer frischen Debian 6-Installation mit der selben LiveConfig-Version (1.5.3-r1988) versucht und kann das immer noch nicht reproduzieren.
Könnten Sie bitte den Inhalt von /etc/apache2/sites-available/web3.conf posten? (oder ggf per PN/E-Mail an mich)
Ich habe die Themen mal zusammengeführt.
Wir haben das eben getestet und das Problem reproduzieren können. Leider verhält sich NGINX nicht ganz so wie er es laut seiner eigenen Dokumentation sollte. 
Kurz gesagt muss für die Verwendung von SNI immer noch ein "Default-Host" (mit eigenem SSL-Zertifikat) eingerichtet werden.
Als kurzfristigen Workaround machen Sie bitte folgendes:
- fügen Sie in die Datei /etc/nginx/sites-available/default nach den "Listen"-Anweisungen noch die Option "default" und beim Port 443-Eintrag noch "ssl" ein:
listen 192.168.141.199:80[B] default[/B];
listen 192.168.141.199:443[B] default ssl[/B];
- kopieren Sie aus der erstbesten vHost-Konfiguration mit SSL noch die SSL-Anweisungen heraus und fügen Sie diese in der "default"-Datei z.B. nach den listen-Anweidungen mit ein, z.B.:
ssl_protocols SSLv3 TLSv1;
ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5;
ssl_certificate /etc/ssl/certs/fe385bfc5d088e1c-combined.crt;
ssl_certificate_key /etc/ssl/private/fe385bfc5d088e1c.key;Danach sollte mit einem "/etc/init.d/nginx restart" erst mal alles funktionieren; die default-Datei wird aber bei jeder Änderung an IP-Einstellungen/IP-Gruppen überschrieben.
Ich mache gleich ein Ticket hierzu auf, wir werden das in den nächsten Tagen sauber lösen. Das wird voraussichtlich darauf hinauslaufen, dass LiveConfig bei SNI ein "eigenes" SSL-Zertifikat erzeugt und damit eine Standard-Seite anzeigt, die den Benutzer darüber informiert dass sein Browser kein SNI unterstützt...
Viele Grüße
-Klaus Keppler