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
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
