Forum Replies Created
-
Posts
-
Hi,
This was due to a service outage this afternoon which has been resolved. See https://learn.fabric-testbed.net/forums/topic/outage-in-credential-manager-services/
Please let us know if your issues are still not resolved.
1 user thanked author for this post.
Again, that is not what Ilya meant by adding the host. What you did by adding “nameserver node1” is that you are telling your node that node1 is your DNS server. That line is incorrect. Please remove that line. Then IPv4 sites should work from this node. As for the “sudo: unable to resolve host Node1: Temporary failure in name resolution” message, it can be safely ignored. It is bound to happen as FABRIC does not provide name resolution for VM hostnames. These messages only pop up in Debian based operating systems. They do not show up on RPM based Operating systems
1 user thanked author for this post.
With a recent feature addition to FABRIC there is no longer any need to run any script to gain access to IPv4 resources from IPv6 FABRIC nodes. As long as the default DNS settings on a FABRIC VM are not changed, your VM should allow you to connect to IPv4 resources. You will have to use DNS names. Direct IPv4 addresses will still not work. FABRIC implements NAT64/DNS64.
1 user thanked author for this post.
Was this for a new slice ? If not then, please
- Launch a new terminal (not a notebook cell) and perform the pip install
- Create a new Slice with MF
Hello,
Due to DNS IP renaming of docker and other Nat64 related changes, there has been a minor update to the MFLIB library being used. We are in the process of pushing out the latest version of the mflib library to jupterhub as a default, but in the mean time, before you begin any of your notebooks, please do
pip install fabrictestbed-mflib==1.0.4
Then “reload kernel ” in the jupyterhub menu if you have any notebooks open. Then redo the tutorial. It should work.
You may have to do the pip install step every time a new jupyterhub session is created until this version is made default in FABRIC.
Unfortunately not at this moment since it’s a policy decision affecting the whole Testbed. If you are unable to use this workaround, I would suggest using nat64.net since that seems to work fine.Based on the decision taken by the FABRIC Dev and Security team, we have deployed a temporary fix for this issue. The fix should be transparent and work for the site you mentioned without any workarounds on your part. Please let us know if you still have issues.
We are seeing issues related to the site objects.githubusercontent.com when used with FABRIC NAT64. For now a workaround that is being used for this is to add
2a01:4f9:c010:3f02:64:0:b9c7:6e85 objects.githubusercontent.com
in your /etc/hosts file. This line forces this one site to route through one of the nat64 servers offered by the NAT64.net site while using FABRIC NAT64 for all others.
Please try your test again and let us know if this works. We have applied a fix to the FABRIC DNS servers so that it no longer provides AAAA records for FABNETv4 addresses and RFC 1918 addresses
1 user thanked author for this post.
Hi Fraida,
The MICH site is currently down. We are trying to determine why but no ETA has been provided.
HI,
Apologize for the delay in responding. Our MF team looked into this and saw the errors you mentioned. There are two major issues we found that are likely the causing the issue. One of them pertains to the NCSA rack MF uses for creating the measurement node. The other was software related. They have a workaround for the software issue but will need some time to fix the NCSA Site issue. Is this an urgent requirement or can this wait for a few days while we resolve the issues without any workarounds?
