The Chef-branded distribution is still built from the same open source repositories that the CINC project is built from; it isn't proprietary. It has an additional EULA that requires people to accept and thus [presumably] pay for.
It's basically the same model as Red Hat. Except Chef never had the market penetration and brand recognition as a trusted source that Red Hat has.
Signed, someone who worked for Chef for almost 13 years.
With Chef 11 Server, the CouchDB component is removed for PostgreSQL. RabbitMQ is still there. Opscode provides a single package with everything above libc required to run the server.
When you run this on a system, like a throwaway VM or EC2 instance, it will download the cookbooks required for this run list, which you can review what they're going to do after the synchronization step of Chef is complete. With rayburst, the cookbooks will be synchronized into /var/cache/rayburst.
"The same user exploited another vulnerability". It wasn't exactly "another vulnerability". It still had to do with the same mass attribute assignment feature just in a different place.
My point is that Rails does not take the high road of providing better, sane, secure defaults for people to build their applications.
While the proposed solutions in the issues I linked to were denied, it doesn't mean there shouldn't be some solution added to Rails. This is definitely a case of convenience favored over security.
I think it’s like .find_by_sql and .where and everywhere else Rails provides a way to write SQL fragments. You can compose strings and open yourself to SQL Injection, or you can have ActiveRecord insert sanitized parameters for you.
There’s no “vulnerability by default” in ActiveRecord’s handling of SQL snippets. There’s a right way and a wrong way. Likewise with mass assignment. There’s a right way to use it and a wrong way to use it. FWIW, I don’t use mass assignment, ever, because the “right” way offends my sensibilities by making me load up a model with authorization logic.
Rails is not vulnerable by default because Rails apps do not include mass assignment by default. It’s not like there’s a controller method called ‘update’ created if you don’t write one that uses mass assignment. You have to generate or write an update method, and if you do and you include a sql query, you have to get the sql fragments right. Likewise if you use mass assignment, you have to do attr_accessible right.
All that being said, I don’t like attr_accessible, I think it might have been brilliant at the time but a few years later I think we can revisit this problem with fresh eyes and a lot of experience as a community and do even better. Which by extension means that I don’t like mass assignment.
SO:
We probably agree that this feature should be taken out and shot, but are quibbling over which charge should be read off the indictment before giving the order to fire ;-)
> It’s not like there’s a controller method called ‘update’ created if you don’t write one that uses mass assignment. You have to generate or write an update method, and if you do and you include a sql query, you have to get the sql fragments right.
Yes, construction of raw SQL queries outside library code is a security hole. The same with writing browsers in C or C++. These bad design choices can be traced to countless security issues. The same for generating HTML using string manipulation. These are all stupid ideas, and until people realise that they're holes we will be stuck with endless security problems. And it's the coward's way out to hide behind the "sharper tools" nonsense. You don't hear chainsaw vendors wearing safety flaws as a badge of pride.
1. We are working on making the search more performance and use less memory.
2. Chef definitely does not discourage declarative configuration. Chef recipes include declarative resource for configuring your infrastructure. Since recipes are an internal ruby dsl, there may be nondeclarative code in them.
3. Chef itself doesn't have a remote trigger mechanism because the. Her run is all about configuring the local node. Nothing prevents you from using the ruby language in a recipe to hook up some kind of remote trigger though. People in the chef community are doing this with projects like Noah and Pylon.
1. I understand that, and have heard that from you guys several times. The issue is the deserialization from JSON. The monkey patch solution I've see so far stores less data, essentially white listing the attributes for search. It sort of destroys the value of search.
2. I should be more specific. Generally chef relies on the information that ohai provides, not with information enumerated by the administrator. There is a general assumption that the systems are properly configured, and chef is only furthering that, since the hosts provide most of the configuration details. (Yes, you could do stuff with data bags to address this issue.)
3. Thanks for the links. I've not seen those projects previously. I've solved the issue for myself using a much lighter weight solution.
1. Yeah, the stop-gap "solution" is to white list a number of attributes in order to reduce the data set, because in the most common use case we see, there's only a few attributes that people actually care about in the chef-client context. The node's run list, its IP address or FQDN. Really. That is the most common. For like, 90%+ of the use cases out there. Everyone has a unique snowflake and thats cool, but really, not that much.
2. There's no assumption that systems are correctly configured other than they start from a baseline configuration in the most common use case. We have worked with several customers managing existing infrastructures of running systems that had an unknown baseline and Chef was able to automated the pieces they cared about.
* Why not use transactions? (freebsd jails, linux namespaces) and allow integration testing for the applications in a given environment? Think rspec for integration testing applications and rolling back on failure.
* Why not modularize chef, right now it's a nightmare to get working, emerge makes a graph about 200 nodes long...
I plan on sometime making a puppet / chef alternative because they both seem lacking
I've looked at cfengine, bfg and others and they all miss the point of what a configuration management system should do, 1. It should be simple, 2. It should have integration testing., 3. It should be simple. None do this or even try to
To be clear, those dependencies are required for running your own open source chef server.
You can use chef without the server, as chef-solo, or let Opscode run it for you in the form of Opscode Hosted Chef. We do make it easy to install Chef Server through Chef Solo itself, or with our Ubuntu/Debian apt repository.
I never understood what kind of person/company would trust a hosted chef.
The chef databags/cookbooks tend to contain rather sensitive information (ssh-keys, passwords). Handing all that stuff over to a third-party borders on criminal negligence to me.
Actually in an upcoming release of Chef, you'll be able to do exactly that - manage Rackspace cloud nodes with the knife command-line tool. What that means is, you can launch new RS Cloud servers with knife, passing in the validation certificate and a run_list of recipes.
For EC2, Opscode provides a reference AMI with Chef pre-installed on Ubuntu 9.10 with a special configuration file that can parse EC2 metadata through Ohai to automatically validate and run a set of recipes. See:
One of Chef's benefits for managing a dynamic environments is the Search Index feature, which can be used to search for other nodes that have particular roles or attributes set. That is part of what the application cookbook does to dynamically deploy and connect with other systems running services like memcached or mysql.
As for the learning curve and getting up to speed, that varies by person.
It's basically the same model as Red Hat. Except Chef never had the market penetration and brand recognition as a trusted source that Red Hat has.
Signed, someone who worked for Chef for almost 13 years.