2023-08-13T00:17:45 *** teepee_ is now known as teepee 2023-08-13T01:22:30 *** teepee_ is now known as teepee 2023-08-13T16:20:15 *** teepee_ is now known as teepee 2023-08-13T17:44:50 acidsys: just wondering - why do you need moreutils in the salt-testing container? 2023-08-13T17:49:33 mispipe 2023-08-13T17:50:05 an escape to our POSIX pipefail adventure ;-) 2023-08-13T17:51:09 ah, getting rid of bashisms ;-) 2023-08-13T17:51:14 hehe 2023-08-13T17:51:28 though I learned recently that it's on its way to be standardized by the open group (probably another X years to be implemented by shells and distributions) 2023-08-13T17:52:42 I'm sure even then there will be fans of "traditional POSIX" who avoid the new, fancy POSIX standard ;-) 2023-08-13T17:53:04 great, another environment variable like MAN_POSIXLY_CORRECT 2023-08-13T17:53:37 ;-) 2023-08-13T17:54:55 Just in case you are bored ;-) - the jekyll cronjob on jekyll.i.o.o sends mails as jekyll@localhost which - for obvious reasons - get rejected 2023-08-13T17:58:09 "myhostname = localhost" doesn't sound quite right 2023-08-13T17:58:17 indeed 2023-08-13T17:58:59 ideally we'd salt that so that the VM stays fully salted ;-) 2023-08-13T18:01:29 https://gitlab.infra.opensuse.org/infra/salt/-/merge_requests/672 2023-08-13T18:02:31 ah wait it should be infra.opensuse.org 2023-08-13T18:03:32 that, and pillar/common/init.sls already has a postfix section which would be a better place for your addition 2023-08-13T18:06:33 ok, now 2023-08-13T18:06:52 I know it would be cleaner to read the roles but I don't want to load the files just for it 2023-08-13T18:07:14 if we need it in another place we can make a macro that reads the id files for role queries inside the pillar 2023-08-13T18:08:33 no worries about that ;-) you could probably even drop the if condition - the mailserver pillar will just overwrite the value from common/init.sls 2023-08-13T18:09:42 will it not merge them ? 2023-08-13T18:11:25 it will merge the maincf structure, but if it hits a different value for the same key (for example "myhostname"), it will be overwritten (last one wins) 2023-08-13T18:11:59 interesting, and how is role.mailserver the last one / having priority? alphabetic includes? 2023-08-13T18:12:23 include order in pillar/top.sls 2023-08-13T18:12:45 nice, I didn't know the top order made a difference 2023-08-13T18:13:36 I learned that the hard way when I started to integrate my *.geeko test VMs, and had to integrate some things at the right place ("late enough" ;-) 2023-08-13T18:13:36 ok, down to a single line :-) 2023-08-13T18:14:11 nice :-) - set to auto-merge 2023-08-13T18:15:10 sweet 2023-08-13T18:17:00 I wonder if Postfix is already started on new VM's, because we do not touch /var/adm/postfix.configured 2023-08-13T18:17:19 so if it starts for the first time it will overwrite it with the /etc/sysconfig/postfix generated stuff 2023-08-13T18:17:45 * acidsys takes mental note to observe next time 2023-08-13T18:17:49 IIRC it gets started automagically (probably via salt) 2023-08-13T18:18:07 yes but if salt is the first one starting it, then you would need to state.apply a second time to write the final postfix config 2023-08-13T18:18:25 because otherwise Salt configures main.cf -> Salt starts Postfix -> Postfix config script rewrites main.cf -> Postfix is started 2023-08-13T18:18:43 ah, the last remainders of SuSEConfig ;-) 2023-08-13T18:19:09 I don't remember issues with it, but it's indeed possible 2023-08-13T18:19:31 (and IIRC the correct fix would be somewhere in /etc/sysconfig/keep-your-fingers-away ;-) 2023-08-13T18:19:57 is it SuSEConfig? it's just a script shipped with the package /usr/lib/postfix/systemd/config_postfix 2023-08-13T18:20:17 right 2023-08-13T18:20:50 but I'm quite sure if you dig deep enough in your archive of openSUSE (or SUSE Linux) distros, you'll find the same script as SuSEConfig.postfix 2023-08-13T18:21:05 haha that's possible I guess :-) 2023-08-13T18:22:19 BTW: in case you wonder what I did today - the ~100 lines of https://gitlab.com/apparmor/apparmor/-/merge_requests/1082 took surprisingly long to get everything working (and the CI gave me some extra fun) 2023-08-13T18:32:44 ooh fancy 2023-08-13T18:35:36 sys.executable ? 2023-08-13T18:37:30 indeed, that looks good :-) 2023-08-13T18:39:31 now the only missing part is to find out if the coverage module is also loaded (typically with python3 -m coverage run [...] test-foo.py - but that doesn't transfer to subprocess calls) 2023-08-13T18:42:56 if it's the same interpreter, you could just try to import it and catch the exception 2023-08-13T18:47:23 looks like there's a more boring way - sys.modules 2023-08-13T18:48:25 oh cool I like that more :-) 2023-08-13T18:55:09 the result looks good - 4% more overall test coverage (and 10% more in a file that really needs it) :-) 2023-08-13T19:09:20 good job 2023-08-13T19:10:35 logprof .. I always I liked the simplicity but after I learnt how to write my own profiles I tend to find it having some quirks 2023-08-13T19:11:49 right, useful tools are rarely perfect (but it's still better than reading 1000 audit.log lines and "translating" them manually ;-) 2023-08-13T19:13:16 right :-) 2023-08-13T21:19:25 your postfix fix helped a bit - we got a new error ;-) (the mail was relayed to anna, and anna tried to deliver it to root@jekyll.i.o.o) 2023-08-13T21:19:37 the missing parts were 2023-08-13T21:20:11 - set mydestination to the hostname so that /etc/aliases gets honored (basically rewriting the mail target to admin-auto) 2023-08-13T21:20:23 - enable the 'local' transport in master.cf 2023-08-13T21:21:58 (no idea why it was disabled) 2023-08-13T21:28:03 interesting 2023-08-13T21:28:58 maybe with that we can resolve multiple of Per's Postfix TLC tickets 2023-08-13T21:29:42 what's the masquerading and root masquerade exception about? 2023-08-13T21:29:55 it seems to not be from the default configuration 2023-08-13T21:30:49 indeed, postconf -d masquerade_exceptions is empty 2023-08-13T21:31:18 it seems to be on many machines 2023-08-13T21:32:45 I don't know if it hurts - after the two changes I did, the jekyll mail was sent to admin-auto via mx1.o.o 2023-08-13T21:32:57 however, it didn't reach my inbox yet 2023-08-13T21:35:38 the mail reached mailman: 2023-08-13T21:35:42 2023-08-13T21:17:58.653220+00:00 mailman3 postfix/qmgr[3119]: 9E4ED127A: from=, size=3339, nrcpt=1 (queue active) 2023-08-13T21:35:48 2023-08-13T21:17:58.694447+00:00 mailman3 postfix/lmtp[29512]: 9E4ED127A: to=, relay=localhost[127.0.0.1]:8024, delay=0.05, delays=0.01/0.01/0/0.03, dsn=2.0.0, status=sent (250 Ok) 2023-08-13T21:37:11 *** teepee_ is now known as teepee 2023-08-13T21:37:31 note the from= - is this really the expected sender address? 2023-08-13T21:38:28 on jekyll.i.o.o it still was from=, next hop on anna logged it as from= 2023-08-13T21:41:25 the sender address is correct, it is the name of the user 2023-08-13T21:41:42 or do you mean the domain should be infra.opensuse.org 2023-08-13T21:41:54 right, I wondered about the rewritten domain 2023-08-13T21:42:06 I suppose anna does some mailservery things 2023-08-13T21:42:32 isn't anna one with the mailserver role? 2023-08-13T21:43:24 anna/elsa handle our outgoing mails 2023-08-13T21:43:41 but funnily they don't have the mailserver role (mx* have it) 2023-08-13T21:44:27 longer-term it's probably a good idea to handle outgoing mail on mx* so that anna/elsa can focus on haproxy 2023-08-13T21:46:07 ah then some manual configuration there 2023-08-13T21:46:59 yes I would want haproxy to forward the ports to mx 2023-08-13T21:47:37 I'd just change the relay.i.o.o DNS entry for that 2023-08-13T21:48:00 (but first make sure that mx* are correctly setup to handle outgoing mail) 2023-08-13T21:56:53 a for relay sure, I thought for mail from the internet. which I realize already goes to mx 2023-08-13T21:59:11 right, the external MX entries point to mx* 2023-08-13T23:29:00 *** teepee_ is now known as teepee