[ale] Managing passwd and sudoers files on multiple servers.

JD jdp at algoloma.com
Fri Aug 22 12:00:48 EDT 2014


I think the client has been working well for years on Debian and Ubuntu even
across major release differences between the clients and server.

I did see a pull request on the project in the last 24 hrs (happened to look at
the git repo), but prior to that, it was a very long time.  This assumes I was
actually looking at the correct version system - hard for me to tell for
Fedora-based stuff. I just don't have the knowledge.

On 08/22/2014 11:48 AM, Jim Kinney wrote:
> Just saw a note on the freeIPA list that the devels hope to have a server
> working by Dec in Debian unstable. No status of client support was
> mentioned.
> 
> 
> On Fri, Aug 22, 2014 at 9:25 AM, Jim Kinney <jim.kinney at gmail.com> wrote:
> 
>> I don't use Debian anywhere to test. Once I get caught up on current
>> projects, I'll set up an Ubuntu VM for IPA testing as that is the other
>> distro used internally.
>> On Aug 22, 2014 8:24 AM, "JD" <jdp at algoloma.com> wrote:
>>
>>> Sounds like NIS/NIS+.
>>>
>>> I looked a few months ago and the debian port of freeIPA seemed stalled
>>> over the
>>> 50+ different languages used in the 100+ tiny tools that make up the
>>> offering. A
>>> few of the key tools didn't work on Debian. I'm exaggerating a little,
>>> but not
>>> much.  Have things changed?
>>>
>>>
>>> On 08/22/2014 07:59 AM, Jim Kinney wrote:
>>>> Bite the bullet and look at freeIPA. It's designed to run AD out of the
>>>> workplace.
>>>> The clincher for me was the hostgroup. All users are in a primary group
>>> and
>>>> as many secondary groups as needed. Hosts are also in groups or not.
>>> User
>>>> groups of the proper type can access host groups as allowed. This can
>>> also
>>>> setup sudo capabilities by user, user group, host and host group. So a
>>>> script that runs as root that does a particular needed task can be
>>> deployed
>>>> to all systems but only accessed by allowed users on allowed hosts. Time
>>>> controls exist as well.
>>>>
>>>> Backups of freeIPA are a bit unnerving. They basically don't exist other
>>>> than turn down the service and copy all files. What is used is the multi
>>>> master replication.
>>>>
>>>> I have 2 primary masters that are department wide. There's a new group
>>> in a
>>>> remote location that has their own big server. It's a secondary master.
>>>> Masters run DNS as well as user with. So the clients in that group use
>>> that
>>>> as their primary DNS and the others as secondary. If network is flaky,
>>> they
>>>> have only a single switch between client and server. And the server
>>> stays
>>>> synchronized with the larger group.
>>>> A really nice feature if freeIPA is it can hold ssh pub keys for users.
>>> SSh
>>>> and Pam knows to check the LDAP for pub keys on login. For users, no
>>> more
>>>> key migration. If you're allowed on that machine, it just works. For
>>>> admins, if a user must be locked out, just dumping their key and locking
>>>> the account to disabled handles it.
>>>>
>>>> Yes, it's run/funded by RedHat now. Debian supports it but I found some
>>>> blockers in Ubuntu (10 I think. Not tried 12). I don't know if SUSE has
>>> a
>>>> pam/ssh compatible or not.
>>>> It works. It works very well. Active support community with developers
>>> on
>>>> the mailing list who help.
>>>>
>>>> Added bonus is dogtag is used for CA and cert management. This can
>>> provide
>>>> user certs for authenticated access to internal websites.
>>>> On Aug 22, 2014 6:58 AM, "JD" <jdp at algoloma.com> wrote:
>>>>
>>>>> On 08/22/2014 12:19 AM, Jeff Hubbs wrote:
>>>>>> On 8/21/14, 11:43 PM, JD wrote:
>>>>>>> NIS if you don't care about security.
>>>>>>>
>>>>>>> LDAP if you do.  FreeIPA is the RH answer for this - I'm jealous.
>>>>>> Agree re LDAP; if you're syncing passwd/group/sudoers files, you're
>>>>> Doing It
>>>>>> Wrong (tm).  I long advocated avoiding "X's LDAP solution" (for values
>>>>> of X to
>>>>>> include Red Hat and Microsoft) so you are motivated to keep things
>>>>> simple and
>>>>>> manageable and don't wind up in abandonwareland or experience
>>>>>> embrace/extend/extinguish.
>>>>>>
>>>>>
>>>>> So - if not puppet/ansible - then how should we be managing sudoers?
>>>>> Teach me Obiwan.
>>>>>
>>>>> Please don't say eTrust. ;)


More information about the Ale mailing list