Search results

The 'unattended' part is done via Ansible on my end, This keeps the config of my 4-node cluster in check. For this i start out with a Debian box to start with, and then ( as the wiki describes ) the move to Proxmox. Playbooks control what packages are needed, repository setup, specific...

In essence every program is a bunch of lines...

Unclear : are we talking of a Proxmox server or a guest on proxmox ?

Just a general question, as the topic said. I myself have both a cluster and a standalone machine for testing purposes. This machine is the result of a debian-install-move to proxmox based on the Wiki and Buster distro, running the latest 6.x version. When running Lynis security audit...

Only thing i can think of is the intro of cgroupsv2 which isnt supported by older OS's ( like CentOS-7 ) ... i tried to implement the kernel options but that didnt work out, as i ran from the one error into the other error, leaving me with an inoperable CentOS-7 LXC - which was quite important...

The 'additional settings' all point towards the way you implemented your Cluster. This makes it quite hard for me to assume your current situation. As you have stated : - you run a 2-Node cluster - corosync contains the specific reference as such. But the great unknown/not disclosed is : - do...

i would first check if the additional settings needed for a 2-node lcuster are still correct / in place.

This playbook is actively in use on a 4-node cluster

No worries, i also use PfSense Firewall , glad it got sorted :) Please mark the thread as solved

Could it be that you are using a 3rd party tool to do such stuff something like https://github.com/Corsinvest/cv4pve-cli ?

Is chrony the future - stepping away from ntpd , and if yes how can one migrate from ntpd to chrony while performing an upgrade of PVE ?

a bit unclear, but you seems you are running a 2-node Cluster ? Question : for a 2-node cluster some additional config needed to be made ... => Could it be that when you upgraded the definition of having a 2-node cluster got erased, so its now killing the other node while working with the other ?

The mechanism for making backups is already there, make em as always, then for the one day he wants an offsite backup ( or better said copy of it offsite) use rsync to just send the already made backup to where he wants it to

I admire all offered options, but ... are we not we over-complicating things ? Why not use RSync ? its easy works on linux and windows can be scheduelled works over secure connection

For what its worth, i experienced the same error-code on my cluster (1006) but looking in the error on the webUI mentions of LC_PVE_TICKET not set, VNC proxy without password is forbidden Examining nodes i found that known_hosts were on their own ( /root/.ssh/known_hosts...

It has been a long time sice i posted in this thread, Alot has changed over the time which has passed. we have a PVE 7 release ( yes i upgraded to it) i am still working on ansible as alternative of puppet, and i think i am quite close to getting it finalised. Just a peek on the playbook i am...

Also what i have noticed in testing it with my IDP is that it chokes on the sent request: <amLogEntry> 2021-07-09T13:56:58Z SEVERE NIDS OAuth: Illegal character """ at position 645 is not allowed as a start of a name in a path template...

FYI: I have scanned the mentioned thread and i see that its on the roadmap of the next release of CheckMK : https://checkmk.com/werk/12307 so its a matter of waiting for that release.

As far as i remember, and i must admit its been a long time since i had migrated a VM, its never been this low, however exact fugures i do not have. I mean the cluster nodes are all connected to 1Gb ethernet ( no separate net for cluster comms) and all have double ( failover config) net

Proxmox 7 has introduced OpenID-Connect authentication which enables us to go on the path of federated login. However for all the different Identity provider solutions the option will have to get ALOT more flexible. Options at the moment are soo limited they are constricting to a single IDP...