Hi,
Am Do., 21. Feb. 2019 um 15:32 Uhr schrieb Lars Vogdt Lars.Vogdt@suse.com: As such, maintaining 447 [1] openSUSE members should not depend on a single tool. Especially not if the used tool has open, well known security issues since years[2].
On Thu, 21 Feb 2019 11:41:19 +0100 Richard Brown wrote:
This isn't the first time I've asked this question on a public stage, but in the hope that this time I get an answer; Who volunteers to tackle the problem with connect.o.o and drive forward a solution?
I made my proposal already and I stand the point: shut down an insecure system!
what does "drive forward a solution" mean? Can we integrate the functions of connect.o.o into other services at openSUSE which are allready maintained like the openSUSE wiki? A form for travel support for example?
An application for membership could be done by e-mail to an e-mail address of the membership officials. Elections could be done with an eVote software like https://github.com/mdipierro/evote for example, but probably there are better tools.
What did I miss?
I think Lars is right an we should shutdown this insecure system as soon as possible.
Regards Christian Imhorst
On Thu, 21 Feb 2019 at 16:21, christian.imhorst@posteo.de wrote:
what does "drive forward a solution" mean? Can we integrate the functions of connect.o.o into other services at openSUSE which are allready maintained like the openSUSE wiki? A form for travel support for example?
Suggestions like that all sound technically viable, so in a technical sense 'drive forward a solution' means picking, and doing, good engineering stuff like that
But the problem isn't just one that exists in the technical sphere. There are a number of stakeholders that will be impacted by any change in this area
This will affect how Membership works and their membership data is stored, so the Membership of the project have to be on board, either informally via discussions on this list, or formally in the term of votes of any changes to their membership database. We can't have a functioning Membership scheme if the Members dont like how their data is being stored (and I agree with the sentiment that our Members shouldn't like the Status quo..but..also I cant argue with the fact that our Members collectively haven't been as motivated to address this as they appear to be right now..)
This will affect how Membership is approved. This means the Membership committee need to be spoken to, they need to agree to work with any new technical solution. We can't have a functioning Membership scheme without their approval.
This will involve infrastructure, either the decommissioning or commissioning of new stuff. That means the openSUSE Heroes need to be involved. No point trying to fix this without them.
So, "driving this forward" means doing the technical stuff, and the human stuff, talking to the right people, getting them on board, encouraging them to contribute to a solution.
If we all agree that this is a problem that needs to be fixed, then lets get started and help fix it - This isn't somebody elses job, it impacts all of us, we all should be doing something to help.
On 2/21/19 9:42 AM, Richard Brown wrote:
On Thu, 21 Feb 2019 at 16:21, christian.imhorst@posteo.de wrote:
functioning Membership scheme if the Members dont like how their data is being stored (and I agree with the sentiment that our Members shouldn't like the Status quo..but..also I cant argue with the fact that our Members collectively haven't been as motivated to address this as they appear to be right now..)
"appear to be" is a good way to put it.
Despite so many posts from so many "concerned" openSUSE-ers, I still really do not see an "I'll Do It!", do you?
On 21/02/2019 21.57, Fraser_Bell wrote:
On 2/21/19 9:42 AM, Richard Brown wrote:
On Thu, 21 Feb 2019 at 16:21, christian.imhorst@posteo.de wrote:
functioning Membership scheme if the Members dont like how their data is being stored (and I agree with the sentiment that our Members shouldn't like the Status quo..but..also I cant argue with the fact that our Members collectively haven't been as motivated to address this as they appear to be right now..)
"appear to be" is a good way to put it.
Despite so many posts from so many "concerned" openSUSE-ers, I still really do not see an "I'll Do It!", do you?
No? :-o
Op donderdag 21 februari 2019 21:57:06 CET schreef Fraser_Bell:
On 2/21/19 9:42 AM, Richard Brown wrote:
On Thu, 21 Feb 2019 at 16:21, christian.imhorst@posteo.de wrote:
functioning Membership scheme if the Members dont like how their data is being stored (and I agree with the sentiment that our Members shouldn't like the Status quo..but..also I cant argue with the fact that our Members collectively haven't been as motivated to address this as they appear to be right now..)
"appear to be" is a good way to put it.
Despite so many posts from so many "concerned" openSUSE-ers, I still really do not see an "I'll Do It!", do you?
Even a 'hey, who could help me do it?" would do.
Le 21/02/2019 à 23:28, Knurpht-openSUSE a écrit :
Even a 'hey, who could help me do it?" would do.
I use a free galette instance we could certainly use also. It keeps membership, allow each member to edit his data...
my lug one
it's more than able to cope with 400 members
http://galette.eu/dc/?navlang=en
when I managed my own server, I couldn't make it work with openSUSE, but I'm pretty sure heroes could do eventually
jdd
On 22/02/2019 01:51, christian.imhorst@posteo.de wrote:
Hi,
Am Do., 21. Feb. 2019 um 15:32 Uhr schrieb Lars Vogdt Lars.Vogdt@suse.com: As such, maintaining 447 [1] openSUSE members should not depend on a single tool. Especially not if the used tool has open, well known security issues since years[2].
On Thu, 21 Feb 2019 11:41:19 +0100 Richard Brown wrote:
This isn't the first time I've asked this question on a public stage, but in the hope that this time I get an answer; Who volunteers to tackle the problem with connect.o.o and drive forward a solution?
I made my proposal already and I stand the point: shut down an insecure system!
what does "drive forward a solution" mean? Can we integrate the functions of connect.o.o into other services at openSUSE which are allready maintained like the openSUSE wiki? A form for travel support for example?
An application for membership could be done by e-mail to an e-mail address of the membership officials. Elections could be done with an eVote software like https://github.com/mdipierro/evote for example, but probably there are better tools.
What did I miss?
The hard part, Storing members personal information in a secure way such that the people who need to be able to access it can access it and everyone else can not.
Am Donnerstag, 21. Februar 2019, 22:09:27 CET schrieb Simon Lees:
The hard part, Storing members personal information in a secure way such that the people who need to be able to access it can access it and everyone else can not.
Came up twice already: take a Nextcloud, drop an LibreOffice Calc document there. It's not the shiny knight on a white horse solution but it should be enough to a) keep the membership committee working b) store the member's data safe c) get rid of this ugly spam dump called connect.o.o
Regards, vinz.
On 22/02/2019 07:52, Vinzenz Vietzke wrote:
Am Donnerstag, 21. Februar 2019, 22:09:27 CET schrieb Simon Lees:
The hard part, Storing members personal information in a secure way such that the people who need to be able to access it can access it and everyone else can not.
Came up twice already: take a Nextcloud, drop an LibreOffice Calc document there. It's not the shiny knight on a white horse solution but it should be enough to a) keep the membership committee working b) store the member's data safe c) get rid of this ugly spam dump called connect.o.o
Yes this discussion has got somewhere further then last time which leaves us with the remaining questions.
Where should we install nextcloud? Who would like to install it and keep it running?
Le 22/02/2019 à 01:01, Simon Lees a écrit :
Where should we install nextcloud? Who would like to install it and keep it running?
and why is a *cloud* storage needed to manage membership?
jdd
jdd@dodin.org wrote:
Le 22/02/2019 à 01:01, Simon Lees a écrit :
Where should we install nextcloud? Who would like to install it and keep it running?
and why is a *cloud* storage needed to manage membership?
To make it more easily accessible to those who have a need to access it.
It could also just be stored on an ftp server, but using a nextcloud instance does make it easier to share.
Simon asked:
- Where should we install nextcloud?
It only needs a fixed ip, apache, php and a database. If we don't have a webserver with those, I'm sure we can get one.
Who would like to install it and keep it running?
Show of hands please.
On Fri, Feb 22, 2019 at 3:28 PM Per Jessen per@computer.org wrote:
Simon asked:
- Where should we install nextcloud?
It only needs a fixed ip, apache, php and a database. If we don't have a webserver with those, I'm sure we can get one.
Who would like to install it and keep it running?
Show of hands please.
-- Per Jessen, Zürich (7.6°C)
Hi,
If you give me an access, I will volunteer for this.
-- Edwin
Le 22/02/2019 à 09:26, Per Jessen a écrit :
Who would like to install it and keep it running?
Show of hands please.
offers a service with 1Gb free
and
https://cloud.zaclys.com/Le-cloud-a-quoi-ca-sert-exemple-dutilisation-du-ser...
this I could manage for openSUSE if necessary. it's even encrypted if you want to
you may think it's a provocation, and it is... why is it so hard to share such service on openSUSE? I managed one myself for years..
jdd
jdd@dodin.org wrote:
Le 22/02/2019 à 09:26, Per Jessen a écrit :
Who would like to install it and keep it running?
Show of hands please.
offers a service with 1Gb free and https://cloud.zaclys.com/Le-cloud-a-quoi-ca-sert-exemple-dutilisation-du-ser...
this I could manage for openSUSE if necessary. it's even encrypted if you want to
you may think it's a provocation, and it is... why is it so hard to share such service on openSUSE? I managed one myself for years..
I'm sure it isn't hard nor difficult. My company also provide cloud storage, but for openSUSE we already have our own hardware in a secure location, with physical access. Creating a new vm instance and asking someone to run a nextcloud instance is no big deal, we only need to make sure it is the right solution.
Am Freitag, 22. Februar 2019, 11:59:00 CET schrieb Per Jessen:
I'm sure it isn't hard nor difficult. My company also provide cloud storage, but for openSUSE we already have our own hardware in a secure location, with physical access. Creating a new vm instance and asking someone to run a nextcloud instance is no big deal, we only need to make sure it is the right solution.
Yeah, I would object to kill some service by adding just another one outside of openSUSE's infrastructure.
So as an alternative to some Nextcloud why not just go with a private section of Bugzilla? That should handle the whole process of application, decision and documentation all in one. Plus it's already there and maintained.
Regards, vinz.
Vinzenz Vietzke wrote:
Am Freitag, 22. Februar 2019, 11:59:00 CET schrieb Per Jessen:
I'm sure it isn't hard nor difficult. My company also provide cloud storage, but for openSUSE we already have our own hardware in a secure location, with physical access. Creating a new vm instance and asking someone to run a nextcloud instance is no big deal, we only need to make sure it is the right solution.
Yeah, I would object to kill some service by adding just another one outside of openSUSE's infrastructure.
So as an alternative to some Nextcloud why not just go with a private section of Bugzilla? That should handle the whole process of application, decision and documentation all in one. Plus it's already there and maintained.
It might be an option, but bugzilla is currently run by SUSE IT, not openSUSE.
Hi all,
I have the same question like Carlos: I would volunteer but I don't now what to do. I have no experience with Elgg and don't know how to maintain a forum.
Carlos E. R. wrote:
If I were to volunteer for that, what would I need to do? It seems to me that it is another forum. I know nothing of maintaining a forum in order to reduce spam, so all I can think of is manually deleting posts and killing those posters,
Regards Christian Imhorst
Hi folks,
On 2/22/19 1:22 AM, Vinzenz Vietzke wrote:
Came up twice already: take a Nextcloud, drop an LibreOffice Calc document there. It's not the shiny knight on a white horse solution but it should be enough to a) keep the membership committee working b) store the member's data safe c) get rid of this ugly spam dump called connect.o.o
Agreed. We start simple.
I volunteer for this. Will check Heroes where I can set this up.
Regards,
Ish Sookun
Hello,
[ I have about 50 unread mails in this discussion, so I might not have seen all relevant comment yet. One thing I noticed is that we have several volunteers. I'm really happy about that :-) Please forgive me for answering only to one of you ;-) ]
Am Freitag, 22. Februar 2019, 08:47:36 CET schrieb Ish Sookun:
On 2/22/19 1:22 AM, Vinzenz Vietzke wrote:
Came up twice already: take a Nextcloud, drop an LibreOffice Calc document there. It's not the shiny knight on a white horse solution but it should be enough to a) keep the membership committee working b) store the member's data safe c) get rid of this ugly spam dump called connect.o.o
Agreed. We start simple.
In a mail nearby, jdd asked the right question:
and why is a *cloud* storage needed to manage membership?
Using nextcloud with a LibreOffice Calc document in it would be a bad idea IMHO. Not because my personal preference is ownCloud ;-) but because it makes things more complicated than necessary. For example, extracting the mail aliases out of a LibreOffice table would be a PITA, or in general, automating anything would be a PITA.
So let's start even more simple and less cloudy, please ;-)
If we go for "a table that can only be edited by the membership committee", then I'd propose to use a MySQL database + phpMyAdmin
The interface would look a bit more "technical", but not too different/ difficult, and it would have several advantages: - extracting the mail aliases out of a database is boring and easy (much easier than extracting them from a binary[1] LibreOffice file) - setting up the server is easy - we could easily track changes, for example with a daily CSV export that gets auto-commited to a git repo (not a requirement for the initial implementation, just an idea for the future) - if we setup a "request membership" form, writing to a database is much easier than writing to a LibreOffice document
The hard part is to convert the data from connect.o.o to the new database scheme. (I never looked at the database scheme used by connect.o.o, therefore I have no idea how hard this will be.)
Writing/updating the export scripts (for example for the mail aliases) is also some work, but not really hard.
I volunteer for this. Will check Heroes where I can set this up.
I'm happy to hear that :-)
Getting a VM (IMHO: for phpMyAdmin and an empty database) shouldn't be too hard ;-) Please write a mail to the heroes mailinglist to request it, and while on it, please also request access to the VPN and the connect.o.o database.
Until that setup is done, you can already start on the drawing board with stuff like "which columns will we need?" I know it sounds boring, but I'm also sure nobody will get this right on the first attemp ;-) On the positive side, adding a column later is easy, so don't worry too much.
Regards,
Christian Boltz
[1] I know that LibreOffice documents are basically zipped XML, but that doesn't make things much easier ;-)
On 23/02/2019 01.49, Christian Boltz wrote:
Hello,
[ I have about 50 unread mails in this discussion, so I might not have seen all relevant comment yet. One thing I noticed is that we have several volunteers. I'm really happy about that :-) Please forgive me for answering only to one of you ;-) ]
Notice that some of us volunteered only to take care of spam while others think and prepare a more permanent solution.
On 2/22/19 4:58 PM, Carlos E. R. wrote:
On 23/02/2019 01.49, Christian Boltz wrote:
Hello,
[ I have about 50 unread mails in this discussion, so I might not have seen all relevant comment yet. One thing I noticed is that we have several volunteers. I'm really happy about that :-) Please forgive me for answering only to one of you ;-) ]
Notice that some of us volunteered only to take care of spam while others think and prepare a more permanent solution.
If we can get moving on the Provide Alternate and Dump Connect idea, there will be no need to bother with the spam, as it will disappear with Connect.
Just sayin'
If you help, even with just some of it, that helps move that process forward towards fruition.
;-)
(... and, I would enjoy working with you, again.)
On 2/22/19 4:49 PM, Christian Boltz wrote:
Hello,
[ I have about 50 unread mails in this discussion, so I might not have seen all relevant comment yet. One thing I noticed is that we have several volunteers. I'm really happy about that :-) Please forgive me for answering only to one of you ;-) ]
Am Freitag, 22. Februar 2019, 08:47:36 CET schrieb Ish Sookun:
On 2/22/19 1:22 AM, Vinzenz Vietzke wrote:
Came up twice already: take a Nextcloud, drop an LibreOffice Calc document there. It's not the shiny knight on a white horse solution but it should be enough to a) keep the membership committee working b) store the member's data safe c) get rid of this ugly spam dump called connect.o.o
Agreed. We start simple.
In a mail nearby, jdd asked the right question:
and why is a *cloud* storage needed to manage membership?
Yes, jdd is offering up some good comments.
Using nextcloud with a LibreOffice Calc document in it would be a bad idea IMHO. Not because my personal preference is ownCloud ;-) but because it makes things more complicated than necessary. For example, extracting the mail aliases out of a LibreOffice table would be a PITA, or in general, automating anything would be a PITA.
Yep.
So let's start even more simple and less cloudy, please ;-)
If we go for "a table that can only be edited by the membership committee", then I'd propose to use a MySQL database + phpMyAdmin
My idea, exactly.
The interface would look a bit more "technical", but not too different/ difficult, and it would have several advantages:
- extracting the mail aliases out of a database is boring and easy (much easier than extracting them from a binary[1] LibreOffice file)
- setting up the server is easy
- we could easily track changes, for example with a daily CSV export that gets auto-commited to a git repo (not a requirement for the initial implementation, just an idea for the future)
- if we setup a "request membership" form, writing to a database is much easier than writing to a LibreOffice document
The hard part is to convert the data from connect.o.o to the new database scheme. (I never looked at the database scheme used by connect.o.o, therefore I have no idea how hard this will be.)
Actually, there are currently only 446 openSUSE Members. That is a number that could easily be split up between Ish, Edwin, Carlos and me -- or more if we can find more -- and that would be less than 112 each.
That would make it possible to convert with manual input, even some cut & paste?
Getting a VM (IMHO: for phpMyAdmin and an empty database) shouldn't be too hard ;-) Please write a mail to the heroes mailinglist to request it, and while on it, please also request access to the VPN and the connect.o.o database.
Until that setup is done, you can already start on the drawing board with stuff like "which columns will we need?" I know it sounds boring, but I'm also sure nobody will get this right on the first attemp ;-) On the positive side, adding a column later is easy, so don't worry too much.
Problem is, I know nothing about setting up or working with the current databases. Last time I did any database work was in Borland dBase III/IV. This new stuff is completely foreign to me: Not that I am a database racist or anything, I just do not understand anything about it. ;-)
Hi Gerry
On 2/23/19 6:31 AM, Fraser_Bell wrote:
That would make it possible to convert with manual input, even some cut & paste?
Let's not focus on the "how" at this moment. Important is that we try the possible alternatives to see what they're capable of. Something which I am doing already.
Problem is, I know nothing about setting up or working with the current databases. Last time I did any database work was in Borland dBase III/IV. This new stuff is completely foreign to me: Not that I am a database racist or anything, I just do not understand anything about it. ;-)
Thanks for stepping too, Gerry.
I'll update you, Edwin and jdd about the solutions I am testing. We can then get in touch the membership officials for a trial.
Regards,
Ish
On Sat, Feb 23, 2019 at 1:08 PM Ish Sookun ish.sookun@lasentinelle.mu wrote:
Hi Gerry
On 2/23/19 6:31 AM, Fraser_Bell wrote:
That would make it possible to convert with manual input, even some cut & paste?
Let's not focus on the "how" at this moment. Important is that we try the possible alternatives to see what they're capable of. Something which I am doing already.
Problem is, I know nothing about setting up or working with the current databases. Last time I did any database work was in Borland dBase III/IV. This new stuff is completely foreign to me: Not that I am a database racist or anything, I just do not understand anything about it. ;-)
Thanks for stepping too, Gerry.
I'll update you, Edwin and jdd about the solutions I am testing. We can then get in touch the membership officials for a trial.
Regards,
Ish
Ish,
I browse the 2 alternatives you sent earlier. I didn't try it or read in detail but seems it lacks something. Connect now has something like social network function and everyone can login using openSUSE credentials which is made through other applications (CMIIW). Spam usually come from bot account, not necessary though, a real human/account can do that too. Of course bot account can easily rejected using some kind mechanism like captcha but the real human account who the intention is making spam might be a bit hard. That usually need an admin works. If the logic/business process can be change so that the new system only for the member it seems more easy, but if the process should follow the existing one we should discuss it more deeper.
Anyway I'll wait your propose solutions. If we already have something more real it will be more easier for my slow brain to discuss. I hope my hand still have some magic left :-)
best wishes, -- Edwin
Let me start a fork of this thread to focus on evaluation of possible solution and list of volunteers to do so
Voluteers (may be) are:
christian Boltz (data base) jdd (galette and more) Ish Sookun Edwin Carlos (?)
(add or remove yourself :-)
needs to fulfill:
* manage a member database with identification, allowing members to check they data and keep them safe * manage a way to allow people to ask to be a members * connect the present base to the new one
solution proposed are:
opensource for sure:
* plain paper * Nextcloud session + libreoffice calc * galette (http://galette.eu/dc/?navlang=en) * mysql + phpmyadmin
probably opensource (to check):
* admidio (https://www.admidio.org/) * clubmaster (http://www.clubmaster.org/) * civicrm (http://groupspaces.com/)
please ad ideas here at will, but fork to add comments (change subject or open a new one) thanks jdd
On 23/02/2019 16.33, jdd@dodin.org wrote:
Let me start a fork of this thread to focus on evaluation of possible solution and list of volunteers to do so
Voluteers (may be) are:
christian Boltz (data base) jdd (galette and more) Ish Sookun Edwin Carlos (?)
Yes, but me only for clearing spam in the Connect platform, so that others have time to evaluate possibilities. Maybe I can do other things related to that platform when/if I find out how it works etc.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday, 2019-02-23 at 20:10 +0100, Carlos E. R. wrote:
On 23/02/2019 16.33, jdd@dodin.org wrote:
Let me start a fork of this thread to focus on evaluation of possible solution and list of volunteers to do so
Voluteers (may be) are:
christian Boltz (data base) jdd (galette and more) Ish Sookun Edwin Carlos (?)
Yes, but me only for clearing spam in the Connect platform, so that others have time to evaluate possibilities. Maybe I can do other things related to that platform when/if I find out how it works etc.
I see Stefan Seyfried also volunteers for this.
- -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar)
Am February 23, 2019 3:33:36 PM UTC schrieb "jdd@dodin.org" jdd@dodin.org:
Let me start a fork of this thread to focus on evaluation of possible solution and list of volunteers to do so
Voluteers (may be) are:
christian Boltz (data base) jdd (galette and more) Ish Sookun Edwin Carlos (?)
(add or remove yourself :-)
I would join, but I don't have a good relationship with our chairman and probably some other members any longer, so I don't expect that my help is welcome. Which I accept, btw, no worries.
But as I explained my problems in this thread and these complaints might be one of the starting points of the whole discussion, you can add Lars as general contact for technical questions. I'm not sure if I'm allowed to do some hands on stuff, but I will for sure do my best to answer any question or offer help in other areas.
needs to fulfill:
- manage a member database with identification, allowing members to
check they data and keep them safe
- manage a way to allow people to ask to be a members
- connect the present base to the new one
solution proposed are:
opensource for sure:
- plain paper
- Nextcloud session + libreoffice calc
- galette (http://galette.eu/dc/?navlang=en)
- mysql + phpmyadmin
probably opensource (to check):
- admidio (https://www.admidio.org/)
- clubmaster (http://www.clubmaster.org/)
- civicrm (http://groupspaces.com/)
please ad ideas here at will, but fork to add comments (change subject or open a new one) thanks
I've one addition: * FreeIPA + maybe some additional forms
But be warned: the idea behind this is bigger than a replacement of connect and might end up in more work.
The idea behind: Establish a new user directory for openSUSE.
You might know that the heroes use FreeIPA internally since a while for authentication and DNS. FreeIPA is utilizing 389 directory (I will call it LDAP from now, as I'm too old to remember numbers ;-) and has a bunch of other features. Especially around authentication and systems management.
I think we should be able to define some new groups like "hero", "board", "election_commitee", "member", "applicant", "user", ... and assign users to these groups. -> all in LDAP. This needs ~10min initial work on the already established system.
The freeipa server is running inside the private network. No setup needed. The system is productive and maintained by the heroes already. Exporting members with their Email settings might not even be needed: using an ldapsearch with a special filter on the mail systems will already do the trick. For the IRC nicknames export script, its about the adaption of the mysql to a ldap query...
Funnily, bugzilla, wikis and other openSUSE tools allow authentication against LDAP since a long time. It might be possible to add the "freeipa LDAP" as authorization source to the running services (in addition or as replacement). This needs migration, cooperation, trust and some time - but would in the end mean that openSUSE would become a bit more independent.
FreeIPA already has a WebUI, that would allow to manage the group membership and other details very user friendly.
So, what is missing? * There is currently no WebUI available in the public. The Heroes could forward the existing UI to the public (especially for evaluation by the membership committee), but this has to be discussed with them (in CC).
* There could be a form, that allows users to request their membership. This could end up in a flag in LDAP, which in turn might result in a notification to the membership committee - but IMHO a mailing list or a real ticket system might be better for membership requests. This has to be discussed with the membership committee (in CC).
* Once approved, members could be added in FreeIPA. Either by asking them to fill out a registration form or by someone with enough rights in FreeIPA. Of course: the best way might be to let them register themselves before they submit their request. In this case, someone could simply add them the the right group and everybody is happy. We need to discuss if they should/could use the same username as they have now, but this is a detail.
* After some evaluation and testing, the community might want to migrate the current Novell/openSUSE login stuff to FreeIPA - but this is not the question here and should be discussed with the openSUSE community (in TO :-).
Regards, Lars
On Sat, 23 Feb 2019 at 20:49, Lars Vogdt lrupp@suse.de wrote:
I would join, but I don't have a good relationship with our chairman and probably some other members any longer, so I don't expect that my help is welcome. Which I accept, btw, no worries.
From my perspective your contributions to this solution would be
absolutely welcome.
But as I explained my problems in this thread and these complaints might be one of the starting points of the whole discussion, you can add Lars as general contact for technical questions. I'm not sure if I'm allowed to do some hands on stuff, but I will for sure do my best to answer any question or offer help in other areas.
I don't know what you mean by "if I'm allowed".
From my view there is nothing that should prevent you or any other
volunteer from being allowed to do hands on stuff to solve this issue. If there are factors I'm unaware of, then I'd suggest we discuss that offlist. I'm prepared to help in any way I can to remove any such blockers. If it would make you more comfortable, I'd suggest emailing board@opensuse.org if you wish an alternative to contacting me directly.
I've one addition:
- FreeIPA + maybe some additional forms
But be warned: the idea behind this is bigger than a replacement of connect and might end up in more work.
The idea behind: Establish a new user directory for openSUSE.
You might know that the heroes use FreeIPA internally since a while for authentication and DNS. FreeIPA is utilizing 389 directory (I will call it LDAP from now, as I'm too old to remember numbers ;-) and has a bunch of other features. Especially around authentication and systems management.
I think we should be able to define some new groups like "hero", "board", "election_commitee", "member", "applicant", "user", ... and assign users to these groups. -> all in LDAP. This needs ~10min initial work on the already established system.
The freeipa server is running inside the private network. No setup needed. The system is productive and maintained by the heroes already. Exporting members with their Email settings might not even be needed: using an ldapsearch with a special filter on the mail systems will already do the trick. For the IRC nicknames export script, its about the adaption of the mysql to a ldap query...
Funnily, bugzilla, wikis and other openSUSE tools allow authentication against LDAP since a long time. It might be possible to add the "freeipa LDAP" as authorization source to the running services (in addition or as replacement). This needs migration, cooperation, trust and some time - but would in the end mean that openSUSE would become a bit more independent.
FreeIPA already has a WebUI, that would allow to manage the group membership and other details very user friendly.
So, what is missing?
There is currently no WebUI available in the public. The Heroes could forward the existing UI to the public (especially for evaluation by the membership committee), but this has to be discussed with them (in CC).
There could be a form, that allows users to request their membership. This could end up in a flag in LDAP, which in turn might result in a notification to the membership committee - but IMHO a mailing list or a real ticket system might be better for membership requests. This has to be discussed with the membership committee (in CC).
Once approved, members could be added in FreeIPA. Either by asking them to fill out a registration form or by someone with enough rights in FreeIPA. Of course: the best way might be to let them register themselves before they submit their request. In this case, someone could simply add them the the right group and everybody is happy. We need to discuss if they should/could use the same username as they have now, but this is a detail.
After some evaluation and testing, the community might want to migrate the current Novell/openSUSE login stuff to FreeIPA - but this is not the question here and should be discussed with the openSUSE community (in TO :-).
Oh boy, talk about a comprehensive solution. This solution would also be compatible with some casual enquiries discussed with the Board recently. If this is an idea the community likes and is willing to work behind, I can see potential in this solution to tie together nicely with other requirements that are currently coalescing over the horizon.
Might be worth the work
Le 23/02/2019 à 21:20, Richard Brown a écrit :
Might be worth the work
good, thanks
jdd
HUGE, HUGE, HUGE SUPER THANKS!!!!
Super Thanks to all the people who are stepping up to offer help on one aspect or another with the remake of Membership database and cleanup of our existing system.
This is what I, personally, needed to see to reinvigorate my energy to work on openSUSE problems.
A Community, Volunteering as Community Members, to solve a pressing Community Issue.
Thanks, everyone!!! Up till now, it was beginning to depress me that calls for help seemed to be constantly ignored.
Now, I am beginning to feel Very Proud of being a Member of this Community!
Am 2019-02-23 21:20, schrieb Richard Brown:
On Sat, 23 Feb 2019 at 20:49, Lars Vogdt lrupp@suse.de wrote:
But as I explained my problems in this thread and these complaints might be one of the starting points of the whole discussion, you can add Lars as general contact for technical questions. I'm not sure if I'm allowed to do some hands on stuff, but I will for sure do my best to answer any question or offer help in other areas.
I don't know what you mean by "if I'm allowed".
Well: I was kicked from machines in the past, without any further information. So I assume that there was either an order from someone or someone inside the heroes team did not want me to contribute any longer. As I explained the weeks before that event that I probably have to step back because my time for the heroes in 2019 is limited, I accepted the removal of my keys (while I still not understand that nobody talked to me about this in front or explained me the reasons). More details are on the heroes list.
So from my point of view, I'm asking the heroes if I'm allowed to help.
I've one addition:
- FreeIPA + maybe some additional forms
[...]
Might be worth the work
Thanks.
Lars
On 2/23/19 12:20 PM, Richard Brown wrote:
On Sat, 23 Feb 2019 at 20:49, Lars Vogdt lrupp@suse.de wrote:
I would join, but I don't have a good relationship with our chairman and probably some other members any longer, so I don't expect that my help is welcome. Which I accept, btw, no worries.
From my perspective your contributions to this solution would be
absolutely welcome.
But as I explained my problems in this thread and these complaints might be one of the starting points of the whole discussion, you can add Lars as general contact for technical questions. I'm not sure if I'm allowed to do some hands on stuff, but I will for sure do my best to answer any question or offer help in other areas.
I don't know what you mean by "if I'm allowed".
From my view there is nothing that should prevent you or any other
volunteer from being allowed to do hands on stuff to solve this issue. If there are factors I'm unaware of, then I'd suggest we discuss that offlist. I'm prepared to help in any way I can to remove any such blockers. If it would make you more comfortable, I'd suggest emailing board@opensuse.org if you wish an alternative to contacting me directly.
Ahhh. As I thought. Thanks, Richard.
On 2/23/19 11:49 AM, Lars Vogdt wrote:
Am February 23, 2019 3:33:36 PM UTC schrieb "jdd@dodin.org" jdd@dodin.org:
Let me start a fork of this thread to focus on evaluation of possible solution and list of volunteers to do so
Voluteers (may be) are:
christian Boltz (data base) jdd (galette and more) Ish Sookun Edwin Carlos (?)
(add or remove yourself :-)
I would join, but I don't have a good relationship with our chairman and probably some other members any longer, so I don't expect that my help is welcome. Which I accept, btw, no worries.
Nonsense! You are fully welcome, in fact *definitely wanted* to join in this Community Exercise! If anyone gives you grief, the rest of us -- I am sure -- will set them straight.
I bet Richard agrees with me, and I bet many others here do, too.
Op zaterdag 23 februari 2019 21:59:26 CET schreef Fraser_Bell:
On 2/23/19 11:49 AM, Lars Vogdt wrote:
Am February 23, 2019 3:33:36 PM UTC schrieb "jdd@dodin.org"
Let me start a fork of this thread to focus on evaluation of possible solution and list of volunteers to do so
Voluteers (may be) are:
christian Boltz (data base) jdd (galette and more) Ish Sookun Edwin Carlos (?)
(add or remove yourself :-)
I would join, but I don't have a good relationship with our chairman and probably some other members any longer, so I don't expect that my help is welcome. Which I accept, btw, no worries.
Nonsense! You are fully welcome, in fact *definitely wanted* to join in this Community Exercise! If anyone gives you grief, the rest of us -- I am sure -- will set them straight.
I bet Richard agrees with me, and I bet many others here do, too.
+1 here.
On 2/23/19 1:28 PM, Knurpht-openSUSE wrote:
Op zaterdag 23 februari 2019 21:59:26 CET schreef Fraser_Bell:
On 2/23/19 11:49 AM, Lars Vogdt wrote:
Am February 23, 2019 3:33:36 PM UTC schrieb "jdd@dodin.org"
Let me start a fork of this thread to focus on evaluation of possible solution and list of volunteers to do so
Voluteers (may be) are:
christian Boltz (data base) jdd (galette and more) Ish Sookun Edwin Carlos (?)
(add or remove yourself :-)
I would join, but I don't have a good relationship with our chairman and probably some other members any longer, so I don't expect that my help is welcome. Which I accept, btw, no worries.
Nonsense! You are fully welcome, in fact *definitely wanted* to join in this Community Exercise! If anyone gives you grief, the rest of us -- I am sure -- will set them straight.
I bet Richard agrees with me, and I bet many others here do, too.
+1 here.
LOL!
I absolutely *love it* when I get to say: "See, toldya so!"
On 2/23/19 8:49 PM, Lars Vogdt wrote:
- After some evaluation and testing, the community might want to
migrate the current Novell/openSUSE login stuff to FreeIPA - but this is not the question here and should be discussed with the openSUSE community (in TO :-).
Note my proposal a couple of months ago:
"Proposal: Use Æ-DIR instead of FreeIPA" https://lists.opensuse.org/heroes/2018-07/msg00002.html
I've done a PoC installation:
https://progress.opensuse.org/issues/39872
I will also present Æ-DIR (see https://ae-dir.com) at oSC 2019.
In the mean-time someone implemented a aehostd state for CentOS and Debian which could be probably pretty easily adapted to openSUSE:
https://git.webmeisterei.com/saltstack-formulas/ae-dir-formula
Ciao, Michael.
On 2/23/19 7:33 AM, jdd@dodin.org wrote:
Let me start a fork of this thread to focus on evaluation of possible solution and list of volunteers to do so
Voluteers (may be) are:
christian Boltz (data base) jdd (galette and more) Ish Sookun Edwin Carlos (?)
(add or remove yourself :-)
Did you forget someone? ;-)
... and, no, Christian Boltz has not volunteered, yet, as he is quite busy, although he will be involved in some ways. He was talking to me at the Heroes meeting about me doing something about the Connect problem, was willing to help me get started with it, but it would be me who was taking it on, not Christian.
He was only offering at the time to point me in the right directions to get the necessary access and technical structure.
Also at the time, we were discussing using the Wiki itself for the Member Profile Pages, in a Members sub-heading, editable *only* by the Admins, necessary people (Membership Committee, f.e.), and the Member themself (so they have full control over their information).
needs to fulfill:
- manage a member database with identification, allowing members to
check they data and keep them safe
See above, as one solution.
- manage a way to allow people to ask to be a members
Website Forms, with captcha and/or other verification system, nothing new. The form would then send the e-mail to the Membership Committee.
- connect the present base to the new one
MySQL, php. And, no, NOT connect the present base, but replace it with a new one. Data can be ported, no problem, then edited if necessary.
solution proposed are:
opensource for sure:
Absolutely
- plain paper
- Nextcloud session + libreoffice calc
- galette (http://galette.eu/dc/?navlang=en)
- mysql + phpmyadmin
YEP! My vote.
... in a VM instance we (openSUSE) have full control over.
And, as I said, I am willing to join the Heroes team and be ONE OF a group of people who will help keep it maintained after it is set up.
Thanks, again, jdd, for joining in.
Le 23/02/2019 à 21:56, Fraser_Bell a écrit :
On 2/23/19 7:33 AM, jdd@dodin.org wrote:
Let me start a fork of this thread to focus on evaluation of possible solution and list of volunteers to do so
Voluteers (may be) are:
christian Boltz (data base) jdd (galette and more) Ish Sookun Edwin Carlos (?)
(add or remove yourself :-)
Did you forget someone? ;-)
I was unsure so I added the "add yourself"
... and, no, Christian Boltz has not volunteered,
it as him that proposed the phpmyadmin solution, so I figured out hi wanted to setup one :-)
opensource for sure:
Absolutely
- plain paper
- Nextcloud session + libreoffice calc
- galette (http://galette.eu/dc/?navlang=en)
- mysql + phpmyadmin
YEP! My vote.
... in a VM instance we (openSUSE) have full control over.
alrady asked the heroes team about this (I don't expect an answer during week end :-()
thanks jdd
Okay, so the first thing we need to do is get this all organized, get everyone willing to help with *whatever* section of this project all on the same page.
We need to split the categories, for one, and we need to select a Team Leader for each of those. Otherwise we will be thrashing around and accidentally stepping on each others toes, not a good thing at all and would probably kill the whole project.
When that is done, the people who are stepping up to offer their help can safely choose what they believe they can do and are willing to do, as little or as much as they each feel like doing.
We need to set some goals and get everyone headed in the same direction.
I propose we arrange an IRC Meeting on either #opensuse-admin or #opensuse-project ASAP. So, first order of business is getting a time all those offering to help can attend.
I can make myself available after 11:00 a.m. Pacific Standard Time (America-Vancouver) most days, which is UTC -08:00.
Who else?
(And, no, I am not trying to take over, I think we probably have better and more sociable Team Leaders here than me, although I would accept if others insist.)
On sob, lut 23, 2019 at 10:32 PM, Fraser_Bell Fraser_Bell@openSUSE.org wrote:
Okay, so the first thing we need to do is get this all organized, get everyone willing to help with *whatever* section of this project all on the same page.
We need to split the categories, for one, and we need to select a Team Leader for each of those. Otherwise we will be thrashing around and accidentally stepping on each others toes, not a good thing at all and would probably kill the whole project.
When that is done, the people who are stepping up to offer their help can safely choose what they believe they can do and are willing to do, as little or as much as they each feel like doing.
We need to set some goals and get everyone headed in the same direction.
I propose we arrange an IRC Meeting on either #opensuse-admin or #opensuse-project ASAP. So, first order of business is getting a time all those offering to help can attend.
I can make myself available after 11:00 a.m. Pacific Standard Time (America-Vancouver) most days, which is UTC -08:00.
Who else?
(And, no, I am not trying to take over, I think we probably have better and more sociable Team Leaders here than me, although I would accept if others insist.)
Eh, out of all that shitposting I started making some quick and easy replacement for connect on Friday.
Initial mockup: https://cdn.discordapp.com/attachments/407993213425680384/548565025325973504...
Current state: https://cdn.discordapp.com/attachments/407993213425680384/548948561950146571... (and some more equally unfinished parts of the interface)
I suspect I will have something usable on monday (and if not my next free time is on the next friday).
Although I would much appreciate less spam in mailing lists so I can focus on that instead of reading emails :P
LCP [Stasiek] https://lcp.world
On 2/23/19 1:39 PM, hellcp@opensuse.org wrote:
On sob, lut 23, 2019 at 10:32 PM, Fraser_Bell Fraser_Bell@openSUSE.org wrote:
Okay, so the first thing we need to do is get this all organized, get everyone willing to help with *whatever* section of this project all on the same page.
We need to split the categories, for one, and we need to select a Team Leader for each of those. Otherwise we will be thrashing around and accidentally stepping on each others toes, not a good thing at all and would probably kill the whole project.
When that is done, the people who are stepping up to offer their help can safely choose what they believe they can do and are willing to do, as little or as much as they each feel like doing.
We need to set some goals and get everyone headed in the same direction.
I propose we arrange an IRC Meeting on either #opensuse-admin or #opensuse-project ASAP. So, first order of business is getting a time all those offering to help can attend.
I can make myself available after 11:00 a.m. Pacific Standard Time (America-Vancouver) most days, which is UTC -08:00.
Who else?
(And, no, I am not trying to take over, I think we probably have better and more sociable Team Leaders here than me, although I would accept if others insist.)
Eh, out of all that shitposting I started making some quick and easy replacement for connect on Friday.
Initial mockup: https://cdn.discordapp.com/attachments/407993213425680384/548565025325973504...
Current state: https://cdn.discordapp.com/attachments/407993213425680384/548948561950146571...
(and some more equally unfinished parts of the interface)
I suspect I will have something usable on monday (and if not my next free time is on the next friday).
Although I would much appreciate less spam in mailing lists so I can focus on that instead of reading emails :P
LCP [Stasiek] https://lcp.world
Looking good!!! Thank you!!!
Can I help in any way?
On 2/23/19 1:32 PM, Fraser_Bell wrote:
Okay, so the first thing we need to do is get this all organized, get everyone willing to help with *whatever* section of this project all on the same page.
We need to split the categories, for one, and we need to select a Team Leader for each of those. Otherwise we will be thrashing around and accidentally stepping on each others toes, not a good thing at all and would probably kill the whole project.
When that is done, the people who are stepping up to offer their help can safely choose what they believe they can do and are willing to do, as little or as much as they each feel like doing.
We need to set some goals and get everyone headed in the same direction.
I propose we arrange an IRC Meeting on either #opensuse-admin or #opensuse-project ASAP. So, first order of business is getting a time all those offering to help can attend.
I can make myself available after 11:00 a.m. Pacific Standard Time (America-Vancouver) most days, which is UTC -08:00.
Who else?
(And, no, I am not trying to take over, I think we probably have better and more sociable Team Leaders here than me, although I would accept if others insist.)
Repeating this highlighting objective in Heading.
Le 23/02/2019 à 23:08, Fraser_Bell a écrit :
Repeating this highlighting objective in Heading.
sorry, it was sleep time for me :-( - I just come again and with little time right now :-(
IRC is not friendly with users all around the world :-(
jdd
Am Sonntag, 24. Februar 2019, 09:16:50 CET schrieb jdd@dodin.org:
Le 23/02/2019 à 23:08, Fraser_Bell a écrit :
Repeating this highlighting objective in Heading.
sorry, it was sleep time for me :-( - I just come again and with little time right now :-(
annoincing this kinbd of stuff a bit more in advance would be the thing to do. Not everybody checks their email every five minutes, especially at 11pm.
IRC is not friendly with users all around the world :-(
jdd
not just irc...
Cheers MH
On 2/24/19 12:16 AM, jdd@dodin.org wrote:
Le 23/02/2019 à 23:08, Fraser_Bell a écrit :
Repeating this highlighting objective in Heading.
sorry, it was sleep time for me :-( - I just come again and with little time right now :-(
IRC is not friendly with users all around the world :-(
jdd
Sorry, jdd. Miscommunication. I am suggesting an IRC Meeting sometime this week, say Tuesday, Wednesday or Thursday. I announced the hours I would be available for such a meeting.
I was instead hoping all taking part would announce their available hours, so we can set a day and time we all could meet.
It is just a suggestion, but I think an important one, because we have a few people working on things.
I would hate to see someone work hard on an idea, only to find out things are going in a different direction.
Such a result would tend to discourage a Contributor from volunteering for things in the future.
I am suggesting we take every step we can to make sure someone does not waste time going in the wrong direction, and we take every step to encourage everyone who wants to step in here, *not* discourage them.
In any case, somehow we need to get things organized, divided into steps and/or Teams, with those stepping up choosing what they can, cannot, or want to do.
Sorry for my miscommunication, here.
Le 23/02/2019 à 16:33, jdd@dodin.org a écrit :
- galette (http://galette.eu/dc/?navlang=en)
I created on my own (shared) domain a galette instance (15" time)
http://dodin.org/galette/webroot//login
I expect some of you to mimic a membership subscription: create your own profile.
you may as well ask for admin account, no problem
jdd
Am Samstag, 23. Februar 2019, 16:33:36 CET schrieb jdd@dodin.org:
Let me start a fork of this thread to focus on evaluation of possible solution and list of volunteers to do so
Voluteers (may be) are:
christian Boltz (data base) jdd (galette and more) Ish Sookun Edwin Carlos (?)
(add or remove yourself :-)
needs to fulfill:
- manage a member database with identification, allowing members to
check they data and keep them safe
- manage a way to allow people to ask to be a members
- connect the present base to the new one
solution proposed are:
opensource for sure:
- plain paper
- Nextcloud session + libreoffice calc
- galette (http://galette.eu/dc/?navlang=en)
- mysql + phpmyadmin
Free ERP system - would allow to manage accounts/payments as well (TSP...)
Cheers Axel
Hello all.
I think at the moment a wiki page to summarize the propositions could be useful.
are you OK? can I process?
thanks jdd
Hi jdd,
On 2/24/19 9:04 PM, jdd@dodin.org wrote:
I think at the moment a wiki page to summarize the propositions could be useful.
are you OK? can I process?
Sure, that'll be nice.
Regards,
Ish
On 2/24/19 9:04 AM, jdd@dodin.org wrote:
Hello all.
I think at the moment a wiki page to summarize the propositions could be useful.
are you OK? can I process?
thanks jdd
That sounds like a very good idea to me, jdd.
Le 24/02/2019 à 23:25, Fraser_Bell a écrit :
On 2/24/19 9:04 AM, jdd@dodin.org wrote:
Hello all.
I think at the moment a wiki page to summarize the propositions could be useful.
are you OK? can I process?
thanks jdd
That sounds like a very good idea to me, jdd.
done:
https://en.opensuse.org/openSUSE_talk:Membership_officials
I used the talk page of the Membership_official, it's free to write there with any openSUSE account (it can be moved if a better place if found)
Please read the page and edit it at will, for the content and for the language, my English is limited :-(.
Feel free to open also sub-pages if what you have to say is a bit long
thanks jdd
On 2/25/19 12:40 AM, jdd@dodin.org wrote:
Le 24/02/2019 à 23:25, Fraser_Bell a écrit :
On 2/24/19 9:04 AM, jdd@dodin.org wrote:
Hello all.
I think at the moment a wiki page to summarize the propositions could be useful.
are you OK? can I process?
thanks jdd
That sounds like a very good idea to me, jdd.
done:
https://en.opensuse.org/openSUSE_talk:Membership_officials
I used the talk page of the Membership_official, it's free to write there with any openSUSE account (it can be moved if a better place if found)
Please read the page and edit it at will, for the content and for the language, my English is limited :-(.
Feel free to open also sub-pages if what you have to say is a bit long
thanks jdd
I will take care of that later today, jdd. Thanks.
On Sat, 23 Feb 2019 16:33:36 +0100 "jdd@dodin.org" jdd@dodin.org wrote:
solution proposed are:
opensource for sure:
- plain paper
- Nextcloud session + libreoffice calc
Let me vote for Nextcloud/Owncloud here: * multiple groups can be created/administrated * has a (public) calendar (another item on the ToDo list) * could be used to provide all members a place for collaboration (files, images, cookbook, ...) - while I'm not sure if we should pay our members some MB space for their work? * could even obsolete users.o.o directly * ...
On the other side, we see what happens if we introduce just more and more systems without carrying about the ones that are implemented. So whatever the final decision is: I vote for obsoleting users.o.o as soon as possible and keep the new system up to date!
Regards, Lars
PS: count me in, please.
On Di, Apr 6, 2021 at 09:55, Lars Vogdt lrupp@suse.de wrote:
Let me vote for Nextcloud/Owncloud here:
- multiple groups can be created/administrated
- has a (public) calendar (another item on the ToDo list)
- could be used to provide all members a place for collaboration (files, images, cookbook, ...) - while I'm not sure if we should pay our members some MB space for their work?
- could even obsolete users.o.o directly
- ...
We could create a mail ticket system on pagure for membership submissions and obsolete connect right now, the much bigger problem is membership applications than keeping existing memberships.
I still vote we do membership management in the login system because: * that allows us to do login for members-only services global instead of implementing the list of members per service * we need to have our own login system for gdpr/foundation reasons anyway (that was discussed during gdpr meeting last year) * we can fold heroes and standard login into one system and manage permissions to infra as groups (as we already do pretty much) * it allows us to check when was the last time the person logged into any service at all for deprecating member status * freeipa provides us with an option to manage email aliases * noggin replaces profiles as well as provides nice settings for the users to manage their account and probably more
The problem is: I don't really know if we can do anything at all, it doesn't seem like SUSE is particularly happy about the prospect of openSUSE Accounts from what we got last year, but it is pretty much delaying inevitable from the legal perspective (assuming foundation happens that is ;). And the system we want to use is way more pleasant to use and navigate as well as actually fit for community purposes compared to the SUSE idp. Actually Fedora deployed it last week if you want to have a look at it (although you will need to register if you don't have a login already)
https://accounts.fedoraproject.org/user/hellcp/ https://accounts.fedoraproject.org/user/ngompa/ (since Neal belongs to group so he can show off the functionality better ;)
LCP [Sasi] https://lcp.world
On Tue, 06 Apr 2021 10:29:03 +0200 Sasi Olin hellcp@opensuse.org wrote:
I still vote we do membership management in the login system because:
That would indeed be a perfect solution. But the current login system is managed by SUSE-IT. There are flags to mark an account as SUSE employee. Maybe there is a possibility to get a similar flag for * openSUSE members * openSUSE heroes * other groups? => Technically no big deal. Someone would have to create a "ticket" anyway to get people added to a group or two.
- we need to have our own login system for gdpr/foundation reasons
anyway (that was discussed during gdpr meeting last year)
Interesting! Can you please share me the meeting minutes?
- noggin replaces profiles as well as provides nice settings for the
users to manage their account and probably more
[...]
https://accounts.fedoraproject.org/user/hellcp/ https://accounts.fedoraproject.org/user/ngompa/ (since Neal belongs to group so he can show off the functionality better ;)
Maybe we all should just switch over to Fedora's infrastructure and invest our saved time in collaboration?
With kind regards, Lars
On Di, Apr 6, 2021 at 18:52, Lars Vogdt lrupp@suse.de wrote:
That would indeed be a perfect solution. But the current login system is managed by SUSE-IT. There are flags to mark an account as SUSE employee. Maybe there is a possibility to get a similar flag for
- openSUSE members
- openSUSE heroes
- other groups?
=> Technically no big deal. Someone would have to create a "ticket" anyway to get people added to a group or two.
Considering that tickets for for example removing accounts of spammers ended up in a void (or rather our ticket system) for a long time without anybody looking at them, I have 0, zero, null and none trust in that working out. We do need a system with which heroes can actually help out and which can be used by membership officials without jumping through hoops.
- we need to have our own login system for gdpr/foundation reasons
anyway (that was discussed during gdpr meeting last year)
Interesting! Can you please share me the meeting minutes?
If that existed it was lost to time, mostly because everybody involved with GDPR stuff is extremely busy, and the meetings haven't managed to turn into a regular thing; please reach out to SUSE Legal though, I'm sure they would be happy to explain to you why clear divide of ownership of data within infrastructure is necessary for GDPR reasons.
Maybe we all should just switch over to Fedora's infrastructure and invest our saved time in collaboration?
How about we use a system which actually allows us to contribute to it, instead of something which not only requires signing CLA, but also apparently requires patching vital functionality and because of it breaks with updates. I know SUSE very much prefers to use tools that are either proprietary or very hard to contribute to though from my experience, so that may not be an actual argument that gets through.
LCP [Sasi] https://lcp.world
Sasi Olin wrote:
On Di, Apr 6, 2021 at 18:52, Lars Vogdt lrupp@suse.de wrote:
That would indeed be a perfect solution. But the current login system is managed by SUSE-IT. There are flags to mark an account as SUSE employee. Maybe there is a possibility to get a similar flag for
- openSUSE members
- openSUSE heroes
- other groups?
=> Technically no big deal. Someone would have to create a "ticket" anyway to get people added to a group or two.
Considering that tickets for for example removing accounts of spammers ended up in a void (or rather our ticket system) for a long time without anybody looking at them, I have 0, zero, null and none trust in that working out.
FYI, we deliberately did not act on those "forum spammers" reports, they did not end up in a void, we just saw no reason to do anything. After discussing it with the forum moderators, it was agreed they would stop sending them.
- we need to have our own login system for gdpr/foundation reasons
anyway (that was discussed during gdpr meeting last year)
Interesting! Can you please share me the meeting minutes?
If that existed it was lost to time,
I do not recall any minutes being taken :-( it was pretty much, iirc, an ad-hoc meeting. (slightly disorganised, not much agenda etc). I believe having separate authentication systems _was_ discussed, but I don't recall it having been listed as an absolute requirement wrt GDPR (at least not until we have our own legal entity).
On Tue, 06 Apr 2021 19:36:07 +0200 Sasi Olin hellcp@opensuse.org wrote:
Considering that tickets for for example removing accounts of spammers ended up in a void (or rather our ticket system) for a long time without anybody looking at them, I have 0, zero, null and none trust in that working out. We do need a system with which heroes can actually help out and which can be used by membership officials without jumping through hoops.
Agreed. But this is a general problem.
please reach out to SUSE Legal though, I'm sure they would be happy to explain to you why clear divide of ownership of data within infrastructure is necessary for GDPR reasons.
Will do. :-)
Maybe we all should just switch over to Fedora's infrastructure and invest our saved time in collaboration?
Just to be a bit more clear: I did neither want to make a joke nor did I want to attack someone. I just get the feeling that our two communities might start sharing not only code on their distributions, but maybe more? I would love to hear others opinions...
How about we use a system which actually allows us to contribute to it, instead of something which not only requires signing CLA, but also apparently requires patching vital functionality and because of it breaks with updates. I know SUSE very much prefers to use tools that are either proprietary or very hard to contribute to though from my experience, so that may not be an actual argument that gets through.
I guess the main problem with this is the parallel use of OBS and Bugzilla at the moment?
If we can bring both systems to support more than one authentication system, we could create a completely independent openSUSE identify management system.
After that, it's more or less only the hardware and domain sponsoring from SUSE which is connecting SUSE and openSUSE. I see both as not critical (as both could be provided by any other sponsor as well).
Did I miss something?
Regards, Lars
On Di, Apr 6, 2021 at 21:28, Lars Vogdt lrupp@suse.de wrote:
Maybe we all should just switch over to Fedora's infrastructure
and
invest our saved time in collaboration?
Just to be a bit more clear: I did neither want to make a joke nor did I want to attack someone. I just get the feeling that our two communities might start sharing not only code on their distributions, but maybe more? I would love to hear others opinions...
I don't really see why wanting to collaborate with another distributions when they have a piece of software that we need for our infrastructure is a bad thing. I would actually rather we do that than use software clearly made for HR departments in companies and not open source communities.
I guess the main problem with this is the parallel use of OBS and Bugzilla at the moment?
If we can bring both systems to support more than one authentication system, we could create a completely independent openSUSE identify management system.
After that, it's more or less only the hardware and domain sponsoring from SUSE which is connecting SUSE and openSUSE. I see both as not critical (as both could be provided by any other sponsor as well).
Did I miss something?
Neal did try reaching out to SUSE/openSUSE Bugzilla maintainers to work on getting it to support multiple identity providers, but that was never answered even once. If this is the approach there, is it even worth starting working on much more involving work in OBS? Believe it or not we also would love to do work that results in effects and it's just ignored time and time again.
LCP [Sasi] https://lcp.world
[ Late response, apologies ]
On Tue 2021-04-06, Sasi Olin wrote:
Neal did try reaching out to SUSE/openSUSE Bugzilla maintainers to work on getting it to support multiple identity providers, but that was never answered even once. If this is the approach there, is it even worth starting working on much more involving work in OBS? Believe it or not we also would love to do work that results in effects and it's just ignored time and time again.
Bugzilla is run by SUSE IT at this point. OBS is run by folks like Henne, Lars,... who are very close to openSUSE. It is an actively maintained and modern part of our infrastructure.
If there's any requirements on or suggestions for OBS, I encourage you to give it a try.
(I don't have the exact Who is Who around OBS these days, but bet Lars can help connect.)
If there's anything needed from SUSE IT, Evzenie and/or members of her team in SUSE IT try to attend the monthly Heroes meeting, and they care. If anything feels stuck, best reach out to her directly (and in the unlikely case you need help beyond that, feel free to copy me).
Gerald
On Wed, Jun 2 2021 at 20:37:34 +0200, Gerald Pfeifer gp@suse.com wrote:
Bugzilla is run by SUSE IT at this point. OBS is run by folks like Henne, Lars,... who are very close to openSUSE. It is an actively maintained and modern part of our infrastructure.
If there's any requirements on or suggestions for OBS, I encourage you to give it a try.
(I don't have the exact Who is Who around OBS these days, but bet Lars can help connect.)
I know how to contact OBS developers, maintainers and admins, they seem to be around the community a lot
If there's anything needed from SUSE IT, Evzenie and/or members of her team in SUSE IT try to attend the monthly Heroes meeting, and they care. If anything feels stuck, best reach out to her directly (and in the unlikely case you need help beyond that, feel free to copy me).
Yeah, we need to finally do that, since we really are stuck there
LCP [Sasi] https://lcp.world
Lars Vogdt wrote:
Maybe we all should just switch over to Fedora's infrastructure and invest our saved time in collaboration?
Just to be a bit more clear: I did neither want to make a joke nor did I want to attack someone. I just get the feeling that our two communities might start sharing not only code on their distributions, but maybe more? I would love to hear others opinions...
Sharing is good as long as it is bilateral or e.g. via open source. I am not interested in "switching over to Fedora's infrastructure", period. Maintaining our independence is important to me.
Op dinsdag 6 april 2021 21:28:11 CEST schreef Lars Vogdt:
ust to be a bit more clear: I did neither want to make a joke nor did I want to attack someone. I just get the feeling that our two communities might start sharing not only code on their distributions, but maybe more? I would love to hear others opinions...
Not another opinion, but I love to see that happening. In our meet.opensuse.org sessions where Fedora users were present I also felt that the Fedora community/devs/packagers like this. We, as communities, have a lot in common, we each have developed tools we could mutually benefit from. Together we could be the standard for how to build, distribute and maintain a distro(version).
On 4/6/21 5:59 PM, Sasi Olin wrote:
On Di, Apr 6, 2021 at 09:55, Lars Vogdt lrupp@suse.de wrote:
Let me vote for Nextcloud/Owncloud here:
- multiple groups can be created/administrated
- has a (public) calendar (another item on the ToDo list)
- could be used to provide all members a place for collaboration
(files, images, cookbook, ...) - while I'm not sure if we should pay our members some MB space for their work?
- could even obsolete users.o.o directly
- ...
We could create a mail ticket system on pagure for membership submissions and obsolete connect right now, the much bigger problem is membership applications than keeping existing memberships.
Handling applications is actually the easy bit, we probably don't need anything more then a email template that you fill out and email to a mailing list. It is then streamlining the process of accepting the membership setting up the email / irc aliases if desired etc is probably what actually needs atleast a little work.
I still vote we do membership management in the login system because:
- that allows us to do login for members-only services global instead of
implementing the list of members per service
- we need to have our own login system for gdpr/foundation reasons
anyway (that was discussed during gdpr meeting last year)
I am not entirely convinced that "Need" is the right word here. Certainly SUSE Legal would prefer not to be responsible from a GDPR perspective, however there are other things at play here.
It would be exceptionally unwise for a "openSUSE Fountdation" to take ownership of user data unless as part of SUSE's sponsorship of openSUSE it covers these costs. To date as part of our foundation discussions we have always seen this as a possible future option but not something that would be done straight away but something that could be discussed later if both sides agree it would be beneficial given there are also significant technical challenges here that i'll get to in a minute.
Having said that it should be considerably cheaper for openSUSE to handle its GDPR then what it costs SUSE Legal, so if SUSE Legal really wants such a change it would be really helpful if they help us develop a business case and outline how the above would work to go to upper SUSE management to help push the foundation proposal forward.
As I said earlier there were technical reasons which have been the main reason behind not looking at this during the formation of the foundation (It's also worth noting when we last had these serious discussions SUSE IT was still in the middle of a carve out). The main ones as you mention are obviously obs and bugzilla, data gets shared from the openSUSE obs instance to the internal one and as you are aware the bugzilla instance is the same.
What makes this problem genuinely hard is there are a number of SUSE employees such as myself who were members of the openSUSE community before joining SUSE, to make our lives easier generally we just continue using our "community" account inside SUSE and just have the SUSE Employee flag set. This means we don't need to constantly swap obs and bugzilla accounts based off whether we are dealing with a package we maintained before joining SUSE or one we maintain as a part of our role. Further to that if an employee leaves SUSE generally it doesn't mean that all there maintainership rights etc in obs should be removed that is generally left up to them.
So under this idea of two account systems does an employee such as myself end up with a "SUSE" account and a "Community" account if so which has access to what inside obs and how do you make sure that my bugs for community packages still get assigned to my SUSE account with access to security bugs because that is the bugzilla account i'll use.
Really if SUSE Legal no longer wants to be legally responsible for community data from a GDPR perspective they need to first work with the openSUSE community to help us establish a foundation that can hold the data and then need to work with SUSE IT and then the heroes to answer the above questions but really currently its still mostly SUSE IT's responsibility and if they come back to SUSE Legal and say yes we can do that but its going to cost $XXXXXX SUSE Legal might turn around and say well if the cost is that much its not worth the benefit and instead we will stick with the existing arrangement.
There are also other technical solutions to this problem that would address these issues in a far simpler manner. For example it maybe possible to have multiple IDP databases such that the employee database is on SUSE hardware and the community one is on foundation hardware, which would solve the GDPR issue from a legal perspective. The foundation could then have a "Service agreement" with SUSE IT to maintain the login system and make changes in a timely fashion. As part of its sponsorship of openSUSE the agreement could also state that SUSE will provide an employee already working on openSUSE to handle GDPR requests which would be much cheaper then SUSE Legal handling them and would mean that a foundation wouldn't have to deal with the risk of not having someone on the Heroes team in 10 years time who is willing to handle GDPR requests.
The reality is any change here will benefit SUSE the most so really they need to be the one driving the process. As a board member in the current state i'd be really hesitant for the Heroes to create yet another authentication system even if it could fix all the above issues without approval from SUSE Legal and SUSE IT because ultimately currently they are still responsible for the data. Without such agreement this would be one rare case where i'd see it as reasonable for the openSUSE Chairman to use there veto.
But as a result of all this I don't think that we can expect to have a separate account system in the near future and maybe its worth using an alternate system as an intermediate step.
As an aside we also have to deal with Emeritus Members and people wishing to transfer either way.
On Tue, Apr 6, 2021 at 8:24 PM Simon Lees sflees@suse.de wrote:
On 4/6/21 5:59 PM, Sasi Olin wrote:
On Di, Apr 6, 2021 at 09:55, Lars Vogdt lrupp@suse.de wrote:
Let me vote for Nextcloud/Owncloud here:
- multiple groups can be created/administrated
- has a (public) calendar (another item on the ToDo list)
- could be used to provide all members a place for collaboration (files, images, cookbook, ...) - while I'm not sure if we should pay our members some MB space for their work?
- could even obsolete users.o.o directly
- ...
We could create a mail ticket system on pagure for membership submissions and obsolete connect right now, the much bigger problem is membership applications than keeping existing memberships.
Handling applications is actually the easy bit, we probably don't need anything more then a email template that you fill out and email to a mailing list. It is then streamlining the process of accepting the membership setting up the email / irc aliases if desired etc is probably what actually needs atleast a little work.
I still vote we do membership management in the login system because:
- that allows us to do login for members-only services global instead of
implementing the list of members per service
- we need to have our own login system for gdpr/foundation reasons
anyway (that was discussed during gdpr meeting last year)
I am not entirely convinced that "Need" is the right word here. Certainly SUSE Legal would prefer not to be responsible from a GDPR perspective, however there are other things at play here.
It would be exceptionally unwise for a "openSUSE Fountdation" to take ownership of user data unless as part of SUSE's sponsorship of openSUSE it covers these costs. To date as part of our foundation discussions we have always seen this as a possible future option but not something that would be done straight away but something that could be discussed later if both sides agree it would be beneficial given there are also significant technical challenges here that i'll get to in a minute.
Having said that it should be considerably cheaper for openSUSE to handle its GDPR then what it costs SUSE Legal, so if SUSE Legal really wants such a change it would be really helpful if they help us develop a business case and outline how the above would work to go to upper SUSE management to help push the foundation proposal forward.
Separation of account systems *must* happen before separation of legal entities anyway. It would be dumb to do a "trial-by-fire" for this particular thing as it could land both SUSE and openSUSE in a lot of hot water.
As I said earlier there were technical reasons which have been the main reason behind not looking at this during the formation of the foundation (It's also worth noting when we last had these serious discussions SUSE IT was still in the middle of a carve out). The main ones as you mention are obviously obs and bugzilla, data gets shared from the openSUSE obs instance to the internal one and as you are aware the bugzilla instance is the same.
What makes this problem genuinely hard is there are a number of SUSE employees such as myself who were members of the openSUSE community before joining SUSE, to make our lives easier generally we just continue using our "community" account inside SUSE and just have the SUSE Employee flag set. This means we don't need to constantly swap obs and bugzilla accounts based off whether we are dealing with a package we maintained before joining SUSE or one we maintain as a part of our role. Further to that if an employee leaves SUSE generally it doesn't mean that all there maintainership rights etc in obs should be removed that is generally left up to them.
So under this idea of two account systems does an employee such as myself end up with a "SUSE" account and a "Community" account if so which has access to what inside obs and how do you make sure that my bugs for community packages still get assigned to my SUSE account with access to security bugs because that is the bugzilla account i'll use.
Let's talk about the world where there are two account systems.
In this world, the openSUSE account system would be told to associate you with your SUSE Bugzilla account by means of you setting your SUSE Bugzilla email address override. This is already supported in the Noggin system that Sasi and I wish to deploy for openSUSE, and Fedora's instance uses it to allow people to override the email address used to link Fedora accounts to the Red Hat Bugzilla system. This situation has existed in Fedora for many years and has a solution built right into the platform that we can use.
Really if SUSE Legal no longer wants to be legally responsible for community data from a GDPR perspective they need to first work with the openSUSE community to help us establish a foundation that can hold the data and then need to work with SUSE IT and then the heroes to answer the above questions but really currently its still mostly SUSE IT's responsibility and if they come back to SUSE Legal and say yes we can do that but its going to cost $XXXXXX SUSE Legal might turn around and say well if the cost is that much its not worth the benefit and instead we will stick with the existing arrangement.
There are also other technical solutions to this problem that would address these issues in a far simpler manner. For example it maybe possible to have multiple IDP databases such that the employee database is on SUSE hardware and the community one is on foundation hardware, which would solve the GDPR issue from a legal perspective. The foundation could then have a "Service agreement" with SUSE IT to maintain the login system and make changes in a timely fashion. As part of its sponsorship of openSUSE the agreement could also state that SUSE will provide an employee already working on openSUSE to handle GDPR requests which would be much cheaper then SUSE Legal handling them and would mean that a foundation wouldn't have to deal with the risk of not having someone on the Heroes team in 10 years time who is willing to handle GDPR requests.
Two account systems are literally the expression of "multiple IDP databases". It's all LDAP on the backend. But realistically, we would not want more than a one-way trust from openSUSE to SUSE (where extra attributes are only on the SUSE side).
The reality is any change here will benefit SUSE the most so really they need to be the one driving the process. As a board member in the current state i'd be really hesitant for the Heroes to create yet another authentication system even if it could fix all the above issues without approval from SUSE Legal and SUSE IT because ultimately currently they are still responsible for the data. Without such agreement this would be one rare case where i'd see it as reasonable for the openSUSE Chairman to use there veto.
But as a result of all this I don't think that we can expect to have a separate account system in the near future and maybe its worth using an alternate system as an intermediate step.
The current situation is pretty bad. We have the broken Connect system, an IDP that isn't particularly nice for community usage, and people subtly saying that we need to be consulting with folks who never (figuratively) take our calls when we're trying to solve problems.
It's really easy to say that we can't/shouldn't do these things when you're not dealing with the consequences of that. Sasi and I deal with a lot of user support over the IDP, and the Connect system is an utter nightmare on its own. We spent *two years* funneling our own requirements into the design of Noggin so that we could have at least a decent starting point to replace this Byzantine system we have now.
If the openSUSE Chairman was going to veto us trying to fix this mess, then I would be pretty cheesed off, personally.
On 4/7/21 12:35 PM, Neal Gompa wrote:
On Tue, Apr 6, 2021 at 8:24 PM Simon Lees sflees@suse.de wrote:
On 4/6/21 5:59 PM, Sasi Olin wrote:
On Di, Apr 6, 2021 at 09:55, Lars Vogdt lrupp@suse.de wrote: I still vote we do membership management in the login system because:
- that allows us to do login for members-only services global instead of
implementing the list of members per service
- we need to have our own login system for gdpr/foundation reasons
anyway (that was discussed during gdpr meeting last year)
I am not entirely convinced that "Need" is the right word here. Certainly SUSE Legal would prefer not to be responsible from a GDPR perspective, however there are other things at play here.
It would be exceptionally unwise for a "openSUSE Fountdation" to take ownership of user data unless as part of SUSE's sponsorship of openSUSE it covers these costs. To date as part of our foundation discussions we have always seen this as a possible future option but not something that would be done straight away but something that could be discussed later if both sides agree it would be beneficial given there are also significant technical challenges here that i'll get to in a minute.
Having said that it should be considerably cheaper for openSUSE to handle its GDPR then what it costs SUSE Legal, so if SUSE Legal really wants such a change it would be really helpful if they help us develop a business case and outline how the above would work to go to upper SUSE management to help push the foundation proposal forward.
Separation of account systems *must* happen before separation of legal entities anyway. It would be dumb to do a "trial-by-fire" for this particular thing as it could land both SUSE and openSUSE in a lot of hot water.
This is simply not true, all our previous planning has been based around no separation which is actually simplest from a legal perspective. Currently the data is hosted on SUSE infrastructure and therefore is owned by SUSE from a GDPR perspective. With one account system just because we now have a foundation doesn't change that fact, the data would still be owned by SUSE.
As I outlined it is beneficial to SUSE to transfer that data to openSUSE as it greatly reduces there GDPR footprint and cost of dealing with GDPR. At the same time there are only two real things that could bankrupt or put a foundation in serious financial issues one is fines for failing to maintain adaquite bookwork the other is fines from failing to handle GDPR correctly, so if (not when) the foundation decides it would like to handle data it needs to be very careful about how it decides to do that to ensure that in 10-15 years time when things and volunteers have changed we still have the capability to properly handle GDPR requests. Atleast that is the legal advice we have to date.
It is also worth noting that to this point as part of creating a foundation there has been no plan to transfer any of the openSUSE Infrastructure currently owned by SUSE to a foundation. If we did go down that path then yes separating login systems and dealing with GDPR is something that we would look at. But again as part of foundation proposals we had no immediate plans to do anything but again if we work with SUSE here and its beneficial to transfer some hardware we can look at it into the future.
As I said earlier there were technical reasons which have been the main reason behind not looking at this during the formation of the foundation (It's also worth noting when we last had these serious discussions SUSE IT was still in the middle of a carve out). The main ones as you mention are obviously obs and bugzilla, data gets shared from the openSUSE obs instance to the internal one and as you are aware the bugzilla instance is the same.
What makes this problem genuinely hard is there are a number of SUSE employees such as myself who were members of the openSUSE community before joining SUSE, to make our lives easier generally we just continue using our "community" account inside SUSE and just have the SUSE Employee flag set. This means we don't need to constantly swap obs and bugzilla accounts based off whether we are dealing with a package we maintained before joining SUSE or one we maintain as a part of our role. Further to that if an employee leaves SUSE generally it doesn't mean that all there maintainership rights etc in obs should be removed that is generally left up to them.
So under this idea of two account systems does an employee such as myself end up with a "SUSE" account and a "Community" account if so which has access to what inside obs and how do you make sure that my bugs for community packages still get assigned to my SUSE account with access to security bugs because that is the bugzilla account i'll use.
Let's talk about the world where there are two account systems.
In this world, the openSUSE account system would be told to associate you with your SUSE Bugzilla account by means of you setting your SUSE Bugzilla email address override. This is already supported in the Noggin system that Sasi and I wish to deploy for openSUSE, and Fedora's instance uses it to allow people to override the email address used to link Fedora accounts to the Red Hat Bugzilla system. This situation has existed in Fedora for many years and has a solution built right into the platform that we can use.
Atleast this is now being better thought out and planned then the original you'll just need to log in everywhere twice and or swap between.
Really if SUSE Legal no longer wants to be legally responsible for community data from a GDPR perspective they need to first work with the openSUSE community to help us establish a foundation that can hold the data and then need to work with SUSE IT and then the heroes to answer the above questions but really currently its still mostly SUSE IT's responsibility and if they come back to SUSE Legal and say yes we can do that but its going to cost $XXXXXX SUSE Legal might turn around and say well if the cost is that much its not worth the benefit and instead we will stick with the existing arrangement.
There are also other technical solutions to this problem that would address these issues in a far simpler manner. For example it maybe possible to have multiple IDP databases such that the employee database is on SUSE hardware and the community one is on foundation hardware, which would solve the GDPR issue from a legal perspective. The foundation could then have a "Service agreement" with SUSE IT to maintain the login system and make changes in a timely fashion. As part of its sponsorship of openSUSE the agreement could also state that SUSE will provide an employee already working on openSUSE to handle GDPR requests which would be much cheaper then SUSE Legal handling them and would mean that a foundation wouldn't have to deal with the risk of not having someone on the Heroes team in 10 years time who is willing to handle GDPR requests.
Two account systems are literally the expression of "multiple IDP databases". It's all LDAP on the backend. But realistically, we would not want more than a one-way trust from openSUSE to SUSE (where extra attributes are only on the SUSE side).
The reality is any change here will benefit SUSE the most so really they need to be the one driving the process. As a board member in the current state i'd be really hesitant for the Heroes to create yet another authentication system even if it could fix all the above issues without approval from SUSE Legal and SUSE IT because ultimately currently they are still responsible for the data. Without such agreement this would be one rare case where i'd see it as reasonable for the openSUSE Chairman to use there veto.
But as a result of all this I don't think that we can expect to have a separate account system in the near future and maybe its worth using an alternate system as an intermediate step.
The current situation is pretty bad. We have the broken Connect system, an IDP that isn't particularly nice for community usage, and people subtly saying that we need to be consulting with folks who never (figuratively) take our calls when we're trying to solve problems.
Yeah I know the issues with the existing system especially connect (we have been trying to properly get rid of it since before I joined the board). At some point we as a board decided that connect.opensuse.org should no longer resolve and only people who really need it should be given access by an alternative means (IE those wanting to apply for membership and the membership committee). I guess this got reverted at some point.
It's really easy to say that we can't/shouldn't do these things when you're not dealing with the consequences of that. Sasi and I deal with a lot of user support over the IDP, and the Connect system is an utter nightmare on its own. We spent *two years* funneling our own requirements into the design of Noggin so that we could have at least a decent starting point to replace this Byzantine system we have now.
I am by no means saying don't do stuff (While i'm still not convinced about needing a 4th auth system to do my job). Just that it is wise to have all the right people onboard. The board could have initially helped in this area but we didn't find out about these plans until significant work and effort had already been invested.
If the openSUSE Chairman was going to veto us trying to fix this mess, then I would be pretty cheesed off, personally.
At the end of the day under current law SUSE is Legally responsible for all openSUSE's data under GDPR as such whenever the Heroes add a new service that stores any form of data SUSE should be comfortable with it and so id be expecting the Heroes to be running these things by the relevant people at SUSE prior to working on them so we don't end up in an awkward situation where SUSE has to tell the Heroes that you shouldn't be running that or no you can't do that. Mind you under the same reasoning I'm really supprised that SUSE hasn't invested the time and effort to migrate us away from connect because I suspect its a serious GDPR liability having it still running and at the end of the day thats there issue not openSUSE's (atleast from a GDPR perspective).
On Wed, Apr 7, 2021 at 1:11 AM Simon Lees sflees@suse.de wrote:
On 4/7/21 12:35 PM, Neal Gompa wrote:
On Tue, Apr 6, 2021 at 8:24 PM Simon Lees sflees@suse.de wrote:
On 4/6/21 5:59 PM, Sasi Olin wrote:
On Di, Apr 6, 2021 at 09:55, Lars Vogdt lrupp@suse.de wrote: I still vote we do membership management in the login system because:
- that allows us to do login for members-only services global instead of
implementing the list of members per service
- we need to have our own login system for gdpr/foundation reasons
anyway (that was discussed during gdpr meeting last year)
I am not entirely convinced that "Need" is the right word here. Certainly SUSE Legal would prefer not to be responsible from a GDPR perspective, however there are other things at play here.
It would be exceptionally unwise for a "openSUSE Fountdation" to take ownership of user data unless as part of SUSE's sponsorship of openSUSE it covers these costs. To date as part of our foundation discussions we have always seen this as a possible future option but not something that would be done straight away but something that could be discussed later if both sides agree it would be beneficial given there are also significant technical challenges here that i'll get to in a minute.
Having said that it should be considerably cheaper for openSUSE to handle its GDPR then what it costs SUSE Legal, so if SUSE Legal really wants such a change it would be really helpful if they help us develop a business case and outline how the above would work to go to upper SUSE management to help push the foundation proposal forward.
Separation of account systems *must* happen before separation of legal entities anyway. It would be dumb to do a "trial-by-fire" for this particular thing as it could land both SUSE and openSUSE in a lot of hot water.
This is simply not true, all our previous planning has been based around no separation which is actually simplest from a legal perspective. Currently the data is hosted on SUSE infrastructure and therefore is owned by SUSE from a GDPR perspective. With one account system just because we now have a foundation doesn't change that fact, the data would still be owned by SUSE.
As I outlined it is beneficial to SUSE to transfer that data to openSUSE as it greatly reduces there GDPR footprint and cost of dealing with GDPR. At the same time there are only two real things that could bankrupt or put a foundation in serious financial issues one is fines for failing to maintain adaquite bookwork the other is fines from failing to handle GDPR correctly, so if (not when) the foundation decides it would like to handle data it needs to be very careful about how it decides to do that to ensure that in 10-15 years time when things and volunteers have changed we still have the capability to properly handle GDPR requests. Atleast that is the legal advice we have to date.
It is also worth noting that to this point as part of creating a foundation there has been no plan to transfer any of the openSUSE Infrastructure currently owned by SUSE to a foundation. If we did go down that path then yes separating login systems and dealing with GDPR is something that we would look at. But again as part of foundation proposals we had no immediate plans to do anything but again if we work with SUSE here and its beneficial to transfer some hardware we can look at it into the future.
As I said earlier there were technical reasons which have been the main reason behind not looking at this during the formation of the foundation (It's also worth noting when we last had these serious discussions SUSE IT was still in the middle of a carve out). The main ones as you mention are obviously obs and bugzilla, data gets shared from the openSUSE obs instance to the internal one and as you are aware the bugzilla instance is the same.
What makes this problem genuinely hard is there are a number of SUSE employees such as myself who were members of the openSUSE community before joining SUSE, to make our lives easier generally we just continue using our "community" account inside SUSE and just have the SUSE Employee flag set. This means we don't need to constantly swap obs and bugzilla accounts based off whether we are dealing with a package we maintained before joining SUSE or one we maintain as a part of our role. Further to that if an employee leaves SUSE generally it doesn't mean that all there maintainership rights etc in obs should be removed that is generally left up to them.
So under this idea of two account systems does an employee such as myself end up with a "SUSE" account and a "Community" account if so which has access to what inside obs and how do you make sure that my bugs for community packages still get assigned to my SUSE account with access to security bugs because that is the bugzilla account i'll use.
Let's talk about the world where there are two account systems.
In this world, the openSUSE account system would be told to associate you with your SUSE Bugzilla account by means of you setting your SUSE Bugzilla email address override. This is already supported in the Noggin system that Sasi and I wish to deploy for openSUSE, and Fedora's instance uses it to allow people to override the email address used to link Fedora accounts to the Red Hat Bugzilla system. This situation has existed in Fedora for many years and has a solution built right into the platform that we can use.
Atleast this is now being better thought out and planned then the original you'll just need to log in everywhere twice and or swap between.
This was always in the plan for openSUSE Accounts. The other aspect of this was to have the SUSE Bugzilla support multi-provider SSO like the Red Hat Bugzilla does, so that whether you log in with SUSE or openSUSE account system, you'll get into Bugzilla and can go on your merry way.
Really if SUSE Legal no longer wants to be legally responsible for community data from a GDPR perspective they need to first work with the openSUSE community to help us establish a foundation that can hold the data and then need to work with SUSE IT and then the heroes to answer the above questions but really currently its still mostly SUSE IT's responsibility and if they come back to SUSE Legal and say yes we can do that but its going to cost $XXXXXX SUSE Legal might turn around and say well if the cost is that much its not worth the benefit and instead we will stick with the existing arrangement.
There are also other technical solutions to this problem that would address these issues in a far simpler manner. For example it maybe possible to have multiple IDP databases such that the employee database is on SUSE hardware and the community one is on foundation hardware, which would solve the GDPR issue from a legal perspective. The foundation could then have a "Service agreement" with SUSE IT to maintain the login system and make changes in a timely fashion. As part of its sponsorship of openSUSE the agreement could also state that SUSE will provide an employee already working on openSUSE to handle GDPR requests which would be much cheaper then SUSE Legal handling them and would mean that a foundation wouldn't have to deal with the risk of not having someone on the Heroes team in 10 years time who is willing to handle GDPR requests.
Two account systems are literally the expression of "multiple IDP databases". It's all LDAP on the backend. But realistically, we would not want more than a one-way trust from openSUSE to SUSE (where extra attributes are only on the SUSE side).
The reality is any change here will benefit SUSE the most so really they need to be the one driving the process. As a board member in the current state i'd be really hesitant for the Heroes to create yet another authentication system even if it could fix all the above issues without approval from SUSE Legal and SUSE IT because ultimately currently they are still responsible for the data. Without such agreement this would be one rare case where i'd see it as reasonable for the openSUSE Chairman to use there veto.
But as a result of all this I don't think that we can expect to have a separate account system in the near future and maybe its worth using an alternate system as an intermediate step.
The current situation is pretty bad. We have the broken Connect system, an IDP that isn't particularly nice for community usage, and people subtly saying that we need to be consulting with folks who never (figuratively) take our calls when we're trying to solve problems.
Yeah I know the issues with the existing system especially connect (we have been trying to properly get rid of it since before I joined the board). At some point we as a board decided that connect.opensuse.org should no longer resolve and only people who really need it should be given access by an alternative means (IE those wanting to apply for membership and the membership committee). I guess this got reverted at some point.
It's really easy to say that we can't/shouldn't do these things when you're not dealing with the consequences of that. Sasi and I deal with a lot of user support over the IDP, and the Connect system is an utter nightmare on its own. We spent *two years* funneling our own requirements into the design of Noggin so that we could have at least a decent starting point to replace this Byzantine system we have now.
I am by no means saying don't do stuff (While i'm still not convinced about needing a 4th auth system to do my job). Just that it is wise to have all the right people onboard. The board could have initially helped in this area but we didn't find out about these plans until significant work and effort had already been invested.
If the openSUSE Chairman was going to veto us trying to fix this mess, then I would be pretty cheesed off, personally.
At the end of the day under current law SUSE is Legally responsible for all openSUSE's data under GDPR as such whenever the Heroes add a new service that stores any form of data SUSE should be comfortable with it and so id be expecting the Heroes to be running these things by the relevant people at SUSE prior to working on them so we don't end up in an awkward situation where SUSE has to tell the Heroes that you shouldn't be running that or no you can't do that. Mind you under the same reasoning I'm really supprised that SUSE hasn't invested the time and effort to migrate us away from connect because I suspect its a serious GDPR liability having it still running and at the end of the day thats there issue not openSUSE's (atleast from a GDPR perspective).
Nothing we're planning or doing adds to the data we're already collecting, so I think we're fine there.
On 4/7/21 7:55 PM, Neal Gompa wrote:
On Wed, Apr 7, 2021 at 1:11 AM Simon Lees sflees@suse.de wrote:
On 4/7/21 12:35 PM, Neal Gompa wrote:
On Tue, Apr 6, 2021 at 8:24 PM Simon Lees sflees@suse.de wrote:
If the openSUSE Chairman was going to veto us trying to fix this mess, then I would be pretty cheesed off, personally.
At the end of the day under current law SUSE is Legally responsible for all openSUSE's data under GDPR as such whenever the Heroes add a new service that stores any form of data SUSE should be comfortable with it and so id be expecting the Heroes to be running these things by the relevant people at SUSE prior to working on them so we don't end up in an awkward situation where SUSE has to tell the Heroes that you shouldn't be running that or no you can't do that. Mind you under the same reasoning I'm really supprised that SUSE hasn't invested the time and effort to migrate us away from connect because I suspect its a serious GDPR liability having it still running and at the end of the day thats there issue not openSUSE's (atleast from a GDPR perspective).
Nothing we're planning or doing adds to the data we're already collecting, so I think we're fine there.
It's not just about the data we collect though, almost more important then that is the compliance officer feeling comfortable that they can locate and remove any users data should they receive a request to do so. If I was the data projection officer i'd be hesitant to leave this to a couple of people in the community becaues who knows if and where they'll be in 10 years things change after all. But on the other hand if there is a well documented process to handle this and the officer has access or knows they can contact someone with access (possibly an employee because they have the right to tell another employee you need to do this today, where as they don't for a community member) i'd start to see this as a non issue.
Please don't get me wrong i'm not trying to single out the new login system here, this is something we should be doing for any new infra we add that stores any form of user data. Not just for SUSE now but for the board of a future foundation to feel comfortable should we decide to transfer some of openSUSE's data to its ownership sometime in the future.
Cheers
On 23/02/2019 11:19, Christian Boltz wrote:
Hello,
[ I have about 50 unread mails in this discussion, so I might not have seen all relevant comment yet. One thing I noticed is that we have several volunteers. I'm really happy about that :-) Please forgive me for answering only to one of you ;-) ]
Am Freitag, 22. Februar 2019, 08:47:36 CET schrieb Ish Sookun:
On 2/22/19 1:22 AM, Vinzenz Vietzke wrote:
Came up twice already: take a Nextcloud, drop an LibreOffice Calc document there. It's not the shiny knight on a white horse solution but it should be enough to a) keep the membership committee working b) store the member's data safe c) get rid of this ugly spam dump called connect.o.o
Agreed. We start simple.
In a mail nearby, jdd asked the right question:
and why is a *cloud* storage needed to manage membership?Using nextcloud with a LibreOffice Calc document in it would be a bad idea IMHO. Not because my personal preference is ownCloud ;-) but because it makes things more complicated than necessary. For example, extracting the mail aliases out of a LibreOffice table would be a PITA, or in general, automating anything would be a PITA.
Depends on how you define PITA and simple but i'm not doing the work so I only care that its maintainable, for example you could export the spreadsheet to a CSV then it'd just take some basic commandline tools to split out the email address's
So let's start even more simple and less cloudy, please ;-)
If we go for "a table that can only be edited by the membership committee", then I'd propose to use a MySQL database + phpMyAdmin
The interface would look a bit more "technical", but not too different/ difficult, and it would have several advantages:
- extracting the mail aliases out of a database is boring and easy (much easier than extracting them from a binary[1] LibreOffice file)
- setting up the server is easy
- we could easily track changes, for example with a daily CSV export that gets auto-commited to a git repo (not a requirement for the initial implementation, just an idea for the future)
- if we setup a "request membership" form, writing to a database is much easier than writing to a LibreOffice document
The hard part is to convert the data from connect.o.o to the new database scheme. (I never looked at the database scheme used by connect.o.o, therefore I have no idea how hard this will be.)
Writing/updating the export scripts (for example for the mail aliases) is also some work, but not really hard.
I volunteer for this. Will check Heroes where I can set this up.
I'm happy to hear that :-)
Getting a VM (IMHO: for phpMyAdmin and an empty database) shouldn't be too hard ;-) Please write a mail to the heroes mailinglist to request it, and while on it, please also request access to the VPN and the connect.o.o database.
Until that setup is done, you can already start on the drawing board with stuff like "which columns will we need?" I know it sounds boring, but I'm also sure nobody will get this right on the first attemp ;-) On the positive side, adding a column later is easy, so don't worry too much.
On the other hand expecting all the membership officials to learn how to do direct database entry could be considered more of a PITA so please make sure there willing to learn if we go down this route.
On 2/22/19 11:27 PM, Simon Lees wrote:
On the other hand expecting all the membership officials to learn how to do direct database entry could be considered more of a PITA so please make sure there willing to learn if we go down this route.
I do not think that should be necessary, at all.
Simple forms, automated, should be all that is necessary.
Note that if it is MySQL, f.e., it can be secured, and can also be accessible across the infrastructure to the authorized individuals, and can allow real-time web access and generation for any future needs.
-
Axel Braun -
Carlos E. R. -
Christian Boltz -
Christian Imhorst -
christian.imhorst＠posteo.de -
Fraser_Bell -
Gerald Pfeifer -
hellcp＠opensuse.org -
Ish Sookun -
jdd＠dodin.org -
Knurpht-openSUSE -
Lars Vogdt -
Mathias Homann -
medwinz -
medwinz -
Michael Ströder -
Neal Gompa -
Per Jessen -
Per Jessen -
Richard Brown -
Sasi Olin
-
Simon Lees -
Vinzenz Vietzke