Custom Query (1145 matches)

Reported by geofft, 13 years ago.

dh_installinit adds code to the postinst to run /etc/init.d/debathena-dotfiles start. This seems like a terrible idea.

Reported by geofft, 13 years ago.

GDM 2 is slowly dying. More importantly, there appears to be  a consensus on debian-devel to make Policy disallow circular dependencies for the benefit of dependency resolvers. This won't happen any time soon (mostly because perl/perl-modules needs to be sorted out) but it looks fairly inevitable, and we'd like resolvers with this assumption not to break when encountering our metapackages.

I believe that our only circular dependencies are in -branding packages, based on the following aptitude query:

geofft@leveret:~$ aptitude search '~Odebathena ?for x: ~D~D?=x'
p   debathena-cluster               - Athena cluster configuration for Debian   
p   debathena-cluster-branding      - Displays which Debathena metapackage level
p   debathena-login-graphical       - Athena graphical login configuration      
p   debathena-login-graphical-brand - Displays which Debathena metapackage level
p   debathena-workstation           - Athena managed workstation configuration  
p   debathena-workstation-branding  - Displays which Debathena metapackage level

Reported by geofft, 13 years ago.

D-Bus has a facility for running services when you send a message to a well-known name but no service is bound to that well-known name (these services are listed in /usr/share/dbus-1/system-services). The system D-Bus daemon runs outside the chroot, so naturally services it activates will also run outside the chroot.

This interacts poorly in a couple of cases with privileged-inside-the-chroot programs making requests to daemons outside the chroot over D-Bus. One notable case is aptdaemon, used by Ubuntu Software Center -- if you install something via that GUI (as opposed to any other GUI, or the command line), then it will get installed in the environment of aptdaemon, namely outside the chroot.

We're probably seeing this in production, given that we've run into a couple of machines with Skype mysteriously installed outside the chroot, and Skype from the partners repository is well-advertised in Ubuntu Software Center.

Addressing #462 would fix this solidly, but would also be fairly high-impact. A much smaller-impact fix is to hook the servicehelper (/usr/lib/dbus-1.0/dbus-daemon-launch-helper, as mentioned in /etc/dbus-1/system.conf), which elevates privileges from the messagebus user to root when running a service. Since we want D-Bus activation to work at boot time, we should have a wrapper that detects if a login chroot exists, and runs the original servicehelper inside the chroot if so, and otherwise just runs the original servicehelper.