Hello,
the PHP packages for Debian-based systems have been updated to version 7.0.20 and 7.1.6.
Best regards
-Klaus Keppler
Hello,
the PHP packages for Debian-based systems have been updated to version 7.0.20 and 7.1.6.
Best regards
-Klaus Keppler
Hallo,
die PHP-Pakete für Debian-basierte Systeme wurden eben auf die Versionen 7.0.20 und 7.1.6 aktualisiert.
Viele Grüße
-Klaus Keppler
Manueller Eintrag in der my.cnf: sql_mode=NO_ENGINE_SUBSTITUTION.
Oder die /usr/my.cnf (zumindest bei den Oracle-Paketen von MySQL) löschen.
Dieser SQL-Mode reicht leider nicht (hakt noch woanders). Wir haben das nun durch angepasste Session-Einstellungen im MySQL-Client gelöst.
Unter Debian 9 gibt es noch einen anderen nervigen Bug, der bislang nur Ubuntu vorbehalten war: die "socket = /var/run/mysqld/mysqld.sock"-Einstellung fehlt im [client]-Abschnitt (#864662). Von Debian paketierte Software sollte das nicht stören (die haben den Suchpfad im Client manuell von /tmp/mysqld.sock auf /var/run/mysqld/mysqld.sock geändert), jegliche "Fremdsoftware" könnte da aber Probleme haben. Wir haben LiveConfig auch hierfür anpassen müssen, um nicht in der globalen MySQL-Konfiguration herumtricksen zu müssen.
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
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
Nö. Hatte nur bisher keine Zeit, die Pakete zu bauen / zu suchen
Wir werden die zusätzlichen PHP-Versionen (5.3-7.1) auch für Debian 9 bauen. Dürfte in 1-2 Wochen erledigt sein.
Auch wenn's off-topic ist:
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...
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.
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
[code]http://www.loswebos.de /var/www/vertragY/logs/access.log 0/0
http://www.loswebos.de /var/www/vertragY/logs/access.log 0/0
http://www.loswebos.de /var/www/vertragY/logs/access.log 0/0
[...]
Sehr merkwürdig... ist das überall auch der selbe Vertragsname (vertragY), oder verschiedene Namen?
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
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
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
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.
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:
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.).
Wird etwas im LiveConfig-Log protokolliert wenn der Backup-Download fehl schlägt?
(ggf. Log-Meldungen mal an support@liveconfig.com schicken)
Sorry, die Fehlermeldung ist ja "permission denied".
Also andere Frage: wem "gehört" die /var/run/lcsam.sock?
Auf Debian/Ubuntu sollte diese postfix:mail gehören und mode=0700 haben (also nur vom User "postfix" beschreibbar sein).
Vielleicht läuft der Postfix-Prozess, der Kontakt mit lcsam aufnehmen möchte, in einer chroot-Umgebung?
Was ergibt "grep '^smtp' /etc/postfix/master.cf"?
(oder anders: welche Prozesse in /etc/postfix/master.cf in der Spalte "chroot" überall ein "y" stehen?)
Ganz einfach: den "Options"-Befehl aus der genannten .htaccess-Datei entfernen.
Hat mit LiveConfig nichts zu tun.