2020-04-22T00:29:10  *** Dream[m] is now known as Dream[m]1
2020-04-22T00:29:11  *** Dream[m]1 is now known as Dream[m]2
2020-04-22T04:37:04  *** janPontaoski[m]1 is now known as pontaoskiblackqu
2020-04-22T04:44:15  -heroes-bot- PROBLEM: PSQL locks on mirrordb2.infra.opensuse.org - POSTGRES_LOCKS CRITICAL: DB postgres total locks: 315 * total waiting locks: 153 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=mirrordb2.infra.opensuse.org&service=PSQL%20locks
2020-04-22T04:44:54  -heroes-bot- PROBLEM: PSQL locks on mirrordb1.infra.opensuse.org - POSTGRES_LOCKS CRITICAL: DB postgres total waiting locks: 4 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=mirrordb1.infra.opensuse.org&service=PSQL%20locks
2020-04-22T04:54:15  -heroes-bot- RECOVERY: PSQL locks on mirrordb2.infra.opensuse.org - POSTGRES_LOCKS OK: DB postgres total=1 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=mirrordb2.infra.opensuse.org&service=PSQL%20locks
2020-04-22T04:54:54  -heroes-bot- RECOVERY: PSQL locks on mirrordb1.infra.opensuse.org - POSTGRES_LOCKS OK: DB postgres total=4 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=mirrordb1.infra.opensuse.org&service=PSQL%20locks
2020-04-22T06:16:43  *** Kryptos[m] is now known as HackerTheCat1420
2020-04-22T06:16:45  *** HackerTheCat1420 is now known as HackerTheCat[m]
2020-04-22T06:58:02  <lcp> cboltz: the only issue is this
2020-04-22T06:58:13  * lcp uploaded an image: Screenshot from 2020-04-22 08-57-34.png (28KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/NUztXGkOUBDmvGAWNUPoNKpf >
2020-04-22T06:58:28  <lcp> I assume it doesn't redirect to https automatically
2020-04-22T07:00:32  *** HackerTheCat[m] is now known as Kryptos[m]1
2020-04-22T07:00:32  *** Kryptos[m]1 is now known as Kryptos[m]2
2020-04-22T07:09:23  <lcp> cboltz: sadly it seems http -> https redirect __has to__ happen before any other redirect
2020-04-22T08:27:15  *** senndaii[m] is now known as Hamakaze2BVeryba
2020-04-22T09:44:20  <darix> lcp:   redirect scheme   https code 301                                     if !is_ssl !letsencrypt
2020-04-22T10:18:34  <kl_eisbaer> tuanpembual: I want to delete the old redmine database now to avoid irritations in the future. This in turn means that the old redmine will become more or less completely obsolete, as it will not work any longer. Which in turn means: can we decomission the old redmine host completely ?
2020-04-22T10:19:31  <tuanpembual> Hi kl_eisbaer
2020-04-22T10:19:58  <tuanpembual> Can I request dump for that db, last backup.
2020-04-22T10:20:03  <tuanpembual> ?
2020-04-22T10:20:16  <tuanpembual> just for worst case.
2020-04-22T11:01:59  <kl_eisbaer> tuanpembual: of course, no problem.
2020-04-22T11:02:11  <kl_eisbaer> I have dumps of the last 31 days at hand :-)
2020-04-22T11:02:22  <kl_eisbaer> where should I place it?
2020-04-22T11:03:14  <tuanpembual> on new progress:/home/tuanpembual/
2020-04-22T11:03:26  <tuanpembual> just for last dump is enough.
2020-04-22T11:03:44  <tuanpembual> for destroy old machine, what do you think cboltz ?
2020-04-22T11:04:15  <tuanpembual> I fine with kl_eisbaer request.
2020-04-22T11:05:50  <cboltz> well, without the database the VM is basically useless ;-)
2020-04-22T11:06:34  <cboltz> maybe shut it down now, and keep the image for a few weeks? (even if it's unlikely that we'll need it)
2020-04-22T11:23:38  <kl_eisbaer> tuanpembual: latest backup from 2020-04-22 is in  progress:/home/tuanpembual/
2020-04-22T11:23:52  <kl_eisbaer> cboltz: how much is "a few weeks"?
2020-04-22T11:25:20  <cboltz> good question, maybe a month?
2020-04-22T11:27:26  <tuanpembual> thanks kl_eisbaer
2020-04-22T11:28:03  <kl_eisbaer> cboltz: JFYI: I will keep a local copy of /etc /root /var/log and probably the stuff in /srv
2020-04-22T11:29:19  <cboltz> ok, thanks
2020-04-22T11:37:28  <lcp> cboltz: did you see what darix wrote about the haproxy to redirect to https on openid?
2020-04-22T11:38:29  <lcp> kl_eisbaer: would you look into the fedora vms somewhat soonish, we kinda wanna be done with implementing the accounts
2020-04-22T11:41:28  <cboltz> yes, I've seen it, and will work on it tonight
2020-04-22T11:45:07  <lcp> excellent, thanks
2020-04-22T11:47:21  <cboltz> the most interesting question is if we can/should do it for "all except $small_list" domains, or if we should limit it to a (probably big) list of domains that support https
2020-04-22T11:47:44  <cboltz> for example, redirecting download.o.o to https would be a bad idea
2020-04-22T11:47:55  <darix> cboltz: redirect all except for a few
2020-04-22T11:47:57  <lcp> was gonna say
2020-04-22T11:47:59  <darix> we want ssl for everything
2020-04-22T11:48:11  <darix> i use http probe for letsencrypt
2020-04-22T11:48:16  <darix> that's why I have that exception
2020-04-22T11:48:57  <cboltz> download.o.o also uses our letsencrypt cert, so that check won't be too useful
2020-04-22T11:49:03  <darix> uhm
2020-04-22T11:49:11  <darix> cboltz: download.o.o is not behind haproxy
2020-04-22T11:49:20  <darix> and opensuse uses dns probe
2020-04-22T11:51:05  <kl_eisbaer> lcp: Sorry, I thought that someone from SUSE-IT like bmwiedemann1 or jdsn would take care
2020-04-22T11:51:22  <kl_eisbaer> lcp: I will have a look later today, ok?
2020-04-22T11:51:34  <cboltz> are you sure about "download.o.o is not behind haproxy"? I see more than one mention of "download" in haproxy.cfg
2020-04-22T11:51:54  <darix> cboltz: yes
2020-04-22T11:51:58  <darix> on the internal interface
2020-04-22T11:52:00  <lcp> kl_eisbaer: no worries, as long as it happens this week, we will manage :P
2020-04-22T11:52:09  <darix> download.infra.opensuse.org to downloadcontent
2020-04-22T11:52:49  <darix> so vms that dont have nat can reach download.o.o
2020-04-22T11:53:16  <cboltz> yes, in   frontend http-dmz-in
2020-04-22T11:53:23  <cboltz> and   frontend http-ext-in   has   default_backend download   which gets used for domains that reach haproxy while not having a haproxy config
2020-04-22T11:53:46  <darix> host download.opensuse.org
2020-04-22T11:53:55  <darix> is that the IP of anna/elsa or their vip?
2020-04-22T11:54:41  <cboltz> no, that IP is directly on pontifex
2020-04-22T11:55:00  <cboltz> so requests from the internet shouldn't see haproxy
2020-04-22T11:55:06  <darix> correct
2020-04-22T11:55:26  <darix> you can also make a 404 backend on haproxy
2020-04-22T11:55:41  <darix> which sends out a static file for "you have found an unknown vhost"
2020-04-22T11:56:21  <lcp> we gotta do that when I make us some nice error page templates
2020-04-22T11:56:46  <cboltz> sounds like a good idea for cleanup
2020-04-22T11:57:12  <darix> https://git.nordisch.org/snippets/156
2020-04-22T11:57:27  <darix> I can give you my response file so it keeps the proper line endings
2020-04-22T11:57:49  <darix> I also do robots.txt like hat :P
2020-04-22T12:00:10  <darix> btw: if you ever use hugo I have a container you can use for gitlab-ci for it
2020-04-22T12:00:29  <darix> I also made a jekyll container for lethliel but that is just basic jekyll
2020-04-22T12:01:12  <lcp> we have jekyll.infra.opensuse.org going already
2020-04-22T12:01:23  <lcp> we don't really have any need for hugo container yet
2020-04-22T12:01:31  <darix> hugo >>> jekyll
2020-04-22T12:01:33  <darix> just saying:P
2020-04-22T12:02:00  <Eighth_Doctor> python >>> ruby >>> golang :)
2020-04-22T12:02:07  <darix> uhm
2020-04-22T12:02:11  <darix> NO
2020-04-22T12:02:28  <Eighth_Doctor> 😆
2020-04-22T12:03:04  <lcp> I didn't like hugo that much
2020-04-22T12:03:52  <lcp> although jekyll is slow for our need of pushing > 1000 articles per site
2020-04-22T12:04:12  <darix> lcp: we (as in pixls.us) use it for a few websites like digikam or rawtherapee and it is super fast
2020-04-22T12:04:25  <darix> pat already regretted to go with some js based stuff for the pixls.us page
2020-04-22T12:04:28  <darix> :)
2020-04-22T12:05:34  <lcp> well, jekyll is super fast if you have to process few articles, it's just an issue when you have a huge backlog to keep up with
2020-04-22T12:08:21  <darix> lcp: for RT ... the 131 pages take 0.5s :)
2020-04-22T12:08:34  <darix> dont know where digikam runs it
2020-04-22T12:10:21  <cboltz> darix: can you please do a bit of paperwork and forward https://www.reddit.com/r/openSUSE/comments/g5etun/opensuse_website_registration_broken/ to MF-IT? ;-)
2020-04-22T12:10:34  <cboltz> (I just tested it, still broken)
2020-04-22T12:25:29  *** Eighth_Doctor is now known as Conan_Kudo
2020-04-22T12:27:22  *** Conan_Kudo is now known as Eighth_Doctor
2020-04-22T12:28:26  *** Eighth_Doctor is now known as Conan_Kudo
2020-04-22T12:29:01  *** Conan_Kudo is now known as Eighth_Doctor
2020-04-22T12:29:49  *** Eighth_Doctor is now known as Conan_Kudo
2020-04-22T12:30:13  *** Conan_Kudo is now known as Eighth_Doctor
2020-04-22T13:21:40  *** Martchus_ is now known as Martchus
2020-04-22T15:35:43  <klein> hi there, I will apply upgrades on gitlab
2020-04-22T15:36:29  <klein> and, need a reboot due to dbus updates
2020-04-22T15:36:33  <klein> ok?
2020-04-22T15:36:54  <cboltz> just do it ;-)
2020-04-22T15:41:07  <cboltz> for the http -> https redirect we discussed earlier today, I checked the haproxy.cfg for "interesting" domains
2020-04-22T15:41:16  <cboltz> most services should work with https without problems
2020-04-22T15:41:50  <cboltz> however I'm unsure about conncheck.o.o - I have no idea how the conncheck applet will behave if it gets a redirect to https
2020-04-22T15:42:46  <cboltz> so in the end I'm going to redirect everything (well, everything that is CNAME proxy.o.o) to https, with the exception of conncheck
2020-04-22T15:42:57  <cboltz> any objections?
2020-04-22T15:43:19  <lcp> sounds good to me
2020-04-22T15:46:28  <cboltz> done, please check (especially, but not only www-new.o.o and www-new.o.o/openid/)
2020-04-22T15:46:29  <klein> looks like we had a problem with the new gitlab packages, already checking with the maintainer
2020-04-22T15:48:15  <klein> darix:
2020-04-22T15:48:43  <lcp> cboltz: it seems it still redirects from www-new to www first and then to https when it's on www already
2020-04-22T15:50:23  <cboltz> can you give me a   curl -v $url   command that shows this?
2020-04-22T15:52:59  <lcp> hm, I will restart firefox first because it might be a fluke
2020-04-22T15:56:10  <lcp> `expires:	Thu, 19 Nov 1981 08:52:00 GMT` susepaste has some cool headers
2020-04-22T15:57:01  <lcp> yeah, openid now redirects correctly
2020-04-22T15:57:14  <lcp> susepaste doesn't, I probably should test with something else
2020-04-22T15:58:23  <cboltz> susepaste is an external server, and therefore isn't affected by the http -> https redirect in haproxy
2020-04-22T15:59:32  <lcp> yeah, I can tell
2020-04-22T16:01:11  <lcp> cboltz: you should be able to test it using this form https://www.libravatar.org/openid/login/?openid_identifier=www-new.opensuse.org/openid/user&change-avatar=Change+Avatar
2020-04-22T16:01:50  <lcp> network tab suggest now that the issue is www.o.o redirect
2020-04-22T16:02:43  -heroes-bot- PROBLEM: MySQL WSREP recv on galera1.infra.opensuse.org - CRIT wsrep_local_recv_queue_avg = 5.994415 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=galera1.infra.opensuse.org&service=MySQL%20WSREP%20recv
2020-04-22T16:03:46  <lcp> cboltz: I see the issue
2020-04-22T16:04:28  <lcp> but I don't know how to fix it
2020-04-22T16:04:58  <lcp> when you access www.opensuse.org/openid/user, it returns xml file containing https://www.opensuse.org/openid/provider, but when you access www-new.opensuse.org/openid/user, it returns http://www.opensuse.org/openid/provider
2020-04-22T16:06:03  <lcp> I suspect you need to get that xml from port 443 regardless of everything else
2020-04-22T16:06:53  <lcp> so instead of redirecting to the url, redirect to url:443
2020-04-22T16:07:01  <lcp> behind the proxy
2020-04-22T16:07:09  <lcp> for /openid/* stuff
2020-04-22T16:07:40  <cboltz> technically it's not a redirect, it's proxying
2020-04-22T16:07:49  <cboltz> and it already goes to port 443
2020-04-22T16:08:33  <cboltz> haproxy config: https://paste.opensuse.org/33657134
2020-04-22T16:09:01  <cboltz> (the last two lines are superfluous, I just deleted them)
2020-04-22T16:09:47  <lcp> maybe there is another header we need then
2020-04-22T16:15:21  <cboltz> I tried adding a bunch of https-related headers (basically all ideas I found in haproxy.cfg) - https://paste.opensuse.org/744d3b5a
2020-04-22T16:15:34  <cboltz> but still get http in /openid/user
2020-04-22T16:17:51  <cboltz> actually - /openid/user looks static. If this is the only problem, maybe we can serve it with the "correct" content ourself instead of proxying it to Provo?
2020-04-22T16:18:08  <cboltz> unfortunately that makes the setup more ugly :-/
2020-04-22T16:24:17  <klein> somehow I tried to access gitlab, and got redirected to https://www.opensuse.org/
2020-04-22T16:25:42  <cboltz> you are not alone - lcp has seen that some days ago, but only for the gitlab main page and only if not logged in
2020-04-22T16:26:02  <cboltz> curl -v https://gitlab.infra.opensuse.org --insecure   shows that the redirect gets done on gitlab.i.o.o
2020-04-22T16:27:55  <lcp> cboltz: we could, I do wonder why this happens though
2020-04-22T16:31:42  <klein> humm... that's weird
2020-04-22T16:33:54  <klein> I don't see anything on nginx that could do that, maybe some internal setting on gitlab
2020-04-22T16:33:59  <klein> checking with darix
2020-04-22T16:35:50  <cboltz> lcp: I also have no idea why it happens
2020-04-22T16:36:17  <cboltz> just to be sure we don't open a can of worms - is this really the only problem, or could more things show up after fixing this?
2020-04-22T16:37:09  <lcp> no, that's basically the only issue by the looks of it
2020-04-22T16:38:15  <lcp> although, you know what, maybe let's try something else
2020-04-22T16:38:42  <darix> das the gitlab.infra.o.o address point to haproxy or to nginx?
2020-04-22T16:38:51  <darix> nginx will probably not redirect you to www.
2020-04-22T16:39:01  <lcp> can we host there for a sec an xml file like so:
2020-04-22T16:39:09  * lcp sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/vdfNtPPGDXxBbutvhLwJIzEF >
2020-04-22T16:39:53  <cboltz> lcp: right, www-new makes sense, at least for testing
2020-04-22T16:40:38  <klein> darix: if I try to reolve here, it points directly to the gitlab server, so, nginx
2020-04-22T16:43:55  *** Kryptos[m]2 is now known as Kryptos[m]4
2020-04-22T16:43:56  *** Kryptos[m]4 is now known as Kryptos[m]6
2020-04-22T16:46:08  *** Kryptos[m]6 is now known as Kryptos[m]8
2020-04-22T16:46:08  *** Kryptos[m]8 is now known as Kryptos[m]10
2020-04-22T16:50:34  <klein> I can't see anything wrong on the gitlab configs
2020-04-22T16:51:13  <darix> klein: do you only get the redirect when you go to http or also https?
2020-04-22T16:52:42  -heroes-bot- PROBLEM: MySQL WSREP recv on galera1.infra.opensuse.org - CRIT wsrep_local_recv_queue_avg = 30.847134 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=galera1.infra.opensuse.org&service=MySQL%20WSREP%20recv
2020-04-22T17:03:52  <cboltz> lcp: https://www-new.opensuse.org/openid/user should deliver the expected content now
2020-04-22T17:04:58  <klein> darix: can't say, now that I am logged in, I dont get redirected anymore
2020-04-22T17:06:10  <cboltz> curl -v https://gitlab.infra.opensuse.org --insecure   # redirect to www.o.o
2020-04-22T17:06:21  <cboltz> curl -v http://gitlab.infra.opensuse.org --insecure   # redirect to https://gitlab.infra.opensuse.org/
2020-04-22T17:06:45  <darix> well check the nginx config then?
2020-04-22T17:07:36  <lcp> cboltz: the xml header breaks it apparently
2020-04-22T17:09:13  <lcp> huh, interesting, the curl result is different from what firefox returns
2020-04-22T17:09:50  <cboltz> firefox cache?
2020-04-22T17:10:05  <lcp> nope, it's with correct url
2020-04-22T17:12:25  <klein> the only place with a `return` clause in nginx is on http (not https as reported by cboltz ) and it has `return 301 https://$http_host$request_uri`
2020-04-22T17:13:06  <klein> which makes no sense, since: (1) the redirect happens on https, (2) the server_name in this case is set to ... ohhh wait
2020-04-22T17:14:04  <klein> nope, server_name is set to gitlab.infra.opensuse.org, no other setting overriding the $host variable
2020-04-22T17:14:44  <cboltz> I'm quite sure the problem is in gitlab because the redirect only happens if you are not logged in - and nginx probably doesn't "know" that
2020-04-22T17:15:23  <cboltz> lcp: just to be sure, please try again - maybe I forgot to reload haproxy after changing the /openid/user file
2020-04-22T17:15:32  * lcp uploaded an image: Screenshot from 2020-04-22 19-15-05.png (11KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/pxBVYgfwCprXDzVnCjYjzzMG >
2020-04-22T17:15:36  * lcp uploaded an image: Screenshot from 2020-04-22 19-14-49.png (27KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/PBuyNQveXuPhTfSJhSVQqohR >
2020-04-22T17:16:03  <lcp> I'm trying to find what else it might need
2020-04-22T17:16:49  <cboltz> I can try to add all the headers we get from Provo
2020-04-22T17:16:52  * klein agrees with cboltz 
2020-04-22T17:17:52  <lcp> cboltz: I know
2020-04-22T17:17:56  <lcp> you didn't close it
2020-04-22T17:18:11  <lcp> the xml is unclosed
2020-04-22T17:18:23  <lcp> or I didn't close it, doesn't matter >:D
2020-04-22T17:20:31  <cboltz> what exactly is missing?
2020-04-22T17:20:47  <lcp> `</xrds:XRDS>` line at the end
2020-04-22T17:22:13  <cboltz> probably my error - I did a copy&paste from what I got from Provo (only added "-new"), and overlooked that line - which was hiding in front of the next prompt (no newline)
2020-04-22T17:22:15  <cboltz> try again
2020-04-22T17:23:22  <lcp> cboltz: even worse, now it's the output of curl -v
2020-04-22T17:24:07  <cboltz> oops ;-)
2020-04-22T17:24:09  <cboltz> try again
2020-04-22T17:24:54  <lcp> yup, works perfectly
2020-04-22T17:25:12  <cboltz> now let me drop the date header again - hardcoding it doesn't make sense ;-)
2020-04-22T17:25:23  <cboltz> and Server: Apache is also wrong
2020-04-22T17:25:55  <cboltz> try again
2020-04-22T17:27:15  <lcp> well, damn, I think we might have undug something by accident
2020-04-22T17:27:41  <lcp> look at this https://www-new.opensuse.org/openid/secureprovider
2020-04-22T17:28:49  <lcp> in any case, redirect back doesn't work since that
2020-04-22T17:28:57  <lcp> 's on www.opensuse.org
2020-04-22T17:29:15  <lcp> I press enter instead of apostrophe way too much
2020-04-22T17:32:43  <lcp> cboltz: one more issue it seems, https://www-new.opensuse.org/openid/provider redirects to http://www-new.opensuse.org/openid/secureprovider and secureprovider as the name implies should have https
2020-04-22T17:33:08  <darix> klein: checked in the pg 11 fix for gitlab
2020-04-22T17:37:19  <lcp> cboltz: I do fear that the fact that that server thinks this is all happening in http is the issue
2020-04-22T17:37:28  <lcp> and I do not know how to even fix that
2020-04-22T17:53:40  <cboltz> yes, that's clearly the problem
2020-04-22T17:54:13  <cboltz> for the redirect back, you could try to override www.o.o in /etc/hosts so that it points to the proxy.o.o IP
2020-04-22T17:54:49  <lcp> right
2020-04-22T18:07:02  <lcp> cboltz: hm, that almost allows me to login
2020-04-22T18:07:12  <lcp> except it dies at the last step
2020-04-22T18:07:32  * lcp uploaded an image: Screenshot from 2020-04-22 20-07-17.png (21KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/wsWZoVLrJtbJXACZDGezmhVr >
2020-04-22T18:09:33  <lcp> I think it's safe to assume this is an error when the servers are communicating with each other, but we are still using the same server, so that doesn't make much sense to me
2020-04-22T18:11:18  <cboltz> right, haproxy is only a proxy adding another step in between and - in theory - shouldn't change anything
2020-04-22T18:11:28  <cboltz> practise obviously disagrees :-/
2020-04-22T18:14:25  <lcp> cboltz: let's maybe not redirect to www-new now? maybe that's an issue
2020-04-22T18:15:27  <cboltz>  /openid/user updated, no  -new  anymore
2020-04-22T18:18:32  <lcp> hm, alright, that's still broken
2020-04-22T18:19:00  <lcp> let's try without the xml then
2020-04-22T18:19:21  <lcp> maybe it has a rule to only have https on www.opensuse.org or something, who knows
2020-04-22T18:19:21  <cboltz> curl -v  -H 'X-Forwarded-For: 192.168.1.1' -H 'HTTPS: on' -H 'X-Forwarded-Ssl: on' -H 'X-Forwarded-Proto: https' -H 'X-Forwarded-Protocol: https'  https://www.opensuse.org/openid/user
2020-04-22T18:19:53  <cboltz> that are the headers added by haproxy, and one of them causes the http
2020-04-22T18:20:08  <lcp> oh, interesting
2020-04-22T18:20:34  <lcp> let's try without xml then, seems promising
2020-04-22T18:22:19  <cboltz> curl -v  -H 'X-Forwarded-Proto: https'  https://www.opensuse.org/openid/user   is enough to trigger http
2020-04-22T18:22:36  <cboltz> and all the others keep https
2020-04-22T18:22:40  <kl_eisbaer> lcp: I'm sorry, but I'm busy with some other work and will not be able to provide you your VMs today. They should be CentOS, right?
2020-04-22T18:23:02  <lcp> fedora, since the python stack on centos is too old
2020-04-22T18:23:31  <lcp> and since the plan is to transition them to leap next year, fedora should be enough for the purpose
2020-04-22T18:26:52  <cboltz> lcp: I adjusted adding the headers to   http-request add-header X-Forwarded-Proto https if is_ssl !is_www
2020-04-22T18:27:02  <cboltz> and disabled the workaround for /openid/user
2020-04-22T18:27:17  <cboltz> we now get https from Provo :-)
2020-04-22T18:27:26  <cboltz> can you test again if that helped?
2020-04-22T18:27:34  <lcp> yup
2020-04-22T18:28:12  <lcp> works!
2020-04-22T18:28:24  <cboltz> :-)
2020-04-22T18:30:34  <cboltz> remaining parts of /openid/user handling dropped from haproxy
2020-04-22T18:30:51  <lcp> you can test yourself: https://www.libravatar.org/openid/login/?openid_identifier=www.opensuse.org/openid/user ;)
2020-04-22T18:31:30  <cboltz> I'll let you do this (probably last) test so that I don't have to override my DNS config for www.o.o ;-)
2020-04-22T18:33:21  <lcp> it works for me
2020-04-22T18:33:46  <cboltz> sounds like the expected result - deleting ununsed config lines shouldn't hurt ;-)
2020-04-22T18:38:00  <kl_eisbaer> lcp: haha - guess what the plan was for the current freeipa.i.o.o ... ? :-)
2020-04-22T18:39:56  <lcp> kl_eisbaer: well, since the freeipa is being now ported to openSUSE, I would assume to move it over to Leap? >:D
2020-04-22T18:40:30  <lcp> joking aside, that's not gonna happen anytime soon, but I hope Leap 16 will allow us to do it
2020-04-22T18:41:14  <lcp> it doesn't really work even on Tumbleweed, gotta submit a lot more stuff
2020-04-22T18:42:24  <lcp> so I assume it was gonna be moved to centos then
2020-04-22T18:42:30  <kl_eisbaer> That's why /me even started to think about ds389 ...
2020-04-22T18:42:55  <kl_eisbaer> I know someone who is currently working on a frontend for it ...
2020-04-22T18:43:15  <lcp> oh yeah, I think I know that person too
2020-04-22T18:43:43  <lcp> I got very affectionate email discouraging from using freeipa from that certain somebody
2020-04-22T18:46:45  -heroes-bot- PROBLEM: Current Load on localhost - CRITICAL - load average: 4.99, 4.79, 4.02 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=localhost&service=Current%20Load
2020-04-22T19:03:00  <cboltz> kl_eisbaer: do you know if www.o.o has any "dirty secrets" besides /openid/ that need a special migration or workaround?