Hi Tim,
A little more on this and if you want to take the pkg-discuss alias out
of this, that's cool with me.
I finally figured out where the process was choking. It seems that the
pkg framework is trying to download the following pkgs:
http://swie.us.oracle.com:10000/solaris/catalog/1/catalog.base.C
http://swie.us.oracle.com:10000/solaris/catalog/1/catalog.summary.C
http://swie.us.oracle.com:10000/solaris/catalog/1/catalog.dependency.C
It tries GET them over and over until the pkg framework times out. If I
didn't have access to our proxy's access.log there would be no way for
me to know that. No output from pkg at all as to why it doesn't complete
the pkgrecv. Unless there is another log that I'm not aware of that pkg
writes to. Piping the output to a file didn't yield me anything either.
To further trouble shoot this, I have run a series of wget commands to
pull these files manually to see what behavior I get and to, hopefully,
get good copies of them in to my proxy cache. I've met with mixed
results and have a bad feeling that it's a network issue between my
servers and the sites they are serving. I'm working with Oracle IT on
that one.
I have enabled logging on pkg.depotd on my repo and see nothing to
indicate an error serving out the files mentioned above. Is there
another place I should look for what pkg.depotd is doing or another log
that it writes to besides what I've defined in the service for the
access_log and the errors_log?
Thanks!
-Brian
On 9/24/12 4:35 PM, Tim Foster wrote:
On 09/25/12 11:31 AM, Brian Phipps wrote:
Thanks for the reply on this, Tim.
No worries.
I was finally able to get around to doing this on one of my machines and
the pkgrecv just stops part way through the start up:
root:~# http_proxy=http://tlc:8080 pkgrecv -s
http://swie.us.oracle.com:10000 -d /export/home/temp -m
all-timestamps '*'
Processing packages for publisher solaris ...
root:~#
That's it? Piping the pkgrecv output to a file might be useful, in
case your terminal has discarded text as a result of the
progress-tracker printing human-readable output.
Is there a better log to look at and see why this is failing? I've tried
upping the values for PKG_CLIENT_CONNECT_TIMEOUT,
PKG_CLIENT_MAX_TIMEOUT, and PKG_CLIENT_LOWSPEED_TIMEOUT with no change
in behavior.
Do package install operations through the proxy exhibit similar
behaviour? Are there any messages appearing in the proxy logs, or
pkg-server logs?
cheers,
tim
On 8/30/12 2:24 PM, Tim Foster wrote:
On 08/31/12 07:15 AM, Brian Phipps wrote:
Hi All,
We use a proxy cache hierarchy between our repo and the 4 main
locations
where we perform installs. Beyond just performing AI installs to pull
the repo content through the cache's, can anyone think of a way to
"pre-seed" our cache machines with the repo content?
I've tried using pkgrecv in this fashion and it didn't work:
export http_proxy=http://swcache:8080; pkgrecv -s http://repo:10000 -d
/dev/null '*' solaris
This failed because there is no repo setup in /dev/null. Any
thoughts on
how I might accomplish something similar to the above to get my bits
cached?
Create a repository in a scratch area, and pkgrecv into it then
destroy the repository.
# pkgrepo create /scratch/foo
# http_proxy=foo pkgrecv -s http://repo:10000 -d /scratch/foo '*'
# rm -rf /scratch/foo
cheers,
tim
--
<http://www.oracle.com>
Brian Phipps | Software Engineer
Oracle WorldWide Operations
3295 NW 211th Terrace | Hillsboro, OR 97124
Phone: +1 503 495-7716
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and
destroy all copies of the original message.
--
Signature <http://www.oracle.com>
Brian Phipps | Software Engineer
Oracle WorldWide Operations
3295 NW 211th Terrace | Hillsboro, OR 97124
Phone: +1 503 495-7716
NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies of
the original message.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss