Alan Coopersmith wrote: > Bart Smaalders wrote: >> Garrett D'Amore wrote: >> >>> must support the various Big Rules (including auditable administration), >> I asked Gary this question, but he declined to answer: >> >> What project satisfies this big Rule today? > > SMF. > >> If my project introduced a config file in /etc/, how could I meet this >> big rule? > > You could provide a fooconfig command, or plugin to some administration > toolset (if we had one with a future, unlike smc), but many projects don't, > which is why new config files in /etc were banned by the SMF policy. > > Of course, like most big rules & SAC policies, we only apply to new projects, > and the trivial way to be exempted is to leave the old code untouched and > not come back to ARC with any enhancements, effectively encouraging > stagnation. >
huh? So I cannot integrate dovecot (a nice imap server) into Solaris, w/o shoving all the config files into the repository? I don't think this is what the SMF team or anyone else had in mind, and indeed, I find: > Appendix A: Guidance for Highly Complex Configuration Grammar > > Projects that have: > > * Services with existing configuration files > * Open Source services with well-known configuration files > * Services that are recognized as having highly complex grammar > > must consult with the ARC to determine if utilizing the Service Configuration > Facility is appropriate for their specific configuration data. > It's pretty clear that the SMF policy doesn't expect or require Open Source services to be rewritten to store their configuration information in SMF. We _do_ expect a SMF manifest; that's simple and often requires no changes in the installed software at all other than trivial rework of rc.d scripts. I don't think PSARC will require sendmail.conf to appear in the SMF repo anytime soon. Reading the Solaris Auditing Policy, I see no prescriptive suggestions for auditing changes to configuration files in /etc. Indeed, the /etc/security directory is full of sensitive security-related configuration files, which have no explicit auditing mechanism other than the basics provided by system call auditing. If this is good enough for such core Solaris components as auditing (heh), openssl, etc, why isn't it good enough for other open source software? If we want to engineer a better solution, I suggest we investigate options that don't require redesigning every piece of software that goes into Solaris. Instead, let's look for ways to leverage our top to bottom control of the system so that we can provide the necessary auditing history/mechanisms w/o changing every piece of software aimed at Solaris. For example, has anyone considered using/modifying ZFS to provide extra transactional semantics for a filesystem mounted on /etc? Perhaps one that doesn't make changes to a file visible until it's closed, and preserves all previous versions of the files? Given that /etc/ traffic is low, you could also implement /etc as a user-level NFS mount (or using FUSE when that integrates) and implement most of the semantics there. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird."
