Finally time to start migration to Linux....

[Bill Campbell]

On Tue, Sep 20, 2011, scooter6 at gmail.com wrote:
>Some of you might have seen we have been heavily contemplating the migration
>from SCO to CentOS Linux.
>Well, the time is quickly approaching to get this started.  I have a few
>questions I'd like some guidance on.
>
>The server we're going to be using is a Dell PowerEdge w/Dual Xeon
>processors, 8GB RAM and 4x146GB drives w/Perc RAID controller.
>(this is just what I have to work with - don't shoot the messenger lol)
>
>So, my thoughts are:
>
>1)  Build 2 mirror RAID volumes - one for the CentOS and one for filePro and
>all the data  (would you agree/disagree with this approach? if you disagree,
>I'm open for ideas)

I've always been a bit squeamish about having the main OS on
RAID, but that may be because I've been bitten in the past.  On
the other hand, we had a Linux software RAID array on a Caldera
system for data only, and it was found immediately when I plugged
in the external chassis holding the drive on a newer SuSE system.

Hardware RAID from LSI (nee 3Ware) has advantages, particularly
regarding hot-swap drives, and there are excellent Linux tools.

>2)  I obviously have to migrate the users to Linux (is there a 'quick' way
>to do this? I have about 75 users to create on the new system)

I have python scripts that handle this pretty easily, and they
can handle things like moving $HOME directories from places like
/usr/$LOGNAME or /u/usr/... to /home where they belong.  It's
probably a good idea to assign new uid and gids that are in sync
with the Linux standards.  SCO tends to use low numeric uids
below the range considered standard in Linux.  Group gids are
also a bit different.  The standard CentOS user admin commands,
like Red Hats, like to assign unique groups for each user.

So long as the user and group names are the same between the
systems, rsync can transfer data using modules preserving the
names and converting the numeric uid and gid (see below).  I
generally create rsync modules in the rsync.conf file for each
user, then have a script that loops through all the non-admin
users on the SCO box to sync the data to the Linux system.
Usually we do this twice, the first time to copy all data, which
may be large, the second to transfer updates and delete any files
that aren't on the SCO box at the time.

>3)  I will need to configure our printers, which are Konica/Minolta BizHubs
>-- is there any 'magic' to doing this on Linux vs SCO?

If you have SYSV interface scripts that do anything unusual,
these can be moved to Linux with a little effort as CUPS supports
all the standard 'lp', 'lpadmin' SYSV tools.  We have always used
'netcat' in the interface scripts, avoiding the SCO/HP methods
which can have some nasty surprises.

>4)  We have a LOT of scripts that are written using the Bourne shell
>(/bin/sh) - do I need to do anything magical on the Linux side to make these
>work when I copy them over?

Mostly these should Just Work(TM) unless they do some really
wierd things depending on SCOish tools.  This is probably a good
time to clean out hard-coded files and such, putting paths into
central configuration files.

>5)  We have approx 25 GB of data that needs to move and I will copy that
>over the LAN.  Does anything special need to happen with the filePro data
>files when I move them from SCO to CentOS?

Use rsync.  Others more familiar with FilePro than I can talk to
differences in FilePro versions.

>6)  I'm looking for a backup system that will backup our data nightly -
>something preferably where I can rotate tapes and keep a copy offsite as
>well.We are very heavily dependent on our data (as I'm sure you all are) and
>with any kind of 'downtime' we're in big trouble not being able to produce
>revenue.

Many use BackupEdge or Lone Tar on Linux.

>     Does anyone have any thoughts/suggestions on best way to do daily
>backups, etc?  Our data footprint will continue to grow so it's needs to be
>fairly scalable and be able to grow with us.

Our in-house systems usually do cross-backups where we have
copies of each system on another system either in-house or on
machines we have co-located off-site.  Again rsync is your
friend.

>7)  Anything else I need to 'be on the lookout' for when doing this
>conversion that perhaps I haven't thought of?

Probably.

Bill
-- 
INTERNET:   bill at celestial.com  Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/  PO Box 820; 6641 E. Mercer Way
Voice:          (206) 236-1676  Mercer Island, WA 98040-0820
Fax:            (206) 232-9186  Skype: jwccsllc (206) 855-5792

Everybody is ignorant, only on different subjects.
    Will Rogers