Time to call it a week....

Well, I took three days off this week, but managed to get a bunch done.  Aside from personal stuff, I setup a clone/mirror server for our company's staff website.  Our staff website runs druapl 5.x and I was hoping to clone the content and jump to 6.6 in one shot, but that proved to be easier said than done.  So I opted to just setup 5.12 on the clone.

At first I attempted to use the Backup Migrate module to import the production site's db into the clone site, but that didnt seem to work at all or give me an error of any sort to go on, so I manually grabbed the production site DB using this command:

mysqldump -u username -p password --opt dbname > drupal_sync.sql

Where username and password is the account that has access to the drupal db, and dbname is the name of your drupal db.  drupal.sync.sql is just the name i chose for the backup copy.  At this point I scp'd it over to the clone site, then on the clone site while in the directory where I scp'd the copy of the db to, I issued:

mysql -u username -p password  dbname < /drupal_sync.sql

That takes the db copy and pushes it into the db I created on the clone site.

At this point, the content was there but my theme was not, the colors were drupal defaults, and it just seemed that a lot was off.  When I went to go configure our theme, i saw an error saying the 'files' directory could not be created, which was a clue to me that the theme configs seem to need the files folder.  At this point i scp'd the files folder from the production server to the clone, at which point the site looked practically perfect.

One more thing needed to be fixed, embedded videos were not working which led me to notice that our WYSIWYG editor(tinymce) was not loading at all.  Everything seemed to be in order, and I decided to disable the TinyMCE module, then re-enable it.  This seemed to fix the problem, so I am content.   I think some tables or something needed to be rebuilt and the disabling/re-enabling triggered that.

One important note if you ever go my route, disable clean urls on the production site first, then make a copy of the DB.  It is much easier that way, especially in my case since the clone server will not allow me to do clean urls for whatever reason.  But even so, I recall a long time ago I made a sandbox server based on our production one and had a quite the clean url fiasco because I didn't disable them before I exported.

So no what?  Well, aside from getting the clean urls working(which I have actually blogged about!), I am setting up nightly syncs.  The sync is a two step process.  First, the production server is mounted via sshfs, then rsynced on the drupal directory that way ensuring any avatars, theme changes, new modules etc migrate to the clone.   The second step is the db export and push into the clone.  

Currently, since I am using some sort of 'minimal' install of Ubuntu 8.04 from our VPS provider, I have been encountering some odd Linux errors:
-As mentioned previously,  clean urls will not work....
-I had to install modprobe by installing module-init-tools
-When my sync script executes 'modprobe fuse' I get the following error:
FATAL: Could not load /lib/modules/2.6.18-53.1.19.el5.028stab053.14/modules.dep: No such file or directory

Stay tuned for an update on all of this.

UPDATE 12/8/82:

In regards to the previous error, there is no /lib/modules/2.6.18-53.1.19.el5.028stab053.14 directory, therefore no modules.dep file(which is created by depmon included in the module-init-tools package). This is happening, I believe, because I am on a minimal Ubunbtu build on a VPS.  So right now, aside from contacting my VPS provider, I am looking into replicating the modules.dep file with an entry for fuse in it.

Uggh, I tried to bring a fuse.ko over from another machine and run depmod, but then when I issued a modprobe fuse I get :

FATAL: Error inserting fuse (/lib/modules/2.6.18-53.1.19.el5.028stab053.14/fuse.ko): Operation not permitted
FATAL: Error running install command for fuse

Stay tuned...