3 ms·

> 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

by zedshaw 16y ago

> 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 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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 16y ago
        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=890613 http://news.ycombinator.com/item?id=890558 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 16y ago
        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 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.
Goladus 16y ago
A configuration management system like cfengine or puppet is probably distributing files directly from revision control. Changes made to files on the system will likely be reverted unless someone specifically disables the agent. > a system that allows any programming language with sqlite3 bindings manage the config is going to help with automation. It's just a different config language, there's nothing that inherently allows more automation. The guy writing a gui interface might find that sqlite3 more useful. The guy using puppet and erb templates will probably prefer the text file. The point of a configuration language is to provide a human interface. If you don't need the human interface then why do you expose configuration at all?

by zedshaw 16y ago

tptacek 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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=890613 http://news.ycombinator.com/item?id=890558 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 16y ago
        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 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.

Goladus 16y ago

A configuration management system like cfengine or puppet is probably distributing files directly from revision control. Changes made to files on the system will likely be reverted unless someone specifically disables the agent. > a system that allows any programming language with sqlite3 bindings manage the config is going to help with automation. It's just a different config language, there's nothing that inherently allows more automation. The guy writing a gui interface might find that sqlite3 more useful. The guy using puppet and erb templates will probably prefer the text file. The point of a configuration language is to provide a human interface. If you don't need the human interface then why do you expose configuration at all?