Danek,
> I can't speak to the caiman bug.
Dave already adressed this.
> As for the pkg(5) bug, the point, which may have been lost in the shuffle,
> is that until the depot supports fine grained authorizations, the
> recommended way to publish packages is to publish either to a fully
Where is this recommended? I haven't seen this in the final 2010.03 IPS
Guide, but may simply be blind.
> protected host (over loopback, on a machine not on the internet, with IPF
There's currently no way to start pkg.depotd listening only on the
loopback interface AFAICS, you can only chose the port. This (or,
better yet, restricting write access to either loopback or a single/few
address/es) would certainly be a start. All I'm asking is something
better than no access control at all.
> blocking the port, whatever) or to a file: URL which doesn't involve an
> open port at all. The resulting repository can then be moved to an
> appropriate location, and a read-only depot stood up on top of that.
>
> This is the way that we've been managing pkg.opensolaris.org, and it's been
> quite successful, and is entirely safe.
I wouldn't have expected otherwise, anything else would have been
criminally careless. But your knowledge, as the developers and
deployers of the service, doesn't automatically diffuse to other users.
> I agree that the documentation could make this process clearer and indicate
> that it's recommended. In addition, making the SMF service default to
> read-only makes sense in case an administrator starts up the service
> without having read the documentation.
Fine. Please also update the man pages with crucial information like
this; having this only in the IPS Guide seems not enough, given the risk
involved.
> I believe Shawn has filed bugs for all of this, and is in the process of
> fixing them.
That's great, thanks.
> I think that what was obvious to the pkg(5) team -- namely that safety is
> entirely achievable without fine grained authorizations, and how to achieve
> it -- was not obvious to you, and that disconnect was not recognized and
> communicated effectively. I hope that we've managed to do so now.
Indeed, and I fear that's one of the problems with the current speed of
IPS development and wide range of deployment: customers start (or are
forced to start, given that the rug is pulled under them with the
removal of SVr4 packaging, Jumpstart, and Flash) using this stuff in the
wild, while important documentation, caveats etc. is either missing, sort
of hidden in the IPS hg repo or on wikis.sun.com. Bringing all this
together in a single place would be very important to avoid disconnects
like this in the future.
> If, given this information, our priorities still appear to you to be poor,
> you have the options of either contributing to the project, or talking to
I'm doing so, at present more the the form of bug reports and RFEs than
contributing code: there are only so many hours in a day, and my python
knowledge is practically zero.
> Angry emails on public forums, as cathartic as they may be from time to
> time, are not helpful, particularly when the new folks in charge are still
> making up their minds whether open development is worth the cost.
Perhaps true, but on the other hand, I often sense what I consider a
highly problematic reaction from some members of the IPS team. The
tenor often is: we're still in development, we know the requirements and
constraints, either contribute or shut up. What this seems to forget is
that many sites are sort of forced to use what is available *now*, and
have been working with packaging software and automated installation for
years if not decades, so they understand their use cases just as well.
On the other hand, it would be a terrible illusion to believe that
closed design and development would do any better: it only means that
important requirements will be missed in the design phase and bugs found
and fixed later since nobody on the team thought to use the software in
this particular way. I know I don't need to tell you this, but I as
well have no idea what Oracle understands about open source projects.
Only time will tell.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
