> There are some comments in the commentary below that > I believe are worthwhile for this ARC to read and > consider > as it reviews future cases. > > Darren > > -------- Original Message -------- > Subject: Re: [sysadmin-discuss] Brussels project > announcement and > request for feedback > Date: Wed, 17 Oct 2007 12:05:57 +0100 > From: Tim Bradshaw <tfb at tfeb.org> > To: Raoul.Carag at Sun.COM > CC: brussels-dev at opensolaris.org, > sysadmin-discuss at opensolaris.org > References: <4715291A.4080602 at Sun.COM> > > > ... > > Gratuitous commentary. [...] > Which brings me to the second point. > > * Configuration repositories[*]. > > dladm looks to me like a classic modern Solaris > fooadm command. It > lets you configure things, and has, somewhere, a > secret undocumented > configuration repository where it keeps persistent > data. This has > certain advantages for implementors: specifically it > has the > advantage that you don't need to document the > repository And it can > be argued that this is not a problem for users, > because the fooadm > command *is* documented, and, well, why would you > need anything else? > > This turns out to be wrong in at least two ways. > > First of all, in order to actually make the thing > usable, you have to > document, and commit to the stability of, the command > to the extent > that (some equivalent of) > > # fooadm --print-config > cf > ... > # fooadm --read-config < cf > > will work (obviously it might not actually be done > like this, but > something like this needs to work). And it needs to > work across > upgrades etc. > > Now, what is cf? Well, in fact, it's a configuration > file. And it > has a documented syntax, to which you've committed. > So, actually, > ou have not succeeded in avoiding documenting the > repository, > because you've had to document fooadm to the point at > which you have, > in fact, documented a configuration file syntax. The > only thing > you've managed to avoid doing is documenting where > the configuration > repository actually is. So you've gained basically > nothing by this. > > Secondly, because there is no documented > configuration repository, > what do users have to do? Well, they have to run the > fooadm command > at some point. Anyone with more than a few machines > (and people with > more than a few machines are almost certainly the > people you should > care about) is going to be interested in automatic > configuration of > those machines, and specifically automated > installation, via > JumpStart etc. To do this with the fooadm approach, > they will have to > do something like: > > - drop the config file they made via fooadm > --print-config onto the > machine during the JumpStart; > - arrange for the machine to run, on first boot, > fooadm --read-config > from that file. > > Note that's two operations, not one: even > superficially this is more > work than the alternative. But in fact it's much > worse than that for > two reasons: (1) that "arrange for a script to run on > first boot" is > non-trivial to do and is fraught with possibilities > for error. (2) > you're arranging for a *script* to run: that script > needs to run with > considerable privilege, and it could potentially do > anything, > including breaking the machine terminally. So that > script needs to be > vetted carefully, much more carefully than a config > file would need > to be vetted. > > (As an aside: having a documented configuration > repository also > allows the suck-the-repository-off-the-machine, > edit-with-gui, drop- > repository-back-on-machine approach I mentioned > earlier.) > > Note that I'm not arguing that the fooadm commands > should not exist > (specifically that dladm should not exist). There > are lots of > reasons for such things, because they can ensure > things happen in the > right order, check syntax, etc, etc. To give a n > unrelated example: > "passwd -l user" is much, much preferable to editing > the shadow file, > even though the syntax of the shadow file is > documented. I hate it > that I have to edit the shadow file on older Solaris > versions. > > What I am arguing is that avoiding documenting the > configuration > repository is making it significantly harder for > users (sysadmins) to > manage systems. Of course, dladm is far from alone > in this. > > Finally, I'll mention (at the same second-hand as > before) that one of > the first things people ask when presented with these > new-style-tools > is "where is the config file?". Truss will usually > tell them, and > they will almost certainly then start relying on the > configuration > file *anyway*. > > --tim > > [*] Note repository, not file. The repository > doesn't have to be a > file. it does have to be something which can be > dropped onto the > filesystem of a machine before it is booted, and > queried from the > filesystem without the machine being booted. It > could be a database > (or some entries in a database) or something (I'm > thinking of what > SMF does here.)
While I agree in principle that all system repositories or files, even /etc/path_to_inst (for which I do see a man page even on Solaris 8, btw) ought to be documented (if only for those really bad situations where you're in a major jam and the backups suck, or for forensics, or whatever), I also note the pile of disclaimers at the bottom of that man page as an example. Or, to refer to the original example, the shadow file: something obviously needs to be done to ensure it is locked properly, so that changes are serialized rather than just last save wins. Ok, so they should be documented, just in case. But loading an initial configuration by simply dropping in a new file should probably _not_ happen except during installation, orLiveUpgrade, "bare metal" restores, or maybe in single-user as an emergency. Neither should grabbing a copy of the file, since unless there is a means whereby one can be ensured at least the equivalent of a read lock while grabbing it, there's no way of being sure it's in a complete, or current, or consistent state. So unless there are mondo disclaimers that it darn well _isn't_ an interface (only something active, like a command or library interface, which can validate its input, is a safe interface, save only for the burden of compatibility with unfortunate legacy file-based specs or expectations), and unless sysadmins can actually be made to _understand_ the risks of fooling with the file (which ultimately means a fair understanding of not just steps in a task to perform, but how stuff really works, which many never really get), I don't know whether documenting it is an opportunity to put all those disclaimers out there, or whether it is just an attractive nuisance. OTOH, between truss, dtrace, most source being available, etc, it's probably silly to think that not documenting something is going to discourage unwise behavior. The problem is, if you document but add disclaimers, in the end you almost have to spell out why/when it is dangerous to modify the file, what the limitations of looking at the file are, etc. As little as I like the idea of a "registry" or overall configuration repository, the one thing I might like is if it had a capability of snapshotting the whole thing or sensible/consistent subsets, and saving that to or reloading it from an external, documented, and if not stable at least "evolving" textual format (preferably not XML, although that wouldn't kill me). That way, one could debug, use it as a hook for multi-system configuration management, etc; while there would still be validation that could take place whether making individual changes or pushing out large configuration updates. But those are the two points I'd insist upon: being enough like a database to have a way of getting a consistent view or update done, and having a textual format that if correct, could save and restore to an equivalent state a configuration, and was documented well enough that in principle it could be generated as well. Without those things, IMO a system-scale black box repository would be just one giant disaster waiting to happen. (SMF mostly fulfills my desires with the svccfg command's various subcommands, although I'm not sure about the documentation aspect, but I haven't read any more than I needed at any given moment so far, so it may be ok; but it seems to me that at the very least, some examples of how (or if) it could be used for enterprise-level configuration management (saving/restoring/tracking configurations) might be in order. And having svcadm/svccfg log changes would be great too; nice to know what was changed if something needs fixing after one of those sessions where one's brain is no longer fully functional. This message posted from opensolaris.org
