SUSE Conversations


What the world needs now is a better SMT

paulgear

By: paulgear

December 14, 2009 11:31 pm

Reads:263

Comments:3

Rating:0

Novell’s SMT (Subscription Management Tool) is a software update tool for SUSE Linux Enterprise and openSUSE.  I’ve had the dubious honour of working with it over the last few months on a customer site.  These notes were compiled as a result of installing SMT on three different servers, and interacting with various people in the Novell forums, especially the novell.support.sles.updates forum.

What’s wrong with SMT?

  • SMT is a mirrored repository, not a proxy.  That is, it has to download the entire distribution, even if you don’t use it.  Not only that, but as far as i can tell, SMT must successfully mirror a complete copy of the catalogue before any client systems can be updated.  I logged enhancement request 14093 to ask to have this fixed, and it has been rejected as having an “insufficient business case”.
  • SMT doesn’t work out which updates its clients need and mirror them automatically.  Instead, sysadmins must know which catalogues their systems need and manually configure these catalogues to be mirrored.  The biggest reason this is a problem is that it can result in some security updates not being applied to systems due to their catalogues not being available on the update server.  The catalogues are named rather obscurely, such that Novell released TID 7001199 to help customers determine which catalogues to mirror.  The TID itself is rather obscure and this suggests that there is a more fundamental issue: flawed design.  I logged enhancement request 14094 to ask for this to be fixed, and again, it was rejected, this time for the reason “Does not align to [sic] Novell strategy”.
  • SMT doesn’t coexist with the Novell Customer Center, so it is a single point of failure (SPOF) for software updates (unless it is clustered, and the SMT documentation doesn’t contain any information about whether this is possible or recommended).  I logged enhancement request 14095 to request this to be fixed, which was rejected, once again for “insufficient business case”.
  • SMT doesn’t have a web interface.  In the “Web 2.0″ world, this is the most inexplicable drawback of all.  Novell works mostly in the Windows world, and if they want their customers to convert from NetWare to SUSE Linux Enterprise, they need to provide users working in a Windows environment (often with little Linux experience) with an easy interface which gives them confidence that their Linux systems are updating frequently and reliably.  I logged enhancement request 14096 asking for this to be added.  It is currently “under consideration”.

The bottom line with SMT from my perspective is that it is designed to solve Novell’s problems rather than their customers’.  The Achilles heel of SUSE Linux Enterprise is its update process, which is crippled by being tied to Novell’s licensing model.  This is a lose-lose proposition: the customer loses because the update process takes longer, needs registration (which is often flaky), and requires live HTTPS connections to the Novell Customer Center (which can’t be cached by a local squid proxy); Novell loses because their customers are less inclined to deploy a system which doesn’t update reliably.  I personally recommend to my clients that they deploy Debian GNU/Linux in all situations where they don’t need the NetWare integration which OES/Linux provides. (See this Novell forums thread for an example of the unreliability of Novell’s patching process.)

What’s right with SMT

All this said, there are some things that SMT does right:

  • It succeeds in making the update process considerably faster on both SLES 10 and SLES 11.  A faster Internet connection might mitigate this somewhat, but i expect Novell’s servers are part of the problem.)  The customer on whose network i implemented SMT has a 4 Mbit synchronous wireless connection to the Internet, and updates were positively painful until SMT was implemented.
  • It removes the need for each system to be individually registered with a license key (at least for those customers licensed with SLAs), eliminating a pointless manual step in the setup of new servers.

What SMT needs

These are the features i think SMT needs (besides those already mentioned above) to have in order to make it a really compelling choice for sysadmins to install on their networks.  Many of these are unabashedly modeled on Microsoft WSUS – in my opinion it is a far superior product which makes managing updates on Windows much easier than using SMT to manage updates on SLES.

  • Administrator-defined grouping of hosts and releasing of updates to those groups.
  • Complete management of software repositories on all clients, so that, for example, an OES2 installation source can be added on a selected list of hosts without manual intervention on every client.
  • Space and bandwidth efficiency, so that older, obsoleted versions of current packages are cleaned up automatically, and not downloaded when a new catalogue is mirrored.  Of course, moving more towards a Debian-style update process or a proxy-based design rather than a mirroring-based one would remove the need for this.
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

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.

3 Comments

  1. By:FBezemer

    Have you looked at ZLM (ZENworks Linux Management)
    Works really well, has a webinterface etc.
    Supports SLES/OES/RedHat (no OpenSuse at the moment though)
    I have implemented it at a number of sites already and I really like it.

    The new version will merge the ZCM and ZLM consoles into one as well!

  2. By:paulgear

    ZLM definitely sounds like a better option (although i can’t really say because i’ve never installed it). On the other hand, it is a much heavier product in terms of system requirements, cost, complexity, and setup (which i can say from looking at the documentation).

    My hope in publishing this blog entry here was to generate a bit of discussion about SMT and its future. In the forums someone suggested that SMT seems like a 0.3 release, not 1.1, and i fully agree. Hopefully Novell will come to see that it’s not useful enough as-is, and that to turn it into something bigger makes it a competitor to ZLM, whereas i think it needs to be positioned more as a competitor to Red Hat Network (RHN) and Microsoft WSUS.

  3. By:csilvaslv

    After a wasted Friday night (There ws a problem with the Novell update site/processes) I was starting to get interested in SMT – used to run the old YOU server and that made life easier (before it became SMT).

    I can only concur wholeheartedly about the flakiness and poor performance of the update process for SLES.

    You would think that the one thing that enables Novell to gain revenue from an otherwise open source solution would demonstrate the value of paying for it and the opposite is the case!

    I can only concur as well about the issue of disk space. Maintaining every part of the software repository to enable updates doesn’t look reasonable for only six servers but i am considering it because of the poor performance of the update servicve – something needs to get better!

Comment

RSS