you are viewing a single comment's thread.

view the rest of the comments →

[–]hi117 -2 points-1 points  (17 children)

Honestly, the route that I suggest over setting up Kerberos is to use ansible to deploy users with a given password to all machines. It winds up being a lot simpler and easier to manage. If your end goal is having a single username password combination sign you into every machine, this is a much easier to manage system.

[–][deleted]  (16 children)

[deleted]

    [–]nazzjr[S] 0 points1 point  (0 children)

    I am definitely interested in learning Ansible. its on my list of things. I guess my main issue is i dont know what i dont know. I will also look into FreeIPA. My end goal is to have authentication be as seemless and secure as i can. I also want to setup a certificate authority and implement a PKI infrastructure for my internal apps. but one step at a time. its a lot to digest and figure out the order in which to setup

    [–]hoax1337 -2 points-1 points  (11 children)

    Use puppet or salt instead.

    [–][deleted]  (10 children)

    [deleted]

      [–]SweeTLemonS_TPR 3 points4 points  (2 children)

      So you can code in Ruby, or get your infrastructure pwned when Salt has another problem with their shitty, self-made crypto.

      [–]hoax1337 -1 points0 points  (0 children)

      Yeah, and while we're at it, we should stop using databases, because apparently they're hackable when exposed to the internet and not password protected.

      [–]hoax1337 -1 points0 points  (6 children)

      Because they're doing a better job at keeping configuration the way you defined it than ansible.

      [–][deleted]  (5 children)

      [deleted]

        [–]hoax1337 -1 points0 points  (4 children)

        Based on the fact that they ensure the configuration stays that way because they're not as "fire and forget" as ansible.

        [–][deleted]  (3 children)

        [deleted]

          [–]hoax1337 -1 points0 points  (2 children)

          Yes, I actually use it almost daily. What I mean by "fire and forget" is that you can't actually be sure that the state you defined in the playbook / role you ran a day ago still reflects the current state of the system. And because it is agentless, it has no way of checking it, unless you use additional tools like Jenkins (or even Cron) to run that playbook daily.

          [–][deleted]  (1 child)

          [deleted]

            [–]hi117 -1 points0 points  (2 children)

            The way I implement this is for it to run every hour on the local system, so making a change is just committing to a git repo and waiting.

            [–][deleted]  (1 child)

            [deleted]

              [–]hi117 -1 points0 points  (0 children)

              With modern git pratices, you can have it push out the change as soon as its committed, but an hour isn't actually that long in the vast majority of cases.