The publish error probably doesn't have to do with your web server's
symlink. More likely it is a problem with your shared file system
setup. Make sure that the shared file system path as entered in Server
Admin for Podcast Producer is identical on all of your Xgrid nodes.
When navigating to the shared file system on all nodes, you should see
common files/folders and changes should be reflected across all nodes.
That said, what is the location of the web server's document root? The
default is /Library/WebServer/Documents/. If you haven't changed the
default, a Podcasts symlink in that directory should take you to the
Podcasts directory of your shared file system.
For example, if your shared file system was mounted at /
PodcastStorage, then you could create the symlink using:
sudo ln -s /PodcastStorage/Podcasts /Library/WebServer/Documents/
Podcasts
When you open up the Podcasts directory in /Library/WebServer/
Documents/ you should directories by date with Podcast content that
have been published with Podcast Producer.
-George
On Feb 1, 2008, at 12:42 PM, Robert Croy wrote:
I have read the logs and I know it is failing on the publish
command. I think there must be a path error to the web server but
we are sure that we made the symbolic link right, at least it is
showing the link in the WebServer/Document/PodcastStorage/Podcasts.
PodcastStorage is the shared file system using NFS.
I ran the first command below and I didn't get any feedback, is
there somewhere else that I need to look for them?
On Jan 31, 2008, at 8:01 PM, George Cook wrote:
First you need to get the Xgrid Job ID by running Xgrid Admin
application and selecting the job you need to track (ID shows up in
the information panel below)
Then you can gather logs related to your workflow running the
following command:
$> xgrid -h <FQDN xgrid controller> -auth Kerberos -job results -
id <Xgrid Job ID>
You could restrict to a particular task doing:
$> xgrid -h <FQDN xgrid controller> -auth Kerberos -job results -
id <Xgrid Job ID> -tid <Xgrid Task ID>
Finally, if you need to see the generated workflow description and
so replaced keys you could run:
$> xgrid -h <FQDN xgrid controller> -auth Kerberos -job
specification -id <Xgrid Job ID>
You can also filter the Xgrid log or the System log for failed
tasks (I used Console.app and filter for "failed"). Sometimes the
commands can be executed from the command-line by copying and
pasting (this requires a little editing). The exception are
commands that use one time passwords (-otp in the command-line). By
design, these commands can't be replayed on the grid.
