Live data from Hacker News

Salt: Like Puppet, Except It Doesn’t Suck

blog.smartbear.com

251–260 of 274 posts

Re: Salt: Like Puppet, Except It Doesn’t Suck

#251
post #223

Earlier quoted context omitted.

It seems that 1) You have not dealt with large enough data, since you advocate just creating VM copies or snapshots. Try that on 10 or 100 TB of data. 2) You haven't thought about what and how those initial CSIE configurations are generated. Do you hand tweak everything, make && make install onto a particular installation of a particular OS all the software then just spawn those? It seems that should go to the dustbi…

you advocate just creating VM copies or snapshots. Try that on 10 or 100 TB of data There are many ways to take an image of an environment, not only VMs or snapshots. But if your system image includes 10-100TB, it could be argued that the problem of size really lies in earlier design decisions. You haven't thought about what and how those initial CSIE configurations are generated. On the contrary, generation should b…

> if your system image includes 10-100TB, it could be argued that the problem of size really lies in earlier design decisions.

Without disagreeing with your conclusion about the design process, it's useful to note that this situation simply isn't a problem for a conventional configuration management tool.

> On the contrary, generation should be automated.

One could argue that Puppet and Chef are ideal tools for performing that automation.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#252
post #196

Earlier quoted context omitted.

> This is what I meant by configuration drift. I forgot to mention this before, it is strange that you credit yourself with defining this term when it has been well defined for some time in ops. > More importantly, PFCTs enable and to some extent encourage modification of generated environments remotely, en-masse, without any significant capacity to ensure that individual instances within a group have not subtly shif…

"Immutable Server" seems like an oxymoron. Frequent refreshes are great, but your system is only doing something useful once it has "mutated" (i.e. accepted external data to operate on). The tradeoff system designers have to make is frequency of refreshes vs the cost of transferring interesting data to that server. Seems like your organization has just coined a new synonym for "gold master"

You can do it the other way round: have your data on direct-attached storage and network mount the root filesystem.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#253

Earlier quoted context omitted.

CSIE sounds great for a certain class of users. For me, however, it seems like it would be impossible. My team has to manage 10,000+ physical servers. We can't possibly wipe and provision from scratch every time we change configurations. In other words, if your servers are ON Amazon's platform, use CSIE. If you are RUNNING the Amazon servers, you need something else.

PXE boot is a great way to automatically re-provision physical servers.

If one of your complaints about configuration management systems was that they're slow, this is not the answer.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#254

Earlier quoted context omitted.

SSH is secure. The configuration of SSH, and the system that it's running on, its operating system, accounts and applications, might not be. It all comes down to how secure you want to be. There is a longer conversation that can be had to explain this. There are lots of mistakes one can make in managing a box with SSH that will easily lead to an account compromise, not even considering universal methods like 0-days,…

This just sounds like FUD. What makes whatever vpn software or "hardware" you're using better, or harder to mismanage, than OpenSSH. Something concrete please..

Keep in mind that most of the time, penetration happens because of operator error. Most common vulnerabilities are patchable or preventable in one way or another.

SSH contains many features which may make it vulnerable to attack. If configured incorrectly it will expose the machine, and depending on the machine this could expose a big portion of your network. I could write 5 pages on abusing SSH options for entry.

After SSH itself, there's the operating system. PAM has had holes for years and yet people everywhere rely on it for their authentication. Their OS might not be patched up, and probably has had no hardening of the kernel or userland against typical attacks.

The box is also probably on a shared network segment, meaning your attack surface is now a whole lot bigger: many machines and user sessions to hijack.

On the other hand, a VPN on a separate network segment provides protection for all these components, if you do it right. Usually the VPN should be an appliance of some kind, with service by a company who spends its time hardening the device and patching the software regularly. This makes sure the configuration of the software is correct, the system itself is resistant to attack, and authentication/authorization is managed outside the machine, which means limited access to the network for specific user sessions.

You cut the attack surface down by separating their network access away from a specific network and shared server. You also cut down on mistakes in managing said service because everything is a managed service, not a config file edited by one or more admins.

Also consider that SSH just doesn't have the features of a standard VPN that make it useful on a network level. Its tunneling feature is a joke; using ppp is the closest way to provide an actual remote vpn tunnel. Persistent connections are nonexistent. Network access control is nonexistent. Pushing routing, DNS and other network information is nonexistent. It is not meant to be a network-level tunnel, it's a single-session user tunnel for remote hosts, not networks. The extra options and features for more network access are hacks.

If you wanted to emulate a VPN using SSH, you could:

  * put a machine on a separate network segment
  * apply Grsec and other patches
  * harden the filesystem and stop all services other than SSH
  * disable user logins
  * disable all features of ssh
  * enable all strict ciphers, modes, options for ssh
  * add ssh config options to run pppd as soon as the user logs in
  * configure PAM to use RADIUS or SQL to auth with a remote database
  * use iptables and some kind of packet-marking module to track network sessions by user id
  * create a custom application that configures iptables rules per user
  * constantly update all patches
That would get you close to a real, normal VPN. Unfortunately, it's also a metric shit-ton more code and services to do the same thing as one service, and considering you'd be setting it up for the first time, there's probably gonna be some mistakes made.

SSH is not a VPN, and a VPN is not SSH. Like I said before, if you're just remoting into your personal box, I don't think you'll have issues, because nobody would care to break in. Bigger networks are a different matter.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#255
post #160

Earlier quoted context omitted.

Computer systems in the wild are stochastic - that's the fundamental assumption that leads to the design of tools that you call "PFCTs" here. This type of design leads to tooling which is relatively slow and often obtuse, but there are well-reasoned (and researched, start maybe with [1]) assumptions behind those tools. In particular: systems modeled by these tools are designed to run for years, include a large variet…

Computer systems in the wild are stochastic Try telling a client who wants 100% uptime that! Computer systems can be many things - it could be (and probably has been) argued that we as progammers fundementally aim to reduce random qualities and increase stability within our programs. there are well-reasoned (and researched) assumptions behind these tools I can see where PFCT's came from. I took a look at the paper (w…

>> Computer systems in the wild are stochastic

> Try telling a client who wants 100% uptime that!

A client who asks for 100% uptime will end up disappointed.

> We attempt to remove an entire class of issues related to deployment environment by changing our platform engagement paradigm to one that is less procedural/'stochastic' to something that is more atomic/reliable.

I'm afraid I don't get the difference. You've argued that configuration drift is a major problem with configuration management tools, but I don't see how any solution based around deploying full system images couldn't also apply to stepped upgrades applied by CM. Allowing config changes to be made directly to production servers instead of going via the deployment tool is the problem there, not anything fundamental to which deployment style has been used.

With puppet configuration (for instance) in version control, it's not a problem to test against a known, versioned, identifiable and auditable environment. As long as you're not applying config changes to live servers, the switchover to a new environment is equally atomic either way.

Given that the trade-off is building, storing and deploying full system images, I don't think there's a fundamental advantage to full-system deployment that can't be matched by a thought-out application of conventional configuration management.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#256
post #223

Earlier quoted context omitted.

It seems that 1) You have not dealt with large enough data, since you advocate just creating VM copies or snapshots. Try that on 10 or 100 TB of data. 2) You haven't thought about what and how those initial CSIE configurations are generated. Do you hand tweak everything, make && make install onto a particular installation of a particular OS all the software then just spawn those? It seems that should go to the dustbi…

you advocate just creating VM copies or snapshots. Try that on 10 or 100 TB of data There are many ways to take an image of an environment, not only VMs or snapshots. But if your system image includes 10-100TB, it could be argued that the problem of size really lies in earlier design decisions. You haven't thought about what and how those initial CSIE configurations are generated. On the contrary, generation should b…

> In the same way that a service to deploy to such an environment is maintained as an individual service project, the environment itself is similarly maintained, labelled, tested and versioned as a platform definition.

A mix of two. Use salt/puppet/chef etc to bootstrap a known OS base image to a stable production platform VM for example. Then spawn clones of that. I would do that and I see how it would work very well with testing.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#257

Earlier quoted context omitted.

This just sounds like FUD. What makes whatever vpn software or "hardware" you're using better, or harder to mismanage, than OpenSSH. Something concrete please..

Keep in mind that most of the time, penetration happens because of operator error. Most common vulnerabilities are patchable or preventable in one way or another. SSH contains many features which may make it vulnerable to attack. If configured incorrectly it will expose the machine, and depending on the machine this could expose a big portion of your network. I could write 5 pages on abusing SSH options for entry. Af…

Keep in mind what we are discussing here, a lot of that was off topic. I never said ssh and VPN is the same, or the ssh should replace VPN, it's the other way around.

Now, it seems like you're saying that vpn is more secure because it's often separated and more hardened. I guess that kind of makes sense, but isn't that really an argument for a single, hardened entry-point into the network? Could be anything.. And of course, this has its drawbacks as well =|

Re: Salt: Like Puppet, Except It Doesn’t Suck

#258

Earlier quoted context omitted.

Keep in mind that most of the time, penetration happens because of operator error. Most common vulnerabilities are patchable or preventable in one way or another. SSH contains many features which may make it vulnerable to attack. If configured incorrectly it will expose the machine, and depending on the machine this could expose a big portion of your network. I could write 5 pages on abusing SSH options for entry. Af…

Keep in mind what we are discussing here, a lot of that was off topic. I never said ssh and VPN is the same, or the ssh should replace VPN, it's the other way around. Now, it seems like you're saying that vpn is more secure because it's often separated and more hardened. I guess that kind of makes sense, but isn't that really an argument for a single, hardened entry-point into the network? Could be anything.. And of…

It's an argument for better network and host security.

If you have a building you want to secure, you could make a lobby with a man-trap and a guard at the front desk and security keys for the lobby and on each floor. Or you could put a padlock on the back door. You decide whether it's worth the risk.

In terms of what to use to remote into your private VPS, just use SSH. A VPN would be overkill.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#259
post #256

Earlier quoted context omitted.

you advocate just creating VM copies or snapshots. Try that on 10 or 100 TB of data There are many ways to take an image of an environment, not only VMs or snapshots. But if your system image includes 10-100TB, it could be argued that the problem of size really lies in earlier design decisions. You haven't thought about what and how those initial CSIE configurations are generated. On the contrary, generation should b…

> In the same way that a service to deploy to such an environment is maintained as an individual service project, the environment itself is similarly maintained, labelled, tested and versioned as a platform definition. A mix of two. Use salt/puppet/chef etc to bootstrap a known OS base image to a stable production platform VM for example. Then spawn clones of that. I would do that and I see how it would work very wel…

Agreed. I think PFCTs are good for generative part, not for the rest. They should be part of a build process really, not live infrastructure.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#260

Earlier quoted context omitted.

you advocate just creating VM copies or snapshots. Try that on 10 or 100 TB of data There are many ways to take an image of an environment, not only VMs or snapshots. But if your system image includes 10-100TB, it could be argued that the problem of size really lies in earlier design decisions. You haven't thought about what and how those initial CSIE configurations are generated. On the contrary, generation should b…

> if your system image includes 10-100TB, it could be argued that the problem of size really lies in earlier design decisions. Without disagreeing with your conclusion about the design process, it's useful to note that this situation simply isn't a problem for a conventional configuration management tool. > On the contrary, generation should be automated. One could argue that Puppet and Chef are ideal tools for perfo…

this situation simply isn't a problem for a conventional configuration management tool

Sure. But loads of other stuff is. The weight of tradeoffs is clearly against PFCTs here.

One could argue that Puppet and Chef are ideal tools for performing that automation.

Absolutely agree - but not within live infrastructure. Only build.

Post reply on HN