Sitegroup migration mini-howto ============================== This is just a quick round-up of a few e-mails on the Midgard mailing list concerning a sitegroup migration. I hope it helps anybody, and I'm open to additions and corrections. Situation --------- You want to move one or more of your hosts in SG0 of a sitegroup-aware 1.4beta* or 1.4 setup (maybe just after an upgrade from an installtion w/o sitegroups) into one or more new sitegroups in order to make use of the new virtual database environment. The following worked for me with 1.4 itself; I'm under the impression that esp. repligard could yield big problems in other, esp. older versions. Before you start ---------------- Have a look at http://www.midgard-project.org/req/midgard-1.4/repligard.htm One quick check first: repligard manages "foreign key relationships" (the "topic" field of an article pointing to its topic, or the "owner" field pointing to a person record) as so-called Links. Those Links are stored as references to GUIDs in order to make sure that repligard is able to restore the right connections in a new database with entirely different record IDs. That problem is taken care of as far as Midgard's own Links are concerned. But if you're working with your own connections (an article's icon field pointing to another, somewhat related article, for example) you have to tell repligard to preserve those Links. I never did, so I cannot say much more than that: you have to change repligard.xml (in /usr/local/share/midgard on a RedHat box) and replace the simple "field" elements of the columns you are using by corresponding "link" elements. Let's go: Create a new, clean database -------------------------------------- First, backup your database and create a new one to play with until you've got the migration done. To create a new, clean Midgard database, be sure to fetch the very latest midgard-data-1.4.tar.bz2 file (there are three of them to my knowledge, all named the same :-/), unpack it and populate the new mysql db with the tables and data from empty.sql (table structure), midgard-en.sql (old Adminsite), update-snippet-admin.sql (old admin update for snippet mgmt) and GUIDSforOLDSITE.sql (repligard Global Unique IDs for the old Admin). (That will change with 1.4.1 -- be careful with anything newer than midgard-data-1.4.tar.bz2 from Dec 29, 2000!) Then create a new blobdir (the code for that is in the dbinstall script which is also part of midgard-data, just scan for 'blob') and make sure that there is a 'midgard' user with the same password able to access the new database (or otherwise, update your repligard.conf accordingly). Don't forget to change the name of the database in your repligard.conf, as it will most likely not be 'midgard' in the midst of a migration. Then it's time to import Asgard, which is the point where you'll see whether your database is in a good state (AsgardSite.xml is as well part of midgard-data): repligard -c /path/to/changed-repligard.conf -i AsgardSite.xml Now adjust the new database's host table in order to get Asgard working. Check your login and access rights as root in SG0 by creating the needed additional sitegroup(s): Sitegroup -> Create Sitegroup. Along with your sitegroup an admin group in this SG is created whose name seems to be bound to the sitegroup's name even if you supply another one (that would be a bug in Asgard -- can anyone confirm this behaviour? Or has it been fixed since?). When using another admin tool, do stuff accordingly. All other modifications to the new sitegroup could only be made after relogging as <admin-user>+<new-sitegroup> (where <admin-user> means a user who is member in the Midgard Admin group (#0) -- at this point this should only be the standard 'admin' ('password'), if you haven't already created users or changed the admin password. But empty sitegroups are the best starting point for your re-import, so just confirm that you are able to log in to the new sitegroup. If you're working at a production system and can't afford much downtime, you could either set up another apache instance with another configuration to work with the new database while the old sites keep running, or you could create the new sitegroup(s) directly via the mysql command line interface. After having created a brand new and clean Midgard 1.4 database, make a backup of it for the case you would later have to go back to this state. Export old database ------------------- xsg (available from CVS) is the only way to make a clean sitegroup export with a repligard version <= 1.4. Fetch xsg (maybe we should offer another way to get it, besides CVS?), adjust xsg.conf and call it ./xsg -d midgard -s SG0 Then you should have a repligard dump of your sitegroup #0 (SG0.xml.gz). You can repeat this step as often as you like and update your database dump until you need a short freeze in the next step of the migration. Populate the new one -------------------- For every new sitegroup you created, do the following: Edit a copy of repligard.conf and - change the database to your new db's name, - change the blobdir to its new location and - change the login information to the username and password you just used to successfully log into the new sitegroup. Now (this is the last point to freeze changes on the old database and create a current dump of SG0) use this modified repligard.conf to import your whole SG0 into the new sitegroup(s): repligard -c /path/to/changed-repligard.conf -i SG0.xml.gz (end foreach ;-)) In order to keep downtime to a minimum, you can now (either via Asgard -- then switch databases _now_ -- or via the mysql command line interface again) edit your host table in order to get the right version of every site working: Disable admin sites in sitegroups != SG0 and disable all other sites in the sitegroups they don't belong to, in order to have exactly one record per name:port/prefix combination marked online. Then your sites should be back at work, and you can clean up your database. You could now simply use Asgard to remove all host, page, style and topic trees as well as groups, users and snippetdirs (if you already had those) you don't need in that sitegroup -- esp. the admin sites, of course. (...) Additions, errata? phr -- Linksystem Muenchen GmbH [EMAIL PROTECTED] Schloerstrasse 10 http://www.link-m.de 80634 Muenchen Tel. 089 / 890 518-0 We make the Net work. Fax 089 / 890 518-77 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[midgard-user] Draft: Sitegroup migration howto
Philipp Rotmann, Linksystem Muenchen Tue, 13 Mar 2001 15:14:35 -0800
