
Why Mongrel2 Doesn't Use INI Files (Zed Shaw) - clyfe
http://sheddingbikes.com/posts/1286700843.html
======
tef_
Using the sqlite db as the canonical configuration is a nice idea, but reminds
me of the fun of bind, editing one file to re-generate another. It is as if he
is ignoring the advice in his older post about making software usable.

Instead of having a simple text format that is the configuration, he
encourages everyone to write their own. I can imagine the fun now on a mailing
list - debugging n+1 languages to start a webserver.

When you deploy, do you deploy the sqlite database file or the script that
generates it? Does the daemon check if the db is out of date on startup? Does
the script clear the existing db when it runs? Does it have merge logic? How
do you keep them in sync?

'But it's powerful' I hear you cry, but my retort is simply 'it is effort to
maintain, deploy and configure'. It smacks of: here is a bus port, go build
yourself a keyboard. This sort of toolsmithery is what brings us delights like
autoconf.

A simple change would improve things a lot, whilst maintaining the flexibility
he craves:

instead of 'generate a config file' with your tool and hand it off to mongrel,
the tool you write is part of mongrel.

You write a script called /etc/mongrel/makeconfig, that takes one argument,
the name of the mongrel settings database. When mongrel starts, it invokes
makeconfig to build the database.

You can provide a bunch of trivial makeconfig scripts as defaults, including a
shell script that just runs a bunch of sqlite statements.

~~~
zedshaw
> Instead of having a simple text format that is the configuration, he
> encourages everyone to write their own.

Uh no, you obviously didn't read the article where at the end I show you the
default format we provide to you in m2sh. I think before you go waxing
poetical about something you should learn more about it.

And it's not powerful, it's simple. Take a look at the code that loads the
configuration in mongrel2 from sqlite, and compare that to similar C code
(also written by me) in the m2sh source to just parse a config file. Code
doesn't lie and in this case, parsing a config is a hell of a lot harder than
just loading it out of a sqlite file.

~~~
gaius
_parsing a config is a hell of a lot harder than just loading it out of a
sqlite file_

Is there really no library for that? </rhetorical> The usual INI file format
has been unchanged since the 80s!

    
    
        [section1]
        param1=value1
        param2=value2
        ; this is a comment
        [section2]
        param3=value3
    

And the reason it's stuck around for so long, on every platform you can think
of, is it works, it's bulletproof, and everyone understands it at a glance.
Anyone can come up with their own scheme, then you end up how it is Javaland
right now, where the "application" is just a runtime for the application
written in a custom one-off language which is the 10,000-line XML
configuration...

Anyway, the people who get called at 3am when production is down won't thank
you for introducing yet another config file format.

------
tptacek
Bad call. The canonical version of the server configuration doesn't play nice
with version control, and so staff has to work with a facsimile and hope that
nobody makes out-of-process changes.

(INI files though? What year is it?)

~~~
yummyfajitas
To get a canonical server configuration in raw text:

    
    
        $ echo '.dump' | sqlite3 mongrel2conf.sqlite > mongrel2conf.human_readable
        $ git add mongrel2conf.human_readable
        $ git commit -m "Added mongrel2 configuration"
    

Then type the following before invoking mongrel2:

    
    
        $ rm mongrel2conf.sqlite
        $ cat mongrel2conf.human_readable > sqlite mongrel2conf.sqlite
    

I agree with you - I prefer a human readable/git friendly config file. That's
why I invested 10 minutes coming up with this solution and putting it into
run_mongrel2.sh.

[edit: earlier version of this post was unnecessarily snarky.]

~~~
mechanical_fish
Congratulations, you have invented the "facsimile" that tptacek spoke of.
Because your "canonical" dump file is just a dump file. At any given moment
your server cannot be guaranteed to be in a configuration that is specified by
your dump file, or by any version of your dump file. Why? Because the server
exposes a tempting non-file-based interface to its internal state, and people
who are trying to fix the servers at three in the morning will tend to use
this to make "out-of-process changes".

If the server is broken, do you dare to naively overwrite its configuration
with the version that is in git? The general answer is "no". Because two weeks
ago somebody did an INSERT into the server's internal database to make
Customer X's site work, and afterwords they didn't take time to properly dump
the config and commit the dump to git. Because it was 3AM, and the edit was
only one of seventeen switches that they were desperately flipping, and they
just forgot. When you restart the server that config setting will be lost and
the customer will crash and you will spend _hours_ trying to recapture the
lost state of the server.

You can prevent all this by making it difficult or impossible to alter the
server config without altering the config file. But then why did we bother
exposing the non-file-based interface in the first place?

~~~
zedshaw
> At any given moment your server cannot be guaranteed to be in a
> configuration that is specified by your dump file, or by any version of your
> dump file.

It's a database, and one that's used by the entire world to reliably store
data guaranteed. So this is just false on technical merits.

> Why? Because the server exposes a tempting non-file-based interface to its
> internal state, and people who are trying to fix the servers at three in the
> morning will tend to use this to make "out-of-process changes".

Yet, you say people store things in version control. You have the exact same
problem then. People can go and make changes out of band that aren't in
version control and forget about them. Happens all the time, and that's a
people problem.

What you seem to not understand is that you just need to take people out of
the equation. Automation is the future of operations, and a system that allows
any programming language with sqlite3 bindings manage the config is going to
help with automation.

Once you don't have humans logging onto machines like it's the 90's then
you've actually solved the problem. A config file won't do that.

~~~
tptacek
Your last sentence is hard to argue with, but it's worth pointing out that
there's a cost to designing systems as if the universe you want to live in is
the universe we actually live in. Let's call it "the Bernstein tax".

~~~
zedshaw
Ah the old DJB canard. I will counter your DJB with Alan Kay who's work
inspired and/or created a huge amount of our modern technological world.

~~~
tptacek
Huh? I have no idea what this is intended to mean.

For what it's worth: I'm an ardent admirer of Bernstein, and happily pay the
Bernstein tax on my systems. All I'm saying is that I recognize that I'm
paying it.

~~~
zedshaw
Whenever someone wants to shoot down a new system that is weird, they pull out
djb. "DJB did this thing with qmail and everyone hated it, but he wanted it
his way and that's why nobody uses qmail."

It's another fear buzzword for sysadmins. It's effectively saying, "If you use
Mongrel2 then it'll be like qmail. BEWARE!"

~~~
tptacek
If Mongrel2 was like qmail, it would in fact be very likely that I _would_ use
it. If you think I'm making up my admiration for Bernstein's work for the sake
of argument, here's what 1 minute of Google searching turns up:

<http://news.ycombinator.com/item?id=890613>
<http://news.ycombinator.com/item?id=890558>

(These are a year old).

Not myself being a sysadmin, I couldn't tell you what the fear buttons are. I
had that job in '96-'97 (the same time period where I read qmail, which I
deployed in early beta versions at the rather popular ISP that employed me,
because I love qmail), became a developer, and never looked back.

~~~
danudey
As a sysadmin for about ten years, this argument makes no sense to me.

Zed has created a new, flexible configuration method using sqlite, which lets
me easily automate changes to the web server configuration. If version control
is an issue, I can easily automate taking a human-readable, source-
controllable dump of the database however often is reasonable.

Bernstein, on the other hand, decided that everything about the UNIX system
was wrong, and built his system around what he asserted was a better way. All
of qmail went into /var/qmail, which meant you had to either symlink
everything in place anyway or add it to your $PATH, which caused unnecessary
confusion.

He encouraged a different (non-human-readable) timestamp for log files
(<http://cr.yp.to/libtai/tai64.html>), making it a huge hassle to take a quick
glance through your log files for something without piping it through at least
one extra process.

While we're talking about config files, he also used one config file for every
variable (allowed hosts, virtual domains, etc), meaning that checking to make
sure you configured something right involved cat'ing all kinds of files back
and forth and scrolling up and down in your terminal.

He designed the qmail build process to hard-code the user IDs into the
binaries, meaning you couldn't move a compiled version of qmail from one
server to another unless all their UIDs/GIDs were identical. He also made
qmail use inode numbers as file names for messages in the mail queue, meaning
you couldn't move a queue from one server to another without renumbering each
file.

Finally, he prevented people from shipping modified copies of his source code,
meaning that adding any new features to qmail required patches, with a very
significant chance that two patches for different features would interact in
unexpected or inconsistent ways. It also meant that if you didn't have the
original source tree and wanted to add one single feature (or even change the
UIDs qmail ran under) there was a significant chance that you would lose
features and/or your config would break.

Presumably this last rule was put in place to prevent people from fixing all
the brain damage that went into qmail's ridiculous design. It caused nothing
but massive headaches, and linux distributions had to jump through hoops to
provide qmail as a package, since one single change to the source required the
installer to download, compile, and install it for you.

qmail was a system administrator's nightmare because DJB had in his head what
he believed to be a much better way to manage software on a UNIX system, and
he went out of his way to make his software use that and force people to deal
with it if he wanted to use that software (making qmail open source for most
of its lifetime). The problem is that that might well have been a great
system, if everything was using it, but since no one but him used his wildly
varied system it just made qmail a headache. For as long as sendmail was the
only alternative, it was a headache worth dealing with, but once Postfix came
along most (open-minded) sysadmins jumped ship at the first opportunity.

Qmail is horrid, non-free software, but, like Windows, it was horrid, non-free
software we all had to deal with for a long time. Now there are other, better
options.

So I'll reiterate: qmail was a horrible mess that made my life, as a system
administrator, a huge hassle. Mongrel2 and its DB config file, on the other
hand, are ideas I'm ridiculously excited about, and can't wait to put into
production, because the flexibility and power available in this sort of config
philosophy are things I can do a great deal with.

Don't compare Zed to DJB. DJB looked down his nose at anyone who didn't like
his pure, pristine system, and if you didn't like it, too bad for you. Zed, on
the other hand, has gone out of his way to make his software work with
whatever workflows we, as sysadmins, need to implement. That's worth some high
praise, as far as I'm concerned.

~~~
tptacek
I skimmed this briefly, saw the sentence "qmail is horrid, non-free software",
and didn't bother to read closely, knowing that it was written by someone who
hasn't even taken the time to learn that qmail is in the public domain. You
probably aren't even engaging the argument, which does not revolve around
Bernstein's software being bad.

------
nivertech
I did opposite in large Windows-based real-time algorithmic system with tens
of thousands of parameters. The parameters were stored in MS-SQL database,
under complex schema. For each branch and version, each developer were adding
new parameters, so after merges or upgrades it quickly become parameters hell.

I changed the parameters storage implementation to use CSV files, instead of
MS-SQL, while external API did't changed. Now we were able to add .CSV files
to the source control and parameters were versioned and automatically merged.
Additional bonus - you can edit .CSV files in Excel ;)

~~~
zedshaw
I don't think it's a valid comparison between your large data set and my
configuration storage, but cool that you went simpler and got more out of it.

------
telemachos
No opinion one way or another about how Mongrel2 handles configuration, but
are INI files really "the fad today"? Just strikes me as an odd insult for
something so old. (I don't work with Python, so maybe that's the faddish part
of all this?)

~~~
maximilianburke
A technology doesn't have to be recent to still be applicable. INI files have
been around a long time but they are a well understood mechanism for storing
confuguration settings and have mature, well debugged, components for handling
them. Not that I don't think that sqlite isn't mature but it seems like
overkill for storing simple configuration settings.

~~~
zedshaw
I usually find that when people request something weird, it's because they
have a "special sauce" idea they want to implement and not tell me about.

As for sqlite3 being overkill, go check out the code for loading the config
with sqlite, and for just _parsing_ the config in m2sh. Parsing is way harder
and more overkill than just querying a db.

------
andrewvc
I like the SQLite config.

SQLite seems like more of a PITA for some cases, but when using something like
chef to configure an instance, SQLite makes more sense than using something
like sed to mangle a config file.

Now, yes, you can define a whole config file in a template, but sometimes you
need to have a separate recipe that makes a change to an existing config (I'm
looking at you engineyard), and for that, we must unfortunately resort to sed.

~~~
zedshaw
Exactly. With m2sh the regular small usage case is very easy, and you get tons
of capabilities other servers don't have. It's not preventing you from working
how you work now, just gives one more step.

But, for everyone else, and the future of operations, this kind of
configuration storage is insanely useful. The idea that we could point
mongrel2 at a redis store in the future and have the 1000s of servers some
companies put out automatically update their configs in realtime is just sexy
as hell.

~~~
wjlroe
That's pretty much what we do at our company (albeit with Riak and it's not
mongrel2) - we have x servers with shared config and they all need to get that
config on startup. I shudder to remember the early days of running sed on
multiple configuration files on multiple servers using parallel-ssh.

~~~
zedshaw
Hey, you live in SF? Can I pick your brain sometime?

~~~
wjlroe
I'm afraid not - London. But go ahead.

------
clyfe
I hate config files, having written a software tool GUI to configure lots of
daemons that traditionally use config files.

The steps, in general, were parse-modify-overwrite, a real hassle considering
the diversity of grammars each daemon employs - following the make your own
parser mantra.

I welcome Zed's initiative of using sqlite, making a configuration GUI tool
for it would be a breeze.

------
thefreshteapot
For a simple site, this maybe overkill.

Yet running a development setup on a VM and having live setups. ( A little bit
like that the deviant guys wrote about

<http://news.ycombinator.com/item?id=1769637> )

I can see sqlite data being very handy.

You could give each their own respective id and then just pull out all the
records for them.

~~~
zedshaw
I think you win a prize for seeing into the future.

------
yatsyk
I've not found answer to question why mongrel2 doesn't use ini files..

It's not so hard to generate sqlite file but it is even easier to generate
ini, yaml, json or xml if you don't like particular ini format. And you can
manage these files by git/svn and config loader could show you line with error
if loading fails.

~~~
zedshaw
It's really hard to load those in C and keep the dependencies and bloat down.

~~~
yatsyk
There are number of json, yaml libraries for c. SQLite is portable for sure,
but json, yaml parsers are usually consist of few files without any
dependencies.

------
nivertech
Why limit yourself to sqllite? This is so old school!

Why not use some NoSQL distributed key/value store? [1]

With simple map/reduce you will be able to generate INI files or any other
format you want ;)

[1] Full disclosure: this is what I doing in my new project

~~~
zedshaw
A couple people have mentioned this, and really I'll tell you a little secret:

The config loading in Mongrel2 is all abstracted away and could support
anything. I haven't done anything explicitly to let you write a "config load
module" but it'd be possible. In theory, since the design kept this MVC idea,
you could configure out of a config file, redis, couchdb, really anything you
need to get your ops mojo working.

I could have easily just went with a config file as the default setup instead
of sqlite3, but then where would all the FUD slingers and bikeshedders go to
waste their energy? :-)

------
pablohoffman
Is it me, or Zed is starting to get annoyed at the Python community now?. I
wonder when he'll write "Python is a Ghetto".

~~~
danudey
I haven't seen the Python community complaining about the config methodology.
It usually just seems to be the people who can't understand new things that
complain about change. As someone who would be managing this in production, I
welcome it.

------
mfukar
I suppose the next question will be "But Zed, why _sqlite3_?".

Good luck. :-)

~~~
zedshaw
Already get those. There's folks who want to use redis, couchdb, just about
anything that can store configurations.

I think the thing most existing sysadmins don't get is that this is written
for people who have to manage mongrel2 servers in a modern way. It doesn't
prevent you from doing your usual manual ssh work, but it's aimed at the
future where people won't be doing that so much.

It's kind of sad, because I want sysadmins to learn to code so bad, and I even
wrote a book so they could learn it, and have helped tons of them get better
jobs, yet they still resist awesome features like this. They're really just
holding themselves back by not realizing automation and code are their future.

~~~
danudey
I don't mean to nitpick, but the sysadmins you're talking about are the _bad_
sysadmins (or maybe just _mediocre_ sysadmins). Any sysadmin worth his salt
knows that when you automate something, you only have to do it once, and you
remove any mistakes down the road. Once you have the script written and
tested, you don't have to worry about typos ever again. If it weren't for
automation, my job would be unbearable, but writing scripts to automate
systems is the most fun I get to have in my day job.

