On Sat, Dec 24, 2022 at 08:05:12AM +0400, Samer Afach <samer.af...@msn.com> wrote:
> Dear Raf: > > Thank you for the hint about UNIX sockets. I'll keep them. My only fear > is/was that they're inappropriate to use across containers and something > will break in the future. I guess I'll have to wait and see. Probably the easiest thing is to configure all the sockets to be in the same directory so that only a single directory needs to be imported into all the containers. > There's actually an open issue in OpenDKIM github with this request from > months ago: https://github.com/trusteddomainproject/OpenDKIM/issues/153 > > Hopefully someone will find the time to do it. That issue hasn't had any response, so maybe they aren't interested. But I've just created a pull request to fix it: https://github.com/trusteddomainproject/OpenDKIM/pull/160 They still might not be interested, but hopefully, this will make it more likely to happen. > Cheers, > Sam cheers, raf > On 24/12/2022 7:38 AM, raf wrote: > > On Sat, Dec 24, 2022 at 06:28:29AM +0400, Samer Afach <samer.af...@msn.com> > > wrote: > > > > > On 24/12/2022 5:30 AM, raf wrote: > > > > On Fri, Dec 23, 2022 at 04:35:03PM +0400, Samer Afach > > > > <samer.af...@msn.com> wrote: > > > > > > > > > About your great loud thought, my containers are versioned but > > > > > there's > > > > > no CI in there, and every launch for them recreates them. > > > > > They're all > > > > > based on either Debian or Ubuntu (depending on support for my > > > > > applications), which means they'll be updated automatically. I > > > > > don't > > > > > use random images from untrusted sources. There's even plan to > > > > > run apt > > > > > update/upgrade on every launch to ensure everything is up to > > > > > date even > > > > > if I forget to recreate a container for any reason, and I'm > > > > > planning > > > > > cron jobs that'll restart the containers daily. I really > > > > > appreciate > > > > > your loud thoughts, keep 'em coming, and I hope I have it > > > > > covered that > > > > > one with my plan. > > > > One thing to consider, rather than restarting the > > > > containers daily, is to install the unattended-upgrades > > > > package in the container and a configuration for it > > > > that automatically installs at least all security > > > > upgrades. That way, the container can stay running for > > > > long periods of time without the need to restart it > > > > daily which presumably introduces tiny regular outages. > > > > > > > > cheers, > > > > raf > > > Dear Raf: > > > > > > That's actually what I do on all the bare-metal machines, but from my > > > understanding of how docker works, every container is made to run exactly > > > one service, and somehow default Linux images disable system services. > > > They > > > can be re-enabled, but it's not the way it's meant to work, and given that > > > I'm just a beginner in this whole docker thing, I'm trying not to jump > > > over > > > rooftops before some time passes by and I feel comfortable with everything > > > I've done so far and build the confidence of "It worked for a while, now > > > let's try changing that one thing". > > Ah, I didn't realise that. Thanks. It makes sense I > > suppose. A container can have any number of processes > > in it, but the default assumption is going to be > > immutable infrastructure, and it won't include any > > processes that you don't put in there explicitly. > > > > However, you could maybe have a cronjob outside the > > container that starts a process inside the container to > > perform security updates. But it sounds like a hassle. > > If the mail volume isn't huge, the tiny outages when > > restarting might not be a problem, and so they don't > > need to be eliminated. > > > > > This can get much worse for beginners, and it took me a while to get email > > > working properly. If you notice in my setup, you'll see that postfix, > > > dovecot and OpenDKIM each is running in its own container (and they all > > > must > > > be running in foreground mode to access logging). > > > Luckily, sharing socket > > > files in Linux is allowed among containers, and the reasoning there, if I > > > understand correctly, is that all these containers use the same kernel, > > > and > > > that's the only required condition. This simplified my setup a lot. Over > > > time I'll have to move everything to inet and stop using socket files > > > because it sounds dirty. > > I wouldn't be too keen to do that. UNIX domain sockets > > are faster than TCP. There's nothing dirty about them. > > It's just another network address family. And they have > > some nice benefits. > > > > > The worst part in all this is OpenDKIM. It doesn't support stdout logging, > > > which means I have to force the rsyslog service to work to see any errors, > > > but given that its docker should start with exactly 1 program in the > > > foreground, I don't know how to print the logs with something like tail > > > since OpenDKIM is running in the foreground. Another problem to be looking > > > into soon when I'm done with all these more prior piling issues. > > > Too much unsolicited information. Apologies, but I wanted to make the > > > situation clear, because this is a typical problem in docker. > > I'd be tempted to see all of these related processes as > > a single service (i.e. mail), and putting them in the > > same container with rsyslog. :-) > > But that's probably silly. > > > > The OpenDKIM authors would probably accept a patch for > > an option that logs to stdout rather than via syslog() > > for use in Docker. It should be easy enough to do. If > > not, at least raise an issue with them. They'd probably > > be happy to make their software easier to use in Docker. > > > > > Cheers, > > > Sam > > cheers, > > raf > >
