[OpenIndiana-discuss] Local IPS repos

[Jim Klimov]

Hello all,

   I'm trying to set up local IPS repositories in the LAN to replicate
oi-dev and (if possible) sfe and sfe-encumbered, as well as publish
our local on-build experiments, and some in-house packages to boot.

   So far I was thinking along the lines of an horde of unrelated IPS
server instances, represented to the consumers by a reverse-proxy
(Apache or somesuch) in one of two manners above. I believe this is
also the only way to make some packages available on the basis of
limited access (commercial subscription or just to limit the scope
of test-builds to make sure they don't pollute production systems)
with client certificates, as MyOracleSupport apparently does.

   What are the best practices for such setups? Should the repos be
differentiated by URI (i.e. http://pkg.my.com/repo-type/...) or by
individual hostnames (i.e. http://repo-type.pkg.my.com/...)?
Also, is it possible to easily publish an illumos-gate build result
to a networked repo?

   A second question is this: I've tried adding mirrors of oi-dev
in the LAN (and blogged on that in the Wiki half a year ago),
however I see that initial "Creating Plan" phase still goes to the
internet. This seems to happen even if I remove the internet origin
from the list of package autorities completely, and set the local
IPS repo (rsynced from internet) as the origin. Should I also forge
the "pkg.openindiana.org" name in local DNS or /etc/hosts in order
to have the LAN mirrors self-sufficient?

   And a third question: if there are mirrors (or origins) in the
list of publishers which are not currently accessible, the package
download phase seems to still round-robin over them, waiting after
SYN_SENT step, so the overall download goes very slowly. Is it
possible to have the pkg client skip those servers which are not
currently seen as available? (I found I can explicitly use the
particular repo server with "pkg update -v -g http://repo:port/"
or something like that, but would prefer a less manual solution).

Thanks for any ideas and insights,
//Jim Klimov