SMT enhancement requests -> black hole

Hi folks,

As a result of a recent discussion thread here, i logged a series of
enhancement requests about SMT. I'd like to know the thoughts of other
SMT users about them - the full text of each is below. With respect to
the first two, i don't know whether to laugh or cry. I've received no
communication from Novell about any of them, even though my email
address is correctly registered on each enhancement request. Does
anyone know how if there is a better channel than this to talk to Novell
about the product? They certainly don't seem very interested in
conversation...

I have half a mind to develop a better alternative and release it as
free software just to prove how wrong they are. ;-)

Thanks,
Paul

------------------------------------------------------------------------

Request Information
Request ID 14093
Request Date 07 Oct 2009
Request Type Enhancement Request for Existing Product
Request Title Download only updates which are required
Problem Description

As the system administrator of a number of systems on the wrong side of a 4 MB link to the Internet, i would like SMT to download ONLY the LATEST versions of packages which are already installed on the systems which it manages (and dependencies of those packages).

My SMT server currently has mirrored a huge number of packages which i do not use, which is wasteful of disk space and bandwidth, and degrades performance of both my servers and Novell's.

I would be happy to wear an initial download delay in order to achieve this (i.e. the first system requesting a patch would need to wait for the patch to be downloaded), although intelligent pre-caching would obviously be preferred.

Proposed Solution

SMT would need to implement an intelligent cache rather than a monolithic repository. This has been achieved with a simple squid redirector script for earlier versions of Windows updates by someone not associated with Microsoft (see http://glob.com.au/windowsupdate_cache/). Surely with full access to internal resources, Novell should easily be able to replicate and improve on this functionality.

Perceived Benefit

* Saved bandwidth on Novell and customer servers due to obsolete and non-required patches not being downloaded.
* Improved performance for Novell customers due to lower load on servers and Internet links.
* Lower overheads in managing disk space.


Status Information
Status Not Accepted
Reason Insufficient business case.


------------------------------------------------------------------------

Request Information
Request ID 14095
Request Date 07 Oct 2009
Request Type Enhancement Request for Existing Product
Request Title SMT co-existence with Novell Customer Center
Problem Description

SMT cannot be used in parallel with the Novell Customer Center. This means that if the SMT server is unavailable for any reason, security patches are not applied to ANY clients of SMT, leaving large numbers of systems vulnerable.

Proposed Solution

SMT should permit coexistence with the Novell Customer Center so that if it is unavailable, client systems can fall back to using NCC for updates.

My preferred mechanism for this is for SMT to exist as a simple software source just like locally-served OS install repositories or Service Packs. Then a simple priority based cascade system just like that used in openSUSE 11 could be implemented - systems could prefer a local update server, but leave the NCC in their list at a lower priority, and software updates could automatically fail over to the lower priority servers in the event of a failure.

Of course, this would also require a different process for registering NCC vs. SMT, but this is desirable anyway.

Perceived Benefit

* Resilience to software or hardware failure.
* More timely application of security fixes in the event of a failure.


Status Information
Status Not Accepted
Reason Insufficient business case.


------------------------------------------------------------------------

Request Information
Request ID 14094
Request Date 07 Oct 2009
Request Type Enhancement Request for Existing Product
Request Title Automatic selection of appropriate SMT catalogs
Problem Description

As the system administrator of a number of SLES systems managed with SMT, the management of SMT catalogs (using the smt-catalogs command-line tool) is a confusing, inconvenient, and error-prone process. I would like these catalogs to be selected automatically by SMT.

Proposed Solution

When a system is initially registered with SMT, SMT should detect which catalogs it requires and update its lists accordingly. Catalog selection should be completely automatic and require no manual intervention. System administrators should be able to query which systems require which catalogs as a verification step.

Perceived Benefit

* Guaranteed correct selection of update sources.
* Reduced overhead on administrative staff.
* Reduced window of vulnerability to security flaws due to complete coverage of all available products without manual intervention.


Status Information
Status Need Info


------------------------------------------------------------------------

Request Information
Request ID 14096
Request Date 07 Oct 2009
Request Type Enhancement Request for Existing Product
Request Title Web interface to SMT
Problem Description

SMT provides no tools to determine how many clients are registered with it, which systems they are, or whether they are up to date. It provides no mechanism for centralised control of client systems.

Proposed Solution

SMT should provide a web-based console which lists the details of the systems it is managing, including their hostname, IP address, architecture, operating system & service pack versions, whether they are up-to-date, and whether they need a reboot. It should be possible from this console to roll out a set of updates to groups or individual systems, on either a scheduled or interactive basis.

Microsoft WSUS would serve as a useful comparison point for review of functionality when creating this interface. (Note, however, that WSUS' limited cross-platform functionality should not be imitated!)

The maximum possible SMT functionality should be accessible through this web interface, which should not be limited to either Windows or Linux client platforms. Preferably, other Linux distributions such as Debian, openSUSE, Red Hat/CentOS, and Ubuntu should be supported as clients, and ideally as servers also.

Perceived Benefit

* Easily accessible visual indicator of SMT client status.
* Greater confidence for sites with low Linux skills that their systems are up-to-date and secure.


Status Information
Status Submitted for Review