Forum Replies Created
-
Posts
-
I believe that this would be 10.20.4.0/23 on all FABRIC racks and 10.40.6.0/23 on a rack called EDC – special RACK for Measurement VMs do be deployed
1 user thanked author for this post.
an intersting observation i came across for UBUNTU vms at NCSA. If the vm is rebooted right after you login the first time , the relogin, everthing works fine. There may be a race condition happenning in Ubuntu between when the network comes up and the DNS resolution becomes active.
As i mentioned before that sudo error is normal. I am not sure if the node.execute() just stops due to that or if it proceeds and fails silently at the apt command . apt is an interactive tool. To run it non-interactively requires a lot more options.
https://stackoverflow.com/questions/33370297/apt-get-update-non-interactive
I dont see any issues on your VM.
i tried this in your VM and it seems to do the right thing
ubuntu@e0a0baa2-fbe3-4d6b-92b9-6d1c74b93897-ei11:~$ sudo apt install python3-scapy
You do have sudo access on your machine to edit this. But please read online posts regarding editing DNS settings for Ubuntu. UBUNTU 18 and higher use systemd-resolved (or resovectl) to make changes to DNS settings. Due to a bug at the NCSA site. ubuntu seems to be picking up DNS servers that are restricted by the hosting site(NCSA).
2606:4700:4700::1111, 2620:0:c80:2::1, 2620:0:c80:2::3 these three DNS servers should work, but i am unable to find the right command to overwrite the settings in resolvectl. The commands i have tried just add these servers to the existing list which does not help. Using Rocky Linux or some other FABRIC Site may work.
I believe the Issue is with the DNS servers the Ubuntu images at NCSA end up using. Rocky Linux seems to pick up the right DNS servers but Ubuntu image are not at NCSA.
If you switch to using 2606:4700:4700::1111, 2620:0:c80:2::1, 2620:0:c80:2::3 these DNS server, it should work.
I am investigation on a proper fix , but this will be a workaround for now.
The error “sudo: unable to resolve host a83f476a-af0e-4b07-8a63-7d1cb0f6c300-h1” is normal since there is no name resolution for this.
As for the Ubuntu repositories, There was an issue with some Ubuntu Repos yesterday worldwide. Try this again today. If it still does not work, please post the contents of the /etc/resolv.conf file from your machine.
Dear experimenters,
This outage has been resolved. Please continue using your FABRIC resources and experiments.
The second workaround you mentioned is just a command line representation of the jump instructions in the ~/work/.ssh/config file.
the -F is required when using jupyterHub because ssh looks for its config file in ~/.ssh/config . When using JupyterHub, this is not possible for persistence since the files in ~/ gets reset. Instead the docs talk about saving files that need to be persistent in ~/work. Hence the ssh config directory is stored in ~/work/.ssh/config and thus the need for the -F to tell ssh where the config file resides .
