Apache 2.2 won't install

M

mdudley

I have been informed that I have to legally upgrade from 1.3 to 2 of Apache. The system is a shopping cart server, and cannot be down. When I try to install 2.2.21 I get the following error:

Code: 
===>  apache-2.2.21 conflicts with installed package(s): 
      apache+mod_ssl-1.3.41+2.8.31_2

      They install files into the same place.
      You may want to stop build with Ctrl + C.
===>  Vulnerability check disabled, database not found
===>  License check disabled, port has not defined LICENSE
===>  Found saved configuration for apache-2.2.21
=> httpd-2.2.21.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/apache22.
=> Attempting to fetch [url]http://www.apache.org/dist/httpd/httpd-2.2.21.tar.bz2[/url]
httpd-2.2.21.tar.bz2                          100% of 5200 kB  620 kBps

===>  apache-2.2.21 conflicts with installed package(s): 
      apache+mod_ssl-1.3.41+2.8.31_2

      They will not build together.
      Please remove them first with pkg_delete(1).
*** Error code 1

Stop in /usr/ports/www/apache22.
*** Error code 1

Stop in /usr/ports/www/apache22.

It is saying I have to deinstall 1.3 first!!!!!!!!!! That is absolutely impossible, I cannot bring the system down to install configure and test version 2, which will likely take several days. I have read of several people who have both installed and running concurrently, but using different ports, so I know it must be possible.

How can I install the new version and get it up and running and testing without deinstalling the old version?

Marshall
 
mdudley said:
That is absolutely impossible, I cannot bring the system down to install configure and test version 2, which will likely take several days.
Click to expand...
Which is why, normally, you'd do this on a test system first.

If that system is so important that it can't be brought down, how do you update anything on it? What happens if the hardware suddenly dies? Wouldn't it be wiser to invest in some HA solution? Or at least a standby system?
 
At very least, create a jail (with a new IP) to install it in. Test it there. When ready, deploy it to the "host" (production) environment.

Image or dump(8) your filesystems before making changes, in case you need to roll back.

And I agree with SirDice's sentiments: something sounds off about your SLA. You need a test environment and redundancy in your production environment, or your customers will need to really adjust expectations.
 
I have a backup system, but it can't be a simple drop in, as multiple sales are made every minute, and by the time the backup is brought up to date, the information is already old. As far as failures are concerned, the drives are on raid, so if one fails it is simply replaced, and if hardware fails, it is swapped out but keeping the old drives. There is also a full operating backup system, but obviously it cannot be completely kept up to date with continuous sales coming in, so a complete swap out is a last resort.

Bringing up apache on a different ip (or port) is no problem and that is what I planned to do, to get it all working, before switching it over to version 2.

I don't understand why it says that it cannot install, from what I can tell it installs in the apache2 directory, and the 1.3 installs in the apache directory, so why should there be a problem? I know it can be done, I have read of others who have both running concurrently.

If I deinstall the running copy before installing the new one, the system will be down for hours at a minimum.

Marshall
 
I may be wrong, but won't deinstalling it leave it still running in memory? From what I remember, things will still be running unless the service stops. Then you will have a problem. Of course, this leaves you in an even more dangerous situation. You could also make the old one as a package so if things go really wrong, you could pkg_add it and have minimal downtime.
 
I have the httpd and apachectl copied to their own directories, so I don't think deinstalling them would keep me from bringing them back up again anyway, since those copies would still exist. I also have backed up the conf directory of apache directory, but since apache 2 uses apache2 for its directory, I do not expect it to be impacted either. I have no problem deinstalling the 1.3, as long as I am certain that I can still run it from the executables I have copied over.

Marshall
 
mdudley said:
I have a backup system, but it can't be a simple drop in, as multiple sales are made every minute, and by the time the backup is brought up to date, the information is already old.
Click to expand...

How can you expect to perform any upgrade, then? You will need to have a system running in parallel (i.e. within a Jail, if you'd like) that receives the same sales updates (DB replication?) that you can cutover to at a specified time. Or you're going to need to plan a service outage.

mdudley said:
As far as failures are concerned, the drives are on raid, so if one fails it is simply replaced, and if hardware fails, it is swapped out but keeping the old drives.
Click to expand...

That's fine. Hard drive failures are common. What about a system board failure? Just had one of those myself a few weeks ago.

mdudley said:
I don't understand why it says that it cannot install, from what I can tell it installs in the apache2 directory, and the 1.3 installs in the apache directory, so why should there be a problem?
Click to expand...

The installed files for the www/apache22 port (%pkg_info -Lx apache-2.2) shows a list of binaries in /usr/local/sbin. My guess is that's the reason for the conflict.
 
Once the new apache is tested, it only takes a second to stop the old one and after changing the ip or ports on the new one, starting it. Downtime should be lees than a minute. Since the db is being handled by perl programs, they will simply continue using the same data as before.

System board is part of the backup system, as is power supply and so forth. If the system board goes out, I put in the backup system, and swap the hard drives so no data is stale from when it went out.

I have already moved those files out of that directory and they execute from a different directory. I guess I will simply have to deinstall 1.3 and install the new version, and depend on the moved executables if there is a problem.

Marshall
 
I have compiled version 2.2 and it passes the config test. I changed the port from 80 to 8000 for testing. However I cannot find where to change the ssl port from 443. I have to test on a different port from the 1.3 I am currently running so they don't conflict. It also said that I cannot start it with the startssl option, so I am assuming I no longer need to tell it to use ssl.

Marshall
 
I seem to have the non-secure portion of the 2.2 working, but when I try to access the secure site I get the following:

Code: 
Unable to connect

Firefox can't establish a connection to the server at http://www.king-cart.com:8443.

I have the same virtual code for the ssl that version 1.3 had, except I am using port 8443 instead of 443, and it does not complain when I test the config file.

Any ideas why the secure host is not listening? I get the same error regardless of if I use http or https.

Marshall
 
Be sure to backup all apache conf files first.

Code: 
cd /usr/ports/www/apache22
make config
[I]Make sure the SSL module is enabled! mod_SSL = YES[/I]
[I]Select other modules you need/like to include[/I]
make deinstall
make reinstall clean

After this, you can remove the previous Apache webserver.
 
mdudley said:
There is also a full operating backup system, but obviously it cannot be completely kept up to date with continuous sales coming in, so a complete swap out is a last resort.
Click to expand...

There may be some clustering solution for your database or HAST may come handy. Throw in CARP and you will have failover cluster. There was some examples on FreeBSD Wiki.

In case you are absolutely sure, that you can install apache22 besides your currently running apache, you can comment out CONFLICTS line in /usr/ports/www/apache22/Makefile, but I wouldn't even consider such messing with things.

In case you don't know for sure, that something will work, prepare testing enviroment and try to destroy things there first. For your scenario, I would consider to:

  1. Replicate live system to testing system
  2. Setup additional testing system as part of cluster with your replica
  3. Setup new apache enviroment in second system
  4. Try to handover from old apache to new apache in testing cluster (under simulated load from "customers")
  5. If it works, try it several more times
  6. If it still works, repeat on running system
  7. Update old system in cluster to new one and you will end with failover cluster running new apache -> profit :)
 
Thanks all. I got it all working. The problem with the secure host was I had the code for it in the main httpd.conf file, instead of the separate file in the extras directory. Once I moved it over it started working.

Marshall
 
You must log in or register to reply here.
Back
Top