Closed sensslen closed 2 years ago
For me, those are two issues of their own, which can be addressed like the following.
First, introduce a second pimod flag to do the opposite of --host-resolv
, never bind the host's /etc/resolv.conf
to the client. This, however, might lead to errors due to the file's absence.
Nevertheless, if a modification to the /etc/resolv.conf
file is made first, this should work, since the user is aware of this with the explicit flag.
Second, we could introduce such an environmental variable, as you have already suggested in #55.
Otherwise, as this is very specific to your use case, you could use the ENV
command within your Pifile.
Please let me know if this would work for you.
Thinking about it, I guess you're right! thanks fpr the suggestion. This will work for me...
@sensslen: I just refactored the --host-resolv
flag into a more generic --resolv
flag, allowing the user to select between the prior auto
behavior, always using the guest
's resolv.conf (never mount), or always using the host
's resolv.conf (introduced as --host-resolv
before).
In my attempt to use pimod to build a customized raspberry pi image fro our appliance, I encountered teh followin issue:
--host-resolv
flag/run/systemd/resolve/stub-resolv.conf
.Apparently the step described above is not possible in pimod (as resolv.conf is bind mounted to the hosts). Unfortunately the current implementation of pimod makes it impossible to detect whether a script runs in pimod envidonment and also makes it impossible to change the original resolv.conf file, as it is moved out to the host.
I'm currently looking for a clean way to execute the described procedure. #55 did allow for context aware modifications and also moved the original resolv.conf file to a well known location accessible by the client (thus allowing above descirbed modifications). On the other hand I totally understand that this is not a clean solution!