2025-08-22T06:15:32 acidsys: for https://github.com/openSUSE/slowroll-tools/blob/prod/tools/selectupdates.pl#L14 2025-08-22T06:15:44 maybe nginx can do CGIs, too? 2025-08-22T06:18:43 maybe via https://github.com/pjincz/nginx-cgi but it is not even packaged on OBS. 2025-08-22T07:54:29 bmwiedemann: ah cool, didn't spot that cgi script - that's fine if it has a legitimate purpose ^^ 2025-08-22T14:10:06 Hi, could you people have a look at paste.opensuse.org? It looks like it is briefly redirecting to susepaste.org then to paste.opensuse.org, with a new paste form. 2025-08-22T17:21:51 knurpht: cannot reproduce 2025-08-22T17:28:32 acidsys: that seems an apt description of what happens to me here https://forums.opensuse.org/t/update-kernel-not-booting-on-amd-athlon-x2/187241/14 2025-08-22T17:29:54 so, the issue is with accessing certain pastes 2025-08-22T17:30:39 I would be interested how @wkazubski is creating their paste, because it has a legacy URL 2025-08-22T17:33:02 LCP: maybe it is time we just remove oldapi_controller to avoid confusion? 2025-08-22T17:33:53 that's how susepaste submits the contents of the pastes 2025-08-22T17:34:03 so unless we replace susepaste, we can't 2025-08-22T17:34:35 susepaste success reports two urls, the old above the current 2025-08-22T17:35:00 new versions of susepaste won't report the old URL 2025-08-22T17:35:23 the forum user I referred to is using 15.6 2025-08-22T17:35:33 wkazubski 2025-08-22T17:37:38 LCP: how about only removing redirect() from it ? 2025-08-22T17:37:44 sure 2025-08-22T17:38:02 I guess it would avoid us more trouble if we just got rid of oldapi entirely 2025-08-22T17:38:15 somebody would write the new susepaste at some point 2025-08-22T17:38:33 (still doesn't explain why this users paste never made it to paste.o.o, but "paste does not exist" is easier in an error report than some output from legacy susepaste) 2025-08-22T17:38:42 yes I agree that the current susepaste tool should be replaced 2025-08-22T18:08:17 *WITH* "NICK=" and "KEY=" in ~/.susepaste it works as expected 2025-08-22T20:53:08 cboltz: can you merge in landing-page? 2025-08-22T20:55:23 yes, done 2025-08-22T20:55:42 thanks 2025-08-22T20:56:26 by the way I tried to add cleanup logic on static/master.sls similar as we have it in jekyll/master.sls but found it impossible with some repositories in the pillar being specified as subdirectories 2025-08-22T20:57:00 indeed, this would be quite tricky 2025-08-22T20:58:15 besides that - while auto-cleanup might sometimes be nice, it also makes switching a page from static to jekyll more difficult (at least if you plan for zero downtime) 2025-08-22T20:58:46 that's true 2025-08-22T20:59:04 so you are also saying that it's more difficult now to switch a page from jekyll back to static? ;-) 2025-08-22T21:00:33 IIRC we (also) don't have auto-cleanup in jekyll, so there shouldn't be a difference (except that the manual cleanup for jekyll has the additional "rendered files" directory, but that's a minor detail) 2025-08-22T21:01:26 we do, I introduced it in 39f1eecfff12e43d1a476fed65585ce28f1db8d0 ^^ 2025-08-22T21:03:52 oh, nice 2025-08-22T21:04:23 thinking about it - it shouldn't be that problematic because it doesn't delete anything from /srv/www 2025-08-22T21:04:45 so as long as web_jekyll doesn't do a cleanup (too early), there shouldn't be a problem 2025-08-22T21:05:17 you forgot about ce15a846b475319f1a11416a470ad79bb4651da1 ? 2025-08-22T21:06:00 indeed ;-) 2025-08-22T21:06:15 ;) 2025-08-22T21:07:00 the good thing is that it checks for web_jekyll and web_static, so if we move a site from one to the other, no cleanup should happen 2025-08-22T21:07:43 well it removes it from the one it was moved away from (which worked correctly with www) 2025-08-22T21:08:49 hence I only applied on static_master (only one backend less) first and only once served from jekyll on web_static 2025-08-22T21:08:49 right, but the cleanup works with {%- set all_sites = websites['web_jekyll'] + websites['web_static'] %} 2025-08-22T21:09:41 right, the order of applying the changes is indeeed relevant in this case ;-) 2025-08-22T21:10:54 websites[role] is only populated if the machine has a pillar from this role (I think it's "future proofing" for a machine having both static and jekyll) 2025-08-22T21:11:28 right, we have that plan since a long time 2025-08-22T21:11:37 maybe we should finallly implement it? ;-) 2025-08-22T21:11:51 (narwal4 would be a good candidate for testing it) 2025-08-22T21:12:57 sure, would be nice. related tt: https://progress.opensuse.org/issues/164245 2025-08-22T21:19:35 cboltz: your changes from https://gitlab.infra.opensuse.org/infra/salt/-/merge_requests/2551 were still pending, I applied it on atlas2, it causes "request: "HEAD /styles.css HTTP/2.0", upstream: "http://unix:/run/quiz/:/styles.css", host: "quiz.opensuse.org"" in backend nginx. do you want to fix it now or revert? 2025-08-22T21:23:24 to finish our previous topic - https://gitlab.infra.opensuse.org/infra/salt/-/merge_requests/2558 submitted 2025-08-22T21:24:19 cboltz@atlas2.infra.opensuse.org: Permission denied (publickey). - kanidm breakage? 2025-08-22T21:25:11 yeah " sshd[20668]: Invalid user cboltz from ..." try now 2025-08-22T21:25:35 better :-) 2025-08-22T21:26:31 still need to finish deploying kanidm 1.7.x maybe that will help 2025-08-22T21:37:36 I'm not really sure what is causing the problem with the quiz health check, so better revert it for now 2025-08-22T21:38:57 https://gitlab.infra.opensuse.org/infra/salt/-/merge_requests/2559 2025-08-22T21:54:46 ok, deployed and removed www.o.o leftovers 2025-08-22T21:55:00 thanks!