We started having this issue too at the same time on all SUSs hacked with 10.8 support. Apple is now using OS detection to block 10.5 SUSs from hosting 10.8 updates. We had to remove 10.8 support from all of our hacked 10.5 servers. This makes us very unhappy. We are in the process of upgrading them all to Server 10.7 or 10.8 for those that will take it. That said, if you solved the issue please do tell.
How exactly did you "remove 10.8 support"? After you did this, did you start getting catalogs again? I'm looking at mine right now, and I do not have any "-mountainlion-" components in my catalog info in the meta/mirror-config-1.plist file. I only have the following:
<string>http://swscan.apple.com/content/catalogs/index.sucatalog</string>I'm not sure why this wouldn't work. It's actually less than was working previously, which was Leopard and Snow Leopard. What all did you revert on yours, and did it allow you do DL the catalog again?Thx,Fred
Sorry, I thought you had added 10.8 support to your 10.5 servers. Speaking of which we are getting the dreaded ...Drat failures on two of our 10.5 servers even without 10.8 support. This sounds like what's happening to you too. I've been trying to nail down why for a few days off and on. What happens is when the catalog reaches download folder 50 > 49 it spits out the error when it gets to the nested iTunesX.smb file. I have tried everything I know and could think of to fix the Drat error to no avail. I read this fixed it for one dude: http://hints.macworld.com/article.php?story=20071009082248452
Oh, no...I'm totally with you-- just wondering what you did to remove the 10.8 support and if it worked. I have indeed toyed around w/ various combinations of 10.5, 10.6, 10.7, and 10.8 updates on 10.5 SUS machines, but I've encountered this problem on almost all of them now, whether or not they were previously tested hosting 10.8 updates.
BTW, how are you figuring that the process is choking at folder 50 -> 49? Are you seeing this in the logs? I'm looking, but I don't see anything obvious.
Also, you said previously that Apple is blocking this using "OS detection"...how did you conclude this?
I assume it's the iTunesX.smb file because if I flush out the downloads folder and watch it rebuild, both boxes fail when they reach that particular file. I have tried copying parts and all of those files from working servers with no luck.
In the Access logs there are entries for "CFNetwork/438.16 Darwin/9.8.0 (i386) (MacPro4%2C1)" which I assume tells Apple's SUS mirrors that this box is running server 10.5. Could be wrong here.
I removed 10.8 support by editing the mirror-config-1.plist file to remove that string. This worked for 20 of our server 10.5 boxes but not for 2 of them. Here is the mirror-config-1.plist file that works for the 20.
Any further observations on this? Have you gotten either of those 2 stubborn boxes to work again? I kinda let it rest for a bit, but I did see where a completely fresh "downloads" directory dies when it gets to that iTunesX.smb file. I also am noticing some failures w/ some of my 10.6.8 SUS boxes to provide updates to clients where a 10.8 SUS will, so I'm thinking that Apple has done something to its upstream catalog files which is choking our 10.5 and 10.6 SUS setups...
This is for you if you still have problems. I saw your name everywhere and constantly as I got rerouted to the same 5 posts about SUS running on old powerpc servers when I was trying to fix mine. I am now serving all updates 10.5-10.8 with G5 server.
I never post anything ever online but I wanted to make sure you got the fix (and anybody else) as they were trying to make everything that SHOULD work on strong powerpc servers work, which is nearly everything since its web protocols and such.
The solution is very simple IF you had the working stuff going before using the methods found in:
which is the thread you list as using in one of your other threads discussing details before it stopped working (with ML release I have figured out).
I simply checked my catalog names using a ML install. They were right. But in doing that I had done some web searches for ML software update server catalogs, names, or whatever. Somebody in one of those threads (I am not going to find that one) said ML now uses HTTPS instead of HTTP.
I changed 'http' to 'https' in mirror config file with everything else identical to prior methods from Jan and it worked immediately downloading the updates and making the symlinks as instructed in those methods showed all updates. Im running 7 gigs of RAM and show absolutely 0 performance impact on anything, malloc errors, or anything else I saw you had going at various times so not sure about that. Did want you to know it works flawlessly with just that simple change. Probably some other people will be happy to read this also.
Incidentally, later post on page 3 gives a great way to configure WGM to handle computers logging in and get the right update catalog. Im using that as well and it seemed to identify properly so far. Thanks to that poster for that.
I have found this other thread where somebody got more advanced than me and did some rewritecond using variables that the system figures out first which I think must do what I did very simply, only more complicated. Its listed as 10.6 though and seems silly when you look at what I did:
Others note success but its very complicated compared to what I am doing, ESP if you already set it up this way before and have been following this at all waiting for a fix.
Hope this benefits somebody as it may be the last thing I ever post like this.
PS - I'm adding this error message to this fix because this is what you start to get when it breaks down if you setting up from scratch instead of having had it set up and then ML came out, SUS protocol changed to https, but you had catalogs already, that now just won't update. That should be a different error I never saw because I was setting up from new. Good Luck and I hope this saves some time, and gives some good use back to some powerpc servers.
<Error>: swupd_syncd failed with SUCatalogLoaderException: We've been foiled by the SUCatalogLoader: no local display name. Drat.
Message was edited by: ipcray
Thanks for your detailed post! I have had recent success in getting catalogs to download again w/o the "Drat" error message, so perhaps part of this is a further change to the catalogs sourced from Apple. However, I'm still unable to have my 10.5 SUSes collect _all_ 10.5-10.8 updates...see below.
Regarding your HTTPS change, can you please elaborate on what you set your entries in mirror-config-1.plist to? I tried putting each of the "merged-1" URLs in it using HTTPS, but get malloc error and swupd_sync crash every time I try to update the list.
This syntax works for us but we almost always need to flush out all the files except the downloads folder for them to work...
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
Yes, as Atom_bomb has said, the format is exactly what was working before with https instead of http for the actual catalog listings.
LOOK OUT with copy/paste because spaces will appear in those listings just like the one right above me 'sucatalo g' is in leopard.merged-1. I assume you have seen this before using these forums though and know this already.
The only thing I didnt mention in my long winded description was that I added each os level (ie, 10.5, then 10.6, then 10.7, then 10.8) only after the previous one had fully downloaded. I was starting from scratch so this didnt matter to me. I simply thought this would stress an already troubled mess less. I continue to have no problems with swupd since this setup and it is getting all updates and updating all boxes all os versions.
I am running 7GB of real RAM in quad G5 if you want for comparison.
Glad I could help you both, as I will assume you get the existing catalog error worked out (even if you have to reload all of it one good time)
Take care and GL both of you and anyone else that finds this thinking how can Apple break a web file server updater using basically open protocols to do its business.