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.