• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1365
  • Last Modified:

Moving the Software Update Server data store off the startup disk

Has anyone succeeded in moving the Software Update Server data store off the startup disk?

The default data store is /var/db/swupd/ on the startup disk. Whenever I change the setting (in Server Admin) to a location that is not on the startup disk, the sync to Apple's server fails, and the Software Update Server error log says:
Syntax error on line 287 of /etc/swupd/swupd.conf:
DocumentRoot must be a directory

Line 287 of /etc/swupd/swupd.conf contains the URL of the data store.

I have tried all kinds of locations and made sure that the privs are correct. No luck.

Any ideas?
0
nxnw
Asked:
nxnw
  • 12
  • 6
  • 2
  • +1
3 Solutions
 
nappy_dCommented:
Try creating a symlink to a different location.
0
 
Parrish ChamberlainCommented:
Are you attempting this through the cosole or another utility?
It is important to rember whenever you make a change to a path you use SUdo command or if another utility has the run as  option you type root.

Sudo runs as root administrator.
I use apple Remote Desktop to assit in automation of such tasks, there are also a number of scripts also you can find that run in automater (Part of the OSX) that willl assist http://support.apple.com/kb/ht2488

Also keep in mind the default  apple update store is in /Library/Packages




0
 
nxnwAuthor Commented:
Sorry for not being clear. I am talking about the data store for Software Update Server. This is a server issue, not a client issue.

I have used Server Admin to change it. See attached image (showing the default data store).

If the data store is moved from the startup disk, it fails to download updates from Apple.

I had not tried using a symlink because I read elsewhere about someone trying that without success as well. Maybe because /var/db/swupd/ is also symlink?
Screen-shot-2010-11-12-at-9.00.4.jpg
0
Prep for the ITIL® Foundation Certification Exam

December’s Course of the Month is now available! Enroll to learn ITIL® Foundation best practices for delivering IT services effectively and efficiently.

 
Parrish ChamberlainCommented:
I have noticed you are using port 8088, try changing to 8080.

ALso you can try this link
 http://serverfault.com/questions/11410/how-do-i-change-the-software-update-server-address-on-a-client-mac-to-use-my-own
It contains information using various scripting methods to cahnge software store.
0
 
gmbaxterCommented:
I also have the same issue under 10.5 server. One thing I haven't tried is checking permissions on the original swupd folder - the owner may be _www if so create your folder with the same permissions perhaps?
0
 
nxnwAuthor Commented:
The privileges are identical to the original. First thing I checked.

Technocity, port 8088 is correct and, I reiterate, the question is not about clients getting updates.
0
 
gmbaxterCommented:
it seems that the actual location of software updates is /usr/share/swupd. Try symlinking to this folder with the location you desire to store them in.
0
 
nxnwAuthor Commented:
The location used to be "/usr/share/swupd/". Under 10.6 the default location really is /var/db/swupd/. I am going to try symlinking that.
0
 
nxnwAuthor Commented:
A bit different using the symlink, but still failing.

The (spurious) "Syntax error on line 287 of /etc/swupd/swupd.conf" error seems to be gone, but software update server is still failing with the same error in the software update service log as before:
<Error>: Unable to retrieve catalog(s) from the Apple server

I have reported this to Apple as a bug. I will post Apple's response, if it is in any way enlightening, and leave this item open in the interim.

Of course, if anyone has managed to make this work, that would be really interesting to know.
0
 
gmbaxterCommented:
I've managed to do it on a 10.6 software update server.

I stopped the software update service
Opened settings for software update in server admin
Under store updates in: "\Volumes\Data4RaidSet\SWUpdates\"
Started software update service

This produced no errors.

The permissions are as follows:

SWUpdates folder:
user _softwareupdate read and write
group _softwareupdate read and write
others read only

Everything within the folder recursively:
user _softwareupdate read and write
group _softwareupdate read only
others read only

Here is the Document Root from my swupd.conf file:

DocumentRoot "/Volumes/Data4RaidSet/SWUpdates/html"

There is also another reference to my path:

<Directory "/Volumes/Data4RaidSet/SWUpdates/html">

Hope this helps!
0
 
nxnwAuthor Commented:
Well, I tried exactly what you did (except that the volume I used was not called "Data4RaidSet") and it failed again. I even used the same name as you, "SWUpdates" instead of swupd, as I had previously and put the SWUpdates folder in the root directory of the volume (whereas it had previously been deeper).

Would you mind providing an ls -aleF of the SWUpdates and html directories? My posix permissions are exactly like yours, but maybe you have some acls.

Also, the volume I tried using contains a sharepoint. Does yours?

Lastly, should I be inferring from the backslashes in "\Volumes\Data4RaidSet\SWUpdates\" that the volume is not hfs+?

Other then the above, I cannot think of what might be different between our respective configurations.

Thanks.
0
 
nxnwAuthor Commented:
gmbaxter: Could you please check one more thing? Does disk utility show your "Data4RaidSet" as "Owners Enabled: Yes"?

I have never noticed "Owners Enabled" before, but the startup volume is the only volume on my server that shows  "Owners Enabled: Yes" in disk utility. On the other hand, the terminal command "diskutil info device" shows every volume as "Owners: Enabled". Perhaps that's another bug.
0
 
gmbaxterCommented:
Hi,

Apologies for the delay.

studentdata4:Data4RaidSet root# ls -aleF | grep SWUpdates
drwxrwxr-x    3 _softwareupdate  _softwareupdate       102  7 Dec 10:47 SWUpdates/

studentdata4:SWUpdates root# ls -aleF
total 0
drwxrwxr-x   3 _softwareupdate  _softwareupdate  102  7 Dec 10:47 ./
drwxrwxr-x  12 _unknown         _unknown         476  7 Dec 10:46 ../
drwxr-xr-x  10 _softwareupdate  _softwareupdate  340  8 Dec 03:00 html/

The Data4RaidSet Volume contains a sharepoint with users home folders in.
Volume is Mac OS Extended (Journaled) - HFS+
Owners are disabled on the volume, but are enabled on the startup volume.
diskutil info device also shows bot of my volumes as owners enabled - definately a bug

Hope this helps you - anything else let me know
0
 
nxnwAuthor Commented:
Except for ownership of the root directory (admin:staff on mine), everything is the same. I am afraid that this is going to be one of those things where it works or fails depending on the order of upgrade installations, or some similarly arbitrary factor, that resulted in some defect in my OS. I know this has happened to others, because there are (unresolved) posts in the apple forums.

Thanks very much for your efforts and quick response.
0
 
gmbaxterCommented:
No problem, hope you manage to get it sorted out.

For reference this server was built with 10.6.3 retail disk and upgraded to 10.6.4.
0
 
nxnwAuthor Commented:
Although this is not resolved, I would like to keep it open until the cause is clarified (as it seems to work for in some cases and not in others).
0
 
gmbaxterCommented:
have you submitted a bug report to apple?

https://bugreport.apple.com/
0
 
nxnwAuthor Commented:
Several weeks ago.
0
 
nxnwAuthor Commented:
Update: workaround identified. In a nutshell there appears to be a bug in the algorithm that causes it to fail based on the privileges to the root directory — although it is not writing to that directory. The fix was to change the privileges to the root directory. It may be that only the last change (giving read/search privileges to "other" was required.  See details below.

A mere four months after I reported this bug to apple, and provided the information they initially requested, they got back to me and instructed me to use a terminal command to crank up the logging to debug, try to sync, and to report back.

The debug log, so produced, included a spurious error message stating that the folder "Software" could not be created on volume "Archive". Software was, in fact, an existing folder in the file path to the swupd folder, and did not have to be created. Moreover, the owner, group and privs for swupd were all correct.

Mindful of this error message, I changed the the "Store Updates In" setting to /Volumes/Archive/swupd, and restarted. Now, SUS duly created the swupd folder in Archive, and gave it the correct owner/group/permissions — but sync failed again, incorrectly reporting that the folder "swupd" could not be created on volume "Archive".

Since the incorrect error messages were focussed on the volume, rather than the directory where swupd was to be located, I compared and trued up Archive's privileges with the privileges on my startup disk and retested.

- changed owner from admin to root - sync failed
- changed group from staff to admin - sync failed
- changed privs from 750 to 770 (gave write privs to group) - sync failed
- changed privs from 770 to 775 (gave read/search privs to other) - sync worked

I have not backtracked to see whether only the last change was required, or whether others were needed as well, but the above should enable others who encounter this problem to deal with it.
0
 
nxnwAuthor Commented:
Want to award assist.
0
 
nxnwAuthor Commented:
my comment details the fix.
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 12
  • 6
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now