Bug#1050001: Unwinding directory aliasing [and 3 more messages]
On Sun, 27 Aug 2023 at 18:03, Sam Hartman <hartmans@debian.org> wrote:
>
>
> TL;DR: I think I understand one of Ian's points. I explain, but do not
> believe it is compelling as an argument to switch direction.
>
> >>>>> "Helmut" == Helmut Grohne <helmut@subdivi.de> writes:
> >> I think "package management" is the wrong term here. It's not
> >> just our tools and packages that are affected. All forms of
> >> operating system management are affected: anything that changes
> >> the software, and not just its configuration.
> >>
> >> Affected tooling includes not just our .debs, but also remote
> >> configuration management systems like Ansible, image construction
> >> (Dockerfiles), and 3rd-party software installation progrmas
> >> (including both 3rd-party .debs and 3rd-party script-based
> >> installation systems).
>
> Helmut> I don't follow the reasoning. Much of the tasks you'd carry
> Helmut> out with (wlog) ansible - even when updating files - will
> Helmut> continue to work in the aliasing layout. The reason that
> Helmut> dpkg is more affected is that it has an inventory of files
> Helmut> and reasons about their ownership in terms of
> Helmut> packages. That's not how any kind of configuration
> Helmut> management operates. If you just "make install" something,
> Helmut> chances are that it'll just work with an aliasing layout
> Helmut> even when installing with --prefix=/. I continue to argue
> Helmut> that the problems we are seeing are quite specific to dpkg
> Helmut> in large parts.
>
> I spent some time with Ian's paragraph you quote above trying to
> understand it, and I think I got somewhere.
> I considered replying yesterday but decided against, because I think we
> are already seeing these effects, and have been seeing them long enough
> that we would have a good feel for how serious the problems are.
>
> I do think that configuration management does have enough of an
> inventory of files and reasoning about structure that some of these
> problems could arise. I agree that configuration management does not
> typically reason in terms of packages.
>
> But mechanisms like
>
> * ADD/COPY in Containerfile
>
> * The rsync module in ansible
> * The file module in Ansible
>
> * various inventories related to modification detection in
> configuration management do reason about the filesystem.
>
> I don't know what would happen if I did
>
> hosts: lots
> remote_user: root
> name: Does this shoot me in the foot
> tasks:
> - rsync: src=install_root dest=/
>
> where install_root has a bin directory containing a couple of scripts.
> I don't know if rsync will replace a symlink with a directory, or will
> just write through the symlink in that situation.
> If rsync happens to write through the symlink, there's probably some
> other tool somewhere else that replaces the symlink.
> And when an admin does that, they get an unbootable system, and fix
> their playbook/whatever.
>
> Similarly, I bet someone somewhere has integrity management scripts that
> want to look at what pam modules are installed under /lib/security, and
> depending on how it worked,
> they had to adjust the config when that moved to
> /lib/security/x86_64-linux-gnu and then again some of them had to adjust
> when /lib became a symlink. And they were probably frustrated during
> the time when new installs had /lib as a symlink and upgrades did not.
>
> Similarly, I bet you can run into trouble with apparmor profiles if you
> try to profile /bin/python rather than /usr/bin/python or similar.
>
> I bet people who had custom selinux policies had to adjust their
> labeling rules and again some of them probably found the mixed state
> where upgraded systems behaved differently than installed systems
> frustrating.
AppArmor, SELinux, Ansible, Chef, Puppet and whatnot all exist and are
used on all distributions. Such distributions have install bases
vastly higher in numbers than Debian, and have adopted the usrmerged
layout a decade ago or so. Is there any evidence of AppArmor, SELinux,
Ansible, Chef, Puppet and whatnot breaking catastrophically as a
consequence?
Speculating about what might or might not happen with future events is
all good and well, but this is in the past. These things either all
broke and suddenly became unusable on Arch, Fedora, CentOS, RHEL,
Alma, Rocky, SUSE, Mandriva, Yocto, Ubuntu and so on, or they did not.
If there's no evidence they did, then it's not even worth mentioning
or discussing, it's all moot.
> I seem to recall having to make some minor adjustments at my day job
> related to usrmerge back in the buster/bullseye time frame.
> I don't remember what they were.
This is much more likely to be closer to reality. As with any change
or upgrade, there's some minor adjustment here or there, that most
won't even remember about after a while given how trivial it is. I
certainly do not remember all the changes I've had to do to software I
maintain when switching between major compiler versions, or library
versions, or debhelper compat leves, and so on and so forth. This
isn't any different.
Reply to: