The users in /etc/passwd have nothing to do with the users in IPA, you can
configure them to have the same UID / GID as the users in IPA, and you can
name them the way you want (ie, just the username without the domain
suffix). This will break in interesting ways if you need to sync updates to
the nodes (think - new users, password changes, group membership changes).
You will be better off adding the nodes to the IPA domain and using sssd to
pull the identity information from the domain. You can configure a default
domain so the users from that domain do not need a domain suffix. The
latest version of sssd also allows you to login as users from any domain
without a domain suffix in most cases, see:
https://docs.pagure.org/SSSD.sssd/design_pages/shortnames.html
Importantly, sssd provides a raft of options to tune caching identity
information, so your nodes will not actually be querying the IPA server for
every lookup.
HTH,
Jatin
On Wed, Aug 2, 2017 at 7:55 AM, Chris Dagdigian via FreeIPA-users <
freeipa-users(a)lists.fedorahosted.org> wrote:
Have a strange use case - this may be a mostly sssd.conf config
question I
think ...
I've got a high performance computing grid running in AWS. The front-end
and user login nodes are managed IPA clients and things are working well
even for the complex AD topology we have with lots of child-domains and
transitive trusts to cross. I can login as "user(a)NAFTA.COMPANY.COM" just
fine ...
What I'm trying to do is avoid having to make the HPC compute nodes into
IPA clients because I expect them to auto-scale up and down in reaction to
job load and I don't want to hammer my IPA server into submission, nor do I
want to swamp the poor replication threads as they try to replicate all
that info across the IPA server fleet.
I thought I could be clever ands scrape the IPA-provided UID and GID
values and use those numbers to create local account entries on the remote
compute node fleet. The login/master nodes would be "IPA integrated" while
the compute nodes would have skeletal /etc/passwd and /etc/group files
populated with data I stole from IPA...
However it turns out Linux really hates usernames with "@" in them and
refuses to let me make accounts. So I can't recreate "
user(a)NAFTA.COMPANY.COM" on my remote compute fleet. The presence of the
"@" symbol in my user ID simply breaks on any host that is not an IPA
client.
And it turns out even Grid Engine commands won't run with "@" in the
active user name so core HPC binaries like "qrsh" and "qlogin" are
busted.
So I'm in a bit of a catch-22 situation:
- I want to avoid using IPA on my elastic compute fleet if possible to
avoid thrashing the IPA masters and replication
- However I can't fake local user accounts with matching UID/GID values on
the fleet because Linux hates the "@" character in usernames
This may be a dumb sssd.conf question but is there a way that I can
configure sssd.conf on my IPA clients to utterly and totally strip out the
long domain name from the user?
I want to map:
userA(a)NAFTA.COMPANY.COM
userB(a)EAME.COMPANY.COM
userC(a)APAC.COMAPNY.COM
To:
userA
userB
userC
.. just on my IPA enrolled HPC edge nodes I don't care if they have to
*login* using the fully qualified AD domain (that may be best anyway) but I
want the local OS to just use the short username if at all possible.
If I can get the IPA_enrolled login node to use pure short names than I
can fake those short names across the HPC cluster and I think things will
be sorted ...
Hope this makes sense! Any tips or hints appreciated. If I can't sort
this out quickly I'm probably just going to bite the bullet and script in
IPA-enroll, re-enroll and un-enroll actions into my auto-scaling stuff. I
really want to avoid that if at all possible.
Regards,
Chris
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org