Hi,
On 2019/05/29 18:01, Michael Orlitzky wrote:
On 5/29/19 5:50 AM, Jaco Kroon wrote:
This GLEP follows the best practice of leaving obsolete user/groups
accounts intact. This guarantees that no files with stale ownership are
left (e.g. on unmounted filesystems) and that the same UID/GID is not
reused for another user/group.
The type of checks for both this and certain updates contemplated above
are similar. And expensive (resources) as you rightly say. I would
provide the tools to perform these checks but in the ebuild I'd rather
the checks be done asap (pkg_pretend?). If we can fail there and
stating what the admin should do to rectify the issue that would be the
best solution in my personal opinion. Ie, from the package manager I'd
state how, but not actually action these changes.
My original goal here was to have "emerge -C <user>" actually uninstall
the user. That turns out to be highly unwise, because you need to audit
the system for things owned and used by said user, and to clean them all
up beforehand. That can take forever, and can't be automated.
Plan (b) was to do exactly as you asked: have the uninstall process bail
out, and tell you what to do. That's... also technically infeasible,
because we don't have a way to make an ebuild bail out of an uninstall.
This could change in the future with an EAPI/PMS update, but simply
isn't an option right now.
I think you misunderstood. My writing was poor on re-read.
My suggestion is to merely lock the user. And make sure that the admin
knows this. Even locking may need to be configurable but by default I
would lock.
Further, the tools should be provided outside of the ebuild (baselayout
perhaps) in order to enable the checks to be completed (ie, confirm no
files has the user as owner), and then report to the sysadmin how to use
these tools.
On merge: Perform the checks before any building starts
(pkg_pretend/pkg_setup, as per libreoffice example I just looked at).
Need to recheck again obviously just prior to actually making the
changes. Bail early in other words during install.
On unmerge: Lock user. Advise sysadmin on how to actually remove the
user (possibly put it in a database somewhere and check somewhere in
portage that these users are "linkgering", similar to retained libs that
gets held because of binaries actually still using it, but never
automatically removed, just checked if the sysadmin has). Can't (should
not) fail.
I hope that clarifies.
Kind Regards,
Jaco
