Univention Bugzilla – Bug 33839
provide possibility to update system in Appliance Mode
Last modified: 2014-11-26 06:56:02 CET
Steps like in #33582. Installed DC Master ((81) [UCS: 3.2-0 amd64 - generic] via ucs-kt-get ) in Appliance Mode and run updates. Joining during System Setup of Member-Server fails. /var/log/univention/join.log: Configure 35univention-management-console-module-appcenter.inst Fri Jan 3 14:03:22 CET 2014 [...] Object exists: cn=ldapschema,cn=univention,dc=host,dc=com ERROR: Registered package version 3.0.50-16.229.201312021426 is newer, refusing registration. Workaround: "Ungejoint Fortfahren" -> After restart connect to UMC -> Update packages in "Modul Software-Aktualisierung" -> Restart -> In Modul "Domänenbeitritt" execute "Alle ausstehenden Join-Skripte ausführen" Idea: The possibility to choose "Update system after installation" during Appliance Mode just like in Installation overview (http://docs.univention.de/manual-3.2.html#installation:overview) during Appliance Mode
(In reply to Michel Smidt from comment #0) > Steps like in #33582. > Installed DC Master ((81) [UCS: 3.2-0 amd64 - generic] via ucs-kt-get > ) in Appliance Mode and run updates. > Joining during System Setup of Member-Server fails. That should always be possible and is the real problem. We will fix it with Bug #33582. I think an additional update button makes the interface more complicated.
(In reply to Stefan Gohmann from comment #1) > I think an additional update button makes the interface more complicated. The idea here was to provide the same functionality like durin installation, where the system installs available updates automatically. I think this should also be possible in the appliance mode, i.e. in EC2 or Vmware images.
(In reply to Ingo Steuwer from comment #2) > (In reply to Stefan Gohmann from comment #1) > > I think an additional update button makes the interface more complicated. > > The idea here was to provide the same functionality like durin installation, > where the system installs available updates automatically. I think this > should also be possible in the appliance mode, i.e. in EC2 or Vmware images. OK, that is like Bug #25592. But that would not solve the original problem because the upgrade will be done after the setup was done. Upgrade the system before the installation would highly increase the test effort.
(In reply to Stefan Gohmann from comment #3) > (In reply to Ingo Steuwer from comment #2) > > (In reply to Stefan Gohmann from comment #1) > > > I think an additional update button makes the interface more complicated. > > > > The idea here was to provide the same functionality like durin installation, > > where the system installs available updates automatically. I think this > > should also be possible in the appliance mode, i.e. in EC2 or Vmware images. > > OK, that is like Bug #25592. > > But that would not solve the original problem because the upgrade will be > done after the setup was done. Upgrade the system before the installation > would highly increase the test effort. That's true; feel free to close this as duplicate of Bug #25592 or vice versa.
*** Bug 25592 has been marked as a duplicate of this bug. ***
I think we should update by default. It should be possible to disable the update by setting a profile variable.
The UCS 3.2 script is here: ucs-3.2-3/base/univention-installer/scripts/90_upgrade.sh
Added a checkbox in univention-system-setup 8.0.35-2.661.201409021041 Does univention-upgrade. As this command does not give useful output, I just write "This might take a while depending on the number of pending updates." I would have to somehow fork and tail -f /var/log/univention/updater.log which is too much of a hassle at the moment.
The text "Alle für UCS 4.0 verfügbaren Aktualisierungen nach der Einrichtung installieren" sound a little bit complicated. The old installer used "System nach der Installation aktualisieren". Maybe you could use the old variant or something similar.
Fixed wording
OK: Wording ~OK~: progress state is currently also buggy (See also Bug #35715) REOPEN: The univention-ssh calls can be combined into 1 call. REOPEN: If univention-ssh fails univention-upgrade is called with --updateto=-. (REOPEN: no error log output, e.g. stderr of univention-ssh) REOPEN: exit code is always 0 even if update fails. OK: unjoined slave systems will only update to patchlevel 0 (probably due to problems in the past). ~OK/REOPEN: The variable content must be "True", should we allow 'yes', 'on' etc. like UCR? or lowercase? (When writing profile by hand this should behave like other vars).
The upgrade should be started after the system has been joined. On a DC master it looks like the system was upgraded before the join scripts were executed.
(In reply to Florian Best from comment #11) > REOPEN: The univention-ssh calls can be combined into 1 call. Done > REOPEN: If univention-ssh fails univention-upgrade is called with > --updateto=-. Done > (REOPEN: no error log output, e.g. stderr of univention-ssh) Done > REOPEN: exit code is always 0 even if update fails. Not done. 1) It seems the exit code is not evaluated => Not important. 2) If it is evaluated in some point in the future (run-parts --exit-on-failure) I would recommend to not return 1 either. 3) If univention-upgrade fails there is little we can do about it. Re-running will probably result in the very same error. The user will have to use the Software Update module or (more likely) will have to use the command line to fix things. Feel free to REOPEN if you do not agree. > ~OK/REOPEN: The variable content must be "True", should we allow 'yes', 'on' > etc. like UCR? or lowercase? (When writing profile by hand this should > behave like other vars). Done
Move all unfinished MS1 and MS2 bugs to RC.
(In reply to Dirk Wiesenthal from comment #13) > (In reply to Florian Best from comment #11) > > REOPEN: The univention-ssh calls can be combined into 1 call. > > Done OK > > REOPEN: If univention-ssh fails univention-upgrade is called with > > --updateto=-. > > Done OK > > (REOPEN: no error log output, e.g. stderr of univention-ssh) > > Done REOPEN: ############################################################ === 90_postjoin/20upgrade (2014-10-03 13:16:01) === __NAME__:90_postjoin/20upgrade Aktualisiere das System __MSG__:Abhängig von der Anzahl der austehenden Updates, kann dies einige Zeit dauern. WARNING: Getting version from DC Master failed! Running normal upgrade: univention-upgrade --noninteractive --updateto 4.0-0 Starting univention-upgrade. Current UCS version is 4.0-0 errata0 ############################################################# → still no log output, maybe 2>&1 instead of 2>>/var/log/univention/setup.log? → please add full path to univention-ssh call (/usr/sbin) > > REOPEN: exit code is always 0 even if update fails. > > Not done. > 1) It seems the exit code is not evaluated => Not important. > 2) If it is evaluated in some point in the future (run-parts > --exit-on-failure) I would recommend to not return 1 either. > 3) If univention-upgrade fails there is little we can do about it. > Re-running will probably result in the very same error. The user will have > to use the Software Update module or (more likely) will have to use the > command line to fix things. > Feel free to REOPEN if you do not agree. OK > > ~OK/REOPEN: The variable content must be "True", should we allow 'yes', 'on' > > etc. like UCR? or lowercase? (When writing profile by hand this should > > behave like other vars). > > Done OK
Could not reproduce the PATH problem. Added absolute paths anyway. stderr output changed.
DC Master: OK A slave always fails: __NAME__:90_postjoin/20upgrade Aktualisiere das System __MSG__:Abhängig von der Anzahl der austehenden Updates, kann dies einige Zeit dauern. E: unknown action "repository/online=yes", see --help WARNING: Getting version from DC Master failed! Running normal upgrade: univention-upgrade --noninteractive --updateto 4.0-0
root@slave6:~# version=$(/usr/sbin/univention-ssh /etc/machine.secret $hostname\$@$ldap_server_name "echo $(/usr/sbin/ucr get version/version)-$(/usr/sbin/ucr get version/patchlevel)" 2>&1) root@slave6:~# echo $? 0 root@slave6:~# echo "$version" Warning: Permanently added 'slave6.ucs.dev,10.200.27.6' (RSA) to the list of known hosts. Could not chdir to home directory /dev/null: Not a directory 4.0-0 → I reverted the 2>&1 to 2>>/var/log/univention/setup.log
Well, still this error remains: === 90_postjoin/20upgrade (2014-11-04 12:45:49) === __NAME__:90_postjoin/20upgrade Aktualisiere das System __MSG__:Abhängig von der Anzahl der austehenden Updates, kann dies einige Zeit dauern. E: unknown action "repository/online=yes", see --help WARNING: Getting version from DC Master failed! Running normal upgrade: univention-upgrade --noninteractive --updateto 4.0-0 Starting univention-upgrade. Current UCS version is 4.0-0 errata0
I fixed a typo in the script.
OK: typo OK: the server tries now to connect to ldap/master instead of ldap/server/name.
UCS 4.0-0 has been released: http://docs.univention.de/release-notes-4.0-0-en.html http://docs.univention.de/release-notes-4.0-0-de.html If this error occurs again, please use "Clone This Bug".