Re: [pca] Heads-up: New download service

2011-08-10 Thread Martin Paul 

Don O'Malley wrote:
There is load balancing performed on the backend to share the load between 
limelight and Akamai.

To cover all scenario's the following should be added to your firewall:


A really long list. Lucky me that I don't have to deal with rules for outgoing 
connections on our firewall. I've updated the list in the PCA installation 
instructions, too:


  http://www.par.univie.ac.at/solaris/pca/installation.html

Martin.

Re: [pca] Heads-up: New download service

2011-08-09 Thread Laurent Blume 

On 08/09/11 18:08, Don O'Malley wrote:

Nope!

There is load balancing performed on the backend to share the load
between limelight and Akamai.
To cover all scenario's the following should be added to your firewall:

# oracle.com
# getupdates.oracle.com
# updates.oracle.com
# aru-llnw.oracle.com
# aru-llnw-dl.oracle.com
# edgesuite.net
# akamai.net
# a248.e.akamai.net.
# llnwd.net
# llnw.net


... ouch... so many...

Certainly helps, thanks. I'll go justify punching open a new bunch of 
holes in the firewall ;-)


Laurent

Re: [pca] Heads-up: New download service

2011-08-09 Thread Don O'Malley 






Laurent Blume wrote:
On
08/02/11 14:30, Don O'Malley wrote:
  
  There were some backend changes to the Oracle
patch download service

over the weekend.


Everything went very smoothly, but you may notice that there is now an

additional level of redirection added to patch downloads.

Requests to getupdates.oracle.com now redirect to updates.oracle.com
via

login.oracle.com (for authentication).


There is a possibility that firewall rules may need to be updated in

certain circumstances to accommodate this change (hence the reason for

the heads-up).

  
  
Should that be the same for everybody?
  

Nope!

There is load balancing performed on the backend to share the load
between limelight and Akamai.
To cover all scenario's the following should be added to your firewall:

oracle.com

getupdates.oracle.com
updates.oracle.com
aru-llnw.oracle.com
aru-llnw-dl.oracle.com

edgesuite.net
akamai.net

a248.e.akamai.net.

llnwd.net
llnw.net



HTH,
-Don
In my
case, the getupdates.oracle.com links redirects directly to an
akamai.net one, which is not allowed by our security (and being
exceedingly generic, is not going to be easily opened).
  
  
Laurent
  
  


-- 
  
Don O'Malley

Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware 
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764 
Team Alias: rpe_patch_system_test...@oracle.com

Re: [pca] Heads-up: New download service

2011-08-09 Thread Laurent Blume 

On 08/02/11 14:30, Don O'Malley wrote:

There were some backend changes to the Oracle patch download service
over the weekend.

Everything went very smoothly, but you may notice that there is now an
additional level of redirection added to patch downloads.
Requests to getupdates.oracle.com now redirect to updates.oracle.com via
login.oracle.com (for authentication).

There is a possibility that firewall rules may need to be updated in
certain circumstances to accommodate this change (hence the reason for
the heads-up).


Should that be the same for everybody?
In my case, the getupdates.oracle.com links redirects directly to an 
akamai.net one, which is not allowed by our security (and being 
exceedingly generic, is not going to be easily opened).


Laurent

Re: [pca] Heads-up: New download service

2011-08-02 Thread Don O'Malley 




Hi Jeff,
 
To answer both questions:
1) Yes you can expect patch downlaods from limelight too, so
aru-llnw.oracle.com and aru-llnw-dl.oracle.com
should be added to firewall rules.
2) The dropoff in S10 patches is due to the upcoming release of S10U10.

Best,
-Don


Jeff Earickson wrote:

  Paul, Don et al,

I too am seeing the Limelight networks addresses and I am in the US,
not Europe.  My pca debug sessions hung on aru-llnw.oracle.com and
aru-llnw-dl.oracle.com; I ended up adding 208.111.128.0/24 into my
firewall rules to get pca working again.

Paul, it would be nice if pca spit up a message if a URL connection
times out, even if you are not running in debug mode.  That would be a
clue that
either something was down at the Oracle end, or there is a
change/firewall issue.  Otherwise you tend to assume that things are
working normally.

Don, I have noticed a big drop-off in Solaris 10 patches in the past
month to six weeks.  Is this because a new release of Solaris 10 is
about to happen?

Jeff Earickson
Colby College

On Tue, Aug 2, 2011 at 9:03 AM, Martin Paul  wrote:
  
  
Don O'Malley wrote:


  Everything went very smoothly, but you may notice that there is now an
additional level of redirection added to patch downloads.
Requests to getupdates.oracle.com now redirect to updates.oracle.com via
login.oracle.com (for authentication).
  

Downloads work for me, but it looks different from your example - at the end
I'm getting the patch from "http://aru-llnw-dl.oracle.com/aaruna04/...". Was
there a switch from akamai to limelight, or does this depend on where the
client is coming from?

Martin.



  
  
  


-- 
  
Don O'Malley

Manager,Patch System Test
Revenue Product Engineering | Solaris | Hardware 
East Point Business Park, Dublin 3, Ireland
Phone: +353 1 8199764 
Team Alias: rpe_patch_system_test...@oracle.com

Re: [pca] Heads-up: New download service

2011-08-02 Thread Jeff Earickson 
Paul,

I was hoping for something simple like examining the return code for
wget.  But googling on the topic of wget return codes, took me to
here:

http://www.gnu.org/software/wget/manual/html_node/Exit-Status.html

These codes are very vague (maybe code 4 would work).  The note about
return codes for older versions convinces me that you are right.
Ugh.

Jeff Earickson
Colby College

On Tue, Aug 2, 2011 at 9:45 AM, Martin Paul  wrote:
> Jeff Earickson wrote:
>>
>> Paul, it would be nice if pca spit up a message if a URL connection
>> times out, even if you are not running in debug mode.
>
> I agree in that it would be nice, but it won't happen. I'm leaving all the
> download stuff to wget - and I'm very glad that I don't have to care about
> that in PCA - which will timeout eventually, but I have no plans to write
> ugly code looking at wget's (debug) output to see what's going on. With all
> the redirects and all the changes in Sun's/Oracle's backend infrastructure
> in the past, this would be a nightmare.
>
> Martin.
>
>

Re: [pca] Heads-up: New download service

2011-08-02 Thread Martin Paul 

Jeff Earickson wrote:

Paul, it would be nice if pca spit up a message if a URL connection
times out, even if you are not running in debug mode.


I agree in that it would be nice, but it won't happen. I'm leaving all the 
download stuff to wget - and I'm very glad that I don't have to care about that 
in PCA - which will timeout eventually, but I have no plans to write ugly code 
looking at wget's (debug) output to see what's going on. With all the redirects 
and all the changes in Sun's/Oracle's backend infrastructure in the past, this 
would be a nightmare.


Martin.

Re: [pca] Heads-up: New download service

2011-08-02 Thread Jeff Earickson 
Paul, Don et al,

I too am seeing the Limelight networks addresses and I am in the US,
not Europe.  My pca debug sessions hung on aru-llnw.oracle.com and
aru-llnw-dl.oracle.com; I ended up adding 208.111.128.0/24 into my
firewall rules to get pca working again.

Paul, it would be nice if pca spit up a message if a URL connection
times out, even if you are not running in debug mode.  That would be a
clue that
either something was down at the Oracle end, or there is a
change/firewall issue.  Otherwise you tend to assume that things are
working normally.

Don, I have noticed a big drop-off in Solaris 10 patches in the past
month to six weeks.  Is this because a new release of Solaris 10 is
about to happen?

Jeff Earickson
Colby College

On Tue, Aug 2, 2011 at 9:03 AM, Martin Paul  wrote:
> Don O'Malley wrote:
>>
>> Everything went very smoothly, but you may notice that there is now an
>> additional level of redirection added to patch downloads.
>> Requests to getupdates.oracle.com now redirect to updates.oracle.com via
>> login.oracle.com (for authentication).
>
> Downloads work for me, but it looks different from your example - at the end
> I'm getting the patch from "http://aru-llnw-dl.oracle.com/aaruna04/...";. Was
> there a switch from akamai to limelight, or does this depend on where the
> client is coming from?
>
> Martin.
>
>

Re: [pca] Heads-up: New download service

2011-08-02 Thread Martin Paul 

Don O'Malley wrote:
Everything went very smoothly, but you may notice that there is now an 
additional level of redirection added to patch downloads.
Requests to getupdates.oracle.com now redirect to updates.oracle.com via 
login.oracle.com (for authentication).


Downloads work for me, but it looks different from your example - at the end I'm 
getting the patch from "http://aru-llnw-dl.oracle.com/aaruna04/...";. Was there a 
switch from akamai to limelight, or does this depend on where the client is 
coming from?


Martin.

Re: [pca] Heads-up: New download service

2011-08-02 Thread Rajiv Gunja 
Thanks for the heads up Don.

Tried downloading and it was successful. I am behind a firewall/proxy. I
used the latest DEV version of PCA.

-GGR

--
Rajiv G Gunja
Blog: http://ossrocks.blogspot.com


On Tue, Aug 2, 2011 at 08:30, Don O'Malley  wrote:

> **
> Hi,
>
> Just a quick heads-up...
>
> There were some backend changes to the Oracle patch download service over
> the weekend.
>
> Everything went very smoothly, but you may notice that there is now an
> additional level of redirection added to patch downloads.
> Requests to getupdates.oracle.com now redirect to updates.oracle.com via
> login.oracle.com (for authentication).
>
> There is a possibility that firewall rules may need to be updated in
> certain circumstances to accommodate this change (hence the reason for the
> heads-up).
>
> I've included the output of a wget request to retrieve a patch below.
>
> Best,
> -Don
>
> $ wget --no-check-certificate --http-user="x" 
> --http-passwd="" 
> "https://getupdates.oracle.com/all_unsigned/120068-02.zip"; 
>  -O 
> /tmp/120068-02.zip
> --2011-08-02 10:31:03--  
> https://getupdates.oracle.com/all_unsigned/120068-02.zip
> Resolving getupdates.oracle.com (getupdates.oracle.com)... 141.146.44.51
> Connecting to getupdates.oracle.com 
> (getupdates.oracle.com)|141.146.44.51|:443... connected.
> WARNING: cannot verify getupdates.oracle.com's certificate, issued by 
> `/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at 
> https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server 
> CA - G3':
>   Unable to locally verify the issuer's authority.
> HTTP request sent, awaiting response... 301 Moved Permanently
> Location: 
> https://login.oracle.com/pls/orasso/orasso.wwsso_app_admin.ls_login?site2pstoretoken=v1.2~E4066BF0~20AAF567DFBC8D71FD4D32721442AB2DAF68711C4CC999EE873CE676C8D825E655DCA9E9A1A706322991CFC5D30F705A4368A860BB7DA9AE2B50EA3258B8A2C50F91030E3F7499AFF1F0998A5E2BC11E78DE73F01D19F205CDDD579AB31791877B68E0291473E89F9B01B0241D85F6F35C5C8E482194F1636C7ABCB4081964DD1A6B00638364CF644D2CB7B744DA202AFFAF33A53A4A82D6100D9B92DC5553B4DFC8C70367CD826C4579CC1BBCC5296D2A45E8930195F639
> [following]
> --2011-08-02 10:31:04--  
> https://login.oracle.com/pls/orasso/orasso.wwsso_app_admin.ls_login?site2pstoretoken=v1.2~E4066BF0~20AAF567DFBC8D71FD4D32721442AB2DAF68711C4CC999EE873CE676C8D825E655DCA9E9A1A706322991CFC5D30F705A4368A860BB7DA9AE2B50EA3258B8A2C50F91030E3F7499AFF1F0998A5E2BC11E78DE73F01D19F205CDDD579AB31791877B68E0291473E89F9B01B0241D85F6F35C5C8E482194F1636C7ABCB4081964DD1A6B00638364CF644D2CB7B744DA202AFFAF33A53A4A82D6100D9B92DC5553B4DFC8C70367CD826C4579CC1BBCC5296D2A45E8
> 930195F639 
> *Resolving
>  login.oracle.com (login.oracle.com)... 141.146.9.36**Connecting to 
> login.oracle.com (login.oracle.com)|141.146.9.36|:443... connected.*
> WARNING: cannot verify login.oracle.com's certificate, issued by 
> `/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at 
> https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server 
> CA - G3':
>   Unable to locally verify the issuer's authority.
> HTTP request sent, awaiting response... 401 Unauthorized
> Reusing existing connection to login.oracle.com:443.
> HTTP request sent, awaiting response... 302 Moved Temporarily
> Location: 
> https://updates.oracle.com/osso_login_success?urlc=v1.2%7E90F38587349B069957EEAD9271CDE9DA5D20A7061EF97051AE81D1498903E94B3E9FD2F389AFF928425B29577B7C6997302DE8A576BE62C612F2843A3DB120F50FDBA2885F9A1F7494495EB81FD9CF74E8C4062DAAB25D20E7521E3D186DFFF4D23993F16ED575729524534
> 0E0DF14534EAA96492718E89FA2753791A45E0082084D88F5DCFB3321026FE507ED07E3625C1EFD58115CA6E916982ABCAD7173B3721A84B749FF9760D947B031632772ACFBE642DF3C59ABE7312365332AD9093AB767B855DFCAB9B72AB485DE1AFCABD7A238F8B900DA288A08F6E3165F40891CF2EBD59CB1F6F6BEADDF8AB8F06EBC1D33F0371787F05D8E806941ABC3E29F62246DF9CCB06C36C49B5688B1CCDB616CB0FD1B37EA6CA2DD4A32FAB00452CE865C1D18FE4AD10E94C00D7D619AACDCD2
>  
>

[pca] Heads-up: New download service

2011-08-02 Thread Don O'Malley 




Hi,

Just a quick heads-up...

There were some backend changes to the Oracle patch download service
over the weekend.

Everything went very smoothly, but you may notice that there is now an
additional level of redirection added to patch downloads.
Requests to getupdates.oracle.com now redirect to updates.oracle.com
via login.oracle.com (for authentication).

There is a possibility that firewall rules may need to be updated in
certain circumstances to accommodate this change (hence the reason for
the heads-up).

I've included the output of a wget request to retrieve a patch below.

Best,
-Don

$ wget --no-check-certificate --http-user="x" --http-passwd="" "https://getupdates.oracle.com/all_unsigned/120068-02.zip" -O /tmp/120068-02.zip
--2011-08-02 10:31:03--  https://getupdates.oracle.com/all_unsigned/120068-02.zip
Resolving getupdates.oracle.com (getupdates.oracle.com)... 141.146.44.51
Connecting to getupdates.oracle.com (getupdates.oracle.com)|141.146.44.51|:443... connected.
WARNING: cannot verify getupdates.oracle.com's certificate, issued by `/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3':
  Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://login.oracle.com/pls/orasso/orasso.wwsso_app_admin.ls_login?site2pstoretoken=v1.2~E4066BF0~20AAF567DFBC8D71FD4D32721442AB2DAF68711C4CC999EE873CE676C8D825E655DCA9E9A1A706322991CFC5D30F705A4368A860BB7DA9AE2B50EA3258B8A2C50F91030E3F7499AFF1F0998A5E2BC11E78DE73F01D19F205CDDD579AB31791877B68E0291473E89F9B01B0241D85F6F35C5C8E482194F1636C7ABCB4081964DD1A6B00638364CF644D2CB7B744DA202AFFAF33A53A4A82D6100D9B92DC5553B4DFC8C70367CD826C4579CC1BBCC5296D2A45E8930195F639 
[following]
--2011-08-02 10:31:04--  https://login.oracle.com/pls/orasso/orasso.wwsso_app_admin.ls_login?site2pstoretoken=v1.2~E4066BF0~20AAF567DFBC8D71FD4D32721442AB2DAF68711C4CC999EE873CE676C8D825E655DCA9E9A1A706322991CFC5D30F705A4368A860BB7DA9AE2B50EA3258B8A2C50F91030E3F7499AFF1F0998A5E2BC11E78DE73F01D19F205CDDD579AB31791877B68E0291473E89F9B01B0241D85F6F35C5C8E482194F1636C7ABCB4081964DD1A6B00638364CF644D2CB7B744DA202AFFAF33A53A4A82D6100D9B92DC5553B4DFC8C70367CD826C4579CC1BBCC5296D2A45E8
930195F639
Resolving login.oracle.com (login.oracle.com)... 141.146.9.36
Connecting to login.oracle.com (login.oracle.com)|141.146.9.36|:443... connected.
WARNING: cannot verify login.oracle.com's certificate, issued by `/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3':
  Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 401 Unauthorized
Reusing existing connection to login.oracle.com:443.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: https://updates.oracle.com/osso_login_success?urlc=v1.2%7E90F38587349B069957EEAD9271CDE9DA5D20A7061EF97051AE81D1498903E94B3E9FD2F389AFF928425B29577B7C6997302DE8A576BE62C612F2843A3DB120F50FDBA2885F9A1F7494495EB81FD9CF74E8C4062DAAB25D20E7521E3D186DFFF4D23993F16ED575729524534
0E0DF14534EAA96492718E89FA2753791A45E0082084D88F5DCFB3321026FE507ED07E3625C1EFD58115CA6E916982ABCAD7173B3721A84B749FF9760D947B031632772ACFBE642DF3C59ABE7312365332AD9093AB767B855DFCAB9B72AB485DE1AFCABD7A238F8B900DA288A08F6E3165F40891CF2EBD59CB1F6F6BEADDF8AB8F06EBC1D33F0371787F05D8E806941ABC3E29F62246DF9CCB06C36C49B5688B1CCDB616CB0FD1B37EA6CA2DD4A32FAB00452CE865C1D18FE4AD10E94C00D7D619AACDCD2 [following]
--2011-08-02 10:31:05--  https://updates.oracle.com/osso_login_success?urlc=v1.2%7E90F38587349B069957EEAD9271CDE9DA5D20A7061EF97051AE81D1498903E94B3E9FD2F389AFF928425B29577B7C6997302DE8A576BE62C612F2843A3DB120F50FDBA2885F9A1F7494495EB81FD9CF74E8C4062DAAB25D20E7521E3D186DFFF4D23993F1
6ED5757295245340E0DF14534EAA96492718E89FA2753791A45E0082084D88F5DCFB3321026FE507ED07E3625C1EFD58115CA6E916982ABCAD7173B3721A84B749FF9760D947B031632772ACFBE642DF3C59ABE7312365332AD9093AB767B855DFCAB9B72AB485DE1AFCABD7A238F8B900DA288A08F6E3165F40891CF2EBD59CB1F6F6BEADDF8AB8F06EBC1D33F0371787F05D8E806941ABC3E29F62246DF9CCB06C36C49B5688B1CCDB616CB0FD1B37EA6CA2DD4A32FAB00452CE865C1D18FE4AD10E94C00D7D619AACDCD2
Resolving updates.oracle.com (updates.oracle.com)... 141.146.44.51
Connecting to updates.oracle.com (updates.oracle.com)|141.146.44.51|:443... connected.
WARNING: cannot verify updates.oracle.com's certificate, issued by `/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3':
  Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://getupdates.oracle.com/all_unsigned/120068-02.zip [following]
--2011-08-02 10:31:06--  https://getupdates.oracle.com/all_unsigned/120068-02.zip
Connecting to getupdates.oracle.com (getupda