F96-CE: Unable to run Hiawatha web server 'out of the box' [Workarounded]

[ozboomer]

As part of a couple of projects where I'm using Puppy, I've been having on-going troubles of various sorts... but I thought I'd post a question to try and resolve this one issue.

I'm running a frugal installation of F96-CE_4 and comparing it to a similar installation of BionicPup64 8.0, both installed on their own USB flash drives with only the ISO contents, as well as the relevant 'devx' .sfs file loaded after startup.

In short, running the 'Hiawatha' web server doesn't work 'out of the box' in F96-CE, whereas it works Ok in BionicPup64... and this is the case on different PCs, with BIOS and UEFI booting.

For F96-CE:

Code: Select all

# hiawatha -k
Using /etc/hiawatha
Reading hiawatha.conf
Reading /etc/mime.types
Configuration OK.
# 
# 
# hiawatha -d
Press Ctrl-C to shutdown the Hiawatha webserver.

...and I then:

- start Firefox
- enter the address: http://localhost/ AND 'hard refresh' the page...

...and a page is displayed:

'Forbidden (403)'

...which tells me the server is working but there's perhaps some 'permission' problem... maybe.

- close Firefox
- stop the web server & exmaine the log:

Code: Select all

# hiawatha -d
Press Ctrl-C to shutdown the Hiawatha webserver.
^C
#
# cat /var/log/hiawatha/error.log
127.0.0.1|Sun 09 Jun 2024 17:08:23 +1000|access denied via filesystem
127.0.0.1|Sun 09 Jun 2024 17:08:36 +1000|access denied via filesystem
127.0.0.1|Sun 09 Jun 2024 17:08:36 +1000|access denied via filesystem
# 

- start Firefox again
- enter the address: http://localhost/ AND 'hard refresh' the page...

...and a page is displayed:

Unable to connect

An error occurred during a connection to localhost.

...which I think indicates there is no server running

- close Firefox

For BionicPup64:

Code: Select all

# hiawatha -k
Using /etc/hiawatha
Reading hiawatha.conf
Reading /etc/mime.types
Configuration OK.
#
#
# hiawatha -d
Press Ctrl-C to shutdown the Hiawatha webserver.

...and I then:

- Start Pale Moon
- enter the address: http://localhost/ AND 'hard refresh' the page...

...and the default page is displayed (that is /root/Web-Server/index.html)

...which suggests the web server is working Ok.

- close Pale Moon
- stop the web server & exmaine the log:

Code: Select all

# hiawatha -d
Press Ctrl-C to shutdown the Hiawatha webserver.
^C
#
# cat /var/log/hiawatha/error.log
# 

...that is, the error.log file is empty

- Start Pale Moon again
- enter the address: http://localhost/ AND 'hard refresh' the page...

...and a page is displayed:

Pale Moon can't establish a connection to the server at localhost.

...which I think indicates there is no web server running

- close Pale Moon

To note:

• the files in /etc/hiawatha and /root/Web-Server in both distributions have the same ownership and contain the same files

• I've gone through the same process on different PCs, with and without an active internet connection, via an ethernet port or a wireless adapter and the (mis-)behaviour is the same

• I've also had successful behaviour 'out of the box' in all these environments using xenialpup64 7.5 and tahrpup64 6.0.5

I'd greatly appreciate any suggestions on where to explore next.

[rockedge]

@ozboomer sorry I didn't see this topic sooner.

I think some adjustments to the /etc/hiawatha/hiawatha.conf will fix this. Can you post the contents of the hiawatha.conf file?

Try starting Hiawatha with no switches:

Code: Select all

hiawatha
killall hiawatha

Stock Hiawatha configuration makes /root/Web-Server the server root and is strickly set up with permissions to run /root/Web-Server/blog

[ozboomer]

/etc/hiawatha/hiawatha.conf in each instance (both F96-CE and BionicPup64) is the same... and is unchanged from what is in each respective .ISO, viz:

Code: Select all

ServerId = webuser
ConnectionsTotal = 150
ConnectionsPerIP = 10
SystemLogfile = /var/log/hiawatha/system.log
GarbageLogfile = /var/log/hiawatha/garbage.log

Binding {
	Port = 80
	Interface = 127.0.0.1
}

Hostname = 127.0.0.1
WebsiteRoot = /root/Web-Server
StartFile = index.html
AccessLogfile = /var/log/hiawatha/access.log
ErrorLogfile = /var/log/hiawatha/error.log

#add this stuff to get a perl script working (pplog)...
#QUISP has a binary executable CGI named 'quisp.bin'...
MimetypeConfig = /etc/mime.types
#CGIhandler = /usr/bin/perl:pl
CGIextension = pl,bin
ExecuteCGI = yes
#QUISP puts %0D, %0A (carriage-return, line-feed) chars in the url
#(v128), to allow chars below ascii 32 need this...
SecureURL = no

I guess one question is whether the hiawatha server is known to actually work 'out of the box' under F96-CE..? Interestingly, even though it does run, it is NOT listed in the 'official' program list ( see https://f96.puppylinux.com/proglist/index.html )... and maybe it's a 'fluke' that the /usr/sbin/hiawatha program works as a 'legacy' with F96-CE being derived from FossaPup96?

[rockedge]

@ozboomer Back when we were putting F96-CE_4 together the Hiawatha web server was with purpose included. I personally use the Hiawatha web server extensively on F96-CE.

I just am testing Hiawatha now on a stock F96-CE. What happens often is the configuration file for Hiawatha was originally made to use /root/Web-Server as the web root and run under the user webuser:webgroup which is the the owner of /root/Web-Server.

These are the modifications I made to get started:

Code: Select all

ServerId = webuser
ConnectionsTotal = 150
ConnectionsPerIP = 10
SystemLogfile = /var/log/hiawatha/system.log
GarbageLogfile = /var/log/hiawatha/garbage.log

Binding {
	Port = 80
#	Interface = 127.0.0.1
	MaxKeepAlive = 30
	TimeForRequest = 6,60
        MaxRequestSize = 8192
}

Hostname = 127.0.0.1
WebsiteRoot = /var/www/hiawatha
StartFile = index.html
AccessLogfile = /var/log/hiawatha/access.log
ErrorLogfile = /var/log/hiawatha/error.log
MaxUrlLength = 2048
ChallengeClient = 200, httpheader, 60 

#add this stuff to get a perl script working (pplog)...
#QUISP has a binary executable CGI named 'quisp.bin'...
MimetypeConfig = /etc/mime.types
CGIhandler = /usr/bin/perl:pl
CGIextension = pl,bin
ExecuteCGI = yes
#QUISP puts %0D, %0A (carriage-return, line-feed) chars in the url
#(v128), to allow chars below ascii 32 need this...
SecureURL = no

VirtualHost {
	Hostname = localhost
	WebsiteRoot = /var/www/hiawatha
	StartFile = index.php
	AccessLogfile = /var/log/hiawatha/access_log
	ErrorLogfile = /var/log/hiawatha/error_log
	TimeForCGI = 60
    ShowIndex = yes
    ExecuteCGI = yes
    FollowSymlinks = yes
    NoExtensionAs = cgi
    EnablePathInfo = yes    
    UseLocalConfig = yes
}

Then important to assign the web server root /var/www/hiawatha to the user webuser

Code: Select all

chown -R webuser:webgroup /var/www/hiawatha

Rename the original hiawatha.conf create a new one and try it out with http://localhost:

Screenshot.jpg (35.07 KiB) Viewed 949 times

[rockedge]

I have found that using Hiawatha to it's fullest potential we'll need to use SFS-Load to install the devx SFS. THe devx has the majority of the PERL modules.

Let's say we also want the Puppy Blog to work in this new web root. So copy /root/Web-Server/blog to /var/www/hiawatha

Open the site with a browser: http://localhost/blog and you should see this:

Screenshot(1).jpg (58.44 KiB) Viewed 932 times

it doesn't start the blog because in the hiawatha.conf we have configured for a .hiawatha file to indicate what to execute. UseLocalConfig = yes

So lets create the hidden file .hiawatha and place it inside /var/www/hiawatha/blog
.hiawatha

Code: Select all

StartFile=pup_pplog.pl

Let us insure that all the ownership for the web sever root is in order with in a terminal:

Code: Select all

chown -R webuser:webgroup /var/www/hiawatha

Now to really get the Blog to work some paths need to be adjusted:

Open /var/www/hiawatha/blog/pup_pplog.pl and change the paths in these lines (35,37,38)

Code: Select all

our $config_smiliesFolder = '/var/www/hiawatha/blog/smilies';				# Path to smilies, if you dont want smilies, just, dont upload that folder
our $config_smiliesFolderName = 'smilies';								# Smilies Folder Name, you should NOT change this...
our $config_postsDatabaseFolder = '/var/www/hiawatha/blog/posts';			# Name of the folder where entries will be saved. 
our $config_commentsDatabaseFolder = '/var/www/hiawatha/blog/comments';	

restart the Hiawatha server:

Code: Select all

killall hiawatha
hiawatha

Screenshot(2).jpg (46.1 KiB) Viewed 932 times

You might have noticed in the previous post's screenshot that there is another directory (site)
This is a simple one page web site written in HTML:

Screenshot(3).jpg (17.24 KiB) Viewed 931 times

[ozboomer]

Fanx!, @rockedge ... 'tis a good explanation of things...

So, I set-up my 'clean' F96-CE ISO-only USB flash drive.. and booted into F96-CE.

I had 3 files in /etc/hiawatha :

• hiawatha.conf.stock = a duplicate of the file in the ISO

• hiawatha.conf.rockedge = your first modified version

• hiawatha.conf.ozb = your first modified version, further changed to work with /root/Web-Server

Their contents compared:

stock-to-rockedge.png (292.2 KiB) Viewed 893 times

rockedge-to-ozb.png (287.98 KiB) Viewed 893 times

..and I proceeded to try a few things:

• I swapped in the 'stock' config file... and the 'Forbidden 403' error came up, as usual.

• I swapped in the 'rockedge' config file... and everything worked, good as gold.

• I swapped in the 'ozb' config file... and the 'Forbidden 403' error came up.

Once the server is working, the cgi and other features all fall out Ok without any further modification... so there' s no need to detail that here.

So, for now, I have a workaround that will get the job done... so, Fanx! a heap for that, as I can do what I need to do .

...but the original question remains: Why does the ISO-version hiawatha installation in BionicPup64 work on /root/Web-Server but the F96-CE installation does not, given they both use the same configuration files and the paths, files, etc have the same protections, etc?

[rockedge]

...but the original question remains: Why does the ISO-version Hiawatha installation in BionicPup64 work on /root/Web-Server but the F96-CE installation does not, given they both use the same configuration files and the paths, files, etc have the same protections, etc?

Still a good question. It should work and why when configured with WebsiteRoot = /root/Web-Server it comes up Forbidden. Somewhere something broke in F96-CE_4 and will have to be tracked down to the exact cause. The original configuration should at least run the PERL blog so we know now that is centered around the WebsiteRoot = /root/Web-Server config.

[rockedge]

@ozboomer After digging into this it is clear that something has changed between Bionicpup and the latest Fossapup that prevents us from configuring Hiawatha to access any folder under the /root directory. No matter what I have tried I can not use /root/Web-Server as the DocumentRoot=.

Note: I have the devx SFS installed.

I can't even start the server via menu to activate the Blog that lives in /root/Web-Server. Although when I copy that to /var/www/Web-Server and assign that as the DocumentRoot=/var/www/Web-Server. Then chown -R webuser:webgroup /var/www/Web-Server to ensure that the web server user matches the DocumentRoot of Hiawatha.

Adding several more options and parameters to the hiawatha.conf and the web server is running in a fully scalable, stable state.

Changing the paths on three lines in the /var/www/Web-Server/blog/pup_pplog.pl PERL program will have it operating smoothly if anyone is interested in it's capabilities. It actually needs some work to modernize it a bit.

So to sum it up......it looks like there is a challenge to allow the Hiawatha web server from serving a DocumentRoot that is in the /root directory

Now to determine what has changed. Is it Hiawatha in newer versions? Or is it something in the later Fossapup64's produced by woof-CE that F96-CE_4 is based on? We know it works in Bionic32 and Bionic64 in this exact configuration. So it is not a difference in config file.

[ozboomer]

Thanks for digging some more, @rockedge ...

So, ultimately, it seems Hiawatha does not work 'out of the box' in F96-CE_4, unlike some other Puppy variants ... but no matter, we can establish a working configuration that isn't horrendous to set-up.

So, f'now, it can be added to the 'issues' list (but I guess, with a low-ish priority).

So, off we go, tilting at other windmills ...