[pca] Questions on initial setup

[little help]

Martin,


On Wed, Nov 10, 2010 at 11:48 AM, little help <littlehelphere at gmail.com>wrote:

>
> Martin,
>    Thanks for the quick response.  Please see below for answers to your
> questions.
>
>
> On Wed, Nov 10, 2010 at 3:30 AM, Martin Paul <martin at par.univie.ac.at>wrote:
>
>> Hi "little help",
>>
>>    1. From the pca website it states "*As pca uses the wget command to
>>>
>>>   download patches from the patch server, make sure that any specially
>>>   required option is set in /etc/wgetrc or $HOME/.wgetrc*.".  I see the
>>>   options to tell pca where wet resides but nothing to set the wgetrc
>>> file.
>>>   Is there a way to do this?  I would like to have one central file that
>>> I can
>>>   use for all my servers rather than copying a file locally.
>>>
>>
>> It depends on wget itself where it looks for wgetrc files by default. The
>> standard wget in Solaris looks for /etc/wgetrc and ~/.wgetrc. If you compile
>> your on version and install it in e.g. a globally shared /usr/local, it
>> looks for /usr/local/etc/wgetrc and ~/.wgetrc.
>>
>> You can also use the WGETRC environment variable to point wget at a
>> certain wgetrc file. PCA itself does not include an option to specify a path
>> to a wgetrc file, but there's an option "--wgetopt" to feed options directly
>> to wget. I recommend setting up wget configuration (e.g. proxy) outside of
>> PCA, as it can be used on its own, too.
>>
>
> Thanks for the pointer.  I think in my situation it make more sense to
> setup the WGETRC variable.
>
>
>>    2. I also notice that wget requires ssl support to work properly. I
>>> have
>>>
>>>   recompiled wget 1.12 a number of times with ssl support but each time
>>> it has
>>>   an issue (only on sparc - x86 works fine). I found a workaround by
>>> using an
>>>   older version of wget (1.10.2).  Is there an issue with pca using 1.12?
>>>
>>
>> PCA should work fine with any version of wget. Always test it outside of
>> PCA first - if that doesn't work, PCA won't either.
>>
>> Is there a reason why you aren't simply using /usr/sfw/bin/wget which
>> comes with Solaris? It includes SSL support and works fine with PCA.
>>
>
> I did try a test outside of pca and it failed as well when going to https.
> I guess I should have phrased the question better.  Are there any know
> issues with wget 1.12 when compiling for SSL?  I asked because being that
> wget is a core component of pca I thought if there was an issue someone here
> would have run into it.
>
>>
>>    3. I have been testing with the --safe flag as well as --pretend to
>>> make
>>>
>>>   sure there are no issues with patches.  This is due to heavy
>>> customization
>>>   for files. Based on the results I save the files and run the install
>>> without
>>>   the flags and go back and replace any modified files.  I am wondering
>>> if I
>>>   opt to install without the --pretend and simply use --safe what would
>>>   happen.  I know the patches that fail --safe will not get installed.
>>>  If I
>>>   go back and install these after would there be any issue with
>>> dependencies,
>>>   etc.  Any issues if it is kernel patch>
>>>
>>
>> As you say, patches which fail the "--safe" check will not get installed.
>> So if a later patch depends on such a patch, it won't get installed. It
>> depends on the local situation (which or how many files included in patches
>> have local modifications). Here, I always use "--safe", but I also try to
>> keep the amount of modified system files to a minimum, and I rarely see such
>> dependency issues. You'll have to try it out.
>>
>>    4. I have opted to use a local patch server.  When I run my script to
>>>
>>>   check the client and download the required patches everything works
>>> fine.
>>>   However, when I run a query from the client to download from the local
>>> patch
>>>   server it does not see to work.  Rather it complains about file type
>>> unknown
>>>   or file not found (404).  See below
>>> ...
>>>
>>> --13:25:29--  http://foohost/dev/pca-proxy.cgi?109611-01
>>>           => `/var/tmp//109611-01.tmp'
>>> Resolving foohost... xxxx
>>> Connecting to foohost|xxx|:80... connected.
>>> HTTP request sent, awaiting response... 200 OK
>>> Length: 154,536 (151K) [text/plain]
>>>
>>
>> Instead of the patch zip file, the web server returns the "pca-proxy.cgi"
>> file itself. Obviously the web server doesn't execute the CGI file
>> correctly. The .cgi file must have execute permissions, and the web server
>> must be configured to allow CGI executions in the directory where
>> "pca-proxy.cgi" is stored (for apache, this is "ExecCGI"). The PCA docs
>> include an example to set up the apache server included in Solaris, too.
>> Sometimes the error log of the httpd contains helpful information, too.
>>
>
> The .cgi file is simply a link to the pca file itself.  Could it be an
> ownership issue?  In regards to the httpd.conf setting - see below.
>
>   Options Indexes FollowSymLinks ExecCGI
>   AddHandler cgi-script .cgi
>
> I set these based on the pca usage info. "Verify that the web server is
> configured to run CGI scripts (for apache, check the ExecCGI and AddHandler
> options in httpd.conf)."
>
> You mentioned there was a sample httpd.conf file.  Can you let me know
> where it is- I could not seem to find it.
>
>>
>> Hope this helps,
>>
>> Martin.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.univie.ac.at/mailman/private/pca/attachments/20101111/316f7d64/attachment.html