Thursday, 23 February 2017

Re: Enabling Connectivity Checking in NetworkManager

On Thu, Feb 23, 2017 at 05:54:40PM +0000, Luke W Faraone wrote:
> On 22/02/17 21:24, Jeremy Bicha wrote:
> > Hi, back in July 2012 on this list, it was proposed that Ubuntu's
> > NetworkManager enable the new connectivity check feature by default.
> > Some concerns were raised and the feature never landed. I'd like to
> > reopen that discussion.

> > In 2014, Fedora enabled that feature by default but they did it using
> > a separate package. I really like this idea since it makes it very
> > easy for users to opt in or out of the connectivity check if they
> > choose.

> > I am proposing that we create a similar package. I would like to have
> > Ubuntu GNOME's metapackage recommend that config-connectivity package.

> Is there meaningful code included in ``config-connectivity``, or is it
> just a config package (as the name suggests)? If the latter, why not
> just make it a debconf question?

As a debconf question, it's more awkward to pre-configure the default
behavior on a per-flavor basis, and for users to know how to override it.

It's also a question of whether you want the behavior change to be tied to
the installation method (debconf preseed in the ISO mastering) vs. the
metapackage.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
[email protected] [email protected]

Re: Enabling Connectivity Checking in NetworkManager

-----BEGIN PGP SIGNATURE-----

iQJIBAEBCAAyFiEEET7ivDodqxaZwFfl2Ov4wRG5tSAFAlivIeEUHGxmYXJhb25l
QHVidW50dS5jb20ACgkQ2Ov4wRG5tSBm3g/+Ke1/v3cr8N4yy5Ywym5WJQgEnnFs
X9wbfLlZ1/umrbeBgxLQxSx6DBCqvExoldA36ZzxqG1GtUc2drA8X+7jDZEsDDR1
j0/jXjsfHFrSJtlJpJgOE3lb3DPa8PIQBkLuY4JMI781VoiCUzCouUyPw6n04VVR
lnZjZnX3vrZP+IG+Jh+xS3Rxpt3mXnJe7oXlsCrQK8M8Q2fk5DBnENdstZrQSrfE
NT18nDyXCusdLbIHf/BTWFFvnhrsS/7RJP2sWtMZNUywk3wv6miY8aIhmnMDIA9q
c2Wf8Ay9js6rzmBAFOpR/LikqRyBWRqXmsKpa97CawjR9F+xXAKvx3ASEG5moJFt
jhyjawfq7nEPXE7q1GPQQ50UuB9j58MLNTQ3f46/hI0e2K0zZ47qDiL2HwxSrcBN
TS1yfdxxmpc+QOgp6rTbuE8XcaYDu+C4vGE9/dT4h0ONC0rrTMvEbOv8SBZUwHmY
jf0F4WAs7rht/R6locpwIj90oFGlmW8gAR2zRyn8GrQ4Ro3L9O4Id01YlK9G2YFX
i0TgzdD7ySFOYjKeTsPDk3Ptt250ZFfPkFHTAXVbYgQ/C3WP9hXdNh+NOcR3ll7p
Vr9GbmdLndz2SkdKO0fJBLIilJSkQymBGeAghzXMry7eoY66bY/mwrTxP8JI3mm6
jnI92uhWJKPBPG4=
=2B4h
-----END PGP SIGNATURE-----
On 22/02/17 21:24, Jeremy Bicha wrote:
> Hi, back in July 2012 on this list, it was proposed that Ubuntu's
> NetworkManager enable the new connectivity check feature by default.
> Some concerns were raised and the feature never landed. I'd like to
> reopen that discussion.
>
> In 2014, Fedora enabled that feature by default but they did it using
> a separate package. I really like this idea since it makes it very
> easy for users to opt in or out of the connectivity check if they
> choose.
>
> I am proposing that we create a similar package. I would like to have
> Ubuntu GNOME's metapackage recommend that config-connectivity package.

Is there meaningful code included in ``config-connectivity``, or is it
just a config package (as the name suggests)? If the latter, why not
just make it a debconf question?

-- Luke Faraone

Wednesday, 22 February 2017

Re: Enabling Connectivity Checking in NetworkManager

Do this by default. In Ubuntu desktop too.

Also we must auto change desktop timezone too... (Separate issue)

I am volunteering as a tribute for any demands.

On 22 Feb 2017 21:25, "Jeremy Bicha" <[email protected]> wrote:
Hi, back in July 2012 on this list, it was proposed that Ubuntu's
NetworkManager enable the new connectivity check feature by default.
Some concerns were raised and the feature never landed. I'd like to
reopen that discussion.

In 2014, Fedora enabled that feature by default but they did it using
a separate package. I really like this idea since it makes it very
easy for users to opt in or out of the connectivity check if they
choose.

I am proposing that we create a similar package. I would like to have
Ubuntu GNOME's metapackage recommend that config-connectivity package.
In GNOME Shell, when a captive portal is detected, the network status
icon changes to include a question mark and a login window pointed to
the portal's login/authorization webpage appears. The login window is
powered by webkit2gtk. This is very similar to the implementation by
most other operating systems.

Here's the Feature Freeze exception bug and merge proposal:
https://launchpad.net/bugs/997200

Jeremy Bicha

--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: upcoming changes to Ubuntu cloud images via cloud-init

[Replying and adding ubuntu-cloud and ubuntu-cloud-announce]

In an effort to improve the performance and efficiency of Ubuntu's cloud
images[1], cloud-init is making some changes in the way that it searches
for datasources. By making use of environment information that platforms
provide such as DMI (Desktop Management Interface) data, cloud-init can
quickly filter out datasources that are not present.

The driver for doing this is to:

- Improve boot speed of Ubuntu images by quickly discarding datasources
that are not present.
- Avoid attempting to access network resources that may not be present.
That can result in timeouts or other unexpected behavior.
- Entirely disable cloud-init if no datasource is present.

Examples of such information that cloud-init will consider:

- OpenStack Nova populating the DMI system product name 'OpenStack Nova'.
- Google Compute Engine [2] populating the DMI system product name with
'Google Compute Engine'.
- Azure guests will be running under Hyper-V and contain a disk with a
well known filesystem label.
- Amazon EC2 [3] populating the DMI system uuid with the same value as
system serial number, and will start with 'ec2'
- NoCloud datasource has disk attached with a well-known label 'cidata'.

Unless those datasource identifiers are present, the datasource will not
be queried.

As with all things in Ubuntu, has been made first in the development
release (17.04). Eventually it will make its way into the 16.04 LTS
release by way of a Stable Release Update.

In the past some cloud providers have served metadata to instances running
unmodified Ubuntu images by emulating the EC2 metadata service. With the
plan above in place, those instances will no longer receive metadata
without modification to either the image or the environment.

Our goal is to work with all cloud providers to ensure that their
environments enjoy the performance improvements these changes to Ubuntu
and cloud-init provide. The best practice for cloud providers is to
supply a specific string in DMI data to their guests that will allow
cloud-init to identify which datasource should be used.

To make sure that instances booting from Ubuntu cloud images continue to
work on your cloud, please:

Test the Ubuntu 17.04 (Zesty) cloud images from
https://cloud-images.ubuntu.com/zesty
If you experience problems, open a bug [4] against cloud-init and provide
information on what datasource cloud-init previously used as well as how
cloud-init can identify your platform.

After you've filed a bug with the proper information, you can make custom
images which will continue to work by specifying the datasource that is
expected to be used. To do so, simply write the following to
/etc/cloud/cloud.cfg.d/99-datasource.cfg, replacing 'YourCloud' with a
datasource below:

datasources_list: [YourCloud, None]

The accepted datasources in 17.04 are:
AltCloud, Azure, Bigstep, CloudSigma, CloudStack, ConfigDrive,
DigitalOcean, Ec2, MAAS, NoCloud, OpenNebula, OpenStack, OVF, SmartOS

The plan is to bring this back to 16.10 (Yakkety) in a Stable Release
Update [5] in the next few days. This will expose it to more users than
the development release (Zesty), and then eventually make the change in
the 16.04 LTS (Xenial).

Scott

--
[1] Ubuntu cloud images are used as the basis for LXD, MAAS and public
cloud images.
[2] https://cloud.google.com/compute/docs/instances/managing-instances
[3] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html
[4] https://bugs.launchpad.net/cloud-init/+filebug
[5] https://wiki.ubuntu.com/StableReleaseUpdates


--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

upcoming changes to Ubuntu cloud images via cloud-init

In an effort to improve the performance and efficiency of Ubuntu's cloud
images[1], cloud-init is making some changes in the way that it searches
for datasources. By making use of environment information that platforms
provide such as DMI (Desktop Management Interface) data, cloud-init can
quickly filter out datasources that are not present.

The driver for doing this is to:

- Improve boot speed of Ubuntu images by quickly discarding datasources
that are not present.
- Avoid attempting to access network resources that may not be present.
That can result in timeouts or other unexpected behavior.
- Entirely disable cloud-init if no datasource is present.

Examples of such information that cloud-init will consider:

- OpenStack Nova populating the DMI system product name 'OpenStack Nova'.
- Google Compute Engine [2] populating the DMI system product name with
'Google Compute Engine'.
- Azure guests will be running under Hyper-V and contain a disk with a
well known filesystem label.
- Amazon EC2 [3] populating the DMI system uuid with the same value as
system serial number, and will start with 'ec2'
- NoCloud datasource has disk attached with a well-known label 'cidata'.

Unless those datasource identifiers are present, the datasource will not
be queried.

As with all things in Ubuntu, has been made first in the development
release (17.04). Eventually it will make its way into the 16.04 LTS
release by way of a Stable Release Update.

In the past some cloud providers have served metadata to instances running
unmodified Ubuntu images by emulating the EC2 metadata service. With the
plan above in place, those instances will no longer receive metadata
without modification to either the image or the environment.

Our goal is to work with all cloud providers to ensure that their
environments enjoy the performance improvements these changes to Ubuntu
and cloud-init provide. The best practice for cloud providers is to
supply a specific string in DMI data to their guests that will allow
cloud-init to identify which datasource should be used.

To make sure that instances booting from Ubuntu cloud images continue to
work on your cloud, please:

Test the Ubuntu 17.04 (Zesty) cloud images from
https://cloud-images.ubuntu.com/zesty
If you experience problems, open a bug [4] against cloud-init and provide
information on what datasource cloud-init previously used as well as how
cloud-init can identify your platform.

After you've filed a bug with the proper information, you can make custom
images which will continue to work by specifying the datasource that is
expected to be used. To do so, simply write the following to
/etc/cloud/cloud.cfg.d/99-datasource.cfg, replacing 'YourCloud' with a
datasource below:

datasources_list: [YourCloud, None]

The accepted datasources in 17.04 are:
AltCloud, Azure, Bigstep, CloudSigma, CloudStack, ConfigDrive,
DigitalOcean, Ec2, MAAS, NoCloud, OpenNebula, OpenStack, OVF, SmartOS

The plan is to bring this back to 16.10 (Yakkety) in a Stable Release
Update [5] in the next few days. This will expose it to more users than
the development release (Zesty), and then eventually make the change in
the 16.04 LTS (Xenial).

Scott

--
[1] Ubuntu cloud images are used as the basis for LXD, MAAS and public
cloud images.
[2] https://cloud.google.com/compute/docs/instances/managing-instances
[3] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/identify_ec2_instances.html
[4] https://bugs.launchpad.net/cloud-init/+filebug
[5] https://wiki.ubuntu.com/StableReleaseUpdates

--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Enabling Connectivity Checking in NetworkManager

Hi, back in July 2012 on this list, it was proposed that Ubuntu's
NetworkManager enable the new connectivity check feature by default.
Some concerns were raised and the feature never landed. I'd like to
reopen that discussion.

In 2014, Fedora enabled that feature by default but they did it using
a separate package. I really like this idea since it makes it very
easy for users to opt in or out of the connectivity check if they
choose.

I am proposing that we create a similar package. I would like to have
Ubuntu GNOME's metapackage recommend that config-connectivity package.
In GNOME Shell, when a captive portal is detected, the network status
icon changes to include a question mark and a login window pointed to
the portal's login/authorization webpage appears. The login window is
powered by webkit2gtk. This is very similar to the implementation by
most other operating systems.

Here's the Feature Freeze exception bug and merge proposal:
https://launchpad.net/bugs/997200

Jeremy Bicha

--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: To access IPP-over-USB printer: Emulate remote machine in the network

On 01/21/2017 09:56 AM, TJ wrote:
> On 16/01/17 18:05, Till Kamppeter wrote:
>> In the beginning I used localhost:60000 which makes polling capabilities
>> and status, printing, and web interface work, but the printer could not
>> be Avahi-broadcasted and so CUPS and cups-browsed could not discover it.
>>
> Possibly not the ideal solution but did you test whether using
> avahi-daemon.conf's "deny-interfaces=" with a single interface name that
> it is safe to ignore (a throw-away dummy interface) would work?
>
> I ask because the man-page for avahi-daemon.conf seems to imply that the
> interface default action is to ignore 'lo' and any point-to-point
> interfaces, but if using "deny-interfaces=" without any
> "allow-interfaces=" it will use all interfaces not specified - which
> implies that it would then use 'lo'. E.g:
>
> # allow-interfaces=
> deny-interfaces=dummy0
> # implication is that 'lo' will be used
>
> If the functionality is only required for the localhost's CUPS service
> this might be sufficient.
>
>
>

I have done some testing, modifying the avahi-daemon.conf as described,
restarting avahi-daemon, and running avahi-discover to see which
services get broadcasted on which interfaces. The "lo" interface did not
appear, also not after running

sudo ip link set lo multicast on

This should activate multicast support on lo if this is possible (at
least "ifconfig" shows the activated multicast flag).

It seems that lo does definitively not have broadcasting support, as

sudo ip link set lo broadcast 127.255.255.255

errors with "Invalid argument".

See also

http://serverfault.com/questions/554503/how-do-i-add-a-broadcast-ip-to-the-loopback-interface-under-os-x-using-ifconfig

http://serverfault.com/questions/421389/how-to-add-a-broadcast-address-to-loopback-with-ifconfig-on-a-os-x

So it looks like that we need to work with an extra interface (dummy0
with IPv6) and find a way to let Avahi broadcast the interface's own
host name or the interface's IP address instead of the system's host
name or we need a way to make ippusbxd emulate a remote host with its
own host name and IP address but not creating a virtual machine, if this
would be possible.

Till


--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel