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 <[email protected]> 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. GUI. I'm not against GUIs, with two caveats. 1. They have to be non-awful. This sounds trivially obvious, but the large majority of sysadmin GUIs that Sun have produced in the last 10 years (at least) have failed this test dismally. Non-awful means: usable as a GUI, and should have reasonable performance (start fast, not be a performance pig). 2. Think about your customers. Is a GUI actually useful to most of them? Sure, it's a nice thing to have if you have a Solaris box on your desk, but does the typical Solaris site look like that? I'm guessing it doesn't look anything like that at all - I'm obviously working in a fairly big site (most of our instances are 25k domains) but I should think the average site has, maybe, 20 instances with some being much, much larger. Is it worth putting an enormous amount of effort into something which will be used by only a tiny proportion of your customers? I'm in the slightly unusual position of hearing a fair amount of feedback from working Solaris sysadmins (albeit at second hand: I'm married to someone who teaches for Sun), and I don't think I have ever heard of anyone being interested in any of the management GUIs. One case where it *would* be useful to have a GUI is if that GUI can work on the configuration for a machine other than the one it's running on, so you can: suck config of target, run GUI on desktop, drop config back on target. Note this is not the same thing as being able to manage a machine over the network: there are a lot of security implications for doing that which are much easier to meet if you can pull the config off the machine & edit it remotely. 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, you 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.) _______________________________________________ sysadmin-discuss mailing list sysadmin-discuss at opensolaris.org http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
