8 ms·

TL;DR "Give a single machine root access across your entire enterprise so you don't have to manually check each machine for security updates in the vendor-suppl

TL;DR "Give a single machine root access across your entire enterprise so you don't have to manually check each machine for security updates in the vendor-supplied packages" Instead of dealing with this thing, I suggest looking at some existing system management tools like Landscape for Ubuntu or Spacewalk for CentOS/RHEL to handle managed updates... or learning how to set up a cron job to email you when security updates are available.

regecks 10y ago
Spacewalk is monolithic. It takes over packaging and licensing and various other roles. I appreciate tools like this because they are single purpose and can be easily be retrofitted to old systems. Also, yum security plugin does not work on centos because security errata are not published in repo. So you have to hack it even with spacewalk. This tool definitely meets a need in the EL ecosystem.
lamontcg 10y ago
Also, it means that one machine is going to have to be ssh'ing into every server that you have on a constant basis, which creates load on that centralized server doing computational part of the ssh connection setup and tear down and all the encryption and hmac'ing. And ssh is not designed to be a lightweight protocol, and it would be simply awful to try to maintain persistent authenticated ssh connections from the management host to every server being monitored. Really "agentless" is all a lie. The "agent" in most cases is usually sshd and you can really do better. Also for this kind of software it makes sense to simply leverage the underlying configuration management system the admin is using. If they're using chef/puppet/cfengine they push out the client over the top of an agent-based protocol. If they're using ansible or salt they'll deploy it "agentless"-ly. They've actually done more work to support this root-trust remote management model when they could have simplified the problem domain to just running their code (as an agent) and reporting on the one host its running on. It seems to have been developed to tick off a buzzword ("agentless") which could have been avoided altogether.

regecks 10y ago

Spacewalk is monolithic. It takes over packaging and licensing and various other roles. I appreciate tools like this because they are single purpose and can be easily be retrofitted to old systems. Also, yum security plugin does not work on centos because security errata are not published in repo. So you have to hack it even with spacewalk. This tool definitely meets a need in the EL ecosystem.

lamontcg 10y ago

Also, it means that one machine is going to have to be ssh'ing into every server that you have on a constant basis, which creates load on that centralized server doing computational part of the ssh connection setup and tear down and all the encryption and hmac'ing. And ssh is not designed to be a lightweight protocol, and it would be simply awful to try to maintain persistent authenticated ssh connections from the management host to every server being monitored. Really "agentless" is all a lie. The "agent" in most cases is usually sshd and you can really do better. Also for this kind of software it makes sense to simply leverage the underlying configuration management system the admin is using. If they're using chef/puppet/cfengine they push out the client over the top of an agent-based protocol. If they're using ansible or salt they'll deploy it "agentless"-ly. They've actually done more work to support this root-trust remote management model when they could have simplified the problem domain to just running their code (as an agent) and reporting on the one host its running on. It seems to have been developed to tick off a buzzword ("agentless") which could have been avoided altogether.