“If this directory doesn’t exist, is empty, or has no
index.html, the default page will be served, mentioning there is no content on the site.”
The provided statement in the sympl.io under Configuration Reference section regarding the default page being served in certain scenarios is incorrect. According to my knowledge after conducting tests and exploring the functionality myself, I have found that this statement is inaccurate and does not reflect the actual behavior. When the specified directory does not exist, is empty, or lacks an index.php or index.html file, it does not serve a default page indicating the absence of content on the site as described in the documentation.
Any Error Messages
You don't have permission to access this resource.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.
I receive the above error or a blank page
- Sympl Version [9.0/10.0]: 11
- Sympl Testing Version? [No]
- Debian Version [Bullseye]
- Hardware Type? [Pi]
- Hosted On? [GCP instance]
The sympl-web packages for the Pi hardware are not currently available for Debian Bullseye due to an issue with the build setup - it’s being looked at, but you should but able to run it on regular x64 hardware, or use the Buster version instead.
Apologies for the confusion in my previous comment. I mistakenly mentioned the hardware type as ‘pi’ instead of the correct ‘virtual’ hardware type.
Sympl hasn’t been fully tested on the GCP as it tends to be not-quite-regular Debian, or has an unusual network setup.
dpkg -l 'sympl-*' and let me know the results - it seems likely something isn’t fully installed.
You should also be able to run
hostname -f and get the full public hostname for the server also.
Here is the result by running dpkg -l ‘sympl-*’ command
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
ii sympl-backup 11.20210818.1 all Automatic backups for Sympl
ii sympl-core 11.20220426.0 all Sympl - Easy server management via SSH
ii sympl-cron 11.20220322.1 amd64 Per-domain crontab support for Sympl
ii sympl-dns 11.20210818.1 all Automatic DNS record generation for Sympl
ii sympl-firewall 11.20220719.0 amd64 Firewall generator for Sympl
ii sympl-ftp 11.20210818.1 all Virtual FTP hosting in Sympl
ii sympl-mail 11.20220929.0 all Virtual email hosting in Sympl
ii sympl-monit 11.20210818.1 all Service monitoring for Sympl
ii sympl-mysql 11.20210818.1 all MariaDB database for Sympl
ii sympl-phpmyadmin 11.20210818.1 all Web-based database access for Sympl
ii sympl-updater 11.20210818.1 all Automatic package updates for Sympl
ii sympl-web 11.20220406.0 amd64 Tools to manage web hosting in Sympl
ii sympl-webmail 11.20220322.0 all Webmail access for mailboxes on Sympl
That all looks as expected, so it’s installed, but its likely that Sympl cannot associate any of the IPs on the VM to the addresses you’re accessing, so it’s falling back to the Apache defaults.
Unfortunately due to the way the Google Cloud platform is apparently set up, you might have this kind of issue, and I don’t have access to a machine running on GCP to diagnose it at present.
Does Sympl work as expected with manually configured sites? The fallback page you’re expecting comes from the default configuration, ie:
/srv/full.hostname.of.server/ so if traffic isn’t getting picked up by that, you’d likely see the message.
You might try running
sympl-ip to get the addresses it knows about, and then adding them to
/srv/example.com/config/ip which will bind that site to the IP address, and also adding a hosts entry to
/etc/hosts for the full hostname also, then running
sudo sympl-web-configure --verbose.
If anyone else is familiar with the GCP setup (or similar), they might be able to help.
After running the
sympl-ip command, I noticed that the IP it displays is the internal IP rather than the expected external IP. Additionally, upon checking the
/srv/example.com/config/ip file, I couldn’t find any IP configuration file present.
I am currently in the process of setting up Sympl on a Vultr Debian instance just because GCP has an unusual network setup and not a regular Debian though.