Let's encrypt error with database collation

  • Hi all,


    I am using i-MSCP 1.3.7 with Let's Encrypt 1.2. After installing and activating it, I switch to a customer panel -> domains -> Let's Encrypt and get:


    Code
    1. An unexpected error occurred
    2. An exception has been thrown in file /var/www/imscp/gui/library/Functions/Shared.php at line 2345:
    3. SQLSTATE[HY000]: General error: 1267 Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '='


    Although I very well understand the error massage, I do not know wether it is a good idea to just log into PMA and change the collation. I have received this error also in the previous version.


    Right now, I cannot use the plugin and need to run Certbot manually. I would like to change that and would appreciate your help.



    Thanks in Advance!

  • Hello,


    Could you please make a dump of your current letsencrypt table in the imscp database and show us the structure?


    Thank you.


    Also please:


    • Distro, codename?
    • MySQL version?
    • i-MSCP version ?

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • @jscha


    Also please, say us for which field (and in which table) the collation is set to utf8_general_ci. Normally, we use only the utf8_unicode_ci collation, excepted for some fields of the reseller_props table which were set to the utf8_general_ci collation by mistake...

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • hi,


    thanks for the fast answer!


    here is further info:
    we currently (still) use imscp 1.37 on debian 7.11 (wheezy) with mysql 5.5.52.0 installed.


    the database dump for let's encrypt showed (info is not complete, but should suffice I hope).


    Unfortunately I must admit, that although the iscp table's 'global' collation is utf8_unicode_ci, all subtables but letsencrypt are set to utf8_general_ci. This may be due to the fact, that we have been carrying this db for quite some time...



    Thanks again.

  • Unfortunately I must admit, that although the iscp table's 'global' collation is utf8_unicode_ci, all subtables but letsencrypt are set to utf8_general_ci.

    Please, clarify a bit. I don't see any problem regarding the letsencrypt table. Collation seem to be set to utf8_general_ci as expected. Which subtable is set with utf8_general_ci collation exactly?

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • Thanks again for the fast answer.


    To clarify:


    - the ispcp global collation is utf8_unicode_ci
    - letsencrypt table's collation is utf8_unicode_ci
    - all other tables (admin, autoreplies_log, config, custom_menus, domain..., web_software_options) are utf8_general_ci



    I hope the structure is clear now. And unfortunately, I do think that this collides with what you stated in your initial response about the collations



    edit:
    I looked into the tables and it seems that in all subtables there are varchar fields that use the utf8_general_ci collation and some that use utf8_unicode_ci.
    When creating a structure only database dump, the fields using utf8_unicode_ci are stated explicitly as utf8_unicode_ci. The tables collation is just marked as utf8.


    As an example you find the dump for the domain table.


    Edited once, last by jscha ().

  • the ispcp

    Ok... You migrated from ispcp.


    For now, please set all tables to utf8_unicode_ci collation manually through PMA, including columns if needed. I'll add a fix in next release. For the columns, do that only for those on which the wrong utf8_general_ci collation is set.


    The bug is not in the LetsEncrypt plugin, nor in i-MSCP core. This is more a migration issue.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • Thanks again for your help and input.
    And yes as previously stated, we have been carrying the database for quite some time :D. Since the migration was a long time ago, I had forgotten.



    I will change the collations manually and report back in a few days.



    Best regards!

  • So I looked again into the database and found that there were way to many fields with the utf8_general_ci collation to do it manually. So I opted out of the idea to do it manually and decided to try an automated way and watch out for any errors.


    I did some reading and found a lot of opinions that apart from special characters (like the german ß / ss ) changing the collation from utf8_general_ci to utf8_unicode_ci should not be troublesome, since the field contents should stay the same (this is different than changing the collation from latin_xxx to utf8 often brings a lot of problems). So I went for it and tried it.


    For now, I have not found any errors the site seems to be working properly AND I can use the LetsEncryptPlugin without any problems! I will continue to test the sites and i-mscp for any erros and will report back.



    For others facing the same problem:


    I found some nice posts on stackoverflow and finally this site (http://georgepavlides.info/con…abase-to-utf8_general_ci/)


    1. I created a copy of the database (database_change)
    and did the following in pma' sql query window


    SQL
    1. SELECT CONCAT('ALTER TABLE `', tbl.`TABLE_SCHEMA`, '`.`', tbl.`TABLE_NAME`, '` CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;') FROM `information_schema`.`TABLES` tbl WHERE tbl.`TABLE_SCHEMA` = 'database_change'

    Note: the last string 'database_change' is the database name


    This then will produce a sql command list to change the collation for every table/field in database

    I copied this and entered it into another sql query window. The query affected 11 tables.


    The the whole database was in utf8_unicode_ci collation. I then renamed the original database to 'database_backup' and renamed 'database_change' to 'database'