RootUsers

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.