Thank you George, the sym link was not right, is didn't even work. It
does now. Also I had a problem where the owners of the folders on the
shared system were wrong, I deleted them all and turned Podcast
Producer back on and it recreated the folders. Left the
pcastserverd.plist alone.
Now I am getting to groupblog and it is failing there. It is failing
at the enclosure description for ipod_publish and audio_publish.
The variable for server_url: if the site is using ssl do we also have
to use ssl to publish to it? I changed it in the properties but it
didn't seem to make a difference.
On Feb 1, 2008, at 12:22 PM, George Cook wrote:
Robert:
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.
