Mixed LDAP / local OBS users

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Mixed LDAP / local OBS users

Stefan Seyfried
Good morning,

after the update to 2.8.3, I found that local users (most prominent the Admin user ;)) no longer work, when LDAP mode is
enabled.

It was pretty easy to get the existing users to work again:

+++ app/models/user.rb  2017-09-20 06:45:18.666231345 +0000
@@ -199,7 +199,10 @@
   # in the database. Returns the user or nil if he could not be found
   def self.find_with_credentials(login, password)
     if CONFIG['ldap_mode'] == :on
-      return find_with_credentials_via_ldap(login, password)
+      user = find_with_credentials_via_ldap(login, password)
+      if user
+        return user
+      end
     end

     user = find_by_login(login)

This still does not enable me to create new users (as admin), because I'm just sent to the Sign Up page, which then
tells me that new users can only sign up via LDAP.

While looking to also fix that and let an admin allow to create (and edit) local users, I found that in git master many
more changes have been made to make this virtually impossible.

So I'm asking why this usecase is actively destroyed. Local OBS users (apart from the obvious Admin user) are useful
e.g. as technical accounts, for automation jobs etc. which are not always possible to get into a corporate user directory.

Thanks,
        Stefan
--
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Mixed LDAP / local OBS users

Björn Geuken
On 09/20/2017 09:05 AM, Stefan Seyfried wrote:
> Good morning,
>
> after the update to 2.8.3, I found that local users (most prominent the Admin user ;)) no longer work, when LDAP mode is
> enabled.
>

That's right. We've decided that in an OBS setup with LDAP enabled, the
user management should only happen via the LDAP instance.

Björn

> It was pretty easy to get the existing users to work again:
>
> +++ app/models/user.rb  2017-09-20 06:45:18.666231345 +0000
> @@ -199,7 +199,10 @@
>    # in the database. Returns the user or nil if he could not be found
>    def self.find_with_credentials(login, password)
>      if CONFIG['ldap_mode'] == :on
> -      return find_with_credentials_via_ldap(login, password)
> +      user = find_with_credentials_via_ldap(login, password)
> +      if user
> +        return user
> +      end
>      end
>
>      user = find_by_login(login)
>
> This still does not enable me to create new users (as admin), because I'm just sent to the Sign Up page, which then
> tells me that new users can only sign up via LDAP.
>
> While looking to also fix that and let an admin allow to create (and edit) local users, I found that in git master many
> more changes have been made to make this virtually impossible.
>
> So I'm asking why this usecase is actively destroyed. Local OBS users (apart from the obvious Admin user) are useful
> e.g. as technical accounts, for automation jobs etc. which are not always possible to get into a corporate user directory.
>
> Thanks,
> Stefan
>


--
Björn Geuken - Rails Developer - Open Build Service
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer,
HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Mixed LDAP / local OBS users

Stefan Seyfried
On 22.09.2017 08:22, Björn Geuken wrote:
> On 09/20/2017 09:05 AM, Stefan Seyfried wrote:
>> Good morning,
>>
>> after the update to 2.8.3, I found that local users (most prominent the Admin user ;)) no longer work, when LDAP mode is
>> enabled.
>>
>
> That's right. We've decided that in an OBS setup with LDAP enabled, the
> user management should only happen via the LDAP instance.

Well, that's nice that this was decided.

But that does throw away lots of useful usecases that -- even though the GUI elements were confusing before -- actually
did work.

One example is again the Admin account ;-)

And service users for automated jobs, which often are hard to get into a corporate Directory.

So might I ask to reconsider this decision?

> Björn
>
>> It was pretty easy to get the existing users to work again:
>>
>> +++ app/models/user.rb  2017-09-20 06:45:18.666231345 +0000
>> @@ -199,7 +199,10 @@
>>    # in the database. Returns the user or nil if he could not be found
>>    def self.find_with_credentials(login, password)
>>      if CONFIG['ldap_mode'] == :on
>> -      return find_with_credentials_via_ldap(login, password)
>> +      user = find_with_credentials_via_ldap(login, password)
>> +      if user
>> +        return user
>> +      end
>>      end
>>
>>      user = find_by_login(login)
>>
>> This still does not enable me to create new users (as admin), because I'm just sent to the Sign Up page, which then
>> tells me that new users can only sign up via LDAP.
>>
>> While looking to also fix that and let an admin allow to create (and edit) local users, I found that in git master many
>> more changes have been made to make this virtually impossible.
>>
>> So I'm asking why this usecase is actively destroyed. Local OBS users (apart from the obvious Admin user) are useful
>> e.g. as technical accounts, for automation jobs etc. which are not always possible to get into a corporate user directory.

--
Stefan Seyfried

"For a successful technology, reality must take precedence over
 public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Mixed LDAP / local OBS users

Carsten Höger
Hi,

> On 22. Sep 2017, at 17:17 , Stefan Seyfried <[hidden email]> wrote:
>
>>> after the update to 2.8.3, I found that local users (most prominent the Admin user ;)) no longer work, when LDAP mode is
>>> enabled.
>>>
>>
>> That's right. We've decided that in an OBS setup with LDAP enabled, the
>> user management should only happen via the LDAP instance.
>
> Well, that's nice that this was decided.
>
> But that does throw away lots of useful usecases that -- even though the GUI elements were confusing before -- actually
> did work.
>
> One example is again the Admin account ;-)
>
> And service users for automated jobs, which often are hard to get into a corporate Directory.
>
> So might I ask to reconsider this decision?
+1

Even worse: How can I do the initial bootstrapping of an obs system now?
As of now I created the initial obs configuration using

curl --insecure -0 --user 'Admin:<initialpw>' -X PUT -T /srv/obs/configuration-ox.xml https://buildservice.<domain>/configuration

How can I do that now?
Do we need to create an LDAP User with name Admin?

--

kind regards,
Carsten Hoeger
Professional Services



Email: [hidden email]


-----------------------------------------------------------------------------------------
Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein
Chairman of the Board: Richard Seibt

European Office:
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718
Managing Directors: Frank Hoberg, Martin Kauss

US Office:
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA
------------------------------------------------------------------------------------------


signature.asc (242 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mixed LDAP / local OBS users

Björn Geuken
In reply to this post by Stefan Seyfried


On 09/22/2017 05:17 PM, Stefan Seyfried wrote:

> On 22.09.2017 08:22, Björn Geuken wrote:
>> On 09/20/2017 09:05 AM, Stefan Seyfried wrote:
>>> Good morning,
>>>
>>> after the update to 2.8.3, I found that local users (most prominent the Admin user ;)) no longer work, when LDAP mode is
>>> enabled.
>>>
>>
>> That's right. We've decided that in an OBS setup with LDAP enabled, the
>> user management should only happen via the LDAP instance.
>
> Well, that's nice that this was decided.
>
> But that does throw away lots of useful usecases that -- even though the GUI elements were confusing before -- actually
> did work.
>
> One example is again the Admin account ;-)
>
> And service users for automated jobs, which often are hard to get into a corporate Directory.
>
> So might I ask to reconsider this decision?

Not my call. I can just say that this change was done intentionally:-)

Though, I should have mentioned earlier that we provided a script[*] to
give admin rights to user to handle such a situation:

   cd /srv/www/obs/api
   bundle exec rake user:give_admin_rights tux RAILS_ENV=production

Sorry for the late reply, I've overlooked this one. Seems my filter for
this list was messed up.

Björn

[*]
http://openbuildservice.org/help/manuals/obs-admin-guide/obs.cha.administration.html#_obs_ldap_configuration

>
>> Björn
>>
>>> It was pretty easy to get the existing users to work again:
>>>
>>> +++ app/models/user.rb  2017-09-20 06:45:18.666231345 +0000
>>> @@ -199,7 +199,10 @@
>>>     # in the database. Returns the user or nil if he could not be found
>>>     def self.find_with_credentials(login, password)
>>>       if CONFIG['ldap_mode'] == :on
>>> -      return find_with_credentials_via_ldap(login, password)
>>> +      user = find_with_credentials_via_ldap(login, password)
>>> +      if user
>>> +        return user
>>> +      end
>>>       end
>>>
>>>       user = find_by_login(login)
>>>
>>> This still does not enable me to create new users (as admin), because I'm just sent to the Sign Up page, which then
>>> tells me that new users can only sign up via LDAP.
>>>
>>> While looking to also fix that and let an admin allow to create (and edit) local users, I found that in git master many
>>> more changes have been made to make this virtually impossible.
>>>
>>> So I'm asking why this usecase is actively destroyed. Local OBS users (apart from the obvious Admin user) are useful
>>> e.g. as technical accounts, for automation jobs etc. which are not always possible to get into a corporate user directory.
>
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Mixed LDAP / local OBS users

Carsten Höger
Hi,

> On 16 November 2017 at 17:21 Bjoern Geuken <[hidden email]> wrote:

> >>> after the update to 2.8.3, I found that local users (most prominent the Admin user ;)) no longer work, when LDAP mode is
> >>> enabled.
> >>>
> >>
> >> That's right. We've decided that in an OBS setup with LDAP enabled, the
> >> user management should only happen via the LDAP instance.
> >
> > Well, that's nice that this was decided.
> >
> > But that does throw away lots of useful usecases that -- even though the GUI elements were confusing before -- actually
> > did work.
> >
> > One example is again the Admin account ;-)
> >
> > And service users for automated jobs, which often are hard to get into a corporate Directory.
> >
> > So might I ask to reconsider this decision?
>
> Not my call. I can just say that this change was done intentionally:-)
>
> Though, I should have mentioned earlier that we provided a script[*] to
> give admin rights to user to handle such a situation:
>
>    cd /srv/www/obs/api
>    bundle exec rake user:give_admin_rights tux RAILS_ENV=production
>
> Sorry for the late reply, I've overlooked this one. Seems my filter for
> this list was messed up.
>
> Björn
>
> [*]
> http://openbuildservice.org/help/manuals/obs-admin-guide/obs.cha.administration.html#_obs_ldap_configuration
Well, ok, but still we have a chicken-or-egg problem.

Given the use case that one wants to deploy obs using an automated deployment process.
The final step is, that you configure OBS:

curl --insecure -0 --user 'userwithadminrights:<initialpw>' -X PUT -T /srv/obs/configuration-ox.xml https://buildservice.<domain>/configuration

But since we do not yet have a user at this stage, this step is no longer possible.
Instead, the automated deployment must be interrupted, an ldap user must login - well, that could also be automated, but
that is really not nice -, and finally the deployment process can be finished.


Finally, there's still this Admin user in OBS. What purpose does that have now?
I did a login with my ldap account, assigned admin rights and ran the configuration curl command with success.

Do we now have to live with a non-functional account named Admin, or do we have to ask our ldap admins
to create a user called Admin??? That would really be unfortunate...



--

kind regards,
Carsten Hoeger
Professional Services



Email: [hidden email]


-------------------------------------------------------------------------------------
Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein
Chairman of the Board: Richard Seibt

European Office:
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718
Managing Directors: Frank Hoberg, Martin Kauss

US Office:
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA
-------------------------------------------------------------------------------------

Screen Shot 2017-11-17 at 9.32.43 .png (38K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mixed LDAP / local OBS users

Carsten Höger
In reply to this post by Stefan Seyfried
Hi,

> On 22 September 2017 at 17:17 Stefan Seyfried <[hidden email]> wrote:
>
>
> On 22.09.2017 08:22, Björn Geuken wrote:
> > On 09/20/2017 09:05 AM, Stefan Seyfried wrote:
> >> Good morning,
> >>
> >> after the update to 2.8.3, I found that local users (most prominent the Admin user ;)) no longer work, when LDAP mode is
> >> enabled.
> >>
> >
> > That's right. We've decided that in an OBS setup with LDAP enabled, the
> > user management should only happen via the LDAP instance.
>
> Well, that's nice that this was decided.
>
> But that does throw away lots of useful usecases that -- even though the GUI elements were confusing before -- actually
> did work.
>
> One example is again the Admin account ;-)
>
> And service users for automated jobs, which often are hard to get into a corporate Directory.
>
> So might I ask to reconsider this decision?

I now opened an issue for that:

https://github.com/openSUSE/open-build-service/issues/4147

--

kind regards,
Carsten Hoeger
Professional Services



Email: [hidden email]


-------------------------------------------------------------------------------------
Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein
Chairman of the Board: Richard Seibt

European Office:
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718
Managing Directors: Frank Hoberg, Martin Kauss

US Office:
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA
-------------------------------------------------------------------------------------
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]