China DNS

192.168.2.111 is a private IP, I do not see china

User error.

The OP is looking up the reversed IP address of 111.2.168.192 which is a public address somewhere in China, not the private IP address of his machine.

Quote from njaimo

...the IP listed in my DNS record, 111.2.168.192, for OMV is in China

...and yes, the 192.168.2.111 is the IP address of the OMV server in my private network -- by the way, how did you find this, I did not put it in my post...

So my question remains, why is an IP based in China is in any way related to my OMV server ?

Does the record mean that my OMV server is reaching out to China and thus the DNS entry ?

Display More

Take a look at how reverse DNS works.

https://www.cloudflare.com/learning/dns/glossary/reverse-dns/

Quote

Reverse DNS lookups query DNS servers for a PTR (pointer) record; if the server does not have a PTR record, it cannot resolve a reverse lookup. PTR records store IP addresses with their segments reversed, and they append ".in-addr.arpa" to that. For example if a domain has an IP address of 192.0.2.1, the PTR record will store the domain's information under 1.2.0.192.in-addr.arpa.

In your example, it's 111.2.168.192.in-addr.arpa., so the actual address is 192.168.2.111.

Quote from njaimo

...the IP listed in my DNS record, 111.2.168.192, for OMV is in China

...and yes, the 192.168.2.111 is the IP address of the OMV server in my private network -- by the way, how did you find this, I did not put it in my post...

So my question remains, why is an IP based in China is in any way related to my OMV server ?

Does the record mean that my OMV server is reaching out to China and thus the DNS entry ?

Display More

You do not properly understand the difference between an IP address and its in-addr.arpa reverse. You can look up the meaning of in-addr.arpa for yourself.

Your IP address of 192.168.2.111 has the reverse in-addr.arpa of 111.2.168.192. Just list the dotted quads in reverse.

The Chinese public address of 111.2.168.192 has absolutely nothing to do with your server or its IP address.

Quote from njaimo

OMV is reaching out to rn-03.koehn.com:123 which I do nto think it is part of the pool.ntp.org servers... I have OMV set to reach out to pool.ntp.org...

...ia this another indication my OMV server has been compromised ?

There are more than 3,000 time servers within the pool.ntp.org cluster. You found one of them which happens when you make a query to pool.ntp.org.

Quote from njaimo

on a separate matter, the OMV server requests NTP every 2-3 minutes... I have OMV set up to reach to pool.ntp.org, and I can read the logs in my pfSense that show the frequency. While I suppose it is not a big issue, it seems unnecessary net traffic, every day would be more than fine -- any way to tune the need to reach for NTP in the OMV install ?

Well, I tried modifying the code, and it should work in theory, but I wouldn't recommend making the change.

OMV uses chrony as the NTP client. You can open the /etc/chrony/chrony.conf file with a text editor, and you might see:

# This file is auto-generated by openmediavault (https://www.openmediavault.org)
# WARNING: Do not edit this file, your changes will get lost.

server pool.ntp.org iburst

Here is the documentation for chrony: https://chrony-project.org/documentation.html

Use chronyc -v to check the version of chrony, then refer to the corresponding version of chrony.conf(5) - chronyd configuration file.

I think what you need are the minpoll and/or maxpoll options.

Next, please take a close look at this: https://docs.openmediavault.or…html#custom-configuration

Based on my testing, modifying chrony's environmental variables will cause errors. The only way to add the chrony directives option is through adding custom states (although this may not exactly be considered "adding custom states").

Please open /srv/salt/omv/deploy/chrony/files/etc-chrony-chrony_conf.j2 with a text editor, search for "iburst", then add the option you need after it and save the file.

Like this:

Run omv-salt deploy run chrony to apply the changes.

Then check /etc/chrony/chrony.conf. In my case, it became:

# This file is auto-generated by openmediavault (https://www.openmediavault.org)
# WARNING: Do not edit this file, your changes will get lost.

server pool.ntp.org iburst minpoll 10 maxpoll 15

In the end, I still have to remind you that this is not a recommended modification. This approach might be no different from directly editing /etc/chrony/chrony.conf. Whether it will be reverted during the next OMV version update is also unknown. Maybe you should ask developers votdev and ryecoaaron for their opinions.