[pve-devel] [RFC cluster] pmxcfs startup: order before MTAs

[pve-devel] [RFC cluster] pmxcfs startup: order before MTAs

[Stoiko Ivanov]

currently pmxcfs and the running mta (postfix in most cases I assume)
have no ordering between them - resulting in the mta starting before
pmxcfs.

This can be problematic in case of a mail for 'root' being in the
mailq: postfix tries to deliver the mail - pvemailforward tries to
look up the destination address in /etc/pve/user.cfg and gets a
connection refused since pmxcfs is not running yet.

reported via our community-forum:
https://forum.proxmox.com/threads/.108893/

Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
---
sending as RFC, since while thinking about this issue and discussing it
off-list (thx @Fiona!) the following alternative approaches were/are
considered:
* letting pvemailforward.pl exit with an error-code - sadly does not work
  as the only difference is that postfix generates a bounce for the mail
  and in (the most-common) case of root being the sender that bounce is
  also undeliverable, and thus dropped
* the fix through systemd-ordering does work for this case - but seems
  not quite fitting (after all pmxcfs and postfix can happily exist w/o
  the other - only delivering mail to root does not work) - also
  the issue also happens if pmxcfs is not available for other reasons
* an alternative approach would be to retry fetching the information from
  pmxcfs a few times (afair postfix' command-timeout is 1000s for this),
  e.g. like we do in the installer when looking for the correct ISO.

 debian/pve-cluster.service | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/pve-cluster.service b/debian/pve-cluster.service
index 4327055..fb706be 100644
--- a/debian/pve-cluster.service
+++ b/debian/pve-cluster.service
@@ -5,6 +5,7 @@ Wants=corosync.service
 Wants=rrdcached.service
 Before=corosync.service
 Before=cron.service
+Before=postfix.service exim4.service sendmail.service qmail.service
 After=network.target
 After=sys-fs-fuse-connections.mount
 After=time-sync.target
-- 
2.30.2

Re: [pve-devel] [RFC cluster] pmxcfs startup: order before MTAs

[Aaron Lauterer]

If the systemd ordering is okay, what about how we have with Ceph, where we 
place the "ceph-after-pve-cluster.conf" for each service instead of changing the 
pve-cluster.service?

See my recent patch regarding this [0].



[0] https://lists.proxmox.com/pipermail/pve-devel/2022-July/053546.html

On 9/5/22 13:58, Stoiko Ivanov wrote:
> currently pmxcfs and the running mta (postfix in most cases I assume)
> have no ordering between them - resulting in the mta starting before
> pmxcfs.
> 
> This can be problematic in case of a mail for 'root' being in the
> mailq: postfix tries to deliver the mail - pvemailforward tries to
> look up the destination address in /etc/pve/user.cfg and gets a
> connection refused since pmxcfs is not running yet.
> 
> reported via our community-forum:
> https://forum.proxmox.com/threads/.108893/
> 
> Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
> ---
> sending as RFC, since while thinking about this issue and discussing it
> off-list (thx @Fiona!) the following alternative approaches were/are
> considered:
> * letting pvemailforward.pl exit with an error-code - sadly does not work
>    as the only difference is that postfix generates a bounce for the mail
>    and in (the most-common) case of root being the sender that bounce is
>    also undeliverable, and thus dropped
> * the fix through systemd-ordering does work for this case - but seems
>    not quite fitting (after all pmxcfs and postfix can happily exist w/o
>    the other - only delivering mail to root does not work) - also
>    the issue also happens if pmxcfs is not available for other reasons
> * an alternative approach would be to retry fetching the information from
>    pmxcfs a few times (afair postfix' command-timeout is 1000s for this),
>    e.g. like we do in the installer when looking for the correct ISO.
> 
>   debian/pve-cluster.service | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/debian/pve-cluster.service b/debian/pve-cluster.service
> index 4327055..fb706be 100644
> --- a/debian/pve-cluster.service
> +++ b/debian/pve-cluster.service
> @@ -5,6 +5,7 @@ Wants=corosync.service
>   Wants=rrdcached.service
>   Before=corosync.service
>   Before=cron.service
> +Before=postfix.service exim4.service sendmail.service qmail.service
>   After=network.target
>   After=sys-fs-fuse-connections.mount
>   After=time-sync.target

Re: [pve-devel] [RFC cluster] pmxcfs startup: order before MTAs

[Stoiko Ivanov]

On Mon, 5 Sep 2022 14:06:02 +0200
Aaron Lauterer <a.lauterer@proxmox.com> wrote:

> If the systemd ordering is okay, what about how we have with Ceph, where we 
> place the "ceph-after-pve-cluster.conf" for each service instead of changing the 
> pve-cluster.service?
thanks for the hint - can be done - the gain would be that we can
ship this in pve-manager instead of pve-cluster then I guess and thus make
it more clear that it's not directly related to pmxcfs<->postfix
interaction - or is there some other upside?

would work for me - and I'll gladly sent a version with this - still
currently more and more considering the retry reading the
user/datacenter.cfg a few times to be the actually better solution (and
would be grateful for feedback for this)

> 
> See my recent patch regarding this [0].
> 
> 
> 
> [0] https://lists.proxmox.com/pipermail/pve-devel/2022-July/053546.html
> 
> On 9/5/22 13:58, Stoiko Ivanov wrote:
> > currently pmxcfs and the running mta (postfix in most cases I assume)
> > have no ordering between them - resulting in the mta starting before
> > pmxcfs.
> > 
> > This can be problematic in case of a mail for 'root' being in the
> > mailq: postfix tries to deliver the mail - pvemailforward tries to
> > look up the destination address in /etc/pve/user.cfg and gets a
> > connection refused since pmxcfs is not running yet.
> > 
> > reported via our community-forum:
> > https://forum.proxmox.com/threads/.108893/
> > 
> > Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
> > ---
> > sending as RFC, since while thinking about this issue and discussing it
> > off-list (thx @Fiona!) the following alternative approaches were/are
> > considered:
> > * letting pvemailforward.pl exit with an error-code - sadly does not work
> >    as the only difference is that postfix generates a bounce for the mail
> >    and in (the most-common) case of root being the sender that bounce is
> >    also undeliverable, and thus dropped
> > * the fix through systemd-ordering does work for this case - but seems
> >    not quite fitting (after all pmxcfs and postfix can happily exist w/o
> >    the other - only delivering mail to root does not work) - also
> >    the issue also happens if pmxcfs is not available for other reasons
> > * an alternative approach would be to retry fetching the information from
> >    pmxcfs a few times (afair postfix' command-timeout is 1000s for this),
> >    e.g. like we do in the installer when looking for the correct ISO.
> > 
> >   debian/pve-cluster.service | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/debian/pve-cluster.service b/debian/pve-cluster.service
> > index 4327055..fb706be 100644
> > --- a/debian/pve-cluster.service
> > +++ b/debian/pve-cluster.service
> > @@ -5,6 +5,7 @@ Wants=corosync.service
> >   Wants=rrdcached.service
> >   Before=corosync.service
> >   Before=cron.service
> > +Before=postfix.service exim4.service sendmail.service qmail.service
> >   After=network.target
> >   After=sys-fs-fuse-connections.mount
> >   After=time-sync.target  
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> 
>