[opensuse-buildservice] ubuntu 11.10 chroot install on obs 2.1 fails
Hallo everyone, we are unable to build packages for ubuntu 11.10 oneiric on our installation of obs. During the preparation of the build chroot, the install fails with the following error message: <snip> installing base-files rmdir: failed to remove `/var/run': Directory not empty dpkg: error processing base-files (--install): subprocess installed post-installation script returned error exit status 1 Processing triggers for install-info ... Errors were encountered while processing: base-files exit ... At this point of the installation, the postinstall script of base-files tries to replace the /var/run directory by a symlink to /run, while it still contains an empty file /var/run/init.upgraded. This file has been placed there by libc6 (source package eglibc). The reason for this is given in the changelog: eglibc (2.12.1-0ubuntu12) natty; urgency=low * do not run 'telinit u' on upgrade, as this will break upstart. touch /var/run/init.upgraded instead, which will force a re-exec just before remounting root read-only. LP: #672177, LP: #694772. On build.opensuse.org there is no problem with ubuntu 11.10 builds. However the site uses a kvm-based setup while our installation uses chroot-based workers. Also I suspect the b-o-o installation to use a newer version of obs. On our installation we use the latest version for opensuse 11.4. Here is a list of our installed obs versions: obs-server-2.1.11-4.6.x86_64 obs-service-download_files-0.2-26.1.noarch obs-signd-2.1.2-1.1.x86_64 obs-server-debuginfo-1.0.0-4.4.x86_64 obs-service-tar_scm-0.2.1-18.1.noarch obs-api-2.1.11-4.6.x86_64 obs-common-2.1.0-2.1.x86_64 obs-service-set_version-0.1-5.1.noarch obs-worker-2.1.11-4.6.noarch obs-server-debugsource-1.0.0-4.4.x86_64 obs-service-verify_file-0.1-4.1.noarch obs-utils-2.1.11-4.6.x86_64 obs-service-recompress-0.1-8.1.noarch obs-productconverter-2.1.11-4.6.x86_64 I'm unsure what causes this problem and how I could try to fix it. Either the postinstall configure script of base-files should run before libc6 gets installed or the file in /var/run should be removed at some other point during the bootstrapping process after it has been created by libc6. Could this be related to the version of the init_buildsystem script in /usr/lib/obs/server/build? Could I try a newer version here or will this break things? I'd be grateful for any hint on how to debug this problem. Thanks and bests, Lars -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Tue, Nov 29, 2011 at 12:54 AM, Lars Volker <lv@lekv.de> wrote:
Could this be related to the version of the init_buildsystem script in /usr/lib/obs/server/build? Could I try a newer version here or will this break things?
I personally doubt this is the cause of the problem because I have a very current installation (2.2.96) of OBS here and see the very same problem. Didn't have the time yet to dig deeper into that. Thus I would be grateful for a hint as well. Robert -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
https://github.com/openSUSE/open-build-service/pull/9 The default LDAP authentication lets users to access OBS as long as the user has LDAP username/password. Most of enterprises don't want this. We want only part of users from LDAP to access OBS. In "src/api/config/environments/production.rb", it suggests to use "LDAP_USER_FILTER" to achieve this goal (let part of users from LDAP to access OBS only). However, in a large enterprise, LDAP server is normally maintained by IT people, but OBS server is normally maintained by CM group. It's always inconvenient to ask IT to add/remove people from LDAP membership to control access write. As an OBS admin, therefore we don't want to use "LDAP_USER_FILTER". Hence, while we still want to use LDAP authentication, we need to have a new mechanism to block users from accessing OBS even if he has LDAP username/password, and this new mechanism can be controlled by OBS admin. Instead of taking "black list" approach (specifying who shouldn't access OBS), we take "white list" approach (only user who has account in OBS database can access), which is similar to the authentication when LDAP_MODE is :off. The difference would be when LDAP_MODE is :off, end users need to keep 2 different set of password (one for OBS and one for LDAP) because IT normally requires end user to change LDAP password every 90 days. Work flow: Before query LDAP server for username/password, the program would first search username in OBS database. If the username doesn't exist in OBS database, the program would block the user. Only if the username exists in OBS database, the program continues the authentication to query LDAP server for username/password. Rick
participants (3)
-
Lars Volker
-
Rick Liu
-
Robert Schiele