[Fwd: Re: To compile or not to compile?]

Here's Arthur's response to my post.

-------- Original Message --------
Subject: Re: To compile or not to compile?
Date: Thu, 4 Jan 2007 13:46:48 -0900 (AKST)
From: Arthur Corliss <acorliss@nevaeh-linux.org>
To: Damien Hull <dhull@digitaloverload.net>
References: <459AFD07.9080607@digitaloverload.net>

I'm no longer on the list, so you'll have to relay this to the list for me,
if you'd like to share the response.

On Tue, 2 Jan 2007, Damien Hull wrote:

<snip>

> I agree. Compiling software for "servers" will allow one to switch between
> different distributions. Compiling Apache, MySQL and PHP should be the same
> on most distributions. Somewhere I've got instructions for doing just that.
> However, it's a little more complicated then ./configure, make && make
> install.

I agree that there are complicated compilations, particularly for those that
don't use autoconf. That said, if you're using Nevaeh's nlbuild system you
only have to figure it out once. Updates from that point on are merely
updating a version tag and uploading a new tarball. That's worked prettly
reliably for me for years. My default apache setup on Nevaeh is Apache
1.3.x w/mod_perl & mod_ssl. I also have PHP available as a separate package
that compiles as an apxs-generated DSO.

> When I meet a new client I have three main issues I have to think about.
>
> 1. What does the client want? (fix whats broken, add services etc..)
> 2. What are the technical issues?
> 3. What solution is the client comfortable with?
>
> Number 1 is not as easy as one might think. Most of the time the client has
> no idea what's broken or what they need in terms of services.

Agreed. If the client knew that, they probably don't need you.

> Number 2 is based on question 1 and the software I know I can support. The
> software needs to provide a services and or fix the problem the client is
> having.
>
> Number 3 is the crazy one. I need to come up with more then one option
> because the client is uncomfortable with changes. It's their network and I'm
> playing with their data. If something goes wrong it could make the situation
> worse. The client doesn't want that to happen. This means the client may
> force me to make changes in step 2. It sounds crazy but it happens. Even when
> things are broken and they haven't been able to get work done for a week they
> still don't want big changes on their network.

I'm not entirely sure where you're going with this. My response to your
initial considerations from a previous e-mail were in response to deploying
a distro that suddenly becomes unsupported. I disputed your claim that
you'd have to rebuild the platform. In my experience both inside and out of
corporate data centers its common to have platforms and applications running
that one or the other, or both, have become EOL'd. Security in the open
source world saves you in that even if your distro is no longer supported
you can easily add a security patch, etc., and rebuild the affected
application.

Don't know how to do that? How about looking at your distro's build
scripts? Even RH has SRPMS that bundle their current set of patches, etc.
That methodology can carry you for years until the package developer comes
out with a radically new upgrade. Even then, you don't have to upgrade
unless you absolutely have to have that new version or they refuse to do
maintenance patches on the older revs. No big deal.

Regardless, yes, I understand your concerns with making changes on the
customer's systems, but Sys-Admin 101 says always to have a backup plan.
Back up the data, back up the application, and upgrade. If it doesn't work,
roll back. I'm not sure how having a "supported" distro saves you from
having to do that. There's plenty of real world examples where distro
updates have broken previously working features, so you're still at risk
there.

Your argument only makes sense if you actually *trust* the distro maintainer
to do due dilligence and proper regression testing. If that's your stance,
you're a far more trusting soul than I am. *You're* on the hook for your
customer's data, not the distro maintainer. They're not going to care if
you nuke the system, they'll simply claim you should have tested before
before deployment. And they'd be right.

> I also have to think about updates to the software. Will I be doing the
> updates or will the client do them? I installed a CentOS email and web server
> a while back. The client new enough about Read Hat that he could run "yum"
> and update CentOS. They have never called me back.

That's great if they've been able to update themselves with no troubles.
But I'd caution you to not make the mistake of thinking that's how it's
always (or even in the majority of circumstances) work. One customer with a
simple setup is still anecdotal evidence, it's not empirical or definitive.
Try talking to many RH customers with commercial support contracts.

> Taking all that into consideration I'm not sure how compiling fits in. I'll
> use my current clients as an example again. Here's a short list of software I
> had to install.
>
> 1. Apache
> 2. MySQL
> 3. PHP
> 4. Postfix
> 5. SASL
> 6. Courier ( IMAP and pop3)
> 7. SpamAssassin
> 8. ClamAV
> 9. ssh (server)
> 10. Webmin
> 11. Samba
>
> I call that a short list because there are dependencies that get installed by
> the package manager. On Ubuntu a few things get configured auto magicly.

Not to nitpick -- I know I'm more paranoid than the average chucklehead --
but "automagically" should scare you. Odds are it's not going to be the
safest and most secure configuration. Odds are it's going to be the most
general configuration that will work for the most types of installations,
but serve none of them as best as it could or should.

> 1. How do I manage the software and all the dependencies required to
> install it?
> 1. Updates
> 2. Security patches
> 2. How does the client maintain this?
>
> Linux is a tough sell. I don't want to make an all ready difficult situation
> worse. If I tell my clients they need to compile from source to upgrade they
> might run away. Package managers can be confusing but it's a lot easier then
> compiling from source. I can tell a client to type "sudo apt-get upgrade".
> I'm not about to explain to them how ./configure works.

My solution was to do psuedo-package management based on source with
nlbuild. If I need to update sendmail and all its dependencies I just do a:

  nlbuild -v -c -d -r sendmail

This automatically updates sendmail and all downrev dependencies -- but from
source. I don't see how that's any harder than your apt-get, other than
being more time consuming because of the compilation process.

Even so, I agree that a solution like mine is not tailored for people with
zero technical skills. But going back to the genesis of the thread, as
AKLUG that shouldn't be how you (AKLUG) intends to operate. I would think
that as a professional or trade organization you would assume there'd be
skilled help to maintain and administer the box.

> If anyone thinks I'm crazy let me know. I'm just trying to make it work for
> both me and my clients. Sometimes the client is crazy but their the one
> paying my fee.

I have clients to support in addition to my day job in AT&T. I'm paid to
administer and mantain systems infrastructure. In both circumstances going
to a system like Nevaeh provides much more benefit to an admin, and it puts
my infrasture at a lot less risk.

Your mileage may vary.

To sum this up: what distro you use needs to be defined by what you think
your role as a sys-admin should be. In my eyes, a sys-admin should
understand every moving part on their OS. If they don't, they cannot
truthfully say they can vouch for the security and hardness of the system.
In my eyes, only the admin and the users have a vested interest in the
integrity and security of the data stored on the system. Trusting a third
party to keep your system secure, whether by updates or otherwise, is
foolish. That's why I watch the security mailing lists myself. It's my
responsibility to evaluate an exploit for applicablility to my
configuration. And its my responsibility to alleviate any problems as soon
as they are identified. My customers won't accept that a system was
infiltrated because I was still waiting for a third party to come up with a
binary package to fix the problem.

Trust no one, secure yourself. All Linux distros are based on open source
software. There are no excuses.

        --Arthur Corliss
          Bolverk's Lair -- http://arthur.corlissfamily.org/
          Digital Mages -- http://www.digitalmages.com/
          "Live Free or Die, the Only Way to Live" -- NH State Motto

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Fri Jan 5 11:43:33 2007