The log message saying that services cannot connect to the database is probably your biggest problem here. Configuring the DB correctly to work in a distributed environment is not difficult in itself, but can be tricky because you have to configure two or three parameters here and there.
First of all, make sure that you can reach the database locally. I do this using the following line: "mysql <db_name> -u <username> -p". You will be asked for the password, and if you can successfully connect to the database, then it's ok. Then, you have to make sure that you can reach the database from the other machine. You can do it by using "mysql <db_name> -h <hostname> -u <username> -p" from the machine in question, where <hostname> is the machine where mysql is running. This is probably going to fail in your case. If it does, please open the file /etc/mysql/my.conf and check for some line containing the key "bind-address". I guess it is set to 127.0.0.1, thus preventing your database from being connected from the outside. Comment that line out, or remove it, and restart mysql (sudo /etc/init.d/mysql restart or sudo service mysql restart). Then try to connect again. Now it should work. Perhaps there was no bind-address parameter or it is commented out. In that case, you probably haven't properly granted permissions to your user to access the database from other machine. The way recommended in the wiki is using this sql statement: > GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,INDEX ON <db_name>.* TO > '<username>'@'10.0.1.%' IDENTIFIED BY '<password>'; > , where you must substitute the '10.0.1.0' by according to your network and subnetwork configuration, i.e. for a 192.168.0.0/11-type network, you should use '192.168.0.%'. This enables every machine in the subnet to access the database with the username and password specified, but you can of course add permissions for a certain user in a certain machine: you only need to issue several statements like the previous one, using the complete machine address (or its url) instead of the pattern, for instance '192.168.0.128' or ' myserver.mydomain.edu'. After configuring your user grants correctly, you should be able to connect to the database using the command in the previous paragraph. If this works, but the "cannot connect to the underlying database" keeps failing, double-check the DB parameters in felix's config.properties. Don't forget to use the right URL for the database server, and not localhost. If all the previous is done and the error keeps showing, I'm sorry but I cannot figure out what the problem is. However it usually comes from one of the previous causes. Good luck, Rubén 2011/8/25 Jack Vant <[email protected]> > 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 >
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
