Beiträge von WebService4U

    Bei der Installation von Drupal 7.80 über den Application Installer von LiveConfig 2.x schlägt seit kurzem der Download bzw. die Installation fehl.

    Ursache ist nicht das eigentliche Drupal-Paket, sondern das deutsche Sprachpaket.

    Im Installer

    wai-drupal-7.80-1.php

    ist für das deutsche Sprachpaket folgende Datei hinterlegt:

    https://ftp.drupal.org/files/translations/7.x/drupal/drupal-7.80.de.po

    LiveConfig erwartet dafür die fest im WAI-Skript hinterlegte SHA1-Prüfsumme:

    e424c5cea317b1063812059bf6d9fe11a7ddc167

    Die Datei wurde auf dem Drupal-Server jedoch am 19.09.2026 neu erzeugt. Der HTTP-Header liefert entsprechend:

    Last-Modified: Sat, 19 Sep 2026 03:12:52 GMT

    Auch im Sprachpaket selbst findet sich:

    POT-Creation-Date: 2026-09-19 03:12+0000

    Die aktuell ausgelieferte Datei hat nun die SHA1-Prüfsumme:

    591501bbbb9f10abea01fe81753c0f98ecee55df

    Das eigentliche Drupal-Paket drupal-7.80.tar.gz ist unverändert und besitzt weiterhin die im Installer hinterlegte korrekte SHA1-Prüfsumme e9d8914beaee3f1ccba62e9d9fa253733e34504e.

    Lösung:

    In wai-drupal-7.80-1.php beim deutschen LANGUAGEPACK die alte SHA1

    e424c5cea317b1063812059bf6d9fe11a7ddc167

    durch

    591501bbbb9f10abea01fe81753c0f98ecee55df

    ersetzen.

    Danach funktioniert die Drupal-Installation über den Application Installer wieder.

    @kkeppler
    Vielleicht kann die korrigierte Prüfsumme auch im Installationsscript zentral neu hinterlegt werden, damit nicht jeder frickeln muss.

    Jeder LiveConfig-Server ist primärer Nameserver der Domain, die auf ihm liegen. In allen Liveconfig-Servern sind 3 Nameserver von InternetX sekundäre Nameserver. Ich lege die Domain in LiveConfig an und registriere sie danach bei InternetX im Modus "nur sekundäre Nameserver", dabei wird dann der zugehörige LiveConfig-Server als primärer Nameserver angegeben und die 3 Nameserver von InternetX als sekundäre. InternetX überträgt die Zone vom LiveCOnfig-Server. Funktioniert tadellos.

    Hier werden also keine primären Nameserver gespiegelt, sondern jedo Domain hat EINEN, der eben genau der LiveConfig-Server ist, auf dem sie liegt.

    Vorteil: Ich muss keine(n) eigene(n) Nameserver pflegen und vermutlich falle ich durch diese "Infrastruktur" auch nicht mehr unter NIS2, denn prinzipiell falle ja DNS-Diensteanbieter darunter. Und ich muss mich nicht um Gefrickel kümmern, wie ich die Zonen von A nach B bekomme.

    Ich hatte gestern einen sehr netten Kontakt zu Smart-Nic. Sehr angenehmer und ehrliche Kommunikation und ich würde ja sofort dorthin umziehen. Leider habe ich nur ein Problem: Mein DNS-Setup. Die Liveconfig-Server sind der primäre Nameserver, die Nameserver von InternetX sind die sekundären, die IP von InternetX für AXFR ist in Liveconfig hinterlegt. Ich lege die Domain in LiveConfig an und registriere sie dann bei InternetX im Modus "nur sekundäre Nameserver" und hinterlege den LiveConfig-Server als primären Nameserver. Das wars. Funktioniert einwandfrei. Leider kann Smart-Nic das nicht und das ist für mich gerade der Showstopper. Leider. Aber vielleicht hat ja einer der Kollegen hier eine Lösung für mich.

    LC-Version: 2.18.10


    Setting:

    *@domain.de leitet weiter in Postfach sammler@domain.de

    test1@domain.de (Postfach)

    test2@domain.de (Postfach)

    test_liste@domain.de leitet weiter auf test1@domain.de, test2@domain.de


    Test 1:

    test_liste@domain.de hat SRS aktiviert

    Mail von xy@z.de an test_liste@domain.de

    Erwartung: Mail kommt bei test1@domain.de und test2@domain.de an

    Ergebnis: Mail kommt bei sammler@domain.de (die Catchall fängt die Mail ein)


    Test 2:

    test_liste@domain.de hat SRS deaktiviert

    Mail von xy@z.de an test_liste@domain.de

    Erwartung: Mail kommt bei test1@domain.de und test2@domain.de an

    Ergebnis: Mail kommt bei test1@domain.de und test2@domain.de an - OK


    Test 3:

    *@domain.de wird gelöscht

    test_liste@domain.de hat SRS aktiviert

    Mail von xy@z.de an test_liste@domain.de

    Erwartung: Mail kommt bei test1@domain.de und test2@domain.de an

    Ergebnis: Mail kommt bei test1@domain.de und test2@domain.de an - OK


    Test 4:

    *@domain.de wird gelöscht

    test_liste@domain.de hat SRS deaktiviert

    Mail von xy@z.de an test_liste@domain.de

    Erwartung: Mail kommt bei test1@domain.de und test2@domain.de an

    Ergebnis: Mail kommt bei test1@domain.de und test2@domain.de an - OK


    Fazit: Das Vorhandensein einer Catchall-Adresse verhindert die Weiterleitung von E-Mails, wenn SRS an der Weiterzuleitenden Adresse aktiviert ist. Dabei spielt es keine Rolle, ob test_liste@domain.de ein Postfach mit gleichzeitiger Weiterleitung oder nur eine Adresse mit Weiterleitung ist.


    Soll das so? Ich denke nein.

    Ich bin da ganz bei Dir und ehrlich gesagt, verstehe ich es auch nicht, warum diese Funktion fehlt. Es ist ja nicht nur der Anwendungsfall, einen Kunden von Server zu Server zu verschieben. Da gibt es noch weitere:

    - Alle Verträge eines Kunden in einen anderen Kundenaccount verschieben

    - Domains mit allem drum und dran oder auch nur mit Subdomains undoder Postfächern, Zertifikaten, Datenbanken innerhalb des Servers in einen anderen Webhostingvertrag verschieben

    - Reselleraccount löschen, der viele Kunden und Verträge angelegt, diese aber bei der Kündigung nicht selbst gelöscht hat

    - Export/Import aller Einstellungen eines Kunden/Vertrages

    - Massenänderung von Domains von externer auf interne DNS

    - Massenänderung PHP-Version

    ...

    soweit ich weiß ist der Support über support@liveconfig.com erreichbar? Oder per Telefon...? (Zumindest bei uns klappt das tadellos) Ein Hinweis, das dies ein Support-Forum ist hab ich noch nicht wirklich gesehen....

    Hast du nicht? Naja, unter https://www.liveconfig.com/de/ befindet sich der Link zum Forum im Menüpunkt "Support", wenn ich mich nicht irre. Was darf ich dann hier erwarten? Dass hier nicht nur User versuchen Usern zu helfen, sondern sich die Herrschaften der LiveConfig GmbH vielleicht auch mal regelmäßig zu Wort melden und mit regelmäßig meine ich nicht alle paar Monate in der Kategorie "Ankündigungen und neue Versionen".


    Und was den Support per E-Mail angeht: Ticket LC#2022090234000027 vom 02.09.2022 (ja, wir lesen richtig) ist seit 2 JAHREN trotz Nachfrage absolut unbeantwortet. Bei aller Liebe: wenn ich so mit meinen Kunden umgehen würde, dann könnte ich den Laden zumachen. Ich kann absolut NICHT verstehen, dass man soviel Energie in eine Veriosn 3.x legt, obwohl in der aktuellen Stable hier seit vielen Jahren unbearbeitete Baustellen sind. Das alles wirft kein gutes Licht mehr auf Herrn Keppler und sein Team. Eigentlich warte ich nur noch darauf, dass es irgendwann eine Pressemitteilung gibt: "LiveConfig verkauft" oder "LiveConfig wird eingestellt, bitte wechseln Sie zu XY", denn das wäre wirklich extrem schade.


    Man verstehe micht bitte nicht falsch: ich bin ein großer Fan von LiveConfig, aber auch ein inzwischen sehr frustrierter Fan.

    Gut, dann wird das wohl darauf hinauslaufen, mit einem Shellscript


    1. alle Domains aus LIVECONFIG.DOMAINS der LC-Datenbank auszulesen, die D_DNSSETID auf 1 zu setzen und eine D_SERIAL zusetzen

    2. die notwendigen Zeilen für jede Domain an die /etc/bind/zones.liveconfig anzängen

    3. für jede Domain die /var/lib/bind/{DOMANNAME}.db zu erzeugen und die Standardwerte für jede Domain reinschreiben, dann für jede Subdomain die Einträge ergänzen und deren Rechte und Besitzer/Gruppe anzupassen

    4. bind neu zu starten

    5. In der Serververwaltung->E-Mail den Default-SPF setzen

    6. In der DNS-Verwaltung eine SOA-einstellung ändern und speichern


    Das habe ich gerade händisch ohne Script durchprobiert und scheint zu funktionieren. Die SPF-Einträge sind dann auch im Zonefilevorhanden, auch wenn ich sie im Schritt 2 nicht scon eingefügt hatte und auch die mail._domainkey-Einträge sind dann gesetzt. Dieser Weg scheint gangbar zu sein.


    Oder halt SOAP-API. Aber dafür bin ich noch zu dumm.


    Aber mal ganz im Ernst unter uns Pastorentöchtern - dieses ständige Rumgefrickle und der wirklich schlechte Support seitens der LiveConfig-GmbH ist langsam unerträglich. In den ersten Jahren konnte man das ja noch nachvollziehen, aber nach 13 Jahren sollte man da anders aufgestellt sein. Das musste mal raus.

    Völlig ins blaue geraten (wirklich geraten!!!).

    Umstellung per DB machen und dann einmal die IP Gruppen unter DNS aktualisieren.

    Meistens, in der LiveConfig Welt, ist es so, dass er mit einer Aktualisierung der IP Gruppen, alle Konfigurationen neu schreibt.


    Man könnte es ja mal mit einer Domain testen ;)

    Das war auch meine 1. Idee. Leider Fehlanzeige. Scheint dann nur über bereits vorhandene Zonen rüberzurollen.

    Ich möchte alle Domains von externen auf internen Nameserver ändern. Meine Idee war, dies direkt über die Datenbank zu versuchen:


    Tabelle DOMAINS: D_DNSSETID=1 setzen, D_SERIAL befüllen und D_STATUS=1 setzen.


    Wie bringe ich LC nun dazu, diese Änderungen in die Konfiguration des Servers zu schreiben?


    Bin für jede Hilfe dankbar, denn ich mag keine hunderte Domains durchklicken, um diese umzustellen.

    Zitat

    ... aber das Programm läuft natürlich noch, weil es ja lokal ist. Wäre es eine Cloud-Anwendung könnte man es von heute auf morgen nicht mehr benutzen....


    Das ist ein klarer Vorteil lokaler Software. Es gibt immer Vorteile und Nachteile. Spätestens, wenn Du ein Datenschutz-Audit hattest, wirst du verstehen, was die Nachteile lokaler Software sein können.

    Zitat
    .... Und was machst Du wenn Deine SAAS-Software nicht mehr läuft? ...

    Ich suche mir einen neuen Anbieter. Das dürfte nicht länger als 4 Wochen dauern und die stehe ich auch durch, ohne Rechnungen zu schreiben oder Lastschriften bei meinen Kunden zu ziehen.

    Zitat
    .... Klar, die Daten kann man exportieren - aber was damit dann machen? Hast Du ein zweites anderes Programm oder Dienstleister wo genau diese Daen wieder importierbar sind? Das kann ich mir kaum vorstellen.... Diese Daten in andere Programme zu übertragen wird auf eine einfache Weise kaum möglich sein.

    Also der Export, die Umstrukturierung/Anpassung an die Datenstruktur der neuen Software und der anschließende Import in eine neue Software sind ja nun wirklich kein Hexenwerk. Macht keinen Spaß, aber das ist mit wenig Aufwand leistbar. Den Aufwand hast du ja auch, wenn Deine lokale Software nicht mehr verfügbar ist und du das System wechseln mußt. Ist also hier weder von Vorteil noch Nachteil.

    Zitat

    Falls doch: Dann verrate uns mal Deinen Anbieter und die Software um die Du dann mit den Daten alternativ einsetzen kann.

    Mein Anbieter: siehe oben.


    Fazit: Beide Varianten haben Vor- und Nachteile. Deine absolute Aussage von oben ist und bleibt unbegründet und ist wohl nur eine persönliche Meinung. Meine Erfahrung sagt mir etwas anderes.

    Lieber flo4545, ich denke, wir missverstehen uns hier grundlegend. Ich bin seit 15 Jahren im Geschäft und ich bin mir durchaus der Zusammenhänge und Anforderungen bewusst, die ich an meine (Vor)Dienstleister stellen muss. Genau für die von Dir beschriebenen Fälle benötigst du einen Disaster-Recovery-Plan. Ich habe meine Buchhaltung seit Jahren in der Cloud und selbstverständlich habe ich im Rahmen meines DRP ein Backup-und-Restore-Konzept auch für diese Daten. Es spielt bei der Auswahl der Dienstleister durchaus eine Rolle, ob diese eine Möglichkeit bieten, die Daten zu exportieren und im Rahmen eines Backup-Konzepts an anderen Stellen vorzuhalten, exakt so, wie man es auch mit lokalen Daten oder Daten, die in Rechenzentren liegen, handhaben muß (Gehaltsabrechnung ist da auch ein schönes Beispiel, oder machst Du Deine Gehaltsabrechnungen für Deine Mitarbeiter selbst?). Insofern kann ich hier keinen Unterschied erkennen, ob Daten in einer Cloud liegen, durch Software im Rahmen von software as a service oder lokal bzw. im eigenen Netz gespeichert werden. Ich bleibe dabei: Die Aussage, dass Kundendaten nicht in die Cloud gehören, ist aus der Luft gegriffen.

    flo4545 Dass Kundendaten nicht in die Cloud gehören ist zunächst einmal eine sehr spanndende Behauptung. Den Nachweis, warum das sol sein soll, bleibst Du aber schuldig und meiner unwesentlichen Meinung nach, ist das auch frei erfunden. Das Argument vom toten Anbieter kann hier kaum greifen, denn das kann Dir auch lokal passieren, wenn Deine lokalen Speichermedien abrauchen. Für diese Fälle gibt es einen Disaster-Rcovery-Plan, und der schließt die Cloud-Daten hoffentlich mit ein.

    Wir arbeiten mit collmex. Collmex hat csv-Import- und Exportfunktionen, diese nutze ich dann über eigene kleine shell- oder php-scripte. Was ich an Collmex wirklich mag, ist die altmodische Oberfläche, die aber eben auch verdammt schnell ist. Das ganze hat aber seinen Preis. Vorher hatte ich Quickbooks (alles manuell gepflegt) und als das auf Grund der vielen Belege zu klein wurde, wollte ich auf Lexoffice umsteigen. Ist bei mir im test aber durchgefallen. Unübersichtlich, buggy, langsam. eigentlich totaler Schrott (just my 2 cents)

    Hallo Herr Keppler,


    werden in Ihrer Firma Support-Tickets Ihrer Kunden eigentlich auch bearbeitet oder ist die Bearbeitung durch die Eingangsbestätigung per Autoresponder schon als erledigt anzusehen?


    Das mag hier vielleicht nicht der richtige Ort sein, aber eine ähnliche Frage wurde ja schon mal gestellt und ich muß nun leider feststellen, dass sich an der Situation nichts verbessert hat. Konkret habe ich am 02.11.22 die Ticketnummer LC#2022090234000027 erhalten und seit dem - au0er der Eingangsbestätigung, die mir einen Bearbeitung oder zumindest Erstmeldung binnen 24 Stunden versprach - nichts mehr von Ihnen gehört, so dass das Problem auch für mich schon in Vergessenheit geriet. Daher habe ich dann (leider) am 02.11.22 ein neues Ticket geschrieben (LC#2022110234000031]). Auch hier wieder nur der nette Autoresponder.


    Wann darf ich mit Hilfe rechnen?