Lyndon Nerenberg wrote:
>> On Wed, Mar 19, 2008 at 02:40:28PM -0700, Darren Reed wrote:
>>
>>> My personal theory on why is simple:
>>> SMF was developed by developers and not system admins.
>>>
>> As a former sysadmin I believe what's missing is remote access. The
>> rest is fine. You're generalizing.
>>
>
> No, what's missing is a simple way for the human sysadmin to view and
> search (and change!) the system's current configuration. SMF's style of
> burying config info in opaque databases makes this difficult, and many
> people find the configuration interface very obtuse.
>
Agreed. The one 'feature' SMF is missing that I find the most useful in
config files are *comments*.
Documenting (right in the admins) face why a config entery is the way it
is, or when wnad why it might be changed, right in the location where
they'll see it when they are changing it.
In text config files, the admin can reorder, group, comment, organize
options in ways that make sense to them, other adimins they work with,
and the situations local to their site. In SMF it's all buried. even in
svccfg, the properties that would have been in a config file, are all
mixed in with many many meta-properties that control how the SMF manages
the service, and not how the service itself is configured. The signal to
noise ratio is just horrible when looking to review the config of a service.
Another shortcoming that has been mentioned elsewhere is the
complexity for the admin to create a new service for an software that
doesn't ship with one. the /etc/rcX.d scripts may not have been the best
for this in the past, but they were shell scripts which was a skill
SysAdmins already knew, and used regularly. Having to learn how to
create new manifests in XML significantly raises that bar. I know SMF
can manage the older script methods, but as I understand it, that gives
reduced functionality, and the impression I've seen people have about it
is that it is only a temporary 'backward-compatibility' feature that
will disappear some day.
Lastly, the lack of jumpstart support (or possibilty to script in in
finish scripts before first reboot,) for configuring SMF during install.
(I'll admit I've only heard others say this is hard. I haven't had a
need to automate this yet - but I will soon.)
> While SMF does a good job of managing processes, it is not the tool for
> managing the configuration of those underlying processes. The power of
> UNIX comes from the "one tool, one task" philosophy, and you ignore that
> at your peril.
>
> The key to making useful software is simplicity and cleanliness of design.
>
+1
> The core idea of SMF -- process management and ordered startup and
> shutdown -- had the potential for a simple design. But adding all the
> associated configuration data management turned it into a nightmare of
> needless complexity. It's enlightening to compare SMF to the {Free,Net}BSD
> rc.d framework. rc.d solves most of the problem using using a few shell
> scripts and a simple C program that solves the start-order dependency
> graph. Layering a process restarter on top of it would be almost trivial.
> Now I don't claim rc.d can (or should) replace SMF, but from an
> engineering standpoint it's interesting to compare the complexity of the
> two systems in relation to the functionality they deliver.
>
>
The complexity does seem higher than required. If both features (service
control/monitoring, and service configuration) are deisred, it seems
like a separate SCF framework would have provided an overall 'simpler'
solution. It also would probably have cleaned up the 'signal to noise'
problem I described above, by splitting the configuration of the service
in SMF from the configuration of the service itself.
> As for remote access being a requirement, rdist solves that problem quite
> nicely. (If remote access is a *requirement*, you're almost always pushing
> configs out from a central configuration management system, anyway.)
>
>
> --lyndon
>
> Good judgement comes from experience. Unfortunately, experience
> comes from bad judgement.
> _______________________________________________
> smf-discuss mailing list
> smf-discuss at opensolaris.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/security-discuss/attachments/20080320/c744715b/attachment.html>
