Beiträge von kk

Hallo,

mit Version 1.8.1-r3397 (ab sofort als Preview, ab morgen dann "stable") können Sie zusätzliche Einstellungen in einer separaten Datei pflegen.
Legen Sie dazu eine Datei namens /etc/proftpd/proftpd.local.conf an und tragen dort Ihre gewünschten Einstellungen ein. Anschließend klicken Sie im LiveConfig in der ProFTPD-Verwaltung den Button "neu konfigurieren" - das war's. In der aktualisierten proftpd.conf sollte nun ein "Include" auftauchen, der Ihre proftpd.local.conf nachlädt.

Ab morgen auch im Handbuch zu finden...

Viele Grüße

-Klaus Keppler

Der Fehler trat auf, wenn nach der Eingabe vom "&" (oder anderen HTML-Entities) im Passwort-Feld das Formular aktualisiert wurde (z.B. aufgrund der Auswahl von Kontaktdaten). LiveConfig hat praktisch "doppelt escaped".
Wurde mit v1.8.1-r3391 behoben (erscheint in Kürze)

Viele Grüße

-Klaus Keppler

Danke, wurde korrigiert.

Vermutlich haben Sie noch eine "alte" default-vHost-Konfiguration (/etc/apache2/sites-available/default).
Wenn Sie über "Server" -> "Web" z.B. den Namen einer IP-Gruppe ändern und auf "speichern" klicken, sollte diese aktualisiert werden und dann auch die richtige Fehlerseite bringen.

Korrigieren Sie mich bitte wenn ich falsch liege, aber ARM kommt derzeit hauptsächlich bei Klein- und Kleinstrechnern (Raspi etc.) zum Einsatz. LiveConfig würde da sicherlich compilieren (ist ja alles in C/C++, daher portabel). Ich kann mir aber (noch) keinen Anwendungsfall vorstellen, bei dem es Sinn macht, so einen Klein(st)rechner mit LiveConfig zu verwalten: der Fokus liegt in einer GUI für Hosting-Verwaltung - das dürfte auf ARMs kaum stattfinden.

Ich bin aber offen für eine Diskussion.

Viele Grüße

-Klaus Keppler

Ist das denn soooo schwer zu finden? Ich hab' ca. 20 Sekunden gebraucht...

ErrorDocument 401 default
ErrorDocument 403 default
ErrorDocument 404 default
ErrorDocument 500 default

Ich habe den Beitrag von "Fehler und Problembehebung" in "Installation und Verwendung" verschoben.

Dennoch verstehe ich nicht, was Sie genau meinen...
Die von LiveConfig bereitgestellten Fehlerseiten finden Sie auf dem Server unter /usr/share/liveconfig/html/ - diese werden bei Updates von LiveConfig aber überschrieben.

Ab sofort steht eine neue Preview bereit (v1.8.1-r3379). Darin wurde ein hartnäckiges und sehr seltenes* Problem beseitigt, wodurch LiveConfig nach der Ausführung externer Programme (z.B. "chattr") unter Umständen hängen geblieben ist.

Die Ursache war eine recht spezielle Race Condition (für Programmierer: zwei separate Threads hatten per waitpid() auf das Ergebnis eines beendeten Child-Prozesses gewartet. Je nachdem wann die CPU einen Kontextwechsel ausgeführt hat, kam eventuell der "falsche" Thread zum Zug - der andere Thread wartete dann...)

Am Montag werden noch einige kleinere (fast fertige) Änderungen in die v1.8.1 aufgenommen, spätestens am Mittwoch erfolgt die Produktiv-Freigabe. Alles Weitere dann nächste Woche...

Viele Grüße

-Klaus Keppler

*) "sehr selten" ist natürlich Ansichtssache - wir haben das auf keinem einzigen all unserer Systeme erlebt, wissen aber von zwei Kunden wo das aufgetreten ist.

Zitat von solidius

ich habe mit CentOS noch ein kleines Problem. Installiert ist liveconfig-1.8.1-r3378.x86_64 auf einem centos6.5 64bit.

Im LiveConfig fehlen alle Status Icons, welches sich durch das gesamte LiveConfig Interface zieht.

Kann ich nicht bestätigen. Eben mit CentOS 6 getestet - alle Icons da. Prüfen Sie bitte, ob LiveConfig vollständig installiert wurde (nicht dass die Festplatte voll war) und ggf. ob der Browser-Cache geleert wurde (einfach mal <Strg>+<R> im Browser drücken).

Ab sofort gibt's ein Update der Preview-Version (v1.8.1-r3378). Unter anderem ist dort das zusätzliche Dummy-Passwortfeld richtig versteckt.

Zitat

Darf man wissen, ob ob mein Wunsch bezüglich der Tabs im Bearbeitungsfenster der (Sub-)Domains auch in dieser Version umgesetzt werden wird?

Wird in v1.8.1 nicht mehr hinein passen, da diese Version nun relativ zeitnah erscheinen soll. Ich denke aber, mit dem nächsten Update (v1.8.2) sollte es klappen. Es sind ohnehin noch Änderungen in der DNS-Verwaltung geplant (u.a. das Anlegen von Resource Records mit Underscores, etwa für DKIM (z.B. "test._dkim.domain.de TXT ...")).

Einige Tests hier auf produktiven Server haben gezeigt, dass es beim Löschen von Verträgen durchaus einige Minuten (!) dauern kann, bis alle Daten vom Webspace entfernt wurden (anders formuliert: bis "rm -rf /var/www/web###" zurückkehrt).
Um das Debugging in solchen Fällen zu vereinfachen, protolliert LiveConfig künftig (ab 1.8.1-r3375) den Aufruf vom "rf -rf..." sowie den Zeitpunkt wenn dieser Befehl abgearbeitet ist.

Längerfristig könnten wir den Löschvorgang mittels Quota-API auch visualisieren (quasi per Fortschrittsbalken).

Viele Grüße

-Klaus Keppler

No, that's not possible with LiveConfig.
Additionaly, that doesn't make any sense and violates common standards. Just bounce unwanted messages.

I can confirm this bug, I've just tested this with WordPress installation in serbian language.
(FYI: there's a log in ~/logs/appinstall.log containing all relevant output when installing an application)

It seems to be a bug "only" in the web installer scripts, so we'll fix this today (no need to update LiveConfig, just restart or wait up to 24 hours to get the updated installer scripts)

Thanks for the info, this was a bug. In the new HTML5 page template, this string wasn't marked as "localised". This is fixed with v1.8.1-r3375.

Ganz einfach: falsche oder fehlende CA-Zwischenzertifikate.
Anleitung des SSL-Anbieters beachten.

Nachtrag: ... oder ist für E-Mail eventuell noch das alte Zertifikat in Verwendung? Ggf. mal im LiveConfig die Konfiguration für Postfix und Dovecot erneut speichern.

Ab sofort steht die Preview v1.8.1-r3373 online. Diese enthält neben der aktuellen OpenSSL-Bibliothek nun auch eine Überarbeitung der Passwort-Eingabe, so dass der Passwort-Manager von Browsern (hoffentlich) keinen Ärger mehr machen sollte.
Falls doch, bitte ich um eine kurze Rückmeldung (vorher bitte sicherstellen, dass nicht noch alter JavaScript-Code im Browser gecached wurde).

Viele Grüße & ein schönes Wochenende

-Klaus Keppler

Kann ich so nicht bestätigen: ich habe hier auf einem Testserver eine Einstellung global geändert (max_execution_time von "90" auf "95" gesetzt). Unmittelbar nach dem Klick auf "Änderungen anwenden..." wurden alle php.ini's (in meinem Fall in den Verzeichnissen ~/conf/php[5|52|55]/php.ini) umgehend aktualisiert.
Bitte prüfen Sie die liveconfig.log, ob eventuell Fehler aufgetreten sind.
Sollte sich das Verhalten reproduzieren lassen, senden Sie uns bitte mal den Inhalt der custom.lua sowie die Ausgabe von "liveconfig --diag".

Viele Grüße

-Klaus Keppler

Zitat von Nosxxx

Außerdem würde ich es super finden wenn ihr für die aliase und das pwd1 autocomplete ausmacht. Mein Firefox füllt dort immer mein Admin Passwort ein ;S

Edit:
Dieser Fehler liegt daran das Firefox automatisch das PW Feld ausfüllt. Kann man das irgendwie beheben, ohne das Passwort aus Firefox löschen zu müssen ?

Die Geister die ich rief...
autocomplete=off wird inzwischen von allen aktuellen Browsern (IE11+, Chrome, Firefox30+, Safari) ignoriert. Die Usability bei "Passwort ändern"-Formularen ist daher eine Katastrophe - der Passwort-Manager lässt sich praktisch nicht mehr vermeiden (außer man deaktiviert den im Browser).
Wenn man's also genau nimmt ist das ein Problem mit dem Browser, wenn dieser Formulare falsch ausfüllt (da kann LiveConfig schließlich nichts für).

Wir haben aber einen Workaround gefunden, wie zumindest keine Passwörter mehr automatisch vom Passwort-Manager übernommen werden (die Nachfrage, ob ein Passwort gespeichert werden soll bleibt leider dennoch bestehen). Die Änderung wird gerade in die nächste Preview (v1.8.1-r337x) integriert.

Bedanken Sie sich bei den Browser-Entwicklern - die übrigens wiederum darauf verweisen, dass sich die Browser nicht von Webseiten vorschreiben lassen sollten, welche Passwörter diese speichern dürfen und welche nicht...

Ja, wenn Sie als admin in Hosting -> PHP-Einstellungen eine (globale) Einstellung bearbeiten und am Ende ganz unten auf den "Änderungen anwenden..."-Button klicken, dann wird das umgehend auf alle php.ini-Dateien angewandt.

Ab v1.8.1 sind diese Limits konfigurierbar - Diskussion hiermit beendet.

Nichts desto trotz rate ich von einem Mißbrauch der Weiterleitungen für "Mailinglisten" dringend ab! Keine Bounce-Verarbeitung, keine Filterung, keine Moderation - gerade bei Spam ist das alles extrem lästig. Wer dennoch nicht die Finger davon lassen kann, der soll einfach den gewünschten Wert in LCDEFAULTS eintragen. Nur weil Confixx das evtl nicht limitiert hat heißt nicht, dass das sinnvoll ist...