Progress update, and decision to use LDAP

[Stuart Herbert]

Hi everyone,

Work on the Seeds has gone quite well in the last couple of weeks.  

• We now have the beginnings of a desktop seed - far from perfect, but certainly good enough to now be my main Linux desktop.
  
• I've added a new utility (installed by the base-system package) called 'update-seed'.  It automatically handles any /etc/portage/* updates before trying to upgrade the installed Seed.  Probably needs refinement, but the basics is working well.

I keep running into upstream quality issues ... stable packages that are badly broken (Sun JDK 1.6 being the worst of those), and packages with circular dependencies (OpenLDAP and Cyrus-SASL, for example), to add to the mutual blockers (bash and portage) that we've already seen.  We're seeing these issues because we're building from scratch; we're doing completely clean installs.  I'm willing to bet that most of the upstream devs are not able to do this, and that's why these issues are escaping through.

Speaking of OpenLDAP ... I've decided to make Seed Linux run off LDAP out of the box.  The plan is to start with moving /etc/passwd et al into LDAP first, and then to revisit the other packages we install to see what we can do.  The vision is for stand-alone Seed Linux boxes to be able to join larger grouped setups through turning their local LDAP installs into slaves replicating from a central master.  If we can get there, and if we can make it easy, then that is a major benefit folks will get from choosing Seed Linux over the competition.  It's going to be interesting to see how close we can get to that in time :)

I've applied to IANA for a Seed Linux OID, so that we can create any custom schemas that we'll need in future.  I'm currently looking at how to get Seed Linux using LDAP out of the box, but still as a standalone system for now.  I've decided to go with OpenLDAP for now.  I'm open to using alternatives if anyone can prove there's a good reason to switch :)

As soon as the basic LDAP support is done, I'll get the LAMP Server seed (which is now broken) working with the new seed-system packages.  And then we'll take it from there.  I hope we'll be able to package something up and call it a downloadable release around that point, but we'll see.

Best regards,

Stu
--
Stuart Herbert

e: stu...@stuartherbert.com
t: +44 7966 284577
w: http://www.stuartherbert.com/
b: http://blog.stuartherbert.com/

[kyron]

On Jun 18, 3:30 pm, "Stuart Herbert" <stu...@stuartherbert.com> wrote:
> Hi everyone,
> Work on the Seeds has gone quite well in the last couple of weeks.
>

>    - We now have the beginnings of a desktop seed - far from perfect, but

>    certainly good enough to now be my main Linux desktop.

>    - I've added a new utility (installed by the base-system package) called

Doing some parallel work here and I think we might want to join our
efforts. I sent this to Sam Briesemeister regarding the "
Configuration Tools." thread which is unfortunately locked down now
and didn't notice that it was originally only sent to him.
http://groups.google.com/group/seed-linux-dev/browse_thread/thread/73cb8a4fef940903#

So here is some copy paste of our exchange (the LDAP part):

Here is what I have made while working on a Gentoo Clustering LiveCD
(which I hope to change into an
actual SEED):

http://wiki.neuralbs.com/~kyron/soc2008/

The two files of interest are cluster_ldap_skel.conf and ldap-
setup.sh, all other files are auto-generated by calling

./ldap-setup.sh cluster_ldap_skel.conf

The final intention is that the functions in the .sh file be
integrated into multiple .ebuilds/seed-ebuilds and that the .conf file
be a reference for these seeds.

As much as possible information is deduced from the system (ie: usage
of $(hostname -d) for generating the ldap DC info) and all.

I am attempting to keep documentation of my efforts here but I'm no
blogger...so:
http://soc.gentooexperimental.org/projects/gentoo-cluster-seed/news

Eric Thibodeau

[Stuart Herbert]

On Thu, Jun 26, 2008 at 7:10 PM, kyron <ky...@neuralbs.com> wrote:

Doing some parallel work here and I think we might want to join our

efforts.

:)

 

Here is what I have made while working on a Gentoo Clustering LiveCD
(which I hope to change into an
actual SEED):

http://wiki.neuralbs.com/~kyron/soc2008/

The two files of interest are cluster_ldap_skel.conf and ldap-
setup.sh, all other files are auto-generated by calling

./ldap-setup.sh cluster_ldap_skel.conf

The final intention is that the functions in the .sh file be
integrated into multiple .ebuilds/seed-ebuilds and that the .conf file
be a reference for these seeds.

As much as possible information is deduced from the system (ie: usage
of $(hostname -d) for generating the ldap DC info) and all.

I am attempting to keep documentation of my efforts here but I'm no
blogger...so:
http://soc.gentooexperimental.org/projects/gentoo-cluster-seed/news

Interesting stuff.  Are you working on this as part of this year's Summer of Code?

[Eric Thibodeau]

Stuart Herbert wrote:

On Thu, Jun 26, 2008 at 7:10 PM, kyron <ky...@neuralbs.com> wrote:

Doing some parallel work here and I think we might want to join our

efforts.

:)

 

Here is what I have made while working on a Gentoo Clustering LiveCD
(which I hope to change into an
actual SEED):

http://wiki.neuralbs.com/~kyron/soc2008/

The two files of interest are cluster_ldap_skel.conf and ldap-
setup.sh, all other files are auto-generated by calling

./ldap-setup.sh cluster_ldap_skel.conf

The final intention is that the functions in the .sh file be
integrated into multiple .ebuilds/seed-ebuilds and that the .conf file
be a reference for these seeds.

As much as possible information is deduced from the system (ie: usage
of $(hostname -d) for generating the ldap DC info) and all.

I am attempting to keep documentation of my efforts here but I'm no
blogger...so:
http://soc.gentooexperimental.org/projects/gentoo-cluster-seed/news

Interesting stuff.  Are you working on this as part of this year's Summer of Code?

Yes, amongst other crazy projects like finishing my Master's thesis ;)

RE the LDAP automation script I made, I was wondering if you had any suggestions on how I (we) should convert this into seed(ed) ebuild(s). Lazily copying from the above blog link:

<quote>

Although most of the work that is being done by the script should be done by an ebuild, I had to chose a stand alone script beacuse:

1- I absolutely have to modify/create some files in /etc
2- Once some of the files created, I have to initiate the ldap database
3- Then successfully start the slapd daemon
4- and only then shall I finish the /etc file modifications (ie: changing /etc/nsswitch.conf to also use ldap as a backend)

Obviously, since this script is supposed to be called from within the catalyst process, Joe user should not have to use it but my intention is that the script could also be used later on for people wishing to implement LDAP without having to learn all that is required to get that going on their system (obviously with a BFW: "This is a one shot deal, don't expect it to work, you should read the docs, it's poison, it will reformat your car's carburator, etc..." I'm also leaving in the possiblity that the same script + config file approach could be used to add LDAP databases in the future (such as a shared Addressbook)

</quote>

Best regards,

Stu

Cheers,

Eric

[Stuart Herbert]

Hi Eric,

On Fri, Jun 27, 2008 at 12:40 PM, Eric Thibodeau <ky...@neuralbs.com> wrote:

RE the LDAP automation script I made, I was wondering if you had any suggestions on how I (we) should convert this into seed(ed) ebuild(s). Lazily copying from the above blog link:

Not at this time.  I need a bit more time to get up to speed with LDAP first before I can say anything useful on this.

 

Although most of the work that is being done by the script should be done by an ebuild, I had to chose a stand alone script beacuse:

1- I absolutely have to modify/create some files in /etc
2- Once some of the files created, I have to initiate the ldap database
3- Then successfully start the slapd daemon
4- and only then shall I finish the /etc file modifications (ie: changing /etc/nsswitch.conf to also use ldap as a backend)

From the Seed Linux point of view, all of this work needs to be possible from within ebuilds.  Because I haven't yet got a local seed working with LDAP, I don't understand why you have to do things in that exact order, so there isn't much of value I can add today.

Obviously, since this script is supposed to be called from within the catalyst process,

Seed Linux currently does not use catalyst, and I'm not convinced that we should use it or support it.  I wrote my own tool to build seeds from stage3 tarballs, which you can find in svn.  Having our own tool means that we can make customisations to work around upstream bugs (esp. dependency problems, the whole expat 2 screwup, and the like), and we can do extra work that catalyst wasn't really meant to do, and which upstream is historically violently hostile too, such as create a fully-working Xen VM.  My tool works very well, and also has the advantage that it works under other Linux distributions (I mostly develop it under CentOS).  It does need expanding to support creating other types of virtual machines, and to do cool things like add Amazon EC2 support too.

Joe user should not have to use it but my intention is that the script could also be used later on for people wishing to implement LDAP without having to learn all that is required to get that going on their system (obviously with a BFW: "This is a one shot deal, don't expect it to work, you should read the docs, it's poison, it will reformat your car's carburator, etc..." I'm also leaving in the possiblity that the same script + config file approach could be used to add LDAP databases in the future (such as a shared Addressbook)

That's not an issue for Seed Linux, I don't think.  We don't need to support people who want to migrate their seeds into LDAP, because we won't release any seeds until they use LDAP out of the box.  But what we will need will be tools to migrate to Seed Linux from other linux distros, especially Gentoo :)

Best regards,

Stu

--

[samba]

Hi all,

Just wanted to keep the thread alive and such -

I've been cleaning up my systems at home, and working on implementing
LDAP here so I know what I'm talking about. (I've had VERY limited
experience with LDAP until this point.) The Gentoo docs on LDAP are
decent, I find:
* http://gentoo-wiki.com/OpenLDAP (VERY applicable)
* http://www.gentoo.org/proj/en/infrastructure/ldap.xml (merely
notable)
* http://www.gentoo.org/doc/en/ldap-howto.xml (also applicable)

I've recently moved to another city, as a few of you know, and things
are shaping up nicely here. I'll very soon (early next month) be able
to commit more time to Seed Linux.

Also, in my new job there may be use for Seed Linux, which may give me
more time to develop for it - would be great. Likely not in the short-
term though, as they're hoping to get some functioning prototype to
the marketing folks, and don't want to spend time in the nearer future
on longer-term investments. (Hmph.)

-- Sam

On Jun 27, 8:03 am, "Stuart Herbert" <stu...@stuartherbert.com> wrote:
> Hi Eric,
>
> On Fri, Jun 27, 2008 at 12:40 PM, Eric Thibodeau <ky...@neuralbs.com> wrote:
> > RE the LDAP automation script I made, I was wondering if you had any
> > suggestions on how I (we) should convert this into seed(ed) ebuild(s).
> > Lazily copying from the above blog link:
>
> Not at this time.  I need a bit more time to get up to speed with LDAP first
> before I can say anything useful on this.
>
> > Although most of the work that is being done by the script should be done
> > by an ebuild, I had to chose a stand alone script beacuse:
>

> > 1- I *absolutely* have to modify/create some files in /etc
> > 2- Once *some* of the files created, I have to initiate the ldap database
> > 3- Then *successfully* start the slapd daemon
> > 4- and *only* then shall I finish the /etc file modifications (ie:

> > changing /etc/nsswitch.conf to also use ldap as a backend)
>
> From the Seed Linux point of view, all of this work needs to be possible
> from within ebuilds.  Because I haven't yet got a local seed working with
> LDAP, I don't understand why you have to do things in that exact order, so
> there isn't much of value I can add today.
>
> Obviously, since this script is supposed to be called from within the> catalyst process,
>
> Seed Linux currently does not use catalyst, and I'm not convinced that we
> should use it or support it.  I wrote my own tool to build seeds from stage3
> tarballs, which you can find in svn.  Having our own tool means that we can
> make customisations to work around upstream bugs (esp. dependency problems,
> the whole expat 2 screwup, and the like), and we can do extra work that
> catalyst wasn't really meant to do, and which upstream is historically
> violently hostile too, such as create a fully-working Xen VM.  My tool works
> very well, and also has the advantage that it works under other Linux
> distributions (I mostly develop it under CentOS).  It does need expanding to
> support creating other types of virtual machines, and to do cool things like
> add Amazon EC2 support too.
>
> > Joe user should not have to use it but my intention is that the script
> > could also be used later on for people wishing to implement LDAP without

> > having to learn *all* that is required to get that going on their system

> > (obviously with a BFW: "This is a one shot deal, don't expect it to work,
> > you should read the docs, it's poison, it will reformat your car's
> > carburator, etc..." I'm also leaving in the possiblity that the same script

> > + config file approach could be used to *add* LDAP databases in the future

[Stuart Herbert]

On Tue, Jul 29, 2008 at 8:52 AM, samba <sam.brie...@gmail.com> wrote:

Hi all,

Just wanted to keep the thread alive and such -

In that vein ... :)  work is currently eating up much of my spare time, leaving me little time to progress the LDAP support myself.

I've been cleaning up my systems at home, and working on implementing
LDAP here so I know what I'm talking about. (I've had VERY limited
experience with LDAP until this point.) The Gentoo docs on LDAP are
decent, I find:
* http://gentoo-wiki.com/OpenLDAP (VERY applicable)

Certain Gentoo developers will be bursting a blood vessel at the notion that the gentoo-wiki.com site is part of the Gentoo docs ;-)  

 

* http://www.gentoo.org/proj/en/infrastructure/ldap.xml (merely
notable)
* http://www.gentoo.org/doc/en/ldap-howto.xml (also applicable)

Best regards,

Stu

--

[samba]

> In that vein ... :)  work is currently eating up much of my spare time,
> leaving me little time to progress the LDAP support myself.

c'est la vie

> Certain Gentoo developers will be bursting a blood vessel at the notion that
> the gentoo-wiki.com site is part of the Gentoo docs ;-)

Indeed, but in a practical sense, who doesn't use the Gentoo wiki from
time to time when setting up their Gentoo boxes? Official affiliation
is overrated :p

[Stuart Herbert]

On Wed, Jul 30, 2008 at 5:45 PM, samba <sam.brie...@gmail.com> wrote:

> In that vein ... :)  work is currently eating up much of my spare time,
> leaving me little time to progress the LDAP support myself.

c'est la vie

I now have my Seed Linux Desktop support user account details stored in LDAP.  The Gentoo Wiki docs were useful, as was the O'Reilly LDAP book I bought a long time ago and had forgotten I owned :)

Now that I have working config files, next steps are:

1) agree a structure to the directory tree, and

2) agree configuration and security measures, and

3) have Seed Linux working with LDAP out of the box.

So, structure ... so far, I simply have ou=users,dc=seed-linux,dc=com in the tree, with the uid field under there being used as the Linux user name.  The structure needs to expand a little bit to include user groups and (probably) valid hosts.  My thinking is that we want a structure that makes as much sense on one machine as it does when there's one LDAP tree shared between many machines via replication.  Anyone have any feedback on this?

Configuration ... the main point here is that I've setup the LDAP clients (pam_ldap et al) to use the local UNIX socket rather than the network.  My thinking is that each machine should always have its own LDAP server.  In a larger setup, there would be a master server that replicates out to all the local servers, and if anyone needs an even larger setup (where the cost of replication is an issue), that can be addressed at the time.

Working out of the box ... my thinking here is that /etc/passwd would continue to hold root + all the system accounts installed by Portage (does Portage support storing new users into LDAP), and all user accounts would be stored in LDAP.  I would prefer to get to the point where only root + a few others lived in /etc/passwd, and everything else ran off LDAP (including accounts created by Portage), but I think that would be difficult to achieve, because we rely on Portage to install the base system in the first place.

Let me have your feedback :)  I'm aiming to commit this to SVN at the weekend.

Speaking of SVN ... I'm about to start renting a dedicated server, which would be suitable for hosting Seed Linux install images (atm, stage4 tarballs or Xen VMs I guess).  I'm very unimpressed with Google Code, and am seriously thinking of switching away.  Any thoughts on this at all?  Trac + svn appeals to me, as does looking at github.

 

> Certain Gentoo developers will be bursting a blood vessel at the notion that
> the gentoo-wiki.com site is part of the Gentoo docs ;-)

Indeed, but in a practical sense, who doesn't use the Gentoo wiki from
time to time when setting up their Gentoo boxes?  Official affiliation
is overrated :p

Heh.  When the time comes, I'd rather have a seed-wiki than just official docs, that's for sure.

Best regards,

Stu

--

[Eric Thibodeau]

Stuart Herbert wrote:

On Wed, Jul 30, 2008 at 5:45 PM, samba <sam.brie...@gmail.com> wrote:

> In that vein ... :)  work is currently eating up much of my spare time,
> leaving me little time to progress the LDAP support myself.

c'est la vie

I now have my Seed Linux Desktop support user account details stored in LDAP.  The Gentoo Wiki docs were useful, as was the O'Reilly LDAP book I bought a long time ago and had forgotten I owned :)

Now that I have working config files, next steps are:

1) agree a structure to the directory tree, and

2) agree configuration and security measures, and

3) have Seed Linux working with LDAP out of the box.

So, structure ... so far, I simply have ou=users,dc=seed-linux,dc=com in the tree, with the uid field under there being used as the Linux user name.  The structure needs to expand a little bit to include user groups and (probably) valid hosts.  My thinking is that we want a structure that makes as much sense on one machine as it does when there's one LDAP tree shared between many machines via replication.  Anyone have any feedback on this?

I strongly suggest not to use dc=com but rather dc=local to keep all options opened, including hostname integration into ldap, thus avoiding real (Internet) vs local DNS resolution.

Configuration ... the main point here is that I've setup the LDAP clients (pam_ldap et al) to use the local UNIX socket rather than the network.  My thinking is that each machine should always have its own LDAP server.  In a larger setup, there would be a master server that replicates out to all the local servers, and if anyone needs an even larger setup (where the cost of replication is an issue), that can be addressed at the time.

The newest version of OpenLDAP (2.4.10) has many new features that will be desirable (caching and groups of group wise).

Working out of the box ... my thinking here is that /etc/passwd would continue to hold root + all the system accounts installed by Portage (does Portage support storing new users into LDAP),

the eutils eclass would have to be re-written for that IIRC...which wouldn't be a bad thing either.

and all user accounts would be stored in LDAP.  I would prefer to get to the point where only root + a few others lived in /etc/passwd, and everything else ran off LDAP (including accounts created by Portage), but I think that would be difficult to achieve, because we rely on Portage to install the base system in the first place.

Make OpenLDAP part of the base system, there aren't that many users in a stage3 when you look at this. I don't have a specific scenario but I can imagine one wanting to centrally control some of the system accounts for XYZ reason (apache, postfix, etc?).

Let me have your feedback :)  I'm aiming to commit this to SVN at the weekend.

It is strongly recommended that Kerberos be part of the loop as it's what is being used in "serious" infrastructures ans would be a sign of robustness. The diradm app shouldn't be too difficult to modify to provide a single interface to user management but it might not be the ideal solution (as it requires that the sldapd admin password be stored in /etc/ldap.secret).

[Donnie Berkholz]

On 13:41 Mon 04 Aug , Eric Thibodeau wrote:

> Stuart Herbert wrote:
> > Working out of the box ... my thinking here is that /etc/passwd would
> > continue to hold root + all the system accounts installed by Portage
> > (does Portage support storing new users into LDAP),
>
> the eutils eclass would have to be re-written for that IIRC...which
> wouldn't be a bad thing either.

This is why Mike Kelly wrote creandus 2 years ago
<http://trac.pioto.org/creandus>. Someone could finish it.

--
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[Stuart Herbert]

On Mon, Aug 4, 2008 at 6:41 PM, Eric Thibodeau <ky...@neuralbs.com> wrote:

I strongly suggest not to use dc=com but rather dc=local to keep all options opened, including hostname integration into ldap, thus avoiding real (Internet) vs local DNS resolution.

Can you provide more information about this?  It's not clear what the problem is that you're suggesting we need to avoid.

  

The newest version of OpenLDAP (2.4.10) has many new features that will be desirable (caching and groups of group wise).

That's what I'm using.  I'm also wondering whether we should move the config into OpenLDAP itself (as per the 2.3 and 2.4 admin handbooks) rather than use /etc/openldap/slapd.conf.

 

the eutils eclass would have to be re-written for that IIRC...which wouldn't be a bad thing either.

My preference would be to replace useradd et al with LDAP-aware versions, tbh.  It would be easy enough to do with a bit of Perl, and we could easily have a rule that all UIDs < 1000 go into /etc/passwd, and the rest go into LDAP. 

Make OpenLDAP part of the base system, there aren't that many users in a stage3 when you look at this. I don't have a specific scenario but I can imagine one wanting to centrally control some of the system accounts for XYZ reason (apache, postfix, etc?).

OpenLDAP will be part of the base system, but the Seed Linux base system is substantially different to Gentoo's.  All of the Seed Linux packages are installed into 'system', leaving 'world' for additional packages installed by the local admin.

There is a good reason why apache, postfix et al should not go into LDAP at this time.  We have zero control over changes made to these system accounts by Portage packages.  It would only take one package to fsck up one of these system accounts, and via LDAP and a suitably-placed referrer Gentoo would take out more than just the local machine.  We can look at this again in the future, but atm it's simply not worth the risk.

It is strongly recommended that Kerberos be part of the loop as it's what is being used in "serious" infrastructures ans would be a sign of robustness. The diradm app shouldn't be too difficult to modify to provide a single interface to user management but it might not be the ideal solution (as it requires that the sldapd admin password be stored in /etc/ldap.secret).

Apart from Windows, I've never come across an installation of Kerberos, so I don't know much about it atm or why it should be built into Seed Linux.  I'd need to know more about who is actually using it before I can go down that road, and how we could make it work from single boxes (e.g. Seed Linux LAMP Developer Desktop) through to larger server farms (e.g. Seed Linux LAMP Server).

 

[Stuart Herbert]

On Mon, Aug 4, 2008 at 6:58 PM, Donnie Berkholz <dber...@gentoo.org> wrote:

This is why Mike Kelly wrote creandus 2 years ago
<http://trac.pioto.org/creandus>. Someone could finish it.

GLEP 27 is a *very* bad idea, and won't be adopted by Seed Linux at this time.

When you move files from machine to machine in a cluster (e.g. to recover from a serious hardware failure), you don't want to fsck around changing file and directory ownerships.  Usernames are nothing more than a convenient mapping to the underlying uids, and its the underlying uids that must be consistent from machine to machine to make a sysadmin's life a lot easier day in and day out.

Best regards,

Stu

--

[Eric Thibodeau]

Stuart Herbert wrote:

On Mon, Aug 4, 2008 at 6:41 PM, Eric Thibodeau <ky...@neuralbs.com> wrote:

I strongly suggest not to use dc=com but rather dc=local to keep all options opened, including hostname integration into ldap, thus avoiding real (Internet) vs local DNS resolution.

Can you provide more information about this?  It's not clear what the problem is that you're suggesting we need to avoid.

No, not really, I just have a bad feeling about setting something that could potentially be used as a real domain name inside a private structure. I say this with Kerberos and other services which are _very_ picky about DNS resolution.

  

The newest version of OpenLDAP (2.4.10) has many new features that will be desirable (caching and groups of group wise).

That's what I'm using.  I'm also wondering whether we should move the config into OpenLDAP itself (as per the 2.3 and 2.4 admin handbooks) rather than use /etc/openldap/slapd.conf.

That's a good question that I have no experience with unfortunately (it's shining new!)

 

the eutils eclass would have to be re-written for that IIRC...which wouldn't be a bad thing either.

My preference would be to replace useradd et al with LDAP-aware versions, tbh.  It would be easy enough to do with a bit of Perl, and we could easily have a rule that all UIDs < 1000 go into /etc/passwd, and the rest go into LDAP.

That's essentially what diradm does, it's worth looking at...

Make OpenLDAP part of the base system, there aren't that many users in a stage3 when you look at this. I don't have a specific scenario but I can imagine one wanting to centrally control some of the system accounts for XYZ reason (apache, postfix, etc?).

OpenLDAP will be part of the base system, but the Seed Linux base system is substantially different to Gentoo's.  All of the Seed Linux packages are installed into 'system', leaving 'world' for additional packages installed by the local admin.

There is a good reason why apache, postfix et al should not go into LDAP at this time.  We have zero control over changes made to these system accounts by Portage packages.  It would only take one package to fsck up one of these system accounts, and via LDAP and a suitably-placed referrer Gentoo would take out more than just the local machine.  We can look at this again in the future, but atm it's simply not worth the risk.

"should NOT" ...agreed!

It is strongly recommended that Kerberos be part of the loop as it's what is being used in "serious" infrastructures ans would be a sign of robustness. The diradm app shouldn't be too difficult to modify to provide a single interface to user management but it might not be the ideal solution (as it requires that the sldapd admin password be stored in /etc/ldap.secret).

Apart from Windows, I've never come across an installation of Kerberos, so I don't know much about it atm or why it should be built into Seed Linux.  I'd need to know more about who is actually using it before I can go down that road, and how we could make it work from single boxes (e.g. Seed Linux LAMP Developer Desktop) through to larger server farms (e.g. Seed Linux LAMP Server).

I'm currently managing a Linux only LDAP+Kerberos environment. I didn't set it up originally but I did manage to migrate the setting from an RH7.3 install to Gentoo so I did have to go through some configuration. One of my colleagues insists that Kerberos is a decent authentication mechanism compared to using OpenLDAP and that it's _meant_ to be one...not ldap per say. But I'm more of a user at that point than an integrator, I just followed the instructions and it works.

[Ranjit Singh]

On Monday 04 August 2008 22:54:00 Eric Thibodeau wrote:
> Stuart Herbert wrote:
> > On Mon, Aug 4, 2008 at 6:41 PM, Eric Thibodeau <ky...@neuralbs.com
> > <mailto:ky...@neuralbs.com>> wrote:
> >
> > I strongly suggest not to use dc=com but rather dc=local to keep
> > all options opened, including hostname integration into ldap, thus
> > avoiding real (Internet) vs local DNS resolution.
> >
> >
> > Can you provide more information about this? It's not clear what the
> > problem is that you're suggesting we need to avoid.
>
> No, not really, I just have a bad feeling about setting something that
> could potentially be used as a real domain name inside a private
> structure. I say this with Kerberos and other services which are _very_
> picky about DNS resolution.
>

.local is fairly standard practise from what I remember (I worked on a project
integrating postNuke with Active Directory via OpenLDAP a few years ago, when
samba3 was in beta, and have seen the same on many client Windows installs.)

> > Make OpenLDAP part of the base system, there aren't that many
> > users in a stage3 when you look at this. I don't have a specific
> > scenario but I can imagine one wanting to centrally control some
> > of the system accounts for XYZ reason (apache, postfix, etc?).
> >
> >
> > OpenLDAP will be part of the base system, but the Seed Linux base
> > system is substantially different to Gentoo's. All of the Seed Linux
> > packages are installed into 'system', leaving 'world' for additional
> > packages installed by the local admin.
> >
> > There is a good reason why apache, postfix et al should not go into
> > LDAP at this time. We have zero control over changes made to these
> > system accounts by Portage packages. It would only take one package
> > to fsck up one of these system accounts, and via LDAP and a
> > suitably-placed referrer Gentoo would take out more than just the
> > local machine. We can look at this again in the future, but atm it's
> > simply not worth the risk.
>
> "should NOT" ...agreed!
>

I think puppet would be ideal for Seed Linux (and indeed Gentoo):
http://reductivelabs.com/trac/puppet
Some of the security stuff looks a lot like Mandrake tbh.

> > It is strongly recommended that Kerberos be part of the loop as
> > it's what is being used in "serious" infrastructures ans would be
> > a sign of robustness. The diradm app shouldn't be too difficult to
> > modify to provide a single interface to user management but it
> > might not be the ideal solution (as it requires that the sldapd
> > admin password be stored in /etc/ldap.secret).
> >
> >
> > Apart from Windows, I've never come across an installation of
> > Kerberos, so I don't know much about it atm or why it should be built
> > into Seed Linux. I'd need to know more about who is actually using it
> > before I can go down that road, and how we could make it work from
> > single boxes (e.g. Seed Linux LAMP Developer Desktop) through to
> > larger server farms (e.g. Seed Linux LAMP Server).
>
> I'm currently managing a Linux only LDAP+Kerberos environment. I didn't
> set it up originally but I did manage to migrate the setting from an
> RH7.3 install to Gentoo so I did have to go through some configuration.
> One of my colleagues insists that Kerberos is a decent authentication
> mechanism compared to using OpenLDAP and that it's _meant_ to be
> one...not ldap per say. But I'm more of a user at that point than an
> integrator, I just followed the instructions and it works.
>

Kerberos is lovely when you can get it to work; it amazes me that people think
it's a Windows thing, though: it was developed by MIT from what I remember,
and only works properly via that god-awful "Services" for Unix thing (unless
your boxen are all doze in which case you have bigger problems..;) All of
these work much better if you don't have Windows running _any_ of the domain
controllers, and can bring up the network using samba for AD from the
beginning, with krb5 on another host as "ticket" manager; client machines
join that domain. I think it's reasonable to focus on that first, and leave
automating the move of an existing `forest' over til later (or for another
project) unless someone wants to work on it, ofc.

Once you have machine accounts setup and talking you're pretty much there
iirc, at least as far as getting a login authenticated by AD from *nix and
querying the user data, although M$ has a habit of adding binary blobs to
standard protocols, just to make it difficult (and keep people upgrading)
which is why I recommend setting up a PDC from Unix before you bring up
Exchange. 2K and XP behave as clients and if they're working with samba AD
and krb5, you're most of the way there (if you avoid Exchange altogether life
will be much sweeter. ;)

[Eric Thibodeau]

Ranjit Singh wrote:

On Monday 04 August 2008 22:54:00 Eric Thibodeau wrote:
  

Stuart Herbert wrote:
    

On Mon, Aug 4, 2008 at 6:41 PM, Eric Thibodeau <ky...@neuralbs.com
<mailto:ky...@neuralbs.com>> wrote:

    I strongly suggest not to use dc=com but rather dc=local to keep
    all options opened, including hostname integration into ldap, thus
    avoiding real (Internet) vs local DNS resolution.


Can you provide more information about this?  It's not clear what the
problem is that you're suggesting we need to avoid.
      

No, not really, I just have a bad feeling about setting something that
could potentially be used as a real domain name inside a private
structure. I say this with Kerberos and other services which are _very_
picky about DNS resolution.
    

.local is fairly standard practise from what I remember (I worked on a project 
integrating postNuke with Active Directory via OpenLDAP a few years ago, when 
samba3 was in beta, and have seen the same on many client Windows installs.)
  

Yes and it also makes it clear which part of the domain you're working on.

Yes, definitely work on a native solution before speaking of migration. It is the same problem as attempting to get people on OpenOffice and want to "migrate" their templates. I was told that one has to be very careful when designing a KRB auth mechanism since there are hierarchies such as the ones seen in LDAP and some of these are required by other software to be usable. MS Windows most probably expects such a structure.  I was told the Oreiley book on the subject is excellent and has a 5 page procedure on setting a Windows PDC using KRB5 and OpenLDAP.

Once you have machine accounts setup and talking you're pretty much there 
iirc, at least as far as getting a login authenticated by AD from *nix and 
querying the user data, although M$ has a habit of adding binary blobs to 
standard protocols, just to make it difficult (and keep people upgrading) 
which is why I recommend setting up a PDC from Unix before you bring up 
Exchange. 2K and XP behave as clients and if they're working with samba AD 
and krb5, you're most of the way there (if you avoid Exchange altogether life 
will be much sweeter. ;

Exchange is very hard to replace in an opensource fashion either as server or even client-server. The showstoppers I've hit:

- PIM gadget sync is poor to non-existant (ie: kpilot is still unable to sync categories) and..well...it doesn't run on windows
- Shared data such as schedules, tasks, and all other collaborative data is less than obvious and not well integrated on the FOSS servers as well as the clients. Point in case, thunderbird doesn't have calendaring yet and, IMHO, still has many annoying bugs/features (can't spell check a word with Shift-F10, I _have_ to use the mouse, sorting is inconsistent, it's not a PIM) .

[Stuart Herbert]

Hi,

On Wed, Aug 20, 2008 at 9:54 PM, Ranjit Singh <ran...@sukhisoft.com> wrote:

.local is fairly standard practise from what I remember (I worked on a project
integrating postNuke with Active Directory via OpenLDAP a few years ago, when
samba3 was in beta, and have seen the same on many client Windows installs.)

That's useful to know.  I'm very happy for us to use .local.

 

I think puppet would be ideal for Seed Linux (and indeed Gentoo):
http://reductivelabs.com/trac/puppet
Some of the security stuff looks a lot like Mandrake tbh.

I'm not convinced yet that puppet is the answer to administration of groups of machine.  I need more time to play with it.

 

Kerberos is lovely when you can get it to work; it amazes me that people think
it's a Windows thing, though: it was developed by MIT from what I remember

It was developed by MIT, but it was Microsoft's embrace of it in Windows NT that made it mainstream.

If someone wants to work on Kerberos support for seed linux, be my guest, but atm I don't feel that it's a priority.

Best regards,

Stu

[Stuart Herbert]

Hi,

On Wed, Aug 20, 2008 at 10:32 PM, Eric Thibodeau <ky...@neuralbs.com> wrote:

Exchange is very hard to replace in an opensource fashion either as server or even client-server. The showstoppers I've hit:

- PIM gadget sync is poor to non-existant (ie: kpilot is still unable to sync categories) and..well...it doesn't run on windows
- Shared data such as schedules, tasks, and all other collaborative data is less than obvious and not well integrated on the FOSS servers as well as the clients. Point in case, thunderbird doesn't have calendaring yet and, IMHO, still has many annoying bugs/features (can't spell check a word with Shift-F10, I _have_ to use the mouse, sorting is inconsistent, it's not a PIM) .

Zimbra does both gadget sync (inc. support for active sync) and collaboration very well, and although I haven't used it myself, their desktop client has had favourable mentions online.

Best regards,

Stu

--