[clug] old-school remote sys configuration/management options

[jm]

Ansible is good when you haveclient machines which you know the address
for. Running servers this is generally true. In some other situations
such as where the machines being managed may pop up on random IP address
anywhere on the Internet or are behind NAT you need an agent to call
home. For a data centre I much prefer the Ansible model though I've not
used Ansible for more than an afternoon myself. The only thing I'd
recommend is starting a second copy of sshd so that if the config gets
misconfigured (it's happened on machines I work with several times) you
have a fall back option. Then again you may just have to walk down the
corridor rather than worry about a truck roll in this situation.

Having said that I much prefer the Ansible model as you can keep the
server with all the valuable secrets secure behind a firewall and you
choose to whom it talks.

>From one stuck with Salt,

Jeff.

On 7/5/20 16:10, Chris Smart via linux wrote:
> On Thu, 7 May 2020, at 15:49, Bob Edwards via linux wrote:
>> The reason I didn't was largely influenced by:
>> https://lists.debian.org/debian-lts-announce/2020/05/msg00005.html
>> - tracked by AusCERT as:
>> "ESB-2020.1595 - [Debian] ansible: Multiple vulnerabilities"
>>
>> I was actually keeping my eye out for:
>> "ESB-2020.1607 - [Debian] salt: Multiple vulnerabilities"
>> but when I saw the slightly earlier Ansible one (without actually
>> reading it), I became further convinced that this wasn't the solution...
>> my bad.
>>
> IMO one of the cool things about Ansible is that it's agentless. So when there's a vulnerability, you just update the package on the host which is going to run the jobs and you're good to go (as opposed to having vulnerable services/agents running on each node on your network).
>
> -c
>