SUSE Conversations


Registering and updating a SLES server through an authenticated proxy

preycor

By: preycor

October 9, 2009 1:27 am

Reads:231

Comments:6

Rating:0

In most corporate environments web proxies are implemented as part of an overall security requirement. When implementing a SLES server it is just as important, from a security standpoint, to keep the server patched up to date. Being able to set the server to register and update from the command line did not seem possible until I discovered the following method.

  1. The suse_register script, which is used to perform the server registration, uses curl in order to interact with the Novell website. The first step is therefore to tell curl to use the proxy, which is done by creating the file /root/.curlrc and adding the following content. Obviously the settings in the file must correspond to the settings required in your environment.
    proxy = "https://10.10.2.10:8080"
    proxy-user = "username:password"
  2. Run suse_register as normal. The registration will appear to fail. What’s happening in the background is that the server is being registered, but is not able to subscribe to the software update channels.
  3. RCD (Red Carpet Daemon) is the background process which keeps track of available updates and listens for update commands from rug. Use the following commands after registering the server in order to set RCD to go through the proxy:
    rug set proxy-url https://10.10.2.10:8080
    rug set proxy-username username
    rug set proxy-password password
  4. Initiate a rug refresh so that the available channels can be picked up:
    rug ref
  5. Check which channels are available.
    rug ca
  6. Subscribe to the appropriate channels, for example:
    rug sub SLES10-SP2-Updates
  7. Retrieve the available updates.
    rug up

One could suggest that step 3 gets done before step 2 in order to make the process more efficient. Unfortunately this doesn’t work – suse_register appears to overwrite whatever settings are already in place for RCD. It’d be great if suse_register could take options which allow this all to be done in one shot. At the time of writing this, suse_register does allow a full registration process to be completed through an unauthanticated proxy (if you configure a proxy through YaST before doing the registration), but not an authenticated proxy.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags:
Categories: SUSE Linux Enterprise Server, Technical Solutions

Disclaimer: As with everything else at SUSE Conversations, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.

6 Comments

  1. By:currin

    Hey Dude
    Dunno if you have checked out Novell’s SMT (Subscription Management Tool). If not – you really must !!!
    It is the best thing since sliced bread, as the saying goes, we are using it to patch all our OES & SLES boxes now, and will be added SLED if we find the need, it can also do RHEL but we haven’t got the subscription for that option.
    Check this URL for a pretty thorough overview: http://www.novell.com/communities/node/5922/keep-your-linux-desktops-and-servers-updated-subscription-management-tool-suse-linux-enter
    Another option I would have tried is running a CNTLM proxy on the box while I needed to connect and then just point your proxy at localhost, but accomplished pretty much what you did anyway.
    Cheers

  2. By:preycor

    I agree that the Subscription Management Tool (SMT) is an excellent way of facilitating patch management. I implemented a previous version of it in May and haven’t had the chance to look at upgrading it to the latest iteration which includes integration with the Novell Support Advisor”.

    When deploying the SMT, the instructions in this post can help for the SMT server itself. The other internal servers will more than likely only need to access the SMT server and therefore probably won’t need to access through an authenticated proxy.

  3. By:abrahamr

    Does anyone know how to get around the issue if you have BorderManager? Client trust does not work on Linux.

  4. By:preycor

    The only way I can suggest is to setup a filter on your NBM box which allows access to the outside world via HTTP/HTTPS from your server IP range. This will be a global setting and I don’t think it’ll be logged by NBM.

  5. By:schmatzp

    Great document !
    many thanks to you.
    But, who’s going to “create” the same for SLES11 ?
    ’cause “rug” seems not existing anymore…

    thanks again,
    Pascal

  6. By:preycor

    Hi Pascal,

    It appears from this that SLES11 has moved over to zypper. It’s usage is covered here.

    I don’t currently have a running SLES11 box to figure everything out with, but I would suggest the following course of action:

    a – Use YaST’s menu option – Network Services -> Proxy – to set the proxy information.
    b – Try using YaST to register with the customer centre.
    c – If that fails, check /root/.curlrc to see whether all the proxy settings were set as described in the above article. If settings are missing, add them.
    d – Do the suse_register as described in this document.
    e – It appears that “rug sa” is replaced by “zypper addservice”. Try that with the same steps as the above article.
    f – It appears that “rug ca” is replaced by “zypper repos”. It also appears that “rug ref” is replaced by “zypper refresh”. Try those with the steps described in the above article.
    g – It appears that “rug sub” is replaced by “zypper addrepo”. Try that with similar steps to the above article.

    I hope that helps you along towards success – please post back with the final procedure if you get it right!

Comment

RSS