On Wed, 2014-04-16 at 13:40 -0500, Christopher Swingler wrote:
Hello, FreeIPA list.
We're looking to start using FreeIPA to replace our standard 389 LDAP
server on our public web server.
That public web server also houses a public wiki, which currently
authenticates against 389. We're running FreeIPA on site in our
hackerspace, but are working toward a goal of a federated login system
between all of our public and internal systems.
My plan, as it stands, is to set up a VPN link between our public web
server and our space, and set up a master-master replication between a
FreeIPA server running onsite, and another on our public web server.
The limitation I'm currently considering is that our public web server
is limited on resources - it's a VM with 1GB of RAM, on which we're
already running Apache, Mediawiki, and an IRC bot. The VM is currently
donated by a member. We're a little crunched on resources as it is,
and I fear that spinning up a full FreeIPA replica on that system may
push us over the edge of resource constraints.
Is it possible to tune FreeIPA to run with fewer resources, or
replicate only the portions of it that we really need running remotely
(just the LDAP server)?
If you avoid configureing the replica as a CA and a DNS server you'll
have only a handful of services running, namely 389ds, krb5kdc, kadmind,
httpd, ipa_memcahed.
Unless you plan on doing maintenance via the public instance, what you
could do is to manually turn off kadmind and ipa_memcached on that
instance. The managment UI would sto pworking and you wouldn't be able
to change password through that server so you may want to avoid
advertizing it on your internal newtork, but it should otherwise work
for authentication on your satellite VM.
Note however that if you are replicating just to allow for redundancy in
authentication what you could do instead is to use pam based
authentication for your applications and use sssd on the system. Using
password based authentication via pam/sssd would allow sssd to cache
password hashes of the users and allow authentication even when the VPN
link fails and would be much more lightweight.
HTH,
Simo.
--
Simo Sorce * Red Hat, Inc * New York
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
