Updating Apache 2.4.25 to latest

After updating freebsd from 10.2 to 10.4 and the openssl, perl and all dependencies to the latest, and spending 3 weeks finding and fixing all the incompatibilities and problems that arose from that upgrade, I am really gun shy about updating Apache from 2.4.25 to the latest 2.4.33. But I am being required to do so to maintain PCI compliance.

I assume that upgrading using
Code:
portmaster -dwv apache.24

will be better than using the ports tree method.

I have upgraded before from major version to major version, and allowed both to be on the system at the same time, letting the old one keep operating while I tested the newly installed one using a non-standard port. But it appears that since this is a minor version change, the old one will be overwritten by the new one.

If I upgrade, will all the configuration files be wiped out? Should I copy the configuration files, and the subdirectories such as "extra" over to a backup directory, then copy them back after upgrading?

Is there any way to keep the old stuff in case there is a major problem, I can restore the original apache until I can figure it out?

Are there any tips, pitfalls, warnings and so forth I should be made aware of? When I search the web I find lots of articles on installing apache, but almost nothing on updating it.

Thanks,

Marshall
 
I suggest you simply use pkg upgrade and be done in 10 minutes.

If I upgrade, will all the configuration files be wiped out?
No, modified configuration files are never removed and never overwritten.

Should I copy the configuration files, and the subdirectories such as "extra" over to a backup directory, then copy them back after upgrading?
It's always a good idea to make backups of course, just in case.

Is there any way to keep the old stuff in case there is a major problem, I can restore the original apache until I can figure it out?
This is just a minor update so you can expect zero problems. Stop the service, update, start the service. It's not going be any more than that.
 
I suggest you simply use pkg upgrade and be done in 10 minutes.

Thanks. I assume the reason for this suggestion is that since it is importing a precompiled package, it not only saves time, but avoids the pitfalls of the compile failing for whatever reason. The first time I ever used pkg, after 20 years of compiling was yesterday, so I am just now starting to become comfortable with it.

This is just a minor update so you can expect zero problems. Stop the service, update, start the service. It's not going be any more than that.

I am not sure why you feel that stopping the service first is required. I have never done this. The service is loaded and running in memory, and should continue fine even if the original program is deleted from memory. I always update, then restart the service to load the new code. Is there any reason this should not be done? I don't want the server out of service any longer than absolutely necessary.

Thanks,

Marshall
 
The first time I ever used pkg, after 20 years of compiling was yesterday, so I am just now starting to become comfortable with it.
Keep well in mind that it is bad practice to mix ports and pre-compiled packages, especially if you customized some of the ports you build.

If you wish to switch from building your own ports to using precompiled packages then the best thing to do is replace them all at once. Something like # pkg upgrade -f. See also pkg-upgrade(8).
 
I am not sure why you feel that stopping the service first is required. I have never done this. The service is loaded and running in memory, and should continue fine even if the original program is deleted from memory. I always update, then restart the service to load the new code. Is there any reason this should not be done? I don't want the server out of service any longer than absolutely necessary.
To be honest I usually just upgrade/update and then restart too. But it's generally "safer" to stop the service(s), update and start it again.
 
I just did the upgrade. It ended with the following message:
Code:
mod_http2 on FreeBSD with OpenSSL from base results in a mostly
functionally unusable mmodule due to lack of "Upgrade" capability
in OpenSSL 1.0.1

When I go to

Code:
http://www.webconfs.com/http-header-check.php

and check the site, it says:

Code:
Date => Mon, 16 Jul 2018 16:06:06 GMT
Server => Apache/2.4.25 (FreeBSD) OpenSSL/1.0.2o
Location => http://www.king-cart.com/
Content-Length => 233
Connection => close
Content-Type => text/html; charset=iso-8859-1

but when I do a version check:

Code:
openssl version
OpenSSL 1.0.1u-freebsd  22 Sep 2016

I tracked down that the old version was in /usr/bin and the new one in /usr/local/bin so I just copied the new version over the
old one in the /usr/bin directory. It now says it is the new one when I do inquire on the command line.

I am afraid to do an apache restart until I can determine what this means, if what I did is what was needed, or if it is going to
bomb if I do a restart.

Thanks,

Marshall[/code]
 
I tracked down that the old version was in /usr/bin and the new one in /usr/local/bin so I just copied the new version over the old one in the /usr/bin directory.
That is a very dumb thing to do because this can potentially break your system. I strongly suggest to reverse the damage you did. Don't forget that the base system is an autonomous system, some of its own services and programs rely on the included OpenSSL version. Not to mention the inconsistency you now created between /usr/bin/openssl and the libraries it normally uses.

I don't know for sure but I wouldn't be surprised if this would also negatively affect future upgrades.

"When in Rome do as the Romans do..."

If you wish to use OpenSSL from the ports collection then simply install it and point whatever 3rd party software you're using to /usr/local, simple as that. If you also install your software using the ports collection then make sure to point that to the OpenSSL port as well using /etc/make.conf. By setting DEFAULT_VERSIONS, basically 'ssl=openssl'.

But don't do this stuff, because this is bound to break several things.

If you want to change your base system then rebuild it from source and customize it using /etc/src.conf. That's the only way to do this without breaking things. Well... If you customize too much then you may still break things, but that's a different story.

What is it you're trying to do achieve anyway? I don't quite understand, if you wish to use SSL with Apache then simply enable the default mod_ssl, you don't need anything extra for that.
 
I am simply trying to update Apache to the latest. I don't know how to point the things using openssl to the /usr/local/bin directory. As far as I can tell these programs, perl, apache, and pkg look whereever they look and are not configurable. I already did do the update, several weeks ago, but it only updated the one in the local/bin directory, but pkg is looking at the bin directory. The make.conf already has the ssl-openssl in it.

I am not trying to customize at all. I think the one in /usr/bin is because years ago that is where it was located by default, and at some point when I would update it started being put in the local/bin, and the updates would not do anything. I was forced to copy it over to the /usr/bin for it to take effect. It seems that by default the problem is that openssl is put one place when you install it, but programs such as perl or apache look for it in another place.

Since it appears that the one is the bin directory should not be there, I just deleted it. Testing it appears everything is still working.

I will go ahead and restart apache, and hope the new version will work properly.

Update: I just did a restart, and it all seems to be working fine, and it is showing the latest version of apache now.

Marshall
 
I don't know how to point the things using openssl to the /usr/local/bin directory. As far as I can tell these programs, perl, apache, and pkg look whereever they look and are not configurable.
They are, but it depends on a few aspects; one of which is the method of installing them.

If you rely on the Ports collection, so building things manually yourself (which you hinted at in your OP (the 'Portmaster comment')) then you can customize quite a bit using both the config build target on a port (go into the port directory, run make config and (de)select whatever you need) or by adding properties to /etc/make.conf (see also make.conf(5) and ports(7)).

The other option of installing is using binary ('precompiled') packages, which SirDice suggested. However, if you do you need to keep in mind that this software is build against default settings. And a default setting for a port is to build itself against the OpenSSL libraries in the base system.

Note that I said: libraries, not executables. Stuff such as libssl.so.9 or libcrypto.so.9, that's what actually will be used by Apache and other programs.

So just replacing an openssl executable within the base system is simply a bad thing to do, because it doesn't change anything for your installed software. Not where the actual libraries are concerned:
Code:
peter@zefiris:/home/peter $ ldd /usr/bin/openssl
/usr/bin/openssl:
        libssl.so.8 => /usr/lib/libssl.so.8 (0x8008a3000)
        libcrypto.so.8 => /lib/libcrypto.so.8 (0x800c00000)
        libc.so.7 => /lib/libc.so.7 (0x80106f000)
peter@zefiris:/home/peter $ ldd /usr/local/bin/openssl
/usr/local/bin/openssl:
        libssl.so.9 => /usr/local/lib/libssl.so.9 (0x8008a4000)
        libcrypto.so.9 => /usr/local/lib/libcrypto.so.9 (0x800c00000)
        libthr.so.3 => /lib/libthr.so.3 (0x801080000)
        libc.so.7 => /lib/libc.so.7 (0x8012a8000)

I already did do the update, several weeks ago, but it only updated the one in the local/bin directory, but pkg is looking at the bin directory. The make.conf already has the ssl-openssl in it.
So you are installing software using the ports collection. This is why I mentioned earlier that you should be careful not to mix binary packages with ports.

I am not trying to customize at all.
Yet you are, you just said so yourself with your comments regarding /etc/make.conf. Anyway, if you have the default version for SSL set to openssl then that is yet another reason not to touch /usr/bin/openssl.

By default the ports collection uses SSL from the base system.

I think the one in /usr/bin is because years ago that is where it was located by default, and at some point when I would update it started being put in the local/bin, and the updates would not do anything.
Pardon me being a bit direct but I think that you have no idea what you're doing and how FreeBSD actually works. I mention this because you previously mentioned PCI compliancy and at the risk of sounding harsh but this is definitely not the way to achieve that.

So, going back to your comment about a version check... Sure, if you just run openssl you may end up firing up the version from the base system. So what's the problem? The only reason this is happening is because of your search path, /usr/bin is usually mentioned before /usr/local/bin. Yet that doesn't automatically imply that the ports are also using it.

Something you can easily check yourself using ldd (see my examples above).

I was forced to copy it over to the /usr/bin for it to take effect.
No you weren't. You may think you were because you apparently don't understand how the search path works nor do you grasp the concept of binaries which get compiled against libraries. But that doesn't make it true. This was an unnecessary action and one that effecitvely breaks your system. No more, no less:

Code:
peter@zefiris:/home/peter $ pkg info -lx apache24 | grep mod_ssl
        /usr/local/include/apache24/mod_ssl.h
        /usr/local/include/apache24/mod_ssl_openssl.h
        /usr/local/libexec/apache24/mod_ssl.so
peter@zefiris:/home/peter $ ldd /usr/local/libexec/apache24/mod_ssl.so
/usr/local/libexec/apache24/mod_ssl.so:
        libssl.so.9 => /usr/local/lib/libssl.so.9 (0x801238000)
        libcrypto.so.9 => /usr/local/lib/libcrypto.so.9 (0x801600000)
        libcrypt.so.5 => /lib/libcrypt.so.5 (0x801a80000)
        libthr.so.3 => /lib/libthr.so.3 (0x801c9f000)
        libc.so.7 => /lib/libc.so.7 (0x800823000)
My server also uses the OpenSSL port because it allows me to upgrade OpenSSL whenever I need to without having to rely on the next FreeBSD release. That's how you check for it to be in effect; notice how the ssl and crypto libraries pointing to /usr/local/lib...

Anyway, my comment still stands. You should definitely undo the damage you did. Not just because you basically broke your system but also because of the potential impact this has on your PCI compliancy. There are also restrictions and regulations set up which apply to the underlying operating system. And if you start meddling in said operating system, up to a point where you perform destructive operations then this definitely has its impact on security as such also on your PCI compliancy.
 
Ok, I think I am beginning to understand. Everything is back to original. I have checked and it seems that two versions of openssl are installed. I am assuming that this is because freebsd keeps both the base version, and the new ports version.

Code:
root@king-cart:/usr/bin # pkg info -lx apache24 | grep mod_ssl
        /usr/local/include/apache24/mod_ssl.h
        /usr/local/include/apache24/mod_ssl_openssl.h
        /usr/local/libexec/apache24/mod_ssl.so
        /usr/local/share/doc/apache24/mod/mod_ssl.html
        /usr/local/share/doc/apache24/mod/mod_ssl.html.en
        /usr/local/share/doc/apache24/mod/mod_ssl.html.fr
root@king-cart:/usr/bin # ldd /usr/local/libexec/apache24/mod_ssl.so
/usr/local/libexec/apache24/mod_ssl.so:
        libssl.so.7 => /usr/lib/libssl.so.7 (0x801636000)
        libcrypto.so.7 => /lib/libcrypto.so.7 (0x8018a2000)
        libcrypt.so.5 => /lib/libcrypt.so.5 (0x801c9a000)
        libthr.so.3 => /lib/libthr.so.3 (0x801eb7000)
        libc.so.7 => /lib/libc.so.7 (0x800822000)
root@king-cart:/usr/bin # ls -l /usr/lib/libssl.so.7
-r--r--r--  1 root  wheel  443488 Jun 19 12:14 /usr/lib/libssl.so.7
root@king-cart:/usr/bin # ls -l /usr/local/lib/libssl.so.9
-r-xr-xr-x  1 root  wheel  481080 Jun 19 20:26 /usr/local/lib/libssl.so.9
root@king-cart:/etc # pkg info -ox "openssl|libressl"
openssl-1.0.2o_4,1             security/openssl


As you can see apache is asking for the old version, although I have the new version installed. From what I have researched this means that the pkg version of apache was precompiled using the old version, instead of the new one.

So I have two questions.


1. Why is the latest version of apache pkg compiled for the old version instead of the new version?
Is this because it was compiled using the base version? Is there any way to override it so it uses the new port version?

And most important, what do I need to do to?

One last question. What does this added to the /etc/make.conf do?

Code:
DEFAULT_VERSIONS+=ssl=openssl

I have it in there, because everyone says it is needed, but want to understand exactly what it is doing. From what I have researched it means to use the new ports version instead of the old base version. But apache is using the old base version despite that being in there.

Thanks,

Marshall
 
Ok, I think I am beginning to understand. Everything is back to original. I have checked and it seems that two versions of openssl are installed. I am assuming that this is because freebsd keeps both the base version, and the new ports version.
That is fully correct.

Consider the base system as an autonomous OS. It contains its own tools and services (tools like ls, cat and awk, services such as SSH, Sendmail and also crypto support through OpenSSL).

Everything you want to add basically gets installed "on top". So yeah, you'd end up with 2 OpenSSL installations, but by tuning /etc/make.conf you're also instructing your system to use one specific version from these two. In our case that would be the ports collection.

This is how FreeBSD handles most things. Offtopic example (I'll be brief): Support for another MTA (mailserver). By default FreeBSD provides Sendmail (see /etc/mail) so what if you want to use Postfix? Then you simply install Postfix (mail/postfix), disable Sendmail and point your system to the new MTA through /etc/mail/mailer.conf.

And the same applies to environments such as SSH, Heimdal (crypto) and OpenSSL.

As you can see apache is asking for the old version, although I have the new version installed. From what I have researched this means that the pkg version of apache was precompiled using the old version, instead of the new one.
Correct.

If you installed Apache using the pre-compiled packages ( pkg install apache24) then it will be build against default settings. Meaning: OpenSSL support through the base system. If you wish to overrule this then you'd have to build Apache yourself using the Ports collection, while also specifying that you wish to build against the OpenSSL port.

1. Why is the latest version of apache pkg compiled for the old version instead of the new version? Is this because it was compiled using the base version? Is there any way to override it so it uses the new port version?
It depends on how you installed Apache. If you used the pre-compiled version then the answer would be "because ports use the SSL version in the base system by default".

However, building the port yourself can overrule this. Basically:

Code:
$ grep ssl /etc/make.conf
DEFAULT_VERSIONS+=apache=2.4 bdb=5 perl5=5.26 pgsql=9.5 python=2.7 python2=2.7 samba=4.6 php=5.6 ruby=2.4 ssl=openssl
This would tell the system that it should use the OpenSSL port (and use specific versions of several ports, but that's besides the point).

And most important, what do I need to do to?
I was under the impression that you installed Apache using the ports collection. And if you have the settings you mentioned in /etc/make.conf then things should already be sorted out.

If not then you should probably rebuild / re-install Apache.

Code:
# cd /usr/ports/www/apache24
# make config
# make deinstall install clean
... something like this. Use of make config is optional.

One last question. What does this added to the /etc/make.conf do?

Code:
DEFAULT_VERSIONS+=ssl=openssl
I already explained this above. Basically this points the system to a specific Ports version which you want to use. You'll find more details in /usr/ports/Mk/bds.default-versions.mk, it can be a difficult read but it basically shows you which ports are considered to be default versions.

In the case of ssl it basically allows you to specify what you want to use. OpenSSL in the base or the ports collection, or not OpenSSL at all but LibreSSL.
 
Thanks. No, I actually used pkg. which was recommended by someone previously in this message. I will rebuild using ports. Everything else has been built from ports using make, or portmaster.

If I do the "make deinstall install", like you show above will this delete the old configuration, like the httpd.conf file and so forth, and replace with the default?

I was thinking that if I use portmaster to upgrade it, it would maintain all the old configuration information, or is that wishful thinking.

Thanks,

Marshall
 
Thanks. No, I actually used pkg. which was recommended by someone previously in this message. I will rebuild using ports. Everything else has been built from ports using make, or portmaster.
Maybe useful to know: FreeBSD 11.2 provides the latest OpenSSL with the base as well:

Code:
peter@zefiris:/home/peter $ /usr/bin/openssl version
OpenSSL 1.0.2o-freebsd  27 Mar 2018
peter@zefiris:/home/peter $ /usr/local/bin/openssl version
OpenSSL 1.0.2o  27 Mar 2018
peter@zefiris:/home/peter $ freebsd-version
11.2-RELEASE
So if you want to get rid of port building then this could be something to consider: upgrading to 11.2, reinstalling all your software through the repository ( # pkg upgrade -f) and then you're pretty much done where the SSL version is concerned.

Although more hassle for now it could make things much easier on you in the future when you have to maintain this server (installing binary packages is usually less work than building ports all the time).

If I do the "make deinstall install", like you show above will this delete the old configuration, like the httpd.conf file and so forth, and replace with the default?
No, FreeBSD ports never handle configuration files, simply because the package doesn't provide them. At best you'll get some sample config files but never the real thing. As a result you never have to worry that a port will somehow disrupt that.

I was thinking that if I use portmaster to upgrade it, it would maintain all the old configuration information, or is that wishful thinking.
That's right on the spot.
 
Thanks. When I did a reinstallation of Apache it complained that the automake was out of date and needed to be updated. When I tried to update it it gave an error:

Code:
automake-1.16.1 conflicts with automake-wrapper-20131203 
> > (installs files into the same place).  Problematic file: 
> > /usr/local/bin/aclocal

After researching, many of the suggested fixes did not work, since there was no devel/automake-wrapper in the ports directory, it was impossible to delete using ports. I finally was able to get rid of it with a pkg delete, which did work. Apache is now installed and working with the correct openssl.

Thanks,

Marshall
 
A few comments to this somehow strange thread:

1.
The apache24 makefile says something like:
# Note: OpenSSL version (base/ports) depends how devel/apr1 was built
So, there is probably not much point in hacking the system after the fact.

2.
Do we need HTTP2 right now?

I just reinstalled my apache24 today, disregarding to read any messages, and now worried about the warning mentioned above. Now, from what I understand, this does only concern HTTP2, which is (as I just learned) a new protocol published about two years ago. The main benefit seems to be improved network speed (obviousely only if the client also supports it, and I currently don't know how widespread that may be the case).

3.
I am really gun shy about updating Apache from 2.4.25 to the latest 2.4.33. But I am being required to do so to maintain PCI compliance.
[...]

If I upgrade, will all the configuration files be wiped out? Should I copy the configuration files, and the subdirectories such as "extra" over to a backup directory, then copy them back after upgrading?

Are You indeed saying that You do run a system that not only is relied on by other people, but even carries sensitive personal data from other people, and do NOT have a professional backup solution in place (where any lost config file can be restored/compared in almost zero time)?

4.
No, modified configuration files are never removed and never overwritten.

This has become true now for very many ports (including apache24) - but I would never rely on it. It is definitely not yet true for openoffice (printer config), and probably some more things.
 
Back
Top