IPV6

[Nicolas Pinault]

Le 09/07/2018 à 13:55, Mads Kiilerich a écrit :
> On 07/09/2018 09:43 AM, Nicolas Pinault wrote:
>> Le 07/07/2018 à 14:19, Mads Kiilerich a écrit :
>>> On 07/06/2018 04:35 PM, Nicolas Pinault wrote:
>>>> Hi Mads,
>>>>
>>>> Le 23/03/2018 à 00:55, Mads Kiilerich a écrit :
>>>>> On 03/22/2018 02:58 PM, Nicolas Pinault wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Is there a way to make kallithea serve on IPV6 only or, IPV4 and 
>>>>>> IPV6?
>>>>>
>>>>> I am not aware of anything that should be IPv4 specific. But I 
>>>>> also haven't tried IPv6.
>>>>>
>>>>> I guess it just works if using Apache and mod_wsgi.
>>>>>
>>>>> The waitress version we default to use for `gearbox serve` doesn't 
>>>>> support IPv6.
>>>>>
>>>>> A quick test on our default branch shows that it seems to work on 
>>>>> IPv6 if you edit setup.py to "waitress>=0.8.8,<2.0" to get 
>>>>> something like waitress 1.1 and edit your .ini to host = * .
>>>>>
>>>>> With reports of Waitress 1.1 (and review of their release note) we 
>>>>> can make that version the default.
>>>> I finally had some time to try your solution.
>>>> I didn't reinstalled all after modifying setup.py.
>>>>
>>>> I upgraded waitress directly with :
>>>> pip install --upgrade "waitress>=0.8.8,<2.0"
>>>>
>>>> I then modified METADATA and metadata.json files located in 
>>>> Kallithea-0.3.5.dist-info directory to set the ">=0.8.8,<2.0" pattern.
>>>>
>>>> Kallithea launches and remote client accesses it.
>>>> However, Kallithea crashes on first access.
>>>>   File "d:\kallithea\env\lib\site-packages\kallithea\lib\auth.py", 
>>>> line 1336, in
>>>>  check_ip_access
>>>>     if ipaddr.IPAddress(source_ip) in ipaddr.IPNetwork(ip):
>>>>   File 
>>>> "d:\kallithea\env\lib\site-packages\kallithea\lib\ipaddr.py", line 
>>>> 76, in
>>>>  IPAddress
>>>>     address)
>>>> ValueError: 'fe80::acaf:647b:6b31:70b8%13' does not appear to be an 
>>>> IPv4 or IPv6
>>>>  address
>>>>
>>>> I believe the scope at the end of the IP address is the culprit. 
>>>> But maybe I am wrong.
>>>
>>> Agree. I didn't know that was a thing that could appear here. I 
>>> guess we just should strip it? That would not be a security issue?
>>>
>>> Can you try something like
>>>
>>> --- a/kallithea/lib/auth.py
>>> +++ b/kallithea/lib/auth.py
>>> @@ -1008,6 +1008,7 @@ def check_ip_access(source_ip, allowed_i
>>>      :param allowed_ips: list of allowed ips together with mask
>>>      """
>>>      from kallithea.lib import ipaddr
>>> +    source_ip = source_ip.split('%', 1)[0]
>>>      log.debug('checking if ip:%s is subnet of %s', source_ip, 
>>> allowed_ips)
>>>      if isinstance(allowed_ips, (tuple, list, set)):
>>>          for ip in allowed_ips:
>>>
>>>> I have added the full trace back at the end of this message.
>>>>
>>>> As IPV6 is not officially supported, I have not created a bug request.
>>>
>>> It is also not not officially unsupported ;-) So please bring it on 
>>> so we can fix all issues.
>> Your patch fixed the issue. I am now able to pull/push to/from 
>> Kallithea.
>
> Great. Can any IPv6 experts confirm that it is the right thing to do?
>
>> Are there other tests I should try ?
>
> Nothing special. Just everything ;-)
>
> Great if you can play around more with IPv6 and Waitress 1.1 and this 
> change and confirm things work ... or report other unexxpected issues 
> you might encounter.

Our "production server", at work now uses this setting (waitress1.1 and 
patch).

A little of history :
We use TortoiseHg (Windows 10) on clients. TortoiseHg is configured with 
the server name, not its IP address.
We changed our server 4 months ago. The new server is running Windows 
2008 server RC2. Since this change, all hg operations on the server 
where very slow.
I had hard time finding the culprit. I finally discovered that IPV6 was 
used by default between clients and server. But as Kallithea does not 
manage IPV6, the IPV6 requests are discarded by the server and the 
client falls down to IPV4 after tens of seconds. This scheme is repeated 
for each client/server operation. This was working but very slowly.
I didn't want to disable IPV6 neither on the server nor on the client 
since we use it for other things.
I also didn't want to use IPV4 address in TortoiseHg configuration.
The solution was to make Kallithea IPV6 compliant. This is the case now 
and speed is back.

I'll keep you informed of any problem.

Thanks a lot for your help.

Nicolas