FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 11-07-2010, 04:17 AM
Philip Amadeo Saeli
 
Default httpd RPM newer than 2.0.63 avail for CentOS 4.x?

I'm maintaining an internet-facing web server which is now running httpd
2.0.63 (httpd-2.0.63-2.el4s1.centos.2) which is now neary 2.5 years
old(!?!). I need to move to either 2.0.64 or 2.2.12 or later. However,
I've been unable to find available RPMs for such releases for CentOS
4.x.

I have to believe that others have these needs also. In light of this,
how do others keep up with security upgrades for the httpd? I'm rather
new to this aspect of things, so am still in the process of sorting
things out in this regard.

Any help would be appreciated.

Thanks!

--Phil

--
Philip Amadeo Saeli
CentOS, RHEL, openSUSE
psaeli@zorodyne.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 11-07-2010, 07:20 AM
RedShift
 
Default httpd RPM newer than 2.0.63 avail for CentOS 4.x?

On 11/07/10 06:17, Philip Amadeo Saeli wrote:
> I'm maintaining an internet-facing web server which is now running httpd
> 2.0.63 (httpd-2.0.63-2.el4s1.centos.2) which is now neary 2.5 years
> old(!?!). I need to move to either 2.0.64 or 2.2.12 or later. However,
> I've been unable to find available RPMs for such releases for CentOS
> 4.x.
>
> I have to believe that others have these needs also. In light of this,
> how do others keep up with security upgrades for the httpd? I'm rather
> new to this aspect of things, so am still in the process of sorting
> things out in this regard.
>
> Any help would be appreciated.
>
> Thanks!
>
> --Phil
>

Upgrade to the latest 5 release.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 11-07-2010, 11:13 AM
Robert Heller
 
Default httpd RPM newer than 2.0.63 avail for CentOS 4.x?

At Sun, 7 Nov 2010 00:17:31 -0500 CentOS mailing list <centos@centos.org> wrote:

>
> I'm maintaining an internet-facing web server which is now running httpd
> 2.0.63 (httpd-2.0.63-2.el4s1.centos.2) which is now neary 2.5 years
> old(!?!). I need to move to either 2.0.64 or 2.2.12 or later. However,
> I've been unable to find available RPMs for such releases for CentOS
> 4.x.
>
> I have to believe that others have these needs also. In light of this,
> how do others keep up with security upgrades for the httpd? I'm rather
> new to this aspect of things, so am still in the process of sorting
> things out in this regard.

Red Hat backports security updates (from newer versions). So long as
you have been applying the standard O/S updates (eg 'yum update')
regularly, your http is up-to-date WRT security updates.

>
> Any help would be appreciated.
>
> Thanks!
>
> --Phil
>

--
Robert Heller -- 978-544-6933 / heller@deepsoft.com
Deepwoods Software -- http://www.deepsoft.com/
() ascii ribbon campaign -- against html e-mail
/ www.asciiribbon.org -- against proprietary attachments



_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 11-07-2010, 11:50 AM
Bob McConnell
 
Default httpd RPM newer than 2.0.63 avail for CentOS 4.x?

RedShift wrote:
> On 11/07/10 06:17, Philip Amadeo Saeli wrote:
>> I'm maintaining an internet-facing web server which is now running httpd
>> 2.0.63 (httpd-2.0.63-2.el4s1.centos.2) which is now neary 2.5 years
>> old(!?!). I need to move to either 2.0.64 or 2.2.12 or later. However,
>> I've been unable to find available RPMs for such releases for CentOS
>> 4.x.
>>
>> I have to believe that others have these needs also. In light of this,
>> how do others keep up with security upgrades for the httpd? I'm rather
>> new to this aspect of things, so am still in the process of sorting
>> things out in this regard.
>>
>> Any help would be appreciated.
>>
>> Thanks!
>>
>> --Phil
>>
>
> Upgrade to the latest 5 release.

It's not that easy to do that much of an upgrade. But since the EOL
announcement for release 3 was posted recently, it definitely needs to
be done. This is how I would proceed.

1. Backup all data and configuration info on that server.
2. Set up a test server with the current release (CentOS 5).
3. Restore all data and configuration info on the test server. Plan on
spending time to rewrite configuration files to match current formats
and settings.
4. Once you finish tweaking the configuration, test all of your
software, web pages, etc.
5. When you are sure everything works, install the current OS on the
production server, restore the data and reconfigure it to match the test
server.
5. Do a complete acceptance test on the production server. (We actually
use a second Internet facing server for acceptance tests before
committing changes to the production server.)
7. Use YUM to update your test server at least once a week.
8. As soon as you finish testing all of the updates each week, use YUM
to install them on the production server. (But don't ever do this on
Friday. If you missed something, you don't want to have to work on the
weekend.)
9. Subscribe to announcements and several security mailing lists to get
advanced warning of any known issues that need to be patched immediately.
10. Start tracking RedHat/CentOS 6 release candidates ASAP.

Officially, by PCI rules we have 30 days after release of an OS update
to get it installed on Internet facing systems. So the auditors will
give us one pass on their monthly validation cycle before they start to
complain. This does give us some time to test for problems and correct
them before updating the production servers. But this requires a test
server that is configured exactly like the production server so we can
make sure the updates won't break any of our applications before we will
install them in production.

We have one developer from each product team, one QA manager, one
Support tech and an IT tech that track these issues and make sure our
servers are up to date. As one of the developers in that group, I
monitor CentOS announcements and two security lists, forwarding relevant
messages to the entire group. There is a similar but larger group
tracking Microsoft updates.

In addition to CentOS and Apache, we also track updates to PHP,
PostgreSQL and a couple dozen supporting packages and maintenance tools.

Bob McConnell
N2SPP
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 11-09-2010, 10:57 PM
Philip Amadeo Saeli
 
Default httpd RPM newer than 2.0.63 avail for CentOS 4.x?

Thank you all for the helpful and informative replies. However, I have
some additional questions (interspersed below).

For some background, the organization I'm doing this for is a
significantly resource constrained, very small company, so I have been
having to take carefully measured steps in upgrading their systems and
bringing them into conformance. In all cases, the systems were set up
by others prior to my time with them.

In particular, it would better, given their constraints, if I could get
their CentOS 4 system up to standards prior to migrating to a CentOS 5
system (which I'd already proposed to them). Even migrating to CentOS 5
doesn't, by itself, solve my problem (see comments below).


* Bob McConnell <rmcconne@lightlink.com> [2010-11-07 07:50:42 -0500]:
>
> 4. Once you finish tweaking the configuration, test all of your
> software, web pages, etc.

> 6. Do a complete acceptance test on the production server. (We actually
> use a second Internet facing server for acceptance tests before
> committing changes to the production server.)

How does one set up a test [web] server which has a number of sites, all
secured via SSL certs which are bound to the domain, and hence the IP
address, of the sites on the server? They do have a developmental
server which uses one, company-issued SSL cert to secure all of the test
sites. However, the Apache config for this is substantially different
than that for the production server.

It appears that I'd have to set up an additional, special testing DNS
space with new IP addressess, or to enter them into the hosts file(s) of
the web client test systems. Also, I would not be able to simply copy
the httpd config file(s) from the production system to the test system
due to having to have different IP addresses for each site. Or is there
some other way to do this? I'm really stumped over this one.

> 7. Use YUM to update your test server at least once a week.
> 8. As soon as you finish testing all of the updates each week, use YUM
> to install them on the production server. (But don't ever do this on
> Friday. If you missed something, you don't want to have to work on the
> weekend.)
> 9. Subscribe to announcements and several security mailing lists to get
> advanced warning of any known issues that need to be patched immediately.
> 10. Start tracking RedHat/CentOS 6 release candidates ASAP.
>
> Officially, by PCI rules we have 30 days after release of an OS update
> to get it installed on Internet facing systems. So the auditors will
> give us one pass on their monthly validation cycle before they start to
> complain. This does give us some time to test for problems and correct
> them before updating the production servers. But this requires a test
> server that is configured exactly like the production server so we can
> make sure the updates won't break any of our applications before we will
> install them in production.
>
> We have one developer from each product team, one QA manager, one
> Support tech and an IT tech that track these issues and make sure our
> servers are up to date. As one of the developers in that group, I
> monitor CentOS announcements and two security lists, forwarding relevant
> messages to the entire group. There is a similar but larger group
> tracking Microsoft updates.
>
> In addition to CentOS and Apache, we also track updates to PHP,
> PostgreSQL and a couple dozen supporting packages and maintenance tools.
>
> Bob McConnell
> N2SPP

Bob, your thoughtful, insightful, informative, and detailed reply is
very helpful. Thanks! My biggest hangup WRT the above is exactly how
to set up a test server that very closely mirrors the production server
without needing to have to maintain significant configuration changes,
esp WRT an SSL-secured web server.


On a related tack:

* Robert Heller <heller@deepsoft.com> [2010-11-07 07:13:27 -0500]:
>
> Red Hat backports security updates (from newer versions). So long as
> you have been applying the standard O/S updates (eg 'yum update')
> regularly, your http is up-to-date WRT security updates.


Even with CentOS 5, the available versions of, especially PHP and MySQL,
are not up-to-date enough feature-wise for the web site code on the
system, so later versions have to be used. The httpd version is not so
critical in this case. How can one cope with this situation, i.e., the
general situation of needing features not supported under a current
version of an OS so the vendor supplied updates are no longer
applicable.

In some cases I've been able to find 3rd party repos which have had the
RPMs I've needed (e.g., rpmforge, dag, epel, remi) but the ones needed
are not always available (as is the case now). I have set up repos and
built my own RPMs in the past, but there is no budget for that in this
case. Also, it is a lot of work, especially for a very few systems.


--Phil
[former N2IWR]

--
Philip Amadeo Saeli
openSUSE, RHEL, CentOS
psaeli@zorodyne.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 11-10-2010, 12:14 AM
Bob McConnell
 
Default httpd RPM newer than 2.0.63 avail for CentOS 4.x?

Philip Amadeo Saeli wrote:
> Thank you all for the helpful and informative replies. However, I have
> some additional questions (interspersed below).
>
> For some background, the organization I'm doing this for is a
> significantly resource constrained, very small company, so I have been
> having to take carefully measured steps in upgrading their systems and
> bringing them into conformance. In all cases, the systems were set up
> by others prior to my time with them.
>
> In particular, it would better, given their constraints, if I could get
> their CentOS 4 system up to standards prior to migrating to a CentOS 5
> system (which I'd already proposed to them). Even migrating to CentOS 5
> doesn't, by itself, solve my problem (see comments below).
>
>
> * Bob McConnell <rmcconne@lightlink.com> [2010-11-07 07:50:42 -0500]:
>> 4. Once you finish tweaking the configuration, test all of your
>> software, web pages, etc.
>
>> 6. Do a complete acceptance test on the production server. (We actually
>> use a second Internet facing server for acceptance tests before
>> committing changes to the production server.)
>
> How does one set up a test [web] server which has a number of sites, all
> secured via SSL certs which are bound to the domain, and hence the IP
> address, of the sites on the server? They do have a developmental
> server which uses one, company-issued SSL cert to secure all of the test
> sites. However, the Apache config for this is substantially different
> than that for the production server.
>
> It appears that I'd have to set up an additional, special testing DNS
> space with new IP addressess, or to enter them into the hosts file(s) of
> the web client test systems. Also, I would not be able to simply copy
> the httpd config file(s) from the production system to the test system
> due to having to have different IP addresses for each site. Or is there
> some other way to do this? I'm really stumped over this one.

It's probably not necessary to use the same certificates, as long as
those you use are the same type and format. When we need to test to that
level, we actually set up our own CA to generate test certificates for
internal use only. We're testing for the functionality, not the specific
certificates. Having said that, most of our in-house testing is done
without SSL. Even servers that are normally part of a VPN are only
tested within a LAN rather than on the VPN. Most of that functionality
comes from third party FLOSS applications, so we are rather confident
that any problems will be fixed before we run across them.

>> 7. Use YUM to update your test server at least once a week.
>> 8. As soon as you finish testing all of the updates each week, use YUM
>> to install them on the production server. (But don't ever do this on
>> Friday. If you missed something, you don't want to have to work on the
>> weekend.)
>> 9. Subscribe to announcements and several security mailing lists to get
>> advanced warning of any known issues that need to be patched immediately.
>> 10. Start tracking RedHat/CentOS 6 release candidates ASAP.
>>
>> Officially, by PCI rules we have 30 days after release of an OS update
>> to get it installed on Internet facing systems. So the auditors will
>> give us one pass on their monthly validation cycle before they start to
>> complain. This does give us some time to test for problems and correct
>> them before updating the production servers. But this requires a test
>> server that is configured exactly like the production server so we can
>> make sure the updates won't break any of our applications before we will
>> install them in production.
>>
>> We have one developer from each product team, one QA manager, one
>> Support tech and an IT tech that track these issues and make sure our
>> servers are up to date. As one of the developers in that group, I
>> monitor CentOS announcements and two security lists, forwarding relevant
>> messages to the entire group. There is a similar but larger group
>> tracking Microsoft updates.
>>
>> In addition to CentOS and Apache, we also track updates to PHP,
>> PostgreSQL and a couple dozen supporting packages and maintenance tools.
>>
>> Bob McConnell
>> N2SPP
>
> Bob, your thoughtful, insightful, informative, and detailed reply is
> very helpful. Thanks! My biggest hangup WRT the above is exactly how
> to set up a test server that very closely mirrors the production server
> without needing to have to maintain significant configuration changes,
> esp WRT an SSL-secured web server.

How close the mirror has to be is a question only you can answer. But
you have to be practical. What are you actually testing? If you have
your own software that is providing SSL and other system level
capabilities, then yes, you need to include them on your test system. If
you are looking at a mix of releases that are not in sync with each
other, yes you may need to test a little more thoroughly. But in most
cases you will likely be using software that is part of the OS
distribution, or what other developers have targeted for that OS. If you
can't trust them and their community to provide you with reliable tools,
why are you using them in the first place?

> On a related tack:
>
> * Robert Heller <heller@deepsoft.com> [2010-11-07 07:13:27 -0500]:
>> Red Hat backports security updates (from newer versions). So long as
>> you have been applying the standard O/S updates (eg 'yum update')
>> regularly, your http is up-to-date WRT security updates.
>
>
> Even with CentOS 5, the available versions of, especially PHP and MySQL,
> are not up-to-date enough feature-wise for the web site code on the
> system, so later versions have to be used. The httpd version is not so
> critical in this case. How can one cope with this situation, i.e., the
> general situation of needing features not supported under a current
> version of an OS so the vendor supplied updates are no longer
> applicable.
>
> In some cases I've been able to find 3rd party repos which have had the
> RPMs I've needed (e.g., rpmforge, dag, epel, remi) but the ones needed
> are not always available (as is the case now). I have set up repos and
> built my own RPMs in the past, but there is no budget for that in this
> case. Also, it is a lot of work, especially for a very few systems.
>
>
> --Phil
> [former N2IWR]
>

Bob McConnell
N2SPP
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 11-12-2010, 07:44 PM
Philip Amadeo Saeli
 
Default httpd RPM newer than 2.0.63 avail for CentOS 4.x?

* Robert Heller <heller@deepsoft.com> [2010-11-07 07:13:27 -0500]:
>
> At Sun, 7 Nov 2010 00:17:31 -0500 CentOS mailing list <centos@centos.org> wrote:
>
> > I'm maintaining an internet-facing web server which is now running httpd
> > 2.0.63 (httpd-2.0.63-2.el4s1.centos.2) which is now neary 2.5 years
> > old(!?!). I need to move to either 2.0.64 or 2.2.12 or later. However,
> > I've been unable to find available RPMs for such releases for CentOS
> > 4.x.
> >
> > I have to believe that others have these needs also. In light of this,
> > how do others keep up with security upgrades for the httpd? I'm rather
> > new to this aspect of things, so am still in the process of sorting
> > things out in this regard.
>
> Red Hat backports security updates (from newer versions). So long as
> you have been applying the standard O/S updates (eg 'yum update')
> regularly, your http is up-to-date WRT security updates.

This is true for vendor-supported version. However, for technical
reasons (i.e., need for additional features or capabilities), we are
running versions more recent than the vendor-supported ones. Up until
recently, I have been able to obtain the needed versions (of, e.g.,
httpd, mysql, and php) from available third-party CentOS repos.
However, this is no longer the case.

My question in this regard is to find out how this problem is generally
handled by others. I know anyone who has internet-facing, secure
servers has to deal with these same issues. Up until now, I've been
able to trust that the community response would result in the needed
RPMs showing up in public repos. That model seems to now be broken (if
indeed it was ever truly viable).

In particular, I need the following package versions (for CentOS 4.x),
none of which I've been able to locate in any publicly available repo:

1. httpd-2.0.64 # released: 2010-10-19
2. php-5.2.14 # released: 2010-07-22

I have been able to locate packages for php-5.3.3 and am in the process
of testing them. However, things would be *much* simpler in the short
term if we could move first to php-5.2.14.

Our longer-range plan is to upgrade the server to CentOS 5, which will
help quite a bit in this regard. However, in the mean time I'm stuck
with CentOS 4 on this server due to severe time, resource, and budget
constraints.

> > Any help would be appreciated.
> >
> > Thanks!
> >
> > --Phil
> >
>
> --
> Robert Heller -- 978-544-6933 / heller@deepsoft.com
> Deepwoods Software -- http://www.deepsoft.com/
> () ascii ribbon campaign -- against html e-mail
> / www.asciiribbon.org -- against proprietary attachments

Any info would be appreciated.

Thanks!

--Phil

--
Philip Amadeo Saeli
openSUSE, RHEL, CentOS
psaeli@zorodyne.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 11-12-2010, 07:57 PM
John Hinton
 
Default httpd RPM newer than 2.0.63 avail for CentOS 4.x?

On 11/12/2010 3:44 PM, Philip Amadeo Saeli wrote:
> * Robert Heller<heller@deepsoft.com> [2010-11-07 07:13:27 -0500]:
>> At Sun, 7 Nov 2010 00:17:31 -0500 CentOS mailing list<centos@centos.org> wrote:
>>
>>> I'm maintaining an internet-facing web server which is now running httpd
>>> 2.0.63 (httpd-2.0.63-2.el4s1.centos.2) which is now neary 2.5 years
>>> old(!?!). I need to move to either 2.0.64 or 2.2.12 or later. However,
>>> I've been unable to find available RPMs for such releases for CentOS
>>> 4.x.
>>>
>>> I have to believe that others have these needs also. In light of this,
>>> how do others keep up with security upgrades for the httpd? I'm rather
>>> new to this aspect of things, so am still in the process of sorting
>>> things out in this regard.
>> Red Hat backports security updates (from newer versions). So long as
>> you have been applying the standard O/S updates (eg 'yum update')
>> regularly, your http is up-to-date WRT security updates.
> This is true for vendor-supported version. However, for technical
> reasons (i.e., need for additional features or capabilities), we are
> running versions more recent than the vendor-supported ones. Up until
> recently, I have been able to obtain the needed versions (of, e.g.,
> httpd, mysql, and php) from available third-party CentOS repos.
> However, this is no longer the case.
>
> My question in this regard is to find out how this problem is generally
> handled by others. I know anyone who has internet-facing, secure
> servers has to deal with these same issues. Up until now, I've been
> able to trust that the community response would result in the needed
> RPMs showing up in public repos. That model seems to now be broken (if
> indeed it was ever truly viable).
>
> In particular, I need the following package versions (for CentOS 4.x),
> none of which I've been able to locate in any publicly available repo:
>
> 1. httpd-2.0.64 # released: 2010-10-19
> 2. php-5.2.14 # released: 2010-07-22
>
> I have been able to locate packages for php-5.3.3 and am in the process
> of testing them. However, things would be *much* simpler in the short
> term if we could move first to php-5.2.14.
>
> Our longer-range plan is to upgrade the server to CentOS 5, which will
> help quite a bit in this regard. However, in the mean time I'm stuck
> with CentOS 4 on this server due to severe time, resource, and budget
> constraints.
Of note, RHEL 6 was released this week, so CentOS 6 will likely be out
maybe around the end of the year. Also, the next version release for
RHEL 5 has an option to move to PHP 5.3. It's coming soon. Your time
restraints might allow you jump two major releases!

As for the PHP upgrades. I don't know if you use SquirrelMail or not,
but on a v5.x test machine, my upgrade to PHP 5.2 broke SquirrelMail. I
didn't bother fixing it. I have recently upgraded that system to PHP 5.3
from EPEL repository and SquirrelMail works again. That's the only thing
I found that was broken... Just beware as it was a surprise to me.

John Hinton
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 07:32 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org