Rescue and recover UCS server

UCS - Univention Corporate Server
#1

Hello,

I have made some performance and reliability tests for different scenarios on our servers. I have noticed that UCR commands are not available when using a 3rd party Linux distro to rescue and recover an UCS installation by mounting the file system and LVM partitions. In the particular case the dedicated UCS server is hosted in a data center without physical access. After installation, the IP address of the server has been changed to an incorrect one via UMC, and as the resulted problem the server is not reachable through Internet and the user depends on the distros the hosting service provider offers to recover the UCS server.

Using Debian, I mounted the LVM partitions and ran the following commands in the univention-backup directory as the instructions on the Univention wiki page Single Server Backup and Restore under title Restoring the configuration instructed:

tar zxvf ucr-backup_20160319.tgz sed -e "s/: /='/g;s/$/'/;1,2d;s/^/ucr set /" -i base.conf sed -e "s/: /='/g;s/$/'/;1,2d;s/^/ucr set --force /" -i base-forced.conf /bin/bash base.conf /bin/bash base-forced.conf reboot

Unfortunately the server is still not reachable, so the UCR recover process failed or it wasn’t enough. I noticed the command /bin/bash base.conf gave “command not found” errors as it tries to run ucr and the system does not recognize the command:

base.conf: line X: ucr: command not found base.conf: line Y: ucr: command not found ... base.conf: line 620: ucr: command not found

My open questions are:
[ol][li]As the base.conf runs commands which the live distro OS does not understand, how to recover and restore the UCR variables?[/li]
[li] In addition to UCR, to which configuration variables the change of the IP address of a network device (e.g. eth0, br0) via UMC affects, if any?[/li]
[li]Is it enough to just recover the UCR variables which include the correct IP addresses, or is it required in the particular case to restore some other configuration variables too, such as LDAP and/or Samba related, as instructed in the linked Univention wiki page?[/li][/ol]

kind regards,
Jussi

#2

Or perhaps I should edit the file /etc/univention/base.conf directly? Testing it next…

#3

Received instructions from Juergen on the #univention IRC channel:

[quote]1) boot your rescue system
2) try to mount the non-booting UCS-system ==> mount /dev/sdXX /mnt
3) bind mount some important directories like /sys, /proc, /dev:
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
mount --bind /dev /mnt/dev
4) call chroot to switch into the UCS system: chroot /mnt
Now the filesystem is limited to the UCS system and all UCS commands should be available.
For comitting all UCR variables, you can simply call “ucr commit”. Afterwards all config files are recreated from UCR variables.
Of course you can additionally change everything you need.
If finished, type “exit” in your shell to leave the chroot.
Then umount /mnt/proc, umount /mnt/sys, umount /mnt/dev
umount /mnt
That’s only the rough idea on how it should work. YMMV[/quote]

Trying it now.

#4

[quote=“Jusle”]Received instructions from Juergen on the #univention IRC channel:

[quote]1) boot your rescue system
2) try to mount the non-booting UCS-system ==> mount /dev/sdXX /mnt
3) bind mount some important directories like /sys, /proc, /dev:
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
mount --bind /dev /mnt/dev
4) call chroot to switch into the UCS system: chroot /mnt
Now the filesystem is limited to the UCS system and all UCS commands should be available.
For comitting all UCR variables, you can simply call “ucr commit”. Afterwards all config files are recreated from UCR variables.
Of course you can additionally change everything you need.
If finished, type “exit” in your shell to leave the chroot.
Then umount /mnt/proc, umount /mnt/sys, umount /mnt/dev
umount /mnt
That’s only the rough idea on how it should work. YMMV[/quote]

Trying it now.[/quote]

This worked perfectly. :slight_smile:

Mastodon