tetrapod

Members
  • Posts

    46
  • Joined

  • Last visited

Everything posted by tetrapod

  1. Ok, so I'm preparing to convert my daily driver to Unriad and took the time to test the rig with NTP problems with a fresh config. With the new (default 6.9.2) config NTP works just fine. Ntpd will correct a clock that is off promptly. Going back to my old config and I'm back to the exact same problem. So, the problem is not HW it seems - it's my config... ๐Ÿ˜ treebeard-diagnostics-20210601-1047.zip
  2. No problem, I'm fumbling around here also :-$ And take my rumblings with a grain of salt. I have no truth claims here at all. My knowledge profile is probably an outlier here. I have been on IT leave for 20 years when raising kids which means I know Unix and some networking, but are really lost when it comes to the actual apps. Ok, you have one PIA VPN tunnel set up on your router, but only certain WAN IPs and/or services are using that tunnel? Do you have VPN enabled in the container? If you have, and it's configured correctly, you will have a VPN tunnel from that container to your VPN provider. As I see it it wouldn't make any difference what so ever if you open a port on your access router. Your actual WAN address is not known to deluge, only the WAN address on your VPN exit point. If the external IP address in deluge is the same as your actual access router WAN address there is something wrong as I see it, or you do not have VPN configured in the container?
  3. Maybe I missunderstand what you mean or I don't understand how this container work, but why would NAT on your router have anything to do with this container? The VPN function of the container punch a hole through the router, to the service you use on the outside. The resulting VPN tunnel have all ports open until some of them are closed by the iptables stuff configured within the container. Because the session is initiated from the LAN side of your router there is no need to configure any port forwarding rules - right? Edit: I now see further up that you made a reference to open ports in connection with ipleak.net. Correct me if I'm wrong, but I think you made the test with the magnet link in the torrent client inside the container and looking for leakage in the ipleak.net interface - right? In that case the web browser isn't using the the same VPN as the container and wouldn't show the right information. If your browser use the same VPN tunnel as the container I would like to know how you set that up. Would be a handy test for me to.
  4. The distinction between VPN_INPUT and OUTPUT wasn't clear to me either, and I'm still not sure I understand this correctly :-$ But, what I empirically understood was that, at first when I only had jackett routed through delugevpn, I only needed to define input ports so that I could reach the jacket GUI. At that point I didn't need any defined output ports. Then, when I added nzbhydra to the mix, I kinda worked also with only adding the the vpn input port. But, for nzbhydra to work as intended nzbhydra also need access to the arrs (and not only the other way around) and that did not work until I added the arrs' ports to VPN_OUTPUT_PORTS. That made sens to me, and is how I now understand it. The VPN part of the variable name is actually confusing. It has nothing to do with the vpn function of the container. As I understand it the INPUT ports are where you define access to the containers on the binhex-delugevpn "net". The OUTPUT variable is where you define the ports that containers on the binhex-delugevpn "net" needs access to. I hope that helped.
  5. Thank you for caring! No, the socket error went away when I changed NTP servers. Regarding the test with a temp licens, I will try that when I have a good amount of time. I have never done anything like that befor and is a little hesitant. I'm afraid to F something up :-$
  6. Well, it doesn't help as such, but it definitely points to a difference. I think that points out that your server calculate a drift of a little over 10 PPM and will use that to adjust your clock. My system on the other hand does, according to syslog, notice that that the clock is wrong, but the drift is calculated to 0 (zero). If it is this that that makes the system not set the clock I don't know? I can see that ntpd is started with "-g" so ntpd should be able to do the initial clock adjustment even if if the first jump is over the sanity value (1000s?) I can see that if I make changes to Unraid, [Settings], [Date and Time] the values ends up in /etc/ntp.conf. Here is my configuration: root@treebeard:/boot/config# cat /etc/ntp.conf # Sample /etc/ntp.conf: Configuration file for ntpd. # # Undisciplined Local Clock. This is a fake driver intended for backup # and when no outside source of synchronized time is available. The # default stratum is usually 3, but in this case we elect to use stratum # 0. Since the server line does not have the prefer keyword, this driver # is never used for synchronization, unless no other other # synchronization source is available. In case the local host is # controlled by some external source, such as an external oscillator or # another protocol, the prefer keyword would cause the local host to # disregard all other synchronization sources, unless the kernel # modifications are in use and declare an unsynchronized condition. # server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 # # NTP server (list one or more) to synchronize with: #server 0.pool.ntp.org iburst #server 1.pool.ntp.org iburst #server 2.pool.ntp.org iburst #server 3.pool.ntp.org iburst # # Full path of a directory where statistics files should be created # statsdir /var/lib/ntp/stats # # Location of an alternate log file to be used instead of the default system syslog(3) facility # #logfile /var/log/ntp # # Drift file. Put this in a directory which the daemon can write to. # No symbolic links allowed, either, since the daemon updates the file # by creating a temporary in the same directory and then rename()'ing # it to the file. # driftfile /var/lib/ntp/drift # # Location of PID file # pidfile /var/run/ntpd.pid # # Uncomment to use a multicast NTP server on the local subnet: #multicastclient 224.0.1.1 # listen on default 224.0.1.1 # Set an optional compensation for broadcast packet delay: #broadcastdelay 0.008 # # Keys file. If you want to diddle your server at run time, make a # keys file (mode 640 owned by root:ntp) and define the key number to # be used for making requests. # PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote # systems might be able to reset your clock at will. # #keysdir /etc #keys /etc/ntp.keys #trustedkey 65535 #requestkey 65535 #controlkey 65535 # # Don't serve time or stats to anyone else by default (more secure) restrict default limited kod nomodify notrap nopeer noquery restrict -6 default limited kod nomodify notrap nopeer noquery # # Use these lines instead if you do want to serve time and stats to # other machines on the network: #restrict default limited kod nomodify notrap nopeer #restrict -6 default limited kod nomodify notrap nopeer # # Trust ourselves. :-) restrict 127.0.0.1 restrict ::1 # Generated entries follow: interface ignore wildcard interface listen bond0 server 0.pool.ntp.org iburst server 1.pool.ntp.org iburst server 2.pool.ntp.org iburst server 3.pool.ntp.org iburst I can see that now /var/lib/ntp/drift have disappeared again have ended up as /boot/config/drift with the same timestamp as the file created an hour after ntpd restart yesterday. root@treebeard:/var/lib/ntp# ls -l /boot/config/drift -rw------- 1 root root 6 May 11 10:24 /boot/config/drift root@treebeard:/var/lib/ntp# ls -l /var/lib/ntp/ total 0 Don't know what to do? I can set the time manually, but I would like to know what the problem is.
  7. Ahh, ok, I read you as you had made a customization. That seems to bee correct root@treebeard:/boot/config# ls -l /boot/config/drift -rw------- 1 root root 6 May 7 10:45 /boot/config/drift root@treebeard:/boot/config# ls -l /var/lib/ntp/drift -rw-r--r-- 1 ntp ntp 6 May 7 16:58 /var/lib/ntp/drift ntpd service restart - checking syslog root@treebeard:/boot/config# cat /var/log/syslog |grep ntpd May 11 09:24:49 treebeard emhttpd: shcmd (682): /etc/rc.d/rc.ntpd stop May 11 09:24:49 treebeard ntpd[16360]: ntpd exiting on signal 1 (Hangup) May 11 09:24:49 treebeard ntpd[16360]: 127.127.1.0 local addr 127.0.0.1 -> <null> May 11 09:24:48 treebeard emhttpd: shcmd (688): /etc/rc.d/rc.ntpd restart May 11 09:24:49 treebeard ntpd[6699]: ntpd 4.2.8p15@1.3728-o Tue Oct 20 18:42:21 UTC 2020 (1): Starting May 11 09:24:49 treebeard ntpd[6699]: Command line: /usr/sbin/ntpd -g -u ntp:ntp May 11 09:24:49 treebeard ntpd[6699]: ---------------------------------------------------- May 11 09:24:49 treebeard ntpd[6699]: ntp-4 is maintained by Network Time Foundation, May 11 09:24:49 treebeard ntpd[6699]: Inc. (NTF), a non-profit 501(c)(3) public-benefit May 11 09:24:49 treebeard ntpd[6699]: corporation. Support and training for ntp-4 are May 11 09:24:49 treebeard ntpd[6699]: available at https://www.nwtime.org/support May 11 09:24:49 treebeard ntpd[6699]: ---------------------------------------------------- May 11 09:24:49 treebeard ntpd[6701]: proto: precision = 0.040 usec (-24) May 11 09:24:49 treebeard ntpd[6701]: basedate set to 2020-10-08 May 11 09:24:49 treebeard ntpd[6701]: gps base set to 2020-10-11 (week 2127) May 11 09:24:49 treebeard ntpd[6701]: Listen normally on 0 lo 127.0.0.1:123 May 11 09:24:49 treebeard ntpd[6701]: Listen normally on 1 lo [::1]:123 May 11 09:24:49 treebeard ntpd[6701]: Listening on routing socket on fd #18 for interface updates May 11 09:24:49 treebeard ntpd[6701]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized May 11 09:24:49 treebeard ntpd[6701]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized May 11 09:24:49 treebeard root: Starting NTP daemon: /usr/sbin/ntpd -g -u ntp:ntp Certainly seem like the /boot/config/drift is overwritten with the /var/lib/ntp/drift from before restart root@treebeard:/boot/config# ls -l /boot/config/drift -rw------- 1 root root 6 May 7 16:58 /boot/config/drift root@treebeard:/boot/config# ls -l /var/lib/ntp/drift /bin/ls: cannot access '/var/lib/ntp/drift': No such file or directory The drift file in all instances is "0.000" Checking in on syslog again, and getting the usual one time ntpd confirming clock unsynchronized. root@treebeard:/boot/config# tail -3 /var/log/syslog May 11 09:24:49 treebeard ntpd[6701]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized May 11 09:24:49 treebeard root: Starting NTP daemon: /usr/sbin/ntpd -g -u ntp:ntp May 11 09:35:30 treebeard ntpd[6701]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized After an hour I'll get a new drift file root@treebeard:/boot/config# ls -l /var/lib/ntp/drift -rw-r--r-- 1 ntp ntp 6 May 11 10:24 /var/lib/ntp/drift ...nothing more in syslog and the file is still "0.000"
  8. By giving the example "emby.mydomain.com" I guess that he ha set up Swag to work with subdomains? What service have you used to point mydomain.com to your WAN address? I think we need a little more information on how you have set this up to be able to give good advice. You should not need to give a port number in the URL ("synology.mydomain.com:5000"). You either need a nginx subdomain config file configured for you synology server pointing to that resource (<synologyLAN-IP>:5000) or you skip Swag and let you NAT point port 5000 to your synology. But, again, there are a lot ways to skin this cat. Depends on what you are trying to accomplish @tvd1.
  9. Thank you for answering (Y) So does that mean that you have changed /etc/ntp.conf to point to your drift file? And does it mean that /var/lib/ntp/drift and /var/lib/ntp/stats would be overwritten at a reboot (if they exists)? And yet again, does your server write /var/lib/ntp/drift and /var/lib/ntp/stats and just wanted to change the behavior, or do you not get those files either?
  10. I know, there isn't much, and I see that I fucked up the servers I had chosen when sending my config. I had tried so many. And yes, getting rid of the wrong one did help with the syslog messages - thank you. But, ntpd still don't set the time? With servers set to the four suggested I have stopped/started the service and stopped/started the server. Originally the server was ca. 10 minutes ahead and I waited 24 hours. It never changed a second. Then I thought that maybe the gap is to wide, but I see that ntpd is started with -g so it should work? Anyway, I changed it manually by stopping the demon and setting time manually in the GUI, this time to one minute behind local time. Started service again, but it still doesn't move the clock a second - I waited another 24 hours. Syslog confirm that ntpd see that the clock isn't synchronized, but doesn't set the time root@treebeard:/etc# cat /var/log/syslog |grep ntpd May 7 09:45:38 treebeard ntpd[2362]: ntpd 4.2.8p15@1.3728-o Tue Oct 20 18:42:21 UTC 2020 (1): Starting May 7 09:45:38 treebeard ntpd[2362]: Command line: /usr/sbin/ntpd -g -u ntp:ntp May 7 09:45:38 treebeard ntpd[2362]: ---------------------------------------------------- May 7 09:45:38 treebeard ntpd[2362]: ntp-4 is maintained by Network Time Foundation, May 7 09:45:38 treebeard ntpd[2362]: Inc. (NTF), a non-profit 501(c)(3) public-benefit May 7 09:45:38 treebeard ntpd[2362]: corporation. Support and training for ntp-4 are May 7 09:45:38 treebeard ntpd[2362]: available at https://www.nwtime.org/support May 7 09:45:38 treebeard ntpd[2362]: ---------------------------------------------------- May 7 09:45:38 treebeard ntpd[2364]: proto: precision = 0.080 usec (-23) May 7 09:45:38 treebeard ntpd[2364]: basedate set to 2020-10-08 May 7 09:45:38 treebeard ntpd[2364]: gps base set to 2020-10-11 (week 2127) May 7 09:45:38 treebeard ntpd[2364]: Listen normally on 0 lo 127.0.0.1:123 May 7 09:45:38 treebeard ntpd[2364]: Listen normally on 1 lo [::1]:123 May 7 09:45:38 treebeard ntpd[2364]: Listening on routing socket on fd #18 for interface updates May 7 09:45:38 treebeard ntpd[2364]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized May 7 09:45:38 treebeard ntpd[2364]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized May 7 09:56:19 treebeard ntpd[2364]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized May 7 16:01:28 treebeard emhttpd: shcmd (123): /etc/rc.d/rc.ntpd stop May 7 16:01:28 treebeard ntpd[2364]: ntpd exiting on signal 1 (Hangup) May 7 16:01:28 treebeard ntpd[2364]: 127.127.1.0 local addr 127.0.0.1 -> <null> May 7 16:01:58 treebeard emhttpd: shcmd (129): /etc/rc.d/rc.ntpd restart May 7 16:01:59 treebeard ntpd[8760]: ntpd 4.2.8p15@1.3728-o Tue Oct 20 18:42:21 UTC 2020 (1): Starting May 7 16:01:59 treebeard ntpd[8760]: Command line: /usr/sbin/ntpd -g -u ntp:ntp May 7 16:01:59 treebeard ntpd[8760]: ---------------------------------------------------- May 7 16:01:59 treebeard ntpd[8760]: ntp-4 is maintained by Network Time Foundation, May 7 16:01:59 treebeard ntpd[8760]: Inc. (NTF), a non-profit 501(c)(3) public-benefit May 7 16:01:59 treebeard ntpd[8760]: corporation. Support and training for ntp-4 are May 7 16:01:59 treebeard ntpd[8760]: available at https://www.nwtime.org/support May 7 16:01:59 treebeard ntpd[8760]: ---------------------------------------------------- May 7 16:01:59 treebeard ntpd[8762]: proto: precision = 0.030 usec (-25) May 7 16:01:59 treebeard ntpd[8762]: basedate set to 2020-10-08 May 7 16:01:59 treebeard ntpd[8762]: gps base set to 2020-10-11 (week 2127) May 7 16:01:59 treebeard ntpd[8762]: Listen normally on 0 lo 127.0.0.1:123 May 7 16:01:59 treebeard ntpd[8762]: Listen normally on 1 lo [::1]:123 May 7 16:01:59 treebeard ntpd[8762]: Listening on routing socket on fd #18 for interface updates May 7 16:01:59 treebeard ntpd[8762]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized May 7 16:01:59 treebeard ntpd[8762]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized May 7 16:01:59 treebeard root: Starting NTP daemon: /usr/sbin/ntpd -g -u ntp:ntp May 7 16:06:36 treebeard emhttpd: shcmd (133): /etc/rc.d/rc.ntpd stop May 7 16:06:36 treebeard ntpd[8762]: ntpd exiting on signal 1 (Hangup) May 7 16:06:36 treebeard ntpd[8762]: 127.127.1.0 local addr 127.0.0.1 -> <null> May 7 15:58:55 treebeard emhttpd: shcmd (140): /etc/rc.d/rc.ntpd restart May 7 15:58:56 treebeard ntpd[16358]: ntpd 4.2.8p15@1.3728-o Tue Oct 20 18:42:21 UTC 2020 (1): Starting May 7 15:58:56 treebeard ntpd[16358]: Command line: /usr/sbin/ntpd -g -u ntp:ntp May 7 15:58:56 treebeard ntpd[16358]: ---------------------------------------------------- May 7 15:58:56 treebeard ntpd[16358]: ntp-4 is maintained by Network Time Foundation, May 7 15:58:56 treebeard ntpd[16358]: Inc. (NTF), a non-profit 501(c)(3) public-benefit May 7 15:58:56 treebeard ntpd[16358]: corporation. Support and training for ntp-4 are May 7 15:58:56 treebeard ntpd[16358]: available at https://www.nwtime.org/support May 7 15:58:56 treebeard ntpd[16358]: ---------------------------------------------------- May 7 15:58:56 treebeard ntpd[16360]: proto: precision = 0.040 usec (-24) May 7 15:58:56 treebeard ntpd[16360]: basedate set to 2020-10-08 May 7 15:58:56 treebeard ntpd[16360]: gps base set to 2020-10-11 (week 2127) May 7 15:58:56 treebeard ntpd[16360]: Listen normally on 0 lo 127.0.0.1:123 May 7 15:58:56 treebeard ntpd[16360]: Listen normally on 1 lo [::1]:123 May 7 15:58:56 treebeard ntpd[16360]: Listening on routing socket on fd #18 for interface updates May 7 15:58:56 treebeard ntpd[16360]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized May 7 15:58:56 treebeard ntpd[16360]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized May 7 15:58:56 treebeard root: Starting NTP daemon: /usr/sbin/ntpd -g -u ntp:ntp May 7 16:09:37 treebeard ntpd[16360]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized I see no files created for configured drift or stats (driftfile /var/lib/ntp/drift, statsdir /var/lib/ntp/stats) Any ideas?
  11. Got an answer from @ados in another thread. ...and this container show deluge as being om 2.0.4? Now, I have never handled plugins for Deluge befor so it could very well be me who is doing something stupid (again). There the plugin is, but I can't Enable it and I do not know how to remove it.
  12. Ok, just my 5 cents here, because I'm no expert at this. But, shouldn't the Deluge port be added to VPN_INPUT? And, I don't think that you should have the same port in VPN_output - I'm sure that is adding confusion See my config here: Now, I don't have the same setup as you, but before I got NZBHydra added I only had Jacket routed through Deluge and Jacket do not need to access to any containers (except Deluge), it's just the arrs that need access to Jacket. Configured like that I didn't need any port configured for VPN_OUTPUT When I added NZBHydra, that container needed access to the arrs and then I had to add these ports in VPN_OUTPUT I hope that can help a little.
  13. I had the same issue and I think, if I remember correctly, that Spaceinwader's video didn't mention that you had to turn of proxy for the subdomain CNAME record. Maybe this worked differently before at Cloudflare? But when I turn on "proxied" for any CNAME that URL will no longer point to my server, it will point to a cloudflare server. How this proxy via Cloudflare is supposed to work I do not know. I can keep "proxied" on for my A records though
  14. 90% of my syslog is ntpd. I get this every 5 minutes: May 6 15:12:34 treebeard ntpd[27360]: bind(19) AF_INET 127.0.0.1#123 flags 0x5 failed: Address already in use May 6 15:12:34 treebeard ntpd[27360]: unable to create socket on lo (3628) for 127.0.0.1#123 May 6 15:12:34 treebeard ntpd[27360]: failed to init interface for address 127.0.0.1 May 6 15:12:34 treebeard ntpd[27360]: bind(19) AF_INET6 ::1#123 flags 0x5 failed: Address already in use May 6 15:12:34 treebeard ntpd[27360]: unable to create socket on lo (3629) for ::1#123 May 6 15:12:34 treebeard ntpd[27360]: failed to init interface for address ::1 I must have fucked something up :-$
  15. No problem with time buddy. I'm just glad to get answers and still trying to figure out where to best ask the questions. I think my knowledge profile is an outlier in this home server arena and a lot of the time the answers I get are just over my head, or my questions are not understood at all and are ignored. But, I'm starting to understand enough to help other people - that feels good. I think I need the "include". How would nginx know where to go for authentication other vice? Yeah I have included the auth_request in all the subdomain config files. Need the granularity for different authentication levels.
  16. I'm using about the same setup, but I'm only routing Jacket and NZBHydra through binhex-delugevpn. Are you sure you haven't switched which ports go where for the VPN ports? My config is this: Maybe It's me who got it wrong :-$ but I don't think so. Works fine between the dockers and Jacket and NZBHydra are accessing through the deluge VPN. There is no longer a WebUI alternative when clicking the docker, but that is not to be expected
  17. Also posted this to Organizr thread Having problems with getting organizr to communicate with deluge docker (using binhex-delugevpn). I have followed the instructions and downloaded the egg file WebAPI-0.4.0-py3.7.egg for Deluge. Renamed it WebAPI-0.4.0-py3.9.egg and installed it. I can however not tick the box to enable the plugin and I'm getting API Error (no. 2) when testing the connection from Organizr. I also can not find out how to remove the plugin from Deluge to start over again ๐Ÿ˜ Is this something I can not do in this container?
  18. I have been going the same route and had some problems. Did you configure these ports in the binhex-delugevpn container config? I missed this and was struggling until I had read and fully understood Q24-27 in binhex exelent guide: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md
  19. Well, yes, but probably no. NGINX seems to be a trustworthy product used by many big companies. It's more that I do not trust my knowledge about security to rely on my server setup and configuration of NGINX :-$ I can see that is working, but I have no idea if it's secure. I'm now using Organizr as an authenticating wall in front of nginx. Your writeup helped me understand the concept, but I'm using Swag so I had to figure some of config out by myself (because I can't use NGINX Proxy Manager as a GUI to nginx in the Swag container - right?). I still think I'm missing something here because it works great accessing/blocking all my container GUIs from WAN, except for the Ombi app. I'd guess that is because the app have no way of authenticating itself to Organizr. But, does that mean I have to leave it out of Organizer authentication all together, or is there a way to let the Ombi API through and still protect the GUI? Maybe you can point me in the right direction @ados?
  20. I have been going the same route and had some problems. Did you configure these ports in the binhex-delugevpn container config? I missed this and was struggling until I had read and fully understood Q24-27 in binhex exelent guide: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md
  21. Having problems with getting organizr to communicate with deluge docker (using binhex-delugevpn). I have followed the instructions and downloaded the egg file WebAPI-0.4.0-py3.7.egg. Renamed it WebAPI-0.4.0-py3.9.egg and installed it. I can however not tick the box for enable and getting API Error (no. 2) when testing the connection. All the other configured arrs and media apps works great. Looks beautiful ๐Ÿค˜ I also can not find out how to remove the plugin to start over again ๐Ÿ˜
  22. @ados intro in the write-up above convinced me to try Organizr and it's now running. It looks beautiful and is so flexible. Heimdall is deleted forever and you are now on my beer supply list. My last step resulted in a problem though and I question my understanding. I run Organizer in a docker on Unraid 6.9.2. My services are reverse proxied (swag) with subdomain setup. My problem started when I started with authentication via Organizer. Worked brilliant as I wanted with different groups, level, on/off LAN access. Everything as I wanted until I came to Ombi. Now, Ombi access works fine in browser, but not the mobile app and I guess that is because it can't authenticate through Organizer and it's here that I question my understanding when I configure nginx. Following https://docs.organizr.app/books/setup-features/page/serverauth#bkmrk-swag%2Fletsencrypt-doc I have: added and edited the /config/nginx/proxy-confs/organizr-auth.subfolder.conf file edited all /config/nginx/proxy-confs/*.subdomain.conf files by adding this in the first location block: include /config/nginx/proxy-confs/organizr-auth.subfolder.conf; auth_request /auth-4; I have only added the above in the first location block even if the config file have more location blocks and it seems to work, but is this correct? The next section (Subdomain and How to include the authorization block in a reverse proxy) in the instruction I don't understand. I though I was using subdomains and reverse proxy, but it seems to work any way? What am I missing and is there a way to get the Ombi app to work or should I just exclude that from authentication?
  23. Yes, this was on the VM. Sorry if that was unclear. root@treebeard:/etc/rc.d# ping time1.google.com PING time1.google.com (216.239.35.0) 56(84) bytes of data. 64 bytes from time1.google.com (216.239.35.0): icmp_seq=1 ttl=109 time=27.1 ms 64 bytes from time1.google.com (216.239.35.0): icmp_seq=2 ttl=109 time=27.7 ms 64 bytes from time1.google.com (216.239.35.0): icmp_seq=3 ttl=109 time=27.7 ms 64 bytes from time1.google.com (216.239.35.0): icmp_seq=4 ttl=109 time=27.3 ms ^C --- time1.google.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 27.074/27.427/27.650/0.240 ms root@treebeard:/etc/rc.d# ./rc.ntpd restart Stopping NTP daemon... Starting NTP daemon: /usr/sbin/ntpd -g -u ntp:ntp root@treebeard:/etc/rc.d# tail -50 /var/lo local/ lock/ log/ root@treebeard:/etc/rc.d# tail -50 /var/log/syslog Apr 30 15:45:08 treebeard ntpd[29429]: ntpd exiting on signal 1 (Hangup) Apr 30 15:45:09 treebeard ntpd[27358]: ntpd 4.2.8p15@1.3728-o Tue Oct 20 18:42:21 UTC 2020 (1): Starting Apr 30 15:45:09 treebeard ntpd[27358]: Command line: /usr/sbin/ntpd -g -u ntp:ntp Apr 30 15:45:09 treebeard ntpd[27358]: ---------------------------------------------------- Apr 30 15:45:09 treebeard ntpd[27358]: ntp-4 is maintained by Network Time Foundation, Apr 30 15:45:09 treebeard ntpd[27358]: Inc. (NTF), a non-profit 501(c)(3) public-benefit Apr 30 15:45:09 treebeard ntpd[27358]: corporation. Support and training for ntp-4 are Apr 30 15:45:09 treebeard ntpd[27358]: available at https://www.nwtime.org/support Apr 30 15:45:09 treebeard ntpd[27358]: ---------------------------------------------------- Apr 30 15:45:09 treebeard ntpd[27360]: proto: precision = 0.040 usec (-24) Apr 30 15:45:09 treebeard ntpd[27360]: basedate set to 2020-10-08 Apr 30 15:45:09 treebeard ntpd[27360]: gps base set to 2020-10-11 (week 2127) Apr 30 15:45:09 treebeard ntpd[27360]: bind(16) AF_INET 127.0.0.1#123 flags 0x5 failed: Address already in use Apr 30 15:45:09 treebeard ntpd[27360]: unable to create socket on lo (0) for 127.0.0.1#123 Apr 30 15:45:09 treebeard ntpd[27360]: failed to init interface for address 127.0.0.1 Apr 30 15:45:09 treebeard ntpd[27360]: bind(16) AF_INET6 ::1#123 flags 0x5 failed: Address already in use Apr 30 15:45:09 treebeard ntpd[27360]: unable to create socket on lo (1) for ::1#123 Apr 30 15:45:09 treebeard ntpd[27360]: failed to init interface for address ::1 Apr 30 15:45:09 treebeard ntpd[27360]: Listening on routing socket on fd #16 for interface updates Apr 30 15:45:09 treebeard ntpd[27360]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized Apr 30 15:45:09 treebeard ntpd[27360]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized Apr 30 15:45:11 treebeard ntpd[27360]: bind(19) AF_INET 127.0.0.1#123 flags 0x5 failed: Address already in use Apr 30 15:45:11 treebeard ntpd[27360]: unable to create socket on lo (2) for 127.0.0.1#123 Apr 30 15:45:11 treebeard ntpd[27360]: failed to init interface for address 127.0.0.1 Apr 30 15:45:11 treebeard ntpd[27360]: bind(19) AF_INET6 ::1#123 flags 0x5 failed: Address already in use Apr 30 15:45:11 treebeard ntpd[27360]: unable to create socket on lo (3) for ::1#123 Apr 30 15:45:11 treebeard ntpd[27360]: failed to init interface for address ::1 Thanks for the help so far ๐Ÿ‘
  24. Perfect! Thank you. Here it is. treebeard-diagnostics-20210430-1429.zip