Stubby-Installer-Asuswrt-Merlin

[Adamm]

When I enable round robin in the .yml using value "1" and enable the other cloudflare servers it breaks stubby. That is if I un-comment the servers for cloudflare, and change round robin value to 1 this happens. When I run stubby restart command it fails to start.

I do not believe I modified previous stubby functionality so I assume this would have been the case using the old script. @Jack Yaz might be able to chip in here.

Would be great to have the changes in in a format a person could understand without being a programmer.

I'm not sure how I can list these changes in any clearer of a format. I literally describe each commit's contents in detail which is a much better summary then me trying to remember the combined details of 29 commits off the top of my head and the thousands of changes big and small.

And what if a user does not want haveged?

Haveged is highly recommended with stubby (as shown by the recent entropy flaw) and even included with Johns fork by default.

No, I disagree. You should have your script tested by others.

Edit: So one of the testers is having issues. Please pull your update back!

The update was tested. Please take the time to read the information provided before complaining.

 

[bbunge]

I do not believe I modified previous stubby functionality so I assume this would have been the case using the old script. @Jack Yaz might be able to chip in here.



I'm not sure how I can list these changes in any clearer of a format. I literally describe each commit's contents in detail which is a much better summary then me trying to remember the combined details of 29 commits off the top of my head and the thousands of changes big and small.

Haveged is highly recommended with stubby (as shown by the recent entropy flaw) and even included with Johns fork by default.




The update was tested. Please take the time to read the information provided before complaining.

Not complaining, just stating a fact. Your testing apparently did not cover all the options in stubby.yml or Skeal would not have had issues when he went to roundrobin.
What works for you may not work for others.
I run without haveged quite well and plan to ask John how to disable it in his fork as I have two AC68U's running John's fork. I am not convinced it is necessary.
Both John and Eric go through extensive testing with feedback from experienced users and noobs. I learned the hard way back in the days of DOS (remember that OS?) that new installs have to be tested by the least experienced user as the nerds can overlook and fix problems on-the-fly. And there are plenty of noobs.

 

[Odkrys]

I am not convinced it is necessary.

https://github.com/getdnsapi/getdns/issues/409#issuecomment-450657514

haveged makes entropy don't drop under 1024.

 

[Adamm]

Not complaining, just stating a fact. Your testing apparently did not cover all the options in stubby.yml or Skeal would not have had issues when he went to roundrobin.

Most changes are related to the installer script its-self so a wide testing pool was not necessary.

I do not believe I modified previous stubby functionality so I assume this would have been the case using the old script.

If you do not agree with the changes on this fork, you are more then welcome to continue using the outdated official version in the OP, I am not holding a gun to your head. Otherwise please respond with constructive feedback and report any actual issues caused by this update specifically.

 

[dave14305]

When I enable round robin in the .yml using value "1" and enable the other cloudflare servers it breaks stubby. That is if I un-comment the servers for cloudflare, and change round robin value to 1 this happens. When I run stubby restart command it fails to start.

Why don't you post your stubby.yml contents? Sounds like maybe you commented or uncommented too much or too little?

 

[skeal]

Why don't you post your stubby.yml contents? Sounds like maybe you commented or uncommented too much or too little?

Removed comment"#" from in front of the two lines for 1.0.0.1, made it look exactly as the above Stubby configured server. I do know how to remove a comment. As stated I enabled round robin as I had it before, change the "0" value to "1". Save the changes and restart stubby, stubby shuts down but fails to start. Shows red "failed".

 

[dave14305]

Removed comment"#" from in front of the two lines for 1.0.0.1, made it look exactly as the above Stubby configured server. I do know how to remove a comment. As stated I enabled round robin as I had it before, change the "0" value to "1". Save the changes and restart stubby, stubby shuts down but fails to start. Shows red "failed".

How about running

stubby -i -C /opt/etc/stubby/stubby.yml

to check the config syntax?

 

[preacher65]

Removed comment"#" from in front of the two lines for 1.0.0.1, made it look exactly as the above Stubby configured server. I do know how to remove a comment. As stated I enabled round robin as I had it before, change the "0" value to "1". Save the changes and restart stubby, stubby shuts down but fails to start. Shows red "failed".

I normally only use 1.1.1.1, but I tried the same thing here after updating and reading the thread, just to test it - uncommented the 1.0.0.1 entry and changed the round robin setting to 1. Restarted Stubby and it worked here, no errors and the check says it's alive. I wonder what's different about our setups? I'm on the AC86U, don't know how much difference that would make.

I'm assuming I did it correctly but yml excerpts are below.

Spoiler

round_robin_upstreams: 1

# Cloudflare Primary IPv4
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
# Cloudflare Secondary IPv4
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"

I can see both resolver addresses via ip_conntrack after the change so I assume it's worked, not sure if that's the best way to check though.

 

[owine]

Removed comment"#" from in front of the two lines for 1.0.0.1, made it look exactly as the above Stubby configured server. I do know how to remove a comment. As stated I enabled round robin as I had it before, change the "0" value to "1". Save the changes and restart stubby, stubby shuts down but fails to start. Shows red "failed".

I had weird issues with the stubby config file not loading. I ended up going through and retyping all leading spaces/tabs which bizarrely fixed it. Seems stubby is sensitive on the config front in my experience. This had nothing to do with what options were set and I did not have to change anything other than retyping the config for it to work.

 

[skeal]

How about running

stubby -i -C /opt/etc/stubby/stubby.yml

to check the config syntax?

Figured it out. If you enable the second ipv6 server, it breaks stubby. Not sure why yet.

 

[preacher65]

Figured it out. If you enable the second ipv6 server, it breaks stubby. Not sure why yet.

Ah, good catch, I don't use ipv6 so didn't enable the secondary server. I think there's an extra leading space in the lines for the 2nd ipv6 server, if I remove those it starts okay, which matches with @owine's comment above about the sensitivity to formatting in the config file. I think it might date back to this commit.

 

[bbunge]

OK, so I broke down and installed Adamm's script on a fresh USB formatted to EXT2 and fresh Entware install. Switched to both CF servers roundrobin, no issues. Switched to CleanBrowsing Security without DNSSEC, no problems. RT-AC66U_B1 Merlin 384.8_2 IPV4 only.

One recommendation is to include proxy-dnssec in dnsmasq.conf.add

 

[john9527]

One recommendation is to include proxy-dnssec in dnsmasq.conf.add

Another FYI....also automatically done in my fork with stubby enabled and you are not using dnsmasq's dnssec support.

 

[owine]

Figured it out. If you enable the second ipv6 server, it breaks stubby. Not sure why yet.

Ah, good catch, I don't use ipv6 so didn't enable the secondary server. I think there's an extra leading space in the lines for the 2nd ipv6 server, if I remove those it starts okay, which matches with @owine's comment above about the sensitivity to formatting in the config file. I think it might date back to this commit.

I am using a manual stubby/Entware setup, not via the installer although I did take the .yml from the installer prior to the recent changes. I have two IPv4 and two IPv6 servers and it runs fine. The spacing issue really was the issue for me.

 

[skeal]

I had weird issues with the stubby config file not loading. I ended up going through and retyping all leading spaces/tabs which bizarrely fixed it. Seems stubby is sensitive on the config front in my experience. This had nothing to do with what options were set and I did not have to change anything other than retyping the config for it to work.

Bingo!! I basically aligned the text to existing and boom it works. Like you said redo the spaces and tabs.

 

[Jack Yaz]

Bingo!! I basically aligned the text to existing and boom it works. Like you said redo the spaces and tabs.

Fixed: https://github.com/jackyaz/Stubby-I...mmit/1ce8126351745f9a4e58cf22a60f5e0f39116433

 

[skeal]

Fixed: https://github.com/jackyaz/Stubby-I...mmit/1ce8126351745f9a4e58cf22a60f5e0f39116433

Nice one Jack!!

 

[dave14305]

Bingo!! I basically aligned the text to existing and boom it works. Like you said redo the spaces and tabs.

Seemed crazy, but sure enough, this is referenced in the stubby repo:

# Also beware that yaml is sensitive to the indentation at the start of each
# line so if you encounter errors when parsing the config file then please check
# that. We will add better checking but a useful online tool to check yaml
# format is here (it also converts yaml to json)
# https://yaml-online-parser.appspot.com/

https://github.com/getdnsapi/stubby/blob/develop/stubby.yml.example

 

[Jack Yaz]

Thanks @Adamm for the rework

 

[Jack Yaz]

No, I disagree. You should have your script tested by others.

Edit: So one of the testers is having issues. Please pull your update back!

This kind of attitude is unwarranted. Support will be provided by myself and others as and when issues are reported. I apologise that my day job prevented me from responding sooner to investigate the issue. The spacing issue @skeal encountered likely always existed, but was not discovered until it was uncommented in the config file. Nonetheless, I have fixed the issue for future new installers.

And what if a user does not want haveged?

haveged can be removed if you so wish

opkg remove haveged

It is better to keep it, however.