-
-
Notifications
You must be signed in to change notification settings - Fork 29
Description
ermo
or, well, maybe ... could we have two userdbs?
one that's "active" and one that is, well, "not active"?
with the not active one containing the IDs that got shuffled out of transactions
enabling us to re-activate them with the correct ids?
Ikey Doherty
I think a central tracker will be fine
So that our packages just work
So they only need defining in sysusers
And reserving in a document somewhere
Consulted for packaging policy
ermo
(could then also consult that inactive db for stray files in a post-trigger?)
i.e. stuff in /var created by now inactive users
I realise that such a trigger is more of a "nice to have" than a "must have" or even "should have"
but it'd still be kind of cool
Ikey Doherty
I view it as essential for moving forwards
Proper stateless
ermo
well, imagine that you have a grace period for "orphaned" files in e.g. /var
such that you have a timer that runs periodically and checks var for files with unmatched uids/gids in the currently active transaction
then matches them against the "known inactive uids/gids" and offers to clean them up
after said grace period
(say, 30 days by default?)
Ikey Doherty
Could be part of state prune
ermo
I know, it's a bit "out there" and possibly beyond the scope of what we're trying to do
but it'd be a nice feature I think?
Ikey Doherty
Sure, self maintaining system
So, gnome by Tuesday? XD