Backup naming: include local domain

hi,

i got many routers with hostname router.

sorting backups is a pain, because all are named the same: backup-router-YYYY-MM-DD.tar.gz.

could the DNS local domain be appended to the hostname if a local domain is defined and the hostname is a simple unqualified name?

(in fact it may even be useful to include both hostname and local domain if the hostname is a FQDN, but this requires discussion.)

thank you!

So to be clear, you name all of your OpenWrt devices "router" and want the developers to implement a feature request for adding another value for your use?

BTW:

  • On the command line, you can name the backup file whatever you desire
  • After saving the file via LuCI, you can rename it
  • Most users (looking at posters in the community) don't edit that
  • Please explain the phrase "a simple unqualified name"
1 Like

To be honest, I doubt there are many users using multiple domains with overlapping OpenWrt hostnames, and even if this is the case, such a setup is best to back up properly, i.e. automated, scheduled, rotated, so the issue becomes irrelevant:

HOST="
router.lan1
router.lan2
"
for HOST in ${HOST}
do ssh root@${HOST} sysupgrade \
-b - > ${HOST}-$(date +%F).tar.gz
done
2 Likes

no, i name all my "main" routers differently. something like router.[main|iot|guest].<location>.lan. you see, DNS is a hierarchical naming system.

the issue is that openwrt sometimes names backups with a FQDN and sometimes with a non-FQDN. it uses a non-FQDN if the "hostname" field is unqualified. i happen to think that openwrt would be a better product if it always named backups with its FQDN.

"the hostname is a simple unqualified name" refers to it being a name without dots in it.

i suppose i agree. are you suggesting it is not worth the effort then? i'd gladly do a PR for it. but although i have a few commits in openwrt, i found that calling attention to pending PRs for review is unfortunately a bit of an uphill battle. i'm not complaining, it's a free project, and a very good one, so it is what it is. but i'm hesitant to open a new PR when i got pending PRs. honestly, for trivial things such as this one, i found it is much faster to ask for a fix than to fix it myself and then ask for PR reviews. in fact, in LuCI, my RFEs were sometimes fulfilled faster than light in a matter of just a couple of hours... amazing really.

well i kind of disagree there. yes, i doubt there are many users using multiple openwrt routers (not to be confused with APs), but of those that use multiple routers surely most of them use them in different domains. for these users, overlapping hostnames is the sane option. why would you name the main router of a domain anything but router and then have to remember not only the domain name but also the silly animal of fruit name you gave each router? we have hierarchical names precisely to avoid this nonsense.

in my case, although my setup might seem a bit complex, these are my home networks. i don't need regular automated backups: only i administer them, and only from one workstation, and i'm old enough to do a manual backup before changing things. it's just that the default naming is a bit of a pain.

nonetheless, thank you very much for providing the skeleton of an automated backup, appreciate it.

BTW, i also think dating the backups instead of timestamping them is a unfortunate choice. but at least we got the unambiguous YYYY-MM-DD format right. :slight_smile:

1 Like

To expand on this tangent, what about using unique hostnames (e.g. foo123.example.com.) and just setting up CNAMEs (e.g. router.example.com.) per subnet?

Best of both worlds, you retain your unique hostnames/ backup files, but can still access the devices under their common (role-) names (and you can omit the domain, with properly configured search domains).

3 Likes

you mean like router-main-callao-lan.main.callao.lan? lol hell no!!!

i hope you people don't think the internet is broken because 90+% of its hosts are name the same: www :slight_smile:

look, i expected 95% of people saying "yeah, this is a good idea and easy to implement" and the other 5% saying "yeah, but i got my script that expects the backup named that way because...

i seriously never expected: call you router tangerine, that's a better solution.

so... let's just celebrate human diversity! :slight_smile:

and no, i don't need help with my setup: this is the RFE channel, i wanted to improve the openwrt product, my setup is fine. good thing i didn't just issued a PR because obviously it seems i don't represent a majority. no worries...

www is indeed pointless, why bother about www.example.com if example.com will do (and thankfully most admins make www just another alias for the same DocumentRoot), so your hostname would/ should be example (if not something completely different, such as foobar1234).

1 Like

absolutely not! it might be pointless to you if you use only one application (browser) and only one protocol (https). but remember that the internet grew as a grassroots effort: the web was created by a then-unknown user, not designed into the internet. that the web dominates today was not something DNS designers could have forecasted, and as such (and because it's the sane thing to do) DNS best practices had to allow for all possible services. and your "solution" requires that all present and future services must be provided by (or at least available at) a single host, which is very poor design. we have ftp.blah, etc for a reason: sometimes we want different hosts for different services. or at least we want the possibility of separating a heavily used service to a different host in the future, if the load or special needs requires it.

There is nothing preventing ftp.example.com, smtp.example.com, gopher.example.com and similar to co-exist alongside {,www}.example.com (independent of the question if those point to the same host or different ones behind the scene and for the cases where this happens to be the same host, ftp://, smtp:// http://, https:// and gopher:// will be sufficient to distinguish between protocols).

But, back on topic, either give the hosts and their backups unique hostname or encode the fully qualified domain name into the tarball, you can do that.

1 Like

or... improve openwrt

Feel free to develop the new feature and then a pull request to get it merged.

1 Like

This is why I asked - becauae if you indeed name your routers differently, I don't see an issue. So I cleaely misunderstand you, as I see dots in the name. Feel free to make a PR.

My suggestion would be to use a dash (i.e. an unqualified name), and viola - a different name.

router-main
router-iot
router-guest

I agree that DNS is hierarchical - so that would mean the devices would manage their own zone.

I don't see the issue that needs fixing or improvement, especially given the software in question doesn't seem to be developed here by OpenWrt developers.

hey, thanks. i've already chosen the names of these routers and i'll keep them.

please read the OP. :frowning: the improvement would be to have openwrt name backups with the FQDN of the router rather than the hostname. although one may have different suffixes in dnsmasq (as i do) the router still has a single "local domain" setting, and i propose we use that local domain to fully qualify the router name for backup naming purposes. just that, so simple. wouldn't you agree that it is a better naming scheme? i think so but you may disagree.

1 Like

yeah i talked about that earlier in the thread. ok i'll do just that once my pending PRs get merged :slight_smile:

FWIW, i'll also do a PR if a user with commit rights tells me they will commit this. i've no issues with making a PR, but i don't want the uphill battle of asking for reviews.

The backup host name stems from here:
https://git.openwrt.org/?p=project/cgi-io.git;a=blob;f=main.c;h=8ca4c046d96eefe88aa8221e93814d0de7a0994c;hb=901b0f0463c9d16a8cf5b9ed37118d8484bc9176#l663

I think if you add a complete, dot terminated host name to /etc/config/system (/proc/sys/kernel/hostname), the filename will reflect that.

thank you. yes i know, that's why in the OP i said:

and later:

the problem is, AFAIK, the hostname should not be a FQDN. in my case, each of the router handles 3 domain suffixes for 3 different segments, and dnsmasq correctly generates 3 names for the router in the form <hostname>.<domain-suffix>. example: router.iot.callao.lan, router.guest.callao.lan, etc.

so how would using a FQDN for hostname work in this situation? how many other subtleties would misbehave if i do this? dnsmasq is a complex piece of software with many nuances, out of necessity as experience showed us: things such as dns rebinding attack protections make it behave... unexpectedly to put it mildly. i am not willing to strain my config, which entails various devices and required time and decent testing, for the benefit of a possible backup naming workaround.

people please understand....

this is not a help me channel. i dont want nor need any advice on how to hack my setup to implement a backup default naming workaround. there is nothing to change with my setup. this is a feature request channel. nearly all messages here ask me to change my config, when what needs changing IMHO is openwrt.

so please let's stay on topic and only discuss the possibility of changing openwrt.

thank you again.

Which of the domain suffixes should be used for the backup filename? An arbitrary one? Is the hostname --fqdn command returning the expected result on your system right now?

I’d rather avoid querying a nameserver to generate a backup filename as this will introduce new headaches wrt. potentially unreachable servers, timeout handling etc. Ideally the changed code should not be vastly more complex than the current gethostname() call.

1 Like

If something like this does get added, I think it should be an opt-in feature needing a config item to be set to enable it. Don't change the long-standing behavior in a default config.

Thanks.

1 Like

no, no, nothing needs be queried, and there is no ambiguity. please read my OP...

there is exactly one DNS local domain setting in openwrt. (it is the domain that the local resolver will append to unqualified names to look them up, just like any other host would.) the fact the dnsmasq may have many domain suffixes for many subnets is irrelevant here: the router has a local domain regardless of what dnsmasq may be up to.