If you have a Solaris server that does not have direct access to the Internet and cannot perform an update, what can you do? Configure a proxy server that has Internet access of course! Here is how it’s done.
In this example we will be using the popular Squid Proxy. While this can also act as a cache we are only concerned with its proxy functionality here. We will also be configuring the Solaris publisher to make use of a proxy server so that updates are downloaded through the proxy.
We will be working with the two example servers specified below.
- Squid – 1.1.1.1 – CentOS 6.6 – This server runs Squid Proxy and has Internet connectivity.
- Solaris – 192.168.0.5 – Solaris 11.2 – Standard Solaris server, the network that it is in does not have access to the Internet. This server will connect via the Squid server to download its updates from the Internet.
Installing and configuring the Squid Proxy
In this example we will be installing Squid onto an existing CentOS 6.6 server, this can be done with ‘yum’ as below.
yum install squid -y
Once Squid has successfully installed, use chkconfig to enable it to start automatically on boot.
chkconfig squid on
Next we need to modify the configuration file for Squid, use your favourite text editor and open ‘/etc/squid/squid.conf’.
Towards the top of the file you should see some default ACL configuration as below.
# Example rule allowing access from your local networks. # Adapt to list your (internal) IP networks from where browsing # should be allowed acl localnet src 10.0.0.0/8 # RFC1918 possible internal network acl localnet src 172.16.0.0/12 # RFC1918 possible internal network acl localnet src 192.168.0.0/16 # RFC1918 possible internal network acl localnet src fc00::/7 # RFC 4193 local private network range acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
Essentially you need to have the IP address of any connecting servers defined in an ACL. In my case, the Solaris server is running in the 192.168.0.0/16 range, so I don’t need to add any additional configuration. To secure things up a bit however, I could further narrow this range down to be more explicit or only allow my Solaris server at 192.168.0.5/32. I could also remove the lines that refer to 10.0.0.0/8 and 172.16.0.0/12 as there is no reason anything within my network from these addresses would need to connect to the proxy. Basically this configuration will depend on the specifics of your environment.
At the bottom of the squid.conf file, add these lines:
via off forwarded_for off request_header_access Allow allow all request_header_access Authorization allow all request_header_access WWW-Authenticate allow all request_header_access Proxy-Authorization allow all request_header_access Proxy-Authenticate allow all request_header_access Cache-Control allow all request_header_access Content-Encoding allow all request_header_access Content-Length allow all request_header_access Content-Type allow all request_header_access Date allow all request_header_access Expires allow all request_header_access Host allow all request_header_access If-Modified-Since allow all request_header_access Last-Modified allow all request_header_access Location allow all request_header_access Pragma allow all request_header_access Accept allow all request_header_access Accept-Charset allow all request_header_access Accept-Encoding allow all request_header_access Accept-Language allow all request_header_access Content-Language allow all request_header_access Mime-Version allow all request_header_access Retry-After allow all request_header_access Title allow all request_header_access Connection allow all request_header_access Proxy-Connection allow all request_header_access User-Agent allow all request_header_access Cookie allow all request_header_access All deny all
This configuration is used to allow anonymous HTTP access through the proxy and should prevent external sources from detecting that you are using a proxy, as some services may block proxy access. It therefore may not be required in your case so feel free to test without it.
Save your changes to the squid.conf file and restart the service to apply the changes.
/etc/init.d/squid restart
If you have any other firewall in place you will need to allow TCP 3128 in to the Squid Proxy server. In this example my Squid proxy server is running iptables, so in /etc/sysconfig/iptables I have added the below configuration, followed by a restart of iptables to apply the changes.
-A INPUT -s 119.63.208.5/32 -m state --state NEW -m tcp -p tcp --dport 3128 -j ACCEPT
Modifying the Solaris publisher to specify the Squid Proxy server
Now that the Squid proxy is ready to proxy our update traffic from the Solaris server, we need to configure the Solaris server to actually use the Squid proxy. We will do this by setting a persistent proxy URI for the solaris publisher. You can view the official Oracle documentation on this process here.
First check the publishers configured as below.
[email protected]:~# pkg publisher PUBLISHER TYPE STATUS P LOCATION solaris origin online T https://pkg.oracle.com/solaris/support/
As shown we have one publisher defined called solaris, we can then look up further information on this as below.
[email protected]:~# pkg publisher solaris Publisher: solaris Alias: Origin URI: https://pkg.oracle.com/solaris/support/ SSL Key: /var/pkg/ssl/8fc38c1980d33f48bc99898f28c91f647ef126c6 SSL Cert: /var/pkg/ssl/9c8be032c740db074ef397aeb6837405cb1442c6 Cert. Effective Date: Thu May 28 09:05:55 2015 Cert. Expiration Date: Sun Jun 04 09:05:55 2017 Client UUID: 4255451e-0ca8-11e5-9f05-b7241e188f10 Catalog Updated: Fri Jun 12 18:46:04 2015 Enabled: Yes
No proxy is defined here, in order to modify the publisher configuration we first unset it then set it again with the proxy flag. Using ‘pkg unset-publisher’ as below we can remove this.
[email protected]:~# pkg unset-publisher solaris Updating package cache 1/1
Now we can set the publisher configuration, this time specifying the --proxy flag as shown.
[email protected]:~# pkg set-publisher -k pkg.oracle.com.key.pem -c pkg.oracle.com.certificate.pem -G '*' -g https://pkg.oracle.com/solaris/support/ --proxy http://1.1.1.1:3128 solaris Refreshing catalog 1/1 solaris 1.42 MB
After this is run it should try to connect through the proxy, if the command succeeds it should be working fine as during this step it will attempt to refresh the catalog. If this does not work and times out you should check the connectivity to your Squid proxy, and confirm that the Squid proxy can connect to the Internet – see the below “Confirm it’s working” section for more information.
We can now run the ‘pkg publisher solaris’ command again, this time noting that Proxy has now been set correctly as 1.1.1.1:3128 as specified.
[email protected]:~# pkg publisher solaris Publisher: solaris Alias: Origin URI: https://pkg.oracle.com/solaris/support/ Proxy: http://1.1.1.1:3128 SSL Key: /var/pkg/ssl/8fc38c1980d33f48bc99898f28c91f647ef126c6 SSL Cert: /var/pkg/ssl/9c8be032c740db074ef397aeb6837405cb1442c6 Cert. Effective Date: Thu May 28 09:05:55 2015 Cert. Expiration Date: Sun Jun 04 09:05:55 2017 Client UUID: 1ee74eb4-1096-11e5-a6e0-377344819cf7 Catalog Updated: Wed Jun 10 19:13:59 2015 Enabled: Yes
Confirm it’s working
Now that the publisher has been set up with the proxy defined, we can perform some testing. If you were able to set the publisher correctly with the --proxy flag specified it should be fine and you should be able to go right ahead and attempt to update.
From the Solaris server you should be able to connect to the Squid server on port TCP 3128, which is the default Squid port for HTTP requests. If you modified the port in the squid.conf file be sure to change it here when testing.
[email protected]:~# telnet 111.125.184.21 3128 Trying 111.125.184.21... Connected to 111.125.184.21. Escape character is '^]'. ^]
This confirms that the Solaris server is able to connect to the Squid proxy on the correct port.
From the Squid Proxy server we should be able to connect to https://pkg.oracle.com over the Internet, this is the Origin URI specified in the output of ‘pkg publisher solaris’ and will use HTTPS TCP port 443.
[[email protected] ~]# telnet pkg.oracle.com 443 Trying 137.254.56.21... Connected to pkg.oracle.com. Escape character is '^]'.
This confirms that the Squid proxy server can connect over the Internet to pkg.oracle.com over HTTPS. Just for demonstation purposes I have also run this on the Solaris server, confirming that it can not directly connect to this on the Internet, preventing it from updating without the proxy server.
[email protected]:~# telnet pkg.oracle.com 443 Trying 137.254.56.21... telnet: Unable to connect to remote host: Connection timed out
Now that the connectivity has been confirmed, an update can be performed on the Solaris server as below. Prior to specifying the new Squid proxy server this operation would time out.
[email protected]:~# pkg update Packages to remove: 3 Packages to install: 28 Packages to update: 300 Create boot environment: Yes Create backup boot environment: No DOWNLOAD PKGS FILES XFER (MB) SPEED driver/fc/emlxs 39/331 508/17769 36.4/471.1 138k/s
This traffic can be confirmed on the Squid proxy server in /var/log/squid/access.log, below is an example log entry showing the Solaris server at 192.168.0.5 connecting through the Squid proxy to reach pkg.oracle.com:443.
1434281872.774 7813 192.168.0.5 TCP_MISS/200 356457 CONNECT pkg.oracle.com:443 - DIRECT/137.254.56.21 -
Conclusion
We have installed Squid proxy onto a Linux CentOS server and allowed the IP address range of our Solaris servers to connect in through both iptables and the ACLs specified within Squids own configuration file. Next the publisher on the Solaris server was modified to define a proxy server to use, in this case our Squid server. When running an update on the Solaris server, the requests will go via the Squid proxy and out to the Internet, meaning the Solaris server can remain in it’s private network that is not directly connected to the Internet and still download updates via the proxy.
Hi , interesting article and goes some way to solving my problem. Our Squid proxy requires a userid and password and I’ve no idea where they should be stored. I’ve set up environment variables http_proxy etc with the userid and password but don’t think pkg and pkgadd understand userid:[email protected].
I’m running 11.4 and Squid is on a Linux box.
any idea?
Glenn
I’m honestly not sure on that one, it’s been many years since I’ve had to manage something like this :(
Hello Glenn
I had the same problem, solution was in the shell:
export http_proxy=”http://oracle.com\\:@proxyhost.do.main:”
the pkg publisher setting supports only proxy-settings, with UID and so isn’t supported… Seems Oracle don’t want security??? :P
how about unsetting the proxy on a container. It seems the global zone controlling it.