debcrafters-packages team mailing list archive

[Andreas Hasenack <2083029@xxxxxxxxxxxxxxxxxx>]

Looks like this can proceed now, with questing open.

-- 
You received this bug notification because you are a member of
Debcrafters packages, which is subscribed to netplan.io in Ubuntu.
https://bugs.launchpad.net/bugs/2083029

Title:
  Try does not recover network

Status in Netplan:
  Fix Committed
Status in netplan.io package in Ubuntu:
  Confirmed
Status in netplan.io source package in Focal:
  Confirmed
Status in netplan.io source package in Jammy:
  Confirmed
Status in netplan.io source package in Noble:
  Triaged
Status in netplan.io source package in Oracular:
  Confirmed
Status in netplan.io source package in Plucky:
  Confirmed

Bug description:
  [ Impact ]

  `netplan try` fails to roll back network changes after an edit to
  /etc/netplan/50-cloud-init.yaml. This occurs using both networkd and
  NetworkManager backends.

  A user makes changes to their netplan configuration over ssh,
  expecting that if the ssh connection is lost, `netplan try` will roll
  back the change. Failure to do so may be highly inconvenient as a user
  may not have physical or console access to the machine they are
  configuring.

  There are two bugs represented here.

  In the networkd backend, networkd will only read new .netdev and
  .network files when their ownership is `root:systemd-network`. When
  `netplan try` backs up the generated networkd configuration, it
  ignores the ownership of the original file, using `root:root` instead.
  When `netplan try` rolls back the configuration, networkd does not
  load them.

  Since Ubuntu 23.10, NetworkManager stores automatically generated
  configuration in netplan yaml instead of GLib keyfiles [1].
  NetworkManager is patched in Ubuntu to support this functionality. The
  patches run `netplan generate` (via DBus) when NetworkManager reloads
  its configuration. When `netplan try` attempts to roll back to the old
  configuration, it restarts NetworkManager, which re-runs `netplan
  generate` with the new (unconfirmed configuration).

  [1] https://netplan.readthedocs.io/en/stable/netplan-everywhere/

  [ Test Plan ]

  `netplan apply` the default netplan configuration in a LXD instance
  (`/etc/netplan/50-cloud-init.yaml`):

  ```
  network:
      version: 2
      ethernets:
          enp5s0:
              dhcp4: true
  ```

  Replace the configuration with a static IP:

  ```
  network:
      version: 2
      ethernets:
          enp5s0:
              dhcp4: false
              addresses:
                - 10.58.215.80/24
  ```

   Run `netplan try --timeout 3` and allow the timeout to elapse.

  The IP assigned to the interface from `ip a` should be restored to the
  DHCP address.

  [ Where problems could occur ]

  The change that preserves file ownership for networkd affects code
  that is only used in `netplan try`; there are unlikely to be issues in
  netplan itself related to this change.

  The netplan generator change will block the netplan generator from
  running if `/run/netplan/netplan-try.ready` exists. If that file is
  not cleaned up, `netplan apply` will fail when it would not otherwise
  have done. The error message from the failure states that the file
  should be removed to force the apply to succeed.

  `/run/netplan/netplan-try.ready` is only created by netplan during
  `netplan try`; users using netplan without `netplan try` are unlikely
  to be affected.

  [Original Description]

  Netplan try fails to rollback network changes after an edit to /etc/netplan/50-cloud-init.yaml
  ```
  network:
      ethernets:
          eno1:
              addresses:
                - 10.1.0.221/23
                - 10.1.1.181/23
  ```
  I removed an IP address and ran "netplan try" and lost ssh. Connection should return after 2min, but that doesn't happen.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2083029/+subscriptions