[TriLUG] OS recommendations/Aging software issues

David McDowell turnpike420 at gmail.com
Thu Jun 2 13:26:19 EDT 2005


Everyone has made great comments/questions so far... so I'll just
re-iterate some of them.  Make sure your Symantec Manhunt can run on
the distro you want.  Some people, as noted, do run EOL'd distros and
are happy with that.  You have to be willing to put in a little more
effort to keep it updated especially if security is a concern.  I'm a
happy CentOS user and since it is based on RHEL, and would recommend
that if Symantec Manhunt can run happily with it.  Best thing you can
do is test things.  Fedora Core is not a good way to go for servers,
as mentioned, and I found this out the hard way... way way too many
updates and default settings changed in updates that occurred far too
often.

I believe you said this was for a defense contract??  Security sounds
important.  I'd make sure to use a distro that is not EOL.  Also, if
you can afford it, go with RHEL to support Red Hat's efforts,
otherwise CentOS!!  Good luck!

so there's my thoughts... :)
David McD


On 6/2/05, sholton at mindspring.com <sholton at mindspring.com> wrote:
> My turn to step-in and be the contrarian.....
> 
> Welcome to the world of Open Source. One of the first things you need to
> learn to do is leave behind the pre-conceived notions which have served
> you well in the world of proprietary software. They will not serve you
> here, but there are other tools which may serve you better.
> 
> Unlike proprietary software, when you buy an Open Source product
> (here it's RedHat 9) you have actually bought the product, not just
> the right to use it. It's an important distinction that many people
> (including many of the very clued Linux people on this list) miss.
> 
> As the owner, it is now _your_ responsibility to ensure this product
> is supported to the extent you need support. In house or external
> is your choice, as is how much you want to spend.
> 
> That's the heart of the problem you're seeing now.
> 
> If you try to run the RH9-era version of Manhunt on a non-RH9
> box, you may find incompatibilities. The chance of this increases
> with the increase in differences in /vintage/ between the two. and
> while the difference between RH9 and FC2 may be small enough
> today, there's always going to be the possibility that a future update
> causes problems.
> 
> It works in the other direction as well: should you choose to keep
> the RH9-box as is, but need to deploy an updated Manhunt, there
> could be problems.
> 
> Keeping the RH9-box and RH9-era Manhunt will keep the vintage
> of those two products in-tune. In this case, pressure will come
> at the interfaces with a (necessarily evolving) external world.
> 
> This is the infamous "network effect" in action.
> 
> Having an Open Source RH9 offers you an advantage here; it is
> /technically possible/ for you to update the RH9 installation to keep
> it current (security patches, advancing hardware support, new
> protocols, etc) while still maintaining the RH9 facilities Manhunt
> needs to run. If you can't do it yourself, you can hire others.
> 
> But clearly the driving factor will be Manhunt, since you don't
> control that component. If you need support from Symantec,
> and they only support a version running under RHEL, you'll
> be filling-out a P.O. for RHEL, or you'll be deciding you don't
> really need Manhunt support that badly. You'll have no other
> choice.
> 
> (This is one of the reasons why Stallman insists that /all/
> software must be free.)
> 
> So here's the questions I'd seek answers to:
> 1. Are you currently entitled to support from Symantec for
>    Manhunt?  What are the conditions of this support, such as
>    cost and required versions? Do you utilize the support you
>    are entitled to?
> 2. Is it /technically possible/ to get the version of Manhunt
>    you'll be using to run on anything other than the RH9 box
>    you've been told to use? If not, this whole discussion might
>    be moot.
> 3. What pressures are there now (and are there likely to be
>    in the future) to change the version of either Manhunt or
>    operating system? These pressures might include evolving
>    requirements from your users, failed and no-longer supported
>    hardware, newly exposed security vulnerabilities, and perhaps
>    difficulty in finding people clued/motivated to support RH9.
>    (I would *not* include "I don't like...going to think is stupid" as
>    a valid reason for change here, but your situation may be different.)
> 4. What resources are currently available for this project? We know
>    your boss has offered at least one person (you) to support the
>    configuration he wants. Is there money in the budget for a new
>    version of Manhunt? For RHEL? If you're currently paying for
>    a support contract from Symantec, could you cancel it and instead
>    purchase RH9 support instead?
> 
> I hope this helps.
> 
> --
> "Currently running a $0 budget production box on RH7.2 and /lovin it/."
> 
> sholton at mindspring.com
> 
> 
> 
> 
> -----Original Message-----
> From: Marc M <linuxr at gmail.com>
> Sent: Jun 2, 2005 9:34 AM
> To: For users of Fedora Core releases <fedora-list at redhat.com>,
>        Triangle Linux Users Group discussion list <trilug at trilug.org>
> Subject: [TriLUG] OS recommendations/Aging software issues
> 
> Hi,
> 
> I work for a major defense contractor that is very tight with money at
> times. Two years ago, before I came, they got RH 9 (bought or downloaded-
> whatever). I guess that got deemed appropriate to buy at the time, and it
> has been sitting here getting old ever since. The purpose of this server is
> to run Symantec Manhunt on it as an IDS. They bought Manhunt at the same
> time and never got around to deploying it until now.
> 
> Now I am about to deploy a linux server (Dell) and I am trying to figure out
> which version to go with - RH 9, FC 1-3, or whatever. I want it to be
> redhat-based since I am the main admin, and I am more comfortable with that
> than on debian based systems.
> 
> On the other hand I am not sure what to do. My boss makes the argument that
> we need to run the oldest, since he has seen versioning issues and conflicts
> in this situation. However most of that is in the world of Windows which
> does stupid things by default as we all know.
> 
> In this scenario my argument is <still> that we should go with something
> more recent. I don't like the idea of putting something out there that is so
> old it isimpractical by today's standards, that am going to think is stupid.
> I guess there is some wisdom in being able to keep the age of the OS in sync
> with the age of the software, but in the linux realm, that really isn't the
> same issue as it is in other areas - right? OTOH I don't want to do a 'yum
> update' on the box and not be able to get updates because the version is so
> <frickin'> old. I think FC2 would be a good choice. Although it is still
> old, it at least is a little bit ahead of RH9. An additional concern - even
> if I were to deploy FC2, I would probably want to upgrade that too. Is that
> gonna be a problem? Can I upgrade versions of Fedora (2 to 3 to whatever) on
> a production box without a lot of problems? Will yum do that cleanly and
> consistently without a lot of headaches?
> 
> Whatever choice I make is going to have to last for a good while. Does
> anyone have any advice for this situation?
> 
> Thanks in advance
> 
> Marc
> --
> TriLUG mailing list        : http://trilug.org/cgi-bin/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
> TriLUG PGP Keyring         : http://trilug.org/~chrish/trilug.asc
> 
> 
> --
> "Convenience causes blindness. Think about it."
> 
> Steve Holton
> sholton at mindspring.com
> --
> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
> TriLUG PGP Keyring         : http://trilug.org/~chrish/trilug.asc
>



More information about the TriLUG mailing list