On Tue, 2006-06-20 at 07:54 -0400, G. Matthew Rice wrote:
> Totally agree.  And level 3 is intended to focus on the enterprise.  You
> mentioned 'ISP' a couple of times.  Is there some belief (from before my
> time?) that lpic-1/2 is ISP focuses or something?

No.  But they tend to dominate some of these discussions and user lists.
I find that 90% of the Linux consultants I run into (or rather their
"work") came from the ISP industry.  Hence my regular issue (especially
the "I've heard NFS is insecure" when immediately gets back my shot,
"and Samba is regularly configured far less secure than NFS!" --
especially for those of us that actually use Kerberos for NFS
authorization ;-).

I don't pretend to be a serious web developer or Apache uber-guru.  In
recent years, I've only worked at one client in the ISP/ASP industry for
3 months and, again, learned to get the hell out of that penny-pinching
arena.  It was fun when I was in late high-school and college,
maintaining SCO, Solaris and then Linux servers for SMTP, NNTP and then,
eventually, CERN HTTPD and the "patchies" for it -- getting paid US
$6/hour.  But I left it only to return once in 2003 and realize I was
working 90 hours/week for half my typical rate (long story and a stupid
decision by me -- one I resigned from after giving it a full 90 days and
I'm glad I did).

There are many things that you don't do in an ISP/ASP environment, such
as run RPC services (except for maybe tunneled).  You also don't have to
be as concerned about LAN/WAN services, because your access is not by
desktops using those protocols -- but by desktops using browsers, etc...
That was Linux's hay-day for me in 1993-1994 -- Apache was (and still
is) a killer app.  But I purposely stay away from that arena now, and
more of my clients that have departments that maintain their on-line
presence are outsourcing more and more anyway -- it's just not worth the
cost internally.

I go into many shops and I'm looking at a mess of SSH, Rsync, SMBfs,
etc... that is just horrendous, unmanageable and constantly going down.
It's standalone, unintegrated and Windows desktops and UNIX/Linux
desktops can't share a thing.  People have to change their password in
3-4 different systems.  Access to the same data is a PITA -- e.g.,
someone writes something, now something else can't access it, etc...
And to make matters worse, the management is just about to just put in
more Windows services instead (and I can't really blame them for what
they were given by the prior consultants).

I just wrote a 21 page discover for a new client the other weekend which
included several options.  They had never even heard of most of them,
even though they are pretty staple to UNIX/Linux enterprises.  As
always, I constantly hear "oh, I didn't know they had something like
that available for Linux."  I get the same responses when I do Linux
training -- there's always 2-3 Windows/ADS experts and I start breaking
it down into the base technologies and those services on Linux that are
equivalent.

"I didn't know Samba had nothing to do with that" is also a common
response.  Samba is _not_ and will _never_ be even remotely an ADS
replacement on its own, and not merely with its "base LDAP schema"
either.  It's really a set of services for interacting with Windows,
_not_ providing a core staple of native UNIX/Linux capabilities --
although it can very easily rely on those.  Winbindd is _not_ often used
by enterprises for Windows-UNIX/Linux sync.

We're building a program that is for enterprises, not ISP/ASPs -- at
least that is my assumption.  It doesn't mean we can't have more
ISP/ASP-centric exams (starting with the "Internet and Web Services"),
but from what I've seen, LPIC-3 is targeted at enterprise administrators
to start.  This means we're going to be talking about things you don't
see in an ISP/ASP environment -- although having something like a KDC in
an ISP/ASP environment is actually beneficial (I just rarely see it).

> Sounds great to me.  I know that I'll be pinching from it.

I'm hoping to attract a lot of people from Fedora/Red Hat, SuSE/Novell,
Debian/Progeny and even Gentoo -- people with experience rolling out
systems in enterprise environments and integrating them.  There's no
real "source" for such integration knowledge out there.

> How about we do this?  I'd like to put together a more comprehensive road map
> for LPIC-3 over the summer and present it at the TAC (Technical Advisory
> Council) at LinuxWorld in SanFran (Aug) and Cologne (Nov) for review.

Actually, that's more of what I was writing before.  I even made up a
diagram of my recommended path.  I can send that to you off-list.

> ergh.  I don't even want to think about a desktop exam.  That sounds like a
> nice 2010+ project.  Matt Szulik may even agree that the desktop is ready by
> then ;)

Understand Szulik's "real world" position.  There is _no_money_ in the
desktop, and from what I've seen, Novell is finally "waking up" to that
with SuSE Linux Enterprise Desktop (and the end of Novell Linux
Desktop).  It's all about economies of scale, as I talked about in an
old blog posting I made here:  

  "6 Things To Know About Linux"
  http://thebs413.blogspot.com/2005/10/6-things-to-know-about-linux.html

  1.  What the Pricetag on Windows Buys You
  2.  What is Community Developed Software All About?
  3.  Commerical Companies and Community Developed Software (key one)
  4.  Why MacOS X is the "Other" UNIX-Like Platform that People Like
  5.  UNIX Invented It, Microsoft Bought the 3rd Best (Leftover) and
Marketed It
  6.  The Distribution Channel is Not a Technical Problem

*HOWEVER*, that blog posting and most arguments are made from the
standpoint of and for the _SOHO_ consumer.  From an "Enterprise
Configuration Management" (ECM) standpoint, the _corporate_ desktop is a
reality.  That's why I one of the domains on ELResource is a ECM one --
one that provides a "base" for an additional 4 vendor-centric sections.

> IMO, being the default debian MTA really helps Exim popularity.

That's _exactly_ what I was thinking as well.  And Exim has some rather
nice (possibly more secure?) ways to deal with redirection to external
programs than just a "pipe" like Postfix, Sendmail, etc...

> It is possible that we could do one 'mail and collab' exam that is postfix
> centric, one that is sendmail centric, ... (there's that 'cost' thing to
> worry about, though).  I don't think that it's fair to expect someone to pass
> a test where the questions could be on any of them.

My view was to try to focus on LAN/WAN-specific enterprise services on
the "Collaboration and , and leave any more "generic" SMTP details to
the "Internet and Web Services," and any subsequent exams that expand on
it (such as server-side scripting, development environments, etc...)

> We may just have to pick a first MTA, fill out the other exam areas and then
> look at supporting other MTAs...nice problem to have.  Let's get these first
> ones done first...

Exactomundo.

> I have a client that calls it lookOut.  enuf said.

No joke.

"Exchange replacements" are often just as proprietary and useless as
Exchange.  And they still rely on Outlook, giving it little more than a
generic server store for Outlook to do its bidding.  The problem is
Outlook itself -- a client-side system.  If you're lucky, the vendor
provides a web-based interface and nothing else.  And pretty much all of
it is based on the Outlook MAPI toolkit (which will never be open
source, and is licensed by Microsoft).

The only company that I've seen really tackle that problem is SKyRiX --
the OpenGroupware.ORG guys -- OGo being based on SKyRiX 4.1.  They
actually built a true, layered and server-side solution.  It starts with
their open back-end store (WebDAV-based**), adds in logic including a
true scheduling/collaboration component and then countless interfaces**
(everything -- from iCal to Palm.NET to a generic XML-RPC service),
including WebDAV connectors for Evolution and Outlook (the connector for
Outlook is not GPL because it requires a license and run-time from
Microsoft's MAPI development toolkit -- although Evolution's now is,
thanx to Novell's acquisition of Ximian).

**NOTE:  Now that CAP (Calendar Access Protocol) is in draft, there is
no reason why they can't add it to their interfaces.  But SKyRiX
4.1/OpenGroupware.ORG doesn't do it ... yet.

It _never_ stores Outlook's proprietary format, it _always_ stores in
the open WebDAV store (converted by the connector) and then that is then
run through the server-side business logic (which is very flexible and
open-ended).  Same deal for anything else, including not merely being a
iCal (FTP/HTTP) store, but actually scheduling that against all other
data from all the other connectors.  Because _everything_ _always_ goes
into that open, WebDAV store from the various interfaces (and any
additional connectors if necessary).


-- 
Bryan J. Smith           Professional, technical annoyance
mailto:[EMAIL PROTECTED]     http://thebs413.blogspot.com
----------------------------------------------------------
The existence of Linux has far more to do with the breakup
of AT&T's monopoly than anything Microsoft has ever done.


_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/mailman/listinfo/lpi-examdev

Reply via email to