[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #34115 [Internal Services/Tor Sysadmin Team]: review the impact of usrmerge
#34115: review the impact of usrmerge
-------------------------------------------------+-------------------------
Reporter: anarcat | Owner: anarcat
Type: defect | Status:
| assigned
Priority: High | Milestone:
Component: Internal Services/Tor Sysadmin Team | Version:
Severity: Major | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Old description:
> Debian buster shipped with a "merged `/usr`", which means that `/bin`,
> `/lib` and `/sbin` are now symlinks to their counterparts in `/usr`.
> There are concerns that this behavior is buggy and triggers problems in
> all sorts of places. In particular, the `dpkg` maintainers are quite
> unhappy about the change and do not support it as a configuration:
>
> https://wiki.debian.org/Teams/Dpkg/MergedUsr
>
> ... which is disturbing, considering the `dpkg` is such a core component
> of a Debian system.
>
> That wiki page provides a hackish script to "migrate away" from usrmerge
> but no one, as far as I know, has done that in production. It definitely
> looks nasty.
>
> We should consider whether:
>
> 1. [ ] this is a real problem
> 2. [x] which machines have usrmerge
> 3. [ ] whether new machines should have it
> 4. [ ] whether we need to fix old machines
New description:
Debian buster shipped with a "merged `/usr`", which means that `/bin`,
`/lib` and `/sbin` are now symlinks to their counterparts in `/usr`. There
are concerns that this behavior is buggy and triggers problems in all
sorts of places. In particular, the `dpkg` maintainers are quite unhappy
about the change and do not support it as a configuration:
https://wiki.debian.org/Teams/Dpkg/MergedUsr
... which is disturbing, considering the `dpkg` is such a core component
of a Debian system.
That wiki page provides a hackish script to "migrate away" from usrmerge
but no one, as far as I know, has done that in production. It definitely
looks nasty.
We should consider :
* [ ] whether this is a real problem (probably?)
* [x] which machines have usrmerge (20 machines or 27%, detailed below)
* [x] whether new machines should have it (probably not? not having
usrmerge is *not* a problem, and having it has risks, so let's not risk
it?)
* [ ] whether we need to fix old machines
There are two ways of fixing the installers:
* pass `--no-merged-usr` to deboostrap
* use `mmdebstrap`
The latter has the advantage of being faster, at the cost of being
possibly less reliable and compatible.
Next steps:
1. [ ] fix cloud installer
2. [ ] fix robot installer
3. [ ] fix ganeti installer - reported as [https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=959745 bug 959745]
--
Comment (by anarcat):
i have filed [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959745 bug
959745] against ganeti-instance-debootstrap to see if that can be
customized. it seems we should be able to override the `debootstrap` call
by defining a function in the variants config file, which remains to be
tested.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/34115#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs