Joost Mulders writes: > > 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? > > Probably I am misguided but .. in the 2002/547 ARC isn't anything that > says that application configuarables should go to SMF. I think the
I'm not sure what you mean by "application" here, but the ones I'm talking about are system services, not just applications. 2002/547 (as Stephen has confirmed) makes it clear that new services should be implemented in SMF. > I am not saying all these projects are miguided. I expressed my > concerns as a user, which is what I am. Properties in SMF's repository > limit me as I can't grep, zip, zap, copy, comment them. The advantages > (snapshot & rollback) don't outweigh. IMHO, there's only one driver I > see fit for a central configuration repository and that is an > administrative GUI. Yep. My dissent on the ARC decision included issues like those. That's long since decided, though. It's no longer a point of contention and isn't at issue here. > Obviously, I am just too late with raising my concerns. No big deal. > I'll eventually learn to live with svccfg as I did with regedt32, > regedit, smit*, sam, and odm*. But, after investing my time in > learning them, I ask: what have they done for me, apart from being in > the way? If you'd like to reargue the Greenline case, please start a new thread. It might be an interesting discussion, but it's not related to this one. -- 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
