Filepro and Samba

[Fairlight]

On Wed, Nov 08, 2006 at 04:03:54PM -0800, after drawing runes in goat's blood,
Bill Campbell cast forth these immortal, mystical words:
> I certainly think that's a great idea!  While I have Linux boxes in use by
> some very computer illiterate people doing normal office productivity
> things without the benefit of the worms that attack the Microsoft Virus,
> Windows, in the last couple of years, we've been recommending Macs to these
> people with excellent results.

I actually just recommended a switch to Mac for an author friend of mine
who can't stand XP.  There's definitely a reason that artistic types have
grativated towards the platform since day one, despite the proliferation of
the same software under Windows.

> While I agree with Mark that Linux/Unix systems require some knowledge to
> use most effectively, I'm not sure I would go quite as far as he on this.
> At least with *nix systems, it's possible to learn to diagnose problems and
> fix them, whereas it's rare to find a Windows ``expert'' who knows more
> than the Three R's of Windows, Reboot, Reboot, Reinstall.

There's the thing though, is you've got people on these platforms, but I'd
wager you're supporting them.  It doesn't matter where the knowledge comes
from--in-house, self-taught, or contracted; the basic idea is that you
shouldn't try do without the knowledge in -some- form.

I have an acquaintance that has been on SCO for years--since Xenix.  They
had a Caldera 2.3 and 3.1.1.  Their 3.1.1 was left for about...well since
the SCO suit started and Caldera dropped support for Caldera Linux.  It's
got more holes in it than a colander.  They've been needing more and
more open-source solutions as they go more web-based with their filePro
and other web-based solutions.  SCO isn't cutting it, as the ports are
rarely kept current and sometimes buggy, and it costs a mint when he needs
something for that platform, where it would cost 1/20th or less that to do
on *BSD, Linux, or any of the saner BSD or Posix-heavy variants.  So he
asked for a recommendation and I said SuSE 10.  He's got that, and still he
can't do basic admin tasks.  Actually, in my experience, if webmin isn't
installed, he's lost--and he admits as much.  This person can't administer
sendmail or much else without it.  That's called not understanding your
subsystems; if he did, he could do it equally profficiently on SCO or
Linux, yet he keeps claiming that Linux (and more currently, SuSE) is
behind the curve, not PnP enough, and not intuitive enough.  I kid you not.

I actually have seen him break three major subsystems, even using yast.
Not through lack of functionality--yast did what it should have every time
(with the exception of somehow getting a corrupt samba registry file, and
I'm unsure if that's a SuSE or a samba issue--I believe samba was indicated
in my research before I fixed it...and WHY does samba have a registry
these days in any event?!).  Nope, the functionality was there 100% in
the graphical admin tool.  Yet sendmail, samba, apache, and bind were all
improperly configured.  I made the point that these same subsystem packages
(excepting samba) are the same ones he's been using on SCO for years, only
the admin tools differ; if you understand the subsystem, you have no issues
as you can bypass the tools entirely if you want/need.  Apparently the
point is lost on some, as the platform itself keeps getting blamed.

So yeah, I can say I've seen someone doing *nix since '84 or so back in the
old days actually be unable to run a Linux box, and in fact break it quite
spectacularly due to sheer unfamiliarity with the underpinnings of what are
basic and common subsystems.

> The recent versions of SuSE Linux have an excellent graphical
> administration tool that allows the inexperienced to ``learn by
> destroying'' with relative ease.  

Tell me!  Configuring DNS, the NS records option is -right- in both the
curses and GUI versions of yast, plain as day.  Who runs DNS on Windows
servers for at least six years, yet doesn't know enough to put NS records
in a zone and expects it to magically work?  But hey, it's SuSE's fault.
Or RH's.  Or whomever the vendor is.  It's a Linux problem in their mind.
Half the samba config from yast was just plain wrong, and I used yast to
fix it not because I needed to, but to prove yast -could- do the job, once
the registry corruption was fixed.  Let's say that corruption was the least
of the problems with the config, although it was the most obscure and
hardest to diagnose.  Ditto some other things--all were doable in yast, all
were fouled in some of the most basic ways despite the visual cues that
said, "Hey, configure me!"

Even those relying on admin tools -still- can do great disservice, if not
outright harm to their *nix systems.  It's at the point when someone asks,
"What do I need, what should I worry about, and oh by the way, I'm putting
this into a production environment, how easy is it?" that my red flags go
up and I start hearing, "Danger!  Danger, Will Robinson!"

I've seen instances where even people that have "adminned" SCO systems for two
decades cannot perform the most basic tasks or configurations when they
try, even using the tools provided to do it more easily.  When someone has
to ask the questions (which, to their credit, -are- best asked before
commencing, rather than presuming they'll know enough), it becomes an
indicator that someone may be about to make an expensive mistake in time,
money, or probably both.

This isn't one person, either.  I've seen this kind of experience repeated
by I don't know how many people over the years.  None that went through
this should have migrated without first learning a lot more, or hiring
someone to do the job.

> Another factor with *nix systems is that it's easy to allow secure shell
> access to the system so that somebody who knows the system can get in
> remotely to diagnose and fix problems that are beyond the competence of the
> local folks.

Windows does too.  I call that RealVNC.  :)  They also have in XP this new
Remote Assistance thingiemabob (that's the technical term, I believe) that
does about the same thing, I gather.

> We have numerous *nix installations where there's nobody on staff who knows
> much more than how to change backup tapes.  A typical example is a trucking
> and warehousing company that has a Linux server and four Mac Minis that
> they use primarily to run my accounting software in xterms to the server.
> They use OpenOffice.org for word processing, spread sheets, etc, and
> Thunderbird and FireFox for e-mail and web access.  I originally replaced a
> Sage Micro box there in 1992 with an SCO 3.2v4.0 system on an Intel 303
> Tower box.  That box was replaced with a Caldera OpenLinux 1.3 box in 1998,
> and I just replaced that box with a new SuSE Linux system a couple of weeks
> ago.  I doubt that I have 30 days billable time with this customer since
> installing the original system 14 years ago.

Yeah, but you know your stuff, and we all know it.  Like I said,
outsourcing the knowledge is one of several options--but the knowledge
has to come from somewhere.  You can't just plop a box down in production,
knowing near nothing, not taking the time to learn the system, and
hiring/contracting nobody to do it for you, and expect miracles to present
themselves.

> I have found serious issues running things like QuickBooks with the files
> on Samba shares, mostly due to the brain-dead file locking mechanisms under
> Windows.  I'm a firm believer that data applications should really be run
> on a server where things like record locking can be handled in shared
> memory, not with a bunch of separate machines accessing the data files in
> the file system and depending on some kind of file locking mechanism.

Yeah, until someone mismatches shared memory segments.  I remember a case
where fP was on 5.0.14, but (apparently, I'm told by someone I've no
reason to doubt) the license manager or something was being rolled back
into that version, and two different versions of 5.0.14, one previously
running, the other a bugfix release for a segv-inducing bug, were mutually
incompatible.  If you ran one, the other would not run--and then would
render shared memory so corrupted that -neither- would actually run, as the
new one was crashing at a point after it claimed shared memory but before
it actually freed shared memory on the last instance out.  It was one of
the few occasions where, short of a few hours of analysis and an attempt
to clear it out manually with some C code (which would have been terribly
cost-inefficient for this one instance), I've actually had to reboot a *nix
system due to an application misbehaving in order to get it running again.

mark->
-- 
Try our new SPF-0 lotion, SunScream[tm].  Get it while it's hot!