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 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, > > > > > >
