Hope there will be IPv6 support

[tianen1108]

[Sailboat265]

@tianen1108

Hey there! Just in time, I recently submitted a pull that adds separated script which deals with IPv6 updating.

It's on pull #75. Go ahead to download the code and let me know if it works!

[Suncatcher]

@Sailboat265 so has anybody tested your PR? does it work?

[Sailboat265]

@Suncatcher Hi! I am using the same IPv6 script everyday too! Works well on my end. I also did testing on different machines before submitting the PR, so it should covers environments that supports ip or ifconfig.

But yeah, it's a bit unfortunately no one else reported any feedback for the IPv6 script yet.

[Suncatcher]

in your script @record_name variable is the domain name or DNS record ID? how do I know it? how to check if the API call was successful? why don't you provide any output?

[Sailboat265]

@Suncatcher Hmm, sorry to ask this but are you a newcomer to this repository?

If you have used the IPv4 version (cloudflare_template.sh) before, you shall recognize that the @record_name is the domain name. Subsequently, the output will be logged to your system log:

• /var/log/messages : On RHEL systems
• /var/log/syslog : On debian etc
• or if your system is using journald, then just do journalctl -xe

If you have configured everything correctly, and running the script with ./my_update_script.sh; if no outputs are shown on your terminal (not system log) then everything is working well.

When there's an error, the script will call logger -s <message>, which -s param means this message will get logged to your system log and stderr. With that being said, when there's an error, you will see it on your terminal, and system log.

And if you're wondering why this approach is used. Then please keep in mind that cloudflare-template.sh is the script for IPv4 version. Meanwhile, the pull request is to basically introduce cloudflare-templatev6.sh which is for IPv6 version. So, cloudflare-templatev6.sh is following the same logic design, same output logic with its parent IPv4 version.

[Suncatcher]

thanks for a thorough explanation, yes I am new to the script and never used it for the IPv4. I entered the game directly with IPv6.

or if your system is using journald, then just do journalctl -xe

kinda non-straightforward way to check for the last logs just after running the script. There may be dozens of running programs that will flood the log immediately with their lines, so it will be impossible to find DNS updater logs. It's better to search by service name like this

journalctl -u sshd

What is the service name one can search for in system journal?

Also, the lines that script writes into the journal are anything but definite. What one can understand from "check initiated"? was it a successful check, was it failure? Was the DNS record changed after check? Was it left as is because IP has not changed? Very ambiguous lines written to log.

And if you're wondering why this approach is used. Then please keep in mind that cloudflare-template.sh is the script for IPv4 version.

no need to resemble the same behavior if it is not good, you need to be better😉 It is more logical to give output both for successfull and unsuccessfull runs, as newcomers like me may not be aware that silence means success, and may start to worry. Not everybody can analyze Bash code just easy as you. I re-read the script and made some adjustments in my system, but many people cannot do this and will just think that the script is not-working. This was my 2 cents, otherwise kudos to you, you made the script better!

[Sailboat265]

What is the service name one can search for in system journal?

Hmm, if I'm not wrong, unfortunately there aren't any service name / unit name to search in journald at the moment.

What one can understand from "check initiated"?

Uhhh, it's just as the message implied. The script will start to perform checking operation such as querying with Cloudflare and performs checks etc. I think it should be very clear that it's not a successful check since you'll see a follow-up message afterwards. 🤔 Quite weird that you're confused from it.

no need to resemble the same behavior if it is not good, you need to be better😉 It is more logical to give output both for successful and unsuccessful runs, as newcomers like me may not be aware that silence means success, and may start to worry.

Well, but I do need to remind you that I'm just a little contributor. You may be satisfied (or not) with the implementation. But there are certain rules in OSS contributions that I have to follow. Please understand that I can't just make an IPv6 version of the base script (IPv4) with the output behavior changed.

It's important to respect the design paradigm of the predecessor when introducing new feature to the software, especially when participating in an OSS development. Additionally, in my opinion, it's important to cater existing sysops who used the IPv4 script before too; so they can transition / utilize the IPv6 script without issues.

Nonetheless, your feedback is highly valuable! It indeed does seems that some enhancements should be made to make the logging mechanism, usage description better; especially to these newcomers.

For better logging mechanism, I'm not sure if the repository owner (also maintainer) would like the addition of unit services file. However, it's possible to utilize tagging mechanism of journald; so every call to logger needs to use the -t (tagging) param.

A possible implementation could be:

logger -t $log_header_name <messages>

Note: It seems that $log_header_name must have no spaces at all. So, if DDNS Updater v6 is used, it should be replaced to DDNS-Updater-v6; or else only DDNS will get tagged with the log.

Then, a devop could simply do journalctl -t <log_header_name> to query the logs from journald. Which will return only all the messages logged under the specific tagging name defined in the <log_header_name> param.

[Ate329]

@Sailboat265 so has anybody tested your PR? does it work?

I didn't test it in detail but it was working absolutely fine for me.