Discussion:
Running Apache On Ubuntu 22
(too old to reply)
Java Jive
2024-12-03 22:54:39 UTC
Permalink
In previous versions of Ubuntu, I had the following working arrangement
for defining localhost subdomains as follows ...


/etc/hosts:

127.0.0.1 localhost
127.0.0.2 local.localhost
127.0.0.3 publish.localhost


Note: In what follows, the files given below are links to files actually
in the sister directory sites-available, as per Apache standard
practice. Further, I've removed all the comments and blank lines to
save space.


/etc/apache2/sites-enabled/001-localhost.conf

<Directory "/home/www">
AllowOverride All
Require all granted
</Directory>


/etc/apache2/sites-enabled/002-local.conf

<VirtualHost 127.0.0.2>
ServerName local.localhost
DocumentRoot "/home/www/Local"
<Directory "/home/www/Local">
Options +Includes +Indexes +FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
<Directory "/home/www/Local/cgi-bin">
Options +ExecCGI
</Directory>
<Directory "/home/www/Local/Resources/Includes">
Options +ExecCGI
</Directory>
</VirtualHost>


/etc/apache2/sites-enabled/003-publish.conf

<VirtualHost 127.0.0.3>
ServerName publish.localhost
DocumentRoot "/home/www/Publish"
<Directory "/home/www/Publish">
Options +Includes +Indexes +FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
<Directory "/home/www/Publish/cgi-bin">
Options +ExecCGI
</Directory>
<Directory "/home/www/Publish/Resources/Includes">
Options +ExecCGI
</Directory>
</VirtualHost>


... however since upgrading from Ubuntu 18 to 22, the subdomains don't
load, giving a 404, and the following sorts of entries are found in ...

/var/log/apache2/other_vhosts_access.log

publish.localhost:80 127.0.0.1 - - [03/Dec/2024:19:15:19 +0000] "GET /
HTTP/1.1" 301 568 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:129.0)
Gecko/20100101 Firefox/129.0"
local.localhost:80 127.0.0.1 - - [03/Dec/2024:19:22:21 +0000] "GET /
HTTP/1.1" 301 574 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:129.0)
Gecko/20100101 Firefox/129.0"
[etc]

... showing I think that the translation of, for example, ...

local.localhost -> 127.0.0.2

... is no longer occurring. Indeed, when I attempt to load the pages by
specifying the IP address directly, they all load. I suspect that this
has something to do with IP6, but do not know how to prove this or make
further progress. Can anyone give me some pointers?
--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk
Grant Taylor
2024-12-04 01:16:38 UTC
Permalink
Post by Java Jive
Can anyone give me some pointers?
What address does ping (et al.) use when you try to ping the sub-domains?

Determine if it's a name resolution issue or something else.
--
Grant. . . .
Java Jive
2024-12-04 02:07:58 UTC
Permalink
Post by Grant Taylor
Post by Java Jive
Can anyone give me some pointers?
What address does ping (et al.) use when you try to ping the sub-domains?
Determine if it's a name resolution issue or something else.
Thanks for the suggestion ...

Pinging each subdomain by name results in the corresponding correct IP,
as defined in /etc/hosts given in my OP, being pinged successfully.
--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk
Andy Burns
2024-12-04 06:13:01 UTC
Permalink
Post by Java Jive
... showing I think that the translation of, for example, ...
    local.localhost -> 127.0.0.2
... is no longer occurring.
Generally, I'm not an Ubuntu user, but to see if it's a resolver issue,
rather than apache, if you

ping local.localhost

do you get replies from 127.0.0.1 instead of 127.0.0.2 ?
Andy Burns
2024-12-04 06:14:52 UTC
Permalink
to see if it's a resolver issue, rather than apache
From your reply to Grant, it's not that ...
J.O. Aho
2024-12-04 07:44:11 UTC
Permalink
Post by Java Jive
In previous versions of Ubuntu, I had the following working arrangement
It's age ago I used apache, but still I think your setup is a bit odd...
I'm assuming that all apache modules has been configured correctly and
they load without errors.
Post by Java Jive
for defining localhost subdomains as follows ...
127.0.0.1    localhost
127.0.0.2    local.localhost
127.0.0.3    publish.localhost
I would have done:

127.0.0.1 localhost local.localhost publish.localhost

they do not need their own ip, specially not for apache.
Post by Java Jive
Note: In what follows, the files given below are links to files actually
in the sister directory sites-available, as per Apache standard
practice.  Further, I've removed all the comments and blank lines to
save space.
/etc/apache2/sites-enabled/001-localhost.conf
<Directory "/home/www">
    AllowOverride All
    Require all granted
</Directory>
If I remember it right, all the domains should be virtualhost when using
virtual hosts, assign the ServerName to it too.

<VirtualHost *:80>
SeverName localhost
...
</VirtualHost>
Post by Java Jive
/etc/apache2/sites-enabled/002-local.conf
<VirtualHost 127.0.0.2>
    ServerName local.localhost
    DocumentRoot "/home/www/Local"
    <Directory "/home/www/Local">
        Options +Includes +Indexes +FollowSymLinks
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
    <Directory "/home/www/Local/cgi-bin">
        Options +ExecCGI
    </Directory>
    <Directory "/home/www/Local/Resources/Includes">
        Options +ExecCGI
    </Directory>
</VirtualHost>
I would use

<VirtualHost *:80>
SeverName local.localhost
...
</VirtualHost>
Post by Java Jive
/etc/apache2/sites-enabled/003-publish.conf
<VirtualHost 127.0.0.3>
    ServerName publish.localhost
    DocumentRoot "/home/www/Publish"
    <Directory "/home/www/Publish">
        Options +Includes +Indexes +FollowSymLinks
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
    <Directory "/home/www/Publish/cgi-bin">
        Options +ExecCGI
    </Directory>
    <Directory "/home/www/Publish/Resources/Includes">
        Options +ExecCGI
    </Directory>
</VirtualHost>
<VirtualHost *:80>
SeverName publish.localhost
...
</VirtualHost>


If you need to access the same virtual host with multiple names, you can
use the ServerAlias for example

<VirtualHost *:80>
SeverName test.localhost
ServerAlias stage.localhost
...
</VirtualHost>

this one would work for both test.localhost and stage.loclhost (of
course you need to add it to your hosts file, before it really would
work in your browser too).
--
//Aho
Java Jive
2024-12-04 17:30:19 UTC
Permalink
Post by J.O. Aho
Post by Java Jive
In previous versions of Ubuntu, I had the following working arrangement
It's age ago I used apache, but still I think your setup is a bit odd...
I'm assuming that all apache modules has been configured correctly and
they load without errors.
Post by Java Jive
for defining localhost subdomains as follows ...
127.0.0.1    localhost
127.0.0.2    local.localhost
127.0.0.3    publish.localhost
127.0.0.1    localhost local.localhost publish.localhost
they do not need their own ip, specially not for apache.
Post by Java Jive
Note: In what follows, the files given below are links to files
actually in the sister directory sites-available, as per Apache
standard practice.  Further, I've removed all the comments and blank
lines to save space.
/etc/apache2/sites-enabled/001-localhost.conf
<Directory "/home/www">
     AllowOverride All
     Require all granted
</Directory>
If I remember it right, all the domains should be virtualhost when using
virtual hosts, assign the ServerName to it too.
<VirtualHost *:80>
  SeverName localhost
  ...
</VirtualHost>
Post by Java Jive
/etc/apache2/sites-enabled/002-local.conf
<VirtualHost 127.0.0.2>
     ServerName local.localhost
     DocumentRoot "/home/www/Local"
     <Directory "/home/www/Local">
         Options +Includes +Indexes +FollowSymLinks
         AllowOverride All
         Order allow,deny
         Allow from all
     </Directory>
     <Directory "/home/www/Local/cgi-bin">
         Options +ExecCGI
     </Directory>
     <Directory "/home/www/Local/Resources/Includes">
         Options +ExecCGI
     </Directory>
</VirtualHost>
I would use
<VirtualHost *:80>
  SeverName local.localhost
  ...
</VirtualHost>
Post by Java Jive
/etc/apache2/sites-enabled/003-publish.conf
<VirtualHost 127.0.0.3>
     ServerName publish.localhost
     DocumentRoot "/home/www/Publish"
     <Directory "/home/www/Publish">
         Options +Includes +Indexes +FollowSymLinks
         AllowOverride All
         Order allow,deny
         Allow from all
     </Directory>
     <Directory "/home/www/Publish/cgi-bin">
         Options +ExecCGI
     </Directory>
     <Directory "/home/www/Publish/Resources/Includes">
         Options +ExecCGI
     </Directory>
</VirtualHost>
<VirtualHost *:80>
  SeverName publish.localhost
  ...
</VirtualHost>
Thanks, the above changes have worked.

Now trying to restore cgi-bin functionality - php is working, but perl
and python not. Will post here if I need more help, meanwhile, thanks
again.
--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk
Java Jive
2024-12-07 11:44:44 UTC
Permalink
Now trying to restore cgi-bin functionality  -  php is working, but perl
and python not.  Will post here if I need more help, meanwhile, thanks
again.
Those turned out to be the shebangs. The site files are identical to
those when the sites runs under localhost on a Windows machine, and in
general this works very well. CGI files are the one exception I've ever
found:

In Windows, the shebang has to be of the form ...
#!python
#!perl
... which, as long as the relevant executables are on the path, works fine.

However, in Linux, and on the final online site, even with the
executables on the path, the shebang has to include the full path ...
#!/usr/bin/python
#!/usr/bin/perl

Can anyone suggest a way of arranging things so that the same shebang
works for both? I tried defining a variable in Linux BIN=/usr/bin/,
which could be empty for Windows, and using an include arrangement in
the shebang ....
#!<!--#echo var='BIN' -->python
... but this didn't work
--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk
Theo
2024-12-07 14:45:13 UTC
Permalink
Post by Java Jive
Now trying to restore cgi-bin functionality  -  php is working, but perl
and python not.  Will post here if I need more help, meanwhile, thanks
again.
Those turned out to be the shebangs. The site files are identical to
those when the sites runs under localhost on a Windows machine, and in
general this works very well. CGI files are the one exception I've ever
In Windows, the shebang has to be of the form ...
#!python
#!perl
... which, as long as the relevant executables are on the path, works fine.
However, in Linux, and on the final online site, even with the
executables on the path, the shebang has to include the full path ...
#!/usr/bin/python
#!/usr/bin/perl
Can anyone suggest a way of arranging things so that the same shebang
works for both? I tried defining a variable in Linux BIN=/usr/bin/,
which could be empty for Windows, and using an include arrangement in
the shebang ....
#!<!--#echo var='BIN' -->python
... but this didn't work
On Unix shebang lookups are run at a low level that isn't part of the shell
and so don't use paths. The usual way is to use 'env', which will look in
the path for the executable:

#!/usr/bin/env python

But I can't speak for what works for Windows.

Maybe instead you need to add a config line that says all scripts of MIME
type XYZ (eg text/x-python, set by a mapping from .py) need to be passed to
the Python interpreter to be executed, rather than served directly? That
should be more reliable and secure than shebangs.

Theo
Andy Burns
2024-12-07 15:36:22 UTC
Permalink
Post by Theo
I can't speak for what works for Windows.
Windows itself doesn't care about shebang lines, I'd leave them so
they're valid for linux.

but add a "ScriptInterpreterSource" directive probably with
"Registry-Strict" to your .conf files

<https://httpd.apache.org/docs/2.4/mod/core.html#ScriptInterpreterSource>

Then add registry entries with the path for each cgi interpreter you
want to invoke as e.g.
HKEY_CLASSES_ROOT\.py\Shell\ExecCGI\Command
Java Jive
2024-12-07 16:04:57 UTC
Permalink
Post by Andy Burns
Post by Theo
I can't speak for what works for Windows.
Windows itself doesn't care about shebang lines, I'd leave them so
they're valid for linux.
No, doesn't work I'm afraid. If I do that, the page rediirects to the
site error page, when I take out the path element of the shebang, it
works again.
Post by Andy Burns
but add a "ScriptInterpreterSource" directive probably with
"Registry-Strict" to your .conf files
<https://httpd.apache.org/docs/2.4/mod/core.html#ScriptInterpreterSource>
Then add registry entries with the path for each cgi interpreter you
want to invoke as e.g.
HKEY_CLASSES_ROOT\.py\Shell\ExecCGI\Command
Will investigate, thanks for the link.
--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk
Andy Burns
2024-12-07 16:16:26 UTC
Permalink
Post by Andy Burns
Windows itself doesn't care about shebang lines, I'd leave them so
they're valid for linux.
No, doesn't work I'm afraid.  If I do that, the page rediirects to the
site error page, when I take out the path element of the shebang, it
works again.
The default for ScriptInterpreterSource is "Script", so I think that's
Apache trying to make shebangs in Windows work similar to Linux
Java Jive
2024-12-08 00:13:48 UTC
Permalink
Post by Andy Burns
Post by Theo
I can't speak for what works for Windows.
Windows itself doesn't care about shebang lines,
But, as explained both in my earlier reply and in the page you linked
below, Apache running under Windows does. However ...
Post by Andy Burns
I'd leave them so
they're valid for linux.
but add a "ScriptInterpreterSource" directive probably with
"Registry-Strict" to your .conf files
<https://httpd.apache.org/docs/2.4/mod/core.html#ScriptInterpreterSource>
Then add registry entries with the path for each cgi interpreter you
want to invoke as e.g.
HKEY_CLASSES_ROOT\.py\Shell\ExecCGI\Command
I've got this to work, the test scripts I have devised now run under
Windows despite have Linux-style shebangs, so many thanks for your help.

These are the settings that worked for me:

In httpd.conf:

ScriptInterpreterSource Registry-Strict

In Registry:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.cgi]
@="Python.File"

[HKEY_CLASSES_ROOT\.pl]
@="Perl"

[HKEY_CLASSES_ROOT\.py]
@="Python.File"

[HKEY_CLASSES_ROOT\Perl\shell\ExecCGI]

[HKEY_CLASSES_ROOT\Perl\shell\ExecCGI\command]
@="C:\\Programs\\Perl\\bin\\perl.exe"

[HKEY_CLASSES_ROOT\Python.File\Shell\ExecCGI]

[HKEY_CLASSES_ROOT\Python.File\Shell\ExecCGI\command]
@="C:\\Programs\\Python\\2-7-16-64\\python.exe"
--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk
Jasen Betts
2024-12-14 06:57:35 UTC
Permalink
Post by Java Jive
Now trying to restore cgi-bin functionality  -  php is working, but perl
and python not.  Will post here if I need more help, meanwhile, thanks
again.
Those turned out to be the shebangs. The site files are identical to
those when the sites runs under localhost on a Windows machine, and in
general this works very well. CGI files are the one exception I've ever
In Windows, the shebang has to be of the form ...
#!python
#!perl
... which, as long as the relevant executables are on the path, works fine.
How is this a windows thing? I thought they did that sort of stuff using
file extensions (and the registry) instead! This is a serious bug,
stuff in /var/www should be os agnostic.

If this is some sort lame bolt on extension, unbolt it and reattach it to
use the second line of the file, or maybe get it to ignore the part between
slashes? you have access to the source right?
--
Jasen.
🇺🇦 Слава Україні
Java Jive
2024-12-14 12:40:46 UTC
Permalink
Post by Jasen Betts
Post by Java Jive
Now trying to restore cgi-bin functionality  -  php is working, but perl
and python not.  Will post here if I need more help, meanwhile, thanks
again.
Those turned out to be the shebangs. The site files are identical to
those when the sites runs under localhost on a Windows machine, and in
general this works very well. CGI files are the one exception I've ever
In Windows, the shebang has to be of the form ...
#!python
#!perl
... which, as long as the relevant executables are on the path, works fine.
How is this a windows thing? I thought they did that sort of stuff using
file extensions (and the registry) instead! This is a serious bug,
stuff in /var/www should be os agnostic.
See Andy's reply suggesting a solution, which I adopted.
--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk
Andy Burns
2024-12-14 12:48:41 UTC
Permalink
Post by Jasen Betts
How is this a windows thing?
It's not a Windows thing, it's Apache on Windows trying to hide the
difference ...

Loading...