make sure the host version of reslov.conf is used in any case #55
Conversation
|
I just found out the hard way that with the changes in this PR no more modifications can be made to the original resolv.conf file (which I need to do unfortunately). Does anybody know of any possible solutions to this? |
… add environment variable that states the pimod environment in order to make client scripts agnostic to being run in pimod
There was a problem hiding this comment.
Honestly, I am not quite sure how I feel about this PR.
On the one hand, I would guess that using the host's /etc/resolv.conf is desired.
This could be achieved easily by bind mounting the host's file into the guest.
However, on the other hand, I am pretty sure there are good reasons to alter the guest's /etc/resolv.conf within pimod.
Further, the special case to alter the host's /etc/rescolv.conf on the fly, and thereby also the guest's one, can only be realized through bind mounting.
Once again, this prevents changes from the guest.
I hope you see the same dilemma as I do.
As a workaround, you could ensure that no /etc/resolv.conf is present within your base image.
Thus, the host's file will always be bind mounted.
I am open for feedback, as the current situation does not seem optimal for me.
| @@ -1,5 +1,6 @@ | |||
| # ENV_VARS is an associative array of environment variables, set via ENV. | |||
| declare -A ENV_VARS=() | |||
| ENV_VARS["PIMOD"]="true" | |||
There was a problem hiding this comment.
I don't see the purpose of this additional ENV_VAR. How is this related to the changes?
There was a problem hiding this comment.
This environment variable is a very simplistic way of detecting that the image is indeed modified inside of pimod and thus take ecounter measures against trying to modify the wrong configuration file. As you already mentioned. I am also not very happy about the situation but the only real possible resolution I currently see is to switch to spinning up a real qemu instance which in turn makes the guest operation system boot like normal. This would indeed have some drawbacks - most notably it would take quite some time to boot.
|
I agree with your hesitation. For now I encounter #54 which makes the current state of pimod unusable for me. The only way to resolve the issue (I do also need to modify resolv.conf) in a timely manner was for me to execute the modifications in this PR. I'd be more than happy to learn about alternative/better solutions to this problem. One alternate solution I can think of is to spin a complete virtual machine in which the modifications to the raspberry Pi are executed. This has the drawback of being slower. Furthermore I don't have enough knowledge to implement such a solution. |
Calling pimod with the newly introduced --host-resolv flag results in the host's /etc/resolv.conf flag to be used over possibly existing resolv.conf files within the guest's image. This commit supersedes and closes #55. Thus, it also closes #54. Co-authored-by: Simon Ensslen <simon.ensslen@griesser.ch>
With this PR we make sure that the host's resolv.conf is used in any case during chroot. I don't see why the mechanism used to do this differently. In any case: this fixes #54.