enterprise-ubuntu team mailing list archive

[Bryan Quigley <bryan.quigley@xxxxxxxxxxxxx>]

Moving to lists.ubuntu.com requires us the list to be worth the effort
to move over, it's really designed for higher traffic lists, which I
don't think we'd qualify for.  Is there a benefit of being on
lists.ubuntu.com that I'm missing?

I think just switching the team to Delegated should help us prevent
most drive-by spam - and maybe add member expiration so we can see if
the list is still found to be useful.

The conversations here have been quite useful in the past and I'd be
willing to put some time in to try to make them happen again.

>* per-user-application-configuration
Very interesting and I'd like to discuss further - at the same time I
wonder how much of this discussion we should really take to the
ubuntu-desktop list so there is more awareness that these issues
exist.

Thanks all!
Bryan

On Tue, Oct 31, 2017 at 3:57 PM, dennis knorr <dennis.knorr@xxxxxxx> wrote:
> 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
>
> --
> Mailing list: https://launchpad.net/~enterprise-ubuntu
> Post to     : enterprise-ubuntu@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~enterprise-ubuntu
> More help   : https://help.launchpad.net/ListHelp