Migrace MySQL na nový hosting

[HanzHanz]

Ahoj, poprosím zkušenější, jestli se náhodou nesetkali s následujícím problémem:

- mám funkční web který potřebuji přenést jinam (Bookedscheduler, rezervační systém)
- na novém serveru jsem provedl čistou instalaci s novou databází, vše běží jak má
- naimportoval jsem kompletní databázi ze starého serveru (mysqldump a potom source)
- všechny tabulky se přenesly bez chyb včetně uživatelů

Nicméně databáze obsahuje uživatelské účty a hesla a při pokusu o přihlášení dostanu hlášku "nesprávné uživatelské jméno nebo heslo". Údaje jsou 100% správné, na starém hostingu účty fungují.

Netušíte prosím kde by mohl být problém?

[Reklama]

[RDa]

Pokud je to PHP + SQL, tak zkus nastavit konfiguraci tak, aby se pouzivala krizem (nova instalace a stara DB nebo stara instalace s novou db).

Tj. musis overit zda ta aplikace doopravdy pristupuje k DB (coz asi by zastaveni DB melo udelat nejaky jiny error).

A dalsi vec je, zda se nesaltuji hesla v DB necim jako "hostname ci secret, kde aplikace bezi". Takova vec by zamezila prolomeni hesel kdyby ti unikla jenom DB, ale taky to znamena vetsi opruz pri migraci.

[Vít Šesták (v6ak)]

Neznám Booked scheduler, ale dovedu si představit takovýto problém způsobený novou instalací a přenesením DB ze staré. Hesla se typicky ukládají jako hash, ke kterému můžeme mít nějaké nastavení. Některá nastavení snad budou v DB u každého uživatele (třeba typ hashovací funkce a její parametry), ale jsou i parametry, které v DB záměrně nebudou. Někdo může hashe ještě šifrovat klíčem uloženým mimo DB (takže uniklá záloha DB nebude tak hodnotná), někdo k podobnému účelu může používat tzv. pepř (asi to není preferovaná varianta, ale to je už jiná debata). Pokud tato část nastavení nesedí, může to způsobit onen problém s přihlášením.

[hknmtt]

typujem to na problem s enkodovanim(collation). porovnaj schemy medzi db cez phpmyadmin alebo heidisql alebo podobne ze ci sedi vsetko.

[HanzHanz]

Děkuji všem za rady, zjistil jsem zatím následující:

- kódování je stejné, obojí latin1_swedish_ci
- hesla jsou uložena jako hash, v původní i naimportované databázi taktéž stejné

V příloze je screenshot z mysql (select * from users;)

[Reklama]

[snugar_i]

- hesla jsou uložena jako hash, v původní i naimportované databázi taktéž stejné

Nejde o to, že by nebyly stejné, ale že ta aplikace ve skutečnosti bude mít někde v konfiguraci magický string, který přidá před/za každé heslo, než ho zahashuje. A tenhle string nemusí být na nové instalaci stejný (může to být třeba hostname nebo cokoliv, tu aplikaci neznáme).

Tj. pokud stará instalace měla v konfiguraci nastaveno "abcde", pak místo heslo "password" ve skutečnosti hashovala "abcdepassword". Pokud nová má v konfiguraci "bleh", bude hashovat "blehpassword" a pak jí samozřejmě ověření hashe neprojde.

[snugar_i]

Ale pokud je to tohle https://github.com/LibreBooking (čímž si nejsem jistej), tak tam nic takovýho nevidím...

[kvas]

pokial sa jedna o toto https://www.bookedscheduler.com/ predpokladam, ze mas kupenu licenciu a teda aj nejaku formu podpory. Nebolo by jednoduchsie obratit sa rovno na dodavatela SW?

[HanzHanz]

Ano jedná se jedná se o tento sw. Původně phpScheduleit, pak Bookedscheduler, který byl do verze 2.xx opensource, nyní je to placené jako SaaS. Librebooking je fork a pokračování té opensource verze.

[e3k]

Děkuji všem za rady, zjistil jsem zatím následující:

- kódování je stejné, obojí latin1_swedish_ci
- hesla jsou uložena jako hash, v původní i naimportované databázi taktéž stejné

V příloze je screenshot z mysql (select * from users;)

ten salt je hned vedla password v tabulke users. to asi problem nebude...


nasiel som ale toto https://forums.bookedscheduler.com/viewtopic.php?t=832
pisu na konci: 5. Clear the /tpl_c folder on the new server before you try logging in.

skus mozno to pojde

[Vít Šesták (v6ak)]

latin1_swedish_ci bude collation (ne kódování), ale u sloupce s heslem je to nejspíš celkem jedno, pokud se tam nedějí nějaké šílenosti. Nejspíš půjde o binární data (možná zakódovaná v hex, base64, nebo něčem podobném), a prakticky jakékoliv kódování bude OK, ledaže by došlo k záměně třeba UTF-8 a UTF-16. Ale to už by byla otázka komunikace s DB…

Salt v tabulce s uživateli – to ano, ale vedle toho se někdy používá ještě pepper nebo šifrování klíčem uloženým mimo DB, jak jsem psal výše.

[HanzHanz]

Chlapi děkuji za rady, stále bez úspěchu...

Napadlo mě zkusit překopírovat pouze jednoho uživatele (jeden záznam, sebe) ze staré databáze do nové pomocí phpmyadmin a pak se zkusit přihlásit. Nicméně nejsem s mysql žádný velký kamarád. Jak to prosím udělat?

[HanzHanz]

Hlásím pokrok...

Do nové databáze jsem k pokusnému uživateli "User" (který měl default heslo "password") nakopíroval hash hesla i salt mého admin uživatele ze staré databáze a nyní je možné se na novém hostingu přihlásit pod "User"/"admin heslo ze staré databáze".

Ne že bych těch uživatelů měl moc, cca 100, ale copy/paste by byl opruz. Je mi jasný, že to tedy půjde udělat hromadně, ale s sql jsem na tom superbídně.

[Tomas-T]

Takže po hromadné migraci to neprošlo a po jednotlivém zkopírování ano?
A v obou případech byl výsledný obsah položky password hash i salt v cílové DB totožný?
To zní nějak divně.

[HanzHanz]

Takže po hromadné migraci to neprošlo a po jednotlivém zkopírování ano?
A v obou případech byl výsledný obsah položky password hash i salt v cílové DB totožný?
To zní nějak divně.

Podezřívám aplikaci samotnou... Původní a nová verze jsou jiné a původní už není ke stažení. Nová verze má sice migrační nástroj ze staré, ale ač se to tváří, že vše proběhlo v pořádku, přihlášení prostě nefunguje.

Překopíroval jsem tedy pouze tabulku s uživateli pomocí phpmyadmin a už to jde.

Každopádně moc děkuji všem za pomoc! Kdybyste měli chuť si u mě někdo zahrát tenis, máte u mě 1h pronájmu kurtu zdarma (pouze letní provoz) - kousek od Prahy.

Pěkný den!