List Archive: gentoo-soc
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<u><b>LDAP:</b></u><br>
I spent many hours (way over the 30 hours I had promised myself to
pass/week on SoC) creating an LDAP-as-auth-backend auto-install script.
It's not simple because Gentoo's philosophy is that ebuilds do as
little as possible and the admin does the work. I have no problems with
this approach but it's, by definition, countering my efforts of
providing a "turn-key" solution Clustering LiveCD. 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:<br>
<br>
1- I _absolutely_ have to modify/create some files in /etc<br>
2- Once _some_ of the files created, I have to initiate the ldap
database<br>
3- Then _successfully_ start the slapd daemon<br>
4- and _only_ then shall I finish the /etc file modifications (ie:
changing /etc/nsswitch.conf to also use ldap as a backend)<br>
<br>
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)<br>
<br>
Well, even though all of this seems far from clustering and HPC, the
whole central auth and management is an issue when it comes to a
cluster. One has to remember that a cluster is like a department
isolated on it's own network and everyone is supposed to be able to log
onto _any_ machine and expect them to all behave the exact same way.<br>
<br>
Stuff that would be nice to also have in LDAP which isn't presently
part of my script/template:<br>
<br>
* Automount definitions<br>
* TLS<br>
* <br>
<br>
<u><b>Catalyst:<br>
</b></u>I updated the spec files to use a new snapshot since I will
want to be using net-nds/openldap-2.4.10 and it's quite recent in the
tree. In the process I noticed I could get to Stage3 with no problems
but that liveCD-stage1.spec now completely barfs with a huge list of
loop dependency errors. I backtracked to the original snapshot and the
errors are also there. I'll have to investigate by removing my profile
overlay, it's probably due to some change I did in there and didn't
rebuild the liveCD since. It's not critical for the moment so I'll set
that aside for the time being (adding a bug ton soc.gexp.o)<br>
<br>
<u><b>Clustering:</b></u><br>
Jsbronder's on fire, I'll definately have to look into his *empi* and
*eselect mpi* work, being more than just relevant to clustering ;)<br>
<br>
<u><b>Special thanks:</b></u><br>
robbat2: for all his help and patience with my obvious n00bism
concerning LDAP ACLs and some config directives ;)<br>
Damm (#ldap): Has helped me with a few questions and made me waste much
time on nssov...which I thwarted him into trying to create an ebuild
now :P<br>
<br>
Eric<br>
PS: also available under the project's News :
<a class="moz-txt-link-freetext" href="http://soc.gentooexperimental.org/projects/gentoo-cluster-seed/news">http://soc.gentooexperimental.org/projects/gentoo-cluster-seed/news</a><br>
Current files not currently available on the web site...so here they
are. I DIDN'T run ispell on them...so please, no harsh comments on my
keyboard dyslexia ;)<br>
</body>
</html>
|
#!/bin/bash
# By Eric Thibodeau
# 13 June 2008
#
# NOTES:
# * it is usually suggested to keep all definitions in
# _lower case_... but do as youi wish!
# * all *_DESC variables are optionnal and are simply used
# in the description field of the LDAP db.
#
# What is the name you want to give the LDAP domain?
# say we wanted the domain to be gentoo.local you would
# put the following:
DOMAIN="gentoo.local"
DOMAIN_DESC="This is the top of the LDAP hierarchy"
# Which part of your organisation is this machine filling in
# for? In the present example, this is the cluster so we'll call
# this Organizational Unit (ou) cluster:
OU="cluster"
OU_DESC="Clustering department branch. All units defined under this branch are for use by the cluster"
# We will create some specific branches under that cluster,
# logically, we'll have users and groups to manage these, so
# we will minimally impose the definition of these two:
USERS_OU="users"
USERS_OU_DESC="Cluster specific Users"
GROUPS_OU="groups"
GROUPS_OU_DESC="Cluster specific Groups"
# OUTHER_OU is parsed to automatically create other sub-OU under
# the one defined above (as OU). This could be, for example:
#OTHER_OU="aliases networks hosts"
# if you want descriptions to be added to each of these groups
# automatically in the LDAP database, dedine a separate _DESC
# vairable for each. For example:
#aliases_DESC="This is the container for user aliases"
#hosts_DESC="This is the container for static host descriptions"
# Although this is often a philosophical debate, we'll stick
# with having an admin for the ldap user database and one
# for managing it's contents. Here is the dirrerence in their
# role:
#
# The ADMIN_DN will be the user used to create the ldap db
# and have total control over it. This user is typically useful
# only at creation and dumping/migration of the database. This
# user _always_ has TOTAL access to the LDAP db where it's
# defined. One typically _doesn't_ use this user to mange the
# LDAP database, the user defined in ADMIN_DN is the one to use.
#
LDAP_ADMIN_DN="admin"
# This is the paswsord to use for LDAP management tasks and is the
# one that is stored in /etc/openldap/slapd.conf (but we at least
# hash it ;)
LDAP_ADMIN_DN_PWD="default"
# The following user will essentially be identical to root, you're better
# off not renaming him.
ADMIN_DN="root"
ADMIN_DN_DESC="root account (under LDAP)"
# The following is the name of the group used to identify people
# with full access to the LDAP db. One advantage is that the members
# of this group can be dynamically changed within the LDAP db. NOTE:
# Since it's given the same gid as wheel, it's functionnaly equivalent!!!
ADMIN_GROUP_DN="wheel"
ADMIN_GROUP_DN_DESC="Users in this group can freely modify the LDAP directory at will"
# The following is the place to put the resulting generated files
# usually we'd want this to be ROOT="/" ...if you trust the script
# entirely ;). We use the environment's $ROOT if one is available...
[[ -z $ROOT ]] && ROOT="/"
# The LDAP_AS_AUTH determines wether we change /etc/nsswitch.conf
# AND /etc/pam.d/system-auth so that LDAP can _also_ be used as
# and authetication backend. We anticipate the script could also be
# used as a means to create other LDAP configs (ie: shared addressbook)
# But for the meantimne, leave it to yes:
LDAP_AS_AUTH="#yes"
# The LDIF_OUT defines the name of the ldif file that will be automatically
# created by the script. It's only really useful if you want to keep that file
# afterwards for xyz reason (obviously, LDIF_OUT_KEEP has to be set to yes):
LDIF_OUT="./create_db.ldif"
LDIF_OUT_KEEP="yes"
|
|
