Le mardi 05 janvier 2016 à 10:22 +0100, Niels de Vos a écrit : > On Mon, Jan 04, 2016 at 05:27:10PM +0100, Michael Scherer wrote: > > Hi, > > > > so over the holidays, I was pondering on moving to ansible from salt. > > > > So the reasons are numerous: > > > > - I am personally much more efficient with ansible than with salt > > (despite using salt for 1 year). While the 2 tools do the same basic > > stuff, there is always some difference (like user vs owner), and there > > is a totally different philosophy when it come to multiple servers > > orchestration (one example is how I do deploy freeipa on salt vs > > ansible). > > Many of us are more familiar with Ansible than Salt. It'll be easier to > get contributions from developers when Ansible is used.
Yeah, that's the point. But I also wanted to know how much people know the tools, for how long, etc, etc. > > > - Fedora is using ansible, and while we can't reuse their code that > > much, we can at least take it and adapt. > > And can ask the Fedora sysadmins for help/ideas, or discuss the general > approach of a role/task. If something in our Ansible doesn't work well > enough, they might be able to share their thoughts. Fedora Infra is > interested in Gluster and they would surely assist with some bits in > return for our help ;-) yeah, that's a issue I have with salt, not much people to discuss with ( as I converted my friends to ansible...). And while I go to the local salt meetup every time, I often ask to do stuff in a different way that the salt philosophy, or where doing things properly would requires more python code (like freeipa integration, for one) > > Now, there is a few downsides: > > > > - it mean rewriting most of the stuff we already have > > > > - it mean that we depend on sshd to be running. IE, if we screwed ssh > > config (happened in the past), we can't just use salt to fix it. > > Having ssh running, or the salt-minion, does not make much of a > difference to me. IIRC, salt-minion do not open a port, it connect to the salt-master. It can also connect in a P2P fashion, or run locally. Both tools are equally flexible on that point. But the way we use salt is the standard way, one salt-master, where each minion connect to receive order. And the point is "I deploy a new config change on openssh", who do not work on EL5, and poof, we lost the access on a server. When it did happen on salt, I just reverted the change and that's it (happened last year). In the mean time, I did add safeguard (like testing the config before a restart...), so that's less risky, but still. > > - it also mean that we will have a ssh key to connect as root on a > > server, and i am not that confortable with the idea (provided that we > > use the regular method of using ansible, ie push based) > > Or (a dedicated ansible user and) use sudo? Might make auditing a little > easier. I think its even possible to use sshd/Match on a username and > only allow certain logins from selected sources (like a management > server). yeah, making the key restricted by IP seems the best protection (it might cause some bootstrapping issues, but I guess I can fix that). About sudo, not sure what it does bring to us in term of auditing. Ansible do send everything to syslog anyway, and sshd can tell you what key was used (maybe not by default, and that's for sure less obvious to grep in log). And having ssh ansible@server + sudo without password seems the same ssh root@server regarding access granted by the key. Maybe I am missing a race condition regarding the log (ie, if someone do ssh root@server killall -9 syslog, will the connexion be logged to the remote syslog server ?) Another solution is to use ansible over salt ( https://github.com/ansible/ansible/pull/12836 ), which mean we get the benefit of both world. If we decide to switch, I would maybe start by that until we can get a more secured network setup (ie, reuse the existing salt setup, and migrate slowly). -- Michael Scherer Sysadmin, Community Infrastructure and Platform, OSAS
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Gluster-infra mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-infra
