Die PHP-Pakete für Debian wurden auf die neuesten Versionen aktualisiert (5.4.37, 5.5.21, 5.6.5).
Siehe auch: KB#22.
Viele Grüße
-Klaus Keppler
Die PHP-Pakete für Debian wurden auf die neuesten Versionen aktualisiert (5.4.37, 5.5.21, 5.6.5).
Siehe auch: KB#22.
Viele Grüße
-Klaus Keppler
Senden Sie einfach mal von extern eine E-Mail an eine dieser neu angelegten Adressen. Was genau wird anschließend alles in /var/log/mail.log auf Ihrem Server protokolliert?
a) gar nichts: das deutet darauf hin, dass mit dem DNS/MX was nicht passt (evtl noch alter Wert in anderen Caches)
b) Mail wird abgewiesen: dabei sollte der einliefernde Mailserver eigentlich ein Bounce erzeugen
c) Mail wird zugestellt (dann gibt's ein anderes Problem)
Wenn ich dem Emailserver(Debian) ein neues Cert zuweisen will passiert leider nichts. In den logs steht nur das das Dovecot/Postfix neugestartet werden. Das Cert im Dovecot verzeichnis ist aber definitiv noch das alte.
Werden wir uns mal anschauen. Hilft es evtl. die Postfix- bzw. Dovecot-Konfiguration neu zu speichern? (dabei sollte das Zertifikat neu geschrieben werden)
ZitatDas zweite Problem ist das auch das zuweisen nicht funktioniert. Also wenn man ein Cert als Administrator anlegt und es einem anderen User zuweist erscheint es einfach nicht bei einem User(verschiedene Certs und User habe ich probiert) in der Liste.
Wenn Sie als Admin oder Reseller ein SSL-Zertifikat anlegen und einem Kunden zuweisen, dann taucht das nicht in der SSL-Liste des Kunden auf (falls dieser die Berechtigung "SSL-Zertifikate verwalten" hat), sondern kann ausschließlich bei der Webspace-Konfiguration ausgewählt werden (Hosting -> Domains -> (Sub)Domain bearbeiten).
Sinn des Ganzen ist, dass der Endkunde so eben nicht den Private Key des Zertifikats sehen kann.
Das klingt nicht gut...
Schicken Sie uns bitte den Backtrace aus dem LiveConfig-Log (/var/log/liveconfig/liveconfig.log) inklusive der exakten Versionsnummer und Name/Version Ihrer Distribution an support@liveconfig.com damit wir das analysieren können.
Viele Grüße
-Klaus Keppler
Ab sofort steht LiveConfig v1.8.1 (r3397) zum Download bereit.
Dieses Update bringt hauptsächlich Fehlerbereinigungen und Detailverbesserungen - eine vollständige Liste finden Sie im Changelog. Die neuen Funktionen sind im Handbuch beschrieben (u.a. individuelle Konfiguration von ProFTPD, Postfix und Dovecot sowie Änderung von Standardwerten (LCDEFAULTS)).
Ab nächster Woche stellen wir dann die erste Preview der nächsten Version (v1.8.2) bereit, zudem wird nun endlich mal die (öffentliche) Roadmap aufgeräumt. ![]()
Vielen Dank nochmals für das großartige Feedback, die Unterstützung bei der Fehlersuche und - last but not least - für die Verwendung von LiveConfig. ![]()
Im Namen des gesamten Entwicklerteams
-Klaus Keppler
Tolle Sache, eine Frage noch dazu. Wie sollen leute die SQLite nutzen die lcdefaults anpassen ? Vielleicht wäre eine Einbindung ins GUI hilfreich
Es wird bereits an einem CLI für LiveConfig gearbeitet (Command Line Interface), u.a. um die Automatisierung der Installation zu vereinfachen. Da gibt's dann auch eine Möglichkeit, die LCDEFAULTS-Werte zu setzen.
Viele Grüße
-Klaus Keppler
Ab sofort steht v1.8.1-r3397 als Preview-Version zur Verfügung.
Das Handbuch wird morgen aktualisiert, dann erfolgt auch die "stable"-Freigabe.
Dieses Update enthält insbesondere einige Verbesserungen an den Lua-Scripten sowie einige GUI-Bugfixes.
Viele Grüße
-Klaus Keppler
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
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.
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. ![]()
ZitatDarf 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)