Authentication services in Ubuntu

[Bolesław Tokarski]

Hello,

On 06/04/2013 10:50 AM, Robie Basak wrote:
>> I'd say to drop the changes made against Debian. Aside for the
>> separation that Debian does with regards to ldap.conf files (for nss
>> and pam, it doesn't seem right to me), I'd say drop the diffs.
> I also got the impression that they weren't maintained well. I'd also
> like to see them resynchronised with Debian, with any extraneous delta
> dropped. Though I'm reluctant to agree straight away, without first
> understanding the circumstances around why they were added in the first
> place.

I believe the reason for adding ldap-auth-config was similar to what 
Timo suggests to use for directory join here. The idea was to have a 
default tool that configures LDAP during installation phase.

> It's also worth noting that we generally don't want to make big changes
> on an LTS release. So any invasive changes that might have some level of
> upgrade incompatibility, or a complex upgrade path that needs testing
> carefully, should really go into a non-LTS release. It's getting late to
> do this in Saucy. So this may have to wait until U, subject to what
> others say.

I don't care about the LDAP part that much. It can enter Z, though I'd 
prefer to mark this on my private buglist as done. However, for the 
domain join, realmd or whatever, I guess we have real benefits of having 
it in the next LTS, even if that means doing a prototype for saucy. This 
does not introduce incompatibility as this has not been in use yet.

Though, for some bizarre reasons, there might be people that want the 
config from ldap-auth-config automatically migrated to SSSD. That would 
bring us a lot of sweat and I wouldn't like to do that.

> Nowadays, would I be right in thinking that enterprises manage their
> config files at a higher level? How many deployments are actually using
> debconf to configure LDAP across their machines?

My company would be a prime example and I could give you 2 other 
enterprises that do this at a 'higher level'. However, I would not 
dismiss the SMBs that use the installation dialogs to configure the 
system. It's easy, intuitive and you can hope it does things faster (or 
at least provides a good start) than you would by digging deep inside 
the READMEs, manuals and example configs. Of course that assumes that 
the debconf questions produces anything useful.

It's good not to get in the way of automation tools by providing means 
to dismiss the questions, though. I saw a couple of packages doing it 
right ("Do you want debconf to manage your smb.conf?"), I saw some that 
were too difficult (I still can't figure out what to put in a seed file 
to dismiss the pam-auth-update questions) and I saw some that were so 
badly written that the only thing you can do is to repackage them 
without debconf.

Cheers,
Ballock