search

djjudas21 / charts

Collection of Helm charts
14 stars 6 forks source link

[smtp-relay] Add persistence for postfix mail queue #61

Closed bmm-alc closed 4 months ago

bmm-alc commented 4 months ago

Is your feature request related to a problem ?

If there is a connexion issue with a relay server and you have to restart the pod to apply a new configuration you loose all the mail stuck in the queue.

Describe the solution you'd like.

the chart should provision a pvc and mount it inside the postfix pod (on /var/spool/postfix ?)

Describe alternatives you've considered.

no one

Additional context.

No response

djjudas21 commented 4 months ago

I like your suggestion. I will implement it soon, when I have some time.

I'm thinking of making it a toggle feature, so the current stateless behaviour can be preserved for those who want it, but with the option of mounting a PVC or an emptydir.

I'll need to check out what happens if someone is running 2 replicas and they use the same PVC. Probably "something bad". So I will probably need to convert the Deployment into a Statefulset, so each pod gets its own PVC.

bmm-alc commented 4 months ago

Hi

thanks for the quick reply, and thanks for the chart you did. I did not think about some people might have several replicas, so you're right this is not as simple as adding a pvc to the deployment... also, From the PVC documentation this is not possible to mount volume into volume so there might be an issue with the socket /var/spool/postfix/public

Best.

djjudas21 commented 4 months ago

I've just released a new Docker image djjudas21/smtp-relay:0.7.0 so I'll include this in the helm chart too

djjudas21 commented 4 months ago

So currently the metrics sidecar image gets its information by also mounting /var/spool/postfix/public/showq from the main Postfix image.

Using a PVC in ReadWriteOnce mode won't work because both containers want to mount it. I'll have to use ReadWriteMany. Is that going to work for you, @bmm-alc?

djjudas21 commented 4 months ago

I think the chart is working but upgrading the smtp-relay image to Alpine 3.19 is crashing out, looks like a permissions issue

/usr/lib/python3.11/site-packages/supervisor/options.py:474: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
  self.warnings.warn(
2024-02-23 20:27:42,393 CRIT Supervisor is running as root.  Privileges were not dropped because no user is specified in the config file.  If you intend to run as root, you can set user=root in the config file to avoid this message.
2024-02-23 20:27:42,393 INFO Included extra file "/etc/supervisor.d/postfix.ini" during parsing
2024-02-23 20:27:42,393 INFO Included extra file "/etc/supervisor.d/rsyslog.ini" during parsing
2024-02-23 20:27:42,397 INFO RPC interface 'supervisor' initialized
2024-02-23 20:27:42,397 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2024-02-23 20:27:42,397 INFO supervisord started with pid 18
2024-02-23 20:27:43,401 INFO spawned: 'master' with pid 19
2024-02-23 20:27:43,406 INFO spawned: 'rsyslog' with pid 20
2024-02-23T20:27:43.422487+00:00 smtp-smtp-relay-0 : [origin software="rsyslogd" swVersion="8.2310.0" x-pid="20" x-info="https://www.rsyslog.com"] start
2024-02-23 20:27:43,423 INFO success: master entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2024-02-23 20:27:44,425 INFO success: rsyslog entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-02-23T20:27:44.694628+00:00 smtp-smtp-relay-0 postfix/postfix-script[133]: warning: not owned by postfix: /var/spool/postfix/public
2024-02-23T20:27:44.699412+00:00 smtp-smtp-relay-0 postfix/postfix-script[136]: warning: not owned by group postdrop: /var/spool/postfix/public
2024-02-23T20:27:44.704548+00:00 smtp-smtp-relay-0 postfix/postfix-script[139]: starting the Postfix mail system
2024-02-23T20:27:44.711952+00:00 smtp-smtp-relay-0 postfix/master[141]: daemon started -- version 3.8.5, configuration /etc/postfix
2024-02-23 20:27:44,712 INFO exited: master (exit status 0; expected)
2024-02-23T20:27:51.608313+00:00 smtp-smtp-relay-0 postfix/smtpd[144]: connect from 192-168-0-59.csi-rbdplugin-metrics.rook-ceph.svc.cluster.local[192.168.0.59]
2024-02-23T20:27:51.608436+00:00 smtp-smtp-relay-0 postfix/smtpd[144]: lost connection after CONNECT from 192-168-0-59.csi-rbdplugin-metrics.rook-ceph.svc.cluster.local[192.168.0.59]
2024-02-23T20:27:51.608456+00:00 smtp-smtp-relay-0 postfix/smtpd[144]: disconnect from 192-168-0-59.csi-rbdplugin-metrics.rook-ceph.svc.cluster.local[192.168.0.59] commands=0/0
2024-02-23T20:27:51.610292+00:00 smtp-smtp-relay-0 postfix/smtpd[144]: connect from 192-168-0-59.prometheus-stack-prometheus-node-exporter.monitoring.svc.cluster.local[192.168.0.59]
2024-02-23T20:27:51.610372+00:00 smtp-smtp-relay-0 postfix/smtpd[144]: lost connection after CONNECT from 192-168-0-59.prometheus-stack-prometheus-node-exporter.monitoring.svc.cluster.local[192.168.0.59]
2024-02-23T20:27:51.610383+00:00 smtp-smtp-relay-0 postfix/smtpd[144]: disconnect from 192-168-0-59.prometheus-stack-prometheus-node-exporter.monitoring.svc.cluster.local[192.168.0.59] commands=0/0
2024-02-23T20:27:51.611966+00:00 smtp-smtp-relay-0 postfix/smtpd[144]: connect from 192-168-0-59.csi-rbdplugin-metrics.rook-ceph.svc.cluster.local[192.168.0.59]
2024-02-23T20:27:51.612043+00:00 smtp-smtp-relay-0 postfix/smtpd[144]: lost connection after CONNECT from 192-168-0-59.csi-rbdplugin-metrics.rook-ceph.svc.cluster.local[192.168.0.59]
2024-02-23T20:27:51.612058+00:00 smtp-smtp-relay-0 postfix/smtpd[144]: disconnect from 192-168-0-59.csi-rbdplugin-metrics.rook-ceph.svc.cluster.local[192.168.0.59] commands=0/0
2024-02-23T20:28:01.578945+00:00 smtp-smtp-relay-0 postfix/smtpd[146]: connect from 192-168-0-59.kubernetes.default.svc.cluster.local[192.168.0.59]
2024-02-23T20:28:01.579233+00:00 smtp-smtp-relay-0 postfix/smtpd[146]: lost connection after CONNECT from 192-168-0-59.kubernetes.default.svc.cluster.local[192.168.0.59]
2024-02-23T20:28:01.579268+00:00 smtp-smtp-relay-0 postfix/smtpd[146]: disconnect from 192-168-0-59.kubernetes.default.svc.cluster.local[192.168.0.59] commands=0/0
2024-02-23T20:28:01.579362+00:00 smtp-smtp-relay-0 postfix/smtpd[144]: connect from 192-168-0-59.prometheus-stack-prometheus-node-exporter.monitoring.svc.cluster.local[192.168.0.59]
2024-02-23T20:28:01.579622+00:00 smtp-smtp-relay-0 postfix/smtpd[144]: lost connection after CONNECT from 192-168-0-59.prometheus-stack-prometheus-node-exporter.monitoring.svc.cluster.local[192.168.0.59]
2024-02-23T20:28:01.579669+00:00 smtp-smtp-relay-0 postfix/smtpd[144]: disconnect from 192-168-0-59.prometheus-stack-prometheus-node-exporter.monitoring.svc.cluster.local[192.168.0.59] commands=0/0
bmm-alc commented 4 months ago

Hi @djjudas21 and thanks for looking so promptly into this issue.

(I'm not really familiar yet with k8s, sorry if some answer does not make sense)

About use of ReadWriteMany, I assume this is about sharing data between several container. I'm afraid it will prevent a lot of people (including me) using this because there is not a lot of cloud provider provider such storage (and AFAIK this is most of the time a nfs storage). I think this is not necessary to try to share the storage between multiple pods, perhaps just going with a statefulSet is enough ?

About the mount in mount issue, could the showq socket be mounted out of the volume ? Or perhaps another solution would be to create one volume and create one subpath per directory under /var/spool/postfix/ ?

best

djjudas21 commented 4 months ago

I have found a way to preserve the /var/spool/postfix/ volume as ReadWriteOnce and then mount the sockets (including showq) on /var/spool/postfix/public as emptyDir so it can be shared between the postfix container and the metrics container within the same pod (nothing is shared between pods).

It seems to be working for me now, but there is still a problem with the permissions on the showq socket so I think I need to rework the container permissions. But at least the persistent volumes and StatefulSet are working:

[jonathan@poseidon smtp]$ kubectl get pods
NAME                READY   STATUS    RESTARTS        AGE
smtp-smtp-relay-0   2/2     Running   2 (2d12h ago)   2d12h
smtp-smtp-relay-1   2/2     Running   2 (2d12h ago)   2d12h

[jonathan@poseidon smtp]$ kubectl get pvc
NAME                      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
spool-smtp-smtp-relay-0   Bound    pvc-487b4e7b-d58c-4178-80ea-b7a904b0cc9b   200Mi      RWO            ceph-block     2d12h
spool-smtp-smtp-relay-1   Bound    pvc-360e8819-7f18-4757-8b20-bb3c222995b3   200Mi      RWO            ceph-block     2d12h
djjudas21 commented 4 months ago

@bmm-alc please try v0.5.0 of the chart and let me know if it works for you

bmm-alc commented 4 months ago

Ok, I'll get back

Thanks for implementing this. :+1:

bmm-alc commented 4 months ago

Hello

Seems good to me.

thank you

On Mon, Feb 26, 2024 at 2:40 PM Jonathan @.***> wrote:

@bmm-alc https://github.com/bmm-alc please try v0.5.0 of the chart and let me know if it works for you

— Reply to this email directly, view it on GitHub https://github.com/djjudas21/charts/issues/61#issuecomment-1964173750, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATF2SCRHALUDAGKYM5ORRPTYVSGFNAVCNFSM6AAAAABDWYCQKKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRUGE3TGNZVGA . You are receiving this because you were mentioned.Message ID: @.***>