Forum Replies Created
-
Posts
-
Hello Nirmala,
We have corrected the image at the WASH site and are updating all other sites with the corrected image. This process should be done by EOD today. You can start using WASH in the meantime
Hello Nirmala,
I believe we have a faulty disk image for Kali. Please bear with us while we get this resolved. It may be a few days before we get back to you.
what is the Ip of the machine you are trying to ssh into. From the first post i see 1.2.3.4 which is not a valid IP
Aha. The cuplrit is the group ownsership on your home folder. This must have been changed somehow.
drwxrwx— 12 ubuntu root 4096 Dec 2 18:17 /home/ubuntu
run the command
sudo chown -R ubuntu:ubuntu /home/ubuntu
That should fix the issue.
Thats not the right machine . We want the output from 00954b21-57cf-40e2-86c2-0d7b7269fecb-classifier node
Can you please post the output of
ls -lad /home/ubuntuls -la /home/ubuntu/.ssh
The can see from the ssh log that the ownership of home directory is the issue
Dec 02 18:07:16 00954b21-57cf-40e2-86c2-0d7b7269fecb-classifier sshd[60744]: Connection closed by authenticating user ubuntu 2001:400:a100:1030::51 port 52118 [preauth]
Dec 02 18:07:16 00954b21-57cf-40e2-86c2-0d7b7269fecb-classifier sshd[60744]: Authentication refused: bad ownership or modes for directory /home/ubuntu
Dec 02 18:07:09 00954b21-57cf-40e2-86c2-0d7b7269fecb-classifier sshd[60742]: Connection closed by authenticating user ubuntu 2001:400:a100:1030::51 port 52104 [preauth]
Dec 02 18:07:09 00954b21-57cf-40e2-86c2-0d7b7269fecb-classifier sshd[60742]: Authentication refused: bad ownership or modes for directory /home/ubuntu
Dec 02 18:06:35 00954b21-57cf-40e2-86c2-0d7b7269fecb-classifier sshd[60740]: Connection closed by authenticating user ubuntu 2001:400:a100:1030::51 port 50056 [preauth]
Dec 02 18:06:35 00954b21-57cf-40e2-86c2-0d7b7269fecb-classifier sshd[60740]: Authentication refused: bad ownership or modes for directory /home/ubuntuCan you please grab the logs using
sudo journalctl -r -u ssh >/tmp/ssh.log
and then email help@fabric-testbed.net with the ssh.log file attached .If pullout the file is not possible then just run
sudo journalctl -r -u ssh
and copy the few recent lines that will help us debug the issue.
I have a anotehr notebook in the same foler that show creating a site. The notebooks picks random sites using a filter that asks for PTP capable only. Here’s the relevant line
sites = fablib.get_random_sites(count=4,filter_function=lambda x:x['ptp_capable'] is True, avoid=(avoid_sites)) https://github.com/fabric-testbed/jupyter-examples/blob/main/fabric_examples/public_demos/KNIT7/Tutorial1_Precision_Time_Measurements_in_FABRIC/knit7_create_topology.ipynb
I would also like to mention that we do not use chrony in our PTP setup. We instead use a utility called phc2sys . There are other utilities in the linuxptp package that let you ask for timestamps and report accuracy.
If you like to use chrony for this purpose, let me know and i can provide you instructions to disable the phc2sys and use chrony with the PTP device as a syncronization source.
okay . So since nothing is being used, all you are doing is running NTP against the default timeservers that chrony picks up. So even if your second VM may be on the same rack, you will achive the accuracy that NTP provides.
Network Time Protocol (NTP) can achieve accuracy <mark class=”QVRyCf”>within tens of milliseconds over the internet, and within one millisecond in local area networks (LANs) under ideal conditions</mark>. However, accuracy can be affected by several factors, including:- Network congestion and asymmetric routes: These can cause errors of 100 milliseconds or more.
- Stratum: The higher the stratum number, the lower the accuracy. Stratum 0 devices, such as atomic and GPS clocks, are the most accurate, but they can’t be connected to via a network connection.
- Physical distance: The further the synchronizing server is from the client, the lower the accuracy
If you would like more achive more accurate measurements you can use PTP. We do have a notebook that you can use to setup PTP in your slice which would allow you to synchronize the system clocks on your VMs.
Just make sure the sites you use have the PTP capability as not all FABRIC sites use PTP.
This notbeook show how to setup PTP synchronization on your VMs. https://github.com/fabric-testbed/jupyter-examples/blob/main/fabric_examples/public_demos/KNIT7/Tutorial1_Precision_Time_Measurements_in_FABRIC/knit7_install_PTP.ipynb
Once setup, all the system clocks on all the VMs in the slice should be in sync to the order of 10s of microseconds or better
- Network congestion and asymmetric routes: These can cause errors of 100 milliseconds or more.
