fosshostorg / aarch64 Goto Github PK

There is now a new API route for managing the dualstack service proxy, /proxy. The methods and example JSON bodies are in the docs, but it would be great to add another page under the "Manage" tab that contains a table of current proxies and a form for creating a new one. The table should have two columns, the left being Label and the right being VM, and the form should be the same but with a dropdown for VM selection.

Console users cannot remove themselves from a project once added. As a user can be added to a project without the user's prior knowledge or consent, I think it is important that we have a way for the user to remove themselves from the project.

In the "Batch creation" section for VM creation, the + and - buttons should switch position. I think people tend to associate + with right and - with left, probably because it's being used like that for a very long time.

Originally posted by @brunomiguel in #12

We're running a very old version of BCG which is now Pathvector. Let's update it with the latest v4 release for more flexibility in peering configs.

We should support SSH keys that can be included in the cloud-init config on VM creation time. Most importantly a user should be able to add/delete SSH keys for their account. I think it would also be beneficial to add SSH keys at a project level for things like project-wide provisioning, logging, auditing, etc.

I propose the following implementation:

• API routes to add (validate) and delete SSH keys on both a user and project basis
• A helper function that takes a project ID and returns a list of SSH keys for that project and all associated users
• Call this helper function on VM creation time to add a list of SSH keys to the VM project
• Modify cloud-init template to add to the SSH key list for root
• Add a list in the settings tab of the dashboard to display which keys were used when the VM was created

Currently there is no way for a user to recover from a lost/forgotten password.

You may want this to be a user flag at provisioning for edge cases, but typically using virtio block device on any modern linux is going to be optimal.

https://github.com/natesales/aarch64/blob/4e65af0ad78444f8b7f320feb7d68e633eecd568/provisioning/roles/vms/tasks/main.yml#L64

I'd suggest trying

--disk path=/opt/aarch64/vms/{{ item["_id"] }}-disk.qcow2,bus=virtio \

Using feature flags for the API will give more flexibility to handle incidents, and will make debugging bits of the services much easier. I'm working on a PR implementing this.

Any opinions?

A beta tester brought up that when deleting and creating VMs quickly, it's possible for a new VM to have the same assigned prefix as an old (now deleted) VM. This means a SSH fingerprint warning because the VM no longer exists. Maybe we should randomize the prefix assignment process to minimize this?

I've started writing an Ansible module to automate provisioning on aarch64 at https://github.com/natesales/ansible-module-aarch64-vm.

Next steps include:

• Finalizing aarch64-client-python and publishing to PyPi, then using it for the ansible module. (Currently the API code is copied into the module definition itself)
• Create an Ansible collection and publish to Galaxy
• Write other modules for project, proxy, and user account management

Originally posted by @natesales in #11

This is a frequently requested feature. Team has already been discussing this; creating an issue for tracking.

Please get code-review from @hamptonmoore and/or @natesales prior to merging.

First we need to setup ansible to install a python daemon on all machines

Provisioned Ubuntu 20.10 VM.. performed apt-update and reboot. network interface doesn't come back up.

Upon creating a project, three main problems exist:

• The whole sidebar flashes with undefined for around half a second.
• The forwarding to the new project page is broken. (forwards to projects/[object Object])
• Active link highlighting in the sidebar doesn't work until you reload the page.

https://bird.network.cz/pipermail/bird-users/2021-April/015367.html

I think having an RFC1918 NAT might be useful for users running docker or pre-made chroots where using DNS64+NAT64 can be on the tougher side.

Currently we show users all VM allocation options, including options they can't select as those choices would be above their allocated core count; perhaps we should limit the display to what options the user can actually allocate?

Request URL: https://console.aarch64.com/img/rocky-8.4.svg
instead of
Request URL: https://console.aarch64.com/img/rocky.svg

Per discussion on Discord; current OS system leads to some oddities like "Rocky" and "Rocky-8.4"

It would be cool to let projects provide feedback and see the roadmap using canny.io
Canny.io have kindly provided us with a free license as a FOSS project
The URL is https://roadmap.aarch64.com/aarch64 and I have already added some suggestions
I have sent admin invites to canny.io for those who require it so that we can manage this effectively
It would be great to use canny.io as a way of getting feedback through the use of community voting

When a VM is first created, it gets a temporary root password field called temp_password that we should display on the dashboard preferably with a copy button to make pasting it into a SSH session quick and easy.

Clicking signup visuall does nothing

Hello there, good morning.
I recently notice that this project uses GPL and it's a web application, however I think it would be better to use AGPL instead because AGPL contains some specif clauses that GPL doesn't contain to the non-release of source code for web applications.

as stated "The AGPL's additional clause only applies when the user interacts with but does not receive the program." from curiousdannii available in <https://opensource.stackexchange.com/questions/4303/is-there-any-difference-between-the-gpl-and-agpl-for-code-executed-in-the-browse >

While we look into a better storage solution we should at a minimum, create daily backups of VM images. This is probably as simple as making a libvirt domain snapshot and copying the files to our existing Fosshost backup servers for now.

@hamptonmoore and @natesales had been seriously considering adding Proxmox integration to the console to allow control of legacy hosts on the same dashboard as Aarch64.

Currently we're using libvirt-sshd which only allows a single SSH connection to the VM virtual serial console. It would be neat to implement a session mux so multiple sessions can access a VM console at once. This will also solve the problem of console sessions becoming stuck in connected state if your terminal doesn't exit gracefully.

It would be lovely to be able to rename projects via the Web UX.

Thanks for consideration!

Currently database edits are used to disable pops and hosts during the install of aarch64 nodes. We should likely replace this with at the minimum an API, and optimally some webui

Hydrogen doesn't update the state of local VMs on startup.

This may potentially break some things as we rely on VM names to also set the hostname.

POST /project/adduser

{
	"project": "605fdf474177ba62253eed4a",
	"email": "[email protected]"
}

Console users currently cannot change the email associated with their account. We should have a process to allow users to update their emails as needed.

Would be nice to have. I think we need new api route too.

OAuth login using providers such as Github will provide a convenient way for clients to login to the console.Also, I'm creating a cli for the console here, and supporting OAuth authentication will make that project's development much easier.

We should add an audit log that captures events on VM creation, deletion, etc to keep track of which user made which actions.

I think it would be beneficial for there to be a way to SSH into the VMs over IPv4. While there is the console it can be finicky and get in a limbo state where one has closed it, but it still believes it is open so one can not access it. A solution to allow for IPv4 SSH would be to create a "jump" user on each host with no password that is used to SSH jump to the IPv6 only VMs inside (https://wiki.gentoo.org/wiki/SSH_jump_host).

The base setup for this would be simple. Just adding a user called "jump" without a password like so

echo jump:U6aMy0wojraho | sudo chpasswd -e

and adding

Match User jump
   AllowAgentForwarding no
   AllowTcpForwarding yes
   X11Forwarding no
   PermitTunnel no
   GatewayPorts no
   ForceCommand echo 'This account can only be used for ProxyJump (ssh -J)'
   PermitEmptyPasswords yes

to the /etc/ssh/sshd_config of the hosts. This jump user can not gain a CLI or do anything besides jump to another host. The issue is then the "jump" user could be used to try to SSH into remote boxes and abused. I think SSH traffic could be limited using an iptables rule that only applies to the "jump" user but I have not had time to test that yet (https://www.cyberciti.biz/tips/block-outgoing-network-access-for-a-single-user-from-my-server-using-iptables.html).

Logging in with the jump user would be as simple as ssh -J [email protected] user@IPv6ofVM

A blank page shows after switching from New Project to Create new VM and back to New project.

video here: click me

Title explains it, only the hypervisor we are installing on should be restarted imo

TASK [virt : Restart libvirt-sshd] ************************************************
changed: [dfw0]
changed: [dfw2]
changed: [dfw1]
changed: [dfw3]
changed: [dfw4]
changed: [lon0]
changed: [lon2]
changed: [lon1]

When batch creating VMs, it redirects to the VM list screen very fast and doesnt actually create them.

If a hypervisor goes offline, we shouldn't try to schedule new VMs on it. Let's add a check before the host usage calculation https://github.com/fosshostorg/aarch64/blob/main/api.py#L623 to exclude a set list of hypervisors.