Carlos E. R. said the following on 10/23/2008 09:03 PM:
[...]
[...] If ldap isn't in the config then it
shouldn't be needed.
Yes, I see your point.
:-) Can I "macro" this argument since I suspect it will come up again :-)
Yes, I understand that tools like 'ls' need to map from the numeric id to the human readable name. See "libacl" --> getpwnam(3) and the use of /etc/nsswitch.conf. Yes if there is a like such as
passwd; ldap files
I could see that ldap is needed. But if the 'ldap' isn't there?
Maybe the client part is a requirement, and the server part is not. I don't know if both are pulled it as requirements.
Since I've done (enterprise) systems that use YP (back when), NIS (more recently) and LDAP (even more recently) I'm sure of my assertions about what ends up being NEEDED. There may be hidden gotchas where some programmer, unaware of things like nsswitch and pam has hard coded the YP/NIS and LDAP routines into the application. Of course we all know that such people should slapped with a wet kipper until they relent.
Let me see... [thinking] ldap will be needed when an optional configuration is included in pam telling it to use ldap. I can see a problem when the ldap libraries are not included, and the user, well, the admin, changes pam configuration and forgets to install ldap. Therefore, it is pulled in as an rpm dependency.
I'm guessing, I don't know pam or ldap in detail.
I do, I have. Your problem is quite valid. In the worst case the nsswitch files and pam.d files get changed by someone like me with VI. More realistically, we learn from Microsoft. There is the "home" edition and the "enterprise" edition. The home edition has all of nsswitch and pam.d set for local files. The enterprise edition asks about NIS, LDAP or AD and loads up all of nsswitch, pam.d and the libraries. Realistically the system shouldn't have to be changed. People like me who just fu**-around ... err "experiment" are expected to either know what they are doing or learn by experimentation or pay the consequences. BTDT. Thirty years gives a lot of opportunity to turn the latter into the former. How any re-installations can you do in one day?
Once again we have the conflict between the needs of an enterprise system with full server support and and IT staff in place, and a simple "user" on a laptop or similar that doesn't have all that infrastructure behind him (or her).
I know of small places that use ldap, even at home.
I do too. Myself once upon a time. Just to prove I could. But as I grew older I decided to simplify. One workstation, lots of headless machines, ssh & certificates. Oh, bugger! (sorry) openSuse doesn't seem to want to run my .bash_profile and the 'keychain' ...
PAM is most certainly pluggable. As far as I can tell
While my syslog files have things like
kdeinit4: nss_ldap: could not search LDAP server - Server is unavailable automount[2813]: bind_ldap_anonymous: lookup(ldap): Unable to bind to the LDAP server: (default), error Can't contact LDAP server
(the latter despite there being no ldap in my /etc/nsswitch.conf!)
I don't see that error in my logs (and I don't run ldap). You must have some configuration somewhere that makes it think it should contact an ldap server; in kde4 (I seldom use kde) and in automount.
I'm trying to track that down! "cd /etc/; grep -Ri ldap *" ... But if you have any ideas ...
I don't see any corresponding entries for NIS/YP. "Obviously" the NIX/YP lookup has been implemented correctly so that ypbind and ypserv are not dependencies.
But 'ldap' is.
As far as I can make out it is because there are entries in /etc/pam.d that make ldap 'required' for all common operations.
I believe that my config does not have such entries. It is only mentioned in the comentary of "common-auth*":
Mine does. Hand edited the nsswitch, re-ran pam-config. Gone! Still some in apparmour that I need to figure out, Still some stuff in /etc/preload.d Perhaps you can advise about the latter...
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the # traditional Unix authentication mechanisms. # auth required pam_env.so auth required pam_unix2.so
That's what I have now after running pam-config. It replaced a 4-line entry that had as its last line auth required pam_ldap.o first_login
Simply deleting 'ldap-client' and the ldap libraries on a stand alone single user system such as a laptop or netbook, or for that matter a SOHO or SMB system that doesn't use ldap, will, yes, "break things".
Yes. Someone made the design decision that had my 'virgin' system with the nsswitch & pam.d needing ldap, so the dependency made sense. As I said, the installer should offer alternatives. NIS and AD authentication should be included as well as LDAP.
You will need to remove the ldap dependency from the entries in /etc/pam.d/*
I'm afraid that simply removing the lines will not affect dependencies.
I'm going to have to override YAST! But I'm going to check for other dependencies first.
Dependencies are rpms needing (saying the need) another rpms. I think that, in order to remove the ldap rpms correctly you also need to remove the pam modules that use ldap. Perhaps somebody knows how to do this, but after the tone that Mr Ruben Safir is inflicting on the thread, this will develop onto a useless flamewar and you will get few technical responses from the people who may know an answer. Sorry :-(
I've tried hard to impose a chain of reason, evidence and causality here, since that as what appeared necessary. I understand Mr Safir's frustration; many of my clients have expressed similar frustrations about many things over the years. What Mr Safir's level of technical knowledge is I'm not presuming, but when I put my mind to it I have he experience to do the forensic investigation. I was once a kernel hacker for ATnT UNIX and have installed many hundreds of *NIX of many breeds on many platforms since 1978. I've seen many permutations and any advances. The good ones survive since the Open Source world is less forgiving of stupidity. The threat of 'go elsewhere', even if not actually exercised, is a powerful one. For most of us and my of our clients the move from one Linux/UNIX GUI to another vendor's is minor.
I'm changing the subject line, in the hope of attracting someone who knows more :-)
Indeed. There's always the 'gotchas'. And when we have the all sorted out perhaps we can write up a requirement or the dependency alternatives.
I very strongly suggest that unless openSUSE 11.x (x>0) is going to be positioned as an 'enterprise' product and have installaton/configuration support to match, that the ldap depencey via the /etc/pam.d files be removed. Smaller footprint, fewer messages to syslog.
I don't have any ldap messsages in my log, going back a year.
I just hope the version I installed off the 'live' CD last weekend hasn't been zapped by one of the automatic update sources I set up !!! How might I check for that?
Interestingly enough, I can remove the modl 'pam_ldap' and yast doesn't complain about dependencies, so obviously there is some inconsistency - if 'pam_ldap' is configured into /etc/pam.d then there should be a dependency.
You have to uninstall pam_ldap...rpm. I have just tried that in Yast and it doesn't complain (I aborted, I didn't let it do it). But rememember that dependencies do not rely on config files.
Try removing (in yast package manager):
pam_ldap...rpm
Done. No dependencies. Took out "nss_ldap" a well.
yast2-ldap*rpm
YIKES! That takes out 11 items including yas2-mail, a whole pile of yast2-*-server, yast2-users, yeast2-sudo, yast2-inetd (which impacts sshd) yeas2-profile-manager, yast2-printer so I can't use CUPS to my print server and kscpm. Doing a 'search="ldap"' with on RPM "requires" show up a lot of items, "kde4-plasma-addons", "curl" and "libcurl4" but not "wget" the KDE PIM libraries, the KDE3 base libraries, "acroread" - which I find surprising - the core of "apache2" rather than the modules, "autofs", "cups", "gpg2" as well as "kde4-kgpg" Recall I warned above about programmers that had hard-coded the LDAP option in rather than going though nsswitch as a plugin? It looks like most of those are mapping user name to ID or vice-versa. They _should_ consult nsswitch and hence chose the right module. -- All generalizations are false. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org