Beiträge von kk

  • Debian 9 "Stretch"

    Zitat von antondollmaier

    LiveConfig wird über Codename "main" installiert. Funktioniert mit Stretch wunderbar.


    In einigen Details waren doch noch Anpassungen für Debian 9 notwendig, damit sind wir nun durch (wir werden hierzu noch eine separate Wiki-Seite mit Hinweisen zum Upgrade anlegen).


    Zitat

    (ja, die PHP-Pakete fehlen. IMHO ist das allerdings seitens Keppler IT ein "zusätzlicher Service", kein Teil des Produktes LiveConfig.)


    Die PHP-Pakete für Debian 9 sind auch fertig (PHP 4.4/5.3/5.4/5.5/5.6/7.0/7.1). Das war eine ziemliche Herausforderung, etwa PHP 5.3 noch zum Laufen zu bekommen (das will nämlich zwingend OpenSSL 1.0.2 haben, Debian 9 kommt mit 1.1.0). Diskussionen ob das sinnvoll ist gab es schon oft genug, das lassen wir bitte sein.
    Die PHP-Pakete werden gerade signiert und ins Debian 9 Repo eingepflegt, das in den nächsten 3-4 Stunden online geht. Ich werde dann noch mal separat im Forum dazu etwas schreiben.


    Das nächste LiveConfig-Update läuft heute ebenfalls nur noch durch die Tests durch, bis zum späten Nachmittag sollte das ebenfalls bereit stehen.


    Viele Grüße


    -Klaus Keppler

  • Zertifikat wird nicht verlängert

    Zitat von kroerig
    Code
    HTTP ist für diese Domain nicht aktiviert


    Das ist auch richtig so, der Host für den dieses Zertifikat erstellt wurde ist nur per SSL erreichbar.


    Wie bekomme ich jetzt das Zertifikat automatisch verlängert?


    HTTP muss aktiviert sein, eine Weiterleitung auf HTTPS ist aber kein Problem (LiveConfig konfiguriert das so, dass die Authorisierung für Let's Encrypt damit funktioniert).


    Wenn HTTP für eine Domain deaktiviert ist, dürfte eher das zu einem erhöhten Supportaufwand führen (schließlich gibt es dann im Browser eine Fehlermeldung, wenn man die gewünschte Domain per HTTP ansurfen möchte).


    Viele Grüße


    -Klaus Keppler

  • Manuelle implementierung von SpamAssassin?

    Auch wenn's off-topic ist:

    Zitat von hchristo

    Your-Sponsoring.eu GbR
    Your-Sponsoring.eu - wir Sponsern dich!


    Eine GbR besteht immer mindestens aus zwei Gesellschaftern, ich sehe da aber nur einen (das wäre dann eine Einzelunternehmung). Im Impressum fehlen zudem etliche Pflichtangaben. Bitte mal mit der örtlichen IHK zusammensetzen um das schnellstmöglich zu überarbeiten...

  • Manuelle implementierung von SpamAssassin?

    Die von LiveConfig konfigurierte Integration von SpamAssassin funktioniert grundsätzlich. Manuelle Eingriffe in die Konfiguration sollte man nur vornehmen, wenn man genau weiß was man tut. "Copy & Paste Administration" können wir beim besten Willen nicht unterstützen.

  • Debian 9 "Stretch"

    Hallo,


    wir testen LiveConfig bereits seit einigen Monaten mit Debian 9, bislang einziger "Showstopper" ist derzeit nur noch MySQL (bzw. MariaDB) - die läuft nun standardmäßig im "strict mode". Wenn LiveConfig eben MySQL/MariaDB als Backend verwendet, dann gibt's derzeit noch Probleme (daran arbeiten wir aber schon). Wir peilen ein vollständig Debian-9 kompatibles Release um den 09. Juni herum an.


    Viele Grüße


    -Klaus Keppler

  • Didn't get replay-nonce from server

    Zitat von weltmeister

    Insgesamt könnte der gesamte SSL-Einrichtungsprozess wesentlich einfacher sein. Es gibt Provider, bei denen setzt man nur einen(!) Haken und die Sache ist erledigt.


    An dem Thema wird bereits gearbeitet. In den nächsten Monaten wird der SSL-Prozess komplett überarbeitet, so dass SSL tatsächlich nur noch mit einem Mausklick aktiviert wird. Das heißt, es muss dann u.a. kein Domainname mehr für das Zertifikat eingegeben werden, kein Let's Encrypt-Zugang angelegt werden, kein SSL in der IP-Gruppe aktiviert werden, und so weiter.
    Gleichzeitig soll auch die Einbindung anderer SSL-Anbieter (teil-)automatisiert werden, um LiveConfig auch unabhängig von der CA zu machen.


    Viele Grüße


    -Klaus Keppler

  • LiveConfig v2.3.0 (r4555) freigegeben

    Zitat von TCRserver

    Was definitiv noch nicht funktioniert ist die korrekte Serverkonfiguration von z.B. Bind9. Somit ist die Funktion bisher nur sehr eingeschränkt nutzbar ;)


    Was genau funktioniert denn bei Ihnen nicht?
    In unseren Testszenarien klappt nämlich alles, und ein paar Kunden nutzen dieses Feature erfolgreich im Produktivbetrieb.


    Es ist lediglich deshalb noch nicht offiziell dokumentiert, weil wir das Bearbeiten der IPs noch über die GUI ermöglichen möchten (damit niemand in die DB eingreifen muss).


    Viele Grüße


    -Klaus Keppler

  • LiveConfig v2.3.0 (r4555) freigegeben

    Zitat von rob

    Gibt es hier schon eine Info? Konnte es bisher immer reproduzieren!
    Wurde es evtl. ver(gelöscht)bessert? :)
    Die binary liegt noch dort (/usr/lib/liveconfig/lclogparse) wurde aber nicht mehr gestartet.


    Das Komplizierte ist: wir können es hier nirgendwo reproduzieren. :(
    Das "alte" init-Script /etc/init.d/lclogparse wird bewusst während dem Upgrade entfernt. Beim Start prüft LiveConfig, welche "Konfigurationsversion" aktiv ist (/etc/liveconfig/sysconfig, Variable "LC_CFGVERSION"). Ist diese <32, dann wird u.a. das lclogparse-Init-Script aus /usr/lib/liveconfig/lclogparse.init nach /etc/init.d/lclogparse kopiert und aktiviert.
    Das sieht auf den ersten Blick etwas umständlich aus, aber nur so kann LiveConfig in einer systemd-Welt die Services "sauber" aktivieren und deaktivieren.


    Sie können testweise mal in /etc/liveconfig/sysconfig die LC_CFGVERSION auf "31" setzen und LiveConfig (oder den lcclient) neu starten. Dieser sollte dann das init-Script für lclogparse anlegen.


    Der einzige sonstige Grund, warum das ggf. nicht passieren würde, wäre dass die Datei /etc/liveconfig/lclogparse.conf nicht existiert...


    Viele Grüße


    -Klaus Keppler

  • Fehler bei Upgrading database schema (r4440 -> r4441)

    Zitat von solidius

    Die vorherige Version müsste 2.2.3-r4343 gewesen sein.
    [...]
    Die Tabellen wurden nicht zurückgesetzt


    Code-seitig ist so ein Fehler absolut unmöglich, da die Schemaänderung von r4440 auf r4441 eindeutig ist. Es wird in der Tabelle HOSTINGCONTRACTS die Spalte HC_LOCKED erstellt - wenn diese schon vorhanden ist (wie in der Fehlermeldung beschrieben) dann nur weil das Schema durcheinander gebracht wurde.


    Sie können die Spalte HC_LOCKED einfach noch mal löschen (ALTER TABLE HOSTINGCONTRACTS DROP HC_LOCKED) und anschließend LiveConfig starten.
    Je nachdem was da mit der Datenbank los ist kann es aber unter Umständen an anderen Stellen krachen. :(

  • Fehler bei Upgrading database schema (r4440 -> r4441)

    Hallo Herr Strausmann,


    welche LiveConfig-Version genau hatten Sie denn vor dem Upgrade am Laufen?
    Dieser Fehler kann eigentlich nur auftreten, wenn einzelne Tabellen der LiveConfig-Datenbank zurückgesetzt wurden (z.B. Restore aus einem Backup).


    Was liefert der folgende SQL-Befehl:

    SQL
    SELECT LC_VALUE FROM LIVECONFIG WHERE LC_KEY='dbschema';

  • Manuelle implementierung von SpamAssassin?

    Zitat von hchristo

    Dann habe ich mir nach vielfachem Googlen die Postfix "master.cf" ma angeguckt und dort auch keine Spur von SpamAssassin.


    Für SpamAssassin hat LC einen eigenen Milterservice ("lcsam": LiveConfig SpamAssassin Milter).
    Die von Ihnen vorgenommenen Einstellungen sind unnötig und berücksichtigen auch nicht die im LiveConfig vorgenommenen Einstellungen (Aktivierung/Deaktivierung des Filters pro Postfach, individuelle Schwellwerte zur Markierung/Ablehnung von Spam, etc.).

  • error bei Domain Weiterleitung

    Zitat von dicker

    More information about this error may be available in the server error log.


    Und, was sagt das error log genau?
    (/var/log/apache2/error.log)


    Irgendwas wird da nämlich definitiv drin auftauchen, wenn der Server einen "Error 500" ausgibt.

  • LiveConfig v2.3.0 (r4555) freigegeben

    Der Fehler trat dann auf, wenn man unter "Serververwaltung" -> "Mail" -> "Postfix" im Feld "Servername" einen manuellen Namen eingestellt hatte und diesen mit LiveConfig r4552-r4555 auf den Standard-Namen zurückgesetzt hatte. Durch einen semantischen (aber nicht syntaktischen) Fehler in SQL kam dann dazu, dass zwar bestehende MX-Einträge gelöscht, der neue Name aber nicht mehr gesetzt wurde. :(


    Wir hatten an dieser Stelle nur getestet, ob die neue Funktionalität (NAT-IPs) korrekt arbeitet, aber diese "Nebenwirkung" nicht bemerkt. Ich bitte um Entschuldigung für die Unannehmlichkeiten - die aktualisierte Version steht bereits im Repository.


    Danke auch für die schnellen Rückmeldungen und die Unterstützung bei der Fehlersuche.


    Viele Grüße


    -Klaus Keppler