After downloading the new 8.0.5 update, it forced me into a WebUI. To be fair I’ve been wanting a WebUI for quite some time now, but didn’t expect it to be so forced and sudden. Anyway, all my downloads are now gone and I don’t know how to restore them. Also, how do I connect to the WebUI from other devices? Every time I try to connect it says unable to connect. It works fine in my browser window on the machine running Tribler though. But first and foremost I need to know if there’s still a way to convert the old downloads I had into this new UI or if they’re gone forever.
1 Like
OK, my downloads have all been restored, now I want to figure out if there’s a way to connect to the WebUI from other devices, e.g. on a LAN network, so I could use Ubuntu Server instead of Ubuntu Desktop for better performance. I want to figure out how to 1. make it use the same port every time 2. start it from the command line 3. open it up for other devices to connect to it
How you have restored downloads?
I honestly don’t know. I went into settings >> versions, then clicked 7.14 and clicked import. I waited a bit but it seemed like it wasn’t doing anything. In frustration, I closed the Web UI and left my computer running (because I have other stuff running on it other than Tribler). At the end of the day, I shut it off and when I turned it on the next day, everything was there. My guess is it either takes a really long time for everything to import into the new version, or the web ui has some sort of bug that prevents it from working correctly until the entire importing process is done. Either way, it seems to be working fine now, I guess I just had to give it some time.
Hey @davidgordiienko, the change you’re looking for is not in the WebUI, rather in the configuration.json file 
For me on linux, this is ~/.Tribler/8.0/configuration.json
The field looks like this:
{
"api":
"http_enabled": true,
"http_port": 46807,
"http_host": "<enter new IP address here>",
...
}
Also, you’d want to launch Tribler as so
/usr/share/tribler/tribler --server
Otherwise it will crash on a headless system
Full disclosure from my testing, there appears to be some local cookie Tribler passes to the browser it calls. Connecting from external hosts produces this error:
(post deleted by author)
You need to add ?key(insert api key from configuration.json here) at the end of the URL so it would be something like [your IP and port]/ui/#/downloads/all?key=[your key]
I have some questions about running it the headless way
- How do you stop it
- If using SSH, do you need to keep the terminal window open/how to make it so that you don’t have to keep it open
- Is there a way to make it not output as much/as often or clean it up a bit/less verbose?
Hi Sachiko
below is a configuration with Apache reverse-proxy:
RewriteEngine on
RewriteRule "^/$" "/ui/#/downloads/all?key=YOUR_KEY" [QSA,P]
Header set Set-Cookie "api_key=YOUR_KEY"
ProxyPass http://127.0.0.1:8085/
ProxyPassReverse http://127.0.0.1:8085/
Here i use Apache => local Tribler in docker
If anyone can find a lighter configuration, I’d love to hear from you.
1 Like
Maybe you should create an independent thread to ask your questions davidgordiienko.
As said above I use docker, and I don’t have to worry about Tribler screen output.
For point 1, I have opened a new thread to get an answer to the question. For now, I accept the process kill given the infrequency of shutdown calls I make.
Tribler can be run without first opening a terminal by creating a user (or global) systemd unit. For user systemd units, it requires:
sudo loginctl enable-linger <user>
The other advantage of a systemd unit is that the logging gets written to journald, and you’d have an easier time filtering it there
1 Like
Hi everyone
Due to the lack of documentation, perhaps we should create a tutorial here bringing together all the info on how to get Tribler headless working properly with or without docker?
Maybe a tutorial category in the forum would be useful?
https://forum.tribler.org/t/how-to-run-tribler-entirely-through-cli/7340/3
Once I am able to verify the systemd unit works as expected. I’d be happy to contribute. The main blocker is the API key requirement when connecting externally. While suitable for a docker container (particularly with a Dockerfile), getting apache installed and configured outside of that introduces complexity not only for us, but also Windows users (although you could argue they’re unlikely to require something like this). One of there two options would be preferable from the Tribler team.
- Treat blank API key as equal to disabling authentication; or;
- Create auth_method key, defaulting to ‘cookie’, also accepting ‘basicauth’ + http_user & http_password