Fachschaft/nixConfig
6
2
Fork 2
Code Issues 10 Pull requests 1 Projects Wiki Activity

nyarlathotep: cleanup after deployment #55

Merged
Gonne merged 22 commits from Gonne/nixConfig:nyarlathotep into main 2025-03-24 19:38:06 +00:00
Conversation 6 Commits 22 Files changed 8 +2 -3
1 changed files with 2 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit ceaaa3bcaf - Show all commits

5
nixos/modules/mail.nix
View file

@ -214,9 +214,8 @@ in {
++ ["sieve.trusted.*"]; #for macros to be able to include our redirection script
sieve.trusted = {
scripts.redirects.contents = "%{file:/tmp/virt_aliases}%"; # generated redirect script
Gonne marked this conversation as resolved Outdated
nerf commented 2025-03-18 09:29:39 +00:00
Outdated
Copy link

maybe we should move this file from /tmp into the /run directory as this usually has proper
file access rights set up.

maybe we should move this file from `/tmp` into the `/run` directory as this usually has proper file access rights set up.
Gonne commented 2025-03-18 10:27:33 +00:00
Outdated
Copy link

There is also JoinsNamespaceOf for PrivateTmp of systemd service units (https://www.man7.org/linux/man-pages/man5/systemd.exec.5.html) but I didn't succeed setting it.

Reading https://lwn.net/Articles/436012/ I have no idea whether /run is a better place.

There is also `JoinsNamespaceOf` for `PrivateTmp` of systemd service units (https://www.man7.org/linux/man-pages/man5/systemd.exec.5.html) but I didn't succeed setting it. Reading https://lwn.net/Articles/436012/ I have no idea whether `/run` is a better place.
nerf commented 2025-03-18 12:26:04 +00:00
Outdated
Copy link

We don't care about the early boot discussion. So the question is, is it runtime date or temporary data, wherever the boundary between these two is. Putting things in /tmp is often a buggy mess as this directory is usually somewhat of a global dumpster fire, where there are no guarantees that this file does not already exist with some important information for some other process (though unlikely). PrivateTmp would save us here, but even the documentation says that one should not rely on this (and we would need to get it to work).

If we already follow Lennart's advice then we also should use mkstemp to generate files in /tmp which will
be very painful in a nix setting (as paths and filenames will only be available at runtime). Lennart also seems to think that /run is primarily for communication primitives (is this one?).
See his blogpost.

So after reading all of this maybe the cleanest option is to get the JoinNamespaceOf option to work?

We don't care about the early boot discussion. So the question is, is it runtime date or temporary data, wherever the boundary between these two is. Putting things in `/tmp` is often a buggy mess as this directory is usually somewhat of a global dumpster fire, where there are no guarantees that this file does not already exist with some important information for some other process (though unlikely). `PrivateTmp` would save us here, but even the documentation says that one should not rely on this (and we would need to get it to work). If we already follow Lennart's advice then we also should use `mkstemp` to generate files in `/tmp` which will be very painful in a nix setting (as paths and filenames will only be available at runtime). Lennart also seems to think that `/run` is primarily for communication primitives (is this one?). See [his blogpost](https://0pointer.net/blog/projects/tmp.html). So after reading all of this maybe the cleanest option is to get the `JoinNamespaceOf` option to work?
Gonne commented 2025-03-24 09:47:30 +00:00
Outdated
Copy link

I got the private /tmp with JoinsNamespaceOf working.

I got the private `/tmp` with `JoinsNamespaceOf` working.
from-addr = "sender"; # set the from-address to the original sender as specified in the MAIL FROM.
from-name = "sender";
return-path = "sender";
return-path = "sender"; # set the outgoing MAIL FROM to the original sender as specified in the incoming MAIL FROM.
Gonne marked this conversation as resolved Outdated
nerf commented 2025-03-02 16:03:00 +00:00
Outdated
Copy link

the trusted part is to much, also see the comment at from-name below

the `trusted` part is to much, also see the comment at `from-name` below
👍 1
Gonne marked this conversation as resolved Outdated
nerf commented 2025-03-02 16:05:15 +00:00
Outdated
Copy link

I couldn't figure out what from-name or from-addr actually do. Reading the documentation I believe combined they
set the default value for the From: header of a generated mail. But I couldn't verify this in tests.
Maybe it does something different that has to do with the MAIL FROM: see comment below

I couldn't figure out what `from-name` or `from-addr` actually do. Reading the documentation I believe combined they set the default value for the `From:` header of a generated mail. But I couldn't verify this in tests. Maybe it does something different that has to do with the `MAIL FROM:` see comment below
nerf marked this conversation as resolved
nerf commented 2025-03-19 12:55:27 +00:00
Copy link

where did the /tmp folder discussion disappeared to?

where did the `/tmp` folder discussion disappeared to?
nerf commented 2025-03-19 12:56:33 +00:00
Copy link

ahh it got marked outdated

ahh it got marked outdated
# If we are the sender, we sign the message with DKIM. Else we leave it alone.
Gonne marked this conversation as resolved Outdated
nerf commented 2025-03-02 16:06:36 +00:00
Outdated
Copy link

This seems to do what we want, even though the documentation reads like it sets the Return-Path: header. But it seems to set the reverse path (which is the argument to the MAIL FROM: smtp command). Maybe it does both?

This seems to do what we want, even though the documentation reads like it sets the `Return-Path:` header. But it seems to set the reverse path (which is the argument to the `MAIL FROM:` smtp command). Maybe it does both?
nerf commented 2025-03-03 10:36:53 +00:00
Outdated
Copy link

This parameter seems to control the MAIL FROM: and with this all the headers we want to set.
The documentation reads to me as if it sets the Return-Path: header. I'm unsure if it actually does it.

This parameter seems to control the `MAIL FROM:` and with this all the headers we want to set. The documentation reads to me as if it sets the `Return-Path:` header. I'm unsure if it actually does it.
sign = [
{