2020-01-07 heroes meeting

[20:00:45] <cboltz> Happy new year and welcome to the heroes meeting ;-)
[20:01:04] <cboltz> We have lots of topics today, see https://progress.opensuse.org/issues/60578
[20:01:21] <cboltz> therefore let's try to handle the first two questions in parallel ;-)
[20:01:28] <cboltz> a) who is here for the meeting?
[20:01:36] <cboltz> b) does someone from the community have a question?
[20:01:47] <kl_eisbaer> a) here! :-)
[20:03:28] <cboltz> I wonder if everybody else is hiding, or if you scared them away with your flood of status reports on the ML ;-)
[20:04:04] <kl_eisbaer> sorry :-/
[20:04:32] <cboltz> well, that's what I'd call a "success problem" ;-) - no need to be sorry!
[20:05:07] <cboltz> we'd have a much shorter TODO list if everybody would have done as much as you did in the last weeks!
[20:05:34] <kl_eisbaer> lol ;-)
[20:06:03] <cboltz> I'd say let's continue with, surprise, status reports - maybe someone else arrives in the meantime
[20:06:09] <cboltz> short report from me:
[20:06:47] <cboltz> I had temporarily routed static.o.o via login2 when we had the strange problems with proxy.o.o in December (see my mail on the ML)
[20:07:03] <lcp_> I'm here, hello
[20:07:14] <cboltz> in the meantime, I switched it back to proxy.o.o (to the main IP as CNAME, not to the separate IP it had before)
[20:07:35] <cboltz> and everything seems to work - so whatever happened in December seems to be fixed
[20:08:15] <cboltz> besides that, I got sidetracked by some interesting 36c3 videos and therefore didn't have much time to work on the infrastructure
[20:08:47] <cboltz> lcp_: I think you could give a quick status report about https://github.com/hellcp/planet-o-o ;-)
[20:09:58] <cboltz> (also a quick question - your planet.ini has "author" as a multi-value field - wouldn't it make sense to spit it into "irc", "username", "member" and "gsoc"?)
[20:10:08] <lcp_> I wish I could
[20:10:37] <lcp_> I would have to ask upstream to change the behaviour, keep in mind all of that is saved to the database before being transformed into posts
[20:11:19] <lcp_> so I just abuse this to make this less of a nightmare to maintain for myself and for upstream >:D
[20:11:45] <cboltz> ok, so you at least have a good reason ;-)
[20:12:28] <kl_eisbaer> did someone already try https://freshrss.org/ ?
[20:12:42] <lcp_> however it is mostly done, I don't think there are any bugs still left there, and it mimicks rss and the general structure of previous planet
[20:14:38] <cboltz> Sounds like we should setup a server with ruby etc. that renders jekyll - IIRC you also worked on moving news.o.o to jekyll, right?
[20:14:59] <lcp_> news-o-o repo is in the openSUSE namespace on github
[20:15:22] <lcp_> although I will have to fix a few things, but it wouldn't hurt to at least host a test version of it
[20:16:11] <lcp_> I might also need to go through very old posts, after that hack back in the days, there are still some spam messages left in some posts
[20:16:30] <cboltz> great :-/
[20:17:01] <lcp_> well, we gotta deal with it, it happened :P
[20:17:29] <cboltz> yeah, but it's still annoying
[20:17:31] <lcp_> kl_eisbaer: I don't really use rss clients, I usually pipe them to other services
[20:18:21] <kl_eisbaer> lcp_: have a look at https://demo.freshrss.org/i/
[20:18:25] <lcp_> I actually also started working on github feeds for purposes of having all the bugs in our namespace in one place, so it's easier to point potential contributors to something fixable
[20:18:46] <lcp_> kl_eisbaer: I did, it looks cool
[20:18:48] <kl_eisbaer> It could be used as successor of planet, if you say the code is rotten old  ;-)
[20:19:24] <lcp_> it's more of a client for a person, than planet tbh
[20:20:04] <lcp_> cboltz: ah, worth noting, thanks to usage of planet pluto, we can parse phoronix for example and display only posts which mention openSUSE
[20:20:18] <kl_eisbaer> At least it allows to have an "anonymous RSS view" - but I like to leave this to those who do the current work ;-)
[20:20:58] <cboltz> well, "anonymous if the post doesn't include pictures etc." ;-)
[20:22:04] <kl_eisbaer> no, pictures are included - just choose the 'Comics' section in the demo for example
[20:22:29] <cboltz> ok, I didn't check this detail ;-)
[20:23:01] <kl_eisbaer> It's just not comparable with the current planet
[20:23:45] <kl_eisbaer> I just kept it in mind when we evaluated possible successors a few years ago. As all the others (planet, venus) were dead already.
[20:24:33] <cboltz> kl_eisbaer: sorry to disappoint you, but I just checked the freshrss demo, and first thing I found is a comic hosted externally ;-)
[20:25:07] <kl_eisbaer> ;-)
[20:25:24] <cboltz> so - should we sum this up to "if someone has time, setting up a VM to host jekyll (for planet.o.o and news.o.o) would be nice"?
[20:25:44] <lcp_> yes
[20:26:07] <kl_eisbaer> lcp_: can you open a ticket for the new VM and assign it to me, please?
[20:26:13] <lcp_> we are ready for 2030 when infra will have to be updated past python2
[20:26:58] <lcp_> kl_eisbaer: sure
[20:27:26] <cboltz> ok, then - any other status reports?
[20:28:23] <cboltz> doesn't look so, next topic then
[20:28:43] <cboltz> given the long list, let's skip "review old tickets" and continue with
[20:28:47] <cboltz>     Internal SSL CA for servers
[20:29:03] <kl_eisbaer> Jip, my topic
[20:29:17] <kl_eisbaer> I hoped that kbabioch would be here..
[20:29:34] <cboltz> I know that we have something[tm] (I'd guess FreeIPA manages its own root CA), but I don't know the details
[20:29:43] <kl_eisbaer> IMHO he already started to package one of the "let's encrypt for local networks" applications
[20:30:14] <kl_eisbaer> If we would stay with FreeIPA, we could create certificates via FreeIPA
[20:30:35] <kl_eisbaer> The only condition would be that the hosts have to be "created" inside the Host tab in FreeIPA
[20:30:58] <cboltz> yeah, _if_ we stay with FreeIPA - that's another open topic, possibly for another day ;-)
[20:31:06] <kl_eisbaer> In that case, FreeIPA would create SSL certificates for the hosts it knows just with hitting a mouse button
[20:31:30] <kl_eisbaer> But as this is on discussion, I thought about possible alternatives...
[20:31:55] <kl_eisbaer> I have my own script to create SSL certificates for clients that use NRPE - but I don't think that this really scales
[20:32:09] <kl_eisbaer> (the script is on the monitor.infra.o.o machine
[20:32:41] <kl_eisbaer> But I think the best might be to wait for Karol - as he already did some analysis of applications in this area.
[20:32:50] <cboltz> right, that might become annoying with increasing number of machines/certs
[20:33:21] <cboltz> however, I wonder if we could use a low-tech solution, like centrally creating the certs and scp'ing to each VM
[20:33:47] <pjessen> that is what we do in my company
[20:34:10] <cboltz> (not that I dislike a fancy internal "let's encrypt openSUSE", but I see more important TODOs than setting this up ;-)
[20:34:25] <kl_eisbaer> Jip. I have something like XCa in mind - but as console application
[20:34:31] <kl_eisbaer> And using Salt to deploy...
[20:34:53] <kl_eisbaer> I just don't remember the name of that beast :-(
[20:36:30] <cboltz> just write a mail when you find/remember it ;-)
[20:36:53] <kl_eisbaer> anyway - if we can agree that a simple commandline tool to manage internal certificates would be ok, I can (re-)start the research
[20:37:14] <pjessen> agree.  simple is better
[20:37:29] <cboltz> I'm a fan of keeping things simple, so please go ahead
[20:37:55] <kl_eisbaer> bmwiedemann1: welcome! Maybe you have an idea: we are searching for a simpple commandline tool to manage SSL certificates (with an own CA for the internal machines)
[20:38:43] <bmwiedemann1> I use openssl , but I found that sometimes certtool is easier to use
[20:39:26] <kl_eisbaer> Is this packaged already?
[20:39:30] <lcp_> that depends if certtool understands your config, but it can be way easier to use
[20:39:41] <bmwiedemann1> yes, in the gnutls package
[20:41:06] <bmwiedemann1> e.g. I used certtool -u for renewals a lot
[20:41:26] <bmwiedemann1> and certtool -i < $crt  for getting text info out
[20:43:11] <kl_eisbaer> HA! I guess, I found it: https://build.opensuse.org/project/show/home:kbabioch:smallstep
[20:43:44] <kl_eisbaer> ^^ "Quickly bootstrap internal PKI: get a public key infrastructure and  certificate authority running in minutes"
[20:44:05] <kl_eisbaer> If nobody objects, I like to give it a try and see how this works for NRPE clients
[20:44:41] <cboltz> no objections
[20:45:18] <cboltz> but note that it partially overlaps with Æ-Dir - for example when it comes to SSH certificates (instead of keys)
[20:45:53] <kl_eisbaer> Well: I'm a fan of KISS - and "one mission, one tool" ;_)
[20:46:04] <cboltz> as I said - no objections ;-)
[20:46:28] <kl_eisbaer> I'll give it a try and if someone wants to volunteer, he's always welcome to take over ;-)
[20:46:42] <cboltz> I "just" have a feeling that it will overlap with other things we have / might have - but testing something never hurts
[20:48:52] <cboltz> next topic?
[20:49:24] <bmwiedemann1> yes
[20:49:41] <cboltz> ok, that is
[20:49:42] <cboltz>     What to do with old FreeIPA accounts (pw expired) 
[20:51:01] <kl_eisbaer> cboltz: If I understand you right, we should send out Emails, if a user is inactive for 6 months (or) more - and disable his account if he agrees or does not respond ?
[20:51:41] <cboltz> yes, I'm afraid that's the only way to go
[20:51:59] <kl_eisbaer> fine with me. Just one question left: how to to wait for an answer, once the Email is send?
[20:52:11] <cboltz> ("password expired" only means someone didn't login in FreeIPA for months - but you can still use the VPN and sudo with an expired password)
[20:52:29] <kl_eisbaer> sure? (mean: did you try?)
[20:52:48] <cboltz> yes, more than once
[20:52:54] <kl_eisbaer> as in that case, I have the feeling that FreeIPA has a security problem :-(
[20:53:04] <cboltz> (especially before you gave me permissions to do DNS changes)
[20:53:26] <cboltz> well, it will force you to set a new password when you login to FreeIPA
[20:53:44] * kbabioch joined the meeting and is sorry for being late ... (listening/reading mode only for now)
[20:53:46] <pjessen> freeipa passwords expire very quickly, don't they?
[20:53:46] <cboltz> but most people don't need to do that...
[20:53:54] <kl_eisbaer> I thought is does this also if you log in to any client?
[20:54:24] <cboltz> no, I'm quite sure that I was able to use sudo with an expired password
[20:54:35] <pjessen> me too
[20:55:13] <kl_eisbaer> crazy - and really not what I would expect!
[20:55:38] <bmwiedemann1> but disabled passwords are not allowed there?
[20:55:43] <cboltz> as a sidenote - I recently heard a nice joke: letting passwords expire means that you have to increase the last digit / "counter" of your password every 3 months ;-)
[20:56:22] <kl_eisbaer> cboltz: that joke is correct - and a reason why expiring passwords is no good practice any more
[20:56:25] <bmwiedemann1> yes. forcing people to change passwords forces them to use weaker passwords
[20:56:43] <kl_eisbaer> but that does not solve the initial question ;-)
[20:56:54] <pjessen> especially these days when everyone has a gazillion passwords
[20:57:09] <kl_eisbaer> so - if I understand correctly: we can not asume that an expired account in FreeIPA is not active any longer
[20:57:33] <cboltz> right
[20:57:36] <kl_eisbaer> which makes it impossible to check who is still active and who is not using his account for decades :-(
[20:58:06] <bmwiedemann1> is there no audit log?
[20:58:11] <cboltz> I'd guess you could grep the VPN logs
[20:58:20] <kl_eisbaer> which - in turn - makes me think about triggering an Email (as we did in the past with the openSUSE members) and checking who answers this Email.
[20:58:35] <cboltz> but sending out a mail is probably easier ;-)
[20:59:05] <cboltz> I'd say allow two weeks to answer, so that we don't lock out someone who is on vacation etc.
[20:59:47] <pjessen> better make it 3 or 4.
[20:59:50] <kl_eisbaer> ok - so I will start with documenting it in our wiki, first - and we can check (and agree on ;-) this docu during the next meeting.
[21:00:04] <kl_eisbaer> once we agreed, we can think about the implementation
[21:00:48] <cboltz> I'd go for a simple solution - send out those mails once per year, and handle the results manually
[21:01:36] * Pharaoh_Atem waves
[21:01:37] <kl_eisbaer> right - that would be my proposal
[21:02:17] <cboltz> :-)
[21:02:39] <kl_eisbaer> ok - I guess we can close this topic here
[21:02:56] <cboltz> right, let's continue with
[21:03:00] <cboltz>      IPv6 renumbering 
[21:03:39] <kl_eisbaer> Oh, what a funny topc...
[21:03:41] <lcp_> oh the nightmares
[21:03:49] <kl_eisbaer> But luckily at the moment it's more "JFYI"
[21:03:54] <cboltz> AFAIK this will "only" affect the external IPs, right?
[21:04:11] <kl_eisbaer> as I hope to get an agreement with the new SUSians to assign an IPv6 subnet directly for opensuse.org machines
[21:04:21] <kl_eisbaer> right: only affecting external machines
[21:04:42] <cboltz> that will make things easier because we only have to touch a few VMs
[21:04:47] <kl_eisbaer> if we could get an own subnet, we might be able to administrate  the reverse entries on our own
[21:05:12] <pjessen> yes, that only requires the proper reverse delegation
[21:05:41] <cboltz> that would make sense - and I'm quite sure there are enough v6 IPs to easily allow this ;-)
[21:05:46] <kl_eisbaer> so - in short: IPv6 renumbering has to be done, but (depending on the conversations) might take a while before we need to start
[21:05:52] <bmwiedemann1> reverse entries mostly matter for mail-servers, no?
[21:06:38] <pjessen> yes, generally speaking only for mail servers.  It's a good practice though.
[21:08:07] <kl_eisbaer> ...and especially for IPv6 aware servers, people also try to do reverse lookups in case of problems (hint: rsync ;-)
[21:09:12] <kl_eisbaer> but I guess we can close this topic as well for now.
[21:09:25] <cboltz> yes, that's the perfect statement to continue with the next topic ;-)
[21:09:28] <cboltz>     Mirror tickets
[21:09:37] <kl_eisbaer> Just in case: if someone would like to start to manage the IPv6 addresses of our servers via Salt, that would be a cool idea already ;-)
[21:09:38] <pjessen> got a few of those
[21:10:03] <kl_eisbaer> Jip - and I did not look into them right now, as I'm currently unsure who is handling them.
[21:10:08] <kl_eisbaer> Only you, Per?
[21:10:18] <pjessen> afaik, only me.
[21:10:42] <pjessen> of course anyone is free to help out :-)
[21:10:52] <kl_eisbaer> I feared that you say this :-)
[21:11:10] <kl_eisbaer> Is there anything which is currently more urgent ?
[21:11:56] <pjessen> I would have to look at the list, but I try to deal with the important ones first
[21:12:53] * klein here now, sorry, missed the time
[21:12:56] <pjessen> right now, I don't believfe there is anything urgent.
[21:13:01] <cboltz> we got two tickets about problems with the mozilla repo today (last one is ~3 hours old)
[21:13:19] <cboltz> but I'd guess that's more a problem between OBS and download.o.o, not with the mirrors
[21:13:38] <pjessen> pontifex has been VERY busy, pushing repos has been taking hours
[21:14:46] <pjessen> one important issue - tumbleweed mirroring / scanning
[21:14:56] <kl_eisbaer> btw. who has currently access to widehat?
[21:15:16] <kl_eisbaer> looks like widehat misses a rsync module that OBS is normally using to push  repos to widehat
[21:15:36] <pjessen> I think there might even be an open issue on that
[21:15:50] <cboltz> AFAIK kbabioch and klein have access
[21:16:02] <klein> yes, what do you need me to check?
[21:16:31] <kl_eisbaer> We need to check for a specific rsync module, that seems to be missing
[21:16:55] <bmwiedemann1> btw: there will be a new widehat machine with 86 TB (raw) disks as replacement
[21:17:02] <kl_eisbaer> klein: if you don't mind, I will open a ticket and assign it to you
[21:17:09] <bmwiedemann1> our SAP process started today
[21:17:15] <kl_eisbaer> woho! :-)
[21:17:18] <cboltz> :-)
[21:17:41] <pjessen> wow
[21:18:05] <klein> kl_eisbaer: on RT or on progress? And, please teach me how to check that :-)
[21:18:12] <bmwiedemann1> after RAID6 it will be only around 60TB, but that should suffice for a while
[21:18:26] <kl_eisbaer> klein: don't worry, I will visit you in your office, once i created it ;-)
[21:18:56] <kl_eisbaer> bmwiedemann1: really RAID6 and not RAID10 ? (just to start the usual RAID performance discussion ;-)
[21:19:21] <klein> ok, I have a "package" from Martin to you, in my desk :-).... ahh, Martin is also here tomorrow
[21:20:13] <kl_eisbaer> hey :-) good to know :-)
[21:20:21] <kl_eisbaer> but we are drifting away...
[21:20:40] <kl_eisbaer> My main intention at the moment is to reduce the number of open tickets
[21:21:06] <kl_eisbaer> especially the really old ones are currently on my radar.
[21:21:29] <pjessen> with mirrors, people can be very slow in responding to feedback requests
[21:21:29] <klein> ok, I can help with that
[21:21:45] <kl_eisbaer> Most of them are IMHO open because nobody wants to make a decision or tell the other side that we are so low on manpower that we can not help.
[21:22:26] <kl_eisbaer> pjessen: this is why I left those out at the moment: I have no idea how you handle this at the moment...
[21:23:40] <pjessen> kl_eisbaer: one at a time :-)
[21:23:50] <kl_eisbaer> shouldn't we define a timeout somehow, so we don't carry too much old tickets with us?
[21:23:58] <pjessen> and by using due dates.
[21:24:16] <kl_eisbaer> so we - for example - close a "feedback" ticket after 4 weeks of no reaction ?
[21:25:11] <klein> I agree on that, if no one cares to give feedback, its because its OK or doesn't really matter anymore
[21:25:43] <cboltz> ... and if someone answers by mail, the ticket will be reopened anyway
[21:25:57] <kl_eisbaer> jip, this is exactly my thinking as well ;-)
[21:26:25] <kl_eisbaer> pjessen: would that work out for you as well ?
[21:26:45] <kl_eisbaer> as this would allow anyone to close open tickets with state "feedback" after 4 weeks
[21:27:06] <pjessen> yes and no.  I would prefer tickets that are asigned to me to remain under my control. I agree with closing tickets waiting too long for feedback though.
[21:27:11] <kl_eisbaer> once we have the new redmine up and running, we might even do this via cron job ;-)
[21:27:49] <kl_eisbaer> pjessen: what about not only assigning the ticket to you in that case, but also NOT setting them to feedback ?
[21:28:18] <klein> I think the owner of the ticket is the one that should close it
[21:28:24] <kl_eisbaer> that would make everyones live a bit easier, as we can start cleaning up automatically
[21:28:49] <pjessen> kl_eisbaer: oh that would help a lot :-)   I usually set feedback status when I hope to have contact with the reporter.
[21:29:01] <kl_eisbaer> klein: yeah - but sometimes the ticket is magically (;-) assigned to someone
[21:29:05] <pjessen> klein: agree
[21:29:21] <klein> kl_eisbaer: hummmm
[21:29:29] <kl_eisbaer> and sometimes the assignee is also not really active any longer
[21:29:57] <klein> ok, for not active assignees, we need to have a special rule?
[21:30:19] <kl_eisbaer> I'm just thinking about some "automatism", that would allow us to get rid of some tickets were we clearly wait for reporter feedback
[21:30:32] <klein> or.. just do it in an automatic way, if the ticket is on feedback for 5 weeks, the ticket tool should close it
[21:30:41] <kl_eisbaer> klein: yes, exactly
[21:31:03] <klein> like, send an e-mail to the reporter and also to the assignee just to make everyone aware, and close it
[21:31:06] <klein> I like that...
[21:31:07] <kl_eisbaer> klein: the ticket will be closed - and if a reporter decides suddently to answer after that - the ticket will get re-opened anyway
[21:31:27] <pjessen> if we time out waiting for feedback, maybe automagically add a comment and return to previous status? I don't like have tickets closed for me.
[21:31:31] <klein> works for me... let's make the machines work for us, not the oppose
[21:32:19] <kl_eisbaer> pjessen: that would mean that we need to add a hack in the script "if assignee is pjessen ..." - but I think this might work
[21:32:51] <klein> I know someone very skilled in Perl that can do that hahahaha
[21:33:08] * kl_eisbaer notes that klein volunteers :-)
[21:33:22] <pjessen> isn't it too much effort for very little gain?
[21:33:47] <pjessen> is anyone monitoring the ticket queue ?  (runs for cover).
[21:33:56] <kl_eisbaer> pjessen: well, it gives the thing a rule.
[21:34:09] <kl_eisbaer> pjessen: the ticket queue is monitored ;-)
[21:34:10] <klein> kl_eisbaer: I am not touching Perl... you are the Perl master haha
[21:34:29] <bmwiedemann1> I also like perl
[21:34:30] <cboltz> who says it has to be perl?
[21:34:30] <kl_eisbaer> klein: you mixed something up  ;-)
[21:34:48] <kl_eisbaer> pjessen: https://monitor.opensuse.org/pnp4nagios/index.php/graph?host=redmine.infra.opensuse.org&srv=_HOST_
[21:34:54] <cboltz> oh, bmwiedemann1 just volunteered ;-)
[21:35:10] <kl_eisbaer> pjessen: oh, sorry, I mean: https://monitor.opensuse.org/pnp4nagios/graph?host=redmine.infra.opensuse.org&srv=Heroes_tickets
[21:35:25] <bmwiedemann1> haha
[21:35:48] <kl_eisbaer> pjessen: especially this one here is interesting: https://monitor.opensuse.org/pnp4nagios/graph?host=redmine.infra.opensuse.org&srv=Heroes_tickets&view=4
[21:35:58] <pjessen> kl_eisbaer: nice one
[21:36:07] <kl_eisbaer> currently the curve is going down - and I like to keep it going this way ;-)
[21:37:35] <kl_eisbaer> and one easy win would be to define a time frame when we close "feedback" tickets - if the reporter seems not to be interested to give feedback
[21:38:42] <pjessen> yeah. I can't really disagree with that, but I'm not in favour.
[21:39:07] <kl_eisbaer> that's why I'm saying: ok, let's make an exception for pjessen tickets ;-)
[21:39:31] <pjessen> hahaha, the personal touch :-)
[21:39:33] <kl_eisbaer> it's not hard to get - just helps others to reduce their workload
[21:39:59] <kl_eisbaer> I'm fine if you need those mountains of tickets in front of you (harrharr ;-)
[21:40:10] <pjessen> okay, count me in (don't count my tickets).
[21:40:19] <kl_eisbaer> perfect, thanks!
[21:40:23] <kl_eisbaer> ...over to cboltz
[21:40:37] <kl_eisbaer> ...who should announce the next topic ;-)
[21:40:55] <cboltz> well, besides the old tickets (which we skipped) there's one topic left:
[21:40:58] <cboltz>     GDPR -> Saltify account removal 
[21:41:37] <cboltz> I have a feeling that we should first define the first step (what do do/remove/...) before working on the second (automating it) ;-)
[21:41:47] <kl_eisbaer> Yes, of course.
[21:41:52] <cboltz> but in general, having a GDPR workflow makes sense
[21:42:01] <kl_eisbaer> I just wanted to make everyone aware of this...
[21:42:34] <kl_eisbaer> IMHO we should think about a way to remove an account from any of our current tools/services via commandline
[21:42:45] <kl_eisbaer> this could be a script that does some API calls
[21:42:54] <kl_eisbaer> or editing a database
[21:43:18] <cboltz> yes, that's the second step ;-)
[21:43:31] <cboltz> first step is: what should we delete?
[21:43:52] <kl_eisbaer> cboltz: IMHO this depends on the tool in question, right?
[21:43:57] * klein was just kidding about perl, sorry
[21:44:06] <cboltz> exactly, and that's where things can become interesting
[21:44:12] <cboltz> for example - what about wiki edits?
[21:44:26] <pjessen> and mailing list archives.
[21:44:32] <kl_eisbaer> for progress.o.o for example, deleting a user results in any old ticket or edit of this user get's assigned to "anonymous", which is ok
[21:45:02] <kl_eisbaer> for wiki, we might copy the behavior of wikipedia ?
[21:45:23] <cboltz> right, that makes progress.o.o a somewhat easy case - but the realname might still be mentioned in the mail/ticket content
[21:45:24] <kl_eisbaer> for lists or forums, we need to check what other distributions or provider of such things are doing to get an idea
[21:46:16] <kl_eisbaer> cboltz: you are right - and we will easily find 100 other problematic places, once we start to think about it
[21:46:51] <kl_eisbaer> the problem I see: at the moment we did not even start to think about it, while the law is already in place since years ...
[21:47:03] <cboltz> right
[21:47:12] <kl_eisbaer> ...and we already get requests from users to get deleted
[21:47:38] <kl_eisbaer> so I like to bring this up, so every admin of a service starts to think about a way how he can implement this
[21:47:41] <pjessen> regularly.
[21:48:03] <pjessen> we will need to know the requirements.
[21:48:04] <kl_eisbaer> and to give him some guidelines, my thinking is to give some easy starting point
[21:48:32] <kl_eisbaer> while knowing that the easy starting point will not be (and probably never every will be) the final solution
[21:48:59] <Pharaoh_Atem> kl_eisbaer: what other distors are doing for what?
[21:49:05] <Pharaoh_Atem> *distros
[21:49:08] <kl_eisbaer> so my requirement would be to have a commandline tool that can be invoked with a login name (from Bugzilla)
[21:49:56] <kl_eisbaer> and that tool should try it's best to delete the aligned content for this login from the system
[21:50:06] <cboltz> Pharaoh_Atem: GDPR requests like "please delete my account and all my data"
[21:50:29] <kl_eisbaer> I know that the first incarnations of those tools might not be 100% perfect.
[21:50:39] <pjessen> I think the key question will be - what is the aligned cntent?
[21:50:53] <kl_eisbaer> But this would be my starting point, which would allow us to automate the mess
[21:51:00] <lcp_> fedora has a slightly easier job, considering they "own" all of their infra
[21:51:20] <kl_eisbaer> pjessen: ...and this content - from my point of view - depends on the services in question
[21:52:13] <pjessen> kl_eisbaer: I don't really have a point of view, it's much to legalese for me.
[21:52:37] <Pharaoh_Atem> cboltz: I think the CPE team for fedora/centos started working on this too, it might be worth asking them what they're doing
[21:52:56] <kl_eisbaer> so for lists we might end up saying that your script needs to find out an Email address for a login and either delete any mail sent from this address or overwrite this Email everywhere with XXXXX
[21:53:05] <lcp_> eh, if we had an account system, this could be integrated into it possibly
[21:53:22] <Pharaoh_Atem> lcp_: I have a suspicion that fedora's stuff is handled as part of FAS data
[21:53:38] <kl_eisbaer> lcp_: Sorry, but I don't really think so. The account system would probably not delete the data of an account
[21:53:59] <lcp_> I don't see why not, fedora accounts system is in-house
[21:54:10] <lcp_> they can do whatever they please with it
[21:54:25] <kl_eisbaer> lcp_: ...and fedora started to write ansible playbooks for their GDPR stuff....
[21:54:57] <kl_eisbaer> https://github.com/dustymabe/fedora-infra-ansible/blob/master/playbooks/manual/gdpr/delete.yml
[21:54:59] <lcp_> good to know
[21:55:22] <kl_eisbaer> I think we should do something simliar
[21:55:35] <Pharaoh_Atem> that would make sense
[21:56:17] <kl_eisbaer> but as I said: before we can start to think about integrating it into Salt, we need to think about each and every service how this could be done there
[21:56:57] <kl_eisbaer> Example: etherpad.o.o - should we grep through all existing pads and delete pads that have the name of the user in them ?
[21:57:25] <kl_eisbaer> ...starting with these kind of thinkings is IMHO the way we need to start.
[21:58:07] <bmwiedemann1> kl_eisbaer: and then someone names his account "and" or "you"
[21:58:08] <kl_eisbaer> and - at least for me - it helps to have in mind that we need to automate  this to get it in a managable state
[21:58:35] <kl_eisbaer> bmwiedemann1: I already have "drop tables;" ;-)
[21:59:11] <lcp_> I think etherpad pads should be a subject of removal on request, there is no real way to automate this
[21:59:19] <kl_eisbaer> so - back to cboltz suggestion: yes, we might start with some wiki (?)  pages for each application to think about what can be done and what not
[21:59:32] <bmwiedemann1> lcp_: riseup has configurable auto-expiry for etherpads
[21:59:50] <kl_eisbaer> for example: in bugzilla it might be enough (as in progress) to delete the account in the applications database
[22:01:04] <cboltz> agreed, a page in the admin wiki makes sense - and when we know what to do and how (and maybe asked SUSE Legal for some confirmation and clarification), we can start to automate it
[22:01:08] <kl_eisbaer> if a user still complains that his account is mentioned "somewhere" inside the application, we need to check if this is a one time effort - or can also be automized - or if it is a legitimate question at all
[22:01:29] <kl_eisbaer> ok
[22:02:01] <lcp_> bmwiedemann1: that doesn't seem like a bad idea tbh
[22:02:02] <kl_eisbaer> So I like to ask every "service admin" to start such a wiki page below the GDPR page in the admin wiki
[22:03:27] <robin_listas> kl_eisbaer:   <https://connect.opensuse.org>  "antispam admin" here. Do I have to do something?
[22:04:21] <kl_eisbaer> robin_listas: yes: check what happens / needs to be done if a user wants to get deleted from connect.
[22:04:54] * bmwiedemann1 goes to sleep. have a lot of phun
[22:05:12] <kl_eisbaer> bmwiedemann1: good night!
[22:05:15] <cboltz> I'd guess: just delete the user, like a spammer ;-)
[22:07:40] <robin_listas> When I delete a user, it is also deleted from the entire opensuse login system, so it has repercussions. The action is not limited to connect alone. If I have to delete content, I do not know how to search for it unless it is recent. All actions would be manual, on the admin interface, I do not have the knowledge to really go inside whatever handles connect.
[22:08:03] <robin_listas> Just saying :-)
[22:08:21] <kl_eisbaer> robin_listas: the user data for connect lives in a database.
[22:08:21] <pjessen> Yeah, gotta go - I think we are done anyway?  Happy New Year everyone!
[22:08:44] <kl_eisbaer> robin_listas: so if you delete a user in connect, the user's data on all other systems (like OBS, lists.o.o) will still be there.
[22:08:51] <robin_listas> (we do not delete spammers, we "bann" them. A deleted user comes back)
[22:09:00] <cboltz> robin_listas: I'm quite sure you overestimate your powers - you only delete users on connect.o.o, but _not_ on the other systems or in the login system
[22:09:41] <kl_eisbaer> robin_listas: that's why I'm asking you (and every other "service/application" admin) to think about a way to request the user deletion from a commandline client
[22:09:46] <robin_listas> I would hope so, but I think it is deleted on the login system opensuse wide
[22:10:03] <kl_eisbaer> robin_listas: sorry to say, but it's not.
[22:10:25] <robin_listas> Ok, I'll write what I know and my concerns to the wiki.
[22:10:45] <kl_eisbaer> The problem is indeed: if MF-IT (who are the current owners of the login system) delete a user there, the data of the user is still in connect
[22:10:49] <robin_listas> Ok, then I was told wrong. Easier to delete users.
[22:11:52] <kl_eisbaer> robin_listas: and this is indeed a problem, as it means that MF-IT "think" they deleted everything of a user by removing his account - but indeed the user data may be split accross multiple applications inside the openSUSE eco system
[22:12:06] <robin_listas> Ah
[22:14:19] <kl_eisbaer> so, yes: if you delete a user in connect, the users data might get deleted - but ONLY in connect and nowhere else.
[22:14:25] <kl_eisbaer> ...and this is the problem...
[22:14:56] <robin_listas> So you want a series of scripts to trigger in cascade to delete it all.
[22:14:58] <kl_eisbaer> So the idea is to have a "trigger" - that get's triggered once an account get's deleted from the login system
[22:15:23] <robin_listas> Then sorry, I don't have the access nor the knowledge to do that in connect.
[22:15:42] <kl_eisbaer> ...and this trigger will call a script on each service with some user information (like login or name) - and the application should delete the users data
[22:16:22] <kl_eisbaer> robin_listas: no worries. We will find someone who should be able to do this (or we shut down connect? ;-)
[22:16:37] <robin_listas> I would suggest to delete the content only if the user requests that deletion. Not every user deletion should mean delete their content.
[22:16:48] <kl_eisbaer> robin_listas: but it would be very helpful, if you could add connect to the wiki page, so we do not forget it...
[22:16:49] <robin_listas> Sure, shut down connect :-D
[22:17:01] <robin_listas> Oops. URL?
[22:18:34] <kl_eisbaer> https://progress.opensuse.org/projects/opensuse-admin-wiki/wiki/Connect?parent=GDPR
[22:19:36] <robin_listas> Oops-2: I get 403, not authorized.
[22:19:47] <kl_eisbaer> are you logged in?
[22:20:08] <robin_listas> Yes, to bugzilla, connect... It shows my name
[22:20:17] <kl_eisbaer> wait a second, please
[22:21:13] <kl_eisbaer> robin_listas: can you try to reload, please
[22:22:12] <robin_listas> Yes, now it loads an empty page with "connect ====" on it :-) Thanks.
[22:22:24] <robin_listas> And an edit box.
[22:22:37] <kl_eisbaer> perfect! :-)
[22:23:15] <kl_eisbaer> I leave the rest up to you - just add some generic words about the service (including the URL) and your thinking of how users might get deleted for GDPR
[22:23:33] <kl_eisbaer> if this means "clicking on delete" - that should be ok
[22:23:41] <robin_listas> Sure. No problem. Not tonight, though :_)
[22:23:49] <kl_eisbaer> thanks
[22:25:46] <kl_eisbaer> cboltz: still awake ?
[22:25:57] <cboltz> yes, but at the moment I'm in two meetings in parallel ;-)
[22:26:16] <kl_eisbaer> oh, sorry. I just want to hand over to you, as I think the GDPR topic is done :-)
[22:27:15] <cboltz> ok ;-)
[22:27:39] <cboltz> GDPR was the last topic, so - does someone have another topic, or can I stop multitasking? ;-)
[22:27:49] <Pharaoh_Atem> cboltz: freeipa upgrade?
[22:28:27] <Pharaoh_Atem> also, in case anyone wasn't aware of this, Fedora has started developing a plugin for FreeIPA to implement aspects of the Fedora Account System directly on FreeIPA: https://github.com/fedora-infra/freeipa-fas
[22:28:27] <cboltz> if you have something about that, go ahead
[22:29:27] <Pharaoh_Atem> cboltz: well, I don't know how I can help, since I'm not sure the state of the machine and how it's setup
[22:29:39] <Pharaoh_Atem> and how to setup a clone to test doing upgrades
[22:30:10] <cboltz> first step is to request a heroes VPN account ;-)
[22:30:16] <Pharaoh_Atem> how do? :D
[22:30:22] <lcp_> Pharaoh_Atem: from our pov, we would need a little bit different set of attributes
[22:30:51] <Pharaoh_Atem> lcp_: could you codify this into an issue filed against it?
[22:30:51] <cboltz> send a mail to admin@o.o with your GPG key (or key id, if it's on the keyservers)
[22:31:00] <Pharaoh_Atem> oh boy, GPG :D
[22:31:40] <lcp_> Pharaoh_Atem: I'm curious why it's specifically RHBZEmail instead of BZEmail, that would make changing this easier
[22:31:57] <Pharaoh_Atem> lcp_: it probably could be BZEmail, most likely it was due to not thinking about it much
[22:32:38] <Pharaoh_Atem> "rhbz" shows up in a lot of things that actually is generic to all bz systems
[22:32:40] <Pharaoh_Atem> especially since bz5
[22:33:10] <lcp_> we would also need member status tbh, but that's secondary probably
[22:33:40] <lcp_> it would be a nice system to use probably, considering that we would have all of that data in account system without connect connected :P
[22:33:43] <Pharaoh_Atem> member status would likely be an IPA group
[22:33:54] <lcp_> alright, then I don't have any more objections
[22:34:06] <Pharaoh_Atem> similar to how various memberships work in Fedora
[22:34:14] <lcp_> I figured
[22:41:58] <Pharaoh_Atem> cboltz: what's the GPG for? encrypting credentials?
[22:42:21] <cboltz> we want a save way to send you the VPN cert and the initial password
[22:43:29] <lcp_> keep in mind it shouldn't be sha-1 encryped, that was broken today
[22:43:40] <lcp_> https://sha-mbles.github.io/
[22:44:14] <lcp_> gnupg still accepted sha-1