Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
SSH key management in PVE is handled in a set of secondary files, while the original debian files are replaced with symlinks. Well, that's still debian. And in some circumstances the symlinks get b0rked or replaced with the original SSH files, the keys get out of sync, and one machine in the cluster can't talk to another. The really irritating thing about this is that the tools meant to fix it (pvecm updatecerts) don't work. I've got an elaborate set of procedures to gather the certs from the hosts and fix the files when it breaks, but it sux bad enough that I've got two clusters I'm putting off fixing.
Corosync is the cluster. It's a shared file system that immediately replicates any changes to all members. That's essentially anything under /etc/pve/. Corosync is very sensitive. I believe they ask for 10ms lag or less between hosts, so it can't work over a WAN connection. Shit like VM restores or vmotion between hosts can flood it out. Looks fukin awful when it goes down. Your whole cluster goes kaput.
All corosync does is push around this set of config files, so a dedicated NIC is overkill, but in busy environments, you might wind up resorting to that. You can put cororsync on its own network, but you obviously need a network for that. And you can establish throttles on various types of host file transfer activities, but that's a balancing act that I've only gotten right in our colos where we only have 1gb networks. I have my systems provisioned on a dedicated corosync vlan and also use a secondary IP on a different physical interface, but corosync is too dumb to fall back to the secondary if the primary is still "up", regardless of whether its actually communicating, so I get calls on my day off about "the cluster is down!!!1" when people restore backups.
Thanks for your answer.
I use proxmox since version 2.1 in my home lab and since 2020 in production at work. We did not have issues with the ssh files yet. Also corosync is working fine although it shares its 10g network with ceph.
In all that time I was not aware of how the certs are handled, despite the fact I had two official proxmox trainings. Ouch.
Cool.
Here. SSH key issues. There was a huge forum war.
https://forum.proxmox.com/threads/ssh-keys-in-a-proxmox-cluster-resolving-replication-host-key-verification-failed-errors.138102/
But its still a thing. That still needs to be fixed by a human. Today that's me.
Regarding CEPH and corosync on the same network ... well I'm just getting started with that now. I do have them on different vlans, but its the same 10gb set of nics. I'm hoping if it gets really lousy, my netadmin can prioritize the corosync vlan. I'll burn that bridge when I come to it.
EDIT ... The linked forum post above leads to the SSH key answer, but its convoluted.
Here's what I put in my own wiki.
Get the right key from each server.
cat ~/.ssh/id_rsa.pub
Make sure they match in here. Fix em if they don't.
/etc/pve/priv/authorized_keys
There's a couple symlinks to fix too, but this should get it.