Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

check new version fails #1335

Closed
simonpanay opened this issue Nov 23, 2016 · 15 comments
Closed

check new version fails #1335

simonpanay opened this issue Nov 23, 2016 · 15 comments
Labels
Milestone

Comments

@simonpanay
Copy link

GLPI fails to check if a new version is available

GLPI 9.1.1 (with plugin FusionInventory)
Debian 8

Step to reproduce :

  • In menu Administration>Maintenance>
  • Click "Check if a new version is available" (Vérifiez si une nouvelle version est disponible) in French

A message appears :
Erreur
Connexion au site impossible (HTTP/1.1 501 Not Implemented)

php_error.log :

  *** PHP Warning(2): Invalid argument supplied for foreach()
  Backtrace :
  inc/toolbox.class.php:1331                         
  front/backup.php:42                                Toolbox::checkNewVersionAvailable()
@trasher
Copy link
Contributor

trasher commented Nov 24, 2016

  *** PHP Warning(2): fsockopen(): php_network_getaddresses: getaddrinfo failed: No address associated with hostname
  Backtrace :
  :                                                  
  inc/toolbox.class.php:1647                         fsockopen()
  inc/toolbox.class.php:1355                         Toolbox::getURLContent()
  front/backup.php:42                                Toolbox::checkNewVersionAvailable()

  *** PHP Warning(2): fsockopen(): unable to connect to ssl://api.github.com:443 (php_network_getaddresses: getaddrinfo failed: No address associated with hostname)
  Backtrace :
  :                                                  
  inc/toolbox.class.php:1647                         fsockopen()
  inc/toolbox.class.php:1355                         Toolbox::getURLContent()
  front/backup.php:42                                Toolbox::checkNewVersionAvailable()

@trasher trasher added the bug label Nov 24, 2016
@trasher trasher added this to the 9.1.2 milestone Nov 24, 2016
@trasher
Copy link
Contributor

trasher commented Jan 3, 2017

I've been able to reproduce the error; but it seems to work now. I wonder if that was a GitHub issue.

Could you please test again?

@simonpanay
Copy link
Author

Nope, it's still failing

2017-01-04 17:19:27 [112@glpi]
  *** PHP Warning(2): Invalid argument supplied for foreach()
  Backtrace :
  inc/toolbox.class.php:1331                         
  front/backup.php:42                                Toolbox::checkNewVersionAvailable()

Sorry...

@orthagh
Copy link
Contributor

orthagh commented Jan 18, 2017

see #656

@trasher
Copy link
Contributor

trasher commented Jan 18, 2017

@simonpanay seems to be related to a proxy issue; are you also behind a proxy?

@trasher
Copy link
Contributor

trasher commented Jan 18, 2017

see also #693

@tyronewyatt
Copy link

The check update used to work behind a proxy in GLPI 0.90.1 and I think 0.90.2 but stopped working in 0.90.3 onwards. It still works when not using a proxy.
I remember testing this feature after the check update was made compatible with github #163
Where I work a proxy is required for internet access.

@trasher
Copy link
Contributor

trasher commented Jan 18, 2017

Could you try with the following changes (I do not have a proxy to test):

diff --git a/inc/toolbox.class.php b/inc/toolbox.class.php
index f0a0104..0f692f1 100644
--- a/inc/toolbox.class.php
+++ b/inc/toolbox.class.php
@@ -1631,16 +1631,18 @@ class Toolbox {
       $content = "";
       $taburl  = parse_url($url);
 
+      $hostscheme  = '';
+      $defaultport = 80;
+
+      // Manage standard HTTPS port : scheme detection or port 443
+      if ((isset($taburl["scheme"]) && $taburl["scheme"]=='https')
+         || (isset($taburl["port"]) && $taburl["port"]=='443')) {
+         $hostscheme  = 'ssl://';
+         $defaultport = 443;
+      }
+
       // Connection directe
       if (empty($CFG_GLPI["proxy_name"])) {
-         $hostscheme  = '';
-         $defaultport = 80;
-         // Manage standard HTTPS port : scheme detection or port 443
-         if ((isset($taburl["scheme"]) && $taburl["scheme"]=='https')
-            || (isset($taburl["port"]) && $taburl["port"]=='443')) {
-            $hostscheme  = 'ssl://';
-            $defaultport = 443;
-         }
          if ($fp = @fsockopen($hostscheme.$taburl["host"],
                               (isset($taburl["port"]) ? $taburl["port"] : $defaultport),
                               $errno, $errstr, 1)) {
@@ -1671,7 +1673,7 @@ class Toolbox {
 
          if ($fp) {
             $request  = "GET $url HTTP/1.1\r\n";
-            $request .= "Host: ".$taburl["host"]."\r\n";
+            $request .= "Host: ".$taburl["host"].":".(isset($taburl["port"]) ? $taburl["port"] : $defaultport)."\r\n";
             if (!empty($CFG_GLPI["proxy_user"])) {
                $request .= "Proxy-Authorization: Basic " . base64_encode ($CFG_GLPI["proxy_user"].":".
                            self::decrypt($CFG_GLPI["proxy_passwd"], GLPIKEY)) . "\r\n";

@tyronewyatt
Copy link

@trasher just tested your change on GLPI 0.90.5 and unfortunately the same error message is occurs.

trasher added a commit to trasher/glpi that referenced this issue Jan 19, 2017
trasher added a commit to trasher/glpi that referenced this issue Jan 19, 2017
trasher added a commit to trasher/glpi that referenced this issue Jan 19, 2017
@trasher
Copy link
Contributor

trasher commented Jan 19, 2017

Please see solution provided in #1660

@simonpanay
Copy link
Author

@trasher
Yes, I'm behind a proxy.
Tried your first patch, but it doesn't seem to work
I'll try the one attached to #1660

@trasher
Copy link
Contributor

trasher commented Jan 19, 2017

@simonpanay thank you. I'm waiting for a positive report to include this fix in the next GLPI release coming monday ;)
Could you please precise if your proxy requires authentication? The tests we've done were on a proxy without auth.

@simonpanay
Copy link
Author

And our proxy doesn't require authentication. Sorry

trasher added a commit that referenced this issue Jan 20, 2017
trasher added a commit that referenced this issue Jan 20, 2017
@trasher
Copy link
Contributor

trasher commented Jan 20, 2017

@simonpanay well, at least, that will work with proxies that does not requires authentication... ;) Thanks for the feedback.

@simonpanay
Copy link
Author

@trasher Indeed. Thanks for the bug fix ;o)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants