Joost Mulders writes: > I have no opinion about temporary instances, but I do have another > concern about this statement: > > > This means storing the configuration data in SMF ... > > When SMF was introduced I remember the general feedback from customers > being "great as long as it doesn't become a big giant registry blob". > I fully agree with that.
I have great sympathy with that. I've been using UNIX and Unix-like systems for around 25 years, and flat files have a number of attractive properties that ODM and the MSFT "Registry" do not. However, that ship has sailed. It went with Greenline (PSARC 2002/547). I don't want to get too wrapped up in the quasi-religious parts of this. My interest is in working on my project (which is bridging, not system administration frameworks), and I'm trying to make my project fit in as naturally as I can with the dominant and recommended mechanisms. For what it's worth, this *does* potentially buy me (and the customers) some useful benefits, including configuration snapshot and rollback capabilities now (though many administrators would have used rcs or sccs with flat files in the past), plus future benefits with templates and enhanced profiles. > What's wrong with an /etc/something.something file? Such files can > easily be edited, grep'd, compared, backup up, copied, saved, moved, > commented etc etc. All these nice features are at least more difficult > when the properties are in SMF. > > So, my 2 cents on the question > > Which way is the SMF community going? > is that it shouldn't become a repository for application properties. That's the part of your response that I find baffling. I don't think that's quite true ... unless I've greatly misunderstood what SMF is supposed to be about. I agree that complex and detailed configuration (think: BGP policy in Quagga) likely has no place in SMF because the semantics just aren't rich enough, but surely basic configuration parameters for the system services do belong there, right? Or are all of the projects that've placed those parameters there already (such as Greenline's changes to inetd, or the routeadm changes), and the ones that plan to do it in the future (NWAM at one point was talking about it for interfaces), and the original SMF project itself (which discussed migrating configuration over time) all misguided? I had thought that the reason we treat all new configuration files (/etc/dladm/*) as Private was that they're just a temporary expediency until they can be redesigned into SMF. Is that not the case? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
