Re: Some Thoughts on resolv.conf.tail Deprecation
On Fri, Nov 12, 2021 at 02:04:56AM +, beebeet...@posteo.de wrote: > > I am not sure about what problem you are trying to solve. Won't the > > lines added by resolvd be overwritten anyway the first time you use the > > backed up file? > > What I'm trying to solve is that static part of the configuration being > mixed up with configuration generated runtime in a single file, which > leads to a few inconveniences: > - resolv.conf will show up in the diff between backups all the time >even if nothing has really changed; You could backup /var/backups/etc_resolv.conf.current file instead of /etc/resolv.conf (or just all /var/backups files). The backup file seems to be changed only if the content is changed (I only checked mtime on the file on a moving laptop). So you will get the "stable" inode if content is the same. > - when migrating the configuration to a different deployment, for >example, one where IP address is statically assigned, resolvd will >not overwrite the "stale" auto-configured lines, and the old >nameserver info will linger unless manually removed. if the new host doesn't use resolvd(8) it could be a problem as the file will not be rewritten. But in this case you should take a different file for source for your template. OpenBSD isn't a static OS, it is expected to have to adapt the administration task for time to time. Please note that you could also run a simple command-line to "cleanup" resolv.conf: # sed -i -e '/ # resolvd: /d' /etc/resolv.conf (and if you put it in /etc/rc.local, your host with resolvd will recreate it at boot, and your host without resolvd will keep it clean). Thanks. -- Sebastien Marie
Re: Some Thoughts on resolv.conf.tail Deprecation
What I'm trying to solve is that static part of the configuration being mixed up with configuration generated runtime in a single file, which leads to a few inconveniences: - resolv.conf will show up in the diff between backups all the time even if nothing has really changed; Oh come on. Something happened. That is why the contents are different. Yes something happened, but something which I imagine is not typically worth being backed up, yet it lives in the same file as things that are. - when migrating the configuration to a different deployment, for example, one where IP address is statically assigned, resolvd will not overwrite the "stale" auto-configured lines, and the old nameserver info will linger unless manually removed. So what? In cases where one doesn't want reveal what nameserver their other machines were using, a bit more error-prone I guess. I just don't see the reasoning behind removing resolv.conf.tail...
Re: Some Thoughts on resolv.conf.tail Deprecation
beebeet...@posteo.de wrote: > > I am not sure about what problem you are trying to solve. Won't the > > lines added by resolvd be overwritten anyway the first time you use the > > backed up file? > > What I'm trying to solve is that static part of the configuration being > mixed up with configuration generated runtime in a single file, which > leads to a few inconveniences: > - resolv.conf will show up in the diff between backups all the time >even if nothing has really changed; Oh come on. Something happened. That is why the contents are different. > - when migrating the configuration to a different deployment, for >example, one where IP address is statically assigned, resolvd will >not overwrite the "stale" auto-configured lines, and the old >nameserver info will linger unless manually removed. So what? > For now resolv.conf is the only configuration file I know of that gets > mixed up with runtime info, and it's manageable; but imagine if many > more configuration files follow similar principles, the administrative > overhead can quickly become too much. Yes, we are going to do the same thing to lots of other configuration files. We are trying to keep up with systemd. Didn't you get the memo?
Re: Some Thoughts on resolv.conf.tail Deprecation
I am not sure about what problem you are trying to solve. Won't the lines added by resolvd be overwritten anyway the first time you use the backed up file? What I'm trying to solve is that static part of the configuration being mixed up with configuration generated runtime in a single file, which leads to a few inconveniences: - resolv.conf will show up in the diff between backups all the time even if nothing has really changed; - when migrating the configuration to a different deployment, for example, one where IP address is statically assigned, resolvd will not overwrite the "stale" auto-configured lines, and the old nameserver info will linger unless manually removed. For now resolv.conf is the only configuration file I know of that gets mixed up with runtime info, and it's manageable; but imagine if many more configuration files follow similar principles, the administrative overhead can quickly become too much.
Re: Some Thoughts on resolv.conf.tail Deprecation
My solution for an static resolv.conf for a long time has been: chattr +i /etc/resolv.conf .. and now disable resovld, of course. If folks use another solution, would be glad to know. -- Fabio Martins On 2021-11-11 17:28, Zé Loff wrote: On Thu, Nov 11, 2021 at 05:36:07PM +, beebeet...@posteo.de wrote: Hi all, I was reading the manual page of resolv.conf(5) today and realized that paragraph on resolv.conf.tail has disappeared since the upgrade to 7.0, so I assume that resolv.conf.tail has been deprecated in response to resolvd being enabled by default. Previously, my backup strategy was to back up the customized system configuration files, which involves backing up resolv.conf.tail, but not resolv.conf. With the new behaviour in 7.0, it appears that my best shot is to back up resolv.conf, which constantly gets edited by resolvd(8). This seems less than ideal. I am not sure about what problem you are trying to solve. Won't the lines added by resolvd be overwritten anyway the first time you use the backed up file? I gave it some thoughts, and came up with an alternative solution to handling resolv.conf: - If resolvd is enabled, then resolv.conf is overidden entirely by resolvd, no more blending of user-edited and auto-configured information is involved. A new resolvd.conf needs to be introduced to instruct resolvd to add static defaults and stuff; - If resolvd is not enabled, then the contents of resolv.conf.tail gets copied to resolv.conf at system start. To me it seems that this is cleaner than the current solution to resolv.conf in that static and dynamic configurations is clearly separated instead of being blended into a one file. What are your thought on this? Thanks!
Re: Some Thoughts on resolv.conf.tail Deprecation
On Thu, Nov 11, 2021 at 05:36:07PM +, beebeet...@posteo.de wrote: > Hi all, > > I was reading the manual page of resolv.conf(5) today and realized that > paragraph on resolv.conf.tail has disappeared since the upgrade to 7.0, so I > assume that resolv.conf.tail has been deprecated in response to resolvd > being enabled by default. > > Previously, my backup strategy was to back up the customized system > configuration files, which involves backing up resolv.conf.tail, but > not resolv.conf. With the new behaviour in 7.0, it appears that my best > shot is to back up resolv.conf, which constantly gets edited by > resolvd(8). This seems less than ideal. I am not sure about what problem you are trying to solve. Won't the lines added by resolvd be overwritten anyway the first time you use the backed up file? > I gave it some thoughts, and came up with an alternative solution to > handling resolv.conf: > > - If resolvd is enabled, then resolv.conf is overidden entirely by >resolvd, no more blending of user-edited and auto-configured >information is involved. A new resolvd.conf needs to be introduced to >instruct resolvd to add static defaults and stuff; > > - If resolvd is not enabled, then the contents of resolv.conf.tail gets >copied to resolv.conf at system start. > > To me it seems that this is cleaner than the current solution to > resolv.conf in that static and dynamic configurations is clearly > separated instead of being blended into a one file. > > What are your thought on this? Thanks! > --
Re: Some Thoughts on resolv.conf.tail Deprecation
No, we will not do what you propose because resolvd so far is working for the majority of people, better than we expected. Luckily we provide all the parts including source, and you can do whatever you want with it. beebeet...@posteo.de wrote: > Hi all, > > I was reading the manual page of resolv.conf(5) today and realized that > paragraph on resolv.conf.tail has disappeared since the upgrade to > 7.0, so I assume that resolv.conf.tail has been deprecated in response > to resolvd being enabled by default. > > Previously, my backup strategy was to back up the customized system > configuration files, which involves backing up resolv.conf.tail, but > not resolv.conf. With the new behaviour in 7.0, it appears that my best > shot is to back up resolv.conf, which constantly gets edited by > resolvd(8). This seems less than ideal. > > I gave it some thoughts, and came up with an alternative solution to > handling resolv.conf: > > - If resolvd is enabled, then resolv.conf is overidden entirely by >resolvd, no more blending of user-edited and auto-configured >information is involved. A new resolvd.conf needs to be introduced to >instruct resolvd to add static defaults and stuff; > > - If resolvd is not enabled, then the contents of resolv.conf.tail gets >copied to resolv.conf at system start. > > To me it seems that this is cleaner than the current solution to > resolv.conf in that static and dynamic configurations is clearly > separated instead of being blended into a one file. > > What are your thought on this? Thanks! >
Some Thoughts on resolv.conf.tail Deprecation
Hi all, I was reading the manual page of resolv.conf(5) today and realized that paragraph on resolv.conf.tail has disappeared since the upgrade to 7.0, so I assume that resolv.conf.tail has been deprecated in response to resolvd being enabled by default. Previously, my backup strategy was to back up the customized system configuration files, which involves backing up resolv.conf.tail, but not resolv.conf. With the new behaviour in 7.0, it appears that my best shot is to back up resolv.conf, which constantly gets edited by resolvd(8). This seems less than ideal. I gave it some thoughts, and came up with an alternative solution to handling resolv.conf: - If resolvd is enabled, then resolv.conf is overidden entirely by resolvd, no more blending of user-edited and auto-configured information is involved. A new resolvd.conf needs to be introduced to instruct resolvd to add static defaults and stuff; - If resolvd is not enabled, then the contents of resolv.conf.tail gets copied to resolv.conf at system start. To me it seems that this is cleaner than the current solution to resolv.conf in that static and dynamic configurations is clearly separated instead of being blended into a one file. What are your thought on this? Thanks!
