CentOS - Apr 2019 - nobody:nobody

On 4/3/19 6:43 AM, mark wrote:
> On 04/02/19 20:21, Mark LaPierre wrote:
>> Hey Y'all,
>>
>> For the last week or more I've been trying to get NFS and OpenLDAP
to
>> play nice with each other.? I've pretty much worn the Google
machine
>> out trying to find a solution.? I've found several that said
"Solved"
>> but none of those solutions solved my nobody:nobody problem.
>>
>> In the past I've used NFS in conjunction with NIS to share home 
>> directories from my NFS server but I read that NIS is deprecated in 
>> favor of LDAP so, being a sucker for new ideas, I decided I would use 
>> LDAP too like the big boys do.? I think I'm regretting this
decision.
>> Now the question:
>>
>> Is there something I need to configure on the client side of the 
>> relationship that all the Google wisdom has failed to mention?? All the
> 
> I'd assume: have you edited /etc/idmapd.conf, and at least put in your 
> domain? Then started the imapd daemon?
> 
> Btw, when you go to C 7, there's no imapd daemon, but you still need to
> edit that file.
> 
>  ????mark
>> guides/tutorial/etc... talk extensively about configuring the server, 
>> many giving conflicting information, but have nothing to say about the 
>> client. I've even found a couple that talk about configuring CentOS
6
>> but contain commands found only in CentOS 7.? Makes one go hmmm?
>>
>> Here's the basic details:
>> Server:
>> CentOS 6
>> openldap-2.4.40-16.el6.i686
>> openldap-clients-2.4.40-16.el6.x86_64
>> perl-LDAP-0.40-3.el6.noarch
>> sssd-ldap-1.13.3-60.el6_10.2.x86_64
>> openldap-2.4.40-16.el6.x86_64
>> openldap-servers-2.4.40-16.el6.x86_64
>> python-ldap-2.3.10-1.el6.x86_64
>> apr-util-ldap-1.3.9-3.el6_0.1.x86_64
>> smbldap-tools-0.9.6-4.el6.noarch
>> nfs-utils-lib-1.1.5-13.el6.x86_64
>> nfs4-acl-tools-0.3.3-8.el6.x86_64
>> nfs-utils-1.2.3-78.el6_10.1.x86_64
>>
>> Client:
>> CentOS 7 KVM VM running on the server
>> sssd-ldap-1.16.2-13.el7_6.5.x86_64
>> python-ldap-2.4.15-2.el7.x86_64
>> openldap-2.4.44-21.el7_6.x86_64
>> nfs4-acl-tools-0.3.3-19.el7.x86_64
>> nfs-utils-1.3.0-0.61.el7.x86_64
>> libnfsidmap-0.25-19.el7.x86_64
>>
>> Both machines are fully updated.
>>
>> Would you like to see any of the myriad of configuration files for 
>> these applications?? Just ask and you shall receive.? Please be sure 
>> to tell me if you want the file from the server or the client hey.
>>
> 
> 
Content of idmapd.conf:
Server:
[General]
#Verbosity = 0
# The following should be set to the local NFSv4 domain name
# The default is the host's DNS domain name.
#Domain = local.domain.edu
Domain = peach.patch.mylan

Client:
[General]
#Verbosity = 0
# The following should be set to the local NFSv4 domain name
# The default is the host's DNS domain name.
#Domain = local.domain.edu
Domain = poppy.patch.mylan

Now one more question.  The imap daemon is a mail server.  How is it 
that I need a mail server running to make LDAP and NFS work?  Doesn't 
seem to make sense to me.


-- 
     _
    ?v?
   /(_)\
    ^ ^  Mark LaPierre
Registered Linux user No #267004
https://linuxcounter.net/
****

On 4/3/19 2:17 PM, Mark LaPierre wrote:
>
> Content of idmapd.conf:

As long as idmapd is *running* it typically doesn't need to be 
configured specifically.

> Now one more question.? The imap daemon is a mail server.? How is it 
> that I need a mail server running to make LDAP and NFS work?? Doesn't 
> seem to make sense to me.

idmapd is not imapd.? idmapd (aka rpc.idmapd) is a helper for NFSv4 
which should be run on the server.? It shouldn't be required on the client.

A couple of points: 1) Your original message isn't specific about the 
problem that you're seeing, but if idmapd is involved, then the problem 
isn't related to LDAP.?? NFSv4 will work the same way whether you're 
using NIS or LDAP.? Pretty much everything other than NSS and PAM will, 
in fact.? 2) I don't recommend rolling your own LDAP services.? It's 
very easy to let sensitive information leak.? Using FreeIPA for LDAP and 
KRB5 is much easier and a lot more secure.

On 03.04.19 23:17, Mark LaPierre wrote:
> Content of idmapd.conf:
> Server:
[...]
> Domain = peach.patch.mylan
> Client:
[...]
> Domain = poppy.patch.mylan
That will fail. Set both to patch.mylan.
> Now one more question.? The imap daemon is a mail server.? How is it
> that I need a mail server running to make LDAP and NFS work?? Doesn't
> seem to make sense to me.
We are talking about the idmapd, not imapd. The idmapd will map UIDs
between clients and server for NFS.

Best regards
Ulf

On 4/3/19 5:29 PM, Gordon Messmer wrote:
> On 4/3/19 2:17 PM, Mark LaPierre wrote:
>>
>> Content of idmapd.conf:
> 
> 
> As long as idmapd is *running* it typically doesn't need to be 
> configured specifically.
> 
> 
>> Now one more question.? The imap daemon is a mail server.? How is it 
>> that I need a mail server running to make LDAP and NFS work??
Doesn't
>> seem to make sense to me.
> 
> 
> idmapd is not imapd.? idmapd (aka rpc.idmapd) is a helper for NFSv4 
> which should be run on the server.? It shouldn't be required on the
client.
> 
> A couple of points: 1) Your original message isn't specific about the 
> problem that you're seeing, but if idmapd is involved, then the problem
> isn't related to LDAP.?? NFSv4 will work the same way whether
you're
> using NIS or LDAP.? Pretty much everything other than NSS and PAM will, 
> in fact.? 2) I don't recommend rolling your own LDAP services.?
It's
> very easy to let sensitive information leak.? Using FreeIPA for LDAP and 
> KRB5 is much easier and a lot more secure.
Thank you for your reply to my incompetent query.

Okay, I'm a bit dyslectic.  I see that I should have seen idmap but I 
saw imap.  I missed the "d".  That leads me to another question:

I don't see a package that contains idmapd.  When I try to install it I get:
No package idmapd available.
No package idmap available.

I don't see idmapd in the Service Configuration GUI.

rpm -qa | grep idmap
libsss_idmap-1.13.3-60.el6_10.2.x86_64

How might one install a daemon by the name idmapd on CentOS 6?

-- 
     _
    ?v?
   /(_)\
    ^ ^  Mark LaPierre
Registered Linux user No #267004
https://linuxcounter.net/
****