Shallow Thoughts : tags : apache

A Tricky Website Bug After Upgrading

Someone contacted me because my Galilean Moons of Jupiter page stopped working.

We've been upgrading the web server to the latest Debian, Bookworm (we were actually two revs back, on Buster, rather than on Bullseye, due to excessive laziness) and there have been several glitches that I had to fix, particularly with the apache2 configuration. But Galilean? That's just a bunch of JavaScript, no server-side involvement like Flask or PHP or CGI.

Read more ...

Tags: web, javascript, apache
[ 13:53 Jun 22, 2023    More linux | permalink to this entry | ]

I'm Glad I Don't Run Wordpress

Last week I spent some time monitoring my apache error logs to try to get rid of warnings from my website and see if there are any errors I need to fix. (Answer: yes, there were a few things I needed to fix, mostly due to changes in libraries since I wrote the pages in question.)

The vast majority of lines in my error log, however, are requests for /wp-login.php or /xmlrpc.php. There are so many of them that they drown out any actual errors on the website.

Read more ...

Tags: web, apache
[ 10:28 Apr 13, 2023    More tech/web | permalink to this entry | ]

Re-enabling PHP when a Debian system upgrade disables it

I updated my Debian Testing system via apt-get upgrade, as one does during the normal course of running a Debian system. The next time I went to a locally hosted website, I discovered PHP didn't work. One of my websites gave an error, due to a directive in .htaccess; another one presented pages that were full of PHP code interspersed with the HTML of the page. Ick!

In theory, Debian updates aren't supposed to change configuration files without asking first, but in practice, silent and unexpected Apache bustage is fairly common. But for this one, I couldn't find anything in a web search, so maybe this will help.

The problem turned out to be that /etc/apache2/mods-available/ includes four files:

$ ls /etc/apache2/mods-available/*php*
/etc/apache2/mods-available/php7.0.conf
/etc/apache2/mods-available/php7.0.load
/etc/apache2/mods-available/php7.2.conf
/etc/apache2/mods-available/php7.2.load

The appropriate files are supposed to be linked from there into /etc/apache2/mods-enabled. Presumably, I previously had a link to ../mods-available/php7.0.* (or perhaps 7.1?); the upgrade to PHP 7.2 must have removed that existing link without replacing it with a link to the new ../mods-available/php7.2.*.

The solution is to restore those links, either with ln -s or with the approved apache2 commands (as root, of course):

# a2enmod php7.2
# systemctl restart apache2

Whew! Easy fix, but it took a while to realize what was broken, and would have been nice if it didn't break in the first place. Why is the link version-specific anyway? Why isn't there a file called /etc/apache2/mods-available/php.* for the latest version? Does PHP really change enough between minor releases to break websites? Doesn't it break a website more to disable PHP entirely than to swap in a newer version of it?

Tags: linux, debian, apache, web
[ 10:31 Mar 01, 2018    More linux | permalink to this entry | ]

Adventures with Virtual hosts and CGI on Apache 2.2

We had a server that was still running Debian Etch -- for which Debian just dropped support. We would have upgraded that machine to Lenny long ago except for one impediment: upgrading the live web server from apache 1 to apache 2.2.

Installing etch's apache 2.2.3 package and getting the website running under it was no problem. Debian has vastly improved their apache2 setup from years past -- for instance, installing PHP also enables it now, so you don't need to track down all the places it needs to be turned on.

But when we upgraded to Lenny and its apache 2.2.9, things broke. Getting it working again was tricky because most of the documentation is standard Apache documentation, not based on Debian's more complex setup. Here are the solutions we found.

Enabling virtual hosts

As soon as the new apache 2.2.9 was running, we lost all our websites, because the virtual hosts that had worked fine on Etch broke under Lenny's 2.2.9. Plus, every restart complained [warn] NameVirtualHost *:80 has no VirtualHosts.

All the web documentation said that we had to change the <VirtualHost *> lines to <VirtualHost *:80>. But that didn't help. Most documentation also said we would also need the line: NameVirtualHost *:80 Usually people seemed to find it worked best to put that in a newly created file called conf.d/virtualhosts. Our Lenny upgrade had already created that line and put it in ports.conf, but it didn't work either there or in conf.d/virtualhosts.

It turned out the key was to remove the NameVirtualHost *:80 line from ports.conf, and add it in sites-available/default. Removing it from ports was the important step: if it was in ports.conf at all, then it didn't matter if it was also in the default virtual host.

Enabling CGI scripts

Another problem to track down: CGI scripts had stopped working. I knew about Options +ExecCGI, but adding it wasn't helping. Turned out it also needed an AddHandler, which I don't remember having to add in recent versions on Ubuntu. I added this in the relevant virtual host file in sites-available:

  <Directory />
    AddHandler cgi-script .cgi
    Options ExecCGI
  </Directory>

Enabling .htaccess

We have one enduring mystery: .htaccess files work without needing a line like AllowOverride FileInfo anywhere. I've needed to add that directive in Ubuntu-based apache2 installations, but Lenny seems to allow .htaccess without any override for it. I'm still not sure why it works. It's not supposed to. But hey, without a few mysteries, computers would be boring, right?

Tags: web, apache, debian
[ 21:46 Jul 05, 2010    More tech/web | permalink to this entry | ]

Enabling CGI and PHP on Apache2

Every time I do a system upgrade on my desktop machine, I end up with a web server that can't do PHP or CGI, and I have to figure out all over again how to enable all the important stuff. It's all buried in various nonobvious places. Following Cory Doctorow's "My blog, my outboard brain" philosophy, I shall record here the steps I needed this time, so next time I can just look them up:

1. Install apache2.
2. Install an appropriate mod-php package (or, alternately, a full fledged PHP package).
3. Edit /etc/apache2/sites-enabled/000-default, find the stanza corresponding to the default site, and change AllowOverride from None to something more permissive. This controls what's allowed through .htaccess files. For testing, use All; for a real environment you'll probably want something more fine grained than that.
4. While you're there, look for the Options line in the same stanza and add +ExecCGI to the end.
5. Edit /etc/apache2/apache2.conf and search for PHP. No, not the line that already includes index.php; keep going to the lines that look something like

   #AddType application/x-httpd-php .php
   #AddType application/x-httpd-php-source .phps
   

   Uncomment these. Now PHP should work. The next step is to enable CGI.
6. Still in /etc/apache2/apache2.conf, search for CGI. Eventually you'll get to

   # To use CGI scripts outside /cgi-bin/:
   #
   #AddHandler cgi-script .cgi
   

   Uncomment the AddHandler line.
7. Finally, disable automatic start of apache at boot time (I don't need a web server running on my workstation every day, only on days when I'm actually doing web development). I think some upcoming Ubuntu release may offer a way to do that through Upstart, but for now, I

   mv /etc/init.d/apache /etc/noinit.d
   

   (having previously created /etc/noinit.d for that purpose).

Tags: tech, web, apache
[ 18:54 Mar 24, 2007    More tech/web | permalink to this entry | ]