I must be having a rough week or just getting older but I can’t seem to come up with an elegant solution to this problem… Ok… I have WSL on my workstation, when I establish VPN to $work, WSL buggers resolv.conf.
From: nameserver <mine> search <$homedomain>
To: nameserver <mine> nameserver <$work1> nameserver <$work2> search <$workdomain>
I have to manually take line 1 and move it to line 3 for internal resolution to work… EVERY DAMNED TIME WSL instantiates (while VPN is established). This is because $workdomain is blackholed publicly.
My first thought was a stupid ed script to move line 1 to 3… that didn’t work so well (my ed skills are apparently lacking).
Ideally the solution would note if there 3 or more nameserver lines, move the lines before ‘nameserver <$work1>’ to one line before the last file. I’d pop that into my .bashrc/.profile or similar.
I couldn’t find how WSL manipulates the file itself otherwise I would have tried to change it…
Anyone have any ideas there?
-- Sean
You're not going to like the official solution: https://docs.microsoft.com/en-us/windows/wsl/troubleshooting#bash-loses-netw...
The various "solutions" are mostly going to be problematic, because apparently it's a bug: https://github.com/microsoft/WSL/issues/1908#issuecomment-296283093
However, there's hope: https://github.com/microsoft/WSL/issues/3928#issuecomment-488556907
At least it's widely known: https://www.sonicwall.com/support/knowledge-base/windows-subsystem-for-linux...
Good luck!
-Adam
On 2020-06-02 16:19, Sean Cody wrote:
I must be having a rough week or just getting older but I can’t seem to come up with an elegant solution to this problem… Ok… I have WSL on my workstation, when I establish VPN to $work, WSL buggers resolv.conf.
From: nameserver <mine> search <$homedomain>
To: nameserver <mine> nameserver <$work1> nameserver <$work2> search <$workdomain>
I have to manually take line 1 and move it to line 3 for internal resolution to work… EVERY DAMNED TIME WSL instantiates (while VPN is established). This is because $workdomain is blackholed publicly.
My first thought was a stupid ed script to move line 1 to 3… that didn’t work so well (my ed skills are apparently lacking).
Ideally the solution would note if there 3 or more nameserver lines, move the lines before ‘nameserver <$work1>’ to one line before the last file. I’d pop that into my .bashrc/.profile or similar.
I couldn’t find how WSL manipulates the file itself otherwise I would have tried to change it…
Anyone have any ideas there?
-- Sean
Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
That last link was helpful... their solution is very similar to the direction I was headed but pulling data from system (interesting approach). If I get around to porting it I'll pop as gist here or something.
Thanks!
-----Original Message----- From: Adam Thompson athompso@athompso.net Sent: June 2, 2020 4:43 PM To: Continuation of Round Table discussion roundtable@muug.ca Cc: Sean Cody sean@tinfoilhat.ca Subject: Re: [RndTbl] Fix resolv.conf on WSL instantiation...
You're not going to like the official solution: https://docs.microsoft.com/en-us/windows/wsl/troubleshooting#bash-loses-netw...
The various "solutions" are mostly going to be problematic, because apparently it's a bug: https://github.com/microsoft/WSL/issues/1908#issuecomment-296283093
However, there's hope: https://github.com/microsoft/WSL/issues/3928#issuecomment-488556907
At least it's widely known: https://www.sonicwall.com/support/knowledge-base/windows-subsystem-for-linux...
Good luck!
-Adam
On 2020-06-02 16:19, Sean Cody wrote:
I must be having a rough week or just getting older but I can’t seem to come up with an elegant solution to this problem… Ok… I have WSL on my workstation, when I establish VPN to $work, WSL buggers resolv.conf.
From: nameserver <mine> search <$homedomain>
To: nameserver <mine> nameserver <$work1> nameserver <$work2> search <$workdomain>
I have to manually take line 1 and move it to line 3 for internal resolution to work… EVERY DAMNED TIME WSL instantiates (while VPN is established). This is because $workdomain is blackholed publicly.
My first thought was a stupid ed script to move line 1 to 3… that didn’t work so well (my ed skills are apparently lacking).
Ideally the solution would note if there 3 or more nameserver lines, move the lines before ‘nameserver <$work1>’ to one line before the last file. I’d pop that into my .bashrc/.profile or similar.
I couldn’t find how WSL manipulates the file itself otherwise I would have tried to change it…
Anyone have any ideas there?
-- Sean
Roundtable mailing list Roundtable@muug.ca https://muug.ca/mailman/listinfo/roundtable
On 2020-06-02 Sean Cody wrote:
To: nameserver <mine> nameserver <$work1> nameserver <$work2> search <$workdomain>
Ideally the solution would note if there 3 or more nameserver lines, move the lines before ‘nameserver <$work1>’ to one line before the last file. I’d pop that into my .bashrc/.profile or similar.
While you're waiting for MS to fix it... perl can do it in an under-200 chars one-liner. I'm assuming WSL lets you have perl!
perl -i -e 'while(<>){ $s.=$_; if (eof ARGV){ $work1="ns.foo.com"; $_=$s; exit if !/(?:nameserver [^\n]+\n){3}/s; s/(.*?\n)?(nameserver \Q$work1\E\n)(.*?\n)([^\n]+\n?)$/$2$3$1$4/s; print } }' /etc/resolv.conf
Just change the $work1 var in there. (tcsh users will have to escape the ! also.) Uses perl's inline editing (-i) but you have to do trickery to operate on full file (necessary here), hence all the weirdness and having to write my own loop rather than use -n.
As you requested: - will not run unless 3+ nameserver lines - $work1 line should be able to be on any line before the search, but I only tested your file test case - the magic happens in the $2$3$1$4 if you need to alter the line ordering: but note, the numbers don't correspond to lines, they correspond to semantic groups: 1. pre-work1, 2. work1, 3. post-work1 but not final line, 4. final line
P.S. Your original wording was a bit wonky ("one line before the last file") which I took to mean one line before the last *line*.