Moin! On Mar 19, 2008, at 23:39 , Henry B. Hotz wrote: > The fact that SMF's internals are so deliberately opaque makes it > impossible for a typical admin to see if that is the case. The fact > that so many people (who don't want to) are *required* to deal with > SMF means there are a lot of people who need that assurance who won't > get it. While I do agree that there could be more and better smf documentation,
especially technical design docs on how it fits together (if someone has pointers please tell me), I disagree on the rest. First of all smf so far for me my team and the several hundred Solaris 10 hosts is something we rely on and have absolute confidence in. Second you still can use /etc/*.d files, smf will automatically take care of them, but once you discovered the beauty of it you won't do this anyway. > As I have said before, I do not know enough about SMF to have a > technical opinion. However from a marketing and customer confidence > standpoint it is clearly a disaster. Well maybe you should have looked a bit deeper technically as smf isn't something that you fall in love with when you first look at it. However if you took the somehow steep learning curve (better docs would help) than you are going to like it, as it solves real problems quite nice i.e - getting services started with non-root users - getting services to start with least privileges - delegating administration of services - persistent enabling and disabling of services - service dependancies All of this brought us to migrate all of our internal services to smf, and as you probably know by now I do like it. One thing I want to note here on the original topic. What should sms store in properties. IMHO everything that is directly OS related e.g user to start with, smf authorization and anything that is not specified in a configuration file, but can be only supplied to the service via a command line option. Anything else we should stay with config files. > The intensity of opinions on this thread raise the question of whether > the "official channels" are appropriate. Marketing and customer > relations issues should be dealt with by the appropriate management, > not a technical development process. It would appear that someone > inside Sun should forward this thread to the appropriate management. Well you can always talk to your Sun rep and ignore opensolaris.org. You can also tell your Sun rep to look at this thread. I guess a lot of people do that and issue there concerns or kudos over this way. I did certainly tell our Sun rep that we do like smf :-). Other than that opensolaris.org is a community and open to anyone. So long -Ralf
