Shouldn't port 443 be open over IPv6 on the pool nodes too?
http://pprc.qmul.ac.uk/~lloyd/gridpp/get_file.php?path=21_Mar_2019/Network_Test_http_ipv6_1671040/15698254/&file=Script1_nettest_remote.sh.log
Duncan
On 21/03/2019 15:06, Robert Currie wrote:
> Hi,
>
> Yes in this case the dpm head node and the storage pool nodes are all
> running ScientificLinux6.
>
> Thanks,
>
> Rob
>
> PS:
> We have already had a testing dual-stacked DPM head node which is on
> CentOS7. This didn't appear to have the same problems. However, this box
> is running DPM+DOME so comparisons can get a bit tricky.
> (I've not recently been monitoring traffic closely on our test dpm
> setup, 1 head node and 1 pool node so there could be some oddities with
> the configuration there that I'm unaware of.)
>
> On 2019-03-21 14:32, Duncan Rand wrote:
>> Hi Rob
>>
>> Does that include the pool nodes?
>>
>> Duncan
>>
>> On 21/03/2019 11:35, Robert Currie wrote:
>>> Hi all,
>>>
>>> We've recently updated the storage at Edinburgh to be dual stacked
>>> IPv4/v6.
>>>
>>> Unfortunately we hit a few problems which may be site specific but I
>>> don't know if anyone else has experienced these issues and knows any
>>> potentially good/better fixes.
>>> Unfortunately all of the boxes we've updated are running
>>> ScientificLinux6. I'm keen to migrate these to CentOS7 but this is
>>> less of a priority to enabling IPv6 support.
>>>
>>> 1)
>>> The first issue is that our IPv6 storage nodes were untrusted by DPM
>>> after updating to the latest (non-DOME) builds. This was solved by
>>> explicitly adding the IPv6 addresses into the shift.conf files.
>>> (After the IPv6 address for all hosts had been registered all
>>> machines were restarted).
>>> The reverse DNS appears to be working for all of the machines and the
>>> gai.conf file which has been shared around for configuring
>>> getaddrinfo resolution was present on all machines. I don't know if
>>> this could just have been a DNS caching issue for the first 24/hr but
>>> I plan not to investigate too much further.
>>>
>>> 2)
>>> MySQL 5.1 . This is the default version of Mysql on ScientificLinux6
>>> which doesn't have complete IPv6 support according to some
>>> documentation.
>>> (Our DB is hosted on the same machine as the DPM head node and is not
>>> externally accessible).
>>> MySQL 5.1 struggled struggled to connect for our IPv6 https DPM
>>> connections. This was tracked down to MySQL 5.1 not binding to an
>>> IPv6 port. (When forced to bind to an IPv6 address in the MySQL
>>> configuration it would crash on launch).
>>> This was resolved by upgrading MySQL to 5.7 (I think at least >=5.6.6
>>> would have been needed) which introduced a _large_ amount of
>>> additional work due to our db being so old.
>>>
>>> 3)
>>> After initially enabling IPv6 support I saw failed connections to
>>> high numbered ports (4xxxx-5xxxx) from our DPM head node to our
>>> storage nodes.
>>> This is still a bit of a mystery as this port range isn't in our site
>>> config and we don't see any traffic on this port range over IPv4.
>>> My assumption at this point is that there might have been a
>>> misconfiguration as when we added `export
>>> GLOBUS_TCP_PORT_RANGE="20000,25000"` to /etc/sysconfig/globus on all
>>> machines and rebooted all services (again) the problem went away.
>>> However this was also discovered(and fixed?) before we had to migrate
>>> our MySQL.
>>>
>>>
>>> Hope this helps anyone and thanks for any suggestions of anything I
>>> may have done incorrectly,
>>> At the moment our storage now appears to be correctly accepting
>>> IPv4/v6 connections and we didn't have to modify any other site
>>> configuration information.
>>>
>>> Best Regards,
>>>
>>> Rob
>>>
>
########################################################################
To unsubscribe from the GRIDPP-STORAGE list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=GRIDPP-STORAGE&A=1
|