FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Server Development

 
 
LinkBack Thread Tools
 
Old 04-28-2010, 05:25 PM
Adam Sommer
 
Default UDS Maverick: Call for Blueprints for Ubuntu Server

Hello,

On Wed, Apr 28, 2010 at 12:58 PM, Mathias Gug <mathiaz@ubuntu.com> wrote:




I think this is a great idea. Basing the work on the openldap-dit project is a

good start.



I would focus on:



*1. Identifying which use cases should be covered:

* ** user and group management.

*2. Creating a DIT that can be used to cover the use cases:

* ** openldap-dit is a good starting point.

*3. Creating a package that asks basic questions and setup the DIT.

*4. Looking into administration tools:

* ** CLI to cover the basic use cases - ldapscripts is useful.



I'd suggest to file a blueprint and discuss it at UDS if you wanna hash out the

plan for Maverick.



--


Thanks Andreas for creating openldap-dit. *For the last couple of days I've been testing it, and after a few updates was able to get it to work on Lucid. *As you mentioned there are a lot of ways to create a directory tree, and everyone does it differently. *I created a branch to attempt to modularize the *openldap-dit-setup.sh script based on which services an admin would like. *It's probably pretty crude, but I was able to apply all the different schemas, and tested the sudo items.


Mathias I created a blueprint here:*https://blueprints.launchpad.net/openldap-dit/+spec/server-maverick-openldap-dit*and I agree that another UDS discussion would be great :-). *


Thanks again.
--
Party On,
Adam

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 04-28-2010, 05:32 PM
Andreas Hasenack
 
Default UDS Maverick: Call for Blueprints for Ubuntu Server

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/28/2010 02:16 PM, Mark Foster wrote:
> On 04/28/2010 09:45 AM, Andreas Hasenack wrote:
>> with reasonable default ACLs, on which new LDAP
>> administrators could build on and have a starting place for whatever
>> setup they wanted
> Do you or will you consider having phpldapadmin as part of this
> "starting place"

I don't know, I kind of think that phpldapadmin could have its own
bootstrapping/dit if it were pointed to a clean directory. I would like
to stay as frontend-agnostic as possible.

> Because, administering LDAP from the command line can have quite steep
> learning curve vs. using the (web) gui once the dir servers is ready for
> that.

Having said that, I would certainly be interested in problems with my
DIT and phpldapadmin or any other tool out there. I can think of one
already which might break stuff out there, and that is the choosing of
groups I made which follows RFC2307bis, and not RFC2307. Not all tools
can cope with that (like smbldaptools, although it's trivial to fix it).

> Also, if LDAP is to be integrated for the DNS, powerdns
> (pdns-backend-ldap) does pretty well.

Could be. I guess I could have a different ldif for each dns
implementation, with its own schema.

In fact, one of the things we talked about in the past UDSs, and which
was done on the slapd package, is to make it so that other packages
could hook into slapd and fill it with their schema and trees. This is
possible because of the LDAPI authentication we have in place, which
maps root (unix id 0) to the ldap admin, so any client that runs as root
and connects to the LDAPI socket will be the ldap admin. Thus a package
would be able to, say, inspect the existing schema, upload its own, etc.
Think about that pdns-backend-ldap package asking in its postinst
permission to configure the locally running ldap server for its needs,
for example (with the default answer being "no, don't do that").

While some (most?) seasoned ldap admins would run away crying just by
the thought of that, surely LDAP newbies would appreciate it.

- --
Andreas Hasenack
andreas@canonical.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvYcSkACgkQeEJZs/PdwpBroACfbQbqBPtax4HhAyuZJ5wM2dAI
6jUAnRpmlB+C3d22VMOjFuSwzWKrQQrm
=McG6
-----END PGP SIGNATURE-----

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 04-28-2010, 05:55 PM
Andreas Hasenack
 
Default UDS Maverick: Call for Blueprints for Ubuntu Server

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/28/2010 02:25 PM, Adam Sommer wrote:
> Thanks Andreas for creating openldap-dit. For the last couple of days
> I've been testing it, and after a few updates was able to get it to work
> on Lucid. As you mentioned there are a lot of ways to create a

Cool!

I think the goal should be to get a starting point that helps newbies to
at least *see* something when they point an ldap client to the server,
and also allow more seasoned admins to build upon that tree.

For me, that means:
- - we need a database configured (indexes, checkpoints, caches,
DB_CONFIG, etc)
- - we need a tree root
- - seems like ou=People and ou=Group are pretty common and we should also
have them at least
- - basic ACLs to protect content that is not even there yet (like
userPassword, krb5key, samba hashes, etc)
- - basic ACLs to allow for group-delegated based administration
- - an admin group, with a member for whom we have a password. This member
is what the user should use. This concept of administration group
resonates quite nicely with the default ubuntu sudo setup.

It's because of this group based administration that I chose RFC2307bis,
because it allows me to use the refint overlay and automatically update
the group memberships if the user is removed from the tree, or has
his/her name changed, etc.

We can build upon that. A sudo-ldap package, for example, could detect
that this tree is in place and offer to:
- - add the sudo schema (assuming it was not added by the openldap-dit
base package)
- - create ou=sudoers and add the group based administration acls (if not
part of the default dit)
- - perhaps even migrate an existing /etc/sudoers to ldap if so desired
(there are scripts for that)

The above can all be done dynamically at postinst, because we have
cn=config, if the package is installed on the same machine as the ldap
server. If not, then it would need ldap credentials to make these
changes over the network, but even so it could work.

In karmic, openldap-dit triggers a bug in slapd which starts consuming
100% cpu and hangs. I filed a LP bug with a patch, and it was applied to
lucid, but not to the karmic package yet (#485026). It's one of the
problems (or risks, should I say) of using these many overlays.
Sometimes a specific combination of them triggers a bug, like that case.

- --
Andreas Hasenack
andreas@canonical.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvYdpsACgkQeEJZs/PdwpBZNQCgo637Pw4z/0GHAPIqQnP8T/DH
C34AoKAL3ptQ/QxQxHHSR9MYxbA+JifZ
=+keB
-----END PGP SIGNATURE-----

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 04-28-2010, 06:14 PM
Adam Sommer
 
Default UDS Maverick: Call for Blueprints for Ubuntu Server

On Wed, Apr 28, 2010 at 1:55 PM, Andreas Hasenack <andreas@canonical.com> wrote:




I think the goal should be to get a starting point that helps newbies to

at least *see* something when they point an ldap client to the server,

and also allow more seasoned admins to build upon that tree.



For me, that means:

- - we need a database configured (indexes, checkpoints, caches,

DB_CONFIG, etc)

- - we need a tree root

- - seems like ou=People and ou=Group are pretty common and we should also

have them at least

- - basic ACLs to protect content that is not even there yet (like

userPassword, krb5key, samba hashes, etc)

- - basic ACLs to allow for group-delegated based administration

- - an admin group, with a member for whom we have a password. This member

is what the user should use. This concept of administration group

resonates quite nicely with the default ubuntu sudo setup.



It's because of this group based administration that I chose RFC2307bis,

because it allows me to use the refint overlay and automatically update

the group memberships if the user is removed from the tree, or has

his/her name changed, etc.



We can build upon that. A sudo-ldap package, for example, could detect

that this tree is in place and offer to:

- - add the sudo schema (assuming it was not added by the openldap-dit

base package)

- - create ou=sudoers and add the group based administration acls (if not

part of the default dit)

- - perhaps even migrate an existing /etc/sudoers to ldap if so desired

(there are scripts for that)



The above can all be done dynamically at postinst, because we have

cn=config, if the package is installed on the same machine as the ldap

server. If not, then it would need ldap credentials to make these

changes over the network, but even so it could work.


I totally agree I think doing all that for Lucid would be a great thing for new users to OpenLDAP and Ubuntu.


*


In karmic, openldap-dit triggers a bug in slapd which starts consuming

100% cpu and hangs. I filed a LP bug with a patch, and it was applied to

lucid, but not to the karmic package yet (#485026). It's one of the

problems (or risks, should I say) of using these many overlays.

Sometimes a specific combination of them triggers a bug, like that case.





Ya, it gets complicated pretty quick once you start adding multiple schemas and acls :-). *I guess when that happens the tool should fail gracefully and maybe point to documentation on how to manually add the required objects to your tree.

*I would really like to see OpenLDAP be a great selling point for Ubuntu Server, and should have time this cycle to help out developing, testing, or whatever needs to be done.
--
Party On,


Adam

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 04-28-2010, 06:24 PM
Mathias Gug
 
Default UDS Maverick: Call for Blueprints for Ubuntu Server

Hi Andreas,

On Wed, Apr 28, 2010 at 02:32:27PM -0300, Andreas Hasenack wrote:
>
> In fact, one of the things we talked about in the past UDSs, and which
> was done on the slapd package, is to make it so that other packages
> could hook into slapd and fill it with their schema and trees. This is
> possible because of the LDAPI authentication we have in place, which
> maps root (unix id 0) to the ldap admin, so any client that runs as root
> and connects to the LDAPI socket will be the ldap admin. Thus a package
> would be able to, say, inspect the existing schema, upload its own, etc.

I've slightly changed the behavior in Lucid: there isn't a mapping anymore (and
thus cn=localroot,cn=config has gone away).

The actual sasl dn is used in the olcAccess for cn=config and the frontend database:

olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=ex ternal,cn=auth manage by * break

> Think about that pdns-backend-ldap package asking in its postinst
> permission to configure the locally running ldap server for its needs,
> for example (with the default answer being "no, don't do that").
>

Exactly. That's the main goal of moving to cn=config and adding an olcAccess
for the local root user:

any package will be able to stick schemas and configure things in the local
slapd instance.

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 04-28-2010, 06:31 PM
Jorge Armando Medina
 
Default UDS Maverick: Call for Blueprints for Ubuntu Server

Benjamin Griese wrote:
> Hi Mark,
>
> thats a quite good idea, at the moment I prefer Apache Directory Studio.
> When you have got a client system to manage the server, its imo the
> better solution to administer your DIT.
> Its available for lnx, win and mac. Therefore it covers the most
> platforms.
Me and some customers prefere Apache Directory Studio over gq,
ldapbrowser and other GUI ldap client and editors, it requieres java,
but who doesnt have java already installed?


>
> Bye.
>
> On Wed, Apr 28, 2010 at 19:16, Mark Foster <mark@foster.cc> wrote:
>
> On 04/28/2010 09:45 AM, Andreas Hasenack wrote:
> > with reasonable default ACLs, on which new LDAP
> > administrators could build on and have a starting place for whatever
> > setup they wanted
> Do you or will you consider having phpldapadmin as part of this
> "starting place"
> Because, administering LDAP from the command line can have quite steep
> learning curve vs. using the (web) gui once the dir servers is
> ready for
> that.
>
> Also, if LDAP is to be integrated for the DNS, powerdns
> (pdns-backend-ldap) does pretty well.
>
> --
> I hate racists. Mark D. Foster<mark@foster.cc>
> http://mark.foster.cc/ | http://www.freegeekseattle.org/
>
>
>
> --
> ubuntu-server mailing list
> ubuntu-server@lists.ubuntu.com <mailto:ubuntu-server@lists.ubuntu.com>
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
> More info: https://wiki.ubuntu.com/ServerTeam
>
>
>
>
> --
> To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To
> be is to do -- Sartre | Do be do be do -- Sinatra
>


--
Jorge Armando Medina
Computación Gráfica de México
Web: http://www.e-compugraf.com
Tel: 55 51 40 72, Ext: 124
Email: jmedina@e-compugraf.com
GPG Key: 1024D/28E40632 2007-07-26
GPG Fingerprint: 59E2 0C7C F128 B550 B3A6 D3AF C574 8422 28E4 0632


--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 04-28-2010, 06:58 PM
Jean-Michel Dault
 
Default UDS Maverick: Call for Blueprints for Ubuntu Server

On Wed, 2010-04-28 at 13:31 -0500, Jorge Armando Medina wrote:
> > thats a quite good idea, at the moment I prefer Apache Directory Studio.
> > When you have got a client system to manage the server, its imo the
> > better solution to administer your DIT.
> > Its available for lnx, win and mac. Therefore it covers the most
> > platforms.
> Me and some customers prefere Apache Directory Studio over gq,
> ldapbrowser and other GUI ldap client and editors, it requieres java,
> but who doesnt have java already installed?

We use GOsa for all of our customers and are really happy with the
results.

It's a web interface built in PHP with smarty templates and
internationalization, that lets you manage users, groups, departments,
sudo roles, and can even do dhcp/dns, and other nice stuff.

I'm currently migrating a chinese manufacturing company with over 800
accounts. They're getting rid of their Active Directory and moving to
Linux thin clients with LTSP and some Windows Terminal Servers for
legacy apps. GOsa handles all the SID generation for Samba so that
everything is seamless.

The only downside is that it uses extended schemas to store the
information. To work with Andréas's DIT structure, we would need to
convert everything to cn=config format. That's on my medium-term TODO
list, but if anyone is interested in helping, that could be ready for
Maverick...

--
Jean-Michel Dault
Technology Architect
jmd@rlnx.com
Révolution Linux inc
http://www.revolutionlinux.com


--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 04-28-2010, 07:24 PM
Andreas Hasenack
 
Default UDS Maverick: Call for Blueprints for Ubuntu Server

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/28/2010 03:58 PM, Jean-Michel Dault wrote:
> The only downside is that it uses extended schemas to store the
> information. To work with Andréas's DIT structure, we would need to
> convert everything to cn=config format. That's on my medium-term TODO
> list, but if anyone is interested in helping, that could be ready for
> Maverick...

If you already have GOSA in place, I don't see why you would need
openldap-dit.

- --
Andreas Hasenack
andreas@canonical.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvYi3QACgkQeEJZs/PdwpBOoQCfb3EJ/gNMLUfhFF4KXwGnPuNs
ijwAnivD80WdOXptdMtsR5apmSwJfyim
=OiHV
-----END PGP SIGNATURE-----

--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 04-28-2010, 07:38 PM
Veli-Matti Lintu
 
Default UDS Maverick: Call for Blueprints for Ubuntu Server

ke, 2010-04-28 kello 14:32 -0300, Andreas Hasenack kirjoitti:

> Having said that, I would certainly be interested in problems with my
> DIT and phpldapadmin or any other tool out there. I can think of one
> already which might break stuff out there, and that is the choosing of
> groups I made which follows RFC2307bis, and not RFC2307. Not all tools
> can cope with that (like smbldaptools, although it's trivial to fix it).

Lately I've been involved in creating OpenLDAP DIT for schools running
on Lucid and one thing that I've been wondering is whether it would be
possible to define one standard structure for Ubuntu that all tools
would be configured to use by default. That wouldn't take away the
possibility of configuring everything differently, but all tools and
tutorials would follow this one model.

Out of curiosity I checked what the defaults are in different systems.
If I got things written down correctly, the different default structures
I could find were:

Hardy slapd package init script and OpenDS:
* ou=People
* ou=Groups

smbldap-tools:
* ou=Users
* ou=Groups
* ou=Computers
* ou=Idmap

openldap-dit and openldap-mandriva-dit are based on RFC2307bis:
* ou=People
* ou=Group
* ou=Hosts
* ou=System Accounts
* ou=System Groups
* ou=Kerberos Realms
* ou=Idmap
* ou=Address Book

Fedora / FreeIPA uses something completely different:
* cn=users,cn=accounts
* cn=groups,cn=accounts
* cn=computers,cn=accounts
* cn=services,cn=accounts
* cn=account inactivation,cn=accounts
* cn=Kerberos

Now different tools have different defaults and tutorials use randomly
some names that probably confuse many people.

Having one standard DIT that is installed by default would help a lot
with external applications that are not packaged for Ubuntu. For example
Moodle that is used in schools can use LDAP, but it needs to be
configured properly. Writing a guide for that gets a lot easier if
standard structure is available.

> In fact, one of the things we talked about in the past UDSs, and which
> was done on the slapd package, is to make it so that other packages
> could hook into slapd and fill it with their schema and trees. This is
> possible because of the LDAPI authentication we have in place, which
> maps root (unix id 0) to the ldap admin, so any client that runs as root
> and connects to the LDAPI socket will be the ldap admin. Thus a package
> would be able to, say, inspect the existing schema, upload its own, etc.
> Think about that pdns-backend-ldap package asking in its postinst
> permission to configure the locally running ldap server for its needs,
> for example (with the default answer being "no, don't do that").

> While some (most?) seasoned ldap admins would run away crying just by
> the thought of that, surely LDAP newbies would appreciate it.

As I wasn't aware of openldap-dit until recently, I've been working on a
script to initialise slapd w/ssl and mit kerberos. The idea is that the
script first checks which schemas and modules are installed and then
adds the missing schemas and modules and configures them. It makes also
possible to dump current configuration and check for common problems
with ssl certificates and such. I try to get it uploaded somewhere soon
so that others can see if it'd be helpful.

Automatically loading the schemas sounds good, but how to configure
overlays and ACLs for everything is something that would probably need
some other solution. E.g. we have some needs for ACLs that probably
don't make sense outside schools, but are needed for us as we have
school districts, schools, superusers, school admins, teachers, pupils,
etc..

Veli-Matti


--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 
Old 04-28-2010, 07:43 PM
Jean-Michel Dault
 
Default UDS Maverick: Call for Blueprints for Ubuntu Server

On Wed, 2010-04-28 at 16:24 -0300, Andreas Hasenack wrote:
> On 04/28/2010 03:58 PM, Jean-Michel Dault wrote:
> > The only downside is that it uses extended schemas to store the
> > information. To work with Andréas's DIT structure, we would need to
> > convert everything to cn=config format. That's on my medium-term TODO
> > list, but if anyone is interested in helping, that could be ready for
> > Maverick...
> If you already have GOSA in place, I don't see why you would need
> openldap-dit.

Both DITs have features that are missing in the other. And I like the
way cn=config works ;-)


--
Jean-Michel Dault
Technology Architect
jmd@rlnx.com
Révolution Linux inc
http://www.revolutionlinux.com


--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
 

Thread Tools




All times are GMT. The time now is 12:51 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org