On Fri, Apr 17, 2020 at 4:50 PM Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
Am 17.04.20 um 16:24 schrieb Ulrich Sibiller:
I think it is a totally wrong approach to fiddle with nscd. Creating a group using system tools should take of that already. If not it's a bug, I'd say.
LOL. nscd caching the wrong(TM) things at the wrong(TM) time is an issue that's probably as old as Unix (or at least nscd) itself. If you take a look at the postinst script in question, you will see that it does, in fact, use the system tools to add the group. Still, it is neccesary to flush the cache or things have a tendency to go wrong.
Well, if you go that route there are more things to take into account:
- is nscd properly configured to cache groups at all?
- is there a distro-tool available for configuring/flushing/handling nscd
- are the multiple versions of nscd around? Which one to take?
- probably more
- what happens if a newer version of nscd is around that needs to be called otherwise
- waht happens if the nscd binary is something completely different and just happens to have the same name?
- same for ssd
- same for ANY other caching mechanism you might not even know
All these things tend to break sooner or later. That's the reason why you should not do this in an installation script but report a bug instead. This must be fixed at distro level.
Are you aware of any installation postscripts other than x2go that handle nscd problems?
Besides: what about sssd that can also cache groups?
That's a more interesting question, and we might have to add a check for it as well. But as of right now, sssd being installed in combination with x2gobroker-ssh during a preseeded installation won't break anything.
I have seen the weirdest problems with sssd (and nscd as well). An I still have one bug open at redhat for more than year which redhat has not fixed yet...
While you can work around such problems in local (site) scripts or as local administrator you should NOT include such workaround in release packages.
Uli