Hi, Darren.
I have a lot of SVR4 experience, but next to no IPS experience, so take
the following in that context.
It seems to me that what you are proposing has two important differences
from the SVR4 experience:
1) Semanatic: I can control the contents of my system by controlling
when I do installs. I may not (for whatever reason) want the latest and
greatest providers. In this use case, I can reboot my system and
stop/start/restart services arbitrarily many times without changing my
system configuration. I therefore suggest that if you provide a means
to automagically check for new things on service start, you provide a
means for disabling this feature both always and for a given startup.
Otherwise, people may feel that they have been blindsighted by what they
will undoubtably call a "side effect" of service start.
2) Performance: outside of test labs, pkg installs happen much less
frequently that server restarts/refreshes. If your post-install scripts
have to phone home to download new functionality, this could very well
be a user-visible delay in service start-up time. Most critically, this
will happen during every restart/refresh, rather than once per system
lifetime and the penalty will be paid whether there is anything to
download or not. During boot, this may not be so obvious, but manual
restarts have the potential to suffer greatly.
HTH,
Glenn
Darren J Moffat wrote:
> As some of you may already know the new IPS pkg(5) system does not
> support generic scripting. This means no postinstall scripts and for
> the most part no class action script equivalents either.
>
> kcf.conf/pkcs11.conf currently get update by class action scripts. We
> need to be able to do this as we add new providers and enhance the
> capabilities of the existing ones. For example since Solaris 10 FCS we
> have added about 5 new kernel providers and update the list of
> mechanisms on at least one. We have also needed change the names of
> providers in the kcf.conf/pkcs11.conf files due to the SUNWcry removal.
>
> With an OpenSolaris 2008.05 system installed by IPS we had a clean slate
> but even since that release there are changes to kcf.conf that are
> needed (including the not yet integrated 6696012 missing CKM_AES_CCM).
>
> Upgrade from an SVR4 based system to an IPS based one is not possible so
> for IPS systems we don't actually need to worry about all the changes
> since S10 FCS, only those since 2008.05 (snv_85). However SVR4 based
> systems will continue to exist in the form of Solaris Express for a
> while yet so we do need to worry about them after all.
>
> That still leaves the delivered i.pkcs11conf and i.kcfconf that are
> documented in docs.sun.com on how to package crypto modules. For now
> those can stay as that is still relevant for SVR4 packaging and we don't
> yet have a need for IPS packaged crypto providers that are delivered
> from somewhere other than pkg.opensolaris.org.
>
> I propose that we change the start and refresh methods for
> svc:/system/cryptosvc to be a script that first checks that
> kcf.conf/pkcs11.conf are up to date and if not makes them so by doing
> basically what the i.kcfconfbase and i.pkcs11confbase class action
> scripts do today. Since this isn't a class action script it won't be
> quite the same code but it will be similar.
>
> The reason we need to fix this one now rather than waiting is that if
> 6696012 (kcf.conf missing CKM_AES_CCM) doesn't get addressed then zfs
> crypto won't work when people upgrade.
>
> pkg-discuss people:
> Does this approach sound correct ?
>
> crypto-discuss people:
> I need someone to work on this as I'm swamped with
> zfs-crypto work at the moment. I'm happy to give input
> I just don't have time to code/test it. The solution
> will need tested on SRV4 and IPS based systems.
>
>
--
______
/_____/\ Glenn Glazer
/____ \\ \ glenn.glazer at sun.com
/_____\ \\ / Compute Resources
/_____/ / \//\ x63073/(408) 992-9073
\_____\//\ / / Cell Phone: (562) 305-2920
\_____/ / /\ /
\_____/ \\ \ Sun Microsystems, Inc.
\_____\ \\ 324 North Mary Avenue
\_____\/ Sunnyvale, CA 94085
make opt, not war.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/crypto-discuss/attachments/20080812/687400df/attachment.html>
