Software Update Server, clients report "no new software available"

Question

I have been running Software Update Service on my 10.5.8 (9L30) Xserve for a short time without any problems, updating about twenty 10.5.8 clients on the local network.
Recently the clients started reporting "no new software available" when running software update (GUI or command line), but updates were available on the Xserve:
# defaults write com.apple.SoftwareUpdate CatalogURL http://myserve.mydomain:8088/
# defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://myserve.mydomain:8088/
# softwareupdate --list
Software Update Tool
Copyright 2002-2007 Apple
No new software available.
When pointing the clients back to apple for updates, the update is available:
# defaults delete /Library/Preferences/com.apple.SoftwareUpdate CatalogURL
# softwareupdate --list
Software Update Tool
Copyright 2002-2007 Apple
Software Update found the following new or updated software:
* iTunesX-9.0.1
iTunes (9.0.1), 87690K [recommended]
Clients can connect to port 8080 on the server, and the iTunes update has been downloaded to the server and is visible on the file system:
# "curl -s http://myserve.mydomain:8088/index.sucatalog iTunesX.tar
http://myserve:8088/content/downloads/05/47/061-7190/xP7dtwZz6YGXLHFHcxVT7CnV6mR dq6RnVY/iTunesX.tar"
# ls -l /usr/share/swupd/html/content/downloads/05/47/061-7190/xP7dtwZz6YGXLHFHcxVT7CnV 6mRdq6RnVY/iTunesX.tar
-rw-r--r-- 1 root wheel 54947840 Sep 22 16:20 /usr/share/swupd/html/content/downloads/05/47/061-7190/xP7dtwZz6YGXLHFHcxVT7CnV 6mRdq6RnVY/iTunesX.tar
The /var/root/Library/Caches/com.apple.SoftwareUpdate/Cache.db is extremely sparse after running the software update against the local Xserve:
# rm /var/root/Library/Caches/com.apple.SoftwareUpdate/Cache.db
# softwareupdate --list
# strings /var/root/Library/Caches/com.apple.SoftwareUpdate/Cache.db | tail
SQLite format 3
indexprotoprops_indexcfurl_cache_blobdata
CREATE INDEX protopropsindex ON cfurlcache_blob_data(entryID)P
Ytablesqlitesequencesqlitesequence
CREATE TABLE sqlite_sequence(name,seq)
[tablecfurlcache_blob_datacfurl_cache_blobdata
CREATE TABLE cfurlcache_blob_data(entryID INTEGER PRIMARY KEY, response_object BLOB, request_object BLOB,
receiver_data BLOB, proto_props BLOB, user_info BLOB)u
indexrequestkey_indexcfurl_cacheresponse
CREATE INDEX requestkeyindex ON cfurlcache_response(requestkey)r
indextimestamp_indexcfurl_cacheresponse
CREATE INDEX timestampindex ON cfurlcache_response(timestamp)
tablecfurlcache_schema_versioncfurl_cache_schemaversion
CREATE TABLE cfurlcache_schema_version(schemaversion INTEGER)
Wtablecfurlcache_responsecfurl_cacheresponse
CREATE TABLE cfurlcache_response(entryID INTEGER PRIMARY KEY AUTOINCREMENT UNIQUE,
version INTEGER, hash_value INTEGER, storage_policy INTEGER, request_key TEXT UNIQUE,
time_stamp NOT NULL DEFAULT CURRENT_TIMESTAMP)G
indexsqliteautoindex_cfurl_cache_response_1cfurl_cacheresponse
indexsqliteautoindex_cfurl_cache_response_2cfurl_cacheresponse
None of the XML data seen in the Cache.db file after running against Apple's update server is present.
Note, I did multi-home this server fairly recently to add an internal website on a different IP/URL, but I don't think that should have effected the SUS service, which is still available at the original IP/port. I am a Unix/Linux admin by training, so some of the OS X idiosyncrasies are still new to me, and I may not be aware of certain tools/commands that may be helpful in diagnosing this problem.
Thanks for your help in advance,
-Tom

Answer 1

Apologies for responding to my own post, but I believe I have found the issue and am replying with a solution for the benefit of others.
Upon reviewing my original post, I noticed that the curl request for the index.sucatalog was returning XML contents with URLs defined with only the hostname, not the FQDN, even though the CatalogURL was specified with a FQDN.
# curl -s http://myhostname.mydomain:8088/index.sucatalog | grep iTunesX.tar
<string>http://myhostname:8088/content/downloads/05/47/061-7190/xP7dtwZz6YGXLHFHcxVT7CnV 6mRdq6RnVY/iTunesX.tar</string>
This change in URL may have arisen when multi-homing my Xserve for some reason. In my case, specifying the search domain field on the clients seems to have fixed the problem as the simple hostname in the URLs are now able to resolve without the domain.