[X2Go-Dev] Bug#1458: Bug#1458: Bug#1458: unattended Debian installations (using preseed) fail when x2gobroker-ssh is involved

[Stefan Baur]

Uli,

let me make this clear, in case you missed the "severity: important" tag
I gave this bug:

Currently, all automated Debian installs for x2gobroker-ssh are failing
due to this faulty piece of code.

Even our own demo install scripts we have in the Wiki, for the newbies
that want to try out X2GoBroker without having to figure out how to
configure this hairy beast manually, are broken.

This is NOT GOOD.

At the same time, "when in doubt, dike it out" is not a feasible
approach, as this code has been put there for a reason - and we can
assume it was added after things broke while testing a manual install.

So if we remove it, we're likely to get another bug report tagged
"severity: important", just coming from the other direction, begging us
to add this code again.

That is why our only option right now is to deploy this patch into
stable ASAP, to make the code do what it is supposed to do - flush the
cache IF nscd is RUNNING, and ONLY THEN.

No one is claiming that this is a magic cure-all for every problem there
may be with nscd or sssd caching.

But it WILL fix an actual issue we have RIGHT NOW and which is blocking
users from deploying x2gobroker-ssh in an automated way.  AND it will
NOT make things WORSE for anyone else.

After the release, we can re-open this bug and downgrade its severity as
a reminder that this caching issue should be investigated further.
But we won't be under pressure to get something working again that
worked before like we are right now.

-Stefan

Am 17.04.20 um 20:02 schrieb Ulrich Sibiller:
> On Fri, Apr 17, 2020 at 4:50 PM Stefan Baur <X2Go-ML-1 at 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
> 


-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243