Hi Stephan,

I tried the thing that you told me, I also tried looking into other things. My 
endpoint is correct since i can see my requests in the logs of the host on 
which the scheduler is running. My cluster is in AWS. The scheduler logs still 
show the following:


W1013 01:51:10.278 [HttpServerLauncher STARTING, Stats:181] Re-using already 
registered variable for key shiro_authorization_failures
W1013 01:51:10.302 [HttpServerLauncher STARTING, IniRealm:139] Users or Roles 
are already populated.  Configured Ini instance will be ignored.
W1013 01:51:10.313 [HttpServerLauncher STARTING, DefaultWebSecurityManager:173] 
The org.apache.shiro.web.mgt.DefaultWebSecurityManager implementation expects 
SessionManager instances that implement the 
org.apache.shiro.web.session.mgt.WebSessionManager interface.  The configured 
instance is of type [org.apache.shiro.session.mgt.DefaultSessionManager] which 
does not implement this interface..  This may cause unexpected behavior.
W1013 01:51:10.333 [HttpServerLauncher STARTING, IniRealm:139] Users or Roles 
are already populated.  Configured Ini instance will be ignored.
W1013 01:51:10.347 [HttpServerLauncher STARTING, IniRealm:139] Users or Roles 
are already populated.  Configured Ini instance will be ignored.
W1013 01:51:10.351 [HttpServerLauncher STARTING, DefaultWebSecurityManager:173] 
The org.apache.shiro.web.mgt.DefaultWebSecurityManager implementation expects 
SessionManager instances that implement the 
org.apache.shiro.web.session.mgt.WebSessionManager interface.  The configured 
instance is of type [org.apache.shiro.session.mgt.DefaultSessionManager] which 
does not implement this interface..  This may cause unexpected behavior.
W1013 01:51:10.362 [HttpServerLauncher STARTING, IniRealm:139] Users or Roles 
are already populated.  Configured Ini instance will be ignored.


If you want I can send you my entire aurora configuration. Would that give you 
more insight into what the root cause might be?


Best Regards,

Jatan Ajmera

________________________________
From: Erb, Stephan <stephan....@blue-yonder.com>
Sent: Monday, October 17, 2016 6:25:20 AM
To: user@aurora.apache.org
Subject: Re: Aurora HTTP BA Issues

I have tested those settings in the Aurora vagrant box and they work for me. I 
still get the obscure scheduler log messages, but the client authentication 
works.

The only thing I can think of right now: Maybe the endpoint you put into the 
netrc file is not correct?  If your client fails with “401 Client Error: 
Unauthorized for url: http://aurora.local:8081/api” you have to put “machine 
aurora.local” into the netrc file.

Best Regards,
Stephan

From: "Ajmera, Jatan" <jajm...@ea.com>
Reply-To: "user@aurora.apache.org" <user@aurora.apache.org>
Date: Sunday 16 October 2016 at 20:04
To: "user@aurora.apache.org" <user@aurora.apache.org>
Subject: Re: Aurora HTTP BA Issues


Hi Stephan,

I am sending you the configuration of the scheduler and the ~/.netrc file that 
I have on my ubuntu box. It matches that of the documentation, but still 
wouldn't allow my to schedule jobs via the CLI.



-http_authentication_mechanism=BASIC

-shiro_realm_modules=INI_AUTHNZ

-shiro_ini_path=/etc/auroara/security.ini
 And the ini file is



[users]

jatan = apple, admin



[roles]

admin = *
 And my ~/.netrc file is :



machine endpoint.of.scheduler.com

login jatan

password apple



Hope this helps you reproduce the errors.



Thanks,

Jatan Ajmera

________________________________
From: Stephan Erb <s...@apache.org>
Sent: Sunday, October 16, 2016 10:37:07 AM
To: user@aurora.apache.org
Subject: Re: Aurora HTTP BA Issues

Yeah, see 
https://github.com/apache/aurora/blob/master/docs/operations/security.md#http-basic-authentication

On So, 2016-10-16 at 10:26 -0700, David McLaughlin wrote:
I *just* seen that in the e2e test. Have we documented that anywhere?

On Sun, Oct 16, 2016 at 10:24 AM, Stephan Erb 
<s...@apache.org<mailto:s...@apache.org>> wrote:

By default we should be using the fallback implementation of the
requests Python module: http://docs.python-requests.org/en/master/user/
authentication/#netrc-authentication<http://docs.python-requests.org/en/master/user/authentication/#netrc-authentication>

So just adding ~/.netrc file should therefore be sufficient to pass
credentials via basic auth.



On So, 2016-10-16 at 10:07 -0700, David McLaughlin wrote:
> I noticed this while I was reviewing the patch to add cookies - I
> couldn't find any HTTP basic auth support in the client. We'd need a
> patch to wire that up (with some method of getting the user
> credentials).
>
> I think this confirms my concern about adding auth support on only
> one side of the CLI/Scheduler :)
>
> On Sun, Oct 16, 2016 at 9:46 AM, Stephan Erb 
> <s...@apache.org<mailto:s...@apache.org>> wrote:
> > Hi,
> >
> > would it be possible to show us your relevant scheduler
> > configuration and your ini file?  This will make it easier to
> > reproduce the issue.
> >
> > Thanks,
> > Stephan
> >
> > On Do, 2016-10-13 at 17:58 +0000, Ajmera, Jatan wrote:
> > > Hi,
> > > I was previously communicating about this issue on the slack
> > > channel sometime back. I am having troubles when i am trying to
> > > configure the HTTP Basic Auth for my aurora scheduler on my Mesos
> > > Cluster. I have configured the necessary flags at deploy time
> > > along with the other flags and have checked the ini file and made
> > > sure it had the right permissions as well. The logs I see on the
> > > master where the scheduler is running are as follows:
> > >
> > > 80006, negotiated timeout = 4000
> > > I1013 01:51:09.751 [RedirectMonitor STARTING,
> > > ServerSetImpl$ServerSetWatcher:317] received initial membership
> > > [ServiceInstance(serviceEndpoint:Endpoint(host:ec2-54-244-159-
> > > 201.us-west-2.compute.amazonaws.com<http://201.us-west-2.compute.amazonaws.com>,
> > >  port:8081),
> > > additionalEndpoints:{http=Endpoint(host:ec2-54-244-159-201.us-
> > > west-2.compute.amazonaws.com<http://west-2.compute.amazonaws.com>, 
> > > port:8081)}, status:ALIVE)]
> > > I1013 01:51:09.765 [HttpServerLauncher STARTING, Server:345]
> > > jetty-9.3.11.v20160721
> > > W1013 01:51:10.278 [HttpServerLauncher STARTING, Stats:181] Re-
> > > using already registered variable for key
> > > shiro_authorization_failures
> > > W1013 01:51:10.302 [HttpServerLauncher STARTING, IniRealm:139]
> > > Users or Roles are already populated.  Configured Ini instance
> > > will be ignored.
> > > W1013 01:51:10.313 [HttpServerLauncher STARTING,
> > > DefaultWebSecurityManager:173] The
> > > org.apache.shiro.web.mgt.DefaultWebSecurityManager implementation
> > > expects SessionManager instances that implement the
> > > org.apache.shiro.web.session.mgt.WebSessionManager interface.
> > > The configured instance is of type
> > > [org.apache.shiro.session.mgt.DefaultSessionManager] which does
> > > not implement this interface..  This may cause unexpected
> > > behavior.
> > > W1013 01:51:10.333 [HttpServerLauncher STARTING, IniRealm:139]
> > > Users or Roles are already populated.  Configured Ini instance
> > > will be ignored.
> > > W1013 01:51:10.347 [HttpServerLauncher STARTING, IniRealm:139]
> > > Users or Roles are already populated.  Configured Ini instance
> > > will be ignored.
> > > W1013 01:51:10.351 [HttpServerLauncher STARTING,
> > > DefaultWebSecurityManager:173] The
> > > org.apache.shiro.web.mgt.DefaultWebSecurityManager implementation
> > > expects SessionManager instances that implement the
> > > org.apache.shiro.web.session.mgt.WebSessionManager interface.
> > > The configured instance is of type
> > > [org.apache.shiro.session.mgt.DefaultSessionManager] which does
> > > not implement this interface..  This may cause unexpected
> > > behavior.
> > > W1013 01:51:10.362 [HttpServerLauncher STARTING, IniRealm:139]
> > > Users or Roles are already populated.  Configured Ini instance
> > > will be ignored.
> > >
> > > And when i try to connect through the client i get a 401 Client
> > > Error:Unauthorized. It would be really appreciated if you could
> > > help me figure this out. Also what would be a good approach to
> > > secure communication from the client to the scheduler.
> > >
> > > Thanks,
> > >
> >
>


Reply via email to