concerned that running wrong mySQL driver and or wrong schema for mod_offline_odbc

Hey, Hi, Gang,

Hope this finds you all well.

I am concerned that we may be (a) running the wrong mySQL driver and or (b) running the wrong schema for mod_offline_odbc. If I run mod_offline, no errors and all is well. If I run mod_offline_odbc I see:

=ERROR REPORT==== 2012-06-13 22:55:25 ===
** State machine <0.524.0> terminating
** Last event in was connect
** When State == connecting
** Data == {state,undefined,mysql,30000,"localhost",1000,{0,{[],[]}}}
** Reason for termination =
** {'module could not be loaded',
[{mysql_conn,start,
["db.example.org",3306,"sip_ejabberd",
"1234567890","sip_ejabberd",
#Fun]},
{ejabberd_odbc,mysql_connect,5},
{ejabberd_odbc,connecting,2},
{p1_fsm,handle_msg,10},
{proc_lib,init_p_do_apply,3}]}

I followed this recipe when setting it up:

https://support.process-one.net/doc/display/MESSENGER/Using+ejabberd+wit...

I am thinking that this is now quite old at this point and that I might need (a) a newer recipe to follow, and or (b) a new SQL driver to use, or (c) and a newer schema to import.

I searched the entire box for *.beam drivers for mySQL and here are my drivers:

[root@liverpool ebin]# pwd
/usr/lib64/ejabberd/ebin
[root@liverpool ebin]# ll | grep -i sql
-rw-r--r-- 1 root root 3436 Apr 18 00:47 mysql_auth.beam
-rw-r--r-- 1 root root 7144 Apr 18 00:47 mysql.beam
-rw-r--r-- 1 root root 9384 Apr 18 00:47 mysql_conn.beam
-rw-r--r-- 1 root root 2204 Apr 18 00:47 mysql_recv.beam
[root@liverpool ebin]#
[root@liverpool ebin]#

Could someone very generously point me in the correct direction here to get me over what I think is the last step to get me talking to mySQL?

Thanks so much!

Appreciated.

Anonymous

So you use "MySQL in native

So you use "MySQL in native mode instead of the ODBC generic mode"?

What other modules are working OK with this mode?
Or do you use native MySQL for mod_offline_odbc only? If so, what are the reasons to do so? Maybe it's practical to check the usual configuration first?

mikekaganski wrote: So you

mikekaganski wrote:

So you use "MySQL in native mode instead of the ODBC generic mode"?

What other modules are working OK with this mode?
Or do you use native MySQL for mod_offline_odbc only? If so, what are the reasons to do so? Maybe it's practical to check the usual configuration first?

Thanks, Mike. You know, now that you ask, I must admit that I do not exactly know those answers. If I mis-stated, I didn't mean to. I guess I ought to know for certain the answers to those questions before I go on. Can you kindly let me know how I would know one or the other? I can say this, all I have been doing in the "conf" file is playing with adding or removing "_odbc" to the end of the lines. I thought that that would in turn tell the daemon to see the ODBC configuration section, which in turn would be my database server configuration line, which in my case would be a dedicated mySQL server on our LAN. If I have misunderstand how that works, then I need to be put straight. :)

Let me ask this, what is best practice here? native driver? or generic driver? or what?

I need to add one very important piece of information here, this is installed on centOS 5.x from the repo' using yum (i.e.: rpm) and nothing else has changed *except* my dropping the above referenced files in to that directory and restarting the daemon.

Thanks much.

Jason

Honestly, I don't know the

Honestly, I don't know the "best practices" here, as I don't use ODBC. My usecase is limited to insite LDAP-based IM.

But maybe this information is relevant. This page tells that there's a step that made that person to hit a wall: the ejabberd user in mysql needs to be granted rights to the database:

mysql>GRANT SELECT,INSERT,UPDATE,CREATE ON jabber.* TO  ejabberd@localhost  IDENTIFIED BY "yourpassword";

HTH

Thanks, Mike, but in this

Thanks, Mike, but in this specific instance, I am confident that this is not related to mySQL permissions. I say that for a couple of reasons: we run a dedicated mySQL server in-house with many many dozens of DB's inside of it & each is set-up in a similar way, with a dedicated connection account and privileges, and we did the same thing here for eJabber. And here is the big one, the error is "module could not be loaded". This thing is not even trying or attempting to touch the DB server yet. It can't even load the SQL module. Once the module is loaded, it will reach out to touch the DB and we will see what happens then. Right now, the module is our issue.

Any one out there know how to get the SQL/mySQL/ODBC modules to load-up correctly at time of daemon start?

Please.

Thanks.

Jason

This seems to have helped a

This seems to have helped a lot. I hope these notes help someone else.

https://support.process-one.net/doc/display/MESSENGER/Using+relational+d...

Specifically, the "R13" set of files that I copied in to /usr/lib64/ejabberd/ebin/ The "R14" files did not work for me (ejabberd-2.1.11-1.el5 running on centOS 5.8 64bit). The "R14" files threw this error:

Loading of /usr/lib64/ejabberd/ebin/mysql_conn.beam failed: badfile

I now see connections to the mySQL database server.

I am updating as I go.

Now to get actual usable records to flow back-n-forth.

It works. The very last "mod"

It works.

The very last "mod" that I have yet to successfully move over is pub sub. That one throws an error, but I think that is my config'. All other modules are moved over to ODBC now.

Thanks all.

I'll go hang a shingle on our website that we are now "ejabbered experts for hire".

Cheers.

Jason
S I P

Syndicate content