Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Connector/OOo tries socket connection even with "localhost" and Socket: blank | ||
---|---|---|---|
Product: | Base | Reporter: | rene |
Component: | MySQL Connector/OOo | Assignee: | dbaneedsconfirm <needsconfirm> |
Status: | CLOSED FIXED | QA Contact: | issues@dba <issues> |
Severity: | Trivial | ||
Priority: | P3 | CC: | issues, john.mccreesh, mechtilde, r4zoli, tim |
Version: | OOo 3.1 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
rene
2009-12-02 21:21:36 UTC
Hmm. - Installed vanilla OOo 3.1.0, on Linux 32 bit, installed C/OOo 1.0.0 final. - Created a new database, using MySQL native connection, server "localhost", DB name "testdb" - tried connecting to this database => error message "Can't connect to MySQL server on 127.0.0.1 (111)" Okay, I have no MySQL server running on localhost :). Can somebody confirm that if you shut down your MySQL server running on localhost, then the error message does not talk about sockets anymore? Ah! Looking into the code of Connector/C, the lib underlying Connector/C++, which in turn is used by Connector/OOo, there indeed is code which basically looks like "if no protocol is specified, and we're connecting to localhost, then use a socket". So, the error here seems to be that C/C++ does not set the protocol to MYSQL_PROTOCOL_TCP by default. I think I can fix this, but since my analysis is from code inspection only, it might be wrong - anybody reading here who would be willing to test a new extension version? ftp://qa-upload.services.openoffice.org/MySQLConnectorOOo, if somebody is interested in ... Tried again to reproduce the problem on a Linux system with a running MySQL server - connected via localhost:3306 - no problem at all. So, to me this boils down to "worksforme". Can somebody of those who encountered the problem please check whether the 1.0.1.alpha, to which I pointed above, solves the problem? Thanks. Or is it perhaps that the problem in general does not happen with the extension from http://extensions.services.openoffice.org/project/mysql_connector, but only with a distro-specific extension? ping. Mechtilde, rene: any chance to test whether the version from ftp://qa-upload.services.openoffice.org/MySQLConnectorOOo fixes the problem for you? As said, I cannot reproduce it, so I cannot check whether this (supposed) fix really works. side note: I've been told this issue has been raised as potential stopper for the 3.2 release. This is not necessary, since the bug is not in OOo code, but really in the C/OOo code. "The extension 'MySQL Connector for OpenOffice.org (Alpha)' does not work on this computer" - I guess because I'm running 64bit Ubuntu (could do with a more explicit error message). Issue 107794 is being proposed as a showstopper for 3.2. The proposed workround is to use the MySQL Connector extension. However, if this is accepted as a workround (still under debate), then getting 107391 fixed becomes a prerequisite - hence a showstopper. Yes, the version linked above is a Linux 32 bit version. For the show-stopper-ness ... well, I am not sure "use C/OOo instead of C/ODBC" is a valid workaround, since this migration to another connector requires some work for affected databases (as mentioned in the issue I think). Anyway, as said above, the fix is (probably) in Connector/C++, a third-party component shipped with Connector/OOo, *not* in OOo code, so whether or not this is a "stopper" for 3.2 doesn't affect *any* code in the 3.2 code line. In IRC, mechtilde reported she still cannot connect to "localhost", using the 1.0.1 alpha version pointed to above, in OOo 3.2 RC 1. However, the error message now doesn't talk about a socket error anymore, but mentions the "111" number which seems to be some kind of generic error ... I still cannot reproduce the problem at all, I just tried with a freshly installed OOo 3.2 RC1, the 1.0.1 alpha, any a freshly installed MySQL server 5.1.36. I'll leave this issue open for a while - perhaps somebody has new ideas how to reproduce the problem. If not, then I'll close it as WORKSFORME. Sorry, but I cannot fix what I cannot reproduce. I saw this problem on my Ubuntu 9.10 desktop as reported in http://www.openoffice.org/issues/show_bug.cgi?id=107391. I can now repeat the problem on my new laptop using Ubuntu 9.10 64 bit, OOo 3.2 RC1, mysql-connector-ooo-1.0.0-linux-x86_64.oxt, MySQL server version: 5.1.37-1ubuntu5. Steps to reproduce: From the database wizard: 1. Select database: Connect to an existing database - MySQL 2. Set up MySQL connection: Connect directly 3. Set up MySQL server data: Database name: stuff Server: localhost Port: 3306 4. Set up user authentication: User name: mystuff Password required: Check press <test connection> Password dialog box: enter password Remember password to end of session: check Press <ok> Error: "Cannot connect to local MySQL server through sockect '/tmp/mysql.sock' (2)" Fails every time. well, yes, that's exactly what I did here ... and it works fine :-\ > I still cannot reproduce the problem at all, I just tried with a freshly > installed OOo 3.2 RC1, the 1.0.1 alpha, any a freshly installed MySQL server > 5.1.36. And probably with the MySQL on the same host and in the same system so that the socket can be used.. Try using OOo from a chroot with "localhost". Or try disabling socket auth (or just rm the socket) > I'll leave this issue open for a while - perhaps somebody has new ideas how to > reproduce the problem. it is trivial to reproduce this problem with chroots and mysql running on the "real" host > Try using OOo from a chroot with "localhost". Or try disabling socket auth
> (or just rm the socket)
Removing the socket doesn't change anything, OOo still works like a charm -
indicating that it indeed connects via TCP. Tried with the 1.0.0 release of the
connector, on unxlngi6.
Phhh ... Just browsing through some BugZilla administration page (completely unrelated to this issue here), I stumbled over the following: This setting is required because MySQL ignores the port specified by the client and connects using its compiled-in socket path (on unix machines) when connecting from a client to a local server. , which reminded me of this issue here ... As I still cannot reproduce the problem, I move the issue to the "dbaneedsconfirm" pool, and reset the target. Well, it now works for me in the Debian 3.2 packages. Thanks. According to reporter the bug was fixed. fixed-> closed. |