I’ve run into this before, but have always been able to get it to work since I have always run the daemon and the web server on the same server, so the default localhost:58846 worked fine. However, I just setup my web server on a separate host from the daemon and could not get auto connect to work no matter what I tried. After some digging and looking at the actual Python code, I finally discovered how this works.
In the web.conf configuration file for the Deluge Web server, there is a line for “default_daemon” which can specify the default daemon. However, everyone on the web says to put the hostname:port here of the daemon you want to connect to. This is not correct. The value here is expected to be the host ID of the configured daemon. However, this info is not provided anywhere in the UI. After a little more digging I finally found the info needed.
Where the web.conf file resides, there is also a file called hostlist.conf.1.2. This file contains all of the configured daemons for the web server. Each host configured in this file should have a long string of characters as the first line in each definition. Here’s an example from my setup: "hosts": [
"a460f75d27562b0317a22b3e2600bd23e1fedb16", <- This is what you need
Now, make sure that your deluge web server daemon is shut down then edit the web.conf file and paste that host ID into the double quotes after “default_daemon”. Now start your deluge web service and it should automatically connect to the specified daemon.
Whether your an IT Pro or just an average computer user, you are most likely familiar with something called DNS. You have likely gotten an error message in your browser indicating a DNS lookup failed, or have read an article mentioning DNS, or even had a computer technician walk you through verifying your computer’s DNS settings. If you are in IT, then you have most likely even encountered DNS in troubleshooting or while setting up a website or email server. After reading this post, you’ll have at least a good understanding of DNS, what it is, how it works, why it is important, and why things can break so easily when there is a DNS problem.
Just minutes ago I had a client forward me a copy of an email that they had just received. The email looked like a standard email that you receive when someone shares a Google Doc with you. The email was from an @gmail.com address. It contained a link to “Open in Docs” and the link was legitimate. When clicking on the link, the following page was displayed:
I recently upgraded two of my CentOS 6 VMs to CentOS 7.3. Both of these utilized ZFS. I installed ZFS using the repos from zfsonlinux.com as I have always done. I do always use the kmod version since I’ve had issues with the dkms version in the past when performing updates. I got my zpools imported just fine, but noticed that after rebooting that I would have to re-import them again. I started investigating this and eventually discovered such a simple solution.
So you have a Sophos UTM device and want to setup dynamic DNS using your Google Domain? Sophos UTM offers a couple of built-in services for DynDNS, but Google Domains is not one of them. There are quite a few guides out there for hacking the UTM so that you can get this functionality, but they all seem to require creating a custom configuration file and then either manually starting the service at each boot, scheduling it to run, or something similar. Continue reading →