I think everything I heard about Fossil so far was great, for the first time I felt something was better than SVN (Git sux in my opinion). The only problem which I have about Fossil (or any other Open Source project on Linux) is: How do I install the Server? I am pretty sure this is a n00b question but usually for Linux apps I have some issues installing. By the way, I am doing this installation on my Ubuntu VirtualBox machine...

Thank you for the help!

The server binary is no different than the client binary.

Did you see the download page? https://fossil-scm.org/fossil/uv/download.html

Download the binary; untar; place in your path, then initialize a repo and fire up the server: fossil server.

Some pages to read:

https://fossil-scm.org/fossil/doc/trunk/www/quickstart.wiki

https://fossil-scm.org/fossil/doc/trunk/www/fiveminutes.wiki

See also: https://www.fossil-scm.org/fossil/doc/trunk/www/server.wiki

Further to this, I was thinking earlier this morning that it would be good to create a documentation page (or pages) that describe in detail how to set up a complete developers site using Fossil, starting from fresh Ubuntu node at Linode and walking the user through the complete process including:

1. Signing up and obtaining a Linode
2. Logging into the new Linode
3. Obtaining a domain name
4. Setting up a web-server
5. Configuring TLS
6. Getting and installing a Let's Encrypt cert
7. Setting up an email server
8. Configuring Fossil to send email alerts
9. Configuring a Fossil Forum
10. Security audit
11. Periodic maintenance

Maybe this should be a whole separate project, including downloads of useful configuration files and scripts. Seems like unpacking a tarball and running a single shell script (as root) could maybe do most of the above by itself.

Even if the instructions above already existed, setting up a private developer site is a lot of work relative to registering with GitHub or the equivalent. And a private site costs you (at least) $7/month for the linode and your domain name. But in exchange for the added hassle and expense, you get enhanced freedom. And you help promote decentralization, which people are increasingly recognizing as a good thing.

For a long time GoDaddy was my email server, but they changed their pricing structure and is too expensive. I got a 1GB Linode server and experimented with setting up my own email server.

After trying to follow the recipe given on HowToForge

https://www.howtoforge.com/tutorial/installing-a-web-email-and-mysql-database-cluster-on-debian-8.4-with-ispconfig-3/

It was just too troublesome, too complicated, and had too many problems.

After trying several other script based setups, and a couple weeks of testing, I eliminated all but one.

Mail-In-A-Box is a complete server setup script which was surprisingly easy to setup. Automatically sets up Ubuntu to host a website for the domain. I have several emails for different domains setup all on the same server. Sets up everything including Lets-encrypt. The best part is it all runs on a simple 1gb vps whereas other installations balked at 1gb wanting at least 2gb.

https://mailinabox.email/

On Linode, initialize with the Ubuntu 18 operating system.

Log on as root using ssh such as Putty or the Linode control panel ssh

DO THIS NEXT STEP BEFORE DOING ANYTHING ELSE

apt-get update

apt-get dist-upgrade

open your browser on your computer to the mail-in-a-box website

https://mailinabox.email/

and follow their instructions. not too difficult and mostly automatic. Just have to answer a few prompts so it knows how to setup a few things. Install takes about 10-15 minutes.

Follow the directions for your fist log on through your browser then write down the various information (or cut and paste) to set the DNS entries. It tells exactly what to set and it worked the first time I tried setting the DNS info from the GoDaddy DNS manager (they are my registrar, but should be similar for other registrars)

You now have a complete Ubuntu server setup. Note that it may take 24 hours for the DNS information to propagate throughout all the internet name servers before it is functional, so go to bed and check it tomorrow.

As to setting up fossil, I poked at it a couple of times but have not been able to get it to work. Someone else needs to chime in on how to do that as I have not yet figured out how to do it. But the hard part of setting up the server system with email is done at this point.

Posting as anonymous because I can't remember my password and don't see a way to recover/replace it.

After many years of lurking, I can make a small contribution to the documentation. Mid-2018, I installed a VPS on Linode. It has been happily running since then with just a couple of restarts for configuration reasons.

Here is the anonymised version of my installation notes for Debian 8. Ubuntu should be similar. I use the Hiawatha web server and Webmin general administration program. If these are not applicable then you will need to change the relevant sections. Using LetEncrypt is just one of a number of installation/configuration activities. It will interact with the installed web server, so document changes might be needed there. The text is in Markdown format. Do with it as you wish.

Regards,

Chris

--- begin text ---

Linode VPS Installation

Introduction

Linode provides a variety of standard configurations for each virtual private server (VPS). The one chosen is one CPU, one gigabyte of RAM, and 20 gigabytes of local storage, called a "nanonode".

In addition, extra disk storage is available to be added as another hard disk device. A 120 gigabyte initial size was chosen. It can be increased later as-needed. It can be called as "/mnt/xxxxx" and has sub-directories to suit your needs.

Define VPS

Linode account registration:

• username: as declared at ordering time

• password: your choice

• VPS identifer: linode7654321 (as stated by linode)

• IP address: 111.222.333.444

Add Extra Storage Volume (optional)

In the Linode control program, select:

Volumes » Volume Attached

The "chosen name" volume will be attached the next time you boot the linode7654321 Linode.

Once attached, it will appear as

/dev/disk/by-id/scsi-0Linode_Volume_library.

Instructions

To get started with a new volume, you'll want to create a filesystem on it:

mkfs.ext4 /dev/disk/by-id/scsi-0Linode_Volume_xxxxxx

Once the volume has a filesystem, you can create a mountpoint for it:

mkdir /mnt/xxxxxx

Then you can mount the new volume:

mount /dev/disk/by-id/scsi-0Linode_Volume_xxxxxx /mnt/xxxxxx

If you want the volume to automatically mount every time your Linode boots, you'll want to add a line like the following to your /etc/fstab file:

/dev/disk/by-id/scsi-0Linode_Volume_xxxxxx /mnt/xxxxxx ext4 defaults 0 2

Login details before a domain name is assigned

At a local command line terminal:

ssh root@111.222.333.444
password: as noted previously

Ensure the operating system is up-to-date

apt-get update
apt-get upgrade
hostnamectl set-hostname <your-host-name>

mkdir /root/local

Install webmin server administration program

cd /root/local

wget https://prdownloads.sourceforge.net/webadmin/webmin_1.xxx_all.deb
apt ./install webmin_1.xxx_all.deb

Install Hiawatha webserver (or other generic server)

apt-get install cmake
apt-get install zlibc zlib1g-dev libxslt1-dev
apt-get install dpkg-dev debhelper fakeroot

cd /root/local

wget https://www.hiawatha-webserver.org/files/hiawatha-10.8.1.tar.gz
tar -xvf hiawatha-10.8.1.tar.gz

cd hiawatha-10.8.1
mkdir build
cd build
cmake ..
../extra/make_debian_package
cd ..
apt install ./hiawatha_10.8.1_amd64.deb

First edit to /etc/hiawatha/hiawatha.conf

nano /etc/hiawatha/hiawatha.conf

Find Hostname = 127.0.0.1 and replace it with

Hostname = 111.222.333.444

Save file and exit from editor

Hiawatha was started during the apt install operation but needs to be restarted to process new configuration.

service hiawatha restart

Using webmin for system administration

url: https://111.222.333.444:10000

Login using id = root and password as noted.

Add users

Use webmin from local browser.

url: https://111.222.333.444:10000

Login using id = root and password as above.

Select left side menu "System" then "Users and Groups".

Create new users: as needed

Change shell to /bin/bash for all to allow command line history.

Assign primary group for all user as www-data. This permits the webserver (also groupid www-data) to access files without issue and avoids permission issues when other users copy or work with files in the various /home/xxxx directories.

Assign secondary groups as sudo and user to select admin users.

Configure firewall

Use webmin from local browser.

Select left side menu "Networking" then "Linux Firewall".

Create new input rules with following conditions for tcp ports:

# ftp:
Accept     If protocol is TCP and destination port is 20
# ftp:
Accept     If protocol is TCP and destination port is 21
# ftp:
Accept     If protocol is TCP and destination port is 22
# http:
Accept     If protocol is TCP and destination port is 80
# https:
Accept     If protocol is TCP and destination port is 443
# mysql:
Accept     If protocol is TCP and destination port is 3128
# proftpd passive ports:
Accept     If protocol is TCP and destination port is 6000 to 7000
# webmin:
Accept     If protocol is TCP and destination port is 10000
# default reject rest:
Reject     Always

Install ftp client program

Login to server from local ssh.

apt-get install ftp

Install ProFTPD server

Use webmin from local browser.

Select left side menu "Un-used Modules" then "ProFTPD Server"

You will be notified that it was not found on server and asked to install it.

By default, the system user file (etc/passwd) identifies permitted users. It is possible to create a separate ftp only login. See the proftpd documentation.

After installation configure as follows for insecure transfers:

• create a new virtual server with handle all connections to 111.222.333.444 and address "<your-domain>".

• in networking options change PASV port range to be 6000 - 7000.

• edit the /etc/proftpd/proftpd.conf file to add this line near the bottom of the file after other configurations files:

  Include /etc/proftpd/modules.conf

• edit the /etc/proftpd/modules.conf file to add this line above the comment "# keep this module the last one:

  # allow use of MLSD/MLST commands
  LoadModule mod_facts.c
  

Restart the proftpd server from webmin.

Install Lets Encrypt certificates

Preliminary

Following activities require operating under superuser.

Login using ssh to root.

If the Lets Encrypt certbot utility is not installed:

apt-get install certbot

Ensure webserver is running before starting this procedure.

In the web server configuration file, temporarily disable any virtual host instruction to require TLS or to enforce hostname redirection to www.<your-domain>.

In Hiawatha, these configuration instructions should be made into comments:

• EnforceFirstHostname = yes # should be applied ONLY if www.--- and no www.--- are defined
• RequireTLS = yes, 2678400; includeSubDomains # applies to all sub-domains

If these entries are still active the LetsEncrypt certbot will fail.

Restart the web server.

systemctl restart <your server start name>

Ensure there are DNS records in the Linode Manager for all intended domains and sub-domains.

Renew Existing Certificates

After the above restart of the web server, it is possible to trigger a renewal action with this command:

certbot renew

If there are certificates within 30 days of expiry they will be renewed. NOTE: this does not perform the extra steps to cat the private key and certificate chain which are described below.

Multiple Domain Certificates

Note that the following command includes multiple domains and the webroot for each must exactly match what is in the web server configuration file. Here is a sample:

certbot certonly --webroot \
-w /mnt/library -d lib.<domain-1>.com \
-w /home/<user-a>/doc/site -d doc.<domain-1> \
-w /home/<user-b>/www/site -d internal.<domain-2> \

If new sub-domain servers are created then the above list will need additions. The last in the list is used as a default for some purposes by letsencrypt so you should insert new domains above the last one.

Upon success, the certificate files will be linked in:

/etc/letsencrypt/live/<domain-2>

The links in this sub-directory point to real files in the sub-directory

/etc/letsencrypt/archive/<domain-2>

BUT hiawatha requires that both private key and certificates be in a single file. Other web servers accept separate files.

cd /etc/letsencrypt/archive/<domain-2>

Note the trailing digit increments with each renewal:

cat privkey1.pem fullchain1.pem >everything1.pem

cd /etc/letsencrypt/live/domain-2>

ln --symbolic ../../archive/<domain-2>/everything1.pem everything.pem

Enable the SSL/TLS section in web server configuration file. For hiawatha, this is done as follows:

nano /etc/hiawatha/hiawatha.conf

Binding {
        Port = 443
#       TLScertFile = tls/hiawatha.pem
        TLScertFile = /etc/letsencrypt/live/<domain-2>/everything.pem
#       Interface = 127.0.0.1
}

This becomes the default certificate. In the section below for some virtual domain(s), another certificate might be obtained and configured in its sub-domains.

Save changes.

Specific Domain Certificate

Repeat the above steps with a different set of domains:

certbot certonly --webroot \
-w /home/<some-user>/uat/site -d uat.<domain-3> \
-w /home/<some-user>/www/site -d <domain-3> -d www.<domain-3>

Upon success, the certificate files will be linked in:

/etc/letsencrypt/live/<domain-3>

The links in this sub-directory point to real files in the sub-directory

/etc/letsencrypt/archive/<domain-3>

BUT hiawatha requires that both private key and certificates be in a single file.

cd /etc/letsencrypt/archive/<domain-3>

Note the trailing digit increments with each renewal:

cat privkey1.pem fullchain1.pem >everything1.pem

cd /etc/letsencrypt/live/<domain-3>

ln --symbolic ../../archive/<domain-3>/everything1.pem everything.pem

Enable use of the correct certificate for these domains. For <domain-3> virtual host sub-domains specified in the certificate in web server configuration file:

TLScertFile = /etc/letsencrypt/live/<domain-3>/everything.pem

Save changes.

Revert Configuration Changes and Restart The Web Server

Remove commenting action on the following configuration entries for each virtual host. For hiawatha the following apply:

• EnforceFirstHostname = yes # should be applied ONLY if www.--- and no www.--- are defined
• RequireTLS = yes, 2678400; includeSubDomains # applies to all sub-domains

Restart the server:

systemctl restart hiawatha

Ensure hiawatha will start at reboot. Verify the systemd service is installed as part of the apt-get install for hiawatha. Look in the webmin - system tab for the entry "hiawatha.service" and confirm that it is flagged for start on boot. Or test it by clearing your browser cache and loading one of the domain pages.

Configure Webmin to use new SSL certificate

Login to webmin as root.

Select the left side menu Webmin and the sub-menu Webmin Configuration.

Select the SSL encryption link.

Change the Private key file entry to:

/etc/letsencrypt/live/<your-domain>/everything.pem

Change the Certificate file entry to:

Same file as private key

Save changes.

Return to the Webmin Configuration page and restart webmin.

Install Fossil source code management software

Use browser to determine current version of fossil then:

Login using ssh to root.

mkdir ~/local
cd ~/local

Using the current version numbers at time of download:

wget http://www.fossil-scm.org/index.html/uv/fossil-linux-x64-2.6.tar.gz
tar -xvf fossil-linux-x64-2.6.tar.gz

A single file (fossil) will be extracted from the zipped file. Now move it to its working location:

mv fossil /usr/local/bin/

--- end text ---

I can't remember my password and don't see a way to recover/replace it.

Send an email directly to me (drh@sqlite.org).

Your text is great. I really want you to be able to publish it directly. I could copy/paste, but it would be better if you do it so that we can record that it came from you.

Just a quick note. the cloud and contacts are optional and are paid services. I do not use those and they are disabled by default.

There's a delete moderation request pending but I don't know where it is? artifact [d26535aea3]

I have logged in as my registered name and provide here an edited version of the original submission.

Further notes:

• Substitution variables in the text are of the forms "xxxx", "111.222.333.444", domain-x, some-user. Do not include the left and right angle brackets if you see them in code sections; that is how I highlighted the variables originally. This forum will remove them from non-code sections, so I had to change technique.

• I chose Hiawatha web server because I find Apache configuration to be a bit of black magic for anything sophisticated.

• Webmin really does help to avoid a lot of command line work.

• I did not install a mail server, having run one for several years I find that recent requirements for SPF, DKIM, DMARC and avoiding blacklists make it a high risk proposition. In my opinion it is much better to use a third party commercial service (Fastmail in my case).

• I did install sSMTP for outbound emails, acting as a relay server to the third party service. It pretends to be sendmail with much simpler configuration.

Again, use this document as you please.

Chris

--- Begin text ---

Linode VPS Installation

Introduction

Linode provides a variety of standard configurations for each virtual private server (VPS). The one chosen is one CPU, one gigabyte of RAM, and 20 gigabytes of local storage, called a "nanonode".

In addition, extra disk storage is available to be added as another hard disk device. A 120 gigabyte initial size was chosen. It can be increased later as-needed. It can be called as "/mnt/xxxxx" and has sub-directories to suit your needs.

Define VPS

Linode account registration:

• username: as declared at ordering time

• password: your choice

• VPS identifer: linode7654321 (as stated by linode)

• IP address: 111.222.333.444

Add Extra Storage Volume (optional)

In the Linode control program, select:

Volumes » Volume Attached

The "chosen name" volume will be attached the next time you boot the linode7654321 Linode.

Once attached, it will appear as

/dev/disk/by-id/scsi-0Linode_Volume_library.

Instructions

To get started with a new volume, you'll want to create a filesystem on it. This is done after ssh login as detailed in the next section.

mkfs.ext4 /dev/disk/by-id/scsi-0Linode_Volume_xxxxxx

Once the volume has a filesystem, you can create a mountpoint for it:

mkdir /mnt/xxxxxx

Then you can mount the new volume:

mount /dev/disk/by-id/scsi-0Linode_Volume_xxxxxx /mnt/xxxxxx

If you want the volume to automatically mount every time your Linode boots, you'll want to add a line like the following to your /etc/fstab file:

/dev/disk/by-id/scsi-0Linode_Volume_xxxxxx /mnt/xxxxxx ext4 defaults 0 2

Login details before a domain name is assigned

At a local command line terminal:

ssh root@111.222.333.444
password: as noted previously

Ensure the operating system is up-to-date

apt-get update
apt-get upgrade
hostnamectl set-hostname <your-domain-name>

mkdir /root/local

Install webmin server administration program

cd /root/local

wget https://prdownloads.sourceforge.net/webadmin/webmin_1.xxx_all.deb
apt install ./webmin_1.xxx_all.deb

Install Hiawatha webserver (or other generic server)

apt-get install cmake
apt-get install zlibc zlib1g-dev libxslt1-dev
apt-get install dpkg-dev debhelper fakeroot

cd /root/local

wget https://www.hiawatha-webserver.org/files/hiawatha-10.8.1.tar.gz
tar -xvf hiawatha-10.8.1.tar.gz

cd hiawatha-10.8.1
mkdir build
cd build
cmake ..
../extra/make_debian_package
cd ..
apt install ./hiawatha_10.8.1_amd64.deb

First edit to /etc/hiawatha/hiawatha.conf

nano /etc/hiawatha/hiawatha.conf

Find "Hostname = 127.0.0.1" and replace it with

Hostname = 111.222.333.444

Save file and exit from editor

Hiawatha was started during the apt install operation but needs to be restarted to process new configuration.

service hiawatha restart

Using webmin for system administration

url: https://111.222.333.444:10000

Login using id = root and password as noted.

Add users

Use webmin from local browser.

url: https://111.222.333.444:10000

Login using id = root and password as above.

Select left side menu "System" then "Users and Groups".

Create new users: as needed

Change shell to /bin/bash for all to allow command line history.

Assign primary group for all user as www-data. This permits the webserver (also groupid www-data) to access files without issue and avoids permission issues when other users copy or work with files in the various /home/xxxx directories.

Assign secondary groups as sudo and user to select admin users.

Configure firewall

Use webmin from local browser.

Select left side menu "Networking" then "Linux Firewall".

Create new input rules with following conditions for tcp ports:

# ftp:
Accept     If protocol is TCP and destination port is 20
# ftp:
Accept     If protocol is TCP and destination port is 21
# ftp:
Accept     If protocol is TCP and destination port is 22
# http:
Accept     If protocol is TCP and destination port is 80
# https:
Accept     If protocol is TCP and destination port is 443
# mysql:
Accept     If protocol is TCP and destination port is 3128
# proftpd passive ports:
Accept     If protocol is TCP and destination port is 6000 to 7000
# webmin:
Accept     If protocol is TCP and destination port is 10000
# default reject rest:
Reject     Always

Install ftp client program

Login to server from local ssh.

apt-get install ftp

This can be used from the ssh command line to access files on other systems. Note that ftp is not considered a safe protocol but it is convenient. sftp might be a better option.

Install ProFTPD server

Use webmin from local browser.

Select left side menu "Un-used Modules" then "ProFTPD Server"

You will be notified that it was not found on server and asked to install it.

By default, the system user file (etc/passwd) identifies permitted users. It is possible to create a separate ftp only login. See the proftpd documentation. Be aware that files written to the VPS by outsiders using ftp logins will have owners identified by their ftp user id since they don't exist in /etc/passwd.

After installation configure as follows for insecure transfers:

• create a new virtual server with handle all connections to 111.222.333.444 and address your-domain-name.

• in networking options change PASV port range to be 6000 - 7000 to match the firewall specification.

• edit the /etc/proftpd/proftpd.conf file to add this line near the bottom of the file after other configurations files:

  Include /etc/proftpd/modules.conf

• edit the /etc/proftpd/modules.conf file to add this line above the comment "# keep this module the last one:

  # allow use of MLSD/MLST commands
  LoadModule mod_facts.c
  

Restart the proftpd server from webmin.

Install Lets Encrypt certificates

Preliminary

Following activities require operating as superuser.

Login using ssh to root.

If the Lets Encrypt certbot utility is not installed:

apt-get install certbot

Ensure the web server is running before starting this procedure.

In the web server configuration file, temporarily disable any virtual host instruction to require TLS or to enforce hostname redirection to www.your-domain.

In Hiawatha, these configuration instructions should be made into comments:

• EnforceFirstHostname = yes # should be applied ONLY if www.--- and no www.--- are defined
• RequireTLS = yes, 2678400; includeSubDomains # applies to all sub-domains

If these entries are still active the LetsEncrypt certbot will fail.

Restart the web server.

systemctl restart <your server start name>

Ensure there are DNS records in the Linode Manager for all intended domains and sub-domains.

Renew Existing Certificates

After the above restart of the web server, it is possible to trigger a renewal action with this command:

certbot renew

If there are certificates within 30 days of expiry they will be renewed. NOTE: this does not perform the extra steps to cat the private key and certificate chain which are described below.

Multiple Domain Certificates

Note that the following command includes multiple domains and the webroot for each must exactly match what is in the web server configuration file. Here is a sample:

certbot certonly --webroot \
-w /mnt/library -d lib.<domain-1> \
-w /home/<user-a>/doc/site -d doc.<domain-1> \
-w /home/<user-b>/www/site -d internal.<domain-2> \

If new sub-domain virtual servers are created then the above list will need additions. The last in the list is used as a default for some purpose by letsencrypt so you should insert new domains above the last one.

Upon success, the certificate files will be linked in:

/etc/letsencrypt/live/<domain-2>

The links in this sub-directory point to real files in the sub-directory

/etc/letsencrypt/archive/<domain-2>

BUT hiawatha requires that both private key and certificates be in a single file. Other web servers accept separate files.

cd /etc/letsencrypt/archive/<domain-2>

Note the trailing digit increments with each renewal:

cat privkey1.pem fullchain1.pem >everything1.pem

cd /etc/letsencrypt/live/domain-2>

ln --symbolic ../../archive/<domain-2>/everything1.pem everything.pem

Enable the SSL/TLS section in web server configuration file. For hiawatha, this is done as follows:

nano /etc/hiawatha/hiawatha.conf

Binding {
        Port = 443
#       TLScertFile = tls/hiawatha.pem
        TLScertFile = /etc/letsencrypt/live/<domain-2>.com/everything.pem
#       Interface = 127.0.0.1
}

This becomes the default certificate. In the section below for some virtual domain(s), another certificate might be obtained and configured in its sub-domains.

Save changes.

Specific Domain Certificate

Repeat the above steps with a different set of domains:

certbot certonly --webroot \
-w /home/<some-user>/uat/site -d uat.<domain-3> \
-w /home/<some-user>/www/site -d <domain-3> -d www.<domain-3>

Upon success, the certificate files will be linked in:

/etc/letsencrypt/live/<domain-3>

The links in this sub-directory point to real files in the sub-directory

/etc/letsencrypt/archive/<domain-3>

BUT hiawatha requires that both private key and certificates be in a single file.

cd /etc/letsencrypt/archive/www.<domain-3>

Note the trailing digit increments with each renewal:

cat privkey1.pem fullchain1.pem >everything1.pem

cd /etc/letsencrypt/live/www.<domain-3>

ln --symbolic ../../archive/www.<domain-3>/everything1.pem everything.pem

Enable use of the correct certificate for these domains. For <domain-3> virtual host sub-domains specified in the certificate in web server configuration file:

TLScertFile = /etc/letsencrypt/live/www.<domain-3>/everything.pem

Save changes.

Revert Configuration Changes and Restart The Web Server

Remove commenting action on the following configuration entries for each virtual host. For hiawatha the following apply:

• EnforceFirstHostname = yes # should be applied ONLY if www.--- and no www.--- are defined
• RequireTLS = yes, 2678400; includeSubDomains # applies to all sub-domains

Restart the server:

systemctl restart hiawatha

Ensure hiawatha will start at reboot. Verify the systemd service is installed as part of the apt-get install for hiawatha. Look in the webmin - system tab for the entry "hiawatha.service" and confirm that it is flagged for start on boot. Or test it by clearing your browser cache and loading one of the domain pages.

Configure Webmin to use new SSL certificate

Login to webmin as root.

Select the left side menu Webmin and the sub-menu Webmin Configuration.

Select the SSL encryption link.

Change the Private key file entry to:

/etc/letsencrypt/live/<your-domain>/everything.pem

Change the Certificate file entry to:

Same file as private key

Save changes.

Return to the Webmin Configuration page and restart webmin.

Note: webmin must be restarted after every certificate renewal since it runs as a daemon and only loads the certificate at start-up.

Install Fossil source code management software

Use browser to determine current version of fossil then:

Login using ssh to root.

mkdir ~/local
cd ~/local

Using the current version numbers at time of download:

wget http://www.fossil-scm.org/index.html/uv/fossil-linux-x64-2.6.tar.gz
tar -xvf fossil-linux-x64-2.6.tar.gz

A single file (fossil) will be extracted from the zipped file. Now move it to its working location:

mv fossil /usr/local/bin/

Using Fossil server mode on the VPS

It is most convenient to run fossil as a server using the CGI method, with a bash script in the (sub-)domain root directory pointing to the relevant directory containing the repositories. This method permits using separate repository directories for different (sub-)domains.

The bash script contents is described in the fossil documents.

Here is a sample:

#!/usr/local/bin/fossil
directory: /home/<some-user>/repos
notfound: http://url-to-go-to-if-repo-not-found/
repolist

Make sure the bash script is executable and that your web server permits execution of scripts in the root directory. You can also configure your web server to execute scripts from another directory, typically ../cgi.

The bash script is accessed from your web browser using a URL like:

https://<your-domain-name>/library.cgi/<repo-name>

Using this URL without the final repo-name but including the final slash will present a list of all repositories in the repos directory.

--- End text ---

There's a delete moderation request pending but I don't know where it is? artifact [d26535aea3]

A user without WrTrusted capability posted something and then deleted it before it was approved by a moderator, so now it doesn't show up in anyone's view of this thread, even that of moderators, so now we can't Reject it.

I've tried hand-constructing a URL to the forum that would Reject this post, but it fails on two separate grounds:

1. It requires a POST, not a GET, so I can't use a browser to construct and execute the URL.

2. If I switch to something like curl, which can POST, it's missing my login cookie, and then if you fix that, it runs into the CSRF protections.

I thought I'd have a go at making such posts still appear for moderators, but I lack a test case, since non-approved forum posts use the same mechanism as private branches, so they don't sync, which means I'd have to be doing such testing on fossil-scm.org itself.

It might be simplest to just have drh or someone else with permission on that server to do hand-surgery on the tables via SQL.

Interesting test case the non-moderator user created for us. How would this be handled in the code so that it doesn't happen?

Per drh's request above, have you sent in a contributor agreement so you can check this in as a new document within the Fossil source tree? While we can link to the forum post from server.wiki, this updated posting of yours is worth distributing with Fossil directly.

Hello wyoung:

Sorry, but I did not consider drh's statement to be an instruction to submit a contributor agreement and thus did not do so. In a private email exchange, drh said:

My intent right now (subject to change, of course) is to use your notes as a baseline to put together a series of documentation pages on the main Fossil website that provide a checklist for setting up a developer website. My intent is for this to be a series of web pages, with each page addressing a specific topic. Hyperlinks allow for easy navigation. A high-level checklist at the top of the hierarchy guides the user to setting up their own site.

To the extent that the text is a usable contribution, then I suggest you copy/paraphrase and adapt to suit, without attribution. It is a relatively trivial contribution to fantastic pieces of software (sqlite3/fossil) and attaching my name to it is not relevant.

Small update: I am migrating to Debian 10 and sSMTP is no longer included in the distribution due to its lack of a maintainer and absence of TLS handling. The nullmailer package serves a similar purpose and I use it now for programmed outbound emails. There is additional help for configuring it at troubleshooters.com.

To enable TLS, the /etc/nullmailer/remotes file needs a couple of extra command line parameters:

your-relay.com --port=587 --starttls --user=yourname@address --password xxxxxxxx

where your-relay.com, user name and password are changed as applicable.

I don't want to arm-twist you into signing the contributor agreement, but I think the linked post from drh above is a pretty clear indication that such a contribution wouldn't be rejected.

Regarding the idea of multiple related documents, the Certbot folks have the same basic problem, and their solution is a pair of drop-down boxes on their home page that causes that page to link you to the doc that covers that particular combination of host OS and front-end software.

For Fossil, I think the initial set of choices should be:

1. Host OS: Windows, Ubuntu/Debian, RHEL family, and at least one BSD

2. Proxy: none, althttpd, nginx, Apache

That's 16 potential combinations, which is plenty of work to start with.

I've left macOS out of the host OS choice because I don't think many people are running Fossil servers on macOS. Clients, yes, lots, but servers? And of those that do, I think they can adapt the Linux or BSD instructions to suit.

There are lots of Linux and BSD flavors we could cover, but I think we can leave that to later authors to expand on the basic initial set of 16 docs. The same goes for all of the proxying options I haven't listed: lighttpd, IIS, haproxy...

The matter of Fossil server operating mode — CGI, SCGI, SSH, or HTTP — we can leave to the author of the article. They can cover as many modes as they like. For example, in my nginx + TLS document I have a section that explains that I'm purposefully covering only SCGI. There's no good reason to cover the other three modes beyond my argument rejecting them for this particular purpose, so I don't.

HTTP mode (fossil server) has complexities (e.g. chroot mode) but I think we can factor that out to other docs like the top-level server.wiki doc. We don't need repeated coverage of those details in the coverage of the individual host + proxy docs.

TLS should be also factored out of each article. The initial 16 articles should talk about the plain HTTP case only, then link you to a suitable TLS guide for that host + proxy combo for those that want it. Those links can go to the Certbot docs where we don't have Fossil-specific docs.

With all of the above in place, several of the existing docs get broken up and rearranged. For example, my ngnx + TLS doc splits into two, a new one covering the "Ubuntu/Debian + nginx" parts under plain HTTP, leaving only the TLS info behind in the current doc, with the first linking to the second.

How about the URL scheme? I'm not wild about continuing to add docs to the www/ level, so how about we create the hierarchy implied by the 4x4 matrix of initial choices?

  www/server/ubuntu/direct.md
  www/server/ubuntu/nginx.md
  www/server/ubuntu/apache.md
  www/server/ubuntu/althttpd.md
  www/server/windows/direct.md
  etc...

I don't see that this removes any existing www/*.{wiki,md} files. Some info in them may be copied or moved into these new docs, but existing external links shouldn't be broken with this scheme.

I should have some initial documentation ready to go for the case of Windows bare fossil + stunnel this week.

Back in the Fossil 1.34 days I spent a week trying to get Fossil and IIS to cooperate. I couldn't do it. Fossil + stunnel is working really well for me right now.

I'm more than happy to use the suggested structure, and I even have the base Windows Fossil as a Service documentation written as part of the stunnel doc.

Thanks.

In case anyone stumbles on this too... The now-current link is https://fossil-scm.org/fossil/doc/trunk/www/server/

The step-by-step recipe in the thread below is also instructive with its detail.