Beiträge von kk

Ich habe das irgendwo anders schon mal ausführlich beschrieben. Das ist kein Fehler im klassischen Sinn, sondern eine wohl "suboptimale" Darstellung.

Wenn jemand eine Domain anlegt ("example.org") werden automatisch zwei Subdomains erzeugt: einmal die mit dem Hostnamen "www", und einmal die mit einem leeren Hostnamen ("").

Löscht man nun http://www.example.org, bleibt logischerweise nur noch die Subdomain mit dem leeren Hostnamen (example.org) übrig.
Löscht man auch diese Subdomain, wäre streng genommen nur eine "leere" Domain übrig. LiveConfig kann das derzeit noch nicht separat hervorheben - daher sieht die "leere Domain" genauso aus wie eine Subdomain mit leerem Hostnamen (alles klar soweit?)
Legt man nun eine Subdomain "www" an, dann existiert nur http://www.example.org, nicht aber example.org.

Ich hoffe, etwas Licht in die Sache gebracht zu haben.

Viele Grüße

-Klaus Keppler

Kurz zur Info: bei einem Update der Zeitzonen-Datenbank sind offenbar einige Verknüpfungen kaputt gegangen Im kommenden LiveConfig-Update ist das korrigiert, künftige Zeitzonen-Updates werden wir "anders" machen.

Viele Grüße

-Klaus Keppler

Zitat von Aybee

Es sollte eine Subdomain angelegt werden in diesem Fall nbv.mk-xxx.de

Das Problem war, das keine DNS Einträge gemacht wurden somit die Domain keinen DNS Eintrag hat bzw keinen A Eintrag, weil LiveConfig eben eine Subzone angelegt hat anstatt eine Subdomain. Somit funktioniert die Subdomain nicht da kein A-Eintrag vorhanden war.

Woran haben Sie ausgemacht, dass der A-Record nicht angelegt wurde?
Das Bearbeiten von DNS-Einträgen läuft ausschließlich über dynamische DNS-Updates. In der Zonendatei (/var/lib/bind/<Zone>.db) ändert sich dabei in der Regel nichts. Es wird aber von BIND eine Journal-Datei (binär) erzeugt, welche alle Updates protokolliert.
Mit anderen Worten: der Inhalt der Zonen-Datei alleine ist erstmal nicht aussagekräftig. Man kann die Zonendatei aber durch BIND neu schreiben lassen (z.B. mit "rndc freeze <zone>", "rndc thaw <zone>").

LiveConfig schreibt selbst auch keine $ORIGIN-Abschnitte, das macht BIND selbst. Und das ist - wie gesagt - völlig ok und normal. Das geschieht manchmal etwa wenn nur einzelne DNS-Einträge eine abweichende TTL aufweisen. Ohne die vollständige Zonendatei kann ich an dieser Stelle auch nur herum raten...

Die ausnahmslos einzige Möglichkeit um zu prüfen, ob ein gewünschter DNS-Eintrag angelegt wurde ist, diesen direkt beim Primary DNS per "dig" abzufragen:

dig @[I]primary.dns.server[/I] [I]name.der.subdomain[/I] ANY

Viele Grüße

-Klaus Keppler

Zitat von Aybee

Nein hat er nicht, wir hatte es selber mit einer Test Subdomain probiert und da war es das selbe.

hevert A 79.143.XXX.XXX
hhvision A 79.143.XXX.XXX
house A 79.143.XXX.XXX
insert A 79.143.XXX.XXX
msh A 79.143.XXX.XXX
$ORIGIN nbv.mk-XXX.de.
$TTL 300 ; 5 minutes

So sah die Abfrage auch, die nbv.mk wurde ganz normal als Subdomain angelegt, unsere Test Subdomain sah genauso aus. Nach einem Bind restart und löschen der Subdomain funktioniert es dann wieder wie es sollte. Trotzdem komisch wie sowas passieren konnte.

Alles anzeigen

Ich verstehe das Problem irgendwie noch nicht ganz, mit den Daten kann ich leider nichts anfangen.
Was für eine Subzone nochmal? Wenn BIND eine Zonen-Datei aktualisiert, dann ist es völlig normal dass er identische Subzonen in eigene $ORIGIN-Abschnitte gruppiert.
Bitte beschreiben Sie, was genau gemacht wurde, was genau passiert ist und was daran falsch war.

Zitat von kt01

Also der Syslog gibt folgende Information zurück:

Code

Nov  2 10:10:24 web1 named[14531]: dns_dnssec_findzonekeys2: error reading private key file meindomainname.xyz/NSEC3RSASHA1/59090: file not found

Das sagt doch eigentlich schon alles...
Prüfen Sie bitte mal, ob auf Ihrem Primary DNS die Dareien /etc/bind/keys/K<Domain>.+007+<Id>.(key|private) vorhanden sind.
Falls diese nicht mehr existieren (auch nicht im Backup), dann müssen Sie einen neuen DNSSEC-Key für diese Domains anlegen und diesen auch beim Domainregistrar aktualisieren.

Viele Grüße

-Klaus Keppler

Zitat von Aybee

Also wir hatten es heute das ein Kunde eine Subdomain angelegt hat und LiveConfig diese als Subzone angelegt hat, wie kann sowas passieren?

Was genau meinen Sie mit "Subzone"?
Wie hat der Kunde die Subdomain angelegt? Hat er evtl. die Berechtigung, eigene Domains hinzuzufügen, und hat dann die Subdomain als Domain angelegt?

Zitat von kt01

Ich habe leider Gottes das gleiche Problem mit einer virtuellen Kiste unter Debian 8. Den Trick von HBO hab ich auch schon einmal ausprobiert, leider ohne Erfolg. Bei mir gibts nur solche Einträge, aber keine Socketfehler:

Code

[749|755] Error while updating NS records (host '', zone 'meindomainname.xyz'): DNS update failed

Kann mir so darauf erstmal keinen Reim machen, warum es von hier auf da nicht mehr funktioniert. Das Problem ist mir nach dem Hinzufügen einer neuen Kundendomain aufgefallen. (welche aber problemlos angelegt wurde)

Wird vielleicht ein Nameserver als NS-Record hinterlegt, der in der selben Zone wie die betroffene Domain liegt?
Ansonsten sollte es bei fehlgeschlagenen DNS-Updates eigentlich eine Meldung in /var/log/messages bzw. /var/log/syslog geben, oder ggf. im systemd ("journalctl").

Zitat von ateo

Unter welchen Umständen können es unzählige Zeilen in die Logfiles fremder Speicherplätze schaffen?

Kurz gesagt: gar nicht.
Webalizer wird für jeden Webspace ausschließlich mit /var/log/<Vertrag>/logs/access.log ausgeführt - anders gesagt: es fließen keine Daten "fremder" Webspaces in Webalizer mit ein.
Suchen Sie den betroffenen Begriff einfach mal in dieser Datei, da sollten die entsprechenden Zugriffe protokolliert sein.

In der Datei /etc/apache2/accesslog.map sehen Sie wiederum, in welcher Logdatei jeweils die Zugriffe der einzelnen Domains landen (in der accesslog.map steht jeweils nur der Domainname, der in der vHost-Konfiguration bei "ServerName" angegeben ist, die "ServerAlias"-Domains tauchen darin nicht auf).

Hallo,

danke für den Hinweis! Es handelte sich hier um einen Fehler, Thai kann tatsächlich nur auf der Anmeldeseite korrekt ausgewählt werden. Der Fehler wurde mit v2.3.0-r4377 behoben, diese Version wird in Kürze als Preview bereitgestellt.

Viele Grüße

-Klaus Keppler

Wie genau finden Sie heraus, dass der MX nicht hinzugefügt wurde?
Der einzige zuverlässige Weg um das zu prüfen ist ein DNS-Lookup am Primary DNS der Domain:

dig @name.server example.org MX

Der Blick in die Zonen-Datei reicht nicht (die wird nur einmalig beim Anlegen der Domain erzeugt, alle Änderungen erfolgen über dynamische Updates). Ein "normaler" nslookup beim Standard-Resolver kann wiederum gecachte Negativ-Auskünfte zurückgeben.

Im Zweifelsfall kann man auf dem Primary DNS den Befehl "rndc freeze example.org" und danach "rndc thaw example.org" ausführen, damit werden alle bis dato erfolgten dynamischen Änderungen in die Zonen-Datei geschrieben.

Viele Grüße

-Klaus Keppler

Das betraf nur das PHP 5.6.27 im "debian-test"-Repository.
Die heute freigegebene Version (Paketversion 5.6.27-2...) enthält auch das mysql-Modul.

Derzeit planen wir das Thema etwa Mitte November anzugehen. Wir streben dabei natürlich die "sauberste" Lösung an: eine Dual-Konfiguration mit RSA- und ECDSA-Schlüsseln. Das ist nicht ganz trivial (das Datenbankschema muss angepasst werden, der Bestellvorgang bei Let's Encrypt, u.v.m.). Ich bitte also um etwas Geduld - sobald es los geht, geben wir Bescheid.

Hello,

the PHP packages for Debian have been updated to version 5.6.27, 7.0.12 and 7.0.1rc4.

Best regards

-Klaus Keppler

Hallo,

die PHP-Pakete für Debian wurden eben auf die Versionen 5.6.27, 7.0.12 und 7.0.1rc4 aktualisiert.

Viele Grüße

-Klaus Keppler

Das gab es bereits an anderer Stelle. Let's Encrypt ist ab der Standard-Version enthalten, genauso wie auch einige andere Funktionen (u.a. DNSSEC).

Wasser ist auch kostenlos, trotzdem wird es weder aus der Leitung noch in Flaschen verschenkt.
So ist es eben auch mit den SSL-Zertifikaten. Die Lizenzgebühren für LiveConfig decken unseren Entwicklungsaufwand - es ist uns dafür völlig egal ob oder wie viele Let's-Encrypt-Zertifikate (oder Kunden, Domains, ...) damit verwaltet werden. Mit 2,35 EUR netto pro Monat bei einer Basic-Lizenz haben wir eben weniger Ressourcen als mit z.B. 8,24 EUR. Der Unterschied von 5,89,- EUR netto pro Monat entspricht etwa zwei Bier, drei Kaffee-to-Go oder einer Schachtel Zigaretten pro Monat...

Gab es eine konkrete Frage?

Sorry for the inconvenience - we've had some issues with that server (Pootle runs on a dedicated VPS).
It's up and running again.

By the way: thank you for your translations!

LiveConfig läuft prinzipiell unabhängig von PHP - es ist LC also egal ob Sie PHP 5.5.x oder 5.6.x nutzen.
Wie das Upgrade im Detail abläuft kommt auf Ihre Distribution an, bzw. aus welcher Quelle Sie Ihr aktuelles PHP-Paket installiert haben.

Sie können auch mehrere PHP-Versionen parallel nutzen (wenn Sie diese parallel installieren) - hierzu müssen Sie eine Datei namens /usr/lib/liveconfig/lua/custom.lua anlegen (siehe hier - wir bieten aber nur fertige PHP-Pakete für Debian-basierte Systeme).

Hello,

LiveConfig v2.2.3 (r4343) is now available for download. The most important changes are:

• updated TLS/SSL cipher list
• disabled 3DES for LiveConfig access
• added "X-Content-Type-Options" header to LiveConfig
• display error message (reason) when application installer script couldn't be run
• show mail server name when adding/editing a mailbox
• ACME: fixed bug with renewal of domain authorizations
• catch-all addresses remained in virtual_alias file after renaming
• TTL was not updated into zones when changed in DNS template (SOA)
• broken/hanging AppInstaller installations can now be deleted after restarting LiveConfig

See the changelog for the full list of changes.

Currently we're working on the next "big" release (v2.3) - we'll let you know as soon as the preview version is available.

Best regards

-Klaus Keppler

Hallo,

ab sofort steht LiveConfig in der Version 2.2.3 (r4343) zum Download bereit. Die wichtigsten Änderungen sind:

• Aktualisierung der SSL/TLS-Chiffren
• 3DES für Zugriff auf LiveConfig deaktiviert
• LiveConfig gibt nun einen "X-Content-Type-Options"-Header aus
• Anzeige der Fehlermeldung (Grund) wenn Anwendungs-Installations-Script nicht ausgeführt werden konnte
• Anzeige des Mailserver-Namens beim Hinzufügen/Bearbeiten eines Postfachs
• ACME: Fehler bei Erneuerung von Domain-Authorisierungen behoben
• Catch-All-Adressen blieben in virtual_alias-Datei erhalten auch wenn diese umbenannt wurden
• DNS-TTL wurde nicht in Zonen aktualisiert wenn diese in DNS-Vorlage geändert wurde (SOA)
• kaputte/hängende AppInstaller-Installationen können nun nach einem Neustart von LiveConfig gelöscht werden

Die vollständige Liste der Änderungen findet sich wie immer im Änderungsverlauf.

Derzeit laufen die Arbeiten für das nächste "große" Update (v2.3) auf Hochtouren - sobald die erste Preview bereit steht geben wir Bescheid.

Viele Grüße

-Klaus Keppler