Dave,
> It's unfortunate that you chose this route rather than perhaps a more
> direct escalation with the project leads. We share your goals, though as
perhaps I should have, but for one there's no documented way to do so
and I saw e.g. yourself and Stephen Hahn on the Cc's of my reports.
Given the fact that only Shawn responded to the pkg.depotd bug and
primarily came up with what seemed like excuses why the known problems
could not even be documented, I deciced to take this route.
> Danek said priorities may not align at particular points in time.
All granted, and I said so before. But especially given that many of
those issues are well known at least to the project team, I'd expect
them to be properly documented and users/customers alerted about them,
together with suggestions for workarounds, rather than keeping silent
and letting users discover the issues themselves, at worst after a
breakin. I think it's critical to raise awareness of the current issues
now, even if a perfect solution is not yet available.
> Getting to technical issues... With respect to the AI bug, yes, it's a
> problem, I see no denial of that in the conversation so far. The current
> mechanism for system configuration in AI was a temporary hack until the
> SMF-based replacement could be built, and while it's well on the way to
> being replaced, the replacement is not ready yet and won't be for a while.
> Your further comments seem to assume that the system configuration manifest
> would continue to be directly available through the existing AI manifest
> service, which has not been proposed, and in fact is not at all likely, for
> many reasons, including this one. I'm quite certain that we can provide
> sufficient security for this configuration data, not least because the
> wanboot infrastructure we're leveraging has stronger security measures
True: I remembered that after sending my message. I think (though I'm
not sure, not having used wanboot in pre-AI days since NFS is far more
convenient in a LAN environment) that the old Jumpstart/WanBoot even
required cryptographic authentication. So the current situation is not
only a regression from the Jumpstart/NFS scenario, but even from
Jumpstart/WanBoot.
> available, though we have yet to make use of them. Getting there will take
> some work, however, and is certainly not something that will be
> accomplished in a week.
Understood.
> In the meantime, I would recommend using IPfilter to restrict access to the
> AI manifest services, and also suggest installing on the client a
> first-boot service (appropriately secured with file system permissions, of
> course) that replaces the password for any account that is a concern so
> that any data obtained through the manifest service is useless.
Good suggestion. My alternative solution, rather than having one
encrypted password per AI client system, was to use a single (or a few)
common ones and to expire the root account via a first-boot service with
passwd -f, letting the first admin to log into it change the password as
required by site policy.
But again: something like this doesn't only belong into a mailing list
archive, but rather in the AI docs.
Thanks.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
