Thanks for your reply. You steered me in a very productive direction. I looked at the components screen on my servers (/system/console/components) and I noticed on my worker server that a number of the components are there but they say unsatisified. One such component is the MediaInspectionServiceImpl and its friend MediaInspectionRestEndpoint. So what does it take to satisfy components. I see that I can select configure from this screen and then it says:
This configuration has no associated description. It suggests that I enter Enter Name-Value pairs of configuration properties So that's where I stopped on that issue. Any suggestions are surely welcome as to how to satisfy the unsatisfied. If matterhorn were my dog, I'd know exactly what to do. I've also started investigating whether the machines can connect to one another properly. I'm able to telnet back to the admin server to 8080 and the mysql port, 3306. Meanwhile I'm doing a crash course in mysql. I was wondering if anyone can tell me whether my matterhorn database is healthy. What commands might I run and what should I see? I ask because I did the setup again on some test vms and I ran into this error: java.sql.SQLException: Connections could not be acquired from the underlying database! I can make this go away if I reference localhost in the line org.opencastproject.db.jdbc.url=jdbc:mysql://localhost/matterhorntest. Something tells me that this isn't quite what I'm after. I'm not a database or a sql guy by any stretch so any help would be much appreciated. Thanks again for your thoughtful reply. And I don't think the documentation is lacking because of language issues. I haven't had any problems understanding anyone's English. If folks are using English as a second language, it hasn't been a bother. Years ago I worked as a technical writer and documented various applications. What I saw over and over again was the developer's understanding of the software didn't really mesh with the user's perspective very well. This is not surprising and it's why I managed to make money writing manuals for companies, but technical writing isn't valued as much as it used to be. At least I couldn't make a living at it, so I started doing work as an administrator. So to make a long story short, If my university decides to proceed with this product (it's under evaluation courtesy of a grant) I'll volunteer my time to do some documentation. Well, that's my lecture for the day. Thanks again for your help. On Tue, Aug 23, 2011 at 5:53 AM, Tobias Wunden <[email protected]> wrote: > Hi Jack, > > thanks for providing the screenshots. They clearly state that you are not > running a lot of services ;-) (only Workflow and Captioning. In addition, > four of your five servers are not online (meaning either physically offline > or not properly registered in the service registry. > > I am also a little concerned about the hostnames you seem to have configured > in your "server.url" setting in config.properties: "http://.boisestate.edu"; > looks to me like some variable replacement failed. On top of that, I would > like to advise you to *always* use dns names rather than ip addresses. Using > ip addresses will turn out to be a major pain sooner or later. > > For next steps, I recommend checking the following: > > 1) Which profiles did you use to build the servers? If you are building an > admin node (e. g. using the recommended > admin,serviceregistry,dist-stub,engage-stub,worker-stub,workspace) then you > need to have the complementary services to all the -stub services running on > some other machines. If not, who should be doing the real work as your local > -stub bundles only help locating the real ones? > > 2) Make sure in /system/console/components that all of your bundles are > "Active". Additionally, you want to check the "Components" section to make > sure you have the services mentioned above running (e. g. > org.opencastproject.composer.impl.ComposerServiceImpl). > > Some general remarks: > > A) You are wondering how the services know each other. The answer is the > service registry. When a service registers it's REST endpoint as a URL, the > service is automatically registered in the service registry (a database). > From know on, everybody knows that there is a service of type x running on > machine y. That being said, the magic only works if you configure your > server.url correctly on every machine. If a service doesn't show up with a > green light on the statistics page of the admin ui, it either means that the > server is down, that the service hasn't been deployed (look for the > corresponding bundle in the felix admin console /system/console), you > misconfigured server.url or the service registry can't be reached which > should be obvious from a look at the logs. > > B) Having the line > org.opencastproject.serviceregistry.url=${org.opencastproject.server.url}/services > in your config.properties means that the server is expecting to be able to > reach the service registry endpoint on your server under the given path. This > is the case if you have "serviceregistry" in "x" your mvn -Px install … > command. If you don't and you are running the service registry on one machine > only, you need to adjust the configuration of the other machines accordingly > and make sure they are able to reach that url (firewalls!). > > C) Should you feel bothered by the poor quality of the documentation, you are > invited to participate in making it better! The documentation has been put > together by the project members, 70% of which are non-native English speakers. > > Tobias > > On 22.08.2011, at 19:36, Jack Vant wrote: > >> Before you or anyone else replies to this, please consider that I'm >> tired after working on this all weekend. I've also noticed from >> reading the mailing list archives (may as well read while maven is >> doing its thing) that what's obvious to Java folk isn't terribly >> helpful to someone who copies war files from time to time and restarts >> tomcat now and again. Examples are most helpful. For example, I've >> been wondering about this thing called serviceregistry in the >> config.properties file. What does the line: >> >> #org.opencastproject.serviceregistry.url=${org.opencastproject.server.url}/services >> >> What does this do? Might this be the answer to the missing servers? >> What do folks have on this line? What should I put on this line given >> 5 servers, admin, worker, engage, streaming and streaming all sharing >> a zfs mount for various things like inboxes and downloads? >> >> Sorry my ignorance is showing, but the necessary mind meld with the >> configuration has not taken place over the weekend. >> >> I have a masters in English and the docs sometimes make me feel like >> I'm reading Finnegan's Wake. > > _______________________________________________ > Matterhorn-users mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > -- Jack Vant System Engineer - Unix Office of Information Technology Boise State University 208-426-4443 208-863-0031 _______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
