Kein gültiger FQDN

Hallo!

Ich bin ja noch immer erst bei der Installation und im Versuchsstadium.
Schon beim Versuch Kolab in Betrieb zu nehmen kam eine Meldung, hex.666.ath.cx wäre kein gültiger FQDN.
Unter Centos6 und Kolab3 hat diese Art FQDN allerdings gut funktioniert.
Nun wollte ich (Server neu aufgebaut, weil Kolabproblem) eine Freigabe für Samba einrichten und wieder kommt diese Meldung.
Was muß ich denn für einen FQDN nach welchen Regeln vergeben, daß funktioniert bzw angenommen wird?

666.ath.cx ist die Dyndns Adresse
hex heißt der Rechner.

Hallo,

ich hoffe mal nicht, dass die Prüfung okkultistische Gründe (Sechshundertsechsundsechzig) hat.
Aber wenn Sie uns den Punkt des Setups (UCS-Installation oder Kolab) sagen, kann vielleicht jemand in den Skripten oder Quellen nachsehen, was die Prüfung da versucht. Vermutlich hat jemand seine eigene Ergänzung von RFC1035 eingebaut.

Viele Grüße,
Dirk Ahrnke

Hallo!

ich vermute auch, daß die Prüfung nicht auf 666 reagiert. Habe mal einen esoterikklamauk au www.sechssechssechs.net fabriziert.

Ich installier UCS gerade neu und übernehme mal (bis auf das angebotene xxx) die angebotene FQDN (xxx.yyy.intranet) um weiterzukommen.

So genau hab ich das nicht mehr im Kopf, leider.
Die Installationen haben jeweils geklappt.
Beim Kolab war es beim anlegen eines (des ersten) Benutzers im Backend, das ging nicht.
Beim Domänencontroller war es beim Anlegen eines (des ersten) shares. (Allgemein)

Hallo,

die aktuelle Kolab-Integration für UCS hat z.Zt. Probleme wenn der eigene Hostname, LDAP und Maildomains nicht zu 100% übereinstimmen.
Kolab Bug 5069. Das könnte auch hier die Ursache sein, wenngleich ich nie diesen Fehler gesehen habe.

Auch das Problem bei den Shares kann ich nicht nachvollziehen.
Können Sie davon mal Screenshots machen? Logs werden auch immer gern genommen. Wenn man nicht weiß welche, geht man in das in Frage kommende Logverzeichnis (hier eher /var/log/univention/), macht eine Repro und schaut sofort mit “ls -altr” welche Logs geändert wurden.

Viele Grüße,
Dirk Ahrnke

Hallo!

Ich war ein bißchen voreilig, da ich keine so prompte antwort erwartet habe und installiere UCS gerade einfach neu.

Wenn Ihnen das hilft, setze ich das nochmal mit meiner Wunschdomain auf. Kein Problem! Momentchen!

Hallo!

Das oben geschilderte Problem äußert sich so während der Grundeinstellung der Freigaben
anbei ein Foto (ist momentan einfacher für mich als screenshot)

Mit einem log kann ich momentan noch nicht dienen. Verblüffenderweise habe ich als Administrator “keinen Zugriff” auf die logs ???

… Pardon ! muß erst su root machen! Sind aber zu viele logs, die in Frage kommen und ich weiß nicht, wonach ich suchen soll

Hallo,

das ist reproduzierbar.
Ich habe dazu [bug]39364[/bug] erstellt.

Viele Grüße,
Dirk Ahrnke

Hallo!

Danke für die prompten Antworten.

Kann ich in der Verwaltungsoberfläche den FQDN einfach ändern? Oder besser neu installieren?
Dann gebe ich mir halt einen neuen Dyndns Namen, mit z.B Buchstaben statt Zahlen. (deprecated?)
Sie sollte halt dem Scheme Rechnername.account.dyndns.org genügen können.
Brauche ich dann eine neue (umsonstene Core) Lizenz?

Hallo,

fangen wir bei der Beantwortung bei der Frage nach der Lizenz an. Die hängt an der LDAP base. Deren Änderung wiederum ist eindeutig nicht trivial und man benötigt definitiv auch eine andere Lizenz.
Der Domain-Name ist eigentlich unabhängig. Der zitierte Kolab-Bug zeigt, dass es aber Probleme geben kann, wenn man vom üblichen Schema abweicht.
Man kann DNS-Zonen neu erstellen und alle benötigten Dinge umziehen. Das ist aber aufwändig. Umbenennen geht m.E. nicht.

Fazit: Neu installieren geht am schnellsten, zumindest, wenn die Installation noch am Anfang ist.

Viele Grüße,
Dirk Ahrnke

Hallo!

Ich hab UCS neu installiert mit einer anderen, zahlenlosen FQDN
also quasi server.account.dyndns.org

Das hat funktioniert.
Das Einrichten der Domain User und Freigaben erscheint mir verglichen mit webmin unter Centos
oder gar manueller Configuration momentan echt entspannend, weil es an z.B win10 sofort funktioniert.

was mich bißchen verwirrt sind die Freigaben netlogon und sysvol im windowsexplorer, wenn ich bei mir
\192.168.1.70 als IP von UCS im Suchfeld eingebe. Eigentlich sollten die Nutzer doch nur die absichtlichen Freigaben sehen ???
Das verleitet Poweruser doch u.U zum Rumbasteln?

pool1 ist die gewollte Freigabe.

Mastodon