2025-04-21T02:45:48 *** teepee_ is now known as teepee 2025-04-21T13:39:59 fyi I installed podman from my home with patched Go on gitlab-runner{1,2} for testing now 2025-04-21T13:42:38 it seems the oom killer is so happy about my change it took over from the segfaults 2025-04-21T13:43:21 sounds interesting[tm]... 2025-04-21T13:43:35 the pipeline still succeeded though 2025-04-21T13:43:46 maybe the gitlab CI second retry masked the oom kill 2025-04-21T13:53:01 looking at your archrwr SR - would it make sense to do the reproducible build change directly in the code on code.o.o instead of doing it in the spec? 2025-04-21T13:53:54 in theory yes, but the build process is somewhat odd, dynamically generating C code containing the build date and host 2025-04-21T13:54:08 it should probably be some macro, or just removed completely 2025-04-21T13:54:40 I'd tend to remove it completely - the build host and date shouldn't be relevant to what the program does 2025-04-21T13:55:06 agree, and you find it in rpm 2025-04-21T13:56:22 but there's other things that should be improved, for example the makefile should have an install step with variables 2025-04-21T13:56:42 I did not feel like doing much more improvements at the moment 2025-04-21T13:57:39 supporting "make install" would be nice, but for a single file, it's not really needed ;-) 2025-04-21T13:58:48 can I convince you to at least move the reproducible fix to code.o.o? (either in the way sed does it, or by completely removing the non-reprocible code - your choice) 2025-04-21T14:10:21 guess I have to hack a bit more on it anyways, it seems mailman3.i.o.o newer had the packaged version installed, and the new binary does not load /etc/nginx/mails.rewritemap, it segfaults at the last line which it cannot split on whitespace 2025-04-21T14:10:23 /opensuse-translation-de/2009-10/msg00020.html /archives/list/translation-de@lists.opensuse.org/message/OYPDGD4YLT4GLSWUQXWIVBCIKC3AO6RZ/; 2025-04-21T14:10:26 /opensuse-translation-de/2009-11/msg00000⏎ 2025-04-21T14:10:58 I'm not sure what sources the currently running binary was built from that it deals with this, but I suppose this last line can go? unless someone knows what target that should point to 2025-04-21T14:24:25 that file is packaged in nginx-rewrite-lists-openSUSE-20210409-4.19.noarch - and rpm -V says it was modified (probably cut off) 2025-04-21T14:25:48 oh now I see it is much bigger 2025-04-21T14:26:45 right, it ends with zypp-devel/2020-03/ 2025-04-21T14:27:06 I'm still surprised that rpm reports it as modified, let me reinstall that package... 2025-04-21T14:30:59 there's a file size difference of 3 MB, line count is the same 2025-04-21T14:31:27 the difference is that the packaged file redirects to ../lists/.. while the modified one redirects to ../list/.. 2025-04-21T14:32:37 both variants seem to work, but lists redirects to list 2025-04-21T14:33:11 interesting, well I suppose it would make sense to have it direct to /list/ directly as opposed to two redirects 2025-04-21T14:33:36 right, that's what the modified file did - I guess someone hotfixed it without updating the package 2025-04-21T14:34:40 ah, we even have a lists -> list redirect in the nginx config 2025-04-21T14:35:39 fun. also does this need to be in /etc/nginx/? it would be nice for archrwr not to run with nginx privileges 2025-04-21T14:36:52 ah, found it - https://progress.opensuse.org/issues/123478 2025-04-21T14:37:22 the ticket even includes the sed command that was applied to mails.rewritemap 2025-04-21T14:37:40 (I'll add that to the spec now.) 2025-04-21T14:38:00 what about changing it in the source file instead? 2025-04-21T14:38:52 that would mean to change a 62 MB file (and that's already the xz-compressed size) 2025-04-21T14:39:02 sed is more friendly to the OBS storage ;-) 2025-04-21T14:39:30 I'm a bit confused how replacing the sources will increase storage 2025-04-21T14:39:49 besides 1 character more per line 2025-04-21T14:40:15 OBS keeps all the historic files (for version diffs, reverts etc.) 2025-04-21T14:41:03 ah ok 2025-04-21T14:43:20 the most storage-friendly way would have been to hardcode /archives/list/ at one place so that we don't have to repeat it millions of times in the file - but doing that now would be a bigger change 2025-04-21T14:43:33 so for now I'll only sed lists -> list in the spec 2025-04-21T14:43:58 right 2025-04-21T14:53:47 updated package installed - and verified that it matches the previous modified file 2025-04-21T14:55:47 https://code.opensuse.org/heroes/archrwr/pull-request/2 2025-04-21T14:57:52 this time I don't have an argument how to make you feel more comfortable reviewing C :P 2025-04-21T15:00:04 well, dropping unused variables is easy to verify by "still builds" ;-) 2025-04-21T15:01:28 :-) 2025-04-21T15:02:26 the other changes also look sane, so feel free to merge 2025-04-21T15:06:24 !2432 needs a rebase 2025-04-21T15:09:41 Hi, all! I'm getting a cert error on https://idp-portal.suse.com/univention/self-service/#page=createaccount. Because of this, I'm also unable to create an account to report the issue. Thought I should let someone know. 2025-04-21T15:11:23 hi ACSpike[Work], already noted your message in -buildservice, thanks for reporting 2025-04-21T15:11:53 cboltz: done 2025-04-21T15:12:29 acidsys: Oh, sorry for cross posting noise. Someone in -buildservice recommended I post it here too. 2025-04-21T15:12:47 no that's fine, here is a good place :) 2025-04-21T15:14:22 cboltz: the archrwr release versioning scheme does not quite "support" two releases in a single day, shall I wait til tomorrow or do we switch to normal version numbers ? 2025-04-21T15:15:00 just wait (at least) 7 hours ;-) 2025-04-21T15:15:29 actually I can just pretend it's tomorrow already 2025-04-21T15:15:53 oh, a release from the future ;-) 2025-04-21T15:16:04 * cboltz hopes it includes the lottery numbers 2025-04-21T15:16:48 yes, I hid the lottery numbers inside mails.rewritemap as your easter egg hunt. happy searching! 2025-04-21T18:53:00 *** teepee_ is now known as teepee 2025-04-21T21:02:35 cboltz: "Link /srv/www/en{,-test}.opensuse.org/public/mediawiki_src target is set to be changed to /usr/share/mediawiki_137/" ? 2025-04-21T21:04:00 jid 20250421154021737367 2025-04-21T21:06:22 that should be 1.37 (with a dot) - unfortunately I don't have an obvious explanation what eats that dot :-/ 2025-04-21T21:08:05 err, actually an underscore 2025-04-21T21:19:34 looks like it only affects 1.37, so the workaround would probably be to explicitely set the version for en.o.o instead of relying on the default version 2025-04-21T21:25:14 salt-call pillar.get mediawiki says: default_version: 137 2025-04-21T21:25:55 let me add two salt.log to try finding where it's coming from 2025-04-21T21:26:18 the default_version should be the same format as version 2025-04-21T21:26:50 * matrix-o-o malcolmlewis and add one salt block for the cows, logs are too much for them... 2025-04-21T21:27:46 wild guess: maybe you just need to add quotes: default_version: '{{ default_wiki_version }}' 2025-04-21T21:28:35 the pillar should be fine, according to `salt riesling.infra.opensuse.org pillar.get mediawiki:default_version` 2025-04-21T21:29:08 I tried directly on riesling, and it gave me 137 (without underscore) 2025-04-21T21:29:16 huh 2025-04-21T21:30:01 interesting, indeed it renders it as an integer there 2025-04-21T21:30:29 and on the master as a string 2025-04-21T21:31:17 try adding the quotes - that would (besides adding an indirection via the variable) basically restore the previous line 2025-04-21T21:31:44 it seems it had the old value in the cache, refreshing again makes it return as an integer there too 2025-04-21T21:31:51 yes sure 2025-04-21T21:45:53 looks better now :-) 2025-04-21T21:47:01 lots of state.test output, but it looks ok, fingers crossed 2025-04-21T21:51:36 seems to have worked, one issue I have is aa-remove-unknown always removing lots of httpd2-event things every time I run it 2025-04-21T21:51:50 what's missing to make it stay empty? 2025-04-21T21:56:32 note the "null-" part in the child profiles - these profiles are automatically created in complain mode if the target profile is missing 2025-04-21T21:56:36 *** teepee_ is now known as teepee 2025-04-21T21:56:40 so it's ok to unload them (done now) 2025-04-21T21:57:05 hm I figured, but I rather meant that they always re-appear ? 2025-04-21T21:57:15 or did you do something else to unload them other than aa-remove-unknown 2025-04-21T21:57:33 now that you added the hats to the profile, they shouldn't 2025-04-21T21:57:57 well I just run aa-remove-unknown for the nth time and again lots of output 2025-04-21T22:00:08 found it - the apache vhosts.d/* have lines like #AADefaultHatName vhost_enwiki 2025-04-21T22:00:26 so a) it's commented out and b) the hat names are vhost_en, not vhost_enwiki 2025-04-21T22:00:41 oh! it never wrote the salt configuration 2025-04-21T22:01:06 let me hotfix it with sed 2025-04-21T22:01:12 no need 2025-04-21T22:01:20 it did not write the salt vhosts because config test failed because !2438 2025-04-21T22:01:49 let's see after that 2025-04-21T22:02:27 that MR looks good 2025-04-21T22:36:08 now aaccess denied :( 2025-04-21T22:36:57 I tried aa-complain httpd2-event as a hot workaround but no help 2025-04-21T22:37:35 this is pretty much the reason why I rather would have kept making a proper aa profile for later 2025-04-21T22:40:06 seems it needs full restart to load the profiles, but found another issue in vhost while at it 2025-04-21T22:40:12 I'm not sure if AppArmor is guilty ;-) 2025-04-21T22:40:22 [Mon Apr 21 22:39:36.945357 2025] [rewrite:error] [pid 15101:tid 140592776464064] [client ...] AH00670: Options FollowSymLinks and SymLinksIfOwnerMatch are both off, so the RewriteRule directive is also forbidden due to its similar ability to circumvent directory restrictions : /srv/www/en.opensuse.org/public/favicon.ico 2025-04-21T22:40:42 that is the "another issue" 2025-04-21T22:40:50 the AA gave tons of DENIED in audit.log 2025-04-21T22:42:17 I see you commented out AADefaultHat again, which (unsurprisingly) floods the audit.log 2025-04-21T22:42:34 I'm quite sure you could keep it enabled 2025-04-21T22:43:09 actually I manually did that for en.o.o before you applied the salt changes, and it worked 2025-04-21T22:44:16 well all I know it returned lots of things like 2025-04-21T22:44:19 type=AVC msg=audit(1745274751.425:21078456): apparmor="DENIED" operation="open" class="file" profile="httpd2-event//vhost_en" name="/usr/share/mediawiki_1_37/resources/src/mediawiki.action/images/checker.svg" p 2025-04-21T22:44:21 id=12404 comm="httpd-event" requested_mask="r" denied_mask="r" fsuid=30 ouid=0 2025-04-21T22:44:52 if you think that classifies as good enough we can keep it sure 2025-04-21T22:45:13 or rather it will be enabled again anyways when I apply the other change 2025-04-21T22:45:42 maybe the profile isn't perfect yet, but commenting out AADefaultHatName and flooding the log with the null-* log entries isn't better 2025-04-21T22:47:09 the profile needs /usr/share/mediawiki_1_*/** r, for all vhosts 2025-04-21T22:49:33 will you add that, or shall I? 2025-04-21T22:50:54 working on it now 2025-04-21T22:51:00 I would have preferred to make rules depending on {{ version }} 2025-04-21T22:51:23 let's call that a future improvement, the mediawiki code isn't that secret ;-) 2025-04-21T22:53:06 also I will move away /etc/apparmor.d/httpd2-prefork because that loads unnecessary profiles 2025-04-21T22:54:09 no objections 2025-04-21T23:03:15 ok highstate shows no more changes and now you will tell me what obvious things I am missing that it is still flooding audit log ? 2025-04-21T23:03:38 the merge pipeline for the apparmor changes is still running 2025-04-21T23:04:03 I circumvented the pipeline 2025-04-21T23:04:14 your patch is applied 2025-04-21T23:04:41 I talk about all the ALLOWED entries now 2025-04-21T23:05:05 ah, I see 2025-04-21T23:05:11 ah because the main httpd-even is in complain 2025-04-21T23:05:41 seems I copied that from the old -prefork 2025-04-21T23:06:08 /proc/*/attr/apparmor/current is used to change hats, so we'll have to allow that 2025-04-21T23:08:03 seems they all have /attr/current but not /attr/apparmor/current. did that change? 2025-04-21T23:08:46 yes (with fallback to the old path) 2025-04-21T23:08:56 I just hotfixed the profile, MR will follow 2025-04-21T23:09:02 ah ok 2025-04-21T23:09:17 cool then if no more ALLOWED lines consider also removing complain? :-) 2025-04-21T23:10:02 give it some time to verify we really catched everything now ;-) 2025-04-21T23:10:33 BTW: aa-logprof says php-fpm wants to read /etc/kanidm/unixd (didn't add that yet) 2025-04-21T23:12:16 that one we already had the discussion and we merged it upstream, so we can add a local in salt but should remember to remove it when newer AA makes it into the distribution 2025-04-21T23:12:34 right 2025-04-21T23:15:28 there are still a few new ALLOWED lines, but nothing that couldn't wait until tomorrow 2025-04-21T23:15:45 I have an urgent meeting with /dev/bed ;-) 2025-04-21T23:16:03 ok, good night! 2025-04-21T23:16:08 good night