Sql_connect: Access denied for user

General Discussions - English
21

Hi.

No modification of user name performed by manticore.
The line you provided as ‘sql_user’ value in config directly passed to mysql_real_connect.
So, first ‘silly’ check is to look what it is there in your config (m.b. you just forget to mention it?)

Possible another way of error might be encryption (ssl).
Usual authorization is when server sends handshake with capabilities. Client then answers with it’s capabilities AND authorization data (username and password), and session begins.
Secured authorization is when server sends handshake with capabilities, containing ‘ssl’ flag. Client then MAY answer with empty username, password, and also set ssl flag. In this case both then switch to ssl, and client then repeat the answer with real username and password over encrypted connection.

Key is that first handshake in the case contains neither username, nor password.
And note, that is NOT manticore way, that is how mysql proto works inside, so we just run ‘mysql_real_connect’, and all these manipulations are done by libmysql.

22

Hi,

I fixed the connection problem (not related to Manticore …) I am now getting indexer core dumping, here are some details, let me know if they mean anything to you and if you want me to report to bug tracker.

indexer myHB_index2 --verbose
Manticore 3.4.2 6903305@200410 release
Copyright (c) 2001-2016, Andrew Aksyonoff
Copyright (c) 2008-2016, Sphinx Technologies Inc (http://sphinxsearch.com)
Copyright (c) 2017-2020, Manticore Software LTD (http://manticoresearch.com)

using config file ‘/etc/manticoresearch/manticore.conf’…
indexing index ‘myHB_index2’…
*** Error in `indexer’: double free or corruption (!prev): 0x0000000002976170 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x81299)[0x7fccfb47e299]
indexer(_ZN16FieldFilterICU_c5ApplyEPKhiRN3sph8Vector_TIhNS2_13DefaultCopy_TIhEENS2_14DefaultRelimitENS2_16DefaultStorage_TIhEEEEb+0xbf)[0x7c874f]
indexer(_ZN19CSphSource_Document15IterateDocumentERbR10CSphString+0x398)[0x596708]
indexer(_ZN13CSphIndex_VLN5BuildERKN3sph8Vector_TIP10CSphSourceNS0_13DefaultCopy_TIS3_EENS0_14DefaultRelimitENS0_16DefaultStorage_TIS3_EEEEii+0xd11)[0x5ac891]
indexer(_Z7DoIndexRK17CSphConfigSectionPKcRK15CSphOrderedHashIS_10CSphString15CSphStrHashFuncLi256EEbP8_IO_FILE+0x1632)[0x556432]
indexer(main+0x1977)[0x54df87]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fccfb41f555]
indexer[0x54f224]
======= Memory map: ========

While I was investigating the previous problem I installed some previous Manticore versions (which I then removed) but it looks like some “sphinx” settings are still hanging around, like for example the manticore user which is listed in /etc/users as:
manticore:x:992:987:Manticore server:/var/lib/sphinx:/bin/bash

/var/lib/sphinx does not exist …

still the indexer created empty files before crashing in the correct directory.

Hope this helps

23

could you create ticket at Github there provide your config and example of DB dump that reproduces crash here locally?

24

What was the problem?

25

It was simple … the link to the conf file was pointing to the wrong place, almost identical to the production one except for the user credentials that were replaced with “****”.

The **s that were driving me crazy came in fact from my own file !!!

I was looking at the wrong file the whole time … how silly me !

well… I leaned a lot about Manticore source and mysql source …and error handling …

  • found also a problem with mysql users credentials handling by libmysql and the way it matches the connection credentials in the user table in the DB.

It will try to match by host then by user, if you use ‘%’ in hostname or * or other special chars this may cause a match with an unwanted user (and thus checking against the wrong password).

This may cause a different behavior depending if you are using mysql (cli) or libmysqlclient.

Now I got to fix the crash but at least the connection is now working, small progress but still progress.

Thanks !!!

26

Hi tomat,

can you please confirm the following options cause a crash for you too:

morphology = icu_chinese
charset_table = non_cjk
ngram_chars = cjk

I know this combination is not valid, still it should not crash indexer I think.

Let me know if you see the same problem and I’ll open a ticket with all the details.
Thanks

27

at our test_370 I use your settings for index idx1

index idx1
{
        source                          = src1
        path                            = <data_path/>/idx1
        docinfo                         = extern
        dict                            = keywords

        charset_table           = non_cjk
        ngram_len                   = 1
        ngram_chars                 = cjk
        morphology            = icu_chinese
}

and test passed well.

I see no issues.

28

ok, I will file a bug report and check I can recreate it.

But the combination of settings is invalid, is this correct ? Cannot have morphology and ngram on the same character set, is this right ?

29

Yes, this is correct. For morphology = icu_chinese the CJK characters should be in charset_table, not ngram_chars. You can find a course on that here Tokenization of Chinese texts

30

I see I already had files a bug for the same issue, the bug was in “waiting for files” status

all files now uploaded under github-issue-315

Thanks

31

do you created issue at github?

where you posted complete case to reproduce issue with data you provided?

32

Issue was already there , I created it some time ago, I added the files.

33

I had same problem, two indexes in one config. First - ok, second - this error.
Result: error in view
ERROR 1449 (HY000): The user specified as a definer (‘some_user’@‘localhost’) does not exist
Check all your queries in mysql console