Hello everyone,
we are trying to install a univention master completely preseeded.
So far so good, the debian installer runs through all steps.
But after successful grub installation, the whole process just stops.
Any ideas?
Kind regards,
René
Hallo erstmal,
Hast du mit einem USB-Stick probiert?
Wenn ich dich Richtig verstehe, versuchst du UCS mit einem PXE Server zu Installieren.
Wenn du es noch nicht getan hast, dann lade über die Univention Webseite das ISO-image runter und Installierst es mit einem USB-stick, damit habe ich mein System Installiert.
Gibt es irgendwelche Fehlermeldungen? wenn es im Installationsprozess fehler gibt (egal wo), such nach diesen Fehler oder nach den Fehlercode.
Hello,
ich habe schon ziemlich viele UCS Systeme installiert, also daran scheitert es nicht. 
Es geht hier wirklich um eine komplett automatisierte (preseeded) Installation übers Netzwerk.
Fehlermeldung gibt es keine:
Ich habe die PXE und Preseed Config hier einmal angehängt.
ucs-pxelinux.txt (217 Bytes) ucs-master-preseed.txt (5.4 KB)
lg
Ich habe so eben mit bekommen, dass das Univention Setup sehr wohl weiter läuft.
Wenn ich auf dem Screen wie oben im Bild in die Konsole wechsle, sehe ich unter /target/var/log/univention wie das Setup weiter läuft, allerdings gibt es keinen grafischen Output.
Das sind scheinbar die letzten Zeilen:
Wieder ein Stück weiter.
Die Installation läuft problemlos durch.
Auch das Univention Setup läuft danach los, und konfiguriert das System entsprechend der uss settings im preseed file.
Allerdings gibt es Probleme beim bind9 service.
Zum einen existiert /etc/bind9/univention.conf nicht, wodurch named-checkconfig bereits einen Fehler wirft und der dns Service gar nicht richtig starten kann.
Die rndc controll settings unter /etc/bind9/named.conf sind meines erachtens falsch, als Controll-Port ist hier 55555 angegeben, laut join log, wird aber laufend versucht Port 953 zu verwenden.
Lege ich die univention.conf via touch an, und ändere den Controll Port auf 953 lässt sich bind9 problemlos starten, und ein aufruf über “rndc status” klappt auch.
Allerdings geht es im Join Log immer noch nicht wirklich weiter.
Note: Das alles natürlich in einer chroot Session aus dem noch laufenden Installers heraus.
Könnte es sich hier um eine Bug handeln?
Nach etwa 2 Stunden läuft der restliche Join durch und das System startet in ein fertig installiertes System, allerdins nicht komplett sauber gejoint.
lg
-
As you already noticed Univention System Setup (USS) starts in the background after GRUB has been setup. USS itself does not send it’s own message to the front-end and so the last message from GRUB remains. You can switch to (Text-)console 4 so see USS running.
-
Setting up an UCS Master is tricky (and officially not supported), as setting up the Master is quiet different from setting up all other UCS roles: The later roles assume already running DNS, LDAP, … services, but the Master cannot. Therefore
univention-joinis never executed on the Master and the equivalent code is sprinkled over different locations in the code, mainly in USS setup-join.sh.
But setting up a Master can be done and actually I’m doing this on a regular basis to setup our UCS training environments.
The main issue with setting up the Master is that many services must be started while the installer is still in its chroot environment, where Debian normally disables starting any service: The installation gets stuck as USS assumes several services to be running, but actually they are not because of the chroot environment. This happens because the package post-installation scripts are required by Debian policy to use invoke-rc.d to start/stop services, which in turn asks policy-rc.d if the action is allowed. In the chroot environment all actions are denied (by default).
This is further complicated by the fact, that UCS still has not transitioned fully from runit to systemd and you have to also start runit during the installation, as systemd is not used during the installation but legacy SysV-Init (with runit for process supervision). Otherwise Univention Directory Listener (UDL) and Univention Directory Notifier (UDN) are not started.
Try inserting the following line into your profile:
d-i partman/early_command string sed -i 's/invoke-rc.d univention-runit/service univention-runit/' /var/lib/dpkg/info/di-univention-net-installer.postinst
You can test your seed/preseed.cfg file more easily by running it in a virtual machine with Qemu with something like this:
# Use the text-install instead of the graphical gkt/ one
# Make sure the kernel matches the ucs444 version in you preseed.cfg!
wget http://updates.software-univention.de/pxe/4.4-4/amd64/debian-installer/amd64/linux
wget http://updates.software-univention.de/pxe/4.4-4/amd64/debian-installer/amd64/initrd.gz
# Create empty test image
qemu-img create -f qcow2 test.qcow2 10G
# Run Qemu
qemu-system-x86_64 \
-machine q35,accel=kvm -m 2048 -cpu host \
-vga virtio -display gtk \
-net nic,model=virtio -net user,tftp=seed/ \
-drive file=test.qcow2,if=virtio,media=dirk,cache=unsafe,format=qcow2 \
-kernel linux -initrd initrd.gz \
-append 'auto=true priority=critical url=tftp://10.0.2.2/preseed.cfg' \
-no-reboot
# You can switch consoles with Alt-Left/Right
# Use `chroot /target bin/bash` for debugging the chroot
After the installation re-run the same command without the 3 last lines -kernel … -no-reboot to test your installation.
Oh god thank you
That did the trick, and thank you for the detailed explanation.
The setup is now finishied within a half hour and looks good afterwards.
The join scripts are executed, and the master seems to be setup correctly, exactly how we need it.
One further question.
Let me explain our use case first.
We are developing an automation, to deploy several customer platforms fully unattended at our datacenter, this includes standard linux distros and also univention servers.
The first one was the ucs master, which now works.
During the deployment, we use an separate network interface (vlan) which has access to the deployment servers (a debian vm with a dhcp and tftp server, and an ucs server without any ucs services nor a domain, for the ucs-net-installer and the ucs repository)
For univention we preseed the correct network configuration (for the main LAN) via uss variables in the preseed file, which works without any problems.
After the setup is finished, we place a rc.local script under /etc/ which connects to our deployment backend, and further tells the backend, that the installation is now finished.
The backend then removes the deployment network interface from the vm, and informs the customer, that the new vm is now set up.
Now my question is, how to deploy further ucs machines in the deployed customer network?
Is it also possible, to preseed the domain information’s and join user?
All the best,
René
Is it also possible, to preseed the domain information’s and join user?
In the past this was possible using some profile variables; see old Extended installation documentation
. But reading the current code of setup-join.sh shows that the code to pass the account and its credentials was removed some years ago.
I’d recommend to run the installation with auto_join disabled and then doing an univention-join -dcaccount Administrator -dcpwd <(printf '%s' 'very-secret-password') afterwards.
Hello,
okay, i will try this.
Just to be sure… if i want to setup and join a Slave Server, i run the installer with univention-system-setup-boot uss/server/role string domaincontroller_slave in the preseed file and uss/start/join set to false.
With an post script i then call univention-join -dcaccount Administrator -dcpwd <(printf '%s' 'very-secret-password' after the first reboot in the fresh installed system?
Yes, that should work: I remember doing it like this in the past, but have not tested it currently. Might me that you need to write the credentials to a file instead of using the <(printf…)-trick.
Another option would be to use our KVM images in Appliance-Mode: It’s a default setup where the Debian-Installer part has already been executed and the VM is suspended when next Univention System Setup (USS) starts. We use that image all the time for our nightly test runs as it saves some time. Basically you ssh in as user root with a default password, place the profile at /var/cache/univention-system-setup/profile and execute /usr/lib/univention-system-setup/scripts/setup-join.sh.
We also had cloud-init support, but that is currently broken,
Wonderful, works without any problems, thanks for the hint.
And here’s the next question:
How should we request core licenses?
We need that, that we can install complete setups from scratch including apps which require a license.
The customer has to buy a license afterwards from us (when everything is set up)
Where do we get an account at the licensing server? https://license.univention.de/shop/order/
Edit:
2nd question.
the trick with <(printf) seems to work for univention-app install to …
But even, it doesn’t work how it should.
For example it i try to install kopano core, the installer roles back after a while.
The breakpoint is the question for the password of root@dc.example.com for master packages installation.
is there a way, to predefine that password?
Contact vertrieb@univention.de
Have a look at utils.sh. Maybe you need to invoke univention-app install --noninteractive --only-master-packages "$app" on the master directly (I’m not an univention-app expert, maybe @dwiesent knows more details).
The answer to this can be found in the help text of univention-app itself:
$ univention-app install -h
usage: univention-app install [-h] [--noninteractive] [--username USERNAME]
[--pwdfile PWDFILE]
[--set KEY=VALUE [KEY=VALUE ...]] [--dry-run]
[--do-not-revert] [--only-master-packages]
[--do-not-install-master-packages-remotely]
[--do-not-pull-image]
app
Install an app
positional arguments:
app The ID of the App
optional arguments:
-h, --help show this help message and exit
--noninteractive Do not prompt for anything, just agree or skip
--username USERNAME The username used for registering the app. Default:
Administrator
--pwdfile PWDFILE Filename containing the password for registering the
app. See --username
--set KEY=VALUE [KEY=VALUE ...]
Sets the configuration variable. Example: --set
some/variable=value some/other/variable="value 2"
--dry-run Perform only a dry-run. App state is not touched
--do-not-revert Do not revert the installation when it fails. May
leave the system in an undesired state
--only-master-packages
Install only master packages
--do-not-install-master-packages-remotely
Do not install master packages on DC master and DC
backup systems
--do-not-pull-image Do not pull the image of a Docker App. Instead, the
image is assumed to be already in place
PS: giving GitHub - univention/schulangebot: https://help.univention.com/t/schulangebot-powered-by-ucs-school-hosted-by-hostern/14593 a closer look could be beneficial in your situation as well. while it has a focus on school deployments it uses a lot of the building blocks you need for your automated deployment as well.