[opensuse-factory] Tumbleweed - Review of the week 2017/41
Dear Tumbleweed users and hackers, Week 41 felt rather ‘quiet’, don’t know why.. it’s not as if nothing would have happened. There were, after all, 5 snapshots released (1005, 1006, 1007, 1009 and 1010), delivering on the promises from last week. Those snapshots contained those noteworthy updates: * GNOME 3.26.1 * KDE Plasma 5.11 * Linux Kernel 4.13.5 * Mozilla Firefox 56 (not for i586!) * Mesa 17.2.2 * Zypper 1.13.37: if you keep on runing ‘zypper up’ with this on Tumbleweed, you will get a warning that this is not the correct way. You stay in control, but at least we can refer to: I told you so. There are quite some larger things happening in Staging, which is why we opened two new staging projects (Staging:N and Staging:O) * openSSL 1.1 as default (Staging:N) * Remove python2 from a default installation (Staging:O) * PostgreSQL 10 is still on the todo (the submitted packages are not all installable) * Linux Kernel 4.13.6 Besides all this progress, please take note that various openSUSE services will not be avaialble on the weekend OCt 14/15, as was announced here: https://goo.gl/Xkmcy9 Cheers, Dominique
Il 13/10/2017 09:59, Dominique Leuenberger / DimStar ha scritto:
Dear Tumbleweed users and hackers,
Week 41 felt rather ‘quiet’, don’t know why.. it’s not as if nothing would have happened. There were, after all, 5 snapshots released (1005, 1006, 1007, 1009 and 1010), delivering on the promises from last week.
Those snapshots contained those noteworthy updates:
* GNOME 3.26.1 * KDE Plasma 5.11 * Linux Kernel 4.13.5 * Mozilla Firefox 56 (not for i586!) * Mesa 17.2.2 * Zypper 1.13.37: if you keep on runing ‘zypper up’ with this on Tumbleweed, you will get a warning that this is not the correct way. You stay in control, but at least we can refer to: I told you so.
There are quite some larger things happening in Staging, which is why we opened two new staging projects (Staging:N and Staging:O)
* openSSL 1.1 as default (Staging:N) * Remove python2 from a default installation (Staging:O) * PostgreSQL 10 is still on the todo (the submitted packages are not all installable) * Linux Kernel 4.13.6
Besides all this progress, please take note that various openSUSE services will not be avaialble on the weekend OCt 14/15, as was announced here: https://goo.gl/Xkmcy9
Cheers, Dominique
Hello after latest "TW dup" a strange window opens on my Gnome whose title is: "gnome-shell-portal-helper" it contains an Apache root folder with the content: check_network_status.txt with date of 27-Jun-2013 and the file inside contents is :"NetworkManager is online" Wonder what it is and how can I disable it from appearing at every login. Thanks and regards, -- Marco Calistri Linux version : openSUSE Tumbleweed 20171010 Kernel: 4.13.6-1.g5a88d59-default - Cinnamon 3.4.6 N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
Affects me too! 2017-10-13 21:31 GMT+03:00 Marco Calistri <mcalistri@hotmail.com>:
Il 13/10/2017 09:59, Dominique Leuenberger / DimStar ha scritto:
Dear Tumbleweed users and hackers,
Week 41 felt rather ‘quiet’, don’t know why.. it’s not as if nothing would have happened. There were, after all, 5 snapshots released (1005, 1006, 1007, 1009 and 1010), delivering on the promises from last week.
Those snapshots contained those noteworthy updates:
* GNOME 3.26.1 * KDE Plasma 5.11 * Linux Kernel 4.13.5 * Mozilla Firefox 56 (not for i586!) * Mesa 17.2.2 * Zypper 1.13.37: if you keep on runing ‘zypper up’ with this on Tumbleweed, you will get a warning that this is not the correct way. You stay in control, but at least we can refer to: I told you so.
There are quite some larger things happening in Staging, which is why we opened two new staging projects (Staging:N and Staging:O)
* openSSL 1.1 as default (Staging:N) * Remove python2 from a default installation (Staging:O) * PostgreSQL 10 is still on the todo (the submitted packages are not all installable) * Linux Kernel 4.13.6
Besides all this progress, please take note that various openSUSE services will not be avaialble on the weekend OCt 14/15, as was announced here: https://goo.gl/Xkmcy9
Cheers, Dominique
Hello after latest "TW dup" a strange window opens on my Gnome whose title is: "gnome-shell-portal-helper" it contains an Apache root folder with the content: check_network_status.txt with date of 27-Jun-2013 and the file inside contents is :"NetworkManager is online"
Wonder what it is and how can I disable it from appearing at every login.
Thanks and regards,
-- Marco Calistri Linux version : openSUSE Tumbleweed 20171010 Kernel: 4.13.6-1.g5a88d59-default - Cinnamon 3.4.6
-- Regards, Andrei Dziahel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat 14 Oct 2017 08:20:28 PM CDT, Andrei Dziahel wrote:
Affects me too!
2017-10-13 21:31 GMT+03:00 Marco Calistri <mcalistri@hotmail.com>:
Il 13/10/2017 09:59, Dominique Leuenberger / DimStar ha scritto:
Dear Tumbleweed users and hackers,
Week 41 felt rather ‘quiet’, don’t know why.. it’s not as if nothing would have happened. There were, after all, 5 snapshots released (1005, 1006, 1007, 1009 and 1010), delivering on the promises from last week.
Those snapshots contained those noteworthy updates:
* GNOME 3.26.1 * KDE Plasma 5.11 * Linux Kernel 4.13.5 * Mozilla Firefox 56 (not for i586!) * Mesa 17.2.2 * Zypper 1.13.37: if you keep on runing ‘zypper up’ with this on Tumbleweed, you will get a warning that this is not the correct way. You stay in control, but at least we can refer to: I told you so.
There are quite some larger things happening in Staging, which is why we opened two new staging projects (Staging:N and Staging:O)
* openSSL 1.1 as default (Staging:N) * Remove python2 from a default installation (Staging:O) * PostgreSQL 10 is still on the todo (the submitted packages are not all installable) * Linux Kernel 4.13.6
Besides all this progress, please take note that various openSUSE services will not be avaialble on the weekend OCt 14/15, as was announced here: https://goo.gl/Xkmcy9
Cheers, Dominique
Hello after latest "TW dup" a strange window opens on my Gnome whose title is: "gnome-shell-portal-helper" it contains an Apache root folder with the content: check_network_status.txt with date of 27-Jun-2013 and the file inside contents is :"NetworkManager is online"
Wonder what it is and how can I disable it from appearing at every login.
Hi A forum user reported the same issue and a temporary fix ; http://forums.opensuse.org/showthread.php?t=527636 I tried to duplicate and can't, have no idea why it's going to nmcheck.gnome.org rather than conncheck.opensuse.org (which it should be) maybe an extension? /usr # fgrep -r "nmcheck.gnome.org" * Binary file bin/gnome-shell-extension-prefs matches Binary file lib/gnome-shell/gnome-shell-portal-helper matches Binary file lib64/gnome-shell/libgnome-shell.so matches -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.2 | GNOME 3.20.2 | 4.4.87-18.29-default HP 255 G4 Notebook | A6-6310 X4 @ 1.80 GHz | AMD Radeon R4 up 5 days 2:44, 1 user, load average: 2.33, 2.51, 1.38 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il 14/10/2017 15:44, Malcolm ha scritto:
On Sat 14 Oct 2017 08:20:28 PM CDT, Andrei Dziahel wrote:
Affects me too!
2017-10-13 21:31 GMT+03:00 Marco Calistri <mcalistri@hotmail.com>:
Il 13/10/2017 09:59, Dominique Leuenberger / DimStar ha scritto:
Dear Tumbleweed users and hackers,
Week 41 felt rather ‘quiet’, don’t know why.. it’s not as if nothing would have happened. There were, after all, 5 snapshots released (1005, 1006, 1007, 1009 and 1010), delivering on the promises from last week.
Those snapshots contained those noteworthy updates:
* GNOME 3.26.1 * KDE Plasma 5.11 * Linux Kernel 4.13.5 * Mozilla Firefox 56 (not for i586!) * Mesa 17.2.2 * Zypper 1.13.37: if you keep on runing ‘zypper up’ with this on Tumbleweed, you will get a warning that this is not the correct way. You stay in control, but at least we can refer to: I told you so.
There are quite some larger things happening in Staging, which is why we opened two new staging projects (Staging:N and Staging:O)
* openSSL 1.1 as default (Staging:N) * Remove python2 from a default installation (Staging:O) * PostgreSQL 10 is still on the todo (the submitted packages are not all installable) * Linux Kernel 4.13.6
Besides all this progress, please take note that various openSUSE services will not be avaialble on the weekend OCt 14/15, as was announced here: https://goo.gl/Xkmcy9
Cheers, Dominique
Hello after latest "TW dup" a strange window opens on my Gnome whose title is: "gnome-shell-portal-helper" it contains an Apache root folder with the content: check_network_status.txt with date of 27-Jun-2013 and the file inside contents is :"NetworkManager is online"
Wonder what it is and how can I disable it from appearing at every login.
Hi A forum user reported the same issue and a temporary fix ; http://forums.opensuse.org/showthread.php?t=527636
I tried to duplicate and can't, have no idea why it's going to nmcheck.gnome.org rather than conncheck.opensuse.org (which it should be) maybe an extension?
/usr # fgrep -r "nmcheck.gnome.org" *
Binary file bin/gnome-shell-extension-prefs matches Binary file lib/gnome-shell/gnome-shell-portal-helper matches Binary file lib64/gnome-shell/libgnome-shell.so matches
Thanks Malcolm for your indications. The fact is that a day after the problem occurs, I stop to see that oddity on my desktop and also the network status indicator stop to display the question-mark "?" and backs to show the connection icon, so I really don't know what happened because I've not touched/changed anything. Best regards, -- Marco Calistri Linux version : openSUSE Tumbleweed 20171010 Kernel: 4.13.6-1.g5a88d59-default - Cinnamon 3.4.6
Il giorno Sun, 15 Oct 2017 13:44:59 +0000 Marco Calistri <mcalistri@hotmail.com> ha scritto:
so I really don't know what happened because I've not touched/changed anything.
The service outage affected also conncheck.opensuse.org, so that's why you see that. It's part of NM's connectivity checking. Should you want to disable it, add interval=0 to /etc/NetworkManager/NetworkManager.conf under the "uri" in the [connectivity] section. A restart of NM is required to put this into effect. -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B
On Mon 16 Oct 2017 06:56:50 AM CDT, Luca Beltrame wrote:
Il giorno Sun, 15 Oct 2017 13:44:59 +0000 Marco Calistri <mcalistri@hotmail.com> ha scritto:
so I really don't know what happened because I've not touched/changed anything.
The service outage affected also conncheck.opensuse.org, so that's why you see that. It's part of NM's connectivity checking. Should you want to disable it, add
interval=0
to /etc/NetworkManager/NetworkManager.conf under the "uri" in the [connectivity] section. A restart of NM is required to put this into effect.
Hi Ummm it was working fine here, the outage information indicated it was not one of the affected services... Running curl -v http://conncheck.opensuse.org/ returned exactly what it was meant to do. -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.2 | GNOME 3.20.2 | 4.4.87-18.29-default HP 255 G4 Notebook | A6-6310 X4 @ 1.80 GHz | AMD Radeon R4 up 6 days 20:21, 1 user, load average: 0.40, 0.44, 0.60 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il 16/10/2017 02:56, Luca Beltrame ha scritto:
Il giorno Sun, 15 Oct 2017 13:44:59 +0000 Marco Calistri <mcalistri@hotmail.com> ha scritto:
so I really don't know what happened because I've not touched/changed anything.
The service outage affected also conncheck.opensuse.org, so that's why you see that. It's part of NM's connectivity checking. Should you want to disable it, add
interval=0
to /etc/NetworkManager/NetworkManager.conf under the "uri" in the [connectivity] section. A restart of NM is required to put this into effect.
Thanks for the suggestion, it is the same workaround which Malcolm has posted by the Forum. Beside the issue itself I really don't know why NM needs to check the connectivity and furthermore why in case of failure it opens a big notification window on the user desktop. IMHO from one side such NM behavior looks like a sort of a "spyware" and from the other side appears to be a bad design of its notification section. But these are just my very personal impressions. Regards, -- TThheerree''ss aann EEcchhoo iinn hheerree.
On Mon, 2017-10-16 at 15:47 +0000, Marco Calistri wrote:
Beside the issue itself I really don't know why NM needs to check the connectivity and furthermore why in case of failure it opens a big notification window on the user desktop.
It's portal detection - the idea is to detect if you are behind a captive portal where you need to login to make use of the network connection (like is the case at every airport) Hence, NM tries to reach http://conncheck.opensuse.org, where it expects to be receiving a http/204 (empty body) answer with a X- NetworkManager-Status: online header in plus; our server setup there is as dumb as it can be: the header is unconditionally injected into a static http/204 reply (any other header would not make sense if NM could already reach that server)
IMHO from one side such NM behavior looks like a sort of a "spyware" and from the other side appears to be a bad design of its notification section.
The notification popped up because NM did not get the expected reply - but when the portal then opened, it could reach nmcheck.gnome.org - which is not something the portal code anticipated. What is not clear, though, is why conncheck.opensuse.org failed to respond correctly during the power outage: a backup server was in place during that time (the only explanation so far is that we might have missed to cater for ipv6-only clients; but I doubt there are THAT many out there yet)
But these are just my very personal impressions.
You're entitled to have them, as much as you're entitled to read the code about the 'phone home impression' so you can find out what happens. you're even able to setup your own server and change your configuration to that server to query the status, if you wish to preserve the functionality, or disable it. The beauty of open source, eh? Cheers Dominique
On 16 October 2017 at 18:08, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
(the only explanation so far is that we might have missed to cater for ipv6-only clients; but I doubt there are THAT many out there yet)
You'd be surprised - I know of areas in Latin America and Asia that are only allocating IPv6 addresses these days, and in Germany you have ISP's like Kabel Deutchland which only provide their customers with IPv6 addresses now, unless you explicitly request an IPv4 address And sure, in many cases they have some kind of fallback for IPv4 addresses, but they often favour IPv6 first and foremost - heck, almost all of our browsers in openSUSE do that by default now also. ~20% of the traffic hitting google worldwide is IPv6 these days https://www.google.com/intl/en/ipv6/statistics.html That bumps upto 30% in Germany, and 33% in Greece & USA So if something like conncheck.opensuse.org was responsive on IPv6 but not responding properly, it's not surprising NM would go try a different host rather than thinking "oh, maybe the webserver will work right on that old legacy protocol I don't like to use any more" ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2017-10-16 at 18:15 +0200, Richard Brown wrote:
On 16 October 2017 at 18:08, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
(the only explanation so far is that we might have missed to cater for ipv6-only clients; but I doubt there are THAT many out there yet)
You'd be surprised - I know of areas in Latin America and Asia that are only allocating IPv6 addresses these days, and in Germany you have ISP's like Kabel Deutchland which only provide their customers with IPv6 addresses now, unless you explicitly request an IPv4 address
And sure, in many cases they have some kind of fallback for IPv4 addresses, but they often favour IPv6 first and foremost - heck, almost all of our browsers in openSUSE do that by default now also.
~20% of the traffic hitting google worldwide is IPv6 these days https://www.google.com/intl/en/ipv6/statistics.html
That bumps upto 30% in Germany, and 33% in Greece & USA
So if something like conncheck.opensuse.org was responsive on IPv6 but not responding properly, it's not surprising NM would go try a different host rather than thinking "oh, maybe the webserver will work right on that old legacy protocol I don't like to use any more" ;)
as far as I know, the temp setup simply had no IPv6 - conncheck.o.o only had A records (well, a CNAME record pointing to a host only having A. same result) Hence, it would really ONLY be valid for IPv6-only hosts having an issue. As soon as the host also hasv4 connectivity, without V6 even being advertised on DNS, it should just have worked. Cheers Dominique
On 10/16/2017 12:15 PM, Richard Brown wrote:
And sure, in many cases they have some kind of fallback for IPv4 addresses, but they often favour IPv6 first and foremost - heck, almost all of our browsers in openSUSE do that by default now also.
It's not the browsers, it's the operating system that determines that. So, even with something like SSH, IPv6 is preferred. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Oct 16, James Knott wrote:
On 10/16/2017 12:15 PM, Richard Brown wrote:
And sure, in many cases they have some kind of fallback for IPv4 addresses, but they often favour IPv6 first and foremost - heck, almost all of our browsers in openSUSE do that by default now also.
It's not the browsers, it's the operating system that determines that.
It's the application programmer who decides which protocol to prefer at first for his application. If he really implements it neutral, it's the resolver and the nameserver. firefox for example has it's own resolver, so the operating system has no way to influence that. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il 16/10/2017 14:08, Dominique Leuenberger / DimStar ha scritto:
On Mon, 2017-10-16 at 15:47 +0000, Marco Calistri wrote:
Beside the issue itself I really don't know why NM needs to check the connectivity and furthermore why in case of failure it opens a big notification window on the user desktop.
It's portal detection - the idea is to detect if you are behind a captive portal where you need to login to make use of the network connection (like is the case at every airport)
Totally a new feature which I see for the first time in openSUSE, for this reason I've been surprised.
Hence, NM tries to reach http://conncheck.opensuse.org, where it expects to be receiving a http/204 (empty body) answer with a X- NetworkManager-Status: online header in plus; our server setup there is as dumb as it can be: the header is unconditionally injected into a static http/204 reply (any other header would not make sense if NM could already reach that server)
IMHO from one side such NM behavior looks like a sort of a "spyware" and from the other side appears to be a bad design of its notification section.
The notification popped up because NM did not get the expected reply - but when the portal then opened, it could reach nmcheck.gnome.org - which is not something the portal code anticipated. What is not clear, though, is why conncheck.opensuse.org failed to respond correctly during the power outage: a backup server was in place during that time (the only explanation so far is that we might have missed to cater for ipv6-only clients; but I doubt there are THAT many out there yet)
But these are just my very personal impressions.
You're entitled to have them, as much as you're entitled to read the code about the 'phone home impression' so you can find out what happens. you're even able to setup your own server and change your configuration to that server to query the status, if you wish to preserve the functionality, or disable it.
Yes, I could safely get rid of this NM checker because I don't need it but now that notification doesn't pops anymore, I can easily live with it.
The beauty of open source, eh?
Cheers Dominique
Cheers, Marco
On Mon, 2017-10-16 at 16:33 +0000, Marco Calistri wrote:
Il 16/10/2017 14:08, Dominique Leuenberger / DimStar ha scritto:
On Mon, 2017-10-16 at 15:47 +0000, Marco Calistri wrote:
Beside the issue itself I really don't know why NM needs to check the connectivity and furthermore why in case of failure it opens a big notification window on the user desktop.
It's portal detection - the idea is to detect if you are behind a captive portal where you need to login to make use of the network connection (like is the case at every airport)
Totally a new feature which I see for the first time in openSUSE, for this reason I've been surprised.
Newly introduced (in our packaging by configratuin) back in Week 12/13 http://dominique.leuenberger.net/blog/2016/04/opensuse-tumbleweed-revie w-of-the-week-201612-13/ But of course, easily missed, as it 'just worked' (for you with a working connection as well for the users that ended up being behind a captive portal, where they nicely got a portal login screen upon connecting). Cheers, Dominique
Il 16/10/2017 18:13, Dominique Leuenberger / DimStar ha scritto:
On Mon, 2017-10-16 at 16:33 +0000, Marco Calistri wrote:
Il 16/10/2017 14:08, Dominique Leuenberger / DimStar ha scritto:
On Mon, 2017-10-16 at 15:47 +0000, Marco Calistri wrote:
Beside the issue itself I really don't know why NM needs to check the connectivity and furthermore why in case of failure it opens a big notification window on the user desktop.
It's portal detection - the idea is to detect if you are behind a captive portal where you need to login to make use of the network connection (like is the case at every airport)
Totally a new feature which I see for the first time in openSUSE, for this reason I've been surprised.
Newly introduced (in our packaging by configratuin) back in Week 12/13
http://dominique.leuenberger.net/blog/2016/04/opensuse-tumbleweed-revie w-of-the-week-201612-13/
Yep!
But of course, easily missed, as it 'just worked' (for you with a working connection as well for the users that ended up being behind a captive portal, where they nicely got a portal login screen upon connecting).
And how NM was working *before* the introduction of the "network-checker ", I mean before 2016/04? May be it is just a personal feeling but I'm still not seeing a great utility in having this feature enabled as default.
Cheers, Dominique
Thanks for your patience! Regards, Marco
On Mon, 2017-10-16 at 20:37 +0000, Marco Calistri wrote:
And how NM was working *before* the introduction of the "network- checker ", I mean before 2016/04? May be it is just a personal feeling but I'm still not seeing a great utility in having this feature enabled as default.
It blindly switched the connection to 'online' when an IP address was assigned. The feature might not benefit you personally, but it does benefit users that actually travel with their notebooks. The discussion can be held for every on/off switch: some people would like it one way, some the other way. I'm not going to be the right person to toggle this thing off - after all I went through all the hoops to get all the services up and running before I toggled the config switch (so that there was actually no negative impact once we enabled it.. and it worked for 18 months until you realised we DID switch it on :) ) cheers Dominique
Il giorno Mon, 16 Oct 2017 20:37:20 +0000 Marco Calistri <mcalistri@hotmail.com> ha scritto:
May be it is just a personal feeling but I'm still not seeing a great utility in having this feature enabled as default.
It is used in some places, for example some KDE software, to check if the network is actually working and act accordingly. -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B
Il 16/10/2017 20:19, Luca Beltrame ha scritto:
Il giorno Mon, 16 Oct 2017 20:37:20 +0000 Marco Calistri <mcalistri@hotmail.com> ha scritto:
May be it is just a personal feeling but I'm still not seeing a great utility in having this feature enabled as default.
It is used in some places, for example some KDE software, to check if the network is actually working and act accordingly.
Luca, Is it part of some uninstallable package/applet? If yes I think I will uninstall it. Thanks and Regards, -- Marco Calistri -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il giorno Wed, 18 Oct 2017 11:18:12 +0000 Marco Calistri <mcalistri@hotmail.com> ha scritto:
Is it part of some uninstallable package/applet? If yes I think I will uninstall it.
It's easier to disable the connectivity check, in that case it becomes a no-op.
Il 18/10/2017 09:32, Luca Beltrame ha scritto:
Il giorno Wed, 18 Oct 2017 11:18:12 +0000 Marco Calistri <mcalistri@hotmail.com> ha scritto:
Is it part of some uninstallable package/applet? If yes I think I will uninstall it.
It's easier to disable the connectivity check, in that case it becomes a no-op.
Noted! Cheers, -- Marco Calistri -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Montag, 16. Oktober 2017 17:47:25 CEST Marco Calistri wrote:
Il 16/10/2017 02:56, Luca Beltrame ha scritto:
Il giorno Sun, 15 Oct 2017 13:44:59 +0000 Marco Calistri <mcalistri@hotmail.com> ha scritto:
so I really don't know what happened because I've not touched/changed anything.
The service outage affected also conncheck.opensuse.org, so that's why you see that. It's part of NM's connectivity checking. Should you want to disable it, add
interval=0
to /etc/NetworkManager/NetworkManager.conf under the "uri" in the [connectivity] section. A restart of NM is required to put this into effect.
Thanks for the suggestion, it is the same workaround which Malcolm has posted by the Forum.
Beside the issue itself I really don't know why NM needs to check the connectivity and furthermore why in case of failure it opens a big notification window on the user desktop.
For the check itself, this is IMHO very welcome. Having a working Wifi or ethernet connection is not a good indication for internet connectivity (and thats what the majority of NM users is interested in). You may have a broken DSL connection and may not be aware of it, and you may be blocked by a captive portal and not aware of it. While a broken DSL connection may be also detected by e.g. ICMP requests, captive portals can only be detected by connecting to a known HTTP server and comparing the result with a known good response.
IMHO from one side such NM behavior looks like a sort of a "spyware" and from the other side appears to be a bad design of its notification section.
You fear being spyed on by a plain HTTP request without any cookies, special headers, nothing else? The notification is *not* done by NetworkManager, but by the applet. The Plasma applet puts an unobtrusive exclamation mark on its icon if the connection does not work as expected, and shows more information in the tooltip. Kind regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-------- Original Message -------- From: Brüns, Stefan Sent: Monday, Oct 16, 2017 2:10 PM SAE To: opensuse-factory@opensuse.org; Marco Calistri Subject: [opensuse-factory] Re: Access Hotspot notification? wasTumbleweed - Review of the week 2017/41
On Montag, 16. Oktober 2017 17:47:25 CEST Marco Calistri wrote:
Il 16/10/2017 02:56, Luca Beltrame ha scritto:
Il giorno Sun, 15 Oct 2017 13:44:59 +0000 Marco Calistri <mcalistri@hotmail.com> ha scritto:
so I really don't know what happened because I've not touched/changed anything.
The service outage affected also conncheck.opensuse.org, so that's why you see that. It's part of NM's connectivity checking. Should you want to disable it, add
interval=0
to /etc/NetworkManager/NetworkManager.conf under the "uri" in the [connectivity] section. A restart of NM is required to put this into effect.
Thanks for the suggestion, it is the same workaround which Malcolm has posted by the Forum.
Beside the issue itself I really don't know why NM needs to check the connectivity and furthermore why in case of failure it opens a big notification window on the user desktop.
For the check itself, this is IMHO very welcome. Having a working Wifi or ethernet connection is not a good indication for internet connectivity (and thats what the majority of NM users is interested in). You may have a broken DSL connection and may not be aware of it, and you may be blocked by a captive portal and not aware of it.
So far I used to check connectivity by hand opening the Google page with a browser or even issuing a nslookup by the console. First time that I see an embedded connectivity checker inside a NM, for this reason I'm quite surprised.
While a broken DSL connection may be also detected by e.g. ICMP requests, captive portals can only be detected by connecting to a known HTTP server and comparing the result with a known good response.
IMHO from one side such NM behavior looks like a sort of a "spyware" and from the other side appears to be a bad design of its notification section.
You fear being spyed on by a plain HTTP request without any cookies, special headers, nothing else?
Cannot see what is running inside the system but it is also clear that a true spyware running in background, wouldn't notify nothing to the user.
The notification is *not* done by NetworkManager, but by the applet. The Plasma applet puts an unobtrusive exclamation mark on its icon if the connection does not work as expected, and shows more information in the tooltip.
Kind regards,
Stefan
Thanks for the additional explanation Regards, Marco
participants (9)
-
Andrei Dziahel -
Brüns, Stefan -
Dominique Leuenberger / DimStar -
James Knott -
Luca Beltrame -
Malcolm -
Marco Calistri -
Richard Brown -
Thorsten Kukuk