Concrete install error on WIMP

Permalink 1 user found helpful
I'm installing concrete 5.7.5.6 on a Windows 2008 server. It was going great through creating the database and then it starts "adding admin user" at which point it fails with the following... It looks like a problem with resolving an internal address?

inet_pton(): Unrecognized address fe80::3486:676f:47b5:77b5%12.

Trace:
#0 [internal function]: Whoops\Run->handleError(2, 'inet_pton(): Un...', 'G:\\C5\\concrete\\...', 42, Array) #1 G:\C5\concrete\src\Utility\IPAddress.php(42): inet_pton('fe80::3486:676f...') #2 G:\C5\concrete\src\Utility\IPAddress.php(21): Concrete\Core\Utility\IPAddress->setIp('fe80::3486:676f...', false) #3 G:\C5\concrete\src\Permission\IPService.php(61): Concrete\Core\Utility\IPAddress->__construct('fe80::3486:676f...') #4 G:\C5\concrete\src\User\User.php(246): Concrete\Core\Permission\IPService->getRequestIP() #5 G:\C5\concrete\src\User\User.php(53): Concrete\Core\User\User->recordLogin() #6 G:\C5\concrete\src\Package\StartingPointPackage.php(354): Concrete\Core\User\User::getByUserID(1, true, false) #7 [internal function]: Concrete\Core\Package\StartingPointPackage->add_users() #8 G:\C5\concrete\controllers\install.php(293): call_user_func(Array) #9 [internal function]: Concrete\Controller\Install->run_routine('elemental_full', 'add_users') #10 G:\C5\concrete\src\Controller\AbstractController.php(161): call_user_func_array(Array, Array) #11 G:\C5\concrete\src\Routing\ControllerRouteCallback.php(27): Concrete\Core\Controller\AbstractController->runAction('run_routine', Array) #12 G:\C5\concrete\src\Routing\Router.php(142): Concrete\Core\Routing\ControllerRouteCallback->execute(Object(Concrete\Core\Http\Request), Object(Concrete\Core\Routing\Route), Array) #13 G:\C5\concrete\src\Support\Facade\Facade.php(119): Concrete\Core\Routing\Router->execute(Object(Concrete\Core\Routing\Route), Array) #14 G:\C5\concrete\src\Application\Application.php(434): Concrete\Core\Support\Facade\Facade::__callStatic('execute', Array) #15 G:\C5\concrete\src\Application\Application.php(434): Concrete\Core\Support\Facade\Route::execute(Object(Concrete\Core\Routing\Route), Array) #16 G:\C5\concrete\bootstrap\start.php(231): Concrete\Core\Application\Application->dispatch(Object(Concrete\Core\Http\Request)) #17 G:\C5\concrete\dispatcher.php(36): require('G:\\C5\\concrete\\...') #18 G:\C5\index.php(2): require('G:\\C5\\concrete\\...') #19 {main}

 
rtomkins replied on at Permalink Reply
I am installing concrete5, version 8.1.0, on Windows 10 64 bit IIS, with PHP 7.1.1 64 bit and MySQL.
All attempts result in the following error,

inet_pton(): Unrecognized address fe80::e5da:9a3f:5b36:2ba9%7
This is the link-local TCP/IP v6 address of my system. It's a valid address

Would anyone know what to do to resolve this problem?
digitaris replied on at Permalink Reply
digitaris
As a short-term solution, you might want to enable IPv4 protocol on your Windows server. There may be a bug with the inet_pton() function as it relates to IPv6 addresses that include the network interface identifer (e.g. the '%7' at the end of the address). Just a thought!
-David
CMSDeveloper replied on at Permalink Best Answer Reply
CMSDeveloper
http://www.wampserver.com/en/
Gondwana replied on at Permalink Reply
Gondwana
Any chance you could use 'localhost' (assuming you're not entering that already)?
rtomkins replied on at Permalink Reply
Both IPv4 and IP v6 are enabled on my Windows 10 Pro machine. I tried the install with IP v6 disabled, same result.

IIS is already installed and running. Installing WAMP is redundant and should not be a real solution as IIS is part of my workflow.

I tried both localhost and "MyComputerName" with the same result.
digitaris replied on at Permalink Reply
digitaris
With IPv4 only enabled I would expect it to work, provided PHP is installed and properly enabled on your Windows server under IIS. Make sure you have your fastcgi Handler Mapping defined for PHP under IIS. Also, make sure you recycle the IIS Application Pools for PHP to pick up any configuration changes. If you haven't done so, create a phpinfo() page under \inetpub\wwwroot\phpinfo.php so you can view and confirm PHP settings.

I do not have a Concrete 5.8 version running under IIS, but I do have one deployment of Concrete 5.7.5.8 on Windows Server 2008 with IIS 7.5 and PHP 5.6.15 working fine.

The function that is referenced in your stack trace (inet_pton) is part of the PHP core and does not need a specific PHP extension enabled to work. If everything is good with your setup and config of PHP, you may have to spend time debugging the core source to identify where the problem is.
rtomkins replied on at Permalink Reply
I complained in the IIS Web Platform Installer forum that Web Platform Installer could not/would not see my installation of MySQL. I asked how to make it work and the recommendation was to uninstall everything and use Web Platform Installer to install everything including concrete5.

Having some time to fool around with this I did remove everything.
I used Web Platform Installer to install concrete5 and it installed,
PHP 5.5.38
MySQL 5.1
concrete5 5.7.5.7

After huge amount of disk activity, it worked.

I have just removed everything.

I'm going to give the another go, using,
MySQL the latest version
PHP 5.5.38
concrete5 8.10

and we'll see what happens. Maybe there is a problem with PHP?
rtomkins replied on at Permalink Reply
AHA! Got it, aw nuts, not really!

Turn off, IP v6, Microsoft LLDP Protocol Driver, Link-Layer Topology Discovery Responder, Link-Layer Topology Discovery Mapper I/O Driver, for all network adapters.
Disable Microsoft Teredo Tunneling Adapter in Device Manager.

Enable PHP 7.1.1
Install MySQL Community Edition 5.7
Install concrete5 8.1.0

You can login and do stuff with concrete5.

Turn on all the disabled network protocols and reenable the Teredo tunneling protocol and,

attempt a login and the following failure occurs.

inet_pton(): Unrecognized address fe80::e5da:9a3f:5b36:2ba9%7

So, it would seem that the problem is with concrete.

I have tried both 32 bit PHP, 5.5.38 and 5.6.24 as well as 64 bit PHP 7.0.9 and 7.1.1.
No matter which version of PHP is in use, concrete5 spits the following error out when attempting to login.

inet_pton(): Unrecognized address fe80::e5da:9a3f:5b36:2ba9%7
rtomkins replied on at Permalink Reply
After all my efforts, I am leaning towards the implementation / use of inet_pton() in concrete5 has a bug.

Is there an official bug reprting page to use?
rtomkins replied on at Permalink Reply
concrete5 5.7.13 fails with same inet_pton error.
concrete5 5.6.3.5 has installed without error using PHP 5.5.38
rtomkins replied on at Permalink Reply
concrete5 5.6.3.5 will not work with PHP 7.1.1 64 bit.

I'm stuck.

I want 64 bit applications and I want the most recent version of these applications too.
digitaris replied on at Permalink Reply
digitaris
NOTE: This is technical guidance and you can render a Concrete5 site unusable if you make changes to core files without a backup from which to restore. Proceed carefully.

I believe your issue is partially related to your network configuration, and to an error in the PHP code. You appear to be using Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), a technology that assigns addresses, configures tunnels between hosts and between routers and hosts, and provides unicast IPv6 connectivity betweeen IPv6 hosts across an IPv4 intranet. The %ZoneID portion of IPv6 address (%12 or %7 in your example) appears to cause the IP address functions used in Concrete5 to fail. This may be exacerbated by the fact you are using link-local addresses. I recommend that you insert logic that will test and remove this identifier from the IPv6 address to see if this resolves your problem so you can use the latest versions. Remember that any such changes you make to the files below will have to be checked against any future versions of Concrete5 and you may have to reinsert this logic when the Concrete5 core is updated. If it works, we can report this recommended fix to the core development team.

Recommended steps to follow:
Keep a copy of the original files that you edit, as a backup, in case you encounter any errors. These steps should be performed after you download the latest Concrete5 to your Windows server, but before you start the formal guided install process:

Files to backup:
concrete\src\Utility\IPAddress.php
concrete\vendor\symfony\http-foundation\IpUtils.php

First file to edit:
concrete\src\Utility\IPAddress.php

Look for the __construct() function and replace it entirely with the following code and then save the file. New code...

public function __construct($ipAddress = null, $isHex = false)
    {
        if ($ipAddress !== null && $ipAddress !== '') {
             $ipAddress = ($pos = strpos($ipAddress, '%')) ? substr($ipAddress, 0, $pos) : $ipAddress;
            $this->setIp($ipAddress, $isHex);
        }
    }


The line above that reads
$ipAddress = ($pos = strpos($ipAddress, '%')) ? substr($ipAddress, 0, $pos) : $ipAddress;
is the new line that we are inserting and its purpose is to strip off the network interface zone identifier if present.

Second file to edit:
concrete\vendor\symfony\http-foundation\IpUtils.php

Find and replace the entire function named checkIp() with the following code and then save the file. The change made to this function does the same thing...it removes the %xx zone identifier from the IP address if it exists. New code...
public static function checkIp($requestIp, $ips)
    {
        if (!is_array($ips)) {
            $ips = array($ips);
        }
            $requestIp = ($pos = strpos($requestIp, '%')) ? substr($requestIp, 0, $pos) : $requestIp;
        $method = substr_count($requestIp, ':') > 1 ? 'checkIp6' : 'checkIp4';
        foreach ($ips as $ip) {
            if (self::$method($requestIp, $ip)) {
                return true;
            }
        }
        return false;
    }


After making these changes, proceed with the install and confirm if this fixes your issue.

Best wishes for success!
rtomkins replied on at Permalink Reply
Whoopee!
Windows 10, IIS 64 bit
PHP 7.1.1 64 bit
MySQL 5.7 64 bit
concrete5 8.1.0

When the code modifications as detailed in the previous post are made, concrete5 8.1.0 installs error free.

I thank you very much for your assistance in making this most excellent product function properly in Windows 10.

Absolutely super effort, thank you.

The link-layer Teredo tunneling protocol is enabled in all versions of Windows 10 to facilitate getting IPV6 traffic out to the IPV6 internet, through a large amount of consumer grade network gear that only works with IPV4, such as routers, and modems.
digitaris replied on at Permalink Reply
digitaris
Fantastic!

I have reported this issue on Github:
https://github.com/concrete5/concrete5/issues/5675...

Hopefully they will integrate the changes into the next release. It is my understanding that 8.1.1, or 8.1.0.1, or 8.2 (not sure of the next version), is nearing release.

When you next upgrade Concrete5, please remember to check for the above changes in the two files that were edited. If the above changes are not found, you will need to make the changes again in the version you download, until the changes make their way into a release.

You can monitor the reported issue by following the reported issue.

Regards,
David
CMSDeveloper replied on at Permalink Reply
CMSDeveloper
digitaris replied on at Permalink Reply
digitaris
Yes, I am aware of the LAMP focus and most of my installs are on Linux. I also have one Windows 2008 R2 and IIS large site on Concrete5 and it has run with minimal Windows-specific errors in the core for over two years, across multiple updates and upgrades.

It never hurts to report and share a recommended fix, even if outside the primary core OS focus.

The core development team will decide if it is worthy.
rtomkins replied on at Permalink Reply
Regardless of the OS and web server involved, how does Linux handle transporting IPV6 communications over IPV4 hardware, if not through tunneling, then what?
digitaris replied on at Permalink Reply
digitaris
The general implementation mechanisms are similar for Linux. What is key to recognize is the fact that in some scenarios Linux will return a zone identifier in an IPv6 address that, if left unhandled, will result in a similar error for the Linux version of Concrete5 as you experienced under Windows. The change I recommended above works for both platforms.

As noted below, Michele has implemented the fix and submitted it for core development team review. Due to the reality that this issue impacts both operating system platforms, I anticipate it will be included in a future release.
rtomkins replied on at Permalink Reply
That's what I had suspected. These days, when it comes to system solutions, there are a lot of similarities amongst various Operating Systems.
This comes about through cross pollination, people working for one company are contributors towards open source efforts, similar foundations, within the North American education system, we teach similar stuff across most colleges and universities, and essential design, as in a lot of code falls under a common need to work cooperatively with other pieces of code.
Of course, when you're trying to make something more modern interoperate with something older from yesteryear (80's), the design solutions that present themselves to you are rather small. The chosen solutions for NTSC colour TV and FM radio were elegant in the day. In both cases, the consumer could continue to use his very expensive investments in older hardware until it wore out.
mlocati replied on at Permalink Reply
mlocati
https://github.com/concrete5/concrete5/pull/5680 fixes this issue: if the core team accepts it, concrete5 8.2 will work flawlessly ;)
digitaris replied on at Permalink Reply
digitaris
This issue has been fixed and is now part of version 8.2.0.
CMSDeveloper replied on at Permalink Reply
CMSDeveloper
Great!
rtomkins replied on at Permalink Reply
I concur, this is great.
The product will now install and operate properly on a system that uses IPv4 tunneling to handle IPv6 traffic on network gear that only handles IPv4 traffic.
In addition, it makes the product more readily accessible to a non-LAMP user community.
Cheers