On 06/13/12 07:34, Tom de Waal wrote:
Dear all,
How does one handle access to an IPS repo? SMF allows access to be
read-only or read-write (optional with keys), but how does one cater for
anonymous read-only access
and authenticated (role based?) write access to the same repo?
It seems to me you do not want write access to an repo for everybody if
you need to update your repo.
There's currently no explicit provisioning for this.
There are some options though depending on what type of transport access
you need.
It's generally recommended that all publication be done through the
filesystem directly to the repository instead of over HTTP. Because of
that, and other reasons, it's much faster. I believe the man page
mentions that as well.
If filesystem-based access is viable, then run the SMF service as
read-only, and then each time you perform publication, just send a
SIGUSR1 to the depot service or restart it. This is mentioned at the
end of the pkg.depotd(1M) man page. This requirement is alluded to as
well at the end of the pkgsend(1) man page.
If HTTP(S) access if your only option, then I'd suggest putting the
depot server in read/write mode on a private port that's firewalled
except for traffic from an Apache server that is configured to act as a
reverse proxy for it. There's a sample reverse proxy config here:
http://src.opensolaris.org/source/xref/pkg/gate/src/util/apache2/
Your only viable option at the moment is to then reject any requests
containing one of these strings in the Apache config:
/open/
/append/
/close/
/abandon/
/add/
/admin/
...if they don't come from a specific IP address. Unfortunately, no
HTTP authentication mechanisms are currently supported for publication,
and HTTPS Cert/Keys are not either.
In short, filesystem-based publication is your best option.
I known its possible to run two SMf services (one r/o and one r/w) on
the same "database" (directory), but I'm unsure this is an appropriate
solution.
That's not recommended; the read-only service will likely get confused
at some points.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
