How about this approach, only to be used for services where the pre-existing config file format was (give or take the odd Solaris extension) cross-platform:
add "import-native" and "export-native" to svccfg, which would require a skeletal manifest to first be imported, that identified a plugin which would digest an externally defined config file format, the location of the config file, and also contained any other properties that could not be derived from the config file. Conceptually and for the purposes of the "archive" and "export" subcommands and the like, the result of applying the "import-native" command would be a complete manifest derived from the merging of the skeletal manifest and the native format config file. The merging would give precedence to the config file, except that the absence of Solaris-specific config file directives in the config file would not override the presence of corresponding properties already loaded (allowing such directives to be managed either by the config file if present there, or by usual SMF commands only.) The support of "export-native" would be optional, and indicated by the presence of the corresponding entry point symbol in the plugin. If supported, that would produce on standard output or to the specified file a config file in native format describing the current configuration. It might well also take an option that would cause it to instead output an updated version of the skeletal manifest, to allow preservation of information not representable as part of the native config file format; and it might have an option to constrain the native format output to only portable directives. An associated method script might well also perform an import-native on start if the config file identified by the appropriate property was newer than a property identifying the time the config was last imported; this would cause config file changes to be reflected on reboot or restart. As an architectural matter, the plugins might well be method-like scripts rather than shared objects, communicating their support or lack thereof for the export functionality by their return code when it was attempted. This would make it more convenient to use perl scripts or the like, although it would typically be slower. If the custom was for a non-SMF implementation to provide for multiple instances via a command line arg that specified an alternate config file, then multiple instance support would now be done via a per-instance property in the skeletal manifest that pointed to the particular config file to use. "import-native" could perhaps also subsume inetconv functionality, give or take options provided. That would allow one to push out (by whatever means) a generic config file, and merely do svcadm restart ssh instead of the Solaris 9 style kill -HUP `cat /var/run/sshd.pid` to cause the new config to become effective. And yet one could still manipulate Solaris-specific features persistently either with or without touching the config file, as desired. That approach could also make migration into SMF not necessarily easier to do, but at least friendlier and better accepted, even for Solaris-specific services being changed to be configured via SMF, since it partially decouples the administrator experience from the migration into SMF - the plugin could optionally be phased out sometime after. Parsing config files that are reasonable to SMF-ify (I don't recall anyone suggesting hacking Apache to get its config from SMF!) has to be done _in_concept_ anyway to manually equate directives and properties and create a manifest, so providing a tool to automate manifest (re)creation isn't _that_ much extra work IMO. Just a thought along the lines of a middle ground that allows for the benefits of both approaches... This message posted from opensolaris.org
