Over the past month, I’ve been working on a new, transparent server configuration. I’ve been using Fetch Apply (https://github.com/P5vc/FetchApply) to convert a previously-“closed source” configuration into a public, auditable one. During this process I’ve come across a few problems, but there’s one oddity that has stood out to me, and my mind can’t rest until I understand why it is happening.
The servers I’m working on use
dnscrypt-proxy, and therefore use a custom
resolv.conf file. When I first started working on the resolv module (https://github.com/P5vc/ServerConfigurations/tree/master/modules/resolv) I had Fetch Apply writing the configuration file directly, via the following Bash command:
/path/to/newResolv.conf > /etc/resolv.conf. This style of command worked (and works) just fine for every other module. However, whenever the
resolv module ran, applying the above command, weird behavior would result, and the file would seem to simultaneously exist and not exist.
Here are some things I noted, after the module ran:
- When opening the file with
nano, a blank file would be opened and the
New Filetext would appear at the bottom
- The updated
resolv.conffile was not applied in the eyes of the other programs. I.E., no DNS resolutions were successful.
- When removing the file (via
rm), I was not given a
File Not Founderror, and was then in fact able to re-run the module and the
resolv.conffile would write correctly and be recognized, after first removing the “ghost” file.
- The module was successfully executed the first time (the time that the “ghost” file was created), and there were no error codes returned.
After noticing this odd behavior, I did a full reinstallation of the OS (Ubuntu Server 20.04 LTS), and tried again. I did this probably about 5 times in total across two different systems and every time, whether run via the module or manually typed by me, replacing the
/etc/resolv.conf via a bash command similar to the one shown above would cause a “ghost” file to be created. In the end, I was able to solve the issue by first writing the file to
/tmp/resolv.conf, and then using
mv /tmp/resolv.conf /etc/resolv.conf, which would correctly write the file the first time, without creating a “ghost” file.
So, I’m wondering:
- What was happening? What was specifically causing this sort of ghost file to appear and behave this way? Is there a way to reproduce this behavior with other files? Is this a common occurrence? etc. I’m curious to learn more about this issue and the technical reason as to why it occurs… if there is one.
Please don’t hesitate to ask questions or for further details, as I know this is an abstract question.