Filepro-list Digest, Vol 42, Issue 48

[Boaz Bezborodko]

> Date: Thu, 26 Jul 2007 18:02:28 -0400
> From: "Brian K. White" <brian at aljex.com>
> Subject: Re: Filepro-list Digest, Vol 42, Issue 41
> To: <filepro-list at lists.celestial.com>
> Message-ID: <003101c7cfd0$a81eda90$861fa8c0 at tv>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> 	reply-type=original
>
>   
>> (It's a bit funny for me to read on this list a suggestion to move to
>> Linux when some on this list were somewhat hostile to me when I wanted
>> to do the same.)
>>     
>
> As I recall it, the problem was not desiring to move to linux, or 
> investigate linux, or any other alternative options.
> It was that you seemed to be switching over a live production system 
> overnight to a system you knew nothing at all about yet, nor contracted 
> anyone else who knew about it. You just lept and hoped for the best, got 
> lucky and only had one mildly serious problem that managed to get cleared up 
> fairly quickly and without too much data mess along the way, and thus seemed 
> to conclude that the way you did things was fine and what's all the fuss 
> about? Bravery is admirable in many situations but I'm glad I wasn't your 
> customer that day.
>
> If it was a desperation move because the old box was crashing and you didn't 
> have time to learn a new system, thats understandable, but in your position, 
> assuming I was familiar with windows and netware, and did not have time to 
> learn a new system first, I would have done any of these 3 things:
> 1) Copy the data to a windows box and host it from there immediately. Thats 
> very easy to do, everyone knows how to create a windows share and solve 
> authentication & other common access problems and win boxes abound. They 
> would be off the crashing netware box in an hour plus however long it takes 
> you to go around to the rest of the machines and change filepro batch files 
> or desktop icons. I would not consider this a permanant solution but it is a 
> great temporary solution because it is very easy and safe and fast.
> 2) Get a new copy of netware and a new netware server box and restore 
> everything to roughly the same state as the old box.
> 3) Hire a linux guy to set up a linux box and do any ongoing maintenance 
> until you could do it. By this I mean set up a samba share and actually 
> continue to use the windows version of fp. This is actually not much of  a 
> "migration". In this case the fact that the server is linux hardly makes a 
> difference vs netware vs windows.
>
> I probably would have done 1 immediately and then investigated 2 & 3 at my & 
> the customers leirsure.
> Maybe in that case as long as the win box is doing ok, then instead of 2 or 
> 3 you could do 4) Take your time bringing up a linux box and learn the 
> important parts yourself before switching over to it for real.
>
> What are the important parts?
> 1 be able to install a new box.
> 2 be able to make the basic networking  setup and and later changes.
> 3 be able to perform a backup.
> 4 be able to perform a non-destructive partial restore.
> 5 be able to perform a full restore.
> 6 be able to set up, config and then manage the services you happen to need 
> (in your case, samba, possibly cups)
>
> Not until _after_ you can do all that, or have a consultant on tap who can, 
> do you have any business putting a customers live data on a new type of 
> system. 1 & 2 are pretty easy these days. Almost does itself. BackupEDGE 
> makes 3, 4, & 5 effortless, otherwise feel free to spend as much time 
> learning the use of star, rsync, & the plethora of other backup utils as you 
> like.
> 6 is the tricky one as you discovered the hard way. There are things you 
> don't even know that you don't know, like the various and sometimes subtle 
> locking behaviour options in samba. Knowing what you don't know is worth 
> more than knowing any amount of other stuff.
>
> But once you do have these basics nailed, then you can handle any problem at 
> least in a crude way and then it's not irresponsible putting a customer 
> there.
>
> Actually, the best would be 5) Run the app on linux using linux fp binaries 
> and ferret out all the windows-isms scattered around in the code, instead of 
> just using a linux box as a drop-in replacement for a windows or netware 
> shared drive. But thats a longer term project and not an appropriate 
> solution for a box thats crashing today.
>
> Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
> filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!
>   
I'd have to read up on my old messages to find out if I conveyed such 
urgency or not, but I remember not feeling that it was that urgent.  I 
had two corruptions in the span of about 3 months and I wanted to move 
over as an alternative.  As it turned out it took me about 2 months 
(real time--I was doing a lot of other stuff at the time as well) to 
climb the learning curve and get a server up and running with backup 
and, yes, I did use BackupEdge.  After that I started moving over 
different services and finally brought FP over about a month or two later.

What I learned in the process is that the learning curve on Samba was 
steep enough that I probably would have been better off moving FP to 
Linux instead, but this was mostly because I was trying to get more 
granular security functionality out of Samba than it was designed for.  
(Afterwards I found that the problem was that RHEL 4.4 is packaged with 
upgraded versions of Samba 3.10 and some of the granularity I was 
looking for wasn't added until 3.11.  The Samba manuals aren't all that 
clear about this.  THEL 5 is packaged with Samba 3.23, but it wasn't in 
final release at the time.)  Part of the problem was that I was spoiled 
by the granularity and easy tools available to me on the old Netware box 
I had.  (Best up time on that one was 580 days when I took it down to 
upgrade the tape backup unit.)

BTW, the locking options for FP weren't ever a problem since someone 
here was kind enough to give me the configuration options that FP would 
require.

Upgrading to FP Linux will now have to wait until we're ready for a new 
upgrade or we come up with problems we can't deal with otherwise.


Boaz