[Touch-packages] [Bug 1774632] Re: The symbolic link /etc/resolv.conf points to the wrong file by default

2021-06-07 Thread Per Olav Kroka 
Please disregard my last comment (#5).  The problem I had was not this
one but related to using other connector agents in addition to
NetworkManager, in my case the openvpn3 command line.

(Automatic connection to the VPN is not there, but that is probably
safest.)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1774632

Title:
  The symbolic link /etc/resolv.conf points to the wrong file by default

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  When using nslookup for local machine names, the local DNS was being
  ignored (not queried) and none of the local machines could be found.

  After much research and digging, it was discovered that the cause was
  the incorrect symbolic link /etc/resolv.conf file.

  The default install caused systemd-resolve to configure the link to point to 
the stub file:
  /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

  Reomving that link and pointing it to the correct file solved the DNS lookup 
issue. The correct link looks like this:
  /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

  
  Steps used to test the bug before fixing the link is to perform an nslookup 
on a local (non FQDN) machine that is in your local DNS (my router is my DNS 
server for this case) Here is an example of the incorrect output:

  $ nslookup web1

  Server: 127.0.0.53
  Address:127.0.0.53#53

  ** server can't find web1: SERVFAIL

  
  Switching the symbolic link solves the problem. Here is my solution:

  $ sudo rm -f /etc/resolv.conf
  $ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

  
  After switching the symbolic link, the nslookup functions properly.

  $ nslookup web1

  Server: 192.168.1.1
  Address:192.168.1.1#53

  Name:   web1
  Address: 192.168.1.107

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Uname: Linux 4.15.0-22-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Jun  1 05:28:41 2018
  InstallationDate: Installed on 2018-01-20 (131 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
  MachineType: Dell Inc. Inspiron 5755
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-22-generic 
root=UUID=7fe151d3-4033-4903-b356-341d9f16e124 ro acpi=force
  SourcePackage: systemd
  UpgradeStatus: Upgraded to bionic on 2018-04-28 (33 days ago)
  dmi.bios.date: 08/27/2015
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A08
  dmi.board.name: 0VY15F
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 8
  dmi.chassis.vendor: Dell Inc.
  dmi.chassis.version: A08
  dmi.modalias: 
dmi:bvnDellInc.:bvrA08:bd08/27/2015:svnDellInc.:pnInspiron5755:pvrA08:rvnDellInc.:rn0VY15F:rvrA00:cvnDellInc.:ct8:cvrA08:
  dmi.product.name: Inspiron 5755
  dmi.product.version: A08
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1774632/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1774632] Re: The symbolic link /etc/resolv.conf points to the wrong file by default

2021-05-27 Thread Per Olav Kroka 
I just want to confirm that this is a problem.  I have had it for a
while and not found another workaround (until now) than restarting the
machine.

If this is NOT a bug then something "close by" is a bug.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1774632

Title:
  The symbolic link /etc/resolv.conf points to the wrong file by default

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  When using nslookup for local machine names, the local DNS was being
  ignored (not queried) and none of the local machines could be found.

  After much research and digging, it was discovered that the cause was
  the incorrect symbolic link /etc/resolv.conf file.

  The default install caused systemd-resolve to configure the link to point to 
the stub file:
  /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

  Reomving that link and pointing it to the correct file solved the DNS lookup 
issue. The correct link looks like this:
  /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

  
  Steps used to test the bug before fixing the link is to perform an nslookup 
on a local (non FQDN) machine that is in your local DNS (my router is my DNS 
server for this case) Here is an example of the incorrect output:

  $ nslookup web1

  Server: 127.0.0.53
  Address:127.0.0.53#53

  ** server can't find web1: SERVFAIL

  
  Switching the symbolic link solves the problem. Here is my solution:

  $ sudo rm -f /etc/resolv.conf
  $ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

  
  After switching the symbolic link, the nslookup functions properly.

  $ nslookup web1

  Server: 192.168.1.1
  Address:192.168.1.1#53

  Name:   web1
  Address: 192.168.1.107

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: systemd 237-3ubuntu10
  ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
  Uname: Linux 4.15.0-22-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Jun  1 05:28:41 2018
  InstallationDate: Installed on 2018-01-20 (131 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20180105.1)
  MachineType: Dell Inc. Inspiron 5755
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-22-generic 
root=UUID=7fe151d3-4033-4903-b356-341d9f16e124 ro acpi=force
  SourcePackage: systemd
  UpgradeStatus: Upgraded to bionic on 2018-04-28 (33 days ago)
  dmi.bios.date: 08/27/2015
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A08
  dmi.board.name: 0VY15F
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 8
  dmi.chassis.vendor: Dell Inc.
  dmi.chassis.version: A08
  dmi.modalias: 
dmi:bvnDellInc.:bvrA08:bd08/27/2015:svnDellInc.:pnInspiron5755:pvrA08:rvnDellInc.:rn0VY15F:rvrA00:cvnDellInc.:ct8:cvrA08:
  dmi.product.name: Inspiron 5755
  dmi.product.version: A08
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1774632/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1641108] [NEW] IF_* variables are not defined (for static IP) in post-up phase

2016-11-11 Thread Per Olav Kroka 
Public bug reported:

SYMPTOM
My computer is set up with static IP on interface eno1 and running 'sudo apt 
update' fails. Adding nameserver aaa.bbb.ccc.ddd in resolv.conf helps, as a 
workaround, but this is reset on reboot.  Another workaround is to create a 
secondary IP on the same interface using DHCP (it works), but I don't want that.

ANALYSIS
I have traced the problem to the IF_* variables not being set at "post-up" 
phase, where resolvconf tries to get the values.  (see 000resolvconf file in 
/etc/network/if-up.d.)

To verify this I created a script named dbg which I placed in all the 
if-*.d folders:
# Start
DBGDIR=/etc/test
mkdir -p $DBGDIR
DEBUGFILE=$DBGDIR/$PHASE

set  | grep -E 
"^(IF_|(IFACE|LOGICAL|ADDRFAM|METHOD|MODE|PHASE|VERBOSITY|PATH)\b)" > $DEBUGFILE
#--- end

(For some reason the mkdir command did not work, so I created the
directory manually.)

These where the resulting files (listed with tail -n20 ...):
==> /etc/test/post-down <==
ADDRFAM='meta'
IFACE='--all'
LOGICAL='auto'
METHOD='none'
MODE='stop'
PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
PHASE='post-down'
VERBOSITY='0'

==> /etc/test/post-up <==
ADDRFAM='meta'
IFACE='--all'
LOGICAL='auto'
METHOD='none'
MODE='start'
PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
PHASE='post-up'
VERBOSITY='0'

==> /etc/test/pre-down <==
ADDRFAM='inet'
IFACE='eno1'
IF_ADDRESS='192.168.0.3'
IF_BROADCAST='192.168.0.255'
IF_DNSNAMESERVERS='193.213.112.4
IF_GATEWAY='192.168.0.1'
IF_HOSTNAME='hopper'
IF_NETMASK='255.255.255.0'
LOGICAL='eno1'
METHOD='static'
MODE='stop'
PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
PHASE='pre-down'
VERBOSITY='0'

==> /etc/test/pre-up <==
ADDRFAM='inet'
IFACE='lo'
LOGICAL='lo'
METHOD='loopback'
MODE='start'
PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
PHASE='pre-up'
VERBOSITY='0'

As you can see the IF_* variables were created in the 'pre-down' phase
but not in the 'post-up' as expected.

I would expect that some of the code in the ifdown program should have
been in the ifup program.

VERSIONS
Distribution: Ubuntu 16.04 (LTS) (latest and greatest)
ifupdown 0.8.10ubuntu1.1 amd64

I also found this one 
(search for "IF_" )

** Affects: ifupdown (Ubuntu)
 Importance: Undecided
 Status: New

** Description changed:

  SYMPTOM
  My computer is set up with static IP on interface eno1 and running 'sudo apt 
update' fails. Adding nameserver aaa.bbb.ccc.ddd in resolv.conf helps, as a 
workaround, but this is reset on reboot.  Another workaround is to create a 
secondary IP on the same interface using DHCP (it works), but I don't want that.
  
- I have traced the problem to the IF_* variables not being set at "post-
- up" phase, where resolvconf tries to get the values.  (see 000resolvconf
- file in /etc/network/if-up.d.)
+ ANALYSIS
+ I have traced the problem to the IF_* variables not being set at "post-up" 
phase, where resolvconf tries to get the values.  (see 000resolvconf file in 
/etc/network/if-up.d.)
  
  To verify this I created a script named dbg which I placed in all the 
if-*.d folders:
  # Start
  DBGDIR=/etc/test
  mkdir -p $DBGDIR
  DEBUGFILE=$DBGDIR/$PHASE
  
  set  | grep -E 
"^(IF_|(IFACE|LOGICAL|ADDRFAM|METHOD|MODE|PHASE|VERBOSITY|PATH)\b)" > $DEBUGFILE
  #--- end
  
  (For some reason the mkdir command did not work, so I created the directory 
manually.)
  These where the resulting files (listed with tail -n20 ...):
  ==> /etc/test/post-down <==
  ADDRFAM='meta'
  IFACE='--all'
  LOGICAL='auto'
  METHOD='none'
  MODE='stop'
  PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
  PHASE='post-down'
  VERBOSITY='0'
  
  ==> /etc/test/post-up <==
  ADDRFAM='meta'
  IFACE='--all'
  LOGICAL='auto'
  METHOD='none'
  MODE='start'
  PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
  PHASE='post-up'
  VERBOSITY='0'
  
  ==> /etc/test/pre-down <==
  ADDRFAM='inet'
  IFACE='eno1'
  IF_ADDRESS='192.168.0.3'
  IF_BROADCAST='192.168.0.255'
  IF_DNSNAMESERVERS='193.213.112.4
  IF_GATEWAY='192.168.0.1'
  IF_HOSTNAME='hopper'
  IF_NETMASK='255.255.255.0'
  LOGICAL='eno1'
  METHOD='static'
  MODE='stop'
  PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
  PHASE='pre-down'
  VERBOSITY='0'
  
  ==> /etc/test/pre-up <==
  ADDRFAM='inet'
  IFACE='lo'
  LOGICAL='lo'
  METHOD='loopback'
  MODE='start'
  PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
  PHASE='pre-up'
  VERBOSITY='0'
  
  As you can see the IF_* variables were created in the 'pre-down' phase
  but not in the 'post-up' as expected.
  
  I would expect that some of the code in the ifdown program should have
  been in the ifup program.
  
- 
  VERSIONS
  Distribution: Ubuntu 16.04 (LTS) (latest and greatest)
  ifupdown 0.8.10ubuntu1.1 amd64

** Description changed:

  SYMPTOM
  My computer is set up with static IP on interface eno1 and r