Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Salt: Like Puppet, Except It Doesn’t Suck

blog.smartbear.com

Post reply on HN
Print view View original

211–220 of 274 posts

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

#211

Post by antihero »

nuclear_eclipse wrote: post #203
hexedpackets wrote: post #175

Earlier quoted context omitted.

Switching SSH to any other port is a good idea as it will reduce the random attacks against it. Sure, those drive-by attacks are pretty weak and not much of a threat against a hardened configuration and the real attackers will find the new port anyway, but it reduces noise significantly. Cleaner logs are easier to parse, so the net result is that you can spot attacks that you care about much more easily.

Install fail2ban, leave ssh on port 22, and have clean logs.

If someone knows your IP, can't they spoof the packets and get you banned from your own server? Or did they solve this issue somehow already?

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

#212

Post by Goladus »

contingencies wrote: post #120
calpaterson wrote: post #115

Earlier quoted context omitted.

I think you're right that Salt/Puppet and to a lesser extent Chef take the wrong approach, but you make some confusing comments that make me suspect you might not understand what these existing approaches are about. > IMHO, the overwhelming problem with salt/cfengine/puppet style solutions (which I will refer to as 'post-facto configuration tinkerers', or PFCT's) is that they potentially accrue vast amounts of undocu…

> isn't a cleaner solution, this is almost the solution you get when you use Puppet The difference betwen deploying an instance of a stored environment and generating that environment from some prior state is the generative process, which can fail or change in unexpected ways due to network conditions and other factors. More importantly, PFCTs enable and to some extent encourage modification of generated environments…

The difference betwen deploying an instance of a stored environment and generating that environment from some prior state is the generative process, which can fail or change in unexpected ways due to network conditions and other factors.

CSIEs are still a generative process. The difference with what you call PCFT is that the generative process isn't swept under the rug and codified into a versioned image unless it's really necessary for performance reasons.

The result is that it's easy to maintain a clear distinction between machine state and human instructions. For a trivial example: a list of packages that humans decided are necessary for the system versus the final output of 'dpkg -l' after all dependencies have been resolved.

With chef/puppet/etc. the code used to generate instances represents a human-created description of what the environment is supposed to look like, with as much version-control and referenced documentation as is necessary. With a versioned-image approach, all you have is the one-dimensional history of the image in question.

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

#213

Post by nuclear_eclipse »

antihero wrote: post #211
nuclear_eclipse wrote: post #203

Earlier quoted context omitted.

Install fail2ban, leave ssh on port 22, and have clean logs.

If someone knows your IP, can't they spoof the packets and get you banned from your own server? Or did they solve this issue somehow already?

a) This was suggested as a method to combat random trolling from botnets, so this sort of response is highly unlikely unless you're already getting DDOS'd [1], and b) Fail2Ban allows you to whitelist some IP's that won't be banned, if you really need to protect against that sort of attack.

1: at which point you'd most likely need to be a lot more involved anyways, and you should most likely be running something more serious in front of your server anyways...

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

#214

Post by greenail »

antihero wrote: post #211
nuclear_eclipse wrote: post #203

Earlier quoted context omitted.

Install fail2ban, leave ssh on port 22, and have clean logs.

If someone knows your IP, can't they spoof the packets and get you banned from your own server? Or did they solve this issue somehow already?

there is a whitelist capability

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

#216

Post by anthonyb »

dzderic wrote: post #205
tptacek wrote: post #52

Earlier quoted context omitted.

Awesome. How many people have reviewed it for flaws? How many people have reviewed OpenSSH?

After finishing the Cousera crypto course, I did a quick review of their approach and found 2 issues which completely broke their authentication protocol ( https://github.com/saltstack/salt/issues/2239 & https://github.com/saltstack/salt/issues/2916 ).

Which they seemed to fix pretty quickly, mainly by migrating to keyczar.

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

#217

Post by StavrosK »

SandB0x wrote: post #48

I'm not a web developer but I have a side-project that runs on a cobbled together EC2 instance. The server state is in theory documented in a set of of shell scripts and virtualenv requirements files. I know that I should be doing this in a more robust way but whenever I try and read up on configuration management tools like Puppet and Chef, they're all described in comparative terms - Puppet does X better than Vagra…

Here's a small, concrete example I wrote to showcase ansible: http://www.stavros.io/posts/example-provisioning-and-deploym...

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

#218

Post by Goladus »

nwmcsween wrote: post #121
danudey wrote: post #83

Earlier quoted context omitted.

These tools allow you to specify a state and then specify which servers should have that state. A 'state', loosely speaking, is a collection of definitions of 'X should be Y'. For example: Package 'libapache2-mod-php' should be installed. File '/etc/apache2/sites-available/customersite' should be the contents of this file we have on the master server. File '/etc/apache2/sites-enabled/customersite' should be a symlink…

But the problem that all of the configuration managers have and also why they all suck is that the state you specify has no guarantee of being the end state. A much better alternative would be to manage state in chunks and test those chunks, e.g an http-server transaction would require responding on port 80 if not fail or roll it back. Rolling back could be using namespaces, jails, etc.

I would not say that is a reason why all configuration managers suck. The feature you'd like to see would represent a significant increase in overhead, complexity, and potential drawbacks that not everyone needs yet.

Meanwhile, a disciplined system of designing and documenting tests and rollback procedures before committing changes will accomplish this without the need for additional software.

My guess is that if you are not disciplined enough to design tests and rollback procedures on your own, then you are probably going to just switch off or work around those features if they are built into the software.

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

#219

Post by StavrosK »

halayli wrote: post #142
nodesocket wrote: post #139

Earlier quoted context omitted.

Founder of https://commando.io here. We are a web based interface for doing remote executions via SSH. Our approach is a beautiful web interface with no external dependencies (agents). Salt and Ansible are amazing, but they still have a bit of a learning curve and setup "costs". Our target market also tends to be less technically proficient, and thus not willing to dive into more robust solutions. Think cPanel for op…

My Ansible learning curve was 5 minutes.

I'm betting it would have been 2 if there were better examples. The concept is trivial to get and the reference is great, but a few more fleshed-out examples would be nice.

After having used it for a while, I adore it. One minute and one command to go from a new project to a full deployment, what more can you ask.

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

#220

Post by Goladus »

fmstephe wrote: post #110
AlexanderDhoore wrote: post #64

Earlier quoted context omitted.

I just now (past few days) started learning about this stuff. I've been doing the "Learning Puppet" tutorials [1]. The most important thing about it is that you describe the state of the server. And puppet applies it for you. It's idempotent (you might know this term from REST). You can run puppet multiple times and the end result would be the same. Normally (without config management) you would write scripts that do…

Ok, the declarative and idempotency sounds great. But consider this one use case. I want to stop a service, upgrade it to a new version, restart that service. The service is an application which I wrote that runs in apache tomcat. 1: Stop Service 2: Upgrade 3: Start Service Right now I have just made three non-declarative statements about my tomcat server. I am describing a process that runs through a series of steps…

The last web company I worked for had an app that required a little extra care and feeding to deploy, and we just didn't use configuration management for that. There were plenty of other uses for config management (changes to rewrites in httpd.conf, for example). We used bash scripts for handling deployments, which primarily relied on distributed ssh and rsync to perform upgrades. (I believe this is the fabric use case, though it didn't exist at the time and I've never used it)

The app was already documented, source-controlled, version-controlled, and tested by developers and QA. There wasn't much benefit to adding anything to the configuration management repository unless there were platform/infrastructure changes.

Post reply on HN