Die Frage war vielmehr, warum in diesem konkreten Fall von der Lab- zurück auf die Stable-Version gewechselt werden soll (also ob ein akutes Problem besteht).
Für die Freigabe von v1.6.2-stable fehlt nur noch der Abschluss der php.ini-Verwaltung, das dauert also nicht mehr lange.
Viele Grüße
-Klaus Keppler
Noch mal: geht es mit anderen E-Mail-Programmen (Thunderbird) auch nicht?
Wurde Postfix neu gestartet?
Setzen Sie das Limit ggf. mal auf einen sinnvolleren Wert herunter (50MB).
Eine weitere häufige Fehlerquelle sind auch lokale Virenscanner, welche sich beim Mailversand quasi zwischen das Mailprogramm und den Mailserver klemmen. Wenn in der Log-Datei (mail.log) beim Sendeversuch überhaupt nichts auftaucht, dann sitzt der Fehler schon viel weiter vorne.
Ab sofort steht die Preview-Version v1.6.2-r2243 zum Download zur Verfügung.
Die wichtigsten Neuerungen sind:
Außerdem wurde noch einiges an der php.ini-Verwaltung getan; dieser Bereich wird in Kürze abgeschlossen, womit der Freigabe von v1.6.2-"stable" dann nichts mehr im Wege steht.
Viele Grüße
-Klaus Keppler
Hallo,
nein, wenn in der "neuen" Datenbank schon Daten angelegt wurden (neue Kunden etc.), dann kann nicht zurück gewechselt werden (LiveConfig ist zwar jeweils "abwärtskompatibel", kann also jede noch so alte LiveConfig-Datenbank auf den aktuellen Stand bringen, nur anders herum geht das eben nicht).
Das Repository selbst können Sie dennoch auf das Stable-Repo zurück stellen, dann erhalten Sie das nächste LiveConfig-Update automatisch wieder aus "stable". Gibt es ansonsten einen bestimmten Grund, warum Sie von der Lab- auf die Stable-Version wechseln möchten? (das nächste Lab-Update steht unmittelbar bevor)
Viele Grüße
-Klaus Keppler
- Klappt das nur mit Outlook nicht?
- Was sagt die Log-Datei nach einem Abbruch? (/var/log/mail.log)
Naja, "ohne Rücksicht" klingt schon etwa hart... 
Schließlich fragt LiveConfig ja eingangs nach, ob es die Verwaltung der jeweiligen Konfigurationsdateien übernehmen darf/soll.
Aber im Grunde stimmt das: LiveConfig überschreibt Konfigurationsdateien meistens (Ausnahmen bestätigen die Regel... s.u.). Der Grund dafür ist, dass ein Parsen der ggf. vom Benutzer manuell hinzugefügten Einstellungen sowie eine Prüfung auf Verträglichkeit mit von LiveConfig vorzunehmenden Einstellungen in den meisten Fällen unverhältnismäßig kompliziert ist.
Wichtig ist aber:LiveConfig aktualisiert prinzpiell keine Konfigurationsdatei selbständig - auch nicht bei einem Upgrade. Tut der Benutzer nichts, dann bleibt im o.g. Fall auch nach einem Upgrade die "alte" (manuell bearbeitete) Konfigurationsdatei aktiv. Erst wenn man in der Serververwaltung etwas an einer Dienstkonfiguration ändert, wird diese neu geschrieben.
Und da sind wir schon beim zweiten wichtigen Punkt: für die meisten Konfigurationsdateien gibt es inzwischen Sperr-Mechanismen, mit denen ein Überschreiben durch LiveConfig verhindert werden kann. Im Handbuch werden diese nun schrittweise erfasst (z.B. für Postfix).
Viele Grüße
-Klaus Keppler
Hallo,
während dem Update müsste in diesem Fall die alte liveconfig.conf als liveconfig.conf.rpmsave gesichert worden sein.
Es stimmt aber, dass dieses Vorgehen nicht optimal ist. Ab v1.6.2-r2233 enthält die RPM-Konfiguration eine Anweisung, dass die vorhandene Konfigurationsdatei beibehalten und die ggf. neue Konfigurationsdatei mit dem Suffix .rpmnew gespeichert wird (wen die technischen Details interessieren: siehe hier).
Viele Grüße
-Klaus Keppler
ZitatEine kurze Frage. Wird die liveconfig.log eigentlich direkt von Liveconfig verwaltet bzw. rotiert?
Nein, diese Logdatei wird nicht rotiert. Ist auch nicht gaaanz trivial: die Logdatei wird beim Start mit root-Rechten geöffnet, später verwirft der GUI-Prozess von LiveConfig seine Rechte und schreibt weiter in diese Datei. Für eine Log-Rotation müsste die Datei geschlossen und neu geöffnet werden - das würde einen Neustart zumindest des Client-Prozesses innerhalb LiveConfigs erfordern.
Lange Rede, kurzer Sinn: eigentlich sollte in diesem Log ohnehin nicht sehr viel drin stehen (die aktuellen Update-Meldungen fürs Repository werden künftig auch auf einen anderen Loglevel gesetzt), so dass die Datei im Laufe ihres Lebens gar nicht großartig anwachsen sollte.
Zur Rotation von Apache access.logs (ein völlig anderes Thema): unser Tool "lclogsplit" (welches die access.logs in den Kundenverzeichnissen live erzeugt) unterstützt intern seit r2163 bereits die Anonymisierung von IP-Adressen (v4 und v6). In der Logrotate-Konfiguration steht zudem jeweils ein eigener Eintrag pro Kunden-Log-Datei - technisch haben wir also alle Voraussetzungen geschaffen, um individuell pro Vertrag die Log-Rotation und IP-Anonymisierung verwalten zu können. Es fehlt schlicht noch an der notwendigen Eingabemaske, um diese Einstellungen zu ändern. Diese wird aber mit einem der nächsten Updates kommen (unverbindlich: ca. v1.7.1, gegen Mai/Juni).
Viele Grüße
-Klaus Keppler
Wie werden die Cronjobs richtig eingetragen
einfach den scriptpfad eingeben oder wie läuft das.
http://www.liveconfig.com/de/handbuch/tutorial.cron.html
ZitatDan noch ne Frage warum können bei mir keine Pngs angezeigt werden auf anderen seiten funktioniert der aufruf
Bitte öffnen Sie für verschiedene Fragen jeweils einen eigenen Thread im Forum.
Warum PNGs nicht angezeigt werden wird Ihnen so niemand beantworten können - ohne eine Beispielseite oder Fehlermeldung ist das unmöglich. Am besten verwenden Sie Firefox mit dem Plugin "Firebug" - da sehen Sie ziemlich genau, wenn beispielsweise einzelne Seiteninhalte nicht geladen werden können.
ZitatIn LiveConfig finde ich jetzt am Anfang vieles etwas verwirrend, und ich würde gern die Lernzeit verkürzen.
Ja, LiveConfig macht einige Dinge anders als Confixx - unser Ziel ist es aber, die jeweiligen Prozesse dennoch möglichst kurz und intuitiv zu gestalten. Könnten Sie uns etwas genauer beschreiben, was Ihnen beim Umstieg Schwierigkeiten bereitet? Wir würden das dann ggf. in der Oberfläche überarbeiten bzw. in der Dokumentation berücksichtigen.
Der Workflow ist grob gesagt: (Angebote anlegen), Kunde anlegen, Vertrag anlegen, Domains anlegen.
Weitere Informationen finden Sie im Handbuch unter http://www.liveconfig.com/de/h…h/tutorial.customers.html
Viele Grüße
-Klaus Keppler
Hallo,
Zitaterror reading data from FastCGI server
Das klingt sehr danach, dass kein FastCGI-Prozess für den betroffenen Webspace existiert.
Prüfen Sie bitte, ob die Datei /var/www/###/conf/php5/php-fcgi-starter existiert, und ob folgende Pakete installiert sind:
apache2-suexec libapache2-mod-fcgid php5-cgi
Viele Grüße
-Klaus Keppler
Wir setzen LC+nginx produktiv auf einem stark frequentiertem Server (mehrere Mio Pageviews/Monat) problemlos ein, haben dort allerdings noch einige Details "tunen" müssen. Die notwendigen Änderungen (insbes. SSL-Konfiguration, "Include" von eigenen Konfigurationabschnitten) fließen in den nächsten Tagen noch in die aktuelle Preview ein.
Kurzum: PHP-FastCGI und Domainkonfiguration läuft stabil und problemlos, es mangelt nur noch an Einstellmöglichkeiten für Spezialfälle.
Falls Sie konkrete Fragen oder spezielle Anforderungen haben, geben Sie einfach Bescheid.
Viele Grüße
-Klaus Keppler
Hallo & herzlich willkommen 
Um nginx verwenden zu können müssen Sie im Grunde lediglich nginx installieren und dann in LiveConfig dessen Verwaltung aktivieren.
Zur Installation: das Paket liveconfig-meta installiert automatisch Apache mit; danach nur Apache zu entfernen ist immer etwas frickelig. Lassen Sie sich lieber mit "aptitude show liveconfig-meta" die Abhängigkeiten anzeigen, und installieren Sie diese ohne Apache, also z.B.:
[code]aptitude install quota bzip2 unzip php5-cgi php5-cli php5-curl php5-gd php5-imagick php5-imap \
php5-mcrypt php5-mhash php5-mysql php5-sqlite imagemagick postfix dovecot-imapd \
dovecot-pop3d clamav-milter mysql-server proftpd-basic webalizer nginx[/quote]
Installieren und starten Sie anschließend LiveConfig. Melden Sie sich als "admin" an, gehen Sie auf "Serververwaltung" -> "Web" und aktivieren Sie dort die Verwaltung von nginx. Dann noch IPs zuweisen, fertig.
WICHTIG: die Unterstützung von NGINX in LiveConfig ist noch nicht perfekt (wir arbeiten daran ;)). Konkret können insbesondere noch keine individuellen Einstellungen (z.B. location-Anweisungen etc. für Redirects) vorgenommen werden.
Wenn Sie spezielle Wünsche haben, immer her damit.
Am einfachsten testen Sie diese Kombination mal in einer virtuellen Maschine (z.B. mit "VirtualBox") und einer kostenlosen Testlizenz.
Viele Grüße
-Klaus Keppler
Hmm, bei mir sind unter "Serververwaltung" => Web alle apache Module mit rotem X, wo vorher kein X war
Fehler wurde mit v1.6.2-r2212 beseitigt (Update voraussichtlich ab Ende der Woche verfügbar)
Hallo,
da scheint ein Fehler vorzuliegen; nach einer Zertifikatsänderung müssten Sie vorerst noch mal irgendeine Domain des betroffenen Kunden öffnen und auf "speichern" klicken (so dass die vHost-Konfiguration eben neu geschrieben wird); dabei wird dann auch das SSL-Zertifikat aktualisiert.
Eigentlich sollte es aber durchaus nach dem Speichern in der Zertifikatsverwaltung automatisch auf dem Server aktualisiert werden... wir kümmern uns da kurzfristig darum.
Viele Grüße
-Klaus Keppler
Live Log Viewer funktioniert bei mir leider nicht. Die Sonne dreht und dreht und dreht....
Es werden keine Ereignisse angezeigt. LC läuft bei mir unter Ubuntu
Welches Log wollten Sie anzeigen lassen - access.log oder error.log?
Das access.log wird derzeit scheinbar mit zu restriktiven Rechten angelegt (gehört root:root, Modus=640, daher kein Lesezugriff). Dieses Problem wird mit dem nächsten Update beseitigt (ist also bis zur Stable Release gelöst).
Zugriff auf error.log sollte eigentlich klappen - können Sie bitte mal prüfen, ob und wenn ja mit welchen Rechten die Datei ~/logs/error.log existiert?
ZitatDie Apache Module sind bei mir übrigens auch mit einem roten X versehen.
Handelt sich offenbar um einen Fehler; bei einem Multi-Server-Setup reicht es meist, den betroffenen LiveConfig-Client neu zu starten. Wird auch in den nächsten Tagen beseitigt sowie in die automatisierten Tests mit aufgenommen... :-|
Vielen Dank für die Rückmeldung & viele Grüße
-Klaus Keppler
Hallo,
ab sofort steht Version 1.6.2-r2210 als Preview zum Download bereit. Die Änderungen sind im Changelog aufgeführt, zu den wichtigsten neuen Funktionen zählen:
Derzeit wird noch an der Fertigstellung der php.ini-Verwaltung gearbeitet; sobald das abgeschlossen ist, erfolgt die "Stable Release".
Viele Grüße
-Klaus Keppler
Diese Meldungen sind im Grunde unkritisch (tritt dann auf, wenn sich in den eigentlichen RRD-Daten nichts geändert hat - durch einen Programmfehler wird dann der UPDATE-Befehl als "nicht erfolgreich" gewertet, dann ein INSERT versucht, und das schlägt natürlich fehl...).
Seit r2151 ist dieses Problem beseitigt; mit dem nächsten LiveConfig-Update sollte das also verschwinden.
Viele Grüße
-Klaus Keppler
Diese Nachrichten nennen sich Delivery Status Notification (DSN) und werden üblicherweise nur versendet, wenn eine Zustellung fehlgeschlagen ist.
Man kann Postfix im Grunde schon erlauben, auch bei Erfolg eine solche Nachricht zu versenden (ich glaube im Mail-Client muss das dann auch irgendwo noch aktiviert werden) - hierzu muss in der postfix.conf die Zeile "smtpd_discard_ehlo_keyword = silent-discard, dsn" auskommentiert/entfernt werden.
Das Problem ist jedoch, dass man Postfix nicht beibringen kann, dass nur "eigene" (authentifizierte) Mail-User eine DSN bei erfolgreicher Zustellung anfordern können - auch jeder beliebige andere (externe) Absender kann damit Zustellbestätigungen bei diesem Mailserver anfordern. Diese DSNs enthalten wiederum manchmal Informationen, die nicht unbedingt für die Öffentlichkeit gedacht sind.
Man kann Postfix so konfigurieren, dass DSNs nur von bestimmten IP-Adressen aus angefordert werden dürfen (smtpd_discard_ehlo_keyword_address_maps) - mit LiveConfig ist das aber nicht möglich. In der Praxis wird diese Einstellung (fast?) nie genutzt; in den seltenen Fällen, in denen man eine Zustellung prüfen möchte, kann man das ja anhand des Log-Files (/var/log/mail.log) tun.
Viele Grüße
-Klaus Keppler
Äh - das klingt in der Tat merkwürdig.
Wenn Sie auf "Serververwaltung" klicken, sollte ja eine Liste der Server erscheinen.
Verstehe ich das richtig, dass dort nur ein Server ("localhost") angezeigt wird?
Sind Sie als "admin" angemeldet, oder als ein anderer Benutzer?
