Slim down Promxmox? Disable corosync, pve-ha services?

[LnxBil]

site wide firewall and per guest firewalls are NOT MUTUALLY EXCLUSIVE. your site wide firewall doesn't provide protection for intrusions stemming from the inside.

That is the main point for the PVE firewall: virtual DMZ per VM, which is not easily available with pfsense. I cannot stress how good this solution is and it is not available in other virtualization solution (or it has additional costs).

correct. but I don't run guests for 3rd parties, I am the only person with access to them (and no guests even have SSH)

Even if you control everything, DMZ is ALWAYS a good idea and if you can restrict the VM to the services for in- and egress, why not?

 

[luison]

Thanks @t.lamprecht for the detailed response regarding logs. We will look into that and review.

For the tmps option we've been considering log2ram or a safe way to limit the tmpfs for certain logs without a flooding risk which is our only concern.

But back to the services you mention:

So there's the pve-ha-lrm pve-ha-crm, which make most sense to disable if one wants to reduce disk writes, as they might occasionally write their last active status time to disk.

So I am trying to guess if our changes make any sense or they should be changed from:

systemctl disable pve-ha-lrm pve-ha-crm corosync pvesr.timer pve-firewall pvefw-logger
to
systemctl disable pve-ha-lrm pve-ha-crm corosync

pvesr.timer Returns an error and I understand that pve-firewall and pvefw-logger will come back up even if disabled.

So, no point in editing "systemctl edit --full pve-manager"? Or is that the way to avoid services (ie firewall) coming back up?

#Wants=pve-firewall.service
#After=pve-firewall.service
#After=pve-ha-crm.service pve-ha-lrm.service

Thanks.

 

[t.lamprecht]

pvesr.timer Returns an error

yeah, that has been merged into the new pvescheduler.service service, which also handles backups and more without an external timer service.

So, no point in editing "systemctl edit --full pve-manager"? Or is that the way to avoid services (ie firewall) coming back up?

After and Before are ordering statements, they itself don't pull in anything, they just ensure correct order if a set of services starts up anyway (i.e., are all enabled).

Wants is a weak dependency (unlike Requires which is a hard one), the systemd.unit man pages states the following about wants:

Units listed in this option will be started if the configuring unit is. However, if the listed units fail to start or cannot be added to the transaction, this has no impact on the validity of the transaction as a whole, and this unit will still be started.

So you might need to mask things, which again, I'd recommend against - but its your host..

IMO there's no point in editing pve-guests.service (pve-manager is a depreacted alias for that), because it doesn't matter that pve-firewall runs, especially as it logs basically nothing (besides if there where errors), even if enabled...

 

[luison]

Thanks that helps a lot.

So you might need to mask things, which again, I'd recommend against - but its your host..

IMO there's no point in editing pve-guests.service (pve-manager is a depreacted alias for that), because it doesn't matter that pve-firewall runs, especially as it logs basically nothing (besides if there where errors), even if enabled...

I have no intention of masking, as it might affect updates and that is why asking for some guidance about this.

As for the firewall and login, I assume if it's not activated on the host or VMs it would not log anything anyway even if our firewall is using iptables.

I still have to admit, that it would make sense to have a simple way to disable the firewall if one is using an alternative.

 

[Proxygen]

... that you know of. kinda the point. only a fool trusts his security just because he is not aware of any intrusion.

well, to your point, pfsense also limits LAN to LAN connections, so....

 

[Neobin]

purge rsyslog, it's a remain of the past and handled by systemd-journald anyway - newer PVE installations won't include it anyway.

Would you please be so kind and elaborate, what one all needs to do, to only utilize journald on older installations?
Does journald need any additional configuration?
Is purging rsyslog enough?
Is some cleanup (especially of all the duplicate logs from rsyslog?) afterwards needed/recommended?

 

[LnxBil]

well, to your point, pfsense also limits LAN to LAN connections, so....

You have a one-VM-to-one-nic-pfsense setup so that you can limit each end every VM through pfsense?

 

[t.lamprecht]

Does journald need any additional configuration?

For older setups the most relevant setting is the Storage= one, as that (indirectly) controls if the journald is written to disk. Here, the default of auto means that it will be made persistent if the /var/log/journal directory exists. This is also what changed in newer installations, the journald.conf stayed the same, but the mentioned directory is now explicitly created on installation.

So, if that doesn't exist yet on an installation of yours, you can simply mkdir /var/log/journal it and then restart the service:
systemctl restart systemd-journald.service

For other settings check out the journald.conf man page: https://manpages.debian.org/bullseye/systemd/journald.conf.5.en.html#OPTIONS

Most have a quite telling name, and it boils down to basic space usage (runtime and system (persistent)), rate limiting, filtering.

There's no log rotation snippet, as journald manages that itself.
While you also can configure retention as a time span, most of the time space is the limiting factor and with rate limiting, compression and the binary format one has a good chance that there's a long time of logs preserved even if a service goes completely bonkers and spams the log.

Is some cleanup (especially of all the duplicate logs from rsyslog?) afterwards needed/recommended?

You might want to clean up the old log files (and their rotations). Not sure if I'd go as far as recommend doing that, but it might make sense to avoid that admins look at a leftover old, e.g., syslog file without noticing - plus they take up space, not much most of the time but still.

By default, rsyslog is configured to split (or copy!) incoming log message to different (or multiple) files.

For example, this snippet from /etc/rsyslog.conf is the most relevant base set that rsyslog will use:

#
# First some standard log files.  Log by facility.
#
auth,authpriv.*            /var/log/auth.log
*.*;auth,authpriv.none        -/var/log/syslog
#cron.*                /var/log/cron.log
daemon.*            -/var/log/daemon.log
kern.*                -/var/log/kern.log
lpr.*                -/var/log/lpr.log
mail.*                -/var/log/mail.log
user.*                -/var/log/user.log

So that'd be the base set on files (plus their log rotated variants) that one might want to clean up.

Packages might ship their own extra rules in /etc/rsyslog.d/*.conf, but IME not a lot of packages do so.

 

[Neobin]

For older setups the most relevant setting is the Storage= one, as that (indirectly) controls if the journald is written to disk. Here, the default of auto means that it will be made persistent if the /var/log/journal directory exists. This is also what changed in newer installations, the journald.conf stayed the same, but the mentioned directory is now explicitly created on installation.

So, if that doesn't exist yet on an installation of yours, you can simply mkdir /var/log/journal it and then restart the service:
systemctl restart systemd-journald.service

For other settings check out the journald.conf man page: https://manpages.debian.org/bullseye/systemd/journald.conf.5.en.html#OPTIONS

Most have a quite telling name, and it boils down to basic space usage (runtime and system (persistent)), rate limiting, filtering.

There's no log rotation snippet, as journald manages that itself.
While you also can configure retention as a time span, most of the time space is the limiting factor and with rate limiting, compression and the binary format one has a good chance that there's a long time of logs preserved even if a service goes completely bonkers and spams the log.


You might want to clean up the old log files (and their rotations). Not sure if I'd go as far as recommend doing that, but it might make sense to avoid that admins look at a leftover old, e.g., syslog file without noticing - plus they take up space, not much most of the time but still.

By default, rsyslog is configured to split (or copy!) incoming log message to different (or multiple) files.

For example, this snippet from /etc/rsyslog.conf is the most relevant base set that rsyslog will use:

#
# First some standard log files.  Log by facility.
#
auth,authpriv.*            /var/log/auth.log
*.*;auth,authpriv.none        -/var/log/syslog
#cron.*                /var/log/cron.log
daemon.*            -/var/log/daemon.log
kern.*                -/var/log/kern.log
lpr.*                -/var/log/lpr.log
mail.*                -/var/log/mail.log
user.*                -/var/log/user.log

So that'd be the base set on files (plus their log rotated variants) that one might want to clean up.

Packages might ship their own extra rules in /etc/rsyslog.d/*.conf, but IME not a lot of packages do so.

Thank you very much for the explanation.
Removed it and cleaned up on all my hosts and guests.

So it can be assumed that, since Debian 12 will not have rsyslog pre-installed anymore [1], Proxmox-products based on that version will also not ship with it ootb?

[1] https://wiki.debian.org/Rsyslog

 

[t.lamprecht]

So it can be assumed that, since Debian 12 will not have rsyslog pre-installed anymore [1], Proxmox-products based on that version will also not ship with it ootb?

Yes, exactly.