Subject: [LON-CAPA-dev] Development cluster

From: "Lucas, Mark" <[email-masked]>
Date: Tue, 27 Mar 2012 22:50:29 -0400

Hi,

A while back I tried to bring my development server back to life and clone chunks of
oucapa2, our production library server. It was behaving strangely and I never got
back to it.

I suddenly realized this morning that I was trying to clone a 64-bit machine to a 32-bit
machine.

Is there any reasonable way to do this? What files get mucked up in the 32 to 64 bit
transition? Is there a conversion that takes you backwards if I were to do a one-shot
partial cloning then run a format adjusting script?

Thanks,
Mark

--
Mark Lucas  email: [email-masked]<mailto:[email-masked]>
252D Clippinger Lab phone: (740)597-2984
Department of Physics and Astronomy fax: (740)593-0433
Ohio University
Athens, OH 45701

---

From: Stefan Bisitz <[email-masked]>
Date: Wed, 28 Mar 2012 10:55:47 +0200

Hi Mark,

we tried this once, too, but it failed. With a look at
http://loncapa.org/hardwareupgrade.html
Step 6b
The database needs to be converted. Currently, there seems to be the 32 
to 64 conversion the only direction available.

I've already checked the script
/home/httpd/perl/debug/db_copy.pl
mentioned there. It doesn't look like a simple solution 
"just-do-it-the-other-way-round".

Stefan Bisitz

Am 28.03.2012 04:50 schrieb Lucas, Mark:
> Mark Lucasemail: [email-masked] <mailto:[email-masked]>
> 252D Clippinger Labphone: (740)597-2984
> Department of Physics and Astronomyfax: (740)593-0433
> Ohio University
> Athens, OH 45701
>
>
>
> _______________________________________________
> LON-CAPA-dev mailing list
> [email-masked]
> http://mail.lon-capa.org/mailman/listinfo/lon-capa-dev

---

From: hkng <[email-masked]>
Date: Wed, 28 Mar 2012 06:44:15 -0400

When db_copy.pl does the conversion, the 32-bit version are renamed
*.db.old. So if those were not deleted, you can copy over and at least get
the server to work (somewhat). My 2-cent. -hk

On Wed, Mar 28, 2012 at 4:55 AM, Stefan Bisitz <[email-masked]>wrote:

> http://loncapa.org/**hardwareupgrade.html<http://loncapa.org/hardwareupgrade.html>
> Step 6b
> The database needs to be converted. Currently, there seems to be the 32 to
> 64 conversion the only direction available.
>
> /home/httpd/perl/debug/db_**copy.pl <http://db_copy.pl>
> "just-do-it-the-other-way-**round".
>
> Stefan Bisitz
>
>
>> ______________________________**_________________
>> http://mail.lon-capa.org/**mailman/listinfo/lon-capa-dev<http://mail.lon-capa.org/mailman/listinfo/lon-capa-dev>
>>
> ______________________________**_________________
> http://mail.lon-capa.org/**mailman/listinfo/lon-capa-dev<http://mail.lon-capa.org/mailman/listinfo/lon-capa-dev>
>
>
>

---

From: "Lucas, Mark" <[email-masked]>
Date: Wed, 28 Mar 2012 08:51:30 -0400

Thanks Stefan

Mark

On Mar 28, 2012, at 4:55 AM, Stefan Bisitz wrote:

Hi Mark,

Stefan Bisitz

A while back I tried to bring my development server back to life and
clone chunks of
oucapa2, our production library server. It was behaving strangely and I
never got
back to it.

I suddenly realized this morning that I was trying to clone a 64-bit
machine to a 32-bit
machine.

Is there any reasonable way to do this? What files get mucked up in the
32 to 64 bit
transition? Is there a conversion that takes you backwards if I were to
do a one-shot
partial cloning then run a format adjusting script?

Thanks,
Mark

---

From: Stuart Raeburn <[email-masked]>
Date: Wed, 28 Mar 2012 09:08:00 -0400

Hi,

> Is there any reasonable way to do this? What files get mucked up in   
> the 32 to 64 bit transition?

The procedure adopted at MSU when using a 32-bit server as a clone of  
a 64-bit LON-CAPA production library server (e.g., for  
testing/troubleshooting) is to replace the standard rpm for gdbm  
installed for the Linux OS/arch with a custom gdbm created a few years  
ago (by Guy Albertelli).

Replacement of the gdbm rpm is on the 32-bit development server, and  
the custom rpm provides a gdbm on that server that can read .db files  
created on 64-bit arch.

Developers with access to CVS can find src rpms for the custom gdbm 1.8.0 in:
modules/msu/gdbm
I just added the src rpm I have used for CentOS 5 to that directory in CVS.

On CentOS 5, if you install rpm-build

yum install rpm-build

and copy the src rpm from modules/msu/gdbm in your local CVS checkout  
to: /usr/src/redhat/SRPMS/

you can then do:

cd /usr/src/redhat/SRPMS/
rpm -i gdbm-1.8.0-64bit.26.2.centos5.src.rpm
cd ../SPECS
rpmbuild -bb gdbm.spec
cd ../RPMS/i386

On CentOS 5 you will then want to replace the standard:  
gdbm-1.8.0-26.2.1.el5_6.1 rpm with the gdbm-1.8.0-64bit.26.2.centos5  
you just created.

rpm -Uvh gdbm-1.8.0-64bit.26.2.centos5

or you could use yum localinstall.

Let me know if you have any questions.

Stuart Raeburn
LON-CAPA Academic Consortium