This is what works for me. If I missed anything, just add it to the bottom.
Quick reference guide for changing your LinksSql or any other gossamer product to a new server:

1. FTP into your old server and copy your /def directory and all .def files to your local hard-drive (ascii)
2. Copy your /plugins directory and all of the files to your local harddrive. (.pm and .cfg's in ascii, .tar's in binary)
SSH into your old server and type the following command:

mysqldump -uUSERNAME -pPASSWORD --add-drop-table DATABASENAME > /home/virtual/site1/fst/var/www/cgi-bin/BACKUPFILE.txt

with the /home/virtual/site1/fst/var/www/cgi-bin/ being the directory you want you mysql file dumped to.

3. FTP into the directory and download the BACKUPFILE.txt to your local harddrive.

4. FTP into the directory (either /default or /local) where you have your templates and copy all of your template files to your local harddrive.

5. On your local harddrive, if your path has change, edit each of the database.def files and change the path to the defs. Also change the database name, user, and password, if different.

6. If you are using Gossamer-Community, edit your Auth_Community.pm file to reflect your new path.

7. Check all of your .defs to make sure you have changed all of the paths. For example, if you upload images or files, you will have to modify your Links.def file and change the path. (A good way to check is to use the windows "Search" utility and search for *.* files for your old path).

Once you have done this, you are ready to upload to your new server.

Install your new LinksSql or your gossamer product.

NOTE: On some servers, cgi scripts will only work at 755 or lower. Chmod your files/directories to 777 to upload your files, once you have completed, chmod them back to 755.

8. First, FTP to your new server and copy all of your def files to your new def directory overwriting the old ones.
9. Then copy all of your /Plugin files to your new Plugins directory overwriting the old ones.
10. Upload your backed up sql file to a location on your server.
11. Upload all of your template files to your new template directory overwriting the old ones.

NOTE: If you created a mysql database and pointed your installation to it, drop the database and recreate it. This will clear all of the tables, and prepare it for the mysqldump file.

SSH into your new server and run the following command:

mysql -uUSERNAME -pPASSWORD DATABASENAME < /home/virtual/site1/fst/var/www/cgi-bin/BACKUPFILE.txt

12. Login to your new installation, resync database and check it out. If everything works, build all, or use as you would normally use.

</not a clue>

Also, a good idea is to get an IP address setup for the new server, so you can keep your old site running whilst moving to the new server.... i.e http://www.yourdomain.com/cgi-bin/links/page.cgi would be http://255.255.255.255/cgi-bin/links/page.cgi (with the IP address being the new servers dedicated IP address for your site).

Also, I couldn't see this in the post. but you also need to change the paths in all the .cgi files, and some of the .pm ones. This is the more tedious task :(

Cheers

Andy (mod)
andy@ultranerds.co.uk

---

Want to give me something back for my help? Please see my Amazon Wish List
GLinks ULTRA Package | GLinks ULTRA Package PRO
Links SQL Plugins | Website Design and SEO | UltraNerds | ULTRAGLobals Plugin | Pre-Made Template Sets | FREE GLinks Plugins!

Hi.

This is how i moved.

(1). dump the database >linksdb.sql

scp -r /old/install/directories user@newhost:/pathto/new/installtion


repeat the above for each directory if u are not copying over the entire doc root from one to another in case the directory layouts are different (like it happened with me).

(2). Create db on new account and import the linksdb.sql

(3). Change the db details in database.def in case there is a change.
(4). Change the paths in all cgi, and Config file, mod_perl.pm and .htaccess

login to admin and check the details (ie if everything in admin works fine).
Check user end functioning.
Check functioning of plugins.

I moved GMail and Links this way and it was less of a pain doing it this way particularly with GMail where there were thousands of Messages to be moved.

Anup

Good points!
Also one other thing, the plugin.cfg in the /Plugins directory sometime will have a path you may need to change on certain plugins...

</not a clue>

I have a slightly different set of "rules" for unix, and for people who know what they are doing, and willing to risk it <G>.

You can rsync via ssh from your new account to the old account, then using grep/perl change your paths.

Dump/inmport your database, set up the mysql passwords to match your old .def file (or edit the current database.def file), wait for your DNS to switch over, and pray ;)

Actually, 9 times out of 10 the site comes up, and the only edits are things to the globals.txt file for formatting reasons.

I can move a site, and get it running in under 20 minutes, 10 minutes if things go well. But, you need to know a bit about unix, and I *DO NOT* recommend it for a first timer.... After that, it's a matter of fixing up the little things, and waiting for DNS to switch over.

If you've never moved a site, figure an hour or two to get it working, less if you are lucky.

But, for those who need to move a pretty complex site, and reinstalling Links SQL is not really an option, it can be done (I've done it about 30 times so far in the past month, and have about a dozen more to go). Andy has a set of routines that allows him to move a site from one server to another, and we offer the service on Ultranerds.com.

I'm moving 10+ year old sites, running on an almost 20 year old Unix layout, to the new GT hosting system.

my paths are entrenched /www/domain or /usr/www/domain -- sometimes both in the same site, and use the /public directory as document root, not /www

I can get the site moved, and if I remember to get my rewrite rules done right, 3 out of 4 come up the first time I try. 9 out of 10 come up when I get the rewrite rules right <G>. The other site gives a bit of a problem, but it's not ever been more than a simple edit.

The *BIG* problem is testing it, since until the DNS switches to your new IP, you can't actually run the site, without editing the confs to use a different server name -- which defeats the purpose in most cases. *BUT* if you have a test server, and test domain name, you can edit your Admin->setup to use the test domain, as long as you have not hard-coded the main domain into any templates/urls and have used <%server_name%>, <%db_cgi_url%> tags, etc, you can test it all out, then edit the server name back, switch the DNS, and run both sites in parallel until the DNS moves over.


In a crunch mode, you can usually do this in under 3 hours, 3 hours being the average TTL of a dns request/cache. Some caches won't update for7 days, but you can't do anything about that. It usually takes about 24-48 hours for a 90-95% propagation of the new DNS data.

Anyway... just a note for those who have a really complex site, know Unix, and want to chance it ;)


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

"Unix gives you just enough rope to hang yourself—and then a couple more feet, just to be sure."
- Eric Allman


Antoine
UltraNerds.com Member

Yeah, but if done right, those couple of extra feet is just long enough to put your toes on the ground ;)


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.