HowTo setup Local DNS/DHCP Plugin

    • OMV 1.0
    • wolffstarr wrote:

      not sure if it really matters but it lets you match the CNAME and the primary name, so if hostname is 'foobar' and you put additionals as 'foobar' it takes it with no issues
      That was one place where there isn't much error checking. You can also put the same name in for the cname over and over (foobar, foobar, foobar). And when it does a check for uniqueness of the cnames, it doesn't break the string apart to see if there is duplicates. It just checks the whole string. I guess it wouldn't be hard to see if the name is the cnames field. Trying to avoid implementing the cnames check though :D

      Let me know what you find about the segfaulting and I will try to fix that.
      omv 5.3.4 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.2.5
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • Still tracking down what it is that makes the difference here, but here's the output of systemctl status dnsmasq.service immediately after running omv-mkconf dnsmasq:

      Source Code

      1. root@rsquared:~/dnsmasq# systemctl status dnsmasq
      2. ● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
      3. Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled)
      4. Drop-In: /run/systemd/generator/dnsmasq.service.d
      5. └─50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf
      6. Active: failed (Result: signal) since Mon 2017-01-16 10:01:38 EST; 449ms ago
      7. Process: 18734 ExecStop=/etc/init.d/dnsmasq systemd-stop-resolvconf (code=exited, status=0/SUCCESS)
      8. Process: 18663 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/SUCCESS)
      9. Process: 18657 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
      10. Process: 18653 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
      11. Main PID: 18662 (code=killed, signal=SEGV)
      12. Jan 16 10:01:36 rsquared dnsmasq-dhcp[18662]: DHCP, IP range 10.40.0.10 -- 10.40.0.254, lease time 12h
      13. Jan 16 10:01:36 rsquared dnsmasq-dhcp[18662]: DHCP, IP range 10.30.0.100 -- 10.30.0.200, lease time infinite
      14. Jan 16 10:01:36 rsquared dnsmasq-dhcp[18662]: DHCP, IP range 10.20.0.100 -- 10.20.0.150, lease time 7d
      15. Jan 16 10:01:36 rsquared dnsmasq-dhcp[18662]: DHCP, IP range 10.25.1.100 -- 10.25.1.150, lease time 7d
      16. Jan 16 10:01:36 rsquared dnsmasq-tftp[18662]: TFTP root is /var/lib/tftp
      17. Jan 16 10:01:36 rsquared dnsmasq[18662]: using local addresses only for domain shadowmatrix.org
      18. Jan 16 10:01:36 rsquared dnsmasq[18662]: no servers found in /var/run/dnsmasq/resolv.conf, will retry
      19. Jan 16 10:01:37 rsquared systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.
      20. Jan 16 10:01:37 rsquared systemd[1]: dnsmasq.service: main process exited, code=killed, status=11/SEGV
      21. Jan 16 10:01:38 rsquared systemd[1]: Unit dnsmasq.service entered failed state.
      22. root@rsquared:~/dnsmasq#
      Display All
      At this point I've narrowed it down to something in /etc/dnsmasq.d/omv.conf, but I still can't place what. Running a diff on the two files, the only things that are actively different are the CNAME entries - everything else is configured identically, and most of the CNAME stuff is just the order it's running in.
    • ryecoaaron wrote:

      That was one place where there isn't much error checking. You can also put the same name in for the cname over and over (foobar, foobar, foobar). And when it does a check for uniqueness of the cnames, it doesn't break the string apart to see if there is duplicates. It just checks the whole string. I guess it wouldn't be hard to see if the name is the cnames field. Trying to avoid implementing the cnames check though :D
      Let me know what you find about the segfaulting and I will try to fix that.

      Okay, I'm at a total loss on the segfault. Something is really bizarre here, and it's specifically to do with the CNAME stuff. As I said, the problem file is /etc/dnsmasq.d/omv.conf, and when I compare the two files (old one, directly stolen from my original OMV 2.x install by the way, and new one generated by omv-mkconf dnsmasq) everything except for the CNAMEs is identical; most of the CNAMEs are just in different order.

      On the off chance I'd flubbed something I went through the list looking for malformed CNAME entries, and didn't find any. I also manually added a CNAME entry to the one static item that didn't have one (from the first report I made) in case that was it, and it didn't make a difference.

      Next, I deleted about 2/3s of the CNAME entries, tried again and still no dice. Regenerated the config with omv-mkconf, deleted the third of the entries I'd left previously and left the 2/3s I'd deleted, no change. Deleted all the CNAME entries entirely and it started right up. I also checked for weird whitespace and didn't find any in the generated config.

      Here's where it gets weird. I regenerated the config again, inserted all the CNAME entries from my old 2.x omv.conf file, and deleted all the entries that omv-mkconf generated... and it works. I'm completely baffled by it. The other thing is, when I do a diff on the old file with the new file after changing the CNAME entries to match, the only differences are extra blank lines between sections in the old file that aren't there in the new.

      As far as I can tell there's really almost no difference between the generated CNAME entries (beyond their specific content, but they're formed the same way) and the ones from the old 2.x file. Same whitespace (that is, none) per line, same formatting, just... one works, the other doesn't.

      If you want me to try something else, I gladly will. I need to check but I think I have an image of the entire OMV 2.x SD card (that install was on the same RPi) so I can probably even dig out the 2.x config.xml section for comparison if you need it.
    • Random thought. I don't recall when, in the middle of all this, that I uploaded openmediavault-dnsmasq 3.1.2, but I uploaded through the update management interface as opposed to uninstalling 3.1.1 and reinstalling 3.1.2. Is it possible that might be causing this CNAME mess? Because 3.1.2 also was causing a socket error (see below) when I tried to login to the web UI. I'm reinstalling it now to see if that fixes the issue, but an apt-get purge openmediavault-dnsmasq allowed me to login to the web UI with no other changes.

      EDIT: Alright, purged 3.1.2 like I said, cleared the 3.1.2 .deb out of the cache, re-uploaded 3.1.1, reinstalled it through the web UI, and the CNAME issue is still there. However, I'm not getting the socket error, so there's that. Wish I had better news on the segfault, but...

      Socket error:

      Source Code

      1. Error
      2. Failed to connect to socket: No such file or directory
      3. Error #0:
      4. exception 'OMV\Rpc\Exception' with message 'Failed to connect to socket: No such file or directory' in /usr/share/php/openmediavault/rpc/rpc.inc:138
      5. Stack trace:
      6. #0 /var/www/openmediavault/rpc/session.inc(56): OMV\Rpc\Rpc::call('UserMgmt', 'authUser', Array, Array, 2, true)
      7. #1 [internal function]: OMVRpcServiceSession->login(Array, Array)
      8. #2 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array(Array, Array)
      9. #3 /usr/share/php/openmediavault/rpc/rpc.inc(84): OMV\Rpc\ServiceAbstract->callMethod('login', Array, Array)
      10. #4 /usr/share/php/openmediavault/rpc/proxy/json.inc(95): OMV\Rpc\Rpc::call('Session', 'login', Array, Array, 3)
      11. #5 /var/www/openmediavault/rpc.php(45): OMV\Rpc\Proxy\Json->handle()
      12. #6 {main}
      13. OK
      14. Hide details
      Display All

      The post was edited 1 time, last by wolffstarr ().

    • Weird. The config file creation (omv-mkconf dnsmasq) hasn't changed since OMV 2.x (other than using variable for config and adding newline flag for xmlstarlet version difference).

      The engined error was a typo in my new code. Fixed in 3.1.3 I would install it from the command line just in case.
      omv 5.3.4 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.2.5
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      Weird. The config file creation (omv-mkconf dnsmasq) hasn't changed since OMV 2.x (other than using variable for config and adding newline flag for xmlstarlet version difference).

      The engined error was a typo in my new code. Fixed in 3.1.3 I would install it from the command line just in case.
      That's the other odd thing too, it didn't happen at once. From what I can tell, when you add a Static Entry, after each one it goes, updates the config.xml, then regenerates the config, yes? I'm 99% positive that it was working for at least the first few entries, because I tested it (mostly because I got tired of remembering to type IPs instead of hostnames) and was able to access hosts via web browser.

      I can go in and clear the XML entries one at a time to see if I can figure out what happened once my daughter's in bed.
    • wolffstarr wrote:

      From what I can tell, when you add a Static Entry, after each one it goes, updates the config.xml, then regenerates the config, yes?
      I just noticed that I never finished porting the function that is executed after each new entry is added. So, I think it may be hup'ing the process instead of restarting it. Let me look at that in a little bit.
      omv 5.3.4 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.2.5
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • wolffstarr wrote:

      I can go in and clear the XML entries one at a time to see if I can figure out what happened once my daughter's in bed.
      Would it be bad to just reload dnsmasq each time an entry is added/edited? It would still be restarted when a setting was changed.
      omv 5.3.4 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.2.5
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      wolffstarr wrote:

      I can go in and clear the XML entries one at a time to see if I can figure out what happened once my daughter's in bed.
      Would it be bad to just reload dnsmasq each time an entry is added/edited? It would still be restarted when a setting was changed.

      Reload configs as opposed to restart you mean? Would make a lot of sense to me.

      Work was a pain in the ass today so I haven't even had a chance to try 3.1.3 yet for you; I'm also beating my head against a Pi Zero setup for a RetroPie that my wife wanted me to try setting up, so once I get that to stop being a bitch, I should be able to poke at it.
    • So, to report on the changes to date. For one, I decided to be a rebel without a clue and updated to 3.1.3 by uploading through the Update Management screen and doing an upgrade. Worked flawlessly, no errors on web UI or SSH (which may or may not have been related to the 3.1.2 issue).

      Went into the Static Entries tab, created a test entry with no CNAME and a bogus IP address (for my network, at least) and clicked Save; UI threw an error indicating that the systemctl restart dnsmasq.service command had failed, referring me to journalctl -xn and so on. Not sure on the order of operations, but since it was restarting to apply, I would say that means the CNAME issue is resolved as well.

      For the Static Entries thing with reload vs. restart, is there any particular reason (including "massive rewrite not worth heartburn") we can't have the entries generate an Apply prompt like changes to the Settings tab causes? It's of limited utility overall - the only time you're really going to mass-update is when you're setting up or adding a new clutch of VMs or something somewhere - but adding hosts vpn0 through vpn9 when I set up OpenVPN on my EdgeRouter so I didn't have to wait for SSH to time out on DNS requests was on the tedious end.

      I did get a chance to go into my old 2.x image that the original config files came from and I can't see anything at all different between the entries in /etc/openmediavault/config.xml between the two versions. Also, you mentioned the possibility that it's HUPing instead of restarting for some reason, but the problem occurs when I manually do systemctl start dnsmasq.service with the 3.x generated /etc/dnsmasq.d/omv.conf in place, but the 2.x generated loads fine.

      The only thing that I'm seeing anywhere different - and I didn't mention it because replacing the file in question didn't change anything - is that the etc/dnsmasq-hosts file now has three spaces, instead of one tab, separating the IP and the hostname. Can't see why that'd make a difference, but it's the only oddity I've come across that I didn't mention. Whether it's spaces or tabs in that file, it still fails to start with 3.x's omv.conf, and starts right up with 2.x's omv.conf. Permissions and ownership are the same on both files.
    • wolffstarr wrote:

      For the Static Entries thing with reload vs. restart, is there any particular reason (including "massive rewrite not worth heartburn") we can't have the entries generate an Apply prompt like changes to the Settings tab causes?
      If we use the Apply prompt, dnsmasq would have to be restarted and could not be reloaded -OR- dnsmasq would have to be reloaded when settings changed. Doesn't bother me which one but I would guess dnsmasq needs to be restarted when settings are changed.

      wolffstarr wrote:

      you mentioned the possibility that it's HUPing instead of restarting for some reason
      I noticed the Debian 8 systemd unit file HUPs the process when reloading. So, that shouldn't be the issue either.

      wolffstarr wrote:

      is that the etc/dnsmasq-hosts file now has three spaces, instead of one tab, separating the IP and the hostname
      This must be a difference in the new version of xmlstarlet on Debian 8? Not sure.

      wolffstarr wrote:

      it still fails to start with 3.x's omv.conf, and starts right up with 2.x's omv.conf
      All I can think is that it is a difference between dnsmasq 2.62 on Debian 7 and dnsmasq 2.72 on Debian 8. Probably means the config file format needs to be changed but I don't know what to change.
      omv 5.3.4 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.2.5
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      If we use the Apply prompt, dnsmasq would have to be restarted and could not be reloaded -OR- dnsmasq would have to be reloaded when settings changed. Doesn't bother me which one but I would guess dnsmasq needs to be restarted when settings are changed.
      I would say go with Apply and do a restart. Honestly, at the moment you're waiting on the restart for every entry, so only having one wait for more than one entry would run smoother IMO.

      ryecoaaron wrote:

      This must be a difference in the new version of xmlstarlet on Debian 8? Not sure.
      Maybe, but since it's not breaking anything that I can tell, probably not worth tracking down. Just mentioned it for completeness' sake.

      ryecoaaron wrote:

      All I can think is that it is a difference between dnsmasq 2.62 on Debian 7 and dnsmasq 2.72 on Debian 8. Probably means the config file format needs to be changed but I don't know what to change.
      I don't see how, since I'm using a dnsmasq 2.62 omv.conf file as the one that works, and the configs generated seem to be identical.

      Here's the CNAME config for my Cisco access point from the old OMV 2.x file:

      Source Code

      1. cname=ap,argos
      2. cname=ap.shadowmatrix.org,argos.shadowmatrix.org


      Here's the same entry in the OMV 3.x generated file:


      Source Code

      1. cname=ap,argos
      2. cname=ap.shadowmatrix.org,argos.shadowmatrix.org

      Like I said, there's no difference even in terms of whitespace.

      I'm going to attach the two configs (omv.conf.old is from Wheezy, omv.conf.new is the problematic one from Jessie) for you to reference if you'd like. Meanwhile, I'm going to manually wipe the CNAME entries out and see if I can get DNSMasq to load without them, then start adding them and testing as I go to see if I can identify something specific.
      Files
    • FOUND IT!

      We can thank 3.1.1 for this one. In order to get the entire house up and running as quickly as possible, since it wouldn't let me leave blank CNAME entries, I was just coming up with something at random for the first few, then I decided I was just going to put in the A record hostname as a CNAME. So when I went to put in the IPMI entry for my primary fileserver, I did that - in this case "ipmi-korval" for both hostname and CNAME. I was re-entering without them, when it sort of hit me over the head that this was a potential bad thing. Tried doing it again, after the save it was dead with the segfault just like before. Edited the static entry to remove the CNAME, and after the save dnsmasq was running again.

      So, at heart it looks like a bug (feature? I could see it being intentional but you'd think it'd log something about it) in dnsmasq itself. You could maybe-possibly put a check in to reject a CNAME that matches the hostname, but that'd be a bandaid and now that 3.1.3 works fine with the blank CNAMEs, it shouldn't come up.

      Sorry to drive you batty on this man, but it sure feels good to figure out what was going on. Guess I'll wander on over to the dnsmasq folks and see if that's a reported bug.

      Let me know if there's anything else you need me to test and I'll get to it as soon as I can.
    • wolffstarr wrote:

      Let me know if there's anything else you need me to test and I'll get to it as soon as I can.
      Do you think I should change the code to restart when a new entry is added then?
      omv 5.3.4 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.2.5
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      wolffstarr wrote:

      Let me know if there's anything else you need me to test and I'll get to it as soon as I can.
      Do you think I should change the code to restart when a new entry is added then?
      Honestly, I think going the Apply route and doing a restart then would both be more uniform from a UI perspective, and less clunky feeling when adding multiple entries.

      Of course, I've added a lot of static entries in the past week, so that may be looming larger in my mind than it otherwise might, but I do remember wondering why it was different back when I first started using it.
    • wolffstarr wrote:

      think going the Apply route and doing a restart then would both be more uniform from a UI perspective, and less clunky feeling when adding multiple entries.
      I agree with that. Does dnsmasq "lose" dynamic dhcp leases when it is restarted?
      omv 5.3.4 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.2.5
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      wolffstarr wrote:

      think going the Apply route and doing a restart then would both be more uniform from a UI perspective, and less clunky feeling when adding multiple entries.
      I agree with that. Does dnsmasq "lose" dynamic dhcp leases when it is restarted?
      Nope, it stores them in /var/lib/misc/dnsmasq.leases so there won't be any loss on a restart. Which explains why I didn't lose any of my lease information when I cleared all the static entries last night.
    • wolffstarr wrote:

      Nope, it stores them in /var/lib/misc/dnsmasq.leases so there won't be any loss on a restart. Which explains why I didn't lose any of my lease information when I cleared all the static entries last night.
      New version here
      omv 5.3.4 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.2.5
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!