view the rest of the comments
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.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
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!
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.