EDG System Administration

System Error 22:10
Call HP Support

Take out all the print cartridges and check them. Our problem was that the magenta cartridge was leaking. After cleaning up all the ink and replacing the magenta cartridge, everything worked again.

Here’s the answer I got from RedHat:

Hello,

Thank You for contacting Red Hat support.

Please note as per SLA () mail/ldap configurations are not supported for basic subscription.
http://www.redhat.com/support/service/sla/rhel4basic.html
Dovecot is compiled with –with-ldap.

Kind Regards,
Liju

——
I went to the link given and found absolutely nothing about how they won’t help support mail/ldap configurations. So, I replied with a very rude comment to that effect. And am leaning toward getting rid of our existing redhat licenses. If they’re not going to offer support, what am I paying for? There “Knowledge Base” online, searchable support database is awful. It reminds me of the joke about customer support. A person asks the customer support rep “Where am I?” and the rep replies, “You are right there.” The answer is technically correct, but is of no use to the person whatsoever. I feel that most of the info on RedHat’s Knowledge Base is like that.

The only file that I need to worry about with ldap and pam is system-auth. All the other modules call system-auth, so changes there will propagate out.

I hadn’t tried logging in graphically with a user still in /etc/passwd for a while. When I did try, I had to enter the password twice. So, I needed to figure out what in /etc/pam.d/gdm was wrong. I made the file look like this and everything works as expected:

#%PAM-1.0
auth       required     pam_env.so
auth       sufficient   pam_ldap.so
auth       sufficient   pam_unix.so shadow nullok use_first_pass
auth       required     pam_stack.so service=system-auth
auth       required     pam_nologin.so
 
account    required     pam_stack.so service=system-auth
account    sufficient   pam_ldap.so

password   required     pam_stack.so service=system-auth

session    required     pam_stack.so service=system-auth
session    optional     pam_console.so

Passwords weren’t working on ldap accounts. This was fixed by adding the following to the slapd.conf file.

access to attr=userPassword
        by self write
        by anonymous auth
        by * none

access to *
        by * read

One big problem with my idea of switching over to ldap for all users is that dovecot 0.99 does not seem to work with ldap. My ldap user is not allowed to login with imap. However, ldap accounts can forward their mail to another account. So, I could set up accounts for people and immediately put a .forward file in their home to forward mail somewhere else.

The dovecot website doesn’t have all that much info on using ldap. One file mentioned is /etc/dovecot-ldap.conf. I have no trace of this file any of my RHEL systems. So, I also think that RedHat has not compiled openldap and dovecot to do this. I put a service request into RedHat asking this.

Finally, I got everything working. I’ll have to write up a special page to outline everything that I just did. But, my MAIN problem was that I didn’t edit the /etc/pam.d/* files. I had to tell a bunch of different processes to specifically allow ldap logins. Files in /etc/pam.d that I edited:
gdm <--do init 3, init 5 to have these changes take effect login sshd xdm I'm sure that I'll have to edit more, but these got me ssh logins and console logins. Problems still to fix. Console logins require the password twice. It shouldn't do that. I also want to double-check that everything is encrypted. From the logs it looks like it is, but I want to use ethereal to watch packets to make sure. Also, don't have the ability to change the password.

I need to get ldap working. So, I’m attempting it again.

My first issue is that there was no ldap in /etc/group. I added one, since ldap in /etc/passwd was in group 55. Therefore, I created ldap group with gid 55.

Problem: When I try to start, I get this error in the log:

Mar  2 09:30:03 host slapd[23208]: sql_select option missing
Mar  2 09:30:03 host slapd[23208]: auxpropfunc error no mechanism available 
Mar  2 09:30:03 host ldap: slapd startup succeeded

But it’s not really running.

Apparently, this problem is due to the Berkeley DB that is shipped from Redhat. To fix, I should compile and install my own BerkeleyDB. Or, I should use the db that Redhat recommends, which is ldbm. I don’t expect a very large load on this ldap server, so I’ll go with ldbm for now.

It is interesting that even after the change, I still get the error messages shown above. But, slapd is running.

Note: slapd -d -1 is good for debugging