# UDEV starts before LDAP, but needs LDAP info...

## dahoste

I recently switched to SMB/LDAP for all of my user:group authentication.  Upon booting, I see some messages about the LDAP server not being available -- which makes sense, because at that point in the boot sequence, it *isn't* available (the network devices aren't even up yet).  While I suspect this might be causing a number of problems to be lurking, I discovered at least one specific problem:  my CDROM device (/dev/hdc) isn't configured correctly because udev can't  access the 'cdrom' group because it can't talk to the LDAP server (at which pam has told it to direct user:group queries, via /etc/nsswitch.conf).

I could probably get around this be re-instating the 'cdrom' group to /etc/group.  I'd prefer not to do this -- I want as much of the user:group info in LDAP and out of /etc as possible.

If I manually run 'udevstart' after booting, then the cdrom gets re-configured properly, as udev can then successfully query the LDAP server.  So, I think I can get around the issue by adding 'udevstart' to /etc/conf.d/local.start.  But that seems like overkill.

Is there a more elegant solution to the boot sequence dependency?  

Thanks!

----------

## m_spidey

Hi There

Maybe you can post your 

```
rc-update -s
```

 Have you played with different load levels?

Cheers

----------

## dahoste

Sure thing:

```
 rc-status -s

Runlevel: all

 apache2                                                                                [ started  ]

 bootmisc                                                                               [ started  ]

 checkfs                                                                                [ started  ]

 checkroot                                                                              [ started  ]

 checksf                                                                                [ stopped  ]

 clock                                                                                  [ started  ]

 consolefont                                                                            [ started  ]

 courier-authlib                                                                        [ started  ]

 courier-imapd                                                                          [ stopped  ]

 courier-imapd-ssl                                                                      [ started  ]

 courier-pop3d                                                                          [ stopped  ]

 courier-pop3d-ssl                                                                      [ started  ]

 crypto-loop                                                                            [ stopped  ]

 cupsd                                                                                  [ stopped  ]

 dbus                                                                                   [ stopped  ]

 dhcpd                                                                                  [ started  ]

 dhcrelay                                                                               [ stopped  ]

 esound                                                                                 [ stopped  ]

 famd                                                                                   [ stopped  ]

 gpm                                                                                    [ stopped  ]

 hald                                                                                   [ stopped  ]

 hdparm                                                                                 [ stopped  ]

 hostname                                                                               [ started  ]

 hotplug                                                                                [ stopped  ]

 http-replicator                                                                        [ started  ]

 ip6tables                                                                              [ stopped  ]

 iptables                                                                               [ stopped  ]

 keymaps                                                                                [ started  ]

 local                                                                                  [ started  ]

 localmount                                                                             [ started  ]

 metalog                                                                                [ started  ]

 mit-krb5kadmind                                                                        [ stopped  ]

 mit-krb5kdc                                                                            [ stopped  ]

 modules                                                                                [ started  ]

 mysql                                                                                  [ started  ]

 mysqlmanager                                                                           [ stopped  ]

 net.eth0                                                                               [ started  ]

 net.eth1                                                                               [ started  ]

 net.lo                                                                                 [ started  ]

 netmount                                                                               [ started  ]

 nfs                                                                                    [ stopped  ]

 nfsmount                                                                               [ stopped  ]

 nscd                                                                                   [ started  ]

 ntp-client                                                                             [ stopped  ]

 ntpd                                                                                   [ started  ]

 numlock                                                                                [ stopped  ]

 pg_autovacuum                                                                          [ stopped  ]

 portmap                                                                                [ started  ]

 postgresql                                                                             [ stopped  ]

 rmnologin                                                                              [ started  ]

 rsyncd                                                                                 [ started  ]

 samba                                                                                  [ started  ]

 shorewall                                                                              [ started  ]

 slapd                                                                                  [ started  ]

 slimserver                                                                             [ started  ]

 slurpd                                                                                 [ stopped  ]

 sshd                                                                                   [ started  ]

 svnserve                                                                               [ stopped  ]

 svscan                                                                                 [ started  ]

 teamspeak2-server                                                                      [ started  ]

 urandom                                                                                [ started  ]

 ventrilo                                                                               [ stopped  ]

 vixie-cron                                                                             [ started  ]

 xdm                                                                                    [ stopped  ]

 zope-apache293                                                                         [ started  ]

```

No - I haven't done anything with load levels.  In fact, I don't know much about them.  I'll have to learn about them.

Thanks for your inquiry.

----------

## aidanjt

 *dahoste wrote:*   

> I recently switched to SMB/LDAP for all of my user:group authentication.  Upon booting, I see some messages about the LDAP server not being available -- which makes sense, because at that point in the boot sequence, it *isn't* available (the network devices aren't even up yet).  While I suspect this might be causing a number of problems to be lurking, I discovered at least one specific problem:  my CDROM device (/dev/hdc) isn't configured correctly because udev can't  access the 'cdrom' group because it can't talk to the LDAP server (at which pam has told it to direct user:group queries, via /etc/nsswitch.conf).
> 
> I could probably get around this be re-instating the 'cdrom' group to /etc/group.  I'd prefer not to do this -- I want as much of the user:group info in LDAP and out of /etc as possible.
> 
> If I manually run 'udevstart' after booting, then the cdrom gets re-configured properly, as udev can then successfully query the LDAP server.  So, I think I can get around the issue by adding 'udevstart' to /etc/conf.d/local.start.  But that seems like overkill.
> ...

 

Well LDAP authentication (and other remote authentication measures) are only ment to replace user usernames and user groups, it doesn't replace /etc for the system users and groups, nor should it.

----------

## dahoste

Does that mean there aren't any issues with mixing & matching -- i.e. referencing system groups (like 'cdrom') in the ldap group membership for a given user, when the gid doesn't exist in the ldap db anywhere.  Or do I need to replicate group entries in ldap for any system groups that I need to use?

thanks!

----------

## locovaca

Ok, I'll ask a question in here, as I'm having the same dilemma.  Can you add, in this case, the CDROM group locally to the workstation, and also have a CDROM group in the LDAP directory (but named something like CDROM-GLOBAL), and then include the global group into the local group?

Essentially I too am trying to clean up /etc and migrate EVERYTHING to LDAP.  For example, I don't want to have to set up the wheel group for su/sudo on 25 workstations- I want to add it once via LDAP and have that pushed out to everything.  Ditto with VMWare.

So nested groups... yea or nay?

(If it turns out to be nay... that's one large thing that Active Directory has over LDAP!)

----------

## VoVaN

Solution 1:

I think in our case one solution is starting udev initially with a minimum set of rules, which isn't involving any LDAP information, and after network starts initialize the rest of udev rules.

Solution 2:

If you need migrating (almost)everything to LDAP, you neet initializing network interface as early as possible during the boot process or even compiling network driver into the kernel and use kernel's DHCP.

----------

## dahoste

Well, this is more frustrating than I'd anticipated.  VoVaN - thanks for your suggestions.  I will look into solution #1 for the specific udev problem I encountered, but as locovaca points outs - this really speaks to a larger issue with LDAP: managing domain-wide groups with system/client groups.  AidanJT first stated that LDAP isn't meant to completely replace /etc/group (and /etc/password), which I believe, but since it *isn't*, how do we reconcile the need to coordinate LDAP group membership with system groups in /etc/group?  LDAP users typically need membership in groups like wheel, cdrom, audio, etc..  And having to manually add that membership in /etc/group for each machine in a domain defeats the purpose of using LDAP.

This came to my attention because I ran into a chicken-egg problem between one of the system groups and access to the LDAP server.  Maybe this isn't as bad as I think it is and there's really only one or two groups that need to be visible before networks services are available (at which point everything in the LDAP db is available to the system).  So I should be looking into how to either (a) make the network services available earlier (as you suggest in solution #2), or (b) postpone starting whatever needs access to the one or two system groups until after -- if that's even possible, depending on the particular service.  There may be a circular dependency that causes this to get really ugly.

The problem originates with the nsswitch mechanism.  My nsswitch.conf currently contains this for groups:

```
group:       files ldap
```

It is configured that way because that's what the SMD/LDAP howto said.  Also - there's a /etc/nsswitch.ldap that is provided as reference, and that's what it contains.  But what if I did something like this instead:

```
group:       ldap [UNAVAIL=continue] files
```

The 'continue' action should actually be the default for the 'UNAVAIL' status, so probably don't have to include that, but the important thing is that this would cause LDAP to be queried first, and if it isn't responding yet, the query would fall back to the /etc/group.  The problem I see with this is that it means *everything* that exists in /etc/group actually does need to exist in LDAP, because when LDAP is responding to queries, it will return 'NOTFOUND' for groups that aren't in LDAP (which is basically all of the system groups).  And what you really want in that case is for the query to also fall back to /etc/group.  So maybe this would work:

```
group:       ldap [UNAVAIL=continue NOTFOUND=continue] files
```

That basically means that LDAP isn't authoritative, but rather just gets first chance to respond to queries.  Actually -- after looking more closer at the man for nsswitch.conf, it looks like 'NOTFOUND=continue' is also the default behavior.  So really the critical thing is to just reverse the order of 'ldap' and 'files' for the group line.  Oh - one other thing I just realized: using the above config would mean that you can't use a machine's /etc/group (or /etc/password) to override any info returned from an LDAP query.  I suspect that's probably why the original order (group: files ldap) is suggested.

Any thoughts on this approach?

thanks!

----------

## VoVaN

dahoste, I think if you would go for the solution #1 only the way, is adjusting /sbin/rc file in order to be sure that network interface is ready before starting udev... I would use initramfs and setup network in /init, so it will be initialize even before init. It looks useful as well if you're using bootsplash already as it's initramfs based and you have adjust settings. I'm using this scenario for diskless computers with LDAP, but I'm keeping all info needed for udev locally. For more details about my setum see https://forums.gentoo.org/viewtopic-t-434302-highlight-aoe+initramfs.html

----------

## locovaca

I'm currently playing around with my servers to see the optimal configuration for me.  On one of the peripheral (Openldap not running on it) I have the kernel getting the IP Address during boot.  However, I have to maintain a local account on my laptop as , when I travel, it obviously can't contact the LDAP server to authenticate.  

The problem is that it's all or nothing- unless I wanted to make a local account with a different name, I can't specify to use LDAP authentication when connected to the network and non-when not without hacking out some bash scripts to replace nsswitch.conf.  I've considered running an LDAP server locally on each computer as well and use slurpd to replicate from my main, master server, but then that's not up before udev so we're back to that problem.  

But again, none of this addresses the nested (global vs. local) group problem.  As dahoste said, if that's not the purpose of LDAP, then what is?  For example, in AD/Windows world, Domain Admins are automatically Admins on any domain workstation/server.  Now, I'm not expecting that much automation, but I would expect to be able to give 35 admins wheel access without having to maintain a master group file and redistribute every time an admin joined/left the group.  It certainly adds another layer to administration that gets more complex the more workstations you add (and the more possible /etc/group configurations you could have).

My goal is to replace AD  and reproduce as much of it as I can.  Cached authentication (which my idea of local LDAP, while excessive, would probably work), n levels of groups (mixed between local and global)- those things matter quite a bit!  And, if they can't be done with LDAP... what is the solution?

----------

## bunder

 *locovaca wrote:*   

> I'm currently playing around with my servers to see the optimal configuration for me.  On one of the peripheral (Openldap not running on it) I have the kernel getting the IP Address during boot.  However, I have to maintain a local account on my laptop as , when I travel, it obviously can't contact the LDAP server to authenticate.  
> 
> The problem is that it's all or nothing- unless I wanted to make a local account with a different name, I can't specify to use LDAP authentication when connected to the network and non-when not without hacking out some bash scripts to replace nsswitch.conf.

 

So duplicate the user into your own /etc/passwd / group files.  Also you don't need a script to switch between ldap and non-ldap setups.  when you boot up when it says press I, push it and select exit to shell.  Change the nsswitch, exit the shell and continue booting.  when you've booted, you can change the files back.

cheers

----------

## locovaca

 *bunder wrote:*   

> 
> 
> So duplicate the user into your own /etc/passwd / group files.  
> 
> 

 

Then what happens when accounts get out of sync- if I change my global password then I have to update the local file, which defeats the purpose of a global authentication system.  

 *bunder wrote:*   

> 
> 
> Also you don't need a script to switch between ldap and non-ldap setups.  when you boot up when it says press I, push it and select exit to shell.  Change the nsswitch, exit the shell and continue booting.  when you've booted, you can change the files back.
> 
> cheers

 

While this technically works, this is a little too intensive for a majority of my users.  :Smile: 

The idea is to make my Linux installs as friendly as Windows.  There's no point in writing bash scripts up the wazoo if there's something better than LDAP.  Having a rather un-technical user make a decision on if they can contact the LDAP server or not, interrupt the boot sequence, then run some commands or a script (which requires root access, thus wheel access, thus you MUST have a local wheel group which we are trying to avoid if possible!), is out of the question.  And, if there's nothing better, then someone else MUST have gone through this because it seems all-to-common.

----------

## bunder

 *locovaca wrote:*   

>  *bunder wrote:*   
> 
> So duplicate the user into your own /etc/passwd / group files.  
> 
>  
> ...

 

usually you only need to sync /etc/group, at least in my experience.  adding a user to wheel in ldap didn't seem to allow me to su until i put the user into the group file.

i was reading in another thread about putting dhcp into the kernel, which would allow the network interface to be up as early as possible preventing ldap-related boot slowdowns... i haven't tried it, but it sounds promising.

cheers

----------

