root@localhost:~# juju add-cloud
This operation can be applied to both a copy on this client and to the one on a controller.
No current controller was detected and there are no registered controllers on this client: either bootstrap one or register one.
Cloud Types
lxd
maas
manual
openstack
vsphere
Select cloud type: manual
Enter a name for your manual cloud: testcloud
Enter the ssh connection string for controller, username<hostname or IP> or <hostname or IP>: root10.3.3.15
Can't validate endpoint: root10.3.3.15: Permission denied (publickey).
Enter the ssh connection string for controller, username<hostname or IP> or <hostname or IP>: ^C
root@localhost:~# ssh root10.3.3.15
Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.0-33-generic x86_64)
*** System restart required ***
Last login: Wed Oct 28 09:48:42 2020 from 10.3.3.16
root@kubeadmtest2:~# exit
logout
Connection to 10.3.3.15 closed.
root@localhost:~#
Another test, I even added ubuntu user! But even if I tell it to use root its still trying ubuntu but still fails?!
On the other node in auth log I see
Oct 28 10:05:39 kubeadmtest2 sshd[1348134]: Connection closed by authenticating user root 10.3.3.16 port 42198 [preauth]
Oct 28 10:06:04 kubeadmtest2 sshd[1348440]: Connection closed by authenticating user ubuntu 10.3.3.16 port 42202 [preauth]
I had to remove all AT symbols because discourse is a joke, detected them as links and didn’t allow me to post because I’m new.
edit: so the bug is that juju seems to be unable to process ed25519 keys, once I had RSA key generated it connected.
Unbelievable…this isnt the 90s anymore, I havent used RSA in ages. FIX THIS!
Deploy is still broken, its messsing around with ubuntu user despite having root defined.
I filed an RFE for ed25519 support against our bug tracker here: bug#1901923
Please feel free to comment/add heat, etc.
Regarding root/ubuntu, Juju makes some assumptions about the Ubuntu user being available (for example, see bug#1886012). We’re working on untangling those dependencies moving forward. For now, things will likely work better if you have an ubuntu user with sudo privileges on the box that you are setting up.
I never seen an ubuntu user on any of ubuntu images, ESPECIALLY not with sudo privileges. Maybe for desktop? Certainly not on server images. I also fund lot of issues because juju expects quite a bunch of installed packages of machines I wanted to add, I often had failure there. I don’t know what ubuntu images are supported here? it’s definitely not server images. Docs aren’t telling me anything about specific requirements either
Thanks for your fast response though. I had nothing but issues with juju today after evaluating it for a new big project, I hope this will change the next days with more testing
Juju is built with cloud images like the ones at https://cloud-images.ubuntu.com/ in mind. These images are designed to be used with OpenStack clouds, and are similar in nature and configuration to the instances used in AWS.
The cloud images generally have some additional packages installed, and are designed to work well with cloud-init, which is an industry standard tool that solves some of the problems inherent in bootstrapping a software image in the cloud, without human intervention.
Since a human operator isn’t going to be sitting at a cloud instance as it comes up, able to type in a root password, cloud images typically come with a user account built in. cloud-init will drop an ssh key into the image as it inits, giving the human operators who eventually want to interact with the machine a secure way of doing so, without the need for a password.
When you’re working with a manual provider, you may need to do some additional work to make your images look similar to the images used by the clouds that Juju natively supports. For example, you need to be able to run cloud-init, which is how the Juju machine agent gets installed, among other things. It can be a little bit tricky – feel free to ask questions here as you continue to evaluate Juju.
