When will "autoinstall.plesk.com" update my old apache on my PLESK-server?

[editor]

When will "autoinstall.plesk.com" update my old apache on my
PLESK-server?
http://autoinstall.plesk.com/versions.inf
http://autoinstall.plesk.com/plesk_7.5.2_fc2.inf

Running here, Plesk 7.5.2 Reloaded Linux has Apache Fedora
in the version 2.0.51-2.9 for HTTP.

Apache Fedora, Version 2.0.53 came on 11th February 2005.
cp. ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.apache.org/dist/httpd/

Apache Fedora, Version 2.0.54 came on 11th April 2005.
cp. ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/ftp.apache.org/dist/httpd/

Today it is the 6th May! What's going on there? What's the matter?
There were a lot of bugs and security-holes with the old
Apache, Version 2.0.51. These bugs and security-holes were
fixed, but "autoupdate.plesk.com" ignores this.

The PLESK-server here is still running this old Apache-Version.
I cannot believe it, that Plesk accept these bugs and security-
holes for more than 2.5 months.

When will "autoinstall.plesk.com" update my old apache on my PLESK-server?

Look here:

Changes with Apache 2.0.53

*) SECURITY: CAN-2004-0942 (cve.mitre.org)
Fix for memory consumption DoS in handling of MIME folded request
headers. [Joe Orton]

*) SECURITY: CAN-2004-0885 (cve.mitre.org)
mod_ssl: Fix a bug which allowed an SSLCipherSuite setting to be
bypassed during an SSL renegotiation. PR 31505.
[Hartmut Keil <Hartmut.Keil adnovum.ch>, Joe Orton]

*) Fix --with-apr=/usr and/or --with-apr-util=/usr. PR 29740.
[Max Bowsher <maxb ukf.net>]

*) mod_proxy: Fix ProxyRemoteMatch directive. PR 33170.
[Rici Lake <rici ricilake.net>]

*) mod_proxy: Respect errors reported by pre_connection hooks.
[Jeff Trawick]

*) --with-module can now take more than one module to be statically
linked: --with-module=<modtype>:<modfile>,<modtype>:<modfile>,...
If the <modtype>-subdirectory doesn't exist it will be created and
populated with a standard Makefile.in. [Erik Abele]

*) Fix the RPM spec file so that an RPM build now works. An RPM
build now requires system installations of APR and APR-util.
Remove some arbitrary moving around of binaries - the RPM now
maps to the ASF build of httpd.
[Graham Leggett]

*) mod_dumpio, an I/O logging/dumping module, added to the
modules/expermimental subdirectory. [Jim Jagielski]

*) mod_auth_ldap: Handle the inconsistent way in which the MS LDAP
library handles special characters. PR 24437. [Jess Holle]

*) Win32 MPM: Correct typo in debugging output. [William Rowe]

*) conf: Remove AddDefaultCharset from the default configuration because
setting a site-wide default does more harm than good. PR 23421.
[Roy Fielding]

*) Add charset to example CGI scripts. [Roy Fielding]

*) mod_ssl: fail quickly if SSL connection is aborted rather than
making many doomed ap_pass_brigade calls. PR 32699. [Joe Orton]

*) Remove compiled-in upper limit on LimitRequestFieldSize.
[Bill Stoddard]

*) Start keeping track of time-taken-to-process-request again for
mod_status if ExtendedStatus is enabled. [Jim Jagielski]

*) mod_proxy: Handle client-aborted connections correctly. PR 32443.
[Janne Hietamäki, Joe Orton]

*) Fix handling of files >2Gb on all platforms (or builds) where
apr_off_t is larger than apr_size_t. PR 28898. [Joe Orton]

*) mod_include: Fix bug which could truncate variable expansions
of N*64 characters by one byte. PR 32985. [Joe Orton]

*) Correct handling of certain bucket types in ap_save_brigade, fixing
possible segfaults in mod_cgi with #include virtual. PR 31247.
[Joe Orton]

*) Allow for the use of --with-module=foo:bar where the ./modules/foo
directory is local only. Assumes, of course, that the required
files are in ./modules/foo, but makes it easier to statically
build/log "external" modules. [Jim Jagielski]

*) Util_ldap: Implemented the util_ldap_cache_getuserdn() API so that
ldap authorization only modules have access to the util_ldap
user cache without having to require ldap authentication as well.
PR 31898. [Jari Ahonen jah progress.com, Brad Nicholes]

*) mod_auth_ldap: Added the directive "Requires ldap-attribute" that
allows the module to only authorize a user if the attribute value
specified matches the value of the user object. PR 31913
[Ryan Morgan <rmorgan pobox.com>]

*) mod_ssl: Fail at startup rather than segfault at runtime if a
client cert is configured with an encrypted private key.
PR 24030. [Joe Orton]

*) apxs: fix handling of -Wc/-Wl and "-o mod_foo.so". PR 31448
[Joe Orton]

*) mod_ldap: Fix format strings to use %APR_PID_T_FMT instead of %d.
[Jeff Trawick]

*) mod_cache: CacheDisable will only disable the URLs it was meant to
disable, not all caching. PR 31128.
[Edward Rudd <eddie omegaware.com>, Paul Querna]

*) mod_cache: Try to correctly follow RFC 2616 13.3 on validating stale
cache responses. [Justin Erenkrantz]

*) mod_rewrite: Handle per-location rules when r->filename is unset.
Previously this would segfault or simply not match as expected,
depending on the platform. [Jeff Trawick]

*) mod_rewrite: Fix 0 bytes write into random memory position.
PR 31036. [André Malo]

*) mod_disk_cache: Do not store aborted content. PR 21492.
[Rüiger Plü <r.pluem t-online.de>]

*) mod_disk_cache: Correctly store cached content type. PR 30278.
[Rüiger Plü <r.pluem t-online.de>]

*) mod_ldap: prevent the possiblity of an infinite loop in the LDAP
statistics display. PR 29216. [Graham Leggett]

*) mod_ldap: fix a bogus error message to tell the user which file
is causing a potential problem with the LDAP shared memory cache.
PR 31431 [Graham Leggett]

*) mod_disk_cache: Do not store hop-by-hop headers. [Justin Erenkrantz]

*) Fix the re-linking issue when purging elements from the LDAP cache
PR 24801. [Jess Holle <jessh ptc.com>]

*) mod_disk_cache: Fix races in saving responses. [Justin Erenkrantz]

*) Fix Expires handling in mod_cache. [Justin Erenkrantz]

*) Alter mod_expires to run at a different filter priority to allow
proper Expires storage by mod_cache. [Justin Erenkrantz]



Changes with Apache 2.0.54

*) mod_cache: Add CacheIgnoreHeaders directive. PR 30399.
[Rüiger Plü <r.pluem t-online.de>]

*) mod_ldap: Added the directive LDAPConnectionTimeout to configure
the ldap socket connection timeout value.
[Brad Nicholes]

*) Correctly export all mod_dav public functions.
[Branko Èibej <brane xbc.nu>]

*) Add a build script to create a solaris package. [Graham Leggett]

*) worker MPM: Fix a problem which could cause httpd processes to
remain active after shutdown. [Jeff Trawick]

*) Unix MPMs: Shut down the server more quickly when child processes are
slow to exit. [Joe Orton, Jeff Trawick]

*) Remove formatting characters from ap_log_error() calls. These
were escaped as fallout from CAN-2003-0020.
[Eric Covener <ecovener gmail.com>]

*) mod_ssl: If SSLUsername is used, set r->user earlier. PR 31418.
[David Reid]

*) htdigest: Fix permissions of created files. PR 33765. [Joe Orton]

*) core_input_filter: Move buckets to a persistent brigade instead of
creating a new brigade. This stop a memory leak when proxying a
Streaming Media Server. PR 33382. [Paul Querna]

*) mod_win32: Ignore both PATH_INFO as well as PATH_TRANSLATED to avoid
hiccups from additional path information passed in non-utf-8 format.
[Richard Donkin <rd9 donkin.org]

 

[editor]

How do you update your apachi?

 

[faris]

There are normally two versions of apache running on a server with Plesk installed.

One version (the one you refer to) is ONLY to run the Plesk control panel. It doesn't get updated unless there is a serious security hole, or a new version of Plesk comes out.

I'm not a security expert, but none of the things you metioned look serious to me, especially when you take into account the fact that a hacker won't get any further in than the login page. And even if they happen to open an account with you, they won't get all that far either.

The other version of apache is for the hosting accounts (the websites hosted on your server). There is more danger here if there are serious security holes. But updating this version of apache is totally up to you. It is your responsibility.

To update it you simply need to use whatever update mechanism is provided with your operating system. On Fedora I think it is yum. I don't run Fedora myself, but assuming it is the same as using yum with the fedora legacy project, then updating apache is as simple as issueing the command:

yum update httpd

Or, to update everything:

yum update

Or, to list the available updates:

yum list updates

This assumes that yum is correctly installed and configred, but I would assume it would be by default.

Faris.

 

[editor]

Thank you for your interesting comment.

 

[jamesyeeoc]

editor,

Keep in mind that Plesk is not responsible for the other software on your Linux server. Plesk will update it's own software and any software they have to tweak to make work with their software.

I don't know of any CP company which takes on that responsibility. Tweaking is one thing, doing things like security fixes is another. The originating company of a software package should be the one to decide how best to 'fix' their software, even if the fix is submitted by the public, then they can release a 'new version' after it's been tested.

Linux is made up of hundreds of Open Source modules. Each person or group which writes a specific module is responsible for their own code, or (in the case of Open Source), if you modify their code, then your modified version becomes 'yours' to maintain.

Plesk's code is not Open Source, and they then maintain their code. They did not write Apache, nor does their softare require the latest version for the hosting end, so it's up to you to decide what to update/upgrade. That's part of being the 'host'. Just remember, no matter what software you use, or if you run under Win or Lin, you the host/hosting company are the ones which knows what will be best for your situation.

In the Windows world, you buy a Windows based PC, then you start adding software (such as Norton AntiVirus, WordPerfect, or whatever). Would you expect Symantec/Norton, or Corel to 'fix' problems or security issues in the Windows OS?

Probably not.

<my 2 cents>

 

[editor]

jamesyeeoc, I totally agree your opinion. But...

Please understand also my situation as a Plesk-Admin. I
stand here in front of a Plesk-Server. On the left side, I
can see a Plesk-Software which urgently needs Apache. On the
right side, I can see Apache which urgently needs the
Plesk-Software. They both have a communication to each other
like housewifes.

For the first and to be gentleman, I cannot do much but to
stand here, stood and stare and to wait until these ladies
are finished with their housewife-talks. These both
softwares are total dependent. They are married and melted.
I cannot come here with an ax and cut the phone-cable,
because I simulate, that I have only to update the frequency
of the phone-line. The same is also with Plesk. Everytime,
if I see that there is an update avaiable for MySQL, Apache,
Linux, PHP, I must always think, that I am perhaps with an
ax anywhere on the Plesk-Server. And I feel unsure to run
around with an ax there, because I don't know if I will
destroy anything of Plesk. This is why I think, that such
extreme updates are very clear the job of Plesk.

If I pull over red socks on Apache and green socks on Plesk,
they both will feel warm. They will still continue to work.
Such things do not have any influence for their own
cooperation to each other. But it will show you a picture of
Apache and Plesk. There is a red color and green color on
this sailing ship. On the top of this sailing-boat, you see
a white light. The lights of this ship are complete. You can
sail worldwide by night. And now you get the info, that
there is an update to do with the lights. But you are not
informed about it, if you will get a better light which
makes you more safe, or if you will short-circuit your ship.
Then the best knowledge about the sailing-law with "First
larboard (red), then starboard (green)" will not help you.
Alike you see, also here it is the job of Plesk that they
either will let me the right one information or they do the
updates by themselves. But not only like theoretical
cybermouth-heros, I want to see facts and action in
practice.

I do not afford much from Plesk. I only need the
communication with Plesk before I will do anything wrong
with my ax on the Plesk-Server. Remember, I am the root. I
am the king of the Empire of this Plesk-Server. And what
does happen with Plesk and SW-Soft? Nobody keeps me
informed. Nobody delivers me actual updates. Nobody delivers
me the latest software. Nobody brings me the latest module.
They are like a mole. I do not know what's going on and
where exactly will be the next hill of this mole coming out
in my garden. And if I go under the earth to check it out
and to get any informations, then I only detect that they
are blind as a bat and they cannot read and write. That's
Plesk.

Apache is out-to-date. Linux is out-to-date. MySQL is
out-to-date. PHP is out-to-date. Perl is out-to-date. What
the heck should I do with all these old out-to-date-
pensioneers? Do they need new hips and I update it with a
plastic surgery? Or will just a little bit massage be
enough? How should I know this? The human root of a
Plesk-Server stands here like an idiot.

You also know the typical example with the questions here in
this forum: "Can I update PHP to PHP5?" and the answer is
"Nooooooo, oh my god, don't do that, Plesk will not run then
anymore. Plesk was written for PHP3". But what's then the
right one solution to come to PHP5, nobody from Plesk or
SW-Soft says that to us.

If I ask Apache, they say: Hmm, you should ask Plesk.
If I ask the Plesk-Reseller, they say: Hmm, we are only
responsible for the hardware, ask Plesk.
If I ask Plesk, they say: Ask SW-Soft.
If I ask SW-Soft, they say: It is your job with Apache. We
only cash money for your out-to-date Plesk-Server, but we
don't get the money from you, we get it from the
Plesk-Reseller. So, ask Plesk-Reseller.
If I go back to the Plesk-Reseler, they say: Hmm, try to ask
in the Plesk-Forum.
If I ask the Webmin of Plesk, he say: We only made this
forum, because you all of idiots of licensees, you can help
yourself to each other.

We paid 19,975 USD for the basis and 6,000 USD extra for the
upgrade to 100 domainnames. Next year, we have to pay
another 6,000 USD only for this one upgrade to 100
domainnames. And Plesk does not allow us to buy the licences
directly from SW-Soft which would be much more unexpensiver.
SW-Soft wants us to go the Plesk-Reseller, because they need
to make profit with all the licences. Calling SW-Soft, they
say that I have to go to the Plesk-Reseller. Calling the
Plesk-Reseller, they say, I can call SW-Soft.

In one of my next article about Plesk, I have a very nice
title here: "Updating Plesk-Server is like a lottery."
Become a winner or a looser, if you have only the wish to be
up-to-date. Nobody knows what will happen. But everybody
knows, that most of the modules and software running onto
Plesk are total out-to-date. Not for some hours or days, the
out-to-dates went for many months. Some things have never
been updated for over 1.5 years. If you use Debian Linux,
then you normally update by this way:

apt-get update
and after it: apt-get

That's all. And the complete machine is up-to-date. But
Plesk running onto Debian Linux and after it to make the
standard-commands with

apt-get update
and after it: apt-get

the complete Plesk-Servers makes: Boommm. You cannot image,
how cracky all the Plesk-Code was after the tests and how
many security-holes there were. And Plesk running onto
Windows? Forget it. So extreme slow. Very similar things are
also with VDECK and CPANEL. It is unbelievable how easy it
is for one simple client with only one domainname to spy out
all the clients running onto a VDECK-server. Hammerhard what
we could find out here with VDECK. And CPANEL? And Webmin?
And, and, and...

The next one thing, what I also do not like. Plesk does not
invest much in the things around up-to-dates, but they
programmed an "open hole for Plesk itself". And this works
so: If someone installed Plesk without having a licence,
then the programmers of SW-Soft are able to manipulate the
"illegal" Plesk-Server. Suddenly, there is a technical
software-problem onto this Plesk-machine. The server begins
then to reboot by itself sometimes. And after a while, it
will frozen again and the root will reboot and reboot it
again and again.

This "top-secret"-feature of Plesk is nice and protect the
honest licensees. But if the programmers of SW-Soft are able
to do this manipulation from outside of a Plesk-Server, this
means also that everybody is able to do that. It is only a
question of time until someone else will find this out. Look
and study the complete code of the Plesk-Software, you will
then also find it. And this is also one of the reason, why I
want always to be up-to-date.

Am I a so bad boy only because I want to be up-to-date?

 

[w3it]

Hi
here is what I have found regarding updates.

I am attempting to upgrade the software to help secure the box. Using YUM it says all updates are current and yet I know they are not. On investigation I found out that Fedora are upgrading only at core 3, so all those of us running core 2 boxes thinking we are running the latest updates, are not! (YUM currently doesnt work anyway for a full update!?)

I have a security report generated against my default server setup and the list is as long as your arm! What would help is to update a lot of the software but being core 2 as standard thats quite a feat to do.

What do you all do? Typing yum update would be great but I really do not want to compile every update as an alternate solution.

Any ideas as to why core 2 is provided and not core 3 so we CAN update?

Thanks
Ian