Niks jammer, maar gewoon stom om een wiel opnieuw uit te willen vinden.
Het kost doorgaands meer tijd om iets zelf uit te zoeken, ontwikkelen en goed te testen dan dat je daar een externe partij voor inhuurt. Daarbij is je ontwikkel traject voor een x aantal klanten en/of machines en vervolgens nagenoeg niet meer bruikbaar.
Succes ermee!
Sorry maar "stom" is iets wat hier niet past! Jij wilt jouw services verkopen en ik maak hier geen gebruik van. Het gaat om 500 servers en daar heb ik jouw betaalde diensten niet voor nodig.....dus ga ik het script opnieuw uitvinden. (als ik zo'n script had dan zou ik het gewoon terbeschikking stellen voor diegene die het nodig hebben) maar dat is nu net het mentaliteits verschil!
Het was maar een vraag en dan zulke antwoorden terug krijgen....sorry dat ik het heb gevraagd! (heb er nu al spijt van)
Laatst gewijzigd door drex; 05/04/12 om 15:21. Reden: typo
Leuke stelling (eerst zien, dan geloven) , ik heb in het verleden meer dan genoeg ter beschikking gesteld, echter wordt er aan alle kanten gejat en geroofd. En een bedankje kan er al helemaal niet meer vanaf. Het mentaliteit verschil is ontstaan door ervaringen met verschillende partijen die ik heb waarvan verschillende er ook hier rondhangen.
Maar als ik alles dus goed interpreteer ga jij op termijn je zelf uitgevonden script dus vrijelijk ter beschikking stellen ?
Ik snap Mikey wel en zeker als je businessmodel is om iets te verdienen aan serverbeheer dan zou ik het zelf ook niet anders doen.
Gezelligheid hierzo
Ik heb een aantal weken geleden een simpel script voor onze migratie gemaakt.
Het hele geheel bestaat uit 2 scripts, een 'transferscript' en een 'handlingscript'.
Beide scripts stellen eigenlijk bijzonder weinig voor, maar werken wel.
Even een korte uitleg:
Transferscript
Deze draai je op de server waar Plesk staat geïnstalleerd.
Je geeft een aantal variabelen op (username, locatie, databasenaam,..)
Vervolgens wordt er een tar.gz gemaakt van de httpdocs, wordt er een sqldump gemaakt van de vooraf opgegeven.
Deze tar.gz en sqldumps worden in 1 tar.gz gegooid en vervolgens via scp overgezet naar de nieuwe server (wil je dit zonder password overzetten, moet je even met aan de slag met authorized_keys..).
Handlingscript
Dit script draai je op de server waar DirectAdmin staat geïnstalleerd.
Het wel een vereiste dat je in DA al de gebruiker hebt aangemaakt. Ook moet je van te voren de database aangemaakt hebben.
Uiteraard wordt er in het handlingscript ook gebruik gemaakt van een aantal variabelen.
Het script pakt de complete tar.gz uit -> je hebt dan weer 1 tar.gz van httpdocs en een aantal sqldumps.
De tar.gz van httpdocs wordt vervolgens uitgepakt en de inhoud hiervan wordt gekopieerd naar public_html/ van het betreffende domein.
De sqldumps worden dan geïmporteerd.
Bij interesse wil ik beide scripts wel posten hierzo.
Ik weet niet in hoeverre het voor jullie van toepasselijk is, maar voor ons is het goed genoeg.
Wij hebben niet bijzonder veel klanten die overgaan naar DirectAdmin. Hierdoor hebben wij het vrij simpel gehouden.
Het vereist nog wel enig handwerk.
Edit: de rechten van mappen / files in public_html zullen wel handmatig goed gezet moeten worden.
Laatst gewijzigd door magentohosting; 05/04/12 om 17:56.
Mochten mensen willen migreren naar cPanel, daar zit een migratie script ingebouwd bij de transfer account function.
Zonet een PM gekregen of dat ik de scripts wou delen.
Bij deze de scripts
Vergeet niet de variabelen aan te passen.
Tevens is het zo dat dit script voor 1 klant tegelijkertijd is.. Je kan het script wel deels kopiëren (aantal variabelen wijzigen) en dan zo meerdere klanten tegelijk doen.
Ik vond het echter een fijner idee om per klant te doen; zeker omdat het er niet heel veel zijn.
Handlingscript.txt
Transferscript.txt
Edit:
Ik heb beide scripts gemaakt in Notepad++.
Mocht je ze 'gewoon' in Notepad openen, kan zijn dat de opmaak e.d. zeer scheef zit.
DreamHost.nl Web hosting - cPanel hosting om bij weg te dromen.
Ach je meent het....heeft iemand het gehad om het voor een appel en een ei weg te geven! Echter de dienst uit te laten voeren door hem is een geheel ander verhaal en dat is wat hij aanbood.
En vergeet niet het was slechts een vraag of hij het migratie script beschikbaar wilde stellen en niets meer dan dat, wil je dat niet dan kun je dat als zodanig gewoon melden. Echter dan komt er een reaktie terug van hem en dan kun je het maar beter in een heel donker plekje stoppen.
Voor mij stopt het hier in iedergeval....
Laatst gewijzigd door drex; 05/04/12 om 22:21.
Bij een bedrijf waar ik voorheen zat was het heel simpel: kosten het veel tijd om dit probleem op te lossen? (van a t/m z).
Zo ja: huur maar iemand in (extern bedrijf, freelancer, etc.) die hier ervaring mee heeft en het snel op kan lossen.
Het kost vaak meer tijd en geld (en bloed zweet en tranen) om het wiel opnieuw uit te vinden. Is gewoon doodzonde.
Er is niks mis met wat Mikey doet. Hij heeft er waarschijnlijk aardig geïnvesteerd om een compleet migratiescript.
Deze scripts zou ik ook niet zomaar even aan jan en alleman weggeven.
De 2 scripts die ik hier zojuist geplaatst hebt, stellen wat dat betreft niet zoveel voor en vereisen alsnog redelijk wat handelingen. Het is enkel een basisdingetje.
Na wat vragen in de e-mail hierbij wat duidelijkheid wat zover wel en niet 1 op 1 overgezet kan worden:
Er zijn een aantal dingen die je niet 1 op 1 over kan nemen vanuit plesk naar directadmin:
• Cronjobs (huidige cronjobs in de export log, het kan wel, voor & nadelen, afweging)
• Databases (deze worden hernoemd en uitgerust met nieuwe gebruikersnaam & wachtwoord)
• Webusers (helemaal geen export)
• Mailing lists
• Certificaat (handwerk)
De volgende onderdelen worden overgenomen:
• Httpdocs
• Httpsdocs
• Email accounts & e-mail
• Databases (welliswaar nieuwe database naam, username & wachtwoord)
• Dns settings
• Email forwarders
• Indien mail disabled is, wordt deze ook in directadmin disabled
• Statistieken (onder voorbehoud)
• Catchall (e-mail)
• Redirects (e-mail)
• aliases(e-mail)
• Account limits, daar waar mogelijk.
Er zijn drie exceptions:
Voor subdomeinen is er een exception, directadmin zet subdomeinen binnen het hoofdaccount in de public_html dir. Dat wil zeggen dat als test.domein.nl een subdomein is, dat er een directory met test in public_html is. Mocht het zijn dat deze directory al bestaat dan wordt het subdomein hernoemd. Test wordt dan test{randomNr}
De tweede is voor het ftp account. Voor directadmin geld dat het panel account tevens het main ftp account is. Bij de export wordt het ftp account gebruikt, deze wordt van ongeldige tekens voorzien en ingekort naar maximaal 8 tekens om binnen directadmin goed inzetbaar te zijn.
De derde, databases uit plesk kunnen niet standaard 1 op 1 overgenomen richting directadmin. Directadmin heeft voor database en gebruikersnaam een opgesteld formaat. $username_$database naam. Bestaande database namen worden hernoemd en ingericht binnen $username_prefix. Hetzelfde geld voor de database gebruiker. Er wordt zowel een nieuwe gebruikersnaam als wachtwoord gegeneerd. De oude database wordt geïmporteerd binnen de nieuwe.
Er blijft een kleine nazorg over:
• Paths aanpassen in de code die hardcoded zijn
• Checken op eventuele web_users, en met klant kortsluiten wat hiermee gedaan wordt. Hier kunnen nieuwe aparte ftp Users voor aangemaakt worden met paths naar eigen directories.
• Cronjobs, deze worden in de log vermeld maar niet geïmporteerd.
• Dns template op de directadmin machine, voor de import dient hier naar gekeken te worden
De export is een full functionele directadmin backup die via directadmin admin panel dan ook op de normale reguliere weg geïmporteerd kan worden. En het zijn backups per domein, niet compleet server wide. Elke geëxporteerd domein heeft een export log met daarin alle wachtwoorden, cronjobs etc etc.
Wij hebben getest om bijvoorbeeld mysql account gegevens door middel van scripts automatisch te laten wijzigen, echter door de eventuele generiek gekozen database & gebruikersnamen bestaat het risico dat er meer stuk gaat dan opgelost. Hetzelfde geld voor de paths in scripts. Dit is een afweging om gebruikers bewust te maken van andere oplossing waarbij dit soort problemen tevens in de toekomst niet meer voorkomen, en dat hun scripts niet meer afhankelijk zijn van een vaste path.
Voor wie zelf aan de slag wilt gaan, staan hierboven een hoop tips waar je zelf ook tegenaan zult lopen.
Dat is een redelijk zware bevalling als ik het zo lees Mickey, zeker niet iets waar je op zit te wachten met honderden servers als je die wilt/moet migreren.
Zal dan maar wat sarcasm brengen: op naar cpanel =)