Beiträge von kk

    Hallo,


    was da geschehen ist war kein Logrotate, sondern ein Server-Neustart (ein Kill-Signal 15 vom init-Prozess deutet zumindest stark darauf hin ;) Außerdem gibt es eine Zeitlücke von über 1,5 Minuten zwischen den Service-Stopps und -Starts.


    Das hat die Fehlerquelle dann auch eingegrenzt: unter Ubuntu 12 konnte LiveConfig das init-Script für lcsam nicht korrekt installieren. Mit folgendem Befehl kann das nachgeholt werden:

    Code
    update-rc.d lcsam defaults


    Mit dem nächsten Update (v1.8) holt LiveConfig das ggf. selbst nach.


    Viele Grüße


    -Klaus Keppler

    Nein, wurde nicht vergessen sondern mit r3132 in den Entwicklerzweig (v1.8.0) aufgenommen. In dem kürzlich freigegebenen 1.7.5-Update wurde das nicht "backported". Ist also im kommenden "richtigen" Update mit dabei. Die Preview erscheint kommende Woche.


    Viele Grüße


    -Klaus Keppler

    Noch mal: Inhalte, die nur per HTTP erreichbar sind, sollten am besten immer nur auf einer IP betrieben werden die nicht mit SSL genutzt wird. Das war schon immer so und wird auch immer so bleiben.


    Unabhängig davon: bearbeiten Sie bitte im LiveConfig einfach irgend eine IP-Gruppe (z.B. irgendwas am Namen einer IP-Gruppe ändern - das reicht schon). Danach erzeugt LiveConfig automatisch auch die Default-vHosts neu und sollte diesen ein eigenes Standard-SNI-Zertifikat zuweisen.


    Viele Grüße


    -Klaus Keppler

    Ab sofort steht mit Version 1.7.5-r3221 ein kleines LiveConfig-Update bereit. Es werden darin nur zwei Detailfehler behoben (ProFTPd-SSL-Konfiguration und Problem mit LCCP bei zu großen Nachrichten). Zudem steht nun auch ein Application-Installer für Magento (inkl. der FireGento-Erweiterung "Mage Setup") zur Verfügung.


    Die Arbeiten an der "nächsten großen Version" (v1.8) gehen gut voran, Anfang kommender Woche soll es die erste Preview-Version geben.


    Viele Grüße


    -Klaus Keppler

    Die Version v1.7.5-r3221 wurde nun unverändert als "Stable" freigegeben. Der "showstopper" war ein Problem im Application Installer, das aber letztendlich im betroffenen Installationsscript lag. Mit v1.7.5-r3221 steht nun nämlich auch Magento (inkl. der FireGento-Erweiterung "Mage Setup") im AppInstaller bereit.


    Die Demo zur v1.8 (siehe anderer Thread) wurde in den letzten Tagen unabhängig davon auch immer wieder mal aktualisiert. Voraussichtlich (!) nächste Woche steht diese dann als erste Preview bereit.

    Wird dem Nutzer anhand des UserAgent dann direkt eine entsprechende Meldung angezeigt und der Login verweigert oder kommt es zu einer Vielzahl von Problemen?


    Nein, wir treffen keine Entscheidungen anhand des UserAgents. Zum einen ist dieser Header nicht unbedingt zuverlässig, zum anderen haben wir keinen Einfluss darauf was ein Browser kann oder nicht kann. Wer tatsächlich noch mit dem IE6 oder 7 unterwegs ist, hat ohnehin ganz andere Probleme. Und auf Windows XP ist ja IE8 schon lange verfügbar.

    Wir haben eben einen kleinen vServer mit unserer aktuellen Entwicklungsversion von v1.8 aufgesetzt:


    https://demo18.liveconfig.com:8443
    Login: "admin"
    Passwort: "demo18"


    WICHTIG: sehr viele Anzeige- und Eingabemasken sind noch nicht überarbeitet bzw. wurde deren CSS noch nicht angepasst. Es gibt in der GUI also noch viele Bereiche, die komisch/defekt aussehen bzw. nicht funktionieren. Also bitte nicht wundern, und bitte vorerst noch keine Fehlerberichte melden.


    Die komplette HTML-Erzeugung wird ja überarbeitet, was bis zu 40% weniger HTML-Code erzeugt und die Seiten i.d.R. fast doppelt so schnell laden lässt. Zudem wird die komplette Ausgabe nur per CSS gesteuert, welches dann auch durch eigene Designs ersetzt werden kann. Alle Eingabemasken nutzen die neuen HTML5-Features zur Formularprüfung - fehlende Eingaben werden so schneller und besser am Bildschirm markiert.
    Wer möchte, kann auch gerne einen Blick auf die neue Passwort-Eingabe werfen (z.B. Einstellungen -> Passwort ändern). Der Schwellwert (ab wann LC ein Passwort akzeptiert) ist frei konfigurierbar.


    Die GUI-Umstellung kommt derzeit ganz gut voran - sobald dieser Punkt abgeschlossen ist, werde ich hier noch mal Bescheid geben - dann können wir die Preview auch zum Download bereitstellen.


    Viele Grüße


    -Klaus Keppler


    PS: ach ja, mit IE6/7 ist LiveConfig nun leider nicht mehr verwendbar. Minimum ist nun IE8 (mit dem testen wir das zumindest als "Minimal-Standard" durch).

    Hallo,


    wir haben eben noch mal ein Update der 1.7.5er-Serie (r3221) als Preview bereitgestellt. Darin werden zwei Fehler beseitigt und zwei Detailsverbesserungen vorgenommen, welche ein paar Kunden betreffen.
    Wir führen morgen früh noch ein paar Tests durch, danach wird die Version dann als "stable" freigegeben.


    Zum Entwicklungsstand der v1.8 gibt es noch separate Informationen (deren Changelog ist auch deutlich länger ;)

    Hallo,


    biete spielen Sie die aktuelle Preview-Version ein (v1.7.5-r3221) - damit sollte das Problem behoben sein.
    Offenbar haben Sie mindestens einen "sehr großen" vHost konfiguriert (soll heißen: wo die reinen Daten aus vHost-Konfiguration und ggf. SSL-Zertifikaten insgesamt >1MB groß sind). Eine eher zu Testzwecken implementierte Prüfung hat diese Nachricht dann nicht durchgelassen. Ab sofort können die einzelnen Konfigurationen nahezu unbegrenzt groß werden.


    Viele Grüße


    -Klaus Keppler

    Wer gestern Abend das neueste PHP5-Paket von Debian Wheezy (5.4.35-0+deb7u1) eingespielt hat, erhält seitdem alle 30 Minuten eine Cron-Fehlermeldung:

    Zitat

    Cron <root@www> [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime)


    sed: invalid option -- 'z'
    Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...


    Dabei handelt es sich um einen Fehler im Debian-Paket (siehe Debian-Bug #770105).


    Ein vorläufiger Workaround ist, in der Datei /usr/lib/php5/sessionclean die erste Befehlszeile (beginnt mit "[ -x /usr/bin/lsof ] ...]") auszukommentieren.


    Ein Update ist wohl schon in Arbeit, dabei werden aber die Patches einer anderen Sicherheitslücken angeblich wieder entfernt...


    Viele Grüße


    -Klaus Keppler

    Hallo,


    aufgrund eines Umzugs auf neuere Hardware waren die LiveConfig-Websites eben für knapp 30 Minuten nicht erreichbar. Das war so natürlich nicht geplant: da alles virtualisiert läuft, sollte eigentlich nur ein Container umziehen. Der Teufel steckte dann im Detail: auf dem neuen System lief ein geringfügig anderer Kernel, mit diesem lief "fam" (file alternation monitor) nicht mehr, damit kam der Webserver nicht mehr korrekt hoch :(


    Wir werden Serverarbeiten künftig hier ankündigen, auch wenn diese als "trivial" eingestuft sind. :rolleyes:


    Ironie des Schicksals: genau diese Arbeiten dienten übrigens der Vorbereitung für zusätzliche Redundanz (via Round-Robin-DNS)...

    Code
    Nov 12 23:28:15 system01 lcsam[17737]: 5.83.128.154: lcsam_helo('node-fra')
    Nov 12 23:28:15 system01 lcsam[17737]: 5.83.128.154: lcsam_envfrom('monitoring@isp-serverfarm.de')
    Nov 12 23:28:15 system01 lcsam[17737]: 5.83.128.154: lcsam_abort()
    Nov 12 23:28:15 system01 lcsam[17737]: : lcsam_close()
    Nov 12 23:31:35 system01 postfix/smtpd[4579]: warning: connect to Milter service unix:/var/run/lcsam.sock: No such file or directory


    Prüfen Sie bitte mal im mail.log bzw. syslog, was zwischen 23:28:15 und 23:31:35 eventuell so alles passiert ist.


    Zitat

    Der Dienst war nach dem letzten Auswahl und Neustart am 12.11. um 22:22, nach nur etwas mehr als 24 Stunden wieder ausgestiegen.


    Das Blöde an der Sache ist, dass der Milter-Prozess komplett durch das Milter-Framework gesteuert wird - man registriert quasi nur die eigenen Handler-Funktionen. Wenn sich das bei Ihnen aber so schnell reproduzieren lässt, bauen wir mal weitere Debug-Informationen ein, die vielleicht einen Hinweis darauf liefern könnten wo genau Milter da aussteigt.

    Suchen Sie bitte mal im /var/log/mail.log, was da so zum lcsam-Prozess drin steht (am besten per grep). Wenn lcsam nicht mehr läuft, müsste es sich natürlich irgendwann beendet haben. Vielleicht gibt das Log mehr Auskünfte dazu.


    Ich gehe davon aus, dass Sie die aktuelle LC-Version einsetzen? (v1.7.5-r3127)

    Ja, DNSSEC wird unterstützt, offiziell aber noch als "Beta".
    Soweit wir das bislang getestet haben funktioniert alles (auch dynamische Zonen-Updates werden korrekt signiert), das mit dem Key-Rollover müssen wir aber noch ausführlicher prüfen.

    Hallo,


    weil sich bei uns die Anfragen zur v1.8 nun häufen, möchte ich an dieser Stelle mal eine kurze Info zum Zwischenstand geben.


    v1.8 hat ja zwei Schwerpunkte: die Unterstützung eigener CSS-Templates sowie der Ausbau der DNS-Verwaltung (frei konfigurierbare A/MX/CNAME/etc. Records).


    Zum CSS: die Arbeiten hieran waren etwas umfangreicher als ursprünglich angenommen. Wir haben die Gelegenheit genutzt, die komplette HTML-Erzeugung zu optimieren. Das heißt: über 80 Eingabemasken wurden komplett überarbeitet, außerdem wurden die meisten unserer eigenen JavaScript-Funktionen in Form von jQuery-Plugins umgeschrieben. Diese Arbeiten sind nun zum größten Teil erledigt und werden diese Woche abgeschlossen.
    Erwähnen möchte ich noch, dass neben den geänderten Eingabemasken parallel auch alle Tests überarbeitet werden mussten, da sich die XPath-Ausdrücke im HTML natürlich auch geändert haben. Da dauert leider alles etwas.


    Zum DNS: die "komplizierten" Sachen sind auch erledigt (insbes. Sicherstellung der dynamischen Zonen-Updates, Vermeidung von Fehlkonfigurationen). Hier werden aktuell "nur" noch die Eingabemasken angepasst, was ebenfalls in den nächsten Tagen abgeschlossen ist.


    Nicht zuletzt wurde natürlich auch an einigen anderen Stellen Verbesserungen durchgeführt. Die Postfix-Verwaltung (postfix.lua) wurde komplett überarbeitet und stark vereinfacht; wer eigene Einstellungen an der main.cf vornehmen möchte, kann das nun mit einer ganz einfachen "Overlay"-Tabelle machen. Beispielcode ist dann im nächsten Handbuch enthalten.


    Zudem wurde angeregt, die Lua-Scripte auf Github zu pflegen. Wir haben nach kurzer Besprechung beschlossen, das einfach mal auszuprobieren. Unsere eigene Versionsverwaltung wird unabhängig davon weiter gepflegt werden, der Stand dann aber regelmäßig mit Github abgeglichen. Aus Zeitgründen werden wir das aber erst nach der Freigabe von LiveConfig v1.8 angehen.


    Voraussichtlich am Mittwoch (19.11.) werden wir einen separaten Demo-Server mit der v1.8 bereit stellen, um sich schon mal einen ersten Eindruck vom neuen Look&Feel verschaffen zu können.


    Viele Grüße


    -Klaus Keppler

    Könnten Sie das "klappt nicht" bitte etwas konkretisieren?
    Bei all unseren Testsystemen klappt nämlich der Statistikzugriff absolut reibungslos auf der jeweils im LiveConfig eingestellten Subdomain - egal ob diese nun ein "www" davor hat oder nicht.


    Wenn Kunden .htaccess-Dateien mit Rewrite-Regeln anlegen, die dann eventuell die Erreichbarkeit der Statistik beeinträchtigen, dann ist das Sache der jeweiligen Kunden (LiveConfig kann hierauf ja keinen Einfluss nehmen).


    Viele Grüße


    -Klaus Keppler

    Noch mal als Hinweis: "example.org" ist kein Hostname.
    "www.example.org" ist auch kein Hostname.
    "www" ist ein Hostname. "example.org" ist ein Domainname. "www.example.org" ist ein FQDN (Fully Qualified Domain Name).


    Der Befehl "hostname" sollte "www" ausspucken. Der Befehl "hostname -f" sollte "www.example.org" ausgeben.


    Viele Grüße


    -Klaus Keppler

    Äh - die exakte Subdomain, unter der die Statistik erreichbar sein soll, lässt sich doch über LiveConfig einstellen...
    Hosting -> Webspace -> Web-Statistiken
    In dem Popup, in dem man auch Benutzername & Passwort einträgt, wählt man auch die gewünschte Subdomain aus. Wer seine Statistiken unter "www.example.org" abrufen will, wählt eben "www.example.org" aus, und nicht "example.org".