[Touch-packages] [Bug 2017196] Re: package pipewire-alsa (not installed) failed to install/upgrade: conflicting packages - not installing pipewire-alsa:amd64 [pipewire-alsa conflicts with pulseaudio]
I realize that the conflict is probably intended and my issue is that vanilla-gnome-desktop relies on pulseaudio still. I'll create a separate bug, sorry. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/2017196 Title: package pipewire-alsa (not installed) failed to install/upgrade: conflicting packages - not installing pipewire-alsa:amd64 [pipewire- alsa conflicts with pulseaudio] Status in pipewire package in Ubuntu: Confirmed Status in pulseaudio package in Ubuntu: Confirmed Bug description: Upgrading from UBUNTU 22.10 to UBUNTU 23.04 as advised. Required software appeared to have downloaded. Committing Changes operated to about 84% at which point the system crashed. It was necessary to re- initiate the upgrade procedure. This time, the upgrade proceeded to about 95% when an error notification appeared on the screen. Further upgrades were not attempted. ProblemType: Package DistroRelease: Ubuntu 22.10 Package: pipewire-alsa (not installed) ProcVersionSignature: Ubuntu 5.19.0-40.41-generic 5.19.17 Uname: Linux 5.19.0-40-generic x86_64 ApportVersion: 2.23.1-0ubuntu3.2 Architecture: amd64 CasperMD5CheckResult: unknown Date: Fri Apr 21 04:46:04 2023 ErrorMessage: conflicting packages - not installing pipewire-alsa:amd64 InstallationDate: Installed on 2020-02-04 (1171 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) Python3Details: /usr/bin/python3.10, Python 3.10.7, python3-minimal, 3.10.6-1 PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.18-9 RebootRequiredPkgs: Error: path contained symlinks. RelatedPackageVersions: dpkg 1.21.9ubuntu1 apt 2.5.3 SourcePackage: pipewire Title: package pipewire-alsa (not installed) failed to install/upgrade: conflicting packages - not installing pipewire-alsa:amd64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/2017196/+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 2017196] Re: package pipewire-alsa (not installed) failed to install/upgrade: conflicting packages - not installing pipewire-alsa:amd64 [pipewire-alsa conflicts with pulseaudio]
I seem to hit the same dep issues on a freshly installed 23.04 system when trying to install vanilla-gnome-desktop. The following packages have unmet dependencies: pipewire-alsa : Conflicts: pulseaudio but 1:16.1+dfsg1-2ubuntu3 is to be installed pipewire-audio : Conflicts: pulseaudio but 1:16.1+dfsg1-2ubuntu3 is to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/2017196 Title: package pipewire-alsa (not installed) failed to install/upgrade: conflicting packages - not installing pipewire-alsa:amd64 [pipewire- alsa conflicts with pulseaudio] Status in pipewire package in Ubuntu: Confirmed Status in pulseaudio package in Ubuntu: Confirmed Bug description: Upgrading from UBUNTU 22.10 to UBUNTU 23.04 as advised. Required software appeared to have downloaded. Committing Changes operated to about 84% at which point the system crashed. It was necessary to re- initiate the upgrade procedure. This time, the upgrade proceeded to about 95% when an error notification appeared on the screen. Further upgrades were not attempted. ProblemType: Package DistroRelease: Ubuntu 22.10 Package: pipewire-alsa (not installed) ProcVersionSignature: Ubuntu 5.19.0-40.41-generic 5.19.17 Uname: Linux 5.19.0-40-generic x86_64 ApportVersion: 2.23.1-0ubuntu3.2 Architecture: amd64 CasperMD5CheckResult: unknown Date: Fri Apr 21 04:46:04 2023 ErrorMessage: conflicting packages - not installing pipewire-alsa:amd64 InstallationDate: Installed on 2020-02-04 (1171 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) Python3Details: /usr/bin/python3.10, Python 3.10.7, python3-minimal, 3.10.6-1 PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.18-9 RebootRequiredPkgs: Error: path contained symlinks. RelatedPackageVersions: dpkg 1.21.9ubuntu1 apt 2.5.3 SourcePackage: pipewire Title: package pipewire-alsa (not installed) failed to install/upgrade: conflicting packages - not installing pipewire-alsa:amd64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/2017196/+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 1886728] Re: OpenVPN OTP replaces the ordinary password
This is still an issue in Ubuntu 21.04 (development, as of March 30, 2021) It looks like people have been complaining about this for years, and while some people have tried to fix it, those fixes never made it in. Surely it must be of some type of urgency to support 2FA one-time passwords in the primary network management solution in Ubuntu? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1886728 Title: OpenVPN OTP replaces the ordinary password Status in NetworkManager: Unknown Status in network-manager package in Ubuntu: Triaged Bug description: When OpenVPN has One-time password (OTP) enabled, and the user connects, a dialog asks the user to enter the One-time password (OTP) and press ok. This action replaces the ordinary "long term" password with the OTP. This causes annoyance as the next login will fail because the password is wrong and the user has to enter both the password and the OTP the next time they log in. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-keyring 3.36.0-1ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44 Uname: Linux 5.4.0-40-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.3 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Wed Jul 8 01:07:18 2020 InstallationDate: Installed on 2020-03-23 (106 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) SourcePackage: gnome-keyring UpgradeStatus: Upgraded to focal on 2020-05-11 (57 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1886728/+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 1879087] Re: dbus errors, frequent roaming and unstable connectivity
Never mind - Somehow my local package simply looked newer from a versioning perspective. I found the right version and as far as I can tell the problems are gone in this version. I have not seen any of the dbus messages and roaming works better (less erratic) here. Thanks a lot for getting this fix in. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1879087 Title: dbus errors, frequent roaming and unstable connectivity Status in wpa package in Ubuntu: Fix Released Status in wpa source package in Focal: Fix Released Bug description: * Impact extra roaming events are been generated * Test case check the output of `journalctl -lu wpa_supplicant`, it shouldn't have those warnings dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 the roaming events should not be too frequent * Regression potential check that wifi connection keep working correctly -- When using this version of wpa_supplicant with my company WPA2-Enterprise wireless setup, I'm experiencing far too frequent roaming events (even when not moving around) accompanied by hiccups in connectivity. I also see these messages in the wpa_supplicant log: dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property RoamTime in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/3 Having done a little research, at least the dbus errors seem to be fixed by this commit upstream: https://w1.fi/cgit/hostap/commit/wpa_supplicant/dbus/dbus_new.c?id=23d87687c2428f3b94865580b0d33e05c03e6756 So I built a version of wpa_supplicant including this particular patch and installed on my machine. Apart from solving the dbus errors completely, it seems to have had a positive impact on the frequent roaming and unstable connectivity as well (I've run for a day with no burst of roaming events at all, where they used to happen every few minutes most of the time.) ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: wpasupplicant 2:2.9-1ubuntu4 ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: GNOME Date: Sat May 16 16:47:27 2020 InstallationDate: Installed on 2020-05-12 (4 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: wpa UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1879087/+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 1879087] Re: dbus errors, frequent roaming and unstable connectivity
I've been looking for the package but cannot seem to find it for testing. Please help me find it and I will test it immediately. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1879087 Title: dbus errors, frequent roaming and unstable connectivity Status in wpa package in Ubuntu: Fix Released Status in wpa source package in Focal: Fix Released Bug description: * Impact extra roaming events are been generated * Test case check the output of `journalctl -lu wpa_supplicant`, it shouldn't have those warnings dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 the roaming events should not be too frequent * Regression potential check that wifi connection keep working correctly -- When using this version of wpa_supplicant with my company WPA2-Enterprise wireless setup, I'm experiencing far too frequent roaming events (even when not moving around) accompanied by hiccups in connectivity. I also see these messages in the wpa_supplicant log: dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property RoamTime in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/3 Having done a little research, at least the dbus errors seem to be fixed by this commit upstream: https://w1.fi/cgit/hostap/commit/wpa_supplicant/dbus/dbus_new.c?id=23d87687c2428f3b94865580b0d33e05c03e6756 So I built a version of wpa_supplicant including this particular patch and installed on my machine. Apart from solving the dbus errors completely, it seems to have had a positive impact on the frequent roaming and unstable connectivity as well (I've run for a day with no burst of roaming events at all, where they used to happen every few minutes most of the time.) ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: wpasupplicant 2:2.9-1ubuntu4 ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: GNOME Date: Sat May 16 16:47:27 2020 InstallationDate: Installed on 2020-05-12 (4 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: wpa UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1879087/+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 1879087] Re: dbus errors, frequent roaming and unstable connectivity
Thank you for taking care of this so swiftly. I don't believe I have much to add to the test-case. From testing locally I can see that the warnings disappear from the log and the connection _seems_ more stable. I underscore _seems_ because I have not been able to figure out which other parts of the system are actually using these particular dbus messages, if any. If nobody is actually using these, the perceived improvement could be placebo. I will keep testing though, because I've generally been struggling with a stable wifi connection on 20.04. Thanks again. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1879087 Title: dbus errors, frequent roaming and unstable connectivity Status in wpa package in Ubuntu: Fix Committed Bug description: * Impact extra roaming events are been generated * Test case check the wpa_supplicant log, it should have warnings dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 the roaming events should not be too frequent * Regression potential check that wifi connection keep working correctly -- When using this version of wpa_supplicant with my company WPA2-Enterprise wireless setup, I'm experiencing far too frequent roaming events (even when not moving around) accompanied by hiccups in connectivity. I also see these messages in the wpa_supplicant log: dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property RoamTime in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/3 Having done a little research, at least the dbus errors seem to be fixed by this commit upstream: https://w1.fi/cgit/hostap/commit/wpa_supplicant/dbus/dbus_new.c?id=23d87687c2428f3b94865580b0d33e05c03e6756 So I built a version of wpa_supplicant including this particular patch and installed on my machine. Apart from solving the dbus errors completely, it seems to have had a positive impact on the frequent roaming and unstable connectivity as well (I've run for a day with no burst of roaming events at all, where they used to happen every few minutes most of the time.) ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: wpasupplicant 2:2.9-1ubuntu4 ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: GNOME Date: Sat May 16 16:47:27 2020 InstallationDate: Installed on 2020-05-12 (4 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: wpa UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1879087/+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 1879087] [NEW] dbus errors, frequent roaming and unstable connectivity
Public bug reported: When using this version of wpa_supplicant with my company WPA2-Enterprise wireless setup, I'm experiencing far too frequent roaming events (even when not moving around) accompanied by hiccups in connectivity. I also see these messages in the wpa_supplicant log: dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property RoamTime in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/3 Having done a little research, at least the dbus errors seem to be fixed by this commit upstream: https://w1.fi/cgit/hostap/commit/wpa_supplicant/dbus/dbus_new.c?id=23d87687c2428f3b94865580b0d33e05c03e6756 So I built a version of wpa_supplicant including this particular patch and installed on my machine. Apart from solving the dbus errors completely, it seems to have had a positive impact on the frequent roaming and unstable connectivity as well (I've run for a day with no burst of roaming events at all, where they used to happen every few minutes most of the time.) ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: wpasupplicant 2:2.9-1ubuntu4 ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: GNOME Date: Sat May 16 16:47:27 2020 InstallationDate: Installed on 2020-05-12 (4 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: wpa UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: wpa (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1879087 Title: dbus errors, frequent roaming and unstable connectivity Status in wpa package in Ubuntu: New Bug description: When using this version of wpa_supplicant with my company WPA2-Enterprise wireless setup, I'm experiencing far too frequent roaming events (even when not moving around) accompanied by hiccups in connectivity. I also see these messages in the wpa_supplicant log: dbus: wpa_dbus_property_changed: no property RoamComplete in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property RoamTime in object /fi/w1/wpa_supplicant1/Interfaces/3 dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/3 Having done a little research, at least the dbus errors seem to be fixed by this commit upstream: https://w1.fi/cgit/hostap/commit/wpa_supplicant/dbus/dbus_new.c?id=23d87687c2428f3b94865580b0d33e05c03e6756 So I built a version of wpa_supplicant including this particular patch and installed on my machine. Apart from solving the dbus errors completely, it seems to have had a positive impact on the frequent roaming and unstable connectivity as well (I've run for a day with no burst of roaming events at all, where they used to happen every few minutes most of the time.) ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: wpasupplicant 2:2.9-1ubuntu4 ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34 Uname: Linux 5.4.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: GNOME Date: Sat May 16 16:47:27 2020 InstallationDate: Installed on 2020-05-12 (4 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: wpa UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1879087/+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
Re: [Touch-packages] [Bug 1734967] Re: tzdata info for WGT/WGST broken
I have started a dialogue on the TZ mailinglist to perhaps have the change (WGT/WGST at least) reverted. That's my goal anyway, so we'll see how it goes. /Thomas -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tzdata in Ubuntu. https://bugs.launchpad.net/bugs/1734967 Title: tzdata info for WGT/WGST broken Status in php5 package in Ubuntu: New Status in php7.0 package in Ubuntu: New Status in php7.1 package in Ubuntu: New Status in tzdata package in Ubuntu: Invalid Status in php7.0 package in Debian: New Bug description: Using "America/Godthab" timezone, "WGT/WGST" is no longer displayed from date command but instead just "-03". Problem is evident in PHP applications too, which now think we're in Sao Paolo. This appears to have changed with latest tzdata update or perhaps in combination with change from DST. Same problem on 16.04, 17.10 and Debian 9. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1734967/+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 1734967] Re: tzdata info for WGT/WGST broken
Hi guys, The removal of WGT/WGST from tzdata is crazy to me. Living in Greenland, I can imagine a bunch of different issues this will cause, so I'll try to figure out what is going on and what possibilities we have of rectifying it. Starting with upstream. /Thomas -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tzdata in Ubuntu. https://bugs.launchpad.net/bugs/1734967 Title: tzdata info for WGT/WGST broken Status in php5 package in Ubuntu: New Status in php7.0 package in Ubuntu: New Status in php7.1 package in Ubuntu: New Status in tzdata package in Ubuntu: Invalid Status in php7.0 package in Debian: New Bug description: Using "America/Godthab" timezone, "WGT/WGST" is no longer displayed from date command but instead just "-03". Problem is evident in PHP applications too, which now think we're in Sao Paolo. This appears to have changed with latest tzdata update or perhaps in combination with change from DST. Same problem on 16.04, 17.10 and Debian 9. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1734967/+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 1734967] [NEW] tzdata info for WGT/WGST broken
Public bug reported: Using "America/Godthab" timezone, "WGT/WGST" is no longer displayed from date command but instead just "-03". Problem is evident in PHP applications too, which now think we're in Sao Paolo. This appears to have changed with latest tzdata update or perhaps in combination with change from DST. Same problem on 16.04, 17.10 and Debian 9. ** Affects: tzdata (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tzdata in Ubuntu. https://bugs.launchpad.net/bugs/1734967 Title: tzdata info for WGT/WGST broken Status in tzdata package in Ubuntu: New Bug description: Using "America/Godthab" timezone, "WGT/WGST" is no longer displayed from date command but instead just "-03". Problem is evident in PHP applications too, which now think we're in Sao Paolo. This appears to have changed with latest tzdata update or perhaps in combination with change from DST. Same problem on 16.04, 17.10 and Debian 9. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1734967/+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 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
@Vincent, re the "If lookups are routed to multiple interfaces, the first successful response is returned", this is indeed the problem with systemd-resolved as I see it, as that method will never be stable for a split DNS setup... You can never reliably predict if you'll get a good or a bad IP for the connections you're currently using. dnsmasq allows a solution to this, because NetworkManager can tell dnsmasq to use the LAN DNS for default stuff, but use the VPN DNS for lookups in the example.lan domain and 10.in-addr.arpa, for example. The dhcp-options you mention is for a direct call to openvpn if I'm not mistaken(?). That would work if you're content with launching every VPN connection by hand. In my case, I use a bunch of different VPN clients and as such, solving this in NetworkManager is a much more universally applicable fix. -- 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/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+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 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
To clarify... I believe NetworkManager is the culprit here - or systemd- resolved is fundamentally broken (i don't have the working knowledge to guess which it is). So my comment #44 is more about getting a working system than addressing any issue with systemd and/or NetworkManager. -- 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/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+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 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
So I have come up with a working solution that actually solves all MY needs in this regard. Hopefully it will be of use or inspiration to some of you guys too... Part 1 -- Switch NetworkManager to use dnsmasq (this will NOT work with resolved!) # apt-get install dnsmasq-base Add dns=dnsmasq to /etc/NetworkManager/NetworkManager.conf [main] section # systemctl disable systemd-resolved # systemctl stop systemd-resolved # systemctl restart network-manager Part 2 -- Modify VPN configuration (in /etc/NetworkManager/system-connections) DNS, Routes and reverse IP for the VPN networks can be tricked to work by modifying the [ipv4] section of the VPN configuration file: dns-search=example.lan;example2.lan;example.net # <-- make sure dns requests for these domains and all subdomains are sent to the VPN DNS servers, allowing the split DNS to work never-default=true # <-- make sure the VPN will not be made the default route ignore-auto-routes=true # <-- if you want to manually select the routes route1=192.168.1.0/24 # <-- sets up a route - with reverse dns forwarding to the vpn dns server for network 1 route2=192.168.2.0/24 # <-- sets up a route - with reverse dns forwarding to the vpn dns server for network 2 -- 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/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+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 1634208] Re: VPN cannot resolve DNS entries on second connect
*** This bug is a duplicate of bug 1624317 *** https://bugs.launchpad.net/bugs/1624317 ** This bug is no longer a duplicate of bug 1629611 dns server priority broken ** This bug has been marked a duplicate of bug 1624317 systemd-resolved breaks VPN with split-horizon DNS -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1634208 Title: VPN cannot resolve DNS entries on second connect Status in network-manager package in Ubuntu: Confirmed Bug description: Ubuntu 16.10 The first time I connect to a VPN (vpnc) everything works fine, but if I disconnect and then reconnect I can no longer resolve DNS entries although I can connect directly via IP address. The only solution seems to be a reboot. This was working fine in 16.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1634208/+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 1629611] Re: dns server priority broken
*** This bug is a duplicate of bug 1624317 *** https://bugs.launchpad.net/bugs/1624317 This is not fixed, but is marked as a duplicate of #1624317 ** This bug has been marked a duplicate of bug 1624317 systemd-resolved breaks VPN with split-horizon DNS -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in NetworkManager-OpenVPN: New Status in network-manager-vpnc: New Status in network-manager package in Ubuntu: Confirmed Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager-openvpn/+bug/1629611/+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 1629276] Re: network-manager ignoring DNS settings in wifi connections
*** This bug is a duplicate of bug 1624317 *** https://bugs.launchpad.net/bugs/1624317 ** This bug is no longer a duplicate of bug 1629611 dns server priority broken ** This bug has been marked a duplicate of bug 1624317 systemd-resolved breaks VPN with split-horizon DNS -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629276 Title: network-manager ignoring DNS settings in wifi connections Status in network-manager package in Ubuntu: Confirmed Bug description: Since updating to network-manager 1.2.4-0ubuntu1 and libnss-resolve 231-7 on the 28th, yakkety is now ignoring manual DNS settings on wifi connections. The resolv.conf file is points to 127.0.1.1 instead of what is configured in the connection. To recreate --- On Ubuntu 16.10 (fully patched as of 2016-09-30): 1) Create an ipv4 wifi connection, with a manually set a dns server. 2) Connect to that wifi connection 3) Test name resolution - it will still be using 127.0.1.1 instead of your manually configured server This might be considered a security problem for people that use special DNS configurations or dnscrypt. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: network-manager 1.2.4-0ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-9136.55-generic 4.4.16 Uname: Linux 4.4.0-9136-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.3-0ubuntu7 Architecture: amd64 CurrentDesktop: Unity:Unity7 Date: Fri Sep 30 05:47:57 2016 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 192.168.9.240 dev wlp3s0 proto static metric 600 169.254.0.0/16 dev wlp3s0 scope link metric 1000 192.168.9.0/24 dev wlp3s0 proto kernel scope link src 192.168.9.153 metric 600 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-dev: DEVICETYPE STATEDBUS-PATH CONNECTION CON-UUID CON-PATH wlp3s0wifi connected /org/freedesktop/NetworkManager/Devices/0 dusk f7b9d8b8-06b6-4d6a-850b-cfd4ebec44ab /org/freedesktop/NetworkManager/ActiveConnection/0 enp2s0f1 ethernet unavailable /org/freedesktop/NetworkManager/Devices/1 -- -- -- hfp/org/bluez/hci0/dev_4C_7C_5F_9E_A6_3C gsm unavailable /org/freedesktop/NetworkManager/Devices/3 -- -- -- loloopback unmanaged /org/freedesktop/NetworkManager/Devices/2 -- -- -- nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.2.4connected started full enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1629276/+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 1633003] Re: (Cisco) VPN name resolution breaks after upgrade to 1.2.2-0ubuntu0.16.04.3
*** This bug is a duplicate of bug 1624317 *** https://bugs.launchpad.net/bugs/1624317 ** This bug is no longer a duplicate of bug 1629611 dns server priority broken ** This bug has been marked a duplicate of bug 1624317 systemd-resolved breaks VPN with split-horizon DNS -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1633003 Title: (Cisco) VPN name resolution breaks after upgrade to 1.2.2-0ubuntu0.16.04.3 Status in network-manager package in Ubuntu: Confirmed Bug description: After upgrading my 16.04 installation today I noticed my VPN sessions suddenly had no name resolution anymore. Digging through /var/log/apt/history.log I noticed these were the updates: Start-Date: 2016-10-13 09:00:37 Commandline: apt dist-upgrade Requested-By: jeroenr (1000) Upgrade: libnm-glib4:amd64 (1.2.2-0ubuntu0.16.04.1, 1.2.2-0ubuntu0.16.04.3), libsystemd0:amd64 (229-4ubuntu10, 229-4ubuntu11), libsystemd0:i386 (229-4ubuntu10, 229-4ubuntu11), libdbusmenu-glib4:amd64 (12.10.3+16.04.20160223.1-0ubuntu1, 16.04.1+16.04.20160927-0ubuntu1), google-chrome-stable:amd64 (53.0.2785.143-1, 54.0.2840.59-1), libnm-glib-vpn1:amd64 (1.2.2-0ubuntu0.16.04.1, 1.2.2-0ubuntu0.16.04.3), udev:amd64 (229-4ubuntu10, 229-4ubuntu11), libnm0:amd64 (1.2.2-0ubuntu0.16.04.1, 1.2.2-0ubuntu0.16.04.3), network-manager:amd64 (1.2.2-0ubuntu0.16.04.1, 1.2.2-0ubuntu0.16.04.3), libdbusmenu-gtk4:amd64 (12.10.3+16.04.20160223.1-0ubuntu1, 16.04.1+16.04.20160927-0ubuntu1), kbd:amd64 (1.15.5-1ubuntu4, 1.15.5-1ubuntu5), libudev1:amd64 (229-4ubuntu10, 229-4ubuntu11), libudev1:i386 (229-4ubuntu10, 229-4ubuntu11), libnm-util2:amd64 (1.2.2-0ubuntu0.16.04.1, 1.2.2-0ubuntu0.16.04.3), libappstream-glib8:amd64 (0.5.13-1ubuntu3, 0.5.13-1ubuntu4), gnome-calculator:amd64 (1:3.18.3-0ubuntu1, 1:3.18.3-0 ubuntu1.16.04.1), systemd-sysv:amd64 (229-4ubuntu10, 229-4ubuntu11), libpam-systemd:amd64 (229-4ubuntu10, 229-4ubuntu11), systemd:amd64 (229-4ubuntu10, 229-4ubuntu11), gir1.2-dbusmenu-glib-0.4:amd64 (12.10.3+16.04.20160223.1-0ubuntu1, 16.04.1+16.04.20160927-0ubuntu1), libdbusmenu-gtk3-4:amd64 (12.10.3+16.04.20160223.1-0ubuntu1, 16.04.1+16.04.20160927-0ubuntu1), lightdm:amd64 (1.18.2-0ubuntu2, 1.18.3-0ubuntu1), liblightdm-gobject-1-0:amd64 (1.18.2-0ubuntu2, 1.18.3-0ubuntu1) End-Date: 2016-10-13 09:01:06 After downloading version 1.2.2-0ubuntu0.16.04.1 copies of libnm-glib- vpn1:amd64 libnm-glib4:amd64 libnm-util2:amd64 libnm0:amd64 network- manager:amd64 and installing them via: sudo -H dpkg -i *.deb my name resolution started working again. Additional information: % lsb_release -rd Description: Ubuntu 16.04.1 LTS Release: 16.04 % apt-cache policy libnm-glib-vpn1 libnm-glib4 libnm-util2 libnm0 network-manager libnm-glib-vpn1: Installed: 1.2.2-0ubuntu0.16.04.1 Candidate: 1.2.2-0ubuntu0.16.04.3 Version table: 1.2.2-0ubuntu0.16.04.3 500 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 1.2.2-0ubuntu0.16.04.1 100 100 /var/lib/dpkg/status 1.1.93-0ubuntu4 500 500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages libnm-glib4: Installed: 1.2.2-0ubuntu0.16.04.1 Candidate: 1.2.2-0ubuntu0.16.04.3 Version table: 1.2.2-0ubuntu0.16.04.3 500 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 1.2.2-0ubuntu0.16.04.1 100 100 /var/lib/dpkg/status 1.1.93-0ubuntu4 500 500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages libnm-util2: Installed: 1.2.2-0ubuntu0.16.04.1 Candidate: 1.2.2-0ubuntu0.16.04.3 Version table: 1.2.2-0ubuntu0.16.04.3 500 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 1.2.2-0ubuntu0.16.04.1 100 100 /var/lib/dpkg/status 1.1.93-0ubuntu4 500 500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages libnm0: Installed: 1.2.2-0ubuntu0.16.04.1 Candidate: 1.2.2-0ubuntu0.16.04.3 Version table: 1.2.2-0ubuntu0.16.04.3 500 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 1.2.2-0ubuntu0.16.04.1 100 100 /var/lib/dpkg/status 1.1.93-0ubuntu4 500 500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages network-manager: Installed: 1.2.2-0ubuntu0.16.04.1 Candidate: 1.2.2-0ubuntu0.16.04.3 Version table: 1.2.2-0ubuntu0.16.04.3 500 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 1.2.2-0ubuntu0.16.04.1 100 100 /var/lib/dpkg/status 1.1.93-0ubuntu4 500 500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages % apt-cache policy vpnc vpnc: Installed: 0.5.3r550-2build1
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
I'm on 17.04 too and suffering from this issue for a while. As I understand this issue, the problem may actually very well be in Network-Manager rather than in systemd-resolved, but the problem is indeed very visible with resolved. Here's how I experience the problem (the root of my problems are a split DNS setup, just like most other people following this ticket). This is the state of my resolved... With no VPN connected (wireless and wifi only): Link 7 (vpn0) Current Scopes: none LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no Link 3 (wlp4s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 192.168.8.1 DNS Domain: int.example.com Link 2 (enp0s31f6) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 192.168.8.1 DNS Domain: int.example.com With VPN connected: Link 7 (vpn0) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 192.168.180.48 192.168.180.49 DNS Domain: example.lan Link 3 (wlp4s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 192.168.8.1 DNS Domain: int.example.com Link 2 (enp0s31f6) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 192.168.8.1 DNS Domain: int.example.com Now, I have one split DNS entry, testserver.example.net. On a public DNS, it will resolve to a public IP - On the example.lan DNS servers, it will resolve to a private IP. Doing the following a couple of times is bound to sometimes return the private IP and sometimes the public IP: systemd-resolve --flush-caches && ping -c1 testserver.example.net So for things to work in this particular example, I'd need the 192.168.8.1 DNS to either be disabled completely or only used for int.example.com. 192.168.180.48 and 49 as provided by the VPN would somehow need to be the default/active nameserver. Note that for my VPN connection in Network Manager, I've *not* enabled the "use this connection only for resources on its own network". In an attempt to work around this problem, I decided to configure network-manager for dnsmasq, which worked fine back in the 16.04 days. Basically the setup worked, but Network-Manager only added the VPN DNS servers for the VPN provided search domain example.lan. Needless to say this works even worse than the resolved solution, because now I get the wrong answer for testserver.example.net every time. It does seem to indicates that perhaps there's something fishy about how network-manager passes DNS servers to resolved. I have not found a way to force network- manager to completely replace the configured DNS servers for a VPN connection, but that might provide a usable workaround. Hopefully this can shed some light on things? -- 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/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+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 1629611] Re: dns server priority broken
Seems to work in 1.4.4-1ubuntu3 in 17.04 at least... Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in NetworkManager-OpenVPN: New Status in network-manager-vpnc: New Status in network-manager package in Ubuntu: Confirmed Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager-openvpn/+bug/1629611/+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 1629611] Re: dns server priority broken
That is certainly a possibility, but unfortunately returns us to a state where applications have to be restarted when nameservers change (glibc resolved.conf issue). That's probably even worse in my situation at least. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in NetworkManager-OpenVPN: New Status in network-manager-vpnc: New Status in network-manager package in Ubuntu: Incomplete Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager-openvpn/+bug/1629611/+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 1629611] Re: dns server priority broken
Unfortunately not much traction here, and this appears to annoy people across distros. In the meantime, an ugly hack is to manually add all internal domains to the NetworkManager VPN config file's dns-search= parameter: dns-search=domain1.lan;domain2.lan;domain3.lan;example.com; This causes NetworkManager to split DNS all lookups for these domains to the VPN DNS server, but with the added overhead of searching through all domains for non-existing hostname queries (make sure the primary internal domains are mentioned first). Also, for a multi-city setup like ours, I need to add A LOT of domains to get a functional DNS while on VPN - Including in-addr.arpa specifications for all IP subnets. So there's a way to sweeten the deal - but this is by no means anything other than a hack. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in NetworkManager-OpenVPN: New Status in network-manager-vpnc: New Status in network-manager package in Ubuntu: Incomplete Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager-openvpn/+bug/1629611/+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 1629611] Re: dns server priority broken
Wow - Long message, but what I got from it was "I need to see a debug log", correct? I'll attach that... I'll also point you to the problematic part: Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1915] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.48@vpn0' for domain "workdom.lan" Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1915] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.48@vpn0' for domain "22.60.10.in-addr.arpa" Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1916] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.48@vpn0' for domain "23.60.10.in-addr.arpa" Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1916] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.49@vpn0' for domain "workdom.lan" Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1916] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.49@vpn0' for domain "22.60.10.in-addr.arpa" Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1916] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.49@vpn0' for domain "23.60.10.in-addr.arpa" Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1916] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.48@enp0s31f6' Dec 5 15:14:48 bar14860 NetworkManager[921]: [1480961688.1917] dnsmasq[0x560b551920f0]: adding nameserver '10.60.180.49@enp0s31f6' Now for this test, I'm using the same DNS before and after, but the VPN connection adds DNS resolution using the VPN provided DNS ONLY for the domains it feels is behind the VPN, and there's nothing I can seemingly do to change that behaviour. This is the exact assumption that breaks VPN for many users. When I connect to VPN, especially one that becomes my default gateway, I need all DNS requests to go the the DNS servers behind the VPN. Need more info, let me know. ** Attachment added: "network-manager.log" https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1629611/+attachment/4787680/+files/network-manager.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in NetworkManager-OpenVPN: New Status in network-manager-vpnc: New Status in network-manager package in Ubuntu: Incomplete Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager-openvpn/+bug/1629611/+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 1629611] Re: dns server priority broken
Here's the thing, I'm on 16.10 which has the debian equiv listed as stretch/sid and my network-manager version is 1.2.4-0ubuntu1. Looking at Debian stretch and sid, they have network-manager packages in various versions but not 1.2.4. Furthermore, since Ubuntu employ their own patches, backports, versions, scripts, configuration etc, It'd be wrong of me to file this bug upstream, since I'd certainly risk wasting the Debian folks' time with something that might very well be Ubuntu specific. I simply cannot be certain. The only proper way to do this, would be for the Ubuntu maintainer to have a look at this bug and decide whether we're dealing with an Ubuntu specific config issue or something upstream and take the proper action upstream if needed. I have found similar but not identical reports in Debian, so I cannot reference anything that resembles duplicates. /T -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in network-manager package in Ubuntu: Confirmed Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1629611/+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 1629611] Re: dns server priority broken
I'll do it :) Any helpful pointers to which package/version i should reference, since I don't have the real debian version of this package anywhere? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in network-manager package in Ubuntu: Confirmed Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1629611/+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 1629611] Re: dns server priority broken
No, that does not seem like the problem to me - Or it's not described correctly. I can't seem to find a proper match in that list. resolv.conf is not the issue here - the problem is in the DNS servers that dnsmasq uses. I.e. one is added to dnsmasq when my wireless connection comes up, and when I launch my VPN, to more are APPENDED. And it seems like dnsmasq will try by wifi DNS first, VPN DNS later. So for split DNS, the VPN DNS servers are not queried at all, causing problems. The proper way is probably to PREPEND the VPN DNS servers to the list of DNS servers that dnsmasq uses or otherwise prioritize these over previously configured servers. That way everything should work as expected. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in network-manager package in Ubuntu: Confirmed Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1629611/+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 1592721] Re: Don't write search domains to resolv.conf in the case of split DNS
This bug seems to bite me in a slightly different way. Please let me know if you feel that this is really a separate bug... Also, this is happening on Yakkety - network-manager-1.2.4-0ubuntu1 When I connect to my work VPN, I'm not using split-tunnelling. Still the DNS resolution is split, causing DNS resolution to only be correct for my primary VPN search domain. This log snippet seems to explain it all: - 192.168.0.1 is my home ADSL DNS. - example.local is the search suffix provided by my VPN. - 10.10.10.12 and 10.10.10.13 are my VPN provided DNS servers. Oct 12 06:43:04 bar14860 NetworkManager[870]: [1476261784.8455] dns-mgr: Writing DNS information to /sbin/resolvconf Oct 12 06:43:04 bar14860 dnsmasq[1226]: setting upstream servers from DBus Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 192.168.0.1#53(via enp0s31f6) Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.12#53 for domain example.local Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.12#53 for domain 20.10.10.in-addr.arpa Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.12#53 for domain 21.10.10.in-addr.arpa Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.13#53 for domain example.local Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.13#53 for domain 20.10.10.in-addr.arpa Oct 12 06:43:04 bar14860 dnsmasq[1226]: using nameserver 10.10.10.13#53 for domain 21.10.10.in-addr.arpa Oct 12 06:43:04 bar14860 NetworkManager[870]: [1476261784.9543] policy: set 'vpn0' (vpn0) as default for IPv4 routing and DNS The result of this is that all my other internal work-domains does not work at all, and may, as the bug describes, leak onto the internet as well. If you need more info, let me know. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1592721 Title: Don't write search domains to resolv.conf in the case of split DNS Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Fix Released Bug description: [Impact] All VPN users meaning to use split-tunnelling in a situation where leaking DNS data to the internet about what might be behind their VPN is undesirable. [Test case] 1) connect to VPN 2) Use dig to request a name that should be on the VPN 3) Verify (kill -USR1 the dnsmasq binary from NM) that the request has only gone through the VPN nameservers (only its request number should have increased by one) 4) Use dig to request a name off-VPN, such as google.com. 5) Verify (kill -USR1 again) that the request has caused the non-VPN nameserver request number to increase, and that the VPN number has not increased. It is easier to verify this when there is as little traffic as possible on the system, to avoid spurious DNS requests which would make it harder to validate the counters. [Regression potential] This change modifies the way in which DNS nameservers and search domains are passed to dnsmasq, as such, if a VPN is configured in a non-standard way and intended to be used to resolve all network requests (which is typically not the case for split-tunnelling) or if the public network is intended to always resolve all requests while the VPN still provides search domains, one might observe incorrect behavior. Possible failure cases would include failure to resolve names correctly (resulting in NXDOMAIN or REFUSED from dnsmasq) or resolving to the incorrect values (if the wrong nameserver is used). --- Currently, NM will write all search domains to both any DNS-handling plugins running, and also to resolv.conf / resolvconf; in all cases. The issue is that doing so means that in the split-DNS case on VPNs, you might get a negative response from all nameservers, then a new request by glibc with the search tacked on, to nameservers again, which might cause DNS requests for "private" resources (say, on the VPN) to be sent to external, untrusted resolvers, or for DNS queries not meant for VPN nameservers to be sent through the VPN anyway. This is fixable in the case where we have a caching plugin running (such as dnsmasq). dnsmasq will already know about the search domains and use that to limit queries to the right nameservers when a VPN is running. Writing search domains to resolv.conf is unnecessary in this case. We should still write search domains if no caching gets done, as we then need to expect glibc to send requests as it otherwise would. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1592721/+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 1629611] [NEW] dns server priority broken
Public bug reported: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1629611 Title: dns server priority broken Status in network-manager package in Ubuntu: New Bug description: network-manager: 1.2.4-0ubuntu1 Yakkety appears to have switched back from resolved to dnsmasq, but it seems server priority/order is broken. Example: In split DNS setups, connecting to VPN will not cause us to query the DNS provided by the VPN first (or only), which should be the proper way to resolve names in that case. Say server.example.com in the public DNS resolves to a.a.a.a and in the private DNS resolves to b.b.b.b. Stuff would work from my normal internet-connection, but connection to VPN would cause stuff to misbehave. I expect to hit the b.b.b.b address but since my normal LAN DNS is being used first, I'm really hitting a.a.a.a. Please let me know how to proceed - Hopefully this can be fixed in time for release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1629611/+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 499773] Re: Race with ureadahead can mean that /var/lib/ureadahead/debugfs appears in /etc/mtab
open-vm-tools also chokes on this, when freezing filesystems for a quiesced snapshot -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mountall in Ubuntu. https://bugs.launchpad.net/bugs/499773 Title: Race with ureadahead can mean that /var/lib/ureadahead/debugfs appears in /etc/mtab Status in mountall package in Ubuntu: Triaged Bug description: When the system is booted, the mountall process may notice a temporarily-mounted file system at /var/lib/ureadahead/debugfs and record that fact in /etc/mtab. Later in the boot process, this file system is unmounted, but mountall doesn't record unmounts, so it never "forgets" this path when it's unmounted. Mountall should if necessary remove this mount from mtab. To confirm on your system that it is indeed not really mounted, look for it in /proc/self/mountinfo Otherwise this may be due to a crash of the ureadahead process during boot. original report Binary package hint: ureadahead $ mount /dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro) proc on /proc type proc (rw) none on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) udev on /dev type tmpfs (rw,mode=0755) none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) none on /dev/shm type tmpfs (rw,nosuid,nodev) none on /var/run type tmpfs (rw,nosuid,mode=0755) none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) none on /var/lib/ureadahead/debugfs type debugfs (rw) /dev/sda6 on /home type ext4 (rw,relatime) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) gvfs-fuse-daemon on /home/hildeb/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=hildeb) /var/lib/ureadahead/debugfs is left lingering around. It's use is somewhat limited, since most Ubuntu users are not kernel developers -- if it's used as intended: http://kerneltrap.org/node/4394 ProblemType: Bug Architecture: amd64 Date: Wed Dec 23 11:04:11 2009 DistroRelease: Ubuntu 9.10 NonfreeKernelModules: nvidia Package: ureadahead 0.90.3-2 ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-17.54-generic SourcePackage: ureadahead Uname: Linux 2.6.31-17-generic x86_64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/499773/+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 1532553] Re: /etc/halt.local has become /usr/sbin/halt.local
Hmmm I can't seem to find it documented anywhere, but last time I needed this to work was in the good old sysvinit days and it may have even been on a different distro. Sorry for not brushing thoroughly up on this, prior to filing this bug. I have checked with CentOS 7 and it has the halt.local placed in /usr/sbin/halt.local as well In any case, this is part of the rc-local type magic that systemd performs and with rc.local in /etc/rc.local, one could argue, that it makes sense for these scripts to be located together. But more importantly, user-maintained stuff in /usr/sbin/ is just bad practice and we should not encourage people to do that. /T -- 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/1532553 Title: /etc/halt.local has become /usr/sbin/halt.local Status in systemd package in Ubuntu: Incomplete Bug description: Ubuntu 15.10, amd64 systemd-225-1ubuntu9 /etc/halt.local seems to have moved to /usr/sbin/halt.local which IMO is bad for a couple of reasons. 1) This is not where it's supposed to be 2) Locally modified (non-dpkg managed) scripts under /usr is bad I have not been able to find anywhere documenting this as a decided change, so it seems like a bug to me. Please let me know if you need more info from me /Thomas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1532553/+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 1532553] Re: /etc/halt.local has become /usr/sbin/halt.local
You're absolutely right - Changed to systemd ** Package changed: transmission (Ubuntu) => systemd (Ubuntu) ** Changed in: systemd (Ubuntu) Status: Invalid => New -- 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/1532553 Title: /etc/halt.local has become /usr/sbin/halt.local Status in systemd package in Ubuntu: New Bug description: Ubuntu 15.10, amd64 systemd-225-1ubuntu9 /etc/halt.local seems to have moved to /usr/sbin/halt.local which IMO is bad for a couple of reasons. 1) This is not where it's supposed to be 2) Locally modified (non-dpkg managed) scripts under /usr is bad I have not been able to find anywhere documenting this as a decided change, so it seems like a bug to me. Please let me know if you need more info from me /Thomas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1532553/+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 1532553] Re: /etc/halt.local has become /usr/sbin/halt.local
Alright - Got your comments late, let me try that out Are these targets documented somewhere, so it becomes clear exactly what is started when? -- 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/1532553 Title: /etc/halt.local has become /usr/sbin/halt.local Status in systemd package in Ubuntu: Fix Committed Bug description: Ubuntu 15.10, amd64 systemd-225-1ubuntu9 /etc/halt.local seems to have moved to /usr/sbin/halt.local which IMO is bad for a couple of reasons. 1) This is not where it's supposed to be 2) Locally modified (non-dpkg managed) scripts under /usr is bad I have not been able to find anywhere documenting this as a decided change, so it seems like a bug to me. Please let me know if you need more info from me /Thomas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1532553/+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 1532553] Re: /etc/halt.local has become /usr/sbin/halt.local
systemd.special(7) explains what they are, but if I could somehow get the correlation between targets, that'd be cool -- 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/1532553 Title: /etc/halt.local has become /usr/sbin/halt.local Status in systemd package in Ubuntu: Fix Committed Bug description: Ubuntu 15.10, amd64 systemd-225-1ubuntu9 /etc/halt.local seems to have moved to /usr/sbin/halt.local which IMO is bad for a couple of reasons. 1) This is not where it's supposed to be 2) Locally modified (non-dpkg managed) scripts under /usr is bad I have not been able to find anywhere documenting this as a decided change, so it seems like a bug to me. Please let me know if you need more info from me /Thomas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1532553/+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 1532553] Re: /etc/halt.local has become /usr/sbin/halt.local
Fair enough... As mentioned earlier, this may be from a systemv time and perhaps from Red Hat, I'm not sure. I do know that /usr/sbin/halt.local works in both Wily and in debian 8 out of the box, the file is just located in dpkg- managed space, which makes no sense. Look, I'm not actually arguing that we keep this particular file, but I think we need to keep the functionality. /lib/systemd/system-shutdown/ seems to provide that functionality, but again, this is in dpkg-managed territory. Is there a user managed folder that is handled the same? If I need to create my own unit-file, I'd be happy to, but I've had a hard time figuring out the proper requiremends/dependencies/befores and afters that will make this the very last thing to run, just before the system prints "system halted". This is where the need for further documentation comes in (or perhaps I'm just too dense to find it) If you can help point me to somewhere that will allow me to figure our the correct dependencies etc for a new unit-file, I'll be happy to let this go :-) -- 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/1532553 Title: /etc/halt.local has become /usr/sbin/halt.local Status in systemd package in Ubuntu: Fix Committed Bug description: Ubuntu 15.10, amd64 systemd-225-1ubuntu9 /etc/halt.local seems to have moved to /usr/sbin/halt.local which IMO is bad for a couple of reasons. 1) This is not where it's supposed to be 2) Locally modified (non-dpkg managed) scripts under /usr is bad I have not been able to find anywhere documenting this as a decided change, so it seems like a bug to me. Please let me know if you need more info from me /Thomas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1532553/+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 1532553] Re: /etc/halt.local has become /usr/sbin/halt.local
In that case we are missing documentation for the shutdown/halt procedure more than ever. Very often halt.local is where we'd do stuff like powering off UPS outlets, to handle power-outage scenarios properly. It may not have been documented or placed ideally, but AFAIKT, it's actually always worked. Without the halt-local.service, we're missing that easy hook, as I see it. The nut package for one, does not include a systemd unit that can do the exact same thing, and to my experience, figuring out exactly which depencencies to create for a new unit tile to accomplish the same without breaking something else, is really not that well documented, or just not very easy to find. -- 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/1532553 Title: /etc/halt.local has become /usr/sbin/halt.local Status in systemd package in Ubuntu: Fix Committed Bug description: Ubuntu 15.10, amd64 systemd-225-1ubuntu9 /etc/halt.local seems to have moved to /usr/sbin/halt.local which IMO is bad for a couple of reasons. 1) This is not where it's supposed to be 2) Locally modified (non-dpkg managed) scripts under /usr is bad I have not been able to find anywhere documenting this as a decided change, so it seems like a bug to me. Please let me know if you need more info from me /Thomas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1532553/+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 1532553] Re: /etc/halt.local has become /usr/sbin/halt.local
Thowing user-managed executables in /lib/systemd/system-shutdown/ is not much better than editing /usr/sbin/halt.local. Is there an /etc or a /usr/local based version of this directory available somewhere, that will work out of the box, then that will work for me, i guess.. I'll try it out at least. -- 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/1532553 Title: /etc/halt.local has become /usr/sbin/halt.local Status in systemd package in Ubuntu: Fix Committed Bug description: Ubuntu 15.10, amd64 systemd-225-1ubuntu9 /etc/halt.local seems to have moved to /usr/sbin/halt.local which IMO is bad for a couple of reasons. 1) This is not where it's supposed to be 2) Locally modified (non-dpkg managed) scripts under /usr is bad I have not been able to find anywhere documenting this as a decided change, so it seems like a bug to me. Please let me know if you need more info from me /Thomas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1532553/+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 1532553] Re: /etc/halt.local has become /usr/sbin/halt.local
Also all other distros, regardless of init system, appears to have this file somewhere. Bad solution IMHO -- 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/1532553 Title: /etc/halt.local has become /usr/sbin/halt.local Status in systemd package in Ubuntu: Fix Committed Bug description: Ubuntu 15.10, amd64 systemd-225-1ubuntu9 /etc/halt.local seems to have moved to /usr/sbin/halt.local which IMO is bad for a couple of reasons. 1) This is not where it's supposed to be 2) Locally modified (non-dpkg managed) scripts under /usr is bad I have not been able to find anywhere documenting this as a decided change, so it seems like a bug to me. Please let me know if you need more info from me /Thomas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1532553/+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 1532553] Re: /etc/halt.local has become /usr/sbin/halt.local
Thank you for your input. It's not working how I want it to right now, but I'm confident it can be done. I need to read up on systemd for this to work. -- 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/1532553 Title: /etc/halt.local has become /usr/sbin/halt.local Status in systemd package in Ubuntu: Fix Committed Bug description: Ubuntu 15.10, amd64 systemd-225-1ubuntu9 /etc/halt.local seems to have moved to /usr/sbin/halt.local which IMO is bad for a couple of reasons. 1) This is not where it's supposed to be 2) Locally modified (non-dpkg managed) scripts under /usr is bad I have not been able to find anywhere documenting this as a decided change, so it seems like a bug to me. Please let me know if you need more info from me /Thomas To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1532553/+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
