openSUSE admin

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