This script is fantastic as-is, but there are a couple of "minor" enhancements I would love to see included for my own use case. Let me preface these by saying that I am very unfamiliar with Linux and scripting in that environment so I'm not sure how challenging these suggestions would be. I am a developer/programmer working in a predominantly Windows environment but have finally started trying to get into using the Linux command line so, while I understand the concepts of what the script is doing, I don't know the syntax for how to make the types of changes I'm asking about.
UX SUGGESTION # 1: MULTIPLE DOMAINS/SUBDOMAINS
First, I actually have two domains registered with GoDaddy and would like to have a subdomain on each that points to the dynamic IP address from my ISP. What I've done to achieve this is to make renamed copies of the three main files (the .sh, .properties, and .log files) and replaced the references to the name in the script with the new name, then run the new .sh file to create a separate cron job. This works as expected - both of my domains are having the A record updated on a 15-minute schedule - but it seems a bit more of a hassle than it could be. Also, if I ever need/want to add another subdomain (and new A record), as it stands, I'm going to have to repeat this process of copy/rename (and possibly verify permissions) -> edit -> run (to create a new cron job) for the new subdomain.
What I believe would be a "better" experience would be if the script were capable of accepting multiple domain names and/or subdomain names from the .properties file. For example, making the keys for domain and name accept a pipe-delimited (or some other delimiter) list of names that the script would parse out to an array, then check each item.
I do see the potential for some confusion with this if the two lists do not have the same number of elements or the user enters them in a different order, but that could simply be a "troubleshooting" step for the end-user if the script doesn't work as expected for them.
Additionally, if only a single name value is provided, the script could basically assume that the same subdomain should be checked on each of the domains, and vice-versa. For example:
domain=example.com with name=linuxshots|subdomain2 tries to update the A records for both linuxshots and subdomain2 on the same domain (example.com)
domain=example.com|mydomain.net with name=linuxshots tries to update an A record for linuxshots on both domains (example.com and mydomain.net)
Also, I realize that most "additional" subdomains pointing to the same IP address on the same domain could likely simply be created as CNAME records with GoDaddy. But there may be certain use-case scenarios where an A record would be more appropriate (such as targets for MX or NS records), so I still think it'd be a good option to include.
Alternately - and I admit that I'm not sure if this would even work for this kind of script in a Linux environment - creating property groups could make it "easier" to customize the configuration according to very specific requirements:
Such a setup (if possible) would allow for granular control over each domain and its associated subdomain(s), as well as allow for possible future "expansion" or additional settings. I suppose it would be possible to even allow the user to specify different GoDaddy API credentials for each domain, but that's probably just me over-thinking the process.
I could definitely see this being incorporated with #9 on the issue list to dynamically build/modify the .properties file as a part of both the proposed setup and update operations. Perhaps this is an interactive thing:
Enter the domain name:> example.com
Enter the name of the A record:> linuxshots
Enter the TTL (Time To Live):> 3600
> GoDaddy DDNS task added for linuxshots.example.com
Please make sure the A record exists for your domain by logging into your GoDaddy account
UX SUGGESTION # 2: HISTORICAL LOGGING
The other thing I would personally like to see is some historical logging of any time the script actually makes changes. This is probably totally unnecessary and just my own desire to keep records of everything, but it would be nice to see something like this in the log file:
EXAMPLE 2.1 - Historical logging for current implementation
DNS Name: linuxshots.example.com
Last Check: Sat 26 Feb 2022 12:15:02 AM CST
DNS IP: 98.123.123.123
TTL: 3600
Status: OK
[2022-01-12 09:45:05] [SUCCESS] Public IP changed (45.147.147.147 -> 68.21.21.21) A Record for linuxshots successfully updated with TTL 3600
[2022-02-25 22:30:02] [SUCCESS] Public IP changed (68.21.21.21 -> 98.123.123.123) A Record for linuxshots successfully updated with TTL 3600
Of course, if the first UX suggestion were implemented, this log would provide the details for each of the domains and their subdomains:
EXAMPLE 2.2 - Historical logging with suggested multiple domain/subdomain configuration
Last Check: Sat 26 Feb 2022 12:15:02 AM CST
DNS IP: 98.123.123.123
Domain: example.com
-------
DNS Name: linuxshots.example.com
TTL: 3600
Status: OK
DNS Name: subdomain2.example.com
TTL: 3600
Status: OK
Domain: mydomain.net
-------
DNS Name: subdomain2.mydomain.net
TTL: 3600
Status: OK
[2022-01-12 09:45:05] [INFO] Public IP changed (45.147.147.147 -> 68.21.21.21)
[2022-01-12 09:45:05] [SUCCESS] A Record for linuxshots successfully updated to 68.21.21.21 with TTL 3600
[2022-01-12 09:45:05] [SUCCESS] A Record for subdomain2 successfully updated to 68.21.21.21 with TTL 3600
[2022-01-12 09:45:05] [SUCCESS] A Record for subdomain2 successfully updated to 68.21.21.21 with TTL 3600
[2022-02-25 22:30:02] [INFO] Public IP changed (68.21.21.21 -> 98.123.123.123)
[2022-02-25 22:30:02] [SUCCESS] A Record for linuxshots successfully updated to 98.123.123.123 with TTL 3600
[2022-02-25 22:30:02] [SUCCESS] A Record for subdomain2 successfully updated to 98.123.123.123 with TTL 3600
[2022-02-25 22:30:02] [SUCCESS] A Record for subdomain2 successfully updated to 98.123.123.123 with TTL 3600
Obviously, this gets a lot more complicated very quickly, but it would be an extremely nice (in my opinion) enhancement to see a detailed history of the actions the script has actually taken. One option I could see to help avoid "clutter" in the log file might be to have separate logs for each domain.
In my "vision", this historical log would, of course, also include documentation of any warnings, failures, or other errors the script encounters. A few potential errors/warnings I imagine a user encountering:
EXAMPLE 2.3 - Sample error/warning logs
[2022-01-02 12:01:16] [ERROR] The supplied GoDaddy API credentials are invalid
[2022-01-02 12:05:38] [ERROR] No A record exists for linuxshots in the example.com domain - please create an A record pointing to 45.147.147.147
[2022-01-03 05:22:54] [ERROR] No Internet connection available
[2022-01-03 07:18:21] [WARNING] Could not retrieve current public IP address from ipinfo.io - assuming no changes are required
CONCLUSION
As I said before, this script is functionally fantastic and seems to work exactly as I need it to. The above suggestions are simply a matter of UX choices and preferences that I believe would provide even more utility and "user-friendliness" to an already great script. Please let me know if you have questions or need clarification on anything I've presented here. Thank you again for this as it's made my life a whole lot easier.
navilg
commented
2 years ago
This script is fantastic as-is, but there are a couple of "minor" enhancements I would love to see included for my own use case. Let me preface these by saying that I am very unfamiliar with Linux and scripting in that environment so I'm not sure how challenging these suggestions would be. I am a developer/programmer working in a predominantly Windows environment but have finally started trying to get into using the Linux command line so, while I understand the concepts of what the script is doing, I don't know the syntax for how to make the types of changes I'm asking about.
UX SUGGESTION # 1: MULTIPLE DOMAINS/SUBDOMAINS
First, I actually have two domains registered with GoDaddy and would like to have a subdomain on each that points to the dynamic IP address from my ISP. What I've done to achieve this is to make renamed copies of the three main files (the
.sh,.properties, and.logfiles) and replaced the references to the name in the script with the new name, then run the new.shfile to create a separate cron job. This works as expected - both of my domains are having theArecord updated on a 15-minute schedule - but it seems a bit more of a hassle than it could be. Also, if I ever need/want to add another subdomain (and newArecord), as it stands, I'm going to have to repeat this process of copy/rename (and possibly verify permissions) -> edit -> run (to create a new cron job) for the new subdomain.What I believe would be a "better" experience would be if the script were capable of accepting multiple domain names and/or subdomain names from the
.propertiesfile. For example, making the keys fordomainandnameaccept a pipe-delimited (or some other delimiter) list of names that the script would parse out to an array, then check each item.EXAMPLE 1.1 - Using pipe-delimited lists
I do see the potential for some confusion with this if the two lists do not have the same number of elements or the user enters them in a different order, but that could simply be a "troubleshooting" step for the end-user if the script doesn't work as expected for them.
Additionally, if only a single
namevalue is provided, the script could basically assume that the same subdomain should be checked on each of the domains, and vice-versa. For example:domain=example.comwithname=linuxshots|subdomain2tries to update theArecords for bothlinuxshotsandsubdomain2on the same domain (example.com)domain=example.com|mydomain.netwithname=linuxshotstries to update anArecord forlinuxshotson both domains (example.comandmydomain.net)Also, I realize that most "additional" subdomains pointing to the same IP address on the same domain could likely simply be created as
CNAMErecords with GoDaddy. But there may be certain use-case scenarios where anArecord would be more appropriate (such as targets forMXorNSrecords), so I still think it'd be a good option to include.Alternately - and I admit that I'm not sure if this would even work for this kind of script in a Linux environment - creating property groups could make it "easier" to customize the configuration according to very specific requirements:
EXAMPLE 1.2 - Using property groups
Such a setup (if possible) would allow for granular control over each domain and its associated subdomain(s), as well as allow for possible future "expansion" or additional settings. I suppose it would be possible to even allow the user to specify different GoDaddy API credentials for each domain, but that's probably just me over-thinking the process.
I could definitely see this being incorporated with #9 on the issue list to dynamically build/modify the
.propertiesfile as a part of both the proposedsetupandupdateoperations. Perhaps this is an interactive thing:UX SUGGESTION # 2: HISTORICAL LOGGING
The other thing I would personally like to see is some historical logging of any time the script actually makes changes. This is probably totally unnecessary and just my own desire to keep records of everything, but it would be nice to see something like this in the log file:
EXAMPLE 2.1 - Historical logging for current implementation
Of course, if the first UX suggestion were implemented, this log would provide the details for each of the domains and their subdomains:
EXAMPLE 2.2 - Historical logging with suggested multiple domain/subdomain configuration
Obviously, this gets a lot more complicated very quickly, but it would be an extremely nice (in my opinion) enhancement to see a detailed history of the actions the script has actually taken. One option I could see to help avoid "clutter" in the log file might be to have separate logs for each domain.
In my "vision", this historical log would, of course, also include documentation of any warnings, failures, or other errors the script encounters. A few potential errors/warnings I imagine a user encountering:
EXAMPLE 2.3 - Sample error/warning logs
CONCLUSION
As I said before, this script is functionally fantastic and seems to work exactly as I need it to. The above suggestions are simply a matter of UX choices and preferences that I believe would provide even more utility and "user-friendliness" to an already great script. Please let me know if you have questions or need clarification on anything I've presented here. Thank you again for this as it's made my life a whole lot easier.