This is a long note but I need some help.
We are in the process of changing servers for webwork. On the new server, I am using Suse 10 (the old is using FC4 I think). I have gotten almost all of the way through the install but I have hit a glitch when I try to create the admin class from the command line. Any help would be appreciated.
What I have tried so far:
Apache 2.2.4 + mod_perl.2.03 compiled from source, using webwork rel-2-4-dev downloaded via cvs.
I have created the wwdata group and followed the install instructions for assigning permissions to the directories within /opt/webwork/webwork2 and /opt/webwork/pg and so on.
The password for webworkWrite is entered within global.conf and I have copied and pasted it with the command inside mysql to assign priviliges to webworkWrite.
I have tried to create the admin course in two different ways:
First I tried using "su" followed by the "newgrp wwdata" command. This leads to the following output:
webwork:/opt/webwork/courses # addcourse admin --db-layout=sql_single --users=adminClasslist.lst --professors=admin
error instantiating DB driver WeBWorK::DB::Driver::SQL for table set_user: DBI connect('webwork','webworkWrite',...) failed: Access denied for user 'webworkWrite'@'localhost' (using password: YES) at /opt/webwork/webwork2/lib/WeBWorK/DB/Driver/SQL.pm line 65
at /opt/webwork/webwork2/lib/WeBWorK/Utils/CourseManagement.pm line 219
This resulted in creating the directory admin under /opt/webwork/courses/
although a similar error then resulted when I tried to click on the "Course Administration" link from the website. So it seems to have done something.
Not really being an mysql expert (far from it!) the only way I could find to try something else was to use "rm -fdr admin" to remove the admin directory. This allowed me to try this second approach:
webwork:/opt/webwork/courses # sudo -u daemon addcourse admin --db-layout=sql_single --users=adminClasslist.lst --professors=admin
WEBWORK_ROOT not found in environment.
BEGIN failed--compilation aborted at /opt/webwork/webwork2/bin/addcourse line 77.
This did not even create the admin directory within /opt/webwork/courses but this gives me a little bit of hope. I have set the WEBWORK_ROOT variable in .bashrc for both my account and for root but my suspicion is that if I could somehow set this variable for the user daemon (my apache user) then maybe I could create this course. On the other hand, this does not seem to answer my first question of why the addcourse command does not work directly.
I did check to see if I could log in to mysql with the webworkWrite user account:
> mysql -u webworkWrite -p webwork
Enter password: <webworkWrite_password>
This does get me into the mysql interface with the webwork database. So I know that the password that I have chosen is working correctly (and I copied and pasted it from global.conf so that should not be in question).
After trying all of this, I realized that perhaps Novell's AppArmor was causing some problems (I have had bad experience with SELinux in this regard within the past year). So I disabled AppArmor and I get the same results as above. Having discovered that it was installed and enabled, however, I am now inclined to just leave it disabled. (After doing this, I redid the permissions on the folders just to be sure that they were set correctly).
BTW, all of this has been done through ssh since I am not able to be locally on the machine at this time.
Thanks for any thoughts,
Brian Camp
Hi Brian,
Is this a completely new installation? What does your database.conf file look like? Does it actually use $database_dsn, $database_username, and $database_password? If you had an old database.conf from 2.2.x, it might be setting the dsn/username/password internally rather than taking those values from global.conf.
That's the only thing I can think of right now.
Incidentally, you can temporarily set an environment variable as follows:
sudo -u daemon env WEBWORK_ROOT=/opt/webwork/webwork2 addcourse admin --db-layout=sql_single --users=adminClasslist.lst --professors=admin
Hope this helps.
-sam
Is this a completely new installation? What does your database.conf file look like? Does it actually use $database_dsn, $database_username, and $database_password? If you had an old database.conf from 2.2.x, it might be setting the dsn/username/password internally rather than taking those values from global.conf.
That's the only thing I can think of right now.
Incidentally, you can temporarily set an environment variable as follows:
sudo -u daemon env WEBWORK_ROOT=/opt/webwork/webwork2 addcourse admin --db-layout=sql_single --users=adminClasslist.lst --professors=admin
Hope this helps.
-sam
Hi Sam,
Thanks for the temporary environment variable help. I will try that and see if that helps (actually, see below).
This is a fresh installation. I have another server that has our older courses on it which is running webwork rel-2-3-dev. My plan is to get this server up and running and then export the courses from the old server into this one.
I have no idea if this is possible or even if it is the best way to do the transfer. I arrived at the idea to do it this way because we are upgrading the hardware at the same time so it did not seem to make sense to use the old webwork installation. Really, the courses that are there are the important part and they should work just as well in rel-2-4-dev.
About the database.conf file, I am not sure what it looks like to be honest. I am assuming that it uses the information from global.conf since that is the only place that the installation instructions said to define the variables $database_dsn, $database_username, and $database_password.
Here is my new attempt with sudo env.
webwork:/opt/webwork/courses # sudo -u daemon env WEBWORK_ROOT=/opt/webwork/webwork2/ /opt/webwork/webwork2/bin/addcourse admin --db-layout=sql_single --users=adminClasslist.lst --professors=admin
error instantiating DB driver WeBWorK::DB::Driver::SQL for table set_user: DBI connect('webwork','webworkWrite',...) failed: Access denied for user 'webworkWrite'@'localhost' (using password: YES) at /opt/webwork/webwork2//lib/WeBWorK/DB/Driver/SQL.pm line 65
at /opt/webwork/webwork2//lib/WeBWorK/Utils/CourseManagement.pm line 219
I guess not. This did however, create the admin course although I cannot log in. When I go to the admin course on the site, I get the following error:
Thanks for the temporary environment variable help. I will try that and see if that helps (actually, see below).
This is a fresh installation. I have another server that has our older courses on it which is running webwork rel-2-3-dev. My plan is to get this server up and running and then export the courses from the old server into this one.
I have no idea if this is possible or even if it is the best way to do the transfer. I arrived at the idea to do it this way because we are upgrading the hardware at the same time so it did not seem to make sense to use the old webwork installation. Really, the courses that are there are the important part and they should work just as well in rel-2-4-dev.
About the database.conf file, I am not sure what it looks like to be honest. I am assuming that it uses the information from global.conf since that is the only place that the installation instructions said to define the variables $database_dsn, $database_username, and $database_password.
Here is my new attempt with sudo env.
webwork:/opt/webwork/courses # sudo -u daemon env WEBWORK_ROOT=/opt/webwork/webwork2/ /opt/webwork/webwork2/bin/addcourse admin --db-layout=sql_single --users=adminClasslist.lst --professors=admin
error instantiating DB driver WeBWorK::DB::Driver::SQL for table set_user: DBI connect('webwork','webworkWrite',...) failed: Access denied for user 'webworkWrite'@'localhost' (using password: YES) at /opt/webwork/webwork2//lib/WeBWorK/DB/Driver/SQL.pm line 65
at /opt/webwork/webwork2//lib/WeBWorK/Utils/CourseManagement.pm line 219
I guess not. This did however, create the admin course although I cannot log in. When I go to the admin course on the site, I get the following error:
Error messages
error instantiating DB driver WeBWorK::DB::Driver::SQL for table set_user: DBI connect('webwork','webworkWrite',...) failed: Access denied for user 'webworkWrite'@'localhost' (using password: YES) at /opt/webwork/webwork2/lib/WeBWorK/DB/Driver/SQL.pm line 65
at /opt/webwork/webwork2/lib/WeBWorK.pm line 286
Call stack
The information below can help locate the source of the problem.
in Carp::croak called at line 208 of /opt/webwork/webwork2/lib/WeBWorK/DB.pmin WeBWorK::DB::init_table called at line 200 of /opt/webwork/webwork2/lib/WeBWorK/DB.pmin WeBWorK::DB::init_table called at line 169 of /opt/webwork/webwork2/lib/WeBWorK/DB.pmin WeBWorK::DB::new called at line 286 of /opt/webwork/webwork2/lib/WeBWorK.pm
Hi Brian,
The error "Access denied for user 'webworkWrite'@'localhost' (using password: YES)" says to me that WeBWorK is trying to connect to the mySQL server, and either isn't providing a password or is providing an incorrect password. Thus mySQL rejects the connection, and we get the error message.
So I think Sam's recommendation is the correct one: to make sure that the settings for the database password (and/or user) are correct. If they look right, then I'd check to see if it's possible to log in to mySQL directly (without going through WeBWorK):
$ mysql -u webworkWrite -p webwork
and then see if the password you think should work for the webworkWrite account works.
Gavin
The error "Access denied for user 'webworkWrite'@'localhost' (using password: YES)" says to me that WeBWorK is trying to connect to the mySQL server, and either isn't providing a password or is providing an incorrect password. Thus mySQL rejects the connection, and we get the error message.
So I think Sam's recommendation is the correct one: to make sure that the settings for the database password (and/or user) are correct. If they look right, then I'd check to see if it's possible to log in to mySQL directly (without going through WeBWorK):
$ mysql -u webworkWrite -p webwork
and then see if the password you think should work for the webworkWrite account works.
Gavin
HI Gavin,
Thanks for the post. I believe that the password is specified correctly in global.conf and that I have correctly set up the webworkWrite user in the mysql interface.
I am able to login as webworkWrite using the password that is specified in global.conf (and which I guess is then fed to database.conf and so on). For example,
$ mysql -u webworkWrite -p webwork
<webworkWrite password from global.conf>
...
mysql>
So I know the password is set correctly. So if the password is set correctly, then does this mean that the addcourse script is not sending the password correctly onto mysql?
Is this perhaps an issue with the update to Webwork 2.4.x? This is a fresh install so it is not like anything is left over from a previous install. This is the first time on this server for webwork so I have decided to go with the latest version (er, Sam apparently updated over the weekend so the "almost latest" version).
In a different attempt, I tried disabling the firewall to see if it was causing any problems (i.e. if mysql just was not accepting connections from perl or apache for example) but that did not seem to solve the problem.
Is there a way to specify the appropriate password for webworkWrite within the addcourse command? Maybe that could help determine if the password is actually getting passed along to mysql or not.
Brian
Thanks for the post. I believe that the password is specified correctly in global.conf and that I have correctly set up the webworkWrite user in the mysql interface.
I am able to login as webworkWrite using the password that is specified in global.conf (and which I guess is then fed to database.conf and so on). For example,
$ mysql -u webworkWrite -p webwork
<webworkWrite password from global.conf>
...
mysql>
So I know the password is set correctly. So if the password is set correctly, then does this mean that the addcourse script is not sending the password correctly onto mysql?
Is this perhaps an issue with the update to Webwork 2.4.x? This is a fresh install so it is not like anything is left over from a previous install. This is the first time on this server for webwork so I have decided to go with the latest version (er, Sam apparently updated over the weekend so the "almost latest" version).
In a different attempt, I tried disabling the firewall to see if it was causing any problems (i.e. if mysql just was not accepting connections from perl or apache for example) but that did not seem to solve the problem.
Is there a way to specify the appropriate password for webworkWrite within the addcourse command? Maybe that could help determine if the password is actually getting passed along to mysql or not.
Brian
Hi Brian,
If I had read your original post more carefully I should have left out some of my previous suggestions. Sorry about that.
Another mysql check that might be worth doing though I doubt will be helpful is to try logging in to mysql with
mysql -u webworkWrite -h localhost -p webwork
That would make sure that there isn't something funny with trying to log on with user webworkWrite and explictly stated host localhost, which is what I think WeBWorK is doing.
If that works, then there's something funny with how WeBWorK is swapping the password around. It looks as if addcourse is reading the mySQL password out from the course environment, and passing it directly to the DB::new call. You could check by editing addcourse (or copying it and editing the copy) to print out the password, but I can't find where that is in the course environment right now. I might be able to look for that later today if it's useful.
Gavin
If I had read your original post more carefully I should have left out some of my previous suggestions. Sorry about that.
Another mysql check that might be worth doing though I doubt will be helpful is to try logging in to mysql with
mysql -u webworkWrite -h localhost -p webwork
That would make sure that there isn't something funny with trying to log on with user webworkWrite and explictly stated host localhost, which is what I think WeBWorK is doing.
If that works, then there's something funny with how WeBWorK is swapping the password around. It looks as if addcourse is reading the mySQL password out from the course environment, and passing it directly to the DB::new call. You could check by editing addcourse (or copying it and editing the copy) to print out the password, but I can't find where that is in the course environment right now. I might be able to look for that later today if it's useful.
Gavin
Gavin and Sam,
I think the problem has been found. I will give a few more details later but what it amounts to is using double quotes in a place where single quotes should have been used (or maybe vice versa). Arrgh!
I'll find out the specific place that I made the mistake (yes, operator error) and post it here so that others don't duplicate my mistake. I thought I had been pretty faithful about following the installation directions online however so I am still a little perplexed.
My next task is transferring information from the old server to this new one. I am hopeful that will go pretty smoothly.
Brian
I think the problem has been found. I will give a few more details later but what it amounts to is using double quotes in a place where single quotes should have been used (or maybe vice versa). Arrgh!
I'll find out the specific place that I made the mistake (yes, operator error) and post it here so that others don't duplicate my mistake. I thought I had been pretty faithful about following the installation directions online however so I am still a little perplexed.
My next task is transferring information from the old server to this new one. I am hopeful that will go pretty smoothly.
Brian
The problem is now solved and it was something very small.
The password that I chose for the webworkWrite user in the database contained an '@' symbol which is a protected character in perl. So when this password is entered into global.conf as follows:
$database_password = "xxxx@yyyy"; (for example)
This causes a problem in perl because of how perl interprets double quotes. When double quotes are used (as it has been explained to me), perl tries to evaluate the expression inside the double quotes. Specifically, it tries to see if the expression inside the double quotes contains any variables. The @ symbol starts a variable in perl so in the above expression, perl thinks there is a variable called @yyyy within my password. This caused all of my database connection errors after this.
The fix was simply to rewrite the line as
$database_password = 'xxxx@yyyy';
with single quotes. This way perl did not try and look for any variable names within the password. (Another possible fix might have been to escape the @ symbol in the password ...)
After this I deleted the webworkWrite user from the database and then recreated it just be sure that there would be no password issues. Problem fixed :)
It might be a good idea (?) if the line in global.conf.dist might say
$database_password = ''; (with just single quotes).
Having not much knowledge of perl or mysql, I had no idea that this would/could be a problem.
Thanks for all the help,
Brian
The password that I chose for the webworkWrite user in the database contained an '@' symbol which is a protected character in perl. So when this password is entered into global.conf as follows:
$database_password = "xxxx@yyyy"; (for example)
This causes a problem in perl because of how perl interprets double quotes. When double quotes are used (as it has been explained to me), perl tries to evaluate the expression inside the double quotes. Specifically, it tries to see if the expression inside the double quotes contains any variables. The @ symbol starts a variable in perl so in the above expression, perl thinks there is a variable called @yyyy within my password. This caused all of my database connection errors after this.
The fix was simply to rewrite the line as
$database_password = 'xxxx@yyyy';
with single quotes. This way perl did not try and look for any variable names within the password. (Another possible fix might have been to escape the @ symbol in the password ...)
After this I deleted the webworkWrite user from the database and then recreated it just be sure that there would be no password issues. Problem fixed :)
It might be a good idea (?) if the line in global.conf.dist might say
$database_password = ''; (with just single quotes).
Having not much knowledge of perl or mysql, I had no idea that this would/could be a problem.
Thanks for all the help,
Brian