enterprise-ubuntu team mailing list archive

[dennis knorr <dennis.knorr@xxxxxxx>]

Hi,

Am 01.09.2017 um 20:36 schrieb Chris Crisafulli:
> I noticed I didn't reply all:
> 
> Bryan,
> 
> I think a good move would be to convert the mailing list to a
> 'lists.ubuntu.com <http://lists.ubuntu.com>", keeping the launchpad page
> where "Members" can still join and participate. I would gladly help with
> moderating the mailing list if needed.

i would prefer this, too. There ist still stuff to do, until Ubuntu and
Linux in general is really "at home" in an enterprise environment from
my point of view. It got a lot better, but far from perfect.

I can help with the moderation, too, if it is needed.

Since Ove postet his points in another mail, i can provide my
experiences, too.

* from what i see sometimes and hear from other people, integration of
ubuntu clients with SSSD in an AD Environment CAN lead to performance
issues and it is often hard to debug what the cause is. A tool for
better analysis would be nice

* per-user-application-configuration
In our company we preconfigure on login application configuration, so
these are ready-to-use. And we start also other stuff as well (like for
example mounting shares). There are two points:
** in the mainstream desktop environments there's no functionality to
start loginscripts (with or without user credentials). PAM is too early
and the DEs do not have a function or framework supporting configuring
arbitrary programs.
This per-user-loginscripts could configure thunderbird, libreoffice,
dolphin,  or other programs. in our systems there is a
logout-script-possibility as well. SKEL is not good enough either, since
that is a rather static approach. we go with upstream-provided standard
configs and adapt these configs as we see fit.
** many programs and their developers do not see the need or value for
their program in an enterprise setting. because of that, there's
sometimes no coherent or simple way to set that config. Some desktop
programs mix state and configuration in the same file. Other make it
unneccesary difficult to automatically decide if changed configuration
is still okay. I know that this is not totally solvable, but some
configurations (like prefs.js) can be preset and later tested if there's
some configuration which must be changed or can be let be.

that would be my suggestions.
we will try to open up our implementation next year, but this depends on
the powers that be.

yours,
dennis