Second Bad Request Problem after migration [not related to imscp​]

    IMSCP: 1.3.8
    PHP FCGID
    Debian 8.6


    I have the same problem with another migration, I know, It is not related to imscp ... just looking for a solution
    Both systems have been migrated from ispcp a few years ago and were last upgraded from imscp 1.1.18
    only these two pages generate a error 400
    /admin/reseller_edit.php?edit_id=xxx
    /admin/reseller_statistics.php


    could this have something to do with the migraftion procedure ... possibly with this part?

    Code
    1. mysql -u root -p
    2. use imcp;
    3. update domain set domain_status = 'ok';
    4. update subdomain set subdomain_status = 'ok';
    5. update domain_aliasses set alias_status = 'ok';
    6. update subdomain_alias set subdomain_alias_status = 'ok';
    7. update mail_users set status = 'ok';
    8. update admin set admin_status = 'ok', admin_sys_name = null, admin_sys_uid = 0, admin_sys_gname = null, admin_sys_gid = 0;
    9. quit


    Or where should I look for the reason for this problem?


    Regards

    @fulltilt


    You already opened a thread for an identical problem... If you're not able to do a migration yourself, best would be to ask for online support instead of making many assumptions without knowning what you're talking about.


    I'll simply repeat my previous sentence: There is surely some orphaned or corrupted entries in your i-MSCP database. If you cannot find them alone, best is to ask for an i-MSCP expert. Outside of the official team, there is also some users on the forum which have a perfect understanding of i-MSCP.


    Thank you for your understanding.

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

    SSH key for online support

    Thanks Nuxwin,
    I just wanted to make sure where I have to check, so I will examine the imscp database records intensively.
    Probably some of my canceled websites were not completely deleted from older versions ...
    Only two systems with prior ispcp installations have these problems, all my original imscp systems were performing perfectly ;-)
    1.3.8 is the best release so far and really I like it!
    Regards

    Hello Nuxwin,
    I was able to repair one database, there were 25 orphans admin and system user entrys ...
    Now I have to repair the other one and I have a question on that.
    Is there is a simple SQL command or script which can be used for copy all the entries of domain_disk_limit to the Email Max Value, so that both are set at the same value?


    Regards


    OK, I will set it manually for each domain :-(

    Edited once, last by fulltilt ().

    Quote from fulltilt

    Is there is a simple SQL command or script which can be used for copy all the entries of domain_disk_limit to the Email Max Value, so that both are set at the same value?

    Not really the subject of this thread, isn't it? Whatever. The folllowing SQL query should do what you expect:


    SQL
    1. # mysql -u root -p
    2. > use imscp;
    3. > UPDATE mail_users AS t1 JOIN domain AS t2 SET t1.quota = t2.domain_disk_limit WHERE t1.domain_id = t2.domain_id AND mail_pass <> '_no_';
    4. > \q

    Note that if you migrated from ispCP, database name could be ispcp instead of imscp, or any other name you have set when installing ispCP.


    Here, we update all mail_users.quota fields using values from the domain.domain_disk_limit fields, only for real mail accounts. Other mail accounts (forwarded mail only accounts) don't need any quota value.

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

    SSH key for online support

    thanks Nuxwin, this is the last part of my migrated ispcp database cleaning,
    after that everything is clean and I will no longer annoy or ask you in this regard afterwards ... I swear ;-)
    Regards, Ralph

    @fulltilt


    You're welcome.


    You don't annoy me with your questions as long as your are creating a thread per subject and more generally speaking, as long as you're following our reporting rules ;) I know that I'm a bit rigid but hey, think for the other people that are reading you ;)

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

    SSH key for online support
    Quote from Nuxwin
    SQL
    1. # mysql -u root -p
    2. > use imscp;
    3. > UPDATE mail_users AS t1 JOIN domain AS t2 SET t1.quota = t2.domain_disk_limit WHERE t1.domain_id = t2.domain_id AND mail_pass <> '_no_';
    4. > \q


    OK, but I guess the value of domain_disk_limit needs converted first to KB because it's set in MB ... right?

    Quote from fulltilt

    OK, but I guess the value of domain_disk_limit needs converted first to KB because it's set in MB ... right?


    domain.domain_disk_limit value is in MiB
    mail_users.quota value is in B.


    So:

    SQL
    1. # mysql -u root -p
    2. > use imscp;
    3. > UPDATE mail_users AS t1 JOIN domain AS t2 SET t1.quota = (t2.domain_disk_limit * 1048576) WHERE t1.domain_id = t2.domain_id AND mail_pass <> '_no_';
    4. > \q

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

    SSH key for online support

    Now, I've got it!
    I wanted to set diskquota and mail_quota equivalent,
    my mistake, I have not exactly looked after ...
    I thought it was in the mail_user table but your query was very helpful!

    SQL
    1. UPDATE domain set mail_quota = (domain_disk_limit * 1048576) WHERE domain_disk_limit <> '0';

    I have also repaired some other faulty stuff


    SQL
    1. UPDATE mail_users set quota = NULL WHERE mail_pass = '_no_';
    2. UPDATE reseller_props set php_ini_max_post_max_size = '20';
    3. UPDATE reseller_props set php_ini_max_upload_max_filesize = '19';
    4. UPDATE php_ini set post_max_size = '20';
    5. UPDATE php_ini set upload_max_filesize = '19';
    6. UPDATE user_gui_props set layout = 'default' WHERE user_id <> '1';
    7. UPDATE domain set web_folder_protection = 'no';