1 Master und 28 Slaves

UCS - Univention Corporate Server
#1

hallo community,
ich möchte euch mal etwas fragen und hoffe ihr könnt mir auskunft geben, ich weiß nämlich noch nicht ob ucs das richtige für mich ist.

also:
Mein plan sieht folgendermaßen aus

ich möchte zentral einen ucs mit der domain example.lan haben auf der diverse dienste wie nextcloud und groupware laufen. desweiteren habe ich 28 Standorte die mit vpn verbunden sind und denen wollte ich die subdomain a.example.lan, b.example.lan usw. geben.

die user möchte ich über den master hinzufügen aber die user + dateifreigaben sollen auf den servern vor ort liegen.
die user in den standorten sollen sich dann natürlich auch auf den diensten des masters (nextcloud, groupware) anmelden können.

ist das ganze mit ucs realisierbar oder eher nicht?
hatte jetzt schonmal einen master und einen slave installiert aber gefühlt konnte ich das nicht gut verbinden.
auch eine anleitung zu meinem plan finde ich leider nicht (daher meine nachricht hier)

Hoffe auf feedback von euch :slight_smile:

grüße
Michael

#2

Hallo Michael,

ich bin hier kein großer Experte, ich beteibe nur einen UCS Master und einen Backup DC. Aber so wie ich das sehe ist UCS durchaus dafür geeignet. Du hast dann eine Management Console inder du zentral alle Freigaben für alle deine Server verwalten kannst und angeben auf welchem Server diese Freigaben liegen. Die Anmeldung sollte dann auch von allen Standorten funktionieren. Wo die Userdaten dann abgelegt werden udn ob man das festlegen kann weiß ich nicht genau.

grüße

#3

das ist doch schonmal super.
ob mir hier einer wohl stichpunktartig den ablauf für die umsetzung aufschreiben könnte?

müssen die ucs system an den anderen standorten slaves sein?
muss ich im main ucs die netzwerke anlegen?
muss ich die OUs selber einrichten oder macht das der slave?
irgendwie fehlt mir für mein vorhaben eine anlaufstelle.

danke schonmal und grüße

Michael

#4

Hallo @trapper-keeper,

kennst Du? https://docs.software-univention.de/scenarios-de.html

Die docs insgesamt sehr gut. Ansonsten auch einzelne Artikel bei https://www.univention.de/news/blog-de/

Da findet man über die Jahre auch Einiges in der Richtung. Hier im Forum auch zu VPN Umsetzungen.

Grüße,
Bernd

#5

uuhhh, nein das hatte ich noch nicht entdeckt, dankeschön :slight_smile:
werde mich da mal ein wenig reinlesen und bei fragen hier nochmal melden, dankeschön

Grüße
Michael

#6

Es ist ratsam die Applikationen (Mail, Groupware, __Cloud, etc) auf einem separaten, zentralen System (typischerweise ein DC Slave) zu betreiben, damit deren CPU- und I/O-intensiven Operationen die Replikation des LDAPs vom Master zu den Standorten nicht ausbremsen.
Topologisch läge dieser “neben” dem Master im RZ oder in einer DMZ. Es ist auch gut die Apps vom Master zu separieren, da er ja vermutlich viele aus dem Internet erreichbare Applikationen anbietet und somit die größte Angriffsfläche bietet.

Grüße
Daniel

#7

Hallo Daniel,
danke für den Rat, wir lassen mal eben unseren Server etwas aufrüsten um auf nummer sicher zu gehen das die ressourcen reichen.

Habe jetzt mal etwas rumgespielt mit dem system und es hat alles erschreckend gut und nahezu fehlerfrei funktioniert (kannte ich von zentyal beispielsweise anders).

Main UCS läuft unter example.intern und die slaves an den standorten, brauchen zwar richtig lange (knapp eine stunde) bis sie sich als slave verbunden haben aber danach laufen auch die problemlos.

folgendes ist mir allerdings aufgefallen.
die slaves haben beim ausführen der scripts zum domain-join das problem das “05univention-bind” immer auf ausstehend bleibt, ist das normal? habe jetzt nicht irgendwie feststellen können das etwas nicht funktioniert.

eine kleine verständnisfrage:
ich hatte eigentlich gedacht ich kann an den Standorten den Slave als DNS angeben, das funktioniert bei mir aber nicht, sondern nur wenn ich den main ucs als DNS angebe. Das hat seine richtigkeit?

Grüße
Michael

#8

Die Slaves müssen beim initialen join (und auch später bei univention-run-join-scripts) den DC Master im DNS auflösen können. Dazu befragen sie ihr eigenes, lokales DNS (→bind). Wenn das noch nicht provisioniert (join script [noch] nicht erfolgreich beendet) ist, dann muss der Master vom nächsten DNS-Server aufgelöst werden. Ist das der DSL-Router/RZ-DNS, klappt das nicht. Hier kann man sich mit manuellen Einträgen für alle DC Master und DC Backups in der /etc/hosts helfen. Nachdem das LDAP komplett repliziert und der bind provisioniert wurde, sollte es keine weiteren Probleme geben, weil der bind seine Infos aus dem lokalen LDAP bezieht.
Wichtig:
Die UCR Variablen nameserver[1,2,3] sind diejenigen, die die Einträge in /etc/resolv.conf erzeugen. Hier sollte die IPs von Master/Backups stehen. Diese DNS-Server sollten die Rechner der UCS-Domäne (master.ucs.local o.ä. usw.) auflösen können.
Die UCR Variablen dns/forwarder[1,2,3] sind für die externen DNS Server - also den DSL-Router/RZ-DNS gedacht.
Zum Join sollte also in nameserver[1,2,3] nur die IP des DC Master stehen! Prüfen mit nslookup my-master.my-ucs.local

Grüße
Daniel

#9

Hi Daniel,
danke für deine auskunft :slight_smile:
konnte den Fehler beheben, habe ausversehen einmal quatsch gemacht auf den wir nicht weiter eingehen müssen :smiley:

aktuell läuft alles tadellos und dienstag wird der 1. Standort eingebunden.

Danke erstmal und Grüße
Michael

Mastodon