Table 'drupal.ldapauth' doesn't exist

Please read

http://drupal.org/node/92407#comment-178886

I have this very issue but the doc that the issue refers - http://drupal.org/node/92407#comment-178886 - doesnt seem to answer the question.
When I install the ldapauth mod, the MySQL table does not get created. Any ideas?
Thanks!

Jeff

Upgrade to latest release - 5.x-1.2.

Make sure to run update.php; you might have to select the latest ldapauth upgrade version manually.

If it doesn't make any changes, then drupal believes you are already updated to the latest version. You can reset that with the following sql (assumes you have no table prefixes):

update system set  schema_version = 0 where name = 'ldapauth';

Then rerun the update.php. You will probably see some errors during the update since it will try to make changes to the DB that have already been made for version 1 for example, but it will not cause any harm. Those changes will just fail.

Thanks - this is the last peice I need working before showing this to the folks who want it set up and Im a bit under the gun...
I tried this but still no luck.
When I go to Site Configuration > LDAP Integration I still get this;

user warning: Table 'drupal.ldapauth' doesn't exist query: SELECT sid, name, status FROM ldapauth ORDER BY sid in C:\Inetpub\wwwroot\includes\database.mysql.inc on line 172.

and when I try to configure the LDAP server I get this;

user warning: Table 'drupal.ldapauth' doesn't exist query: SELECT name FROM ldapauth WHERE name = 'ADBind' in C:\Inetpub\wwwroot\includes\database.mysql.inc on line 172. user warning: Table 'drupal.ldapauth' doesn't exist query: INSERT INTO ldapauth (name, status, server, port, tls, encrypted, basedn, user_attr, mail_attr, binddn, bindpw) VALUES ('ADBind', '1', 'rmc2k3dc1.rmc.edu', '389', '0', '0', 'cn=faculty, cn=rmc community, dc=rmc,dc=edu', 'sAMAccountName', 'mail', 'rmc\\ldapdrupal', 'Nastucr87RAS') in C:\Inetpub\wwwroot\includes\database.mysql.inc on line 172. user warning: Table 'drupal.ldapauth' doesn't exist query: SELECT sid, name, status FROM ldapauth ORDER BY sid in C:\Inetpub\wwwroot\includes\database.mysql.inc on line 172.

Prior to this, I had deleted the ldap fields under system and downloaded ldap_integration-5.x-1.2.tar.gz, unpacked it to sites\all\modules. Am I doing something wrong (newbie...)? Is there any way to determine why the ldapauth table is not being created? Is there another way to be sure that it is completely backed out before trying again?

Thanks again!

Jeff

jhague,

I think the point of referencing that comment was to make sure you uninstall all prior version of ldap_integration. There was a major rewrite for the 5.x branch.

It would be easier to read the errors if you put them in code or blockquote tags. Also next time (or maybe go edit your comment), you might want to obfuscate your ldapdn password.

Let's cover some basics.

• You're running Drupal 5.1 & LDAP_integration 5.x-1.2?
• This is a new install, not a Drupal 4.7 upgrade?
• The first ldap_integration module you installed was release 5.x-1.0, nothing prior 5?
• You've confirmed that php has ldap library built in?
• You have the ldap_integration folder only in sites/all/modules - no duplicates in any other module directory?
• Did you really delete the record from the system table as you said or just set the schema version to 0 as I suggested?

No matter how foobared I've gotten the ldap module while testing, these steps have always straightened it out. Try this:

1. turn off all ldap modules in admin/build/modules;
2. uninstall ldapauth in admin/build/modules/uninstall (check the ldapauth table & the system -> ldapauth record is removed from the DB);
3. delete the ldap_integration folder from the module directory;
4. untar the latest release into sites/all/modules;
5. in drupal, turn on ldapauth (check that the ldapauth table was recreated along with the ldapauth record in the systems table);
6. setup at admin/settings/ldapauth;

Sorry - new here... I dont know how to put them in code or blockquote tags. I also didnt realize that my password was displayed - staring at a screen far too long today...
Other responses below.

I am running Drupal 5.1 & LDAP_Integration 5.x-1.2

It is a new install - downloaded Drupal this past Saturday.

I believe the first version I tried was 5.x-1.2 - downloaded it yesterday.

php_ldap.dll is installed and uncommented in php.ini

I dont see any duplicate folders anywhere

I did delete the ldap records from system and set the schema version to 0 but not the first couple of times I tried uninstalling/installing it. When I first ran the SELECT name FROM system statement in PHPMyAdmin, I didnt see the ldap records so I assumed they were never created - it turns out that I haddnt drill down far enough. This last time, I deleted the records from system and set the schema version to 0.

I followed your list of steps with the same results - ldapauth table does not exist. From checking with PHPMyAdmin, the ldapauth table was not created but the ldap records were created in system.

Reaching for straws, I uninstalled (per your steps) and downloaded LDAP 5.x-1.1. That seems to install fine and doesnt throw any errors. I could not log on against AD but I think my base DN may have been wrong. It also did not create an ldapauth table but it did create the ldap records in system.

Is it possible to install that and then upgrade it to 5.x-1.2?
Does 5.x-1.2 create a seperate table but 5.x-1.1 does not?
What would keep it from creating the table?
Thanks again!

Jeff

Blockquote and code tags are just html tags (all possible tags listed at bottom of comment textarea). So you could type:
<code>
Code or error goes here
</code>

I'm not sure what you mean by:
This last time, I deleted the records from system and set the schema version to 0.
I'm confused because the schema attribute is in the system table, so you couldn't have deleted the ldapauth record from the system table and set the ldapauth schema level to 0 in the same table. Probably you mean you deleted the ldapauth table and set the ldapauth schema version attribute to 0 in the system table. But since you didn't say that, I'm not sure what you did. Please take the time to give clear, objective, unambiguous information. It is only courteous and more importantly will lead to a solution more quickly.

Reaching for straws, I uninstalled (per your steps) and downloaded LDAP 5.x-1.1. That seems to install fine and doesnt throw any errors. I could not log on against AD but I think my base DN may have been wrong. It also did not create an ldapauth table but it did create the ldap records in system.

Again this doesn't add up. The older release could NOT have "install[ed] fine" if "it... did not create an ldapauth table" since that is part of the installation. Just to be absolutely clear, the ldapauth module will not work without the ldapauth table. In fact, your base DN was definitely wrong because without an ldapauth table, there was no base DB to use. You should have gotten a lot of errors after saving the ldapauth settings page. You did reset the base DN, user attr, mail attr, & etc right?

More questions...

• Did you go to the ldapauth settings page to create the ldap server settings?
• Have you checked the drupal logs for other sql errors unrelated to hte ldap_integration module?
• Are you using MySql as the DB?
• Have you double checked your settings.php file is correct, specifically the $db_url?
• Have you installed any other modules, created any content, or customized your drupal install in any other way yet?

Off the cuff, I'm guessing your problem has nothing to do with the ldap_integration module. I believe that because I took a fresh install of drupal 5.1 and installed the ldap_integration module from the latest release as I described yesterday. It did create the ldapauth table. Which seems to be the root of your problem. There is no ldapauth table, hence their is no server information. But the question is why isn't the installation working? Seems like only obvious reason is the db user account used in the settings.php file doesn't have enough permissions. I wouldn't recommend using this grant statement for a production site, but for testing your user settings (on MySql) execute:

grant all on <db name>.* to '<db username>'@'<localhost or drupal server if different>' identified by 'some password';

If you are using Postgress for the DB, the cause might be related to that - For a hack c/o http://drupal.org/node/132065; I haven't had a chance to fix it in HEAD, but plan to in the next couple of days, maybe tonight.

If none of those are true, I'd say your best bet is to delete the whole installation and start over. Obviously the decision to do this needs to be balanced by how much effort you've already put into the site that would have to be repeated.

I am sorry if Im not being clear, I am trying to answer these questions as well as I can...

I have installed and uninstalled the 5.x-1.2 and 5.x-1.1 ldap modules several times and the ldapauth table has not been created during any of those attempts. Every time I have enabled the module (5.x-1.2) and then gone to the configuration page, I have received the ldapauth table does not exist error. I did not receive that error with the 5.x-1.1 module but I also did not see an ldapauth table when looking at the db through PHPMyAdmin.

I have gone to the ldapauth settings page and created the ldap server settings. The 5.x.1-2 module threw a lot of errors when I clicked to save the configuration but it did store the values (except port number). I could navigate away from the page and go back and the info was still there. The 5.x-1.1 module did not report any errors.

I have not checked any logs directly because I do not know where to look or what to look for. I have checked the log entries presented by Drupal but they dont give much detail - they just list the same errors that I see on the settings page.

I am using MySQL 5.0.37, PHP 5.2.1, Windows Server 2003 & IIS6. Everything else seems to be working as expected.

Settings.php appears to be correct; $db_url = 'mysql://user:pwd@localhost/drupal'; (I changed the user and password here but they are correct in the production file).

I have installed quite a few other modules including blogger, bloginfo, buddylist, cck, chatroom, daily, date, epublish, faq, htmlarea, jeopardy, question, survey, weather, wikitools (to name a few). The only issues I have run into were that I could never get the Tinymce editor to show up anywhere once installed so I decided to use htmlarea instead. I had some trouble with that one too until I found better documentation.

I dont mind re-installing as this is a test installation to determine if we want to use Drupal or not. I just want to be sure that I wont run into the same issue a second time around...

Could the number of installed modules or the order in which they were installed be a problem?
Should I look at Drupal 4.7.6 or are the enhancements in 5 that significant?
Where can I find the logs and what kinds of things might I want to look for?

Thanks again!

Jeff

I understand, especially with something new, that things can get confusing. It just ends up wasting time. I believe the improvements in Drupal 5 are huge. Also the ldap_integration for 4.7 is not as stable or feature rich compared to the 5.x branch.

Recent logs are available at admin/logs/watchdog in drupal. There are other options at administer >> log menu. After enabling the ldapauth module at admin/build/modules, go to the logs page and see if there was an error. That is when the ldapauth table should get created. If possible, check for errors in the webserver log as well. The error message I need is the one when the module is turned on. You might not see the error message unless you first uninstall the module as I described previously.

Did you try increasing the permissions for the site db user?

I doubt that the order or number of modules is having an effect, but it is possible. To figure that out, you would need to start from scratch and add one module at a time. Start with the ldap_integration module.

You don't have to redo everything for the test. Without touching your current site, unpack Drupal 5.1 to a new folder. Create a new DB. Untar the ldap_integration module to sites/all/modules and set it up. See if the ldapauth table is created. If it is, trying setting up the ldap server and authenticating. If you get that far, you get to choose if you are going to move to the new site or use it to debug the first - your decision.

OK - this is the log entry after unpacking the module and enabling it;

BLOB/TEXT column 'basedn' can't have a default value query: CREATE TABLE ldapauth ( sid int NOT NULL auto_increment, name varchar(255) NOT NULL default '', status int NOT NULL default '0', server varchar(255) NOT NULL default '', port int(10) NOT NULL default '389', tls int NOT NULL default '0', encrypted int NOT NULL default '0', basedn text(1000) NOT NULL default '', user_attr varchar(255) NOT NULL default '', mail_attr VARCHAR(255) NOT NULL DEFAULT '', binddn varchar(255) NOT NULL default '', bindpw varchar(255) NOT NULL default '', bindpw_clear varchar(255) NOT NULL default '', ldap_groups_in_dn int NOT NULL default '0', ldap_groups_in_dn_desc int NOT NULL default '0', ldap_group_dn_attribute varchar(255) default '', ldap_group_attr varchar(255) default '', ldap_groups_in_attr int NOT NULL default '0', ldap_groups_as_entries int NOT NULL default '0', ldap_group_entries varchar(255) default '', ldap_group_entries_attribute varchar(255) default '', ldapdata_binddn VARCHAR(255) NOT NULL default '', ldapdata_bindpw VARCHAR(255) NOT NULL default '', ldapdata_bindpw_clear VARCHAR(2) NOT NULL default '', ldapdata_rwattrs LONGTEXT NOT NULL default '', ldapdata_roattrs LONGTEXT NOT NULL default '', ldapdata_mappings LONGTEXT NOT NULL default '', PRIMARY KEY (name), KEY sid (sid) ) /*!40100 DEFAULT CHARACTER SET UTF8 */ in C:\Inetpub\wwwroot\includes\database.mysql.inc on line 172.

The site db user has all privileges on the drupal db.

I hadnt thought about just unpacking a second Drupal folder but that sounds pretty easy - Ill give it a shot.
Thanks again!

Jeff

FYI - on a second install of Drupal, same error...
Could it be an IIS6 issue? IIS6 does not seem to be officially supported.
Could it have something to do with the MySQL install?

Jeff

Indeed it seems to be a mysql on M$ Winblows specific problem. From your most recent error:

BLOB/TEXT column 'basedn' can't have a default value

I checked the MySql docs and looks like the error is accurate, though it only causes a failure that I've heard of running on win. If you can't wait for a fix, you can fix this on your copy by editting ldapauth.install with your favorite editor.

In the mysqli case, change:

       basedn text(1000) NOT NULL default '',

To:

       basedn text(1000) NOT NULL,

Then re-enable ldapauth module on modules page.

Thanks! Thats almost got it, I think.
After making the change you recommend to ldapauth.install, I no longer get the error when I enable the module but I do still get the following when I go to configure it;

user warning: Table 'drupal.ldapauth' doesn't exist query: SELECT sid, name, status FROM ldapauth ORDER BY sid in C:\Inetpub\wwwroot\includes\database.mysql.inc on line 172.

I also checked with phpmyadmin and the ldapauth table is not there...

If you think this is an important enough issue that a fix will be forthcoming in the next few days, I will likely just wait.
Thanks again for your help!

Jeff

maybe you can remove the basedn text size to be able to install the module.
Hope it helps

Jeff,

Did you check admin/logs/watchdog after initially turning on your customized ldap module? Because it still failed to create the table, you should have seen an error. Make sure to check watchdog after initially turning on new module; the error caused when creating the ldapauth table is the only problem we know you are having. All of the other errors you posted are red herrings. The ldapauth table didn't get created, that is the problem. Until we know why the ldapauth table wasn't created, none of that other stuff matters.

Did you uninstall per the previous instructions? >> uncheck module, uninstall module, check that ldapauth record is gone from system table, start over with modified module;

Since this is a bug in a "stable" release, and there are a couple of other minor bugs, I want to fix, a new release might be ready any day. But I'm swamped so it is hard to know for sure when I'll get a chance to do it.

dlr's suggestion might help. If you try it though, do so after completely uninstalling the previous module and make sure to check the watchdog logs after enabling it, prior to changing any ldap settings.

I got it working! But I will still install the patched version when it came out.
After making the suggested change to basedn entry in ldapauth.install, I started to receive similar errors listing ldapdata_bindpw_clear, ldapdata_rwattrs and ldapdata_roattrs. They each gave the error "cant have a default querry string". I had found for basedn that I had to modift ldapauth.install in 2 places (toward the top and again toward the bottom). When I tried that with these valuse though the mod would install and the table got created but when I went to configure the mod I got an error saying "doesnt have a default querry". So I couldnt create the table with a default but then I couldnt use it without one?
I noticed that the difference between those entries and basedn was that basedn is varchar and the others were longtext. Since the table had already been created, I went in through phpmyadmin and changed those setting to varchar (1024) with a default of 0. I expect that I could figure out how to change it in the ldapauth.install but this seemed to be a quick way to verify whether it would work or not... Ldapauth is now installed and it works - I can log in against AD and the account gets created in Drupal!
I expect that there is a reason that those values were set to longtext and that something will break later so I will wait for the patch but I thought this info might be useful.
Thanks for all your help!

Jeff

Thanks for the follow up jhague! You prevented another bug. I'm just about to commit these changes to head and a new release soon.

Since your mysql install is so much more sensitive than mine, please try these fixes.

Hi!

In my work:
in here:
basedn text(1000) NOT NULL default '',
to:
basedn text NOT NULL default '',

adios

Are you saying that you changed the first line to the second and it worked? If so, that's great, but I believe the correct syntax is:

basedn text NOT NULL,

It is patched in HEAD. I'll make a new bug release soon or feel free to try HEAD.