On 6.10.2014 20:43, Alexander Bokovoy wrote:
On Mon, 06 Oct 2014, Nordgren, Bryce L -FS wrote:
The hostname put by ipa-client-install corresponds to the server to which this
client is enrolled. You enroll with a single server, after all.
How would one enroll with multiple IPA servers? For instance, a
standard configuration for a Rocks HPC cluster is to have at least two
and usually three networks active, with different DNS zones for each.
The "public" network is "company.example.com", "private" is typically
an isolated GbE network named "local", and there's usually a fast
network for real work (Infiniband or 10GbE); let's name it "ipoib" for
IP over Infiniband. There may also be a slow 100bT network for
management.
I don't think this has anything to do with 'enroll with multiple IPA servers'.
'Enrolling a host' in IPA terms means:
1. creating a host record + Kerberos principal for host/`hostname`
2. configuring the client to provide identity information, with
host/`hostname` as an originator when talking to LDAP and other
servers.
As all IPA masters are equal and only differs in additional services
like hosting CA or DNS, a record created at one of them will be
propagated to all of others in the topology. So (1) can be done at any
accessible IPA master.
By default (2) is configured against the server used at (1). If
discovery of IPA master using SRV records was successful, SSSD will have
its configuration pointed to use _srv_ (meaning do dynamic discovery
using SRV records at run time) and using the server this host was
enrolled to as a server of last hope.
If you want to use another strategy, you are welcome to change the
generated configuration to something different.
If you have some masters that are accessible by these isolated nodes,
enroll isolated nodes against these masters. Nobody prevents you to
select your deployment strategy and manipulate configuration files
afterwards. Purpleidea's puppet module even allows you to define IPA
masters' topology right in puppet scripts, if puppet is in use.
A few machines have access to all three networks
(headnode.company.example.com, headnode.local, and headnode.ipoib).
Compute nodes have access to two (compute-0-0.local,
compute-0-0.ipoib).
Is it possible to make a single IPA instance manage the two isolated
networks (local and ipoib)? Would multiple IPA servers and multiple
enrollments be required? Once an IPA solution is defined, how does one
configure openssh/sssd/krb5 on the compute nodes such that Kerberos SSO
(and NFS server access) works regardless of which isolated network is
used for communication? Would the compute nodes' two-network
configuration be extensible to the headnode's three-network
configuration?
If you want to make IPA masters available through several interfaces,
you need to select one of that interfaces as primary and add SAN names
to the certificates (LDAP, HTTP) of that server so that any node
enrolled to this master will be able to use it. Think of those nodes as
IPA masters in the isolated network, then enroll your isolated computing
nodes to those masters.
As long as you have means to uniquely identify DNS names of all hosts
and your local IPA master can give you a ticket to a host/`hostname` of
a host in question, things will work on Kerberos level.
I agree with Alexander so I will only mention one nit from DNS's point of view:
Do not use 'local.' TLD, it is reserved for mDNS [1]. It is much better to use
name 'compute-0-0.local.company.example.com' instead of 'compute-0-0.local'.
The fact parent DNS name is in public sub-tree (company.example.com) doesn't
force you to make all children also public. The name server can have private
IP address or you can drop all queries from outside on firewall.
This approach has two benefits:
- You will not get naming conflicts when companies merge.
- Things will not break when DNSSEC validation is enabled.
Naturally you will not change host names now but it is a thing to keep in mind
for future.
Have a nice day!
[1] http://tools.ietf.org/html/rfc6762
--
Petr^2 Spacek
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
