migration error

  • da gibts schon einige Unterschiede in der DB Struktur ...
    rechts ist die Original 1.0.7 Struktur - links meine:
    http://postimg.org/image/wingf6nzn/


    ausserdem ist überall das charset anders:
    im original:
    `name` varchar(200) COLLATE utf8_unicode_ci DEFAULT NULL,


    bei mir:
    `name` varchar(200) DEFAULT NULL,


    und hier scheint die Reihenfolge nicht zu stimmen bei:
    gender
    http://postimg.org/image/3ld3w9447/

    Edited once, last by fulltilt ().

  • reihenfolge der spalten oder spalten zu viel stört nicht, soweit ich das datenbank update script verstanden habe, ich habs aber nur kurz überflogen.


    du hattest ja auf deiner testmaschine erfolg gehabt, mach von der produktiv maschine unbedingt ein vollständiges backup ganz frisch bevor du loslegst, und mach die migration am besten nachts ^^


    probieren geht über studieren, aber halt dir den rückweg frei.


    ausserdem könntest du dir zeit nehmen das migrationsscript zu studieren und bei bedarf anzupassen an deine struktur

  • also den Fehler ignoriere ich jetzt einfach mal, beim 2. Start läuft alles sauber durch und es sind keine Fehler feststellbar, alle configs stimmen ...


    Ich habe jetzt auch mal die neue Datenbank komplett exportiert und versucht auf einem anderen Server mit neuer IP zu migrieren ....
    Das geht ja 1000mal schneller als mit ispcp :D
    Es gab diesmal auch keine Fehler alles glatt durchgelaufen mit allen Kunden


    Kann man die Migration > Server Umzug so machen?



    noch was vergessen ...
    wie ist es wenn ich die alten Webs und Mailfolder vor dem Update schon hochlade
    werden dann wie bei ispcp die default_domain_pages in die Webfolder kopiert?
    Wöre dann nicht so gut wenn vorhandene index.html überschrieben werden ...

    Edited once, last by fulltilt ().


  • noch was vergessen ...
    wie ist es wenn ich die alten Webs und Mailfolder vor dem Update schon hochlade
    werden dann wie bei ispcp die default_domain_pages in die Webfolder kopiert?
    Wöre dann nicht so gut wenn vorhandene index.html überschrieben werden ...


    nein, das ist schon lang nicht mehr so.

  • hier gibt es noch ein Problem, nach der Migration ispcp auf imscp werden die UIDs & GUIDs falsch gesetzt in der /etc/passwd sind die User jetzt alle doppelt vorhanden ...


    vorher war die start uid z.b. 3060
    jetzt bei den Webfoldern startet die UID mit 2006


    bei den FTP Users sind alle alten UIDs noch vorhanden wie sie vorher waren mit Start bei 3060


    z.b. in /etc/passwd
    vu3060 und vu2006 stehen jetzt für ein und denselben Kunden
    so sieht es da aus:
    vu2111:x:3917:3917:iMSCP virtual user:

    Edited once, last by fulltilt ().


  • mysql_secure_installation wird schon im autoinstaller durchgeführt ;)


    Exactly :D Ive integrated all queries from the mysql_secure_installation script into the i--MSCP installer.

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


  • So please, in such case, you must open a ticket... I'm begin to be tired to have to read all german thread to find bugs... You want a better software??? Ok, use our bug tracker. ;)

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

  • Hallo zusammen,


    ich habe die gleiche Störung beim migrieren von ispCP 1.0.7 OMEGA build: 20101124 Codename: Priamos auf die derzeit aktuelle i-MSCP Version imscp-1.1.0-rc3.


    Code
    1. [ ERROR ]main::setupUpdateDatabase: [ERROR] Configuration variable`PHPINI_POST_MAX_SIZE` is missing.StackTrace:#0 /var/www/imscp/gui/library/iMSCP/Config/Handler.php(189):iMSCP_Config_Handler->get('PHPINI_POST_MAX...')#1 /var/www/imscp/gui/library/iMSCP/Update/Database.php(1937):iMSCP_Config_Handler->offsetGet('PHPINI_POST_MAX...')#2 /var/www/imscp/gui/library/iMSCP/Update/Database.php(138):iMSCP_Update_Database->_databaseUpdate_137()#3 /var/www/imscp/engine/setup/updDB.php(51):iMSCP_Update_Database->applyUpdates()#4 {main}


    Die Fehlermeldung lautet nun mal das die Varible PHPINI_POST_MAX_SIZE unbekannt bzw. ohne Inhalt ist. Ich habe ebenfalls den Vorschlag vom flames gemacht um zu prüfen ob ggf. alte Fehlerhafte php.ini Datein vorhanden sind. Beim mir war auch das völlig OK.


    Code
    1. find /var/www/fcgi/ -iname 'php.ini' | xargs grep '{*}' -sl


    Mir ist aufgefallen das in einigen Template Dateien eben nach dieser Variable gefragt wird und da diese im configfile /etc/imscp/imscp.conf nicht definiert ist. Möglicherweise kommt dieser Wert aus der DB und bei einer Migration existiert dieser Wert noch nicht.


    Die vorgehensweise von "flames" zur migration ist schon sehr Hilfreich.

    Code
    1. cp -fR /tmp/imscp/* / cd /var/www/imscp/engine/setup perl imscp-migrate-from-ispcp


    Ich habe nun nur noch die Datei /etc/imscp/imscp.conf angepasst und die folgende Zeile bei den PHP Vars hinzugefügt:

    Code
    1. PHPINI_POST_MAX_SIZE = 16


    Somit ist diese fehlende Variable PHPINI_POST_MAX_SIZE nun vorhanden und mit einem Wert versehen, die installation kann nun gestartet werden und bei mir ist diese fehlerfrei durchgelaufen.


    Code
    1. perl imscp-setup


    Allerdings werden die Webuser in der /etc/passwd gelöscht und neu angelegt dabei entstehen kleine lücken und die UID GID ändert sich. Die Dateirechte der Webuser setzt der installer aber korrert um so das eine Migration ohne weitere probleme durchlaufen sollte.


    Bei mir musste ich einige wenige webuser (2 sück) aus der /etc/passwd und /etc/shadow löschen damit diese nicht doppelt sind.


    Aber wie kann ich nach manuellen änderungen Konfig Datein (z.b. nur Apache, bind) neuen aufbauen lassen? Kennt jemand die Funktion dafür?