[ipac] installing HIP 3.x

Wed Jun 11 12:41:11 EDT 2008

SD was somewhat ambiguous for HIP. Horizon on Linux absolutely must be
on RH4.

What I found was that HIP on RH5 works, but it is not very stable. I did
a rebuild on my server and installed RH4 and HIP seems stable now. I
suspect is has to do with running java 1.4.2 on RH5, but I can't prove
it.

John

-----Original Message-----
From: ipac-bounces at lists.tblc.org [mailto:ipac-bounces at lists.tblc.org]
On Behalf Of Jonathan Rochkind
Sent: Wednesday, June 11, 2008 10:39 AM
To: Dynix's Horizon Information Portal,formerly iPac (discussion)
Subject: Re: [ipac] installing HIP 3.x

Is HIP officially supported on RH5, or does it officially require RH4?

If it officially supports RH5, then I'm sure I had the machine built 
with RH5. But if you guys are saying I want to avoid it, I better 
rebuild the machine.

Jonathan

Chadwick, John, DCA wrote:
> Thanks for the extra pointers Michael, we have just completed our
> migration HIP migration and I am doing the switch over later today. I
> ran into a lot of problems with RH5 running HIP and had to rebuild the
> machine using RH4 and reinstall. After a couple of tries, it worked.
>
> The biggest thing I found in our migration was backing up the
> ipacadmin.gdb file and restoring it. This must absolutely be done with
> the firebird process turned off on the old machine for the backup and
on
> the new machine when restored. Otherwise, you corrupt the data.
>
> Another thing I discovered involves the startup scripts in /etc/init.d
> have /sun in the path for starting the processes. Commenting out any
> line with /sun works for the xsl script and the hzapp script. It is
best
> to edit hzsearch and hzindex files and replace /sun with /linux.
>
> John Craig was a good teacher, which helped me when I had to go from
RH5
> to RH4. I also worked with Jessica Moody at SD, she really knows HIP
on
> linux.
>
> John
>
>
+-----------------------------------------------------------------------
> --+
> John Chadwick, Ed.D. Information Technology Manager
> New Mexico State Library
> 1209 Camino Carlos Rey
> Santa Fe, NM 87507
> Phone: 505-476-9740  Cell: 505-629-8116 Fax: 505-476-9761
> john.chadwick at state.nm.us
> http://www.nmstatelibrary.org
>
> -----Original Message-----
> From: ipac-bounces at lists.tblc.org [mailto:ipac-bounces at lists.tblc.org]
> On Behalf Of Michael Silver
> Sent: Wednesday, June 11, 2008 10:03 AM
> To: 'Dynix's Horizon Information Portal,formerly iPac (discussion)'
> Subject: Re: [ipac] installing HIP 3.x
>
> Hello,
>
> It depends what you mean by "no downtime" - if you really mean
> absolutely no downtime for any user, then it's beyond what I try to
do.
> I minimize downtime and often try to do these things in the wee small
> hours of the morning, but there are a few minutes of downtime.
>
> These notes all deal with Linux installations - if you're running
> Windows the general process should work but the paths and commands
will
> definitely be different!
>
> Major parts of the move are:
>
> * Installing HIP on the new server. DANGER, WILL ROBINSON!
> * Copying your xsl stylesheets and configuration from the old server
to
> the new.
> * Creating (or possibly copying old) HIP indices on the new server.
> * Copying your ipacadmin.gdb database from the old server to the new.
> INVOLVES DOWNTIME
> * Updating word_index and matham tables in Horizon.
> * Updating DNS records, firewall policies, etc.
> * Bring up new server.
>
> Notes:
>
> Installing 
> ==========
> I usually install from scratch rather than trying to copy the entire
> /opt/dynix structure. Theoretically, if the operating system and
> architecture are the same this might work, but I feel you get a
cleaner
> instance doing a fresh install. 
>
> The DANGER note is because you must not start the indexer on the new
> server while the indexer is running on the old server. Running
multiple
> indexers against the same database results in incomplete indices on
both
> servers!
>
> XSL
> ===
> I copy the /opt/dynix/xsl/xsl folder and the
> /opt/dynix/xsl/xsltransformer.xml files to the new server after making
a
> copy of the original ones. If you've set up multiple xsl processors,
> you'll need to copy the multiple start scripts or recreate them.
>
> Start the xsl processor(s) and make sure it's (they're) running
> correctly.
>
> HIP indices
> ===========
> The indexer updates the indices as the database changes. They'll work
> just fine without the indexer running although they will be
out-of-date.
> To rebuild the indices on the new server, you have to stop the indexer
> on the old server first. The old HIP will continue to operate while
> building the new indices.
>
> Start the mass indexer on the new server. Don't start hzsearch or
hzapp
> on the new server until at least 50000 records have been processed.
> Since you're building a new server, I wouldn't start those processes
> until the build is complete.
>
> The mass indexer will automatically become a dynamic indexer after
it's
> run, but I usually stop the indexer totally, then start the dynamic
> indexer. That's primarily because I run the mass indexer in the
> foreground so I can monitor the progress.
>
> Theoretically, you could copy the indices from
> /opt/dynix/hznindexservices/indexes/ on the old server to the new if
> you're using the same architecture and operating system. I haven't
> tested this since I always rebuild from scratch.
>
> There is a document on the SD support site about rebuilding indices in
> the background. You basically create a second instance of the
> hznindexservices directory, stop the indexer in the main one and start
> the mass indexer in the temp one. Once the indices are rebuilt, you
stop
> the hzsearch in the live one, copy the indices from the temp directory
> to the live directory (after making a backup, of course) then start
> hzsearch and the dynamic indexer. Seems to work well, and minimizes
> downtime. The document title is "Keeping a backup of healthy hip
> indexes: Regular mass-indexing in the background".
>
> ipacadmin.gdb
> =============
> Here's the downtime part. Shut down hzapp on both servers, then create
a
> transportable backup on the old server. Do this with the following
> command all on one line:
> /opt/firebird/bin/gbak -IG -V -B -T -USER SYSDBA -PASSWORD password
> /opt/dynix/appserver/jboss/server/default/data/ipacadmin.gdb
> /opt/dynix/appserver/jboss/server/default/data/backupfilename.gbk
>
> Note that there are graphical tools to do this and the restore
mentioned
> below, but I don't use them so I can't give you any pointers there.
> Check out 
> http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_admin_tools 
> for a list of available tools. You would run them on your desktop and
> connect using the network.
>
> Once the backup is created, transfer it to the new server, and restore
> from the backup using the following command all on one line:
> /opt/firebird/bin/gbak -USER SYSDBA -PASSWORD password -C -REP -V -P
> 4096 /opt/dynix/appserver/jboss/server/default/data/backupfilename.gbk
> /opt/dynix/appserver/jboss/server/default/data/ipacadmin.gdb
>
> NOTE: The command above replaces the existing ipacadmin.gdb database
> without making a backup. If I was overwriting a live database, I would
> make sure I have an backup of the existing file before blowing it
away!
>
> Update Horizon
> ==============
> Change the entries in the word_index and matham tables in Horizon to
> point to the new server. (As an alternative, you could swap IP
addresses
> between the new and old servers - just make sure you never have two
> machines with the same IP address!)
>
> Update DNS, firewall rules, etc.
> ================================
> Change the DNS entry for your server to point to the new IP address,
and
> make sure the appropriate rules exist on your firewall(s) for access
to
> the new server. (If you did the IP address swap mentioned above you
> wouldn't need to do this - the old ones should still work!)
>
> Start hzapp, hzsearch on new server
> ==================================
> You're done! It may take a while for the DNS changes to propagate, but
> the actual work is done at this point.
>
> I think this covers it all. I find that the actual downtime doing it
> this way is less than 5 minutes. YMMV, of course.
>
> I hope this helps. If anyone sees any errors or places to improve,
> please let me know, either on-list or off!
>
> Michael
>
>  
> Michael Silver, Network Administrator 
> Parkland Regional Library 
> 5404 56 Avenue Lacombe, AB T4L 1G1 
> Phone: 403.782.3850    Fax: 403.782.4650
> http://www.prl.ab.ca/  msilver at prl.ab.ca
>
>
> _______________________________________________
> ipac mailing list
> ipac at lists.tblc.org
> http://lists.tblc.org/mailman/listinfo/ipac
>
> ______________________________________________________________________
> This inbound email has been scanned by the MessageLabs Email Security
> System.
> ______________________________________________________________________
>
>
> Confidentiality Notice: This e-mail, including all attachments is for
> the sole use of the intended recipient(s) and may contain confidential
> and privileged information. Any unauthorized review, use, disclosure
or
> distribution is prohibited unless specifically provided under the New
> Mexico Inspection of Public Records Act. If you are not the intended
> recipient, please contact the sender and destroy all copies of this
> message. -- This email has been scanned by the Sybari - Antigen Email
> System. 
>
>
>
>
>
> Confidentiality Notice: This e-mail, including all attachments is for
the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited unless specifically provided under the New
Mexico Inspection of Public Records Act. If you are not the intended
recipient, please contact the sender and destroy all copies of this
message. -- This email has been scanned by the Sybari - Antigen Email
System. 
>
>
>
>
> _______________________________________________
> ipac mailing list
> ipac at lists.tblc.org
> http://lists.tblc.org/mailman/listinfo/ipac
>
>   

-- 
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886 
rochkind (at) jhu.edu

_______________________________________________
ipac mailing list
ipac at lists.tblc.org
http://lists.tblc.org/mailman/listinfo/ipac

______________________________________________________________________
This inbound email has been scanned by the MessageLabs Email Security
System.
______________________________________________________________________

Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. 