To compile or not to compile?

From: Damien Hull <dhull@digitaloverload.net>
Date: Tue Jan 02 2007 - 15:47:03 AKST

I'm quoting you here.

    Regardless, I'm going to put this as simply as possible: 90% of the
    problems you guys are having aren't issues with Nevaeh, they're
    package-specific issues that exist on all platforms. Preconfigured
    binary
    packages can allow you to be ignorant of a lot of things, and that's
    why you
    don't deal with it on other distros. I agree that Nevaeh doesn't
    tolerate
    that way of thinking. It rarely makes assumptions for the admin, and
    when
    it does it makes the most paranoid one. None of this, though, would stop
    anyone who's very familiar with the package in question, and with
    any dev
    environment.

    As for that 10%: they're still not Nevaeh issues, they're *UNIX* issues,
    and while my base philosophy is different from yours, any capable admin
    should be able to figure out how to change them. It's not like I
    implement
    a kernel root kit to enforce my way of thinking. It's all a simple
    matter
    of editing a few text files. And they're all *standard* files.

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.

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.

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 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.

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.

   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.

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.
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue Jan 2 15:47:35 2007

This archive was generated by hypermail 2.1.8 : Tue Jan 02 2007 - 15:47:35 AKST