Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip
From: Benjamin Krueger (benjamin@macguire.net)
Date: 04/19/02
- Next message: Giorgos Keramidas: "Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip"
- Previous message: Karsten W. Rohrbach: "Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip"
- In reply to: Karsten W. Rohrbach: "Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip"
- Next in thread: Nate Williams: "Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip"
- Reply: Nate Williams: "Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 18 Apr 2002 17:14:54 -0700 From: Benjamin Krueger <benjamin@macguire.net> To: "Karsten W. Rohrbach" <karsten@rohrbach.de>, Benjamin Krueger <benjamin@macguire.net>, Jeff Palmer <scorpio@drkshdw.org>, freebsd-security@freebsd.org
* Karsten W. Rohrbach (karsten@rohrbach.de) [020418 16:43]:
> Benjamin Krueger(benjamin@macguire.net)@2002.04.18 15:43:38 +0000:
> > Like it or not, Brett has raised a concern which is entirely valid and echoed
> > by many system administrators. ( I have a feeling the number is not small )
>
> but you are missing the point that _administrators_ have the option (and
> the knowledge) to upgrade from source, using a builder system, just like
> most freebsd admins with larger installations do.
Indeed they do. Doing this for 1000 individual servers, even when scripted, is
an incredible task, and not very feasible.
> > FreeBSD currently does not enable easy maintainance between critical release
> > points for large server environments. Using cvsup to maintain source builds
> > for environments like these ( say 400 servers or more ) is not only
> > unacceptable without an on staff developer and release engineer, it is
> > infeasible.
>
> at my previous employer we had 1000+ customer boxes out there, some with
> maintenance contracts, and freebsd turned out to be the most performant,
> most stable and cheapest solution. i would be delighted to see the
> numbers you get under the bottom line for TCO of the three platforms.
I'm not sure why you're bringing up TCO here. A change like this would help
reduce your TCO. How many hours did you spend every update with those 1000
servers? How much does it cost per hour for your company to employ you? What
kind of profitable work would you have been doing if you only had to apply
patches instead of building? How much will it cost them if you fubar and a
customer goes down?
> > For those of you who would be quick to note that "Corporations with 400
> > servers should be able to afford a developer and release engineer" please
> > note that 400 NT, Solaris, AIX, or HP-UX servers can be maintained by a small
> ^^^^^^ ^^^^^
> > team of administrators, and do not require these extra resources. If you can
> ^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
> so, money is not a resource at your site? freebsd is an os, _freely
> available_, running on _darn cheap_ hardware. your comparison lacks a
> bit of realism here, at least from the european point of view of the
> software/hardware prices of the vendors mentioned above.
> btw, i'd also like to have some of the stuff you smoke over there ;-)
Lets be realistic here. Corporations don't like unsure things. They spend
money on good hardware and support contracts because they have gaurantees and
somebody to hold accountable. You're going to have an easier time getting them
to be flexible on this point if there are patches for critical releases that
system administrators can use, rather than having to maintain an internal
build infrastructure. ("You want us to replace vendor support contracts and
SLAs with an internal build team that we have to pay for ourselves? Who do we
hold accountable when the internal build breaks and 500 servers go tits up?")
Yes, FreeBSD does run on darn cheap hardware, and it runs well. That being
said, I would never run a large operation on cheap hardware. I will find a
reliable hardware manufacturer with quality parts who doesn't balk when I need
to order 100 spare hotswap scsi drives or RMA 324 dead power supply fans that
came out of a bad production run by tomorrow morning.
Reliability costs money, and the operating system is just a part of that
reliability. To be frank, I don't think most shops spend most of their server
budget on software. Yes, NT licenses cost money. Build engineer salaries cost
money too. I still believe the bulk of IT budgets goes towards purchasing reliable
hardware. I don't recommend that folks use FreeBSD because its free. I recommend
they use it because its one of the most capable systems out there.
> > Nobody expects a new system to replace the current and trustworthy cvsup
> > method. By the same token, nobody expects The Project to support every
> > possible hardware/software configuration out there. On the flip side, FreeBSD
> > is not like NetBSD or Linux in that we don't support 40 architectures, and a
> > few household appliances.
>
> nevertheless, release engineering for RELENG_4_X (X!=5) turned out to be
> pretty perfect for an opensource os, from my point of view.
Nothing is perfect. Ever. It definately went smoothly though.
> > Currently, we have 2 major architectures spanning 3 processors. Intel and
> > AMD processors on the PC, and Alpha. Sparc and IA64 may be considerations in
> > the future. For now, any patches or builds of this nature could very well be
> > limited to 3 supported base architectures. Typically, we have maybe 2 or 3
> > critical releases of this nature per month. That comes to 3 builds three
> > times a month, not a considerable strain, for the benefit of releasing
> > patches that folks will use.
> >
> > I should like to note that this kind of system would be an excellent
> > opportunity for a FreeBSD support company to pick up some slack that perhaps
> > The Project doesn't have the resources to cover. It could potentially be a
> > valuable service for customers and users alike.
>
> i agree partly. from my experience in the freebsd community there are
> quite some folks who _do_ release builds for internal use at their site.
> it would rather be a coordination effort to get one or more publicly
> available update releases available out there, if their employers would
> spend the resources on doing this.
Quite a few shops do have the luxery of being able to maintain and release
internal builds. Quite a few more do not. Either way, its still a good
opportunity for someone who can. =)
> regards,
> /k
-- Benjamin Krueger "Life is far too important a thing ever to talk seriously about." - Oscar Wilde (1854 - 1900) ---------------------------------------------------------------- Send mail w/ subject 'send public key' or query for (0x251A4B18) Fingerprint = A642 F299 C1C1 C828 F186 A851 CFF0 7711 251A 4B18 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
- Next message: Giorgos Keramidas: "Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip"
- Previous message: Karsten W. Rohrbach: "Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip"
- In reply to: Karsten W. Rohrbach: "Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip"
- Next in thread: Nate Williams: "Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip"
- Reply: Nate Williams: "Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
