[tw5] Use TiddlyWiki on a dedicated Linux root server

Google Group (Read Only)
#1

Hi @all,

Is there a possibility to use TiddlyWiki on my dedicated Linux root server (Ubuntu 20.04 LTS)?
If possible I would love it to have access to the wiki from everywhere and can also make it available for other users.

It would also be good to have two different access possibilities.
So for example when you open the link to the wiki you can only read the entries of the wiki.
And the other possibility would be to log in, then you can edit the entries, create new entries and so on…
And maybe it is possible not to make all entries of the wiki visible to all users, so for example make some entries invisible unless you are logged in.

Can anybody tell me if this is possible and - if yes - how I can realize this?

Best regards
heusmich

#2

Hi,
IMO it depends on the orchestration environment that you use or want to use.

Everything is possible. … BUT the main concern will be security.

-m

#3

Hi Heusmich,

I think a first option could be to serve a tiddlywiki file via WebDav : not only it can give access to the wiki from anywhere on your network, but it will also handle the saver operations without any further configuration. There are many WebDav services available for the Linux platform, but Rclone is probably one of the most easy to use, yet very powerful.

So a basic, unsecure, command for serving a TiddlyWiki file that resides in your ~/public_html/wikis repository with Rclone (let’s call it mywiki.html) would be:

rclone serve webdav ~/public_html/wikis/ --addr 0.0.0.0:8998

That’s it! As you guessed, it will make all the files present in ~/public_html/wikis/ available at the port 8998 on your Linux machine. So if your server has the IP address 192.168.1.3 on your network, pointing a browser to http://192.168.1.3:8998/mywiki.html will serve the file mywiki.html on HTTP, and write any modifications directly on the same file.

As Mario noted, such a simple setup means that you must really trust your network. Even if you are the only person who uses it, some applications running on your other machines can easily discover your WebDav service, and do whatever with your wiki file.

The next step would thus be to add an authentication file with htpasswd. The command “htpasswd -cB .myhtpasswd.txt me” would ask you a password for the user me, then create the file .myhtpasswd.txt with that password encrypted.

Now you can reissue a slightly more secure command:

rclone serve webdav ~/public_html/wikis --htpasswd ~/.myhtpasswd.txt --addr 0.0.0.0:8998

Each time someone wants to connect to http://192.168.1.3:8998, (s)he will be asked for their credentials. But if an application is sniffing your network, it will see the password as you type it.

The next step would thus be to add a key and a certificate so that rclone serves through HTTPS instead of HTTP. https://tiddlywiki.com/#Using%20HTTPS explains how to generate the key and the self-signed certificate.

Once you have the cert and the key file, you can enhance the above command by issuing:

rclone serve webdav ~/public_html/wikis --htpasswd ~/.myhtpasswd.txt --addr 0.0.0.0:8998 --cert ~/.tls/server.crt --key ~/.tls/key.pem

This is more reasonable, although you’ll notice that your browser complains that the certificate is self-signed.

Now you are ready to try a different approach, that is serving your wiki through NodeJS. See the two tiddlers at https://tiddlywiki.com/#WebServer:%5B%5BInstalling%20TiddlyWiki%20on%20Node.js%5D%5D%20WebServer

Regards,

2 Likes
#4

If you did this, could you access your file from outside your network – assuming that you know your network ip number? Or would network firewalls block it ?

#5

Hi Mark,

Yes you can, provided that your gateway/router holds a rule that redirects access. Let’s say your gateway’s address is 185.199.111.153. Your internet provider makes it usually easy to add a NAT rule saying that for instance any access on port 8999 should be redirected to the host 192.168.1.3, port 8998. From now on, using our example, requesting the page https://185.199.111.153:8999/mywiki.html from outside your local network will access your wiki.

Please folks, don’t try that before both your HTTPS and htpasswd credentials are set up.

#6

Hi Xavier,

One question. I did the first two steps of your guide, so far it´s OK and working.

But I have one problem. I connect via Putty to the server and start the WebDav with the command you provided. But as soon as I close Putty or press CTRL + C, the wiki is not reachable anymore.
CTRL + A, CTRL + D like in Screen doesn´t work.

Is it somehow possible to keep the WebDav open even when I close Putty?

Best regards
heusmich

#7

IMO https:// only makes it hard for others to watch your connection and make sense of it.

It doesn’t add anything to the security settings of the server itself. If the server keeps all outside connections open, the server itself is highly vulnerable. I’d recommend, that a firewall closes all “windows and doors” for incoming connections. … Except those, that you intend to use.

If you start rclone with --addr 0.0.0.0 it will listen to every IP address that can reach it. I think it should only listen to an IP that it knows and trusts.

just some thoughts.
-mario

#8

Hi heusmisch,

Indeed, “detaching from the console” after having issued a remote command is a common need in networking. What you want is

  1. making sure your command is run in the background. An ‘&’ at the end of the command line will do the trick.

  2. making sure it is detached from the shell you are using, so that it doesn’t get killed when you close the shell. You express this by wrapping your command with the nohup (aka No Hang Up) command.

So,

nohup rclone serve webdav ~/public_html/wikis --htpasswd ~/.myhtpasswd.txt --addr 0.0.0.0:8998 &

The next question is “what if I want to kill this command, now that it is detached ?”

You’ll first need to know the process identifier. pgrep is handy for that: you give it a pattern to recognise the initial command, like so:

pgrep -f webdav

and it will respond with the process identifiers of all the commands that contain the string webdav. You can then kill the command with:

kill <my_process_id>

Best,
Xavier.

2 Likes
#9

Hi Xavier,

Thanks again for that detailed guide. I really appreciate it.

But I have two more questions:

  1. How exactly can I secure the address of the wiki with a certificate? For my personal homepage I did this via “Let´s Encrypt”, but until now I didn´t find a way to do it for the wiki address.
    In the guide that I used for securing my homepage I used the certbot to generate the certificate from “Let´s Encrypt”, but when I try to use it for the wiki address, it doesn´t work.
    It only shows the addresses of my website name.

Currently the address of my wiki looks like the following:
http://:8998/empty.html

Can you tell me what exactly I have to do to generate a certificate for the wiki?

  1. What do I have to do to save the changes directly in the folder on the server? When I do some changes in the wiki and click on save, it always wants to download a file, but the wiki should save the changes on the server directly.
    Doesn´t make sense to download a file with the changes, I want to save them directly on the server to have the online wiki up to date.

Sorry that I ask so many questions, but I love this wiki, in my opinion it´s the best.
But I can´t get some things working by myself… :frowning:

#10

Hi heusmisch,

Regarding your second question, the fact that direct saving doesn’t work probably means that you don’t serve your file with WebDav but standard HTTP. If you don’t use rclone, you need another tool that can serve through the WebDav protocol.

Regarding your first question, I’m afraid I won’t be able to help you further. Linux and networking is a field in itself that goes far beyond the topic of TiddlyWiki. I gave you some recipes that work in the very limited context that I tried to describe, but if you depart from it, chances are that it won’t work…

#11

Hi Xavier,

thanks for your fast answer.
OK, then I will check again if I can get it working somehow.
If not, I will check if there will be another possibility to make it available via browser.

So thanks again for all your help, have a nice weekend!
:smiley:

Best regards
heusmich