XPost: alt.os.linux

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2024-12-04 01:16, Grant Taylor wrote:

On 12/3/24 16:54, Java Jive wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 12/3/24 16:54, Java Jive wrote:

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. . . .

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

Java Jive wrote:

... 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 ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

Andy Burns wrote:

to see if it's a resolver issue, rather than apache

From your reply to Grant, it's not that ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 03/12/2024 23.54, Java Jive wrote:

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.

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

I would have done:

127.0.0.1 localhost local.localhost publish.localhost

they do not need their own ip, specially not for apache.

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>

/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>

/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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2024-12-04 07:44, J.O. Aho wrote:

On 03/12/2024 23.54, Java Jive wrote:

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.

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

I would have done:

127.0.0.1    localhost local.localhost publish.localhost

they do not need their own ip, specially not for apache.

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>

/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>

/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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2024-12-04 17:30, Java Jive wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:

On 2024-12-04 17:30, Java Jive wrote:

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2024-12-07 15:36, Andy Burns wrote:

Theo wrote:

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

Theo wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

Java Jive wrote:

Andy Burns wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2024-12-07 15:36, Andy Burns wrote:

Theo wrote:

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 ...

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2024-12-07, Java Jive <java@evij.com.invalid> wrote:

On 2024-12-04 17:30, Java Jive wrote:

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.

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.
🇺🇦 Слава Україні

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2024-12-14 06:57, Jasen Betts wrote:

On 2024-12-07, Java Jive <java@evij.com.invalid> wrote:

On 2024-12-04 17:30, Java Jive wrote:

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

Jasen Betts wrote:

How is this a windows thing?

It's not a Windows thing, it's Apache on Windows trying to hide the
difference ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)