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