DSM7

[christianmeier]

New path dhcpd.conf.leases DSM6 ATIME=stat /etc/dhcpd/dhcpd-leases.log | grep Modify DSM7 ATIME=stat /etc/dhcpd/dhcpd.conf.leases g | grep Modify EDIT:dhcpd.conf.leases

[gclayburg]

Hi. Thanks for noticing this.

I haven't looked at this in a while, but on my system, I do see both of those files. For me they are both have the same contents and the same timestamp. Are you saying something needs to be changed here?

[christianmeier]

Him Gary, thank you for getting back to me!

I got this entry in the log : stat: cannot stat '/etc/dhcpd/dhcpd-leases.log': No such file or directory

/var/services/homes/admin/scripts/logs$ date Sat Jan 23 17:31:22 CET 2021

/var/services/homes/admin/scripts/logs$ ls -ali /etc/dhcpd/ |grep dhcp 91982 -rw-r--r-- 1 DhcpServer DhcpServer 13 Jan 23 14:33 dhcpd-bond0.info 139743 -rw-r--r-- 1 DhcpServer DhcpServer 191 Sep 22 16:25 dhcpd-bond0-static.conf 65751 -rw-r--r-- 1 DhcpServer DhcpServer 575 Jan 23 14:33 dhcpd-bond0-subnet0.conf 65949 -rw-r--r-- 1 DhcpServer DhcpServer 13 Jan 23 14:33 dhcpd-bond0-subnet0.info 141782 -rw-r--r-- 1 DhcpServer DhcpServer 1049 Jan 23 14:33 dhcpd.conf 90478 -rw-r--r-- 1 root root 1931 Jan 23 17:31 dhcpd.conf.leases 92241 -rw-r--r-- 1 root root 173 Jan 23 14:33 dhcpd-dns-dns.conf 91674 -rw-r--r-- 1 root root 14 Jan 23 14:33 dhcpd-dns-dns.info 106540 -rw-r--r-- 1 DhcpServer DhcpServer 13 Jan 23 14:33 dhcpd.info 110188 -rw-r--r-- 1 DhcpServer DhcpServer 48 Nov 25 2013 dhcpd-server-options.conf 140278 -rw-r--r-- 1 DhcpServer DhcpServer 0 Mar 30 2016 dhcpd-server-static.conf 110622 -rw-r--r-- 1 DhcpServer DhcpServer 0 Sep 13 2018 dhcpd-static-static.conf 36658 -rw-r--r-- 1 DhcpServer DhcpServer 2703 Jan 23 11:40 tmp-dhcpd-leases.log

I’d updated to day to the new DSM 7.0-41222 beta version and your script stoped working. Maybe there is a change. I will monitor this and come back to you if something comes up again.

Chris

On 23 Jan 2021, at 17:10, Gary Clayburg notifications@github.com wrote:

Hi. Thanks for noticing this.

I haven't looked at this in a while, but on my system, I do see both of those files. For me they are both have the same contents and the same timestamp. Are you saying something needs to be changed here?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gclayburg/synology-diskstation-scripts/issues/34#issuecomment-766111101, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZVEW7ZVVAVZC6CBICTNN3S3LYGHANCNFSM4WPWPOUQ.

[gclayburg]

Oh that could be. I haven't tried these scripts with that version yet. There definitely were some changes we needed to do for the DSM 5 to version 6 some time ago. Maybe synology is using a newer version of DNS?

[christianmeier]

The script is working as it should. I'd changed the following line from reload to restart It seems that reload does not publish the changes. (Changes are added and removed to the zones correctly) and only a restart make them available to query.

$ZoneRootDir/script/reload.sh root@nas:/var/services/homes/admin/scripts# cat diskstation_dns_modify.sh |grep restart $ZoneRootDir/script/restart.sh

[gclayburg]

Ok. What version of the DNS package are you running?

[christianmeier]

3.0.0 - 6047

On 27 Jan 2021, at 21:13, Gary Clayburg notifications@github.com wrote:

Ok. What version of the DNS package are you running?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gclayburg/synology-diskstation-scripts/issues/34#issuecomment-768547979, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZVEW4E4PB2KRYQYE5CHLLS4BXWZANCNFSM4WPWPOUQ.

[gclayburg]

Ok. I am running version 2.2.2 5027 and I am not seeing this problem. The standard reload.sh seems to work fine. My concern in changing the script to do a restart is that it could lead to more hiccups for everyday clients while the service is restarted. And this script can run quite often especially on a network with several dhcp clients.

Are you sure the restart is required for you? Or was there some sort of timeout involved when you were testing? Could you try it again with a new dhcp lease and a reload.sh step in the script?

[christianmeier]

The script was changing the zone correctly but the entries were not advertised by the dns. Via nslookup new IP can’t resolved with reload only. Strange behaviour I know. But now it’s working In my home lan there are roughly 70 devices registering IPS and DNS. Most of them are smart devices. They do not have a good WILAN connectivity and loos the connection over the time. As said - I do not have any issues with the script now. I will monitor this closely and keep you posted. Please come back to me for any new findings from your side.

On 28 Jan 2021, at 17:18, Gary Clayburg notifications@github.com wrote:

Ok. I am running version 2.2.2 5027 and I am not seeing this problem. The standard reload.sh seems to work fine. My concern in changing the script to do a restart is that it could lead to more hiccups for everyday clients while the service is restarted. And this script can run quite often especially on a network with several dhcp clients.

Are you sure the restart is required for you? Or was there some sort of timeout involved when you were testing? Could you try it again with a new dhcp lease and a reload.sh step in the script?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gclayburg/synology-diskstation-scripts/issues/34#issuecomment-769198293, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZVEW5LSOK4BEWKKCVPSILS4GE4JANCNFSM4WPWPOUQ.

[sw2828]

Hi @gclayburg , I have been having the same issue as @christianmeier over the past few months.. At one point DHCP clients were dynamically registering to DNS and I was able to resolve the FQDNs(My first to systems). Now the DHCP clients dynamically register to DNS, but they aren't published until I restart the DNS service with the following command: "/volume1/@appstore/DNSServer/script/restart.sh". Once I run that, everything resolves with no issue. So, before I restart DNS, the records are in the table, but nslookup fails until I restart. This sounds like the same issue @christianmeier had.

I now have the same issue on all three of my Synology systems in my labs. Two of them worked for a while, but then stopped. One is a new install and does not work.

I'm running the following versions: DSM DNS NAS61 DSM 6.2.3-25426 Update 3 2.2.2-5027 NAS08 DSM 6.2.3-25426 2.2.1-5024 NAS17 DSM 6.2.4-25556 <having an issue displaying version, but this is the newest NAS>

I have not tried @christianmeier work around yet since I just came across this thread. I'm waiting to upgrade all my systems to the same versions because I was thinking this was a version issue, but as you can see, my issues are with various version.

Please let me know if you have been able to determine the root cause and can provide a fix.

Thank you.

[gclayburg]

Hmm. I have not seen this issue on my synology diskstation. I wonder if your system is doing more DHCP changes than my network? Maybe DHCP is assigning new IP addresses to existing names more often? Do you see this issue for a new DHCP client being added to the network, i.e. a using a name that did not exist in DNS? Or does this issue only occur for existing DHCP clients?

BTW, I'm not sure if it matters, but I am using the latest DNS version now: 2.2.3-5028

Although for some reason, I'm not able to bring up the DNS package details screen from the package center using the web UI. To me this looks like some sort of strange UI issue, unrelated to this problem. I do see the version number for DNSServer in the /var/log/synopkg.log file like this:

2021/04/24 08:14:33 upgrade DNSServer 2.2.3-5028 Begin preinst

[sw2828]

@gclayburg , Thanks for the quick response.

I had a good amount of time to troubleshoot today and I found the root cause, but not a complete solution.

The issues is that I configure all my DNS server 'Zone Update Rules' with a key. This way only systems with the same key can update the zone.

When I remove this rule completely, the zone gets updated as expected with your script and when I run the reload.sh command manually. When I add the key rule, the zone does not get updated with your script or the manual command. This makes perfect sense.

So, in order to try to resolve the issue, I tried a few things that did not work and I'm hoping someone can point me in the right direction.

Here's what I tried. 1) Remove rule completely. Everything works as expected with your script. Command below is successful also. /var/packages/DNSServer/target/bin/rndc -k /var/packages/DNSServer/target/named/rndc.key reload test.lab.com

2) Use the HMAC-SHA512 rndc key that I created through the DNS key GUI (DNS, Keys, Create, Key Name: xxx, Algorithm: HMAC-SHA512 -Run the following command and get an error below /var/packages/DNSServer/target/bin/rndc -k /volume1/@appstore/DNSServer/named/etc/key/rndcupdatekey reload test.lab.com "rndc: unsupported algorithm: HMAC-SHA512"

3) Use the HMAC-MD5 rndc key that I created through the DNS key GUI (DNS, Keys, Create, Key Name: xxx, Algorithm: HMAC-MD5 -Run the following command and get an error below /var/packages/DNSServer/target/bin/rndc -k /volume1/@appstore/DNSServer/named/etc/key/rndcupdatekey reload test.lab.com **rndc: connection to remote host closed This may indicate that

• the remote server is using an older version of the command protocol,
• this host is not authorized to connect,
• the clocks are not synchronized, or
• the key is invalid.**

4) Use the default key that works with the original command by exporting it, then importing it using the DNS key GUI (DNS, Keys, import, browse for rndc key I exported from /var/packages/DNSServer/target/named/rndc.key) -This failed with an error "This name is reserved for system use. Please enter a different name.". -I then rename the file, but get same error. It doesn't seem to allow me to import the default system's rndc key.

Do you have any ideas about the rndc key?

######################## As for the DNS versions...

I wanted to upgrade DNS, but I didn't want to break anything further since I know it did work at one time on the current version of the two systems. Now that I know it's not a version issue, I will go ahead and upgrade to the latest.

Your command to get the DNS version worked. So I'm running three different versions, all have the same issue. NAS.......DSM.................................................DNS NAS61 DSM 6.2.3-25426 Update 3....2.2.2-5027 NAS08 DSM 6.2.3-25426.......................2.2.1-5024 NAS17 DSM 6.2.4-25556.......................2.2.3-5028

[gclayburg]

ok, so the script is working for you but you are having trouble configuring zone update rules? I haven't tried using anything other than the default, so I can't offer much help on that.

[sw2828]

@gclayburg , Thank you. If I figure out a way to do it, I will post my solution here.

[christianmeier]

@all If I can support you in case. let me know

[sw2828]

@christianmeier, Thank you. I have tried many options, but I haven not been able to get this working when 'Zone Update Rules' are enabled . If you have time to look into this further, that would be a great help. At this point, I'm out of ideas. I know this isn't directly related to this script, but if anyone does have 'Zone Update Rules' enabled, the script won't work.

The quickest way to test is running the following command, changing the full path of the rndc key and the domain name. /var/packages/DNSServer/target/bin/rndc -k /volume1/@appstore/DNSServer/named/etc/key/rndcupdatekey reload test.lab.com

[brainchild0]

Would I understand accurately that as of now the main branch is not reliable for use with DSM 7?

[dougmeek]

@brainchild0 I'd say it's stable, but only after updating the command in poll-dhcp-changes.sh to be:

ATIME='stat /etc/dhcpd/dhcpd.conf.leases g | grep Modify'

[brainchild0]

Is there any reason for not introducing this change into the distribution?

[christianmeier]

Hi, let me check this tomorrow. BR C

On 5 Jul 2021, at 19:47, brainchild0 @.***> wrote:

Is there any reason for not introducing this change into the distribution?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gclayburg/synology-diskstation-scripts/issues/34#issuecomment-874257426, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZVEWZVR3APPCQR3USCQ4LTWHV2DANCNFSM4WPWPOUQ.

[dougmeek]

@brainchild0 I actually submitted a pull request yesterday to do exactly that. Someone with the correct permissions needs to approve and merge, but based on the other two that have been sitting out there for a while I wouldn't expect it to happen in the near future. I know @gclayburg hasn't spent much time on this script lately, and that's totally understandable. You may just need to make the change yourself.

[gclayburg]

Hi guys - I should have some time later tonight to look at this. My issue though is that I'm using an older synology that can't run DSM 7 so I can't test it the way I'd like. I can at least verify that it doesn't break anything with DSM 6 though.

[christianmeier]

Hi, I’m bleeding edge… coming back-had an outage to day.. lot on my table.. C

On 7 Jul 2021, at 16:23, Gary Clayburg @.***> wrote:

 Hi guys - I should have some time later tonight to look at this. My issue though is that I'm using an older synology that can't run DSM 7 so I can't test it the way I'd like. I can at least verify that it doesn't break anything with DSM 6 though.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[brainchild0]

I see the PR, so it seems one option is that I simply take the snapshot from a10c15ca41e3a0d651563cc213c3859fd01ef408. However, it would be nice to have a merge, or any more official pathway for obtaining a functional snapshots.

[gclayburg]

Ok guys, it looks like we need some better error detection for poll-dhcp-changes.sh. So I'm looking on my system running DSM 6 and I do see both of these files: /etc/dhcpd/dhcpd-leases.log /etc/dhcpd/dhcpd.conf.leases

From what I see both of these files get modified when a new DHCP lease occurs. Does this always happen? I've been using the script for years with the script only doing a reload when the /etc/dhcpd/dhcpd-leases.log file changes. Apparently this doesn't always happen anymore under DSM7?

I want to fix this to work under DSM 7, but I don't want to break anything for DSM 6 users like me. So I think what I might do is change the script to do a DNS reload if either of these files are modified.

@dougmeek Thank you for your contribution. If I run the command in your patch I get an error. Is this intentional or just an oversight? I bet it probably works though.

# stat /etc/dhcpd/dhcpd-leases.log g
  File: ‘/etc/dhcpd/dhcpd-leases.log’
  Size: 587         Blocks: 8          IO Block: 4096   regular file
Device: 900h/2304d  Inode: 83866       Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-07-10 16:23:12.184351925 -0600
Modify: 2021-07-10 16:23:08.910381405 -0600
Change: 2021-07-10 16:23:08.910381405 -0600
 Birth: -
stat: cannot stat ‘g’: No such file or directory

[gclayburg]

FYI - I plan on testing this change I just created for the next few days on DSM 6. Any volunteers to test this change on DSM 7?

[christianmeier]

As said, I’m on DSM 7 and can test it. No issue. Regarding the logging I suggest to place them to /var/logs and also set up log-rotate. let me knew witch snapshot I can test.

On 11 Jul 2021, at 02:55, Gary Clayburg @.***> wrote:

FYI - I plan on testing this change I just created for the next few days on DSM 6. Any volunteers to test this change on DSM 7?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gclayburg/synology-diskstation-scripts/issues/34#issuecomment-877723542, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZVEW3JUUOOHNUXPSOVO4TTXDTYDANCNFSM4WPWPOUQ.

[dougmeek]

@gclayburg I think that may have been a typo on my part. It was supposed to be:

stat /etc/dhcpd/dhcpd.conf.leases | grep Modify

As far as the difference between versions goes, if both files are present and updated on DSM 6, I suggest that we target the file that exists on DSM 7. That said, it probably wouldn't be too difficult to build an if statement to determine the release version, after determining the version:

cat /etc/VERSION | grep majorversion

Give me a bit and I'll update my PR to reflect the correct command, that targets both versions.

I appreciate you looking at this.

---

EDIT: I didn't see your updates after your message to me because I was looking on mobile. Looks like you've already made a change to address this. I'll throw it up on my DSM 7 box and give it a try. Will let you know what I see in a bit. I'll kill a bunch of clients and have them get new addresses, which should generate some tests.

[dougmeek]

@gclayburg I've dropped the change on my NAS. I'm seeing a 100% success rate on 28 systems checking back in with new IPs. The old records are being removed/updated, and the new IPs are correct both in the forward and reverse zones. Additionally for context, I'm using a class B reverse zone rather than a class C, and it's working as expected.

I'd call that a success on DSM 7. I don't have a DSM 6 box laying around to test with, but I'm good with this change from my testing results.

Thanks for looking into this.

@christianmeier I'd be down with integrating the log file to the DSM Log Center, but I don't even know how to go about doing that. If you do, that would be a pretty nice enhancement. I'd even help you work on the coding of it if you had some knowledge of the logging mechanisms of DSM. My guess is that it uses the /var/log files but I have no idea.

[gclayburg]

@christianmeier I created a new branch called dsm7. You can test with that if you like. I plan on merging it in to master and creating a release once testing is complete. Here is the link that shows all the files in that branch: https://github.com/gclayburg/synology-diskstation-scripts/tree/dsm7

As far as the logging goes, you're right. The logging is quite crude to say the least. lol. It could be improved quite a bit. To be honest, I haven't really looked at any of the logs since I last changed the code years ago. Maybe the default should be just to turn off logging. Anyway if you guys come up with better logging, I'm all for it.

[christianmeier]

Hi all, will look at it - think it needs not that much to send the output instead to a file to the syslog facility. Come back to U guys! C

On 11 Jul 2021, at 18:41, Gary Clayburg @.***> wrote:

 @christianmeier I created a new branch called dsm7. You can test with that if you like. I plan on merging it in to master and creating a release once testing is complete. Here is the link that shows all the files in that branch: https://github.com/gclayburg/synology-diskstation-scripts/tree/dsm7

As far as the logging goes, you're right. The logging is quite crude to say the least. lol. It could be improved quite a bit. To be honest, I haven't really looked at any of the logs since I last changed the code years ago. Maybe the default should be just to turn off logging. Anyway if you guys come up with better logging, I'm all for it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[christianmeier]

Hi, I’m playing around with

logger -h

I’m not sure if it makes sense to push all the messages into syslog. More message noise makes it hard to keep an eye on the important one.

keep you posted

On 11 Jul 2021, at 18:41, Gary Clayburg @.***> wrote:

@christianmeier https://github.com/christianmeier I created a new branch called dsm7. You can test with that if you like. I plan on merging it in to master and creating a release once testing is complete. Here is the link that shows all the files in that branch: https://github.com/gclayburg/synology-diskstation-scripts/tree/dsm7 https://github.com/gclayburg/synology-diskstation-scripts/tree/dsm7 As far as the logging goes, you're right. The logging is quite crude to say the least. lol. It could be improved quite a bit. To be honest, I haven't really looked at any of the logs since I last changed the code years ago. Maybe the default should be just to turn off logging. Anyway if you guys come up with better logging, I'm all for it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gclayburg/synology-diskstation-scripts/issues/34#issuecomment-877830059, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZVEWYFXHXRW3VCWE2DUGDTXHCU3ANCNFSM4WPWPOUQ.

[dougmeek]

@gclayburg and @christianmeier I think it would make sense to have multiple logging levels. For instance: info, error, debug, etc. I agree that I don't want to see 6000 logs a day in DHCP script messages, but it would be nice to log errors in the same place that other error logs go. Perhaps make it configureable in the settings file?

[christianmeier]

Gents, do we have an other channel for communication. eMails is not appropriate in this development phase. what about slack?

On 12 Jul 2021, at 15:44, Doug Meek @.***> wrote:

@gclayburg https://github.com/gclayburg and @christianmeier https://github.com/christianmeier I think it would make sense to have multiple logging levels. For instance: info, error, debug, etc. I agree that I don't want to see 6000 logs a day in DHCP script messages, but it would be nice to log errors in the same place that other error logs go. Perhaps make it configureable in the settings file?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gclayburg/synology-diskstation-scripts/issues/34#issuecomment-878291360, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZVEWZSIDCTVBB4XDS7DCTTXLWSRANCNFSM4WPWPOUQ.

[brainchild0]

@christianmeier: Your e-mail messages are being posted to a GitHub issue, which in my view is an appropriate medium for this discussion.

[brainchild0]

Where does this project stand with respect to stable support in DSM 7?

[christianmeier]

Its stable

[christianmeier]

Sorry, tried to make a new branche and have no rights. Had to chance this line if user:group nobody to DNSServer ! chown DNSServer:DNSServer $BackupPath/$ForwardMasterFile.bumped $BackupPath/$ReverseMasterFile.bumped ; then

[brainchild0]

@christianmeier: Would you please explain the relation between the last two comments? In the prior, you wrote "it's stable". Is this statement not true because of issues discussed in the latter? Is additional information needed or additional steps required for users to run in DSM 7?

[christianmeier]

It's running stable as said - but I had issues with the syno dns app to manage dns entries. I saw, that the file permission of the zones belong to nobody:nobody. This was causing that I was not able edit the zones.

[brainchild0]

@christianmeier: To me, this observation would mean, unfortunately, that the package is not yet stable.

You said you tried to make a branch. Do you have a working solution to the problem? You can simply clone project to your Github account, push your fix to your account, and then create a pull request. Hopefully, the author would be happy to accept if it is a good solution.

[christianmeier]

@christianmeier: To me, this observation would mean, unfortunately, that the package is not yet stable.

You said you tried to make a branch. Do you have a working solution to the problem? You can simply clone project to your Github account, push your fix to your account, and then create a pull request. Hopefully, the author would be happy to accept if it is a good solution.

I stick to it, that it runs stable. Stable means for me that it does what it is expected. The issues with the permissions on the zone need to be verified from others. May I'm the only one with that symptom : )

[brainchild0]

Do you have an improved version available for testing?

[christianmeier]

imported it into my gitlab and invited you

[brainchild0]

I see the project, but no code. It may be helpful to put it in Github, since the project started here, and as far I know pull requests are only supported within the platform. More important, it would seem helpful to share with everyone, not just with me.

[christianmeier]

Got your point, I'll stay in Gitlab. Most of my code is work-related and I'm not allowed to share it . Why you do not import the projekt into your github?

[dougmeek]

@brainchild0 you are not the only one having issues. I have the same permissions issue and have resorted to just updating the master zones with SSH if I need to modify a record. The GUI is broken when running this. There's another open issue #38 that documents this.

[christianmeier]

hi, try this

diskstation_dns_modify.sh

Change: user:group nobody to DNSServer ! chown DNSServer:DNSServer $BackupPath/$ForwardMasterFile.bumped $BackupPath/$ReverseMasterFile.bumped ; then

[dougmeek]

@christianmeier I will when I get a few. Currently in great need of coffee lol. I see that #38 has a potential fix, it just needs to be put into a PR and tested.

[dougmeek]

@christianmeier I'd say at this point with the original intent of this issue, it's probably safe to close this issue. It's been close to a year and the only major problem that's cropped up is this permissions issue that seems relatively new and is documented in a separate issue.

[christianmeier]

@christianmeier I'd say at this point with the original intent of this issue, it's probably safe to close this issue. It's been close to a year and the only major problem that's cropped up is this permissions issue that seems relatively new and is documented in a separate issue.

Agree