[Closed] mintUpdate - why urlopen() before ping is needed

[karlchen]

Hello, Clem.

Foreword:
This is not an attempt to continue discussing whether it is evil to contact Google.com in order to make sure an internet connection is available.
This post is intended to explain why the command urlopen("<name of website>") must not be removed from mintupdate.py.

References:

• Thread [url=http://forums.linuxmint.com/viewtopic.php?f=90&t=145176]Steady Info to Google - hardcoded in Linux Mint ?![/url] in general. [url=http://forums.linuxmint.com/viewtopic.php?f=90&t=145176#p764963]Your reply at the end of page 1 in particular[/url].
• Posted mintUpdate fix on Github: Only use ping_domain to check connection, don't rely on pinging google.com …

In your reply you wrote that you could not remember why the initial command

Code: Select all

url=urlopen("http://google.com")

had been kept.
Well, I can tell you why. And I can tell why the address may be changed using the address got from the mintupdate dialog box (prefs["ping_domain"]), but why the whole code block is needed :

Code: Select all

try:
            from urllib import urlopen
            url=urlopen("prefs["ping_domain"]") <== what ever the right python code will be to get it there, prefixed with http://
            url.read()
            url.close()
            log.writelines("++ Connection to the Internet successful (tried to read http://www.google.com)\n")

Why it is there and why it needs to stay:

• urlopen("<name of website>") can be used no matter whether the user is connected through a DSL router or through a proxy.
• if os.system("ping " + prefs["ping_domain"] + " -c1 -q"): can be used from my home machine connected through a DSL router.
  But our company proxy server e.g. will discard ping commands to the internet making the command always fail.
• Consequence:
  Currently mintupdate succeeds on my office machine, because urlopen("<name of webpage>") will pass the proxy.
  With the suggested fix mintupdate will always fail on any machine behind a proxy that drops ping commands.
• Conclusion:
  The proper fix will be to keep the code block, but to make sure it uses "http://" + prefs["ping_domain"]" instead of "http://google.com".

Sorry to open a new thread for this. But the old one has been locked. And I did not feel like registering with Github just to make this post, in particular as my nickname is already in use and my alternative nickname as well. Never mind. If I wish to register there will be another nickname.

Kind regards,
Karl

[Mohr]

Too bad this is seemingly not relevant for clem.

[Mohr]

As time passes by and there are - as far as I can see - no people with problems, what's your conclusion?

[karlchen]

Hello, Mohr.

Currently my office machine runs on Mint 13. Yet, it quite seems as if the changed script /usr/lib/linuxmint/mintUpdate/mintUpdate.py (30-Nov-2013) has made its way onto this machine as well.
Checking the daily logfile /tmp/mintUpdate/jzrs2J (the filename is random and will change on each Mint reboot) reveals this:

++ Launching mintUpdate in user mode
++ Testing initial connection
-- No connection found (tried to ping google.com) - sleeping for 30 seconds

OK, this confirms that our proxy will not pass through ping packets.
Yet then the logfile goes on

++ Starting refresh
++ Auto-refresh timer is going to sleep for 15 minutes, 0 hours and 0 days
++ System is up to date
++ Refresh finished
++ MintUpdate is in tray mode, performing auto-refresh
++ Starting refresh
++ Auto-refresh timer is going to sleep for 15 minutes, 0 hours and 0 days
++ System is up to date
++ Refresh finished

This suggests that although the initial test whether the internet were available failed, mintUpdate does not really care about the failed try and later on regularly checks for updated software lists nonetheless.
OK, this suggests, too, that I will have to check more carefully, why mintUpdate correctly decides to carry on instead of giving up because pinging google.com failed.

Summary:
Hm, if the modified verification procedure does not make mintUpdate fail behind company proxies, there is no need to complain. And we may consider this case closed.

Kind regards,
Karl

[Mohr]

Thank you!
I would have been happy if your idea would have been correct.

But ... now all what remains as an explanation again is Clems "I don't know / I forgot" about why to insert "Google.com" hardcoded in the script and add another strange feature like the "15 min" - default request, which is a wonderful tracking feature for a datacraken.