Re: [OpenStack-Infra] Infra Shanghai PTG Recap

[Jimmy Mcarthur]

Just to add a bit to this...

Clark Boylan wrote:

We also talked about translation services as Zanata is no longer supported. The 
i18n team is interested in using weblate, we (probably me?) need to reach out 
to the weblate team to see if hosting an open source project the size of 
openstack is outside of their scope for their normal open source hosting. If it 
is then we can work with the OSF to see if using the paid hosting platform for 
weblate is viable. If not we also have the option of possibly hosting our own 
weblate.
Apparently Fedora already moved to weblate and did so through some kind 
of sponsorship/partnership.  I've raised this flag already with OSF 
staff, though I think I misheard weblate as "Red Plate", I think I got 
the gist across.  Basically Fedora was able to dedicate some time and 
resources to help move the project forward. As a result, weblate is 
helping Fedora get set up. So far, they've been working on it for a 
year.  i18n has asked OSF to reach out to weblate to see if we can do 
some in-kind exchange as well so they can help us with the transition.  
Ian Choi estimated it would take 2 years to completely transition from 
Zanata to weblate.  I have no idea the scope of that move, so I can't 
speak to that estimate.



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] ask.openstack.org down for some days

[Jimmy McArthur]

Typically we give a cry for help and people pay attention and start
moderating again for a month or so. Then it falls off of people’s
radar again. The site needs massive improvements: better spam
filtering, smarter suggestion engine to discourage duplicate posts,
better tagging and search, etc... most questions go unanswered or
unmoderated for months.

I’d love it if someone took up that task, but I fear it won’t happen.
Ifwecant find a champion, I believe we should think about winding down
the service. In its current state it’s doing more harm than good.

Thanks,
Jimmy

> On Nov 9, 2019, at 7:06 PM, Bernd Bausch  wrote:
>
> Yes, I guess it's still useful. Traffic is not very high, perhaps 5 
> questions a day (if there are logs, it should be easy to confirm this), both 
> from absolute beginners and advanced users.
>
> No idea what time and skill is required to maintain an Askbot site, but I am 
> certainly curious.
>
> Bernd.
>
>> On 2019/11/10 2:07 AM, Jeremy Stanley wrote:
>> For some reason Apache has been failing to restart during daily log
>> rotation all week. I've manually started it again. Most of the
>> sysadmins have been busy with other things in Shanghai (myself
>> included), but I had a few free minutes on a layover just now.
>>
>> It's worth keeping in mind that the ask.openstack.org site has
>> basically been unmaintained for years, ever since the AskBot
>> maintainer OSF was contracting to run it disappeared. If folks are
>> still finding the service useful, then we probably need to have a
>> conversation about finding a maintainer for it.
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] How can I have access to OpenStack source code?

[Jimmy Mcarthur]

Another good resource is: https://www.openstack.org/software/start/

Cheers,
Jimmy


Jeremy Stanley 
August 7, 2019 at 4:42 PM

Assuming you're looking at https://www.openstack.org/ when you refer
to the site, at the top you should see a drop-down which says
"Software" and if you click on that (or expand it and select
"Overview") then the Software page has a link near the top for
"Source Code" which should get you the list of sources for the
latest release.
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
jalali.h 
August 7, 2019 at 9:23 AM
Hello,

We are developing our systems based on AWS. We are studying other 
clouds beacause costs of AWS.
Im interested to OpenStack. According to your website, OpenStack is an 
open source software but I couldnt find its source. Where can I find 
its source?


Thanks,
Reza



.
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Proposed changes to how we run our meeting

[Jimmy Mcarthur]

Clark Boylan 
November 18, 2018 at 1:09 PM
Hello everyone,

In Berlin there was a forum session on dealing with timezones and 
language barriers. There were a couple related ideas that came out of 
that session. In particular that having meetings only when there is a 
strong agenda helps people avoid staying up all night for nothing and 
that listing an agenda ahead of time can help non english speakers 
better prepare for the meeting.
This is a GREAT idea.  Not just for English speakers, but for everyone. 
I'm a big fan of not having meetings just to fill time.


Both ideas seem sound to me and I think we should try to implement 
them for the Infra team. I propose that we require agenda updates 24 
hours prior to the meeting start time and if there are no agenda 
updates we cancel the meeting. Curious to hear if others think this 
will be helpful and if 24 hours is enough lead time to be helpful.
Love the 24 hour lead time. Looking forward to seeing how this works and 
hope it can be adopted across other projects.


We'll have our meeting this Tuesday (with this item on the agenda), 
but it would probably also be good to use the mailing list for 
feedback as I think that gives us a broader set of potential feedback.


Thanks for taking the lead on this Clark!  Nice work :)


Thank you,
Clark

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [openstack-dev] Zuul memory improvements

[Jimmy McArthur]

Congrats on the improvements, Jim! Sounds like this is going to make a 
huge difference.  Go Zuul!


Cheers,
Jimmy




James E. Blair 
April 30, 2018 at 10:03 AM
Hi,

We recently made some changes to Zuul which you may want to know about
if you interact with a large number of projects.

Previously, each change to Zuul which updated Zuul's configuration
(e.g., a change to a project's zuul.yaml file) would consume a
significant amount of memory. If we had too many of these in the queue
at a time, the server would run out of RAM. To mitigate this, we asked
folks who regularly submit large numbers of configuration changes to
only submit a few at a time.

We have updated Zuul so it now caches much more of its configuration,
and the cost in memory of an additional configuration change is very
small. An added bonus: they are computed more quickly as well.

Of course, there's still a cost to every change pushed up to Gerrit --
each one uses test nodes, for instance, so if you need to make a large
number of changes, please do consider the impact to the whole system and
other users. However, there's no longer a need to severely restrict
configuration changes as a class -- consider them as any other change.

-Jim

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Asking for comments on translate-dev.o.o auth table mismatch

[Jimmy McArthur]

On Jan 10, 2018, at 6:05 PM, Patrick Huang  wrote:

Not only the password mismatch. The problem is username (among other
things, e.g. the identifier url, name and email, are returned from
openstackId authentication and can be changed by user then saved to Zanata)
has to be unique in Zanata. Since the identifier values come from two
different providers (openstackid and openstackid dev), Zanata will consider
they are two different users. Therefore for the same person, he would have
two users in Zanata with different username. The idea here is to remove the
obsolete user already in the database. Now the new propose is to start with
a fresh database which I think it's much easier.


+1


Regards,
Patrick

On Thu, Jan 11, 2018 at 8:16 AM, Jimmy McArthur  wrote:

> Technically those affected users could just update their password on both
> the OpenStackID production and dev sites. Then the problem would be solved.
> I can’t imagine we are talking about that many people that have changed
> their passwords?
>
> Thanks,
> Jimmy McArthur 
> 512.965.4846 <(512)%20965-4846>
>
>
> On Jan 10, 2018, at 3:48 PM, Alex Eng  wrote:
>
> According to his comment, it would be nice if Zanata manages openid full
>> url by separating
>> into domain part (e.g., "openstackid.org") and rest part (e.g., "/...").
>> @Patrick, would it be possible to support in Zanata
>> as a new feature?
>
>
> As much as I would like to solve issue asap, I don't think this is the
> right solution.
> It is best to handle the URL changes through a script or the jboss-cli.
>
> On Thu, Jan 11, 2018 at 2:08 AM, Ian Y. Choi  wrote:
>
>> Hello,
>>
>> I would like to update this (sorry for my late sharing on this mailing
>> list and infra team):
>>
>> - Jimmy commented on the Etherpad on Dec 13.
>>
>> According to his comment, it would be nice if Zanata manages openid full
>> url by separating
>> into domain part (e.g., "openstackid.org") and rest part (e.g., "/...").
>> @Patrick, would it be possible to support in Zanata
>> as a new feature?
>>
>> By the way, I18n team decided to have another approach: freshing database
>> used in translate-dev.openstack.org,
>> which would address current openstackid issues and I18n PTL proposed
>> https://review.openstack.org/#/c/531736/ .
>> It would be so nice if the patch gets more attention from system-config
>> cores.
>>
>>
>> With many thanks,
>>
>> /Ian
>>
>> Patrick Huang wrote on 12/6/2017 11:03 AM:
>>
>>> I've put my comments in the etherpad.
>>>
>>> On Wed, Dec 6, 2017 at 11:19 AM, Ian Y. Choi >> <mailto:ianyrc...@gmail.com>> wrote:
>>>
>>> Hello,
>>>
>>> Since Zanata upgrade to 4.3.1 on translate-dev.openstack.org
>>> <http://translate-dev.openstack.org> is going well [1],
>>> I think it is a good time to discuss translate-dev.o.o
>>> authentication problems.
>>>
>>> I wrote a brief current problem on authentication issues in
>>> translate-dev.o.o and my suggestion on proposed solution
>>> :
>>> https://etherpad.openstack.org/p/translate-dev-openstackid-issues
>>> <https://etherpad.openstack.org/p/translate-dev-openstackid-issues>
>>> .
>>>
>>> Clark looked at this proposal and said that it looked good
>>> previously.
>>> It would be so nice if infra team, openstackid developers, I18n
>>> PTL, and Zanata development team
>>> would be in same pages.
>>>
>>> In my opinion we can discuss more on for example:
>>> - openstackid developers: How the sync between openstackid-dev and
>>> openstackid databases is accomplished
>>>   (regarding password mismatch)
>>> - Sharing Zanata auth table structure from Zanata development team
>>> would be nice.
>>>
>>>
>>> With many thanks,
>>>
>>> /Ian
>>>
>>> [1] https://storyboard.openstack.org/#!/story/2001362
>>> <https://storyboard.openstack.org/#%21/story/2001362>
>>>
>>>
>>>
>>>
>>> --
>>> Patrick Huang
>>> Senior Software Engineer
>>> Engineering - Internationalisation
>>> Red Hat, Asia-Pacific Pty Ltd
>>> Level 1, 193 North Quay
>>> <https://maps.google.com/?q=193+North+Quay+%0D+Brisbane+4000+%0D+Office:+%2B61&entry=gmail&source=g>
>>> Bri

Re: [OpenStack-Infra] Asking for comments on translate-dev.o.o auth table mismatch

[Jimmy McArthur]

Technically those affected users could just update their password on both the 
OpenStackID production and dev sites. Then the problem would be solved. I can’t 
imagine we are talking about that many people that have changed their passwords?

Thanks,
Jimmy McArthur 
512.965.4846


On Jan 10, 2018, at 3:48 PM, Alex Eng  wrote:

>> According to his comment, it would be nice if Zanata manages openid full url 
>> by separating
>> into domain part (e.g., "openstackid.org") and rest part (e.g., "/..."). 
>> @Patrick, would it be possible to support in Zanata
>> as a new feature?
>  
> As much as I would like to solve issue asap, I don't think this is the right 
> solution. 
> It is best to handle the URL changes through a script or the jboss-cli.
> 
>> On Thu, Jan 11, 2018 at 2:08 AM, Ian Y. Choi  wrote:
>> Hello,
>> 
>> I would like to update this (sorry for my late sharing on this mailing list 
>> and infra team):
>> 
>> - Jimmy commented on the Etherpad on Dec 13.
>> 
>> According to his comment, it would be nice if Zanata manages openid full url 
>> by separating
>> into domain part (e.g., "openstackid.org") and rest part (e.g., "/..."). 
>> @Patrick, would it be possible to support in Zanata
>> as a new feature?
>> 
>> By the way, I18n team decided to have another approach: freshing database 
>> used in translate-dev.openstack.org,
>> which would address current openstackid issues and I18n PTL proposed 
>> https://review.openstack.org/#/c/531736/ .
>> It would be so nice if the patch gets more attention from system-config 
>> cores.
>> 
>> 
>> With many thanks,
>> 
>> /Ian
>> 
>> Patrick Huang wrote on 12/6/2017 11:03 AM:
>>> I've put my comments in the etherpad.
>>> 
>>> On Wed, Dec 6, 2017 at 11:19 AM, Ian Y. Choi >> <mailto:ianyrc...@gmail.com>> wrote:
>>> 
>>> Hello,
>>> 
>>> Since Zanata upgrade to 4.3.1 on translate-dev.openstack.org
>>> <http://translate-dev.openstack.org> is going well [1],
>>> I think it is a good time to discuss translate-dev.o.o
>>> authentication problems.
>>> 
>>> I wrote a brief current problem on authentication issues in
>>> translate-dev.o.o and my suggestion on proposed solution
>>> :
>>> https://etherpad.openstack.org/p/translate-dev-openstackid-issues
>>> <https://etherpad.openstack.org/p/translate-dev-openstackid-issues> .
>>> 
>>> Clark looked at this proposal and said that it looked good previously.
>>> It would be so nice if infra team, openstackid developers, I18n
>>> PTL, and Zanata development team
>>> would be in same pages.
>>> 
>>> In my opinion we can discuss more on for example:
>>> - openstackid developers: How the sync between openstackid-dev and
>>> openstackid databases is accomplished
>>>   (regarding password mismatch)
>>> - Sharing Zanata auth table structure from Zanata development team
>>> would be nice.
>>> 
>>> 
>>> With many thanks,
>>> 
>>> /Ian
>>> 
>>> [1] https://storyboard.openstack.org/#!/story/2001362
>>> <https://storyboard.openstack.org/#%21/story/2001362>
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Patrick Huang
>>> Senior Software Engineer
>>> Engineering - Internationalisation
>>> Red Hat, Asia-Pacific Pty Ltd
>>> Level 1, 193 North Quay
>>> Brisbane 4000
>>> Office: +61 7 3514 8278
>>> Fax: +61 7 3514 8199
>>> IRC: pahuang
>>> github: github.com/huangp <http://github.com/huangp>
>>> Website: www.redhat.com <http://www.redhat.com>
>> 
>> 
> 
> 
> 
> -- 
> ALEX ENG
> ASSOCIATE MANAGER
> GLOBALIZATION TOOLING, CUSTOMER PLATFORM
> Red Hat Inc
> 193 North Quay, Brisbane City QLD 4000
> alex@redhat.comM: 0423353457 IM: aeng
> 
> 
> 
> 
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Zuul mailing lists

[Jimmy Mcarthur]

Jeremy Stanley wrote:

I'd go further and credit it with much of the unnecessary perceived
division between developers and operators in the OpenStack
community. The proposal sounds great.
-- Jeremy Stanley

+1
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Pholio Spec 340641

[Jimmy Mcarthur]

The logs are showing your .com.au address. So my guess is the 
configuration problem is there. I do see an OpenStackID for 
cra...@mcwhirter.io, but it appears that's not the credentials being 
passed here:


 [2016-08-25 06:00:52] dev.WARNING: * CheckPointService - exception :<<
   Authentication Exception : member craige mcwhirter com au does not exists!
   >>  - IP Address: 101.162.51.242 [] []
   i verified db and its true your user does not exists
   are you trying to get log with that user?


Jimmy

Craige McWhirter 
August 25, 2016 at 7:36 PM

...and I discover that my "From:" is being re-written outbound. I use the
address cra...@mcwhirter.io for OpenStackID.

--
Craige McWhirter
M: +61 4685 91819
W: https://mcwhirter.com.au/
GNUSocial: https://social.mcwhirter.io/craige
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Craige McWhirter 
August 25, 2016 at 7:29 PM
On Thu, Aug 25, 2016 at 08:43:25AM -0300, Sebastian Marcet wrote:

Craige
all i see on production environment
is this exception
[2016-08-25 06:00:52] dev.WARNING: * CheckPointService - exception :<<
Authentication Exception : member craige mcwhirter com au does not exists!
>>  - IP Address: 101.162.51.242 [] []
i verified db and its true your user does not exists
are you trying to get log with that user?


No, I'm using the address this email is from. I did use that one initially as
it was the address I once used. I have since been using this address.


lets try to test with production env for now 
also lets try a minimal config for the mod_auth_openid

AuthType OpenID
require valid-user
AuthOpenIDSingleIdP [1]https://openstackid.org/



Switched back to this original configuration. Unfortunately, no love.


also which is the flow that are u seeing ( in the case that you are using
a valid user )
should be somehting like that:
you got redirect to [2]https://openstackid.org/accounts/user/login


I get to this OK. I enter my valid, current credentials but do not reach the
next stage in your work flow. Phabricator reports "There has been an error
while attempting to authenticate." and prompts me to choose another provider.


enter your credentials, and if they are valid
then you should get this url
[3]https://openstackid.org/accounts/user/consent
and after your consent you should be redirected to you origin domain
in case that you dont have any valid account on production site
please create one here
[4]https://www.openstack.org/join/register
let me know


I'm currently trying to work out what Phabricator thinks the actual problem is.
If you have any clues from the OpenStackID side, they'd be greatly appreciated.

--
Craige McWhirter
M: +61 4685 91819
W: https://mcwhirter.com.au/
GNUSocial: https://social.mcwhirter.io/craige
Sebastian Marcet 
August 25, 2016 at 6:43 AM
Craige
all i see on production environment
is this exception

[2016-08-25 06:00:52] dev.WARNING: * CheckPointService - exception : 
<< Authentication Exception : member craige mcwhirter com au does not 
exists! >> - IP Address: 101.162.51.242 [] []


i verified db and its true your user does not exists

are you trying to get log with that user?

lets try to test with production env for now 

also lets try a minimal config for the mod_auth_openid


AuthType OpenID
require valid-user
AuthOpenIDSingleIdP https://openstackid.org/


also which is the flow that are u seeing ( in the case that you are 
using a valid user )

should be somehting like that:
you got redirect to https://openstackid.org/accounts/user/login
enter your credentials, and if they are valid
then you should get this url
https://openstackid.org/accounts/user/consent
and after your consent you should be redirected to you origin domain

in case that you dont have any valid account on production site
please create one here

https://www.openstack.org/join/register

let me know

regards

Sebastian









Craige McWhirter 
August 25, 2016 at 1:44 AM

I switched to using a hostname with a valid TLD and I can now get to both
OpenStackID and -dev, so yay, much progress there.

However that's where it comes to halt.

I do not have an account on OpenStackID-dev and all links to create 
one / reset

password take me to OpenStackID.

My attempt to login via OpenStackID returns:

"There has been an error while attempting to authenticate."

I'm currently using a config that is, apart form the URLs, precisely 
what you

recommended.

Anything interesting in the logs on your end?

Thanks again Sebastian!

--
Craige McWhirter
M: +61 4685 91819
W: https://mcwhirter.com.au/
GNUSocial: https://social.mcwhirter.io/craige
Sebastian Marcet 

Re: [OpenStack-Infra] A tool for slurping gerrit changes in to bug updates

[Jimmy Mcarthur]

I'm not sure about Infra, but we're in the same boat with one of our bug 
trackers. This would be awesome to have and I'm sure we would use it.


Out of curiosity, what bug tracker are you currently using?

Cheers,
Jimmy

Gregory Haynes wrote:

Hello -Infra folks,

While setting up an OpenStack-infra style testing infrastructure we have
run in to the need for a tool to update our issue tracker in a different
manner than the current Gerrit ->  jeepyb system used for OpenStack. Our
issue boils down to the fact that our bug tracker lives on a network our
Gerrit cannot initiate a connection in to. As a result we need something
to connect to Gerrit from within our bug tracker's network. We are
considering making a small project to connect to and read from the
Gerrit event stream and then update our bug tracker.


My hope with this email was to see if:

Is there something (aside from not having crazy network requirements)
were missing that might make this project unnecessary?

If we implemented this, would this be something the -infra project would
like to have live upstream? It seems easy enough to make this generally
useful to others with similar requirements.

Any other thoughts/comments that might help :).

Thanks,
Greg




___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Session expired on openstack.org account creation

[Jimmy Mcarthur]

OK - thank you for the report. If you continue to have problems, please 
don't hesitate to email me directly.


Cheers!
Jimmy

Pavel Gluschak wrote:

No, I tried following link:
https://www.openstack.org/join/register/?membership-type=foundation

But now registration process works for me. Thanks.

On Wed, Apr 6, 2016 at 6:15 PM, Jimmy Mcarthur <mailto:ji...@tipit.net>> wrote:


Pavel,

To be clear, you're trying to create an account here:
https://www.openstack.org/join/register/#community

    Thanks!
Jimmy McArthur
OpenStack Foundation

Pavel Gluschak wrote:

Hello,

I've been trying to set up Openstack membership account, but
keep getting error "Your Session has expired!."
Does it work?

-- 
Kind regards,

Pavel Gluschak
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
<mailto:OpenStack-Infra@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra





--
Kind regards,
Pavel Gluschak


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Session expired on openstack.org account creation

[Jimmy Mcarthur]

Pavel,

To be clear, you're trying to create an account here: 
https://www.openstack.org/join/register/#community


Thanks!
Jimmy McArthur
OpenStack Foundation

Pavel Gluschak wrote:

Hello,

I've been trying to set up Openstack membership account, but keep 
getting error "Your Session has expired!."

Does it work?

--
Kind regards,
Pavel Gluschak
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Wiki.o.o sustaining spam attack

[Jimmy Mcarthur]

Jeremy Stanley wrote:

On 2016-03-22 08:23:08 -0500 (-0500), JP Maxwell wrote:

If anyone wants to approve this I am still happy to help.

https://review.openstack.org/#/c/285641/1


Can you elaborate on how you intend to help which has to be done
first with root access to the server (rather than merely with the
assistance of someone with root access)? The commit message on that
change indicates you just want access to logs files, which I or
other root sysadmins can certainly provide.

We want to make sure that all modifications are reflected in
configuration management so that it's reviewed, tracked and
repeatable, and this is why we generally limit production server
root access to people who also have the ability to approve
configuration management changes for the same servers. This service
is already in a bit of an unfortunate state because years ago we
were less strict and in a moment of weakness allowed the MW
deployment/migration to precede the configuration management of that
deployment (which was subsequently never completed). We need to make
sure its tenuous situation doesn't regress further.
I think the idea that something bad happened years ago shouldn't 
determine the fate of this service forever more. There is a real issue 
occurring here and none of the current stop gaps have been working. JP's 
proposal is pretty sound and isn't attempting to work around any rules. 
Simply to get to the root of the problem and then submit a patch for 
review. IMO we can't wait another 6 weeks until the summit is over to 
take a second look at this and hope an Ubuntu and MW upgrade fixes the 
issue.



I don't think you are ever going to be successful at blocking
accounts or IPs. You must block the creation of the spam by the
bots. IMHO focusing on improving the captcha or understanding the
bypass path around the captcha is the best short term path to
accomplish this.


I'm pretty sure we have consensus on this already. Blocking accounts
and manual cleanup are only viewed as a temporary workaround while
we plan for a safe upgrade to a more recent MW (and as a
prerequisite, more recent Ubuntu) release so that we can take
advantage of current access control measures and similar mitigation
solutions developed by their community in response to escalating
advancement in defacement and valdalism on Wikipedia and elsewhere.


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Log in problem in translation website

[Jimmy Mcarthur]

Hi -

Could you paste the URL of the site you're trying to log into?

Thanks,
Jimmy

Ying Chun Guo wrote:

Hello,

I meet problem to log in to translation website with Openstack ID.
When I click log in button, the page refreshed and nothing happened. The
login button is still there.
Refstack website cannot login with Openstack ID neither.
So I think it's a problem of Openstack ID.

Who can help to resolve the problem?

Best regards
Ying Chun Guo (Daisy)



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Wiki.o.o sustaining spam attack

[Jimmy McArthur]

Super thankful for all the folks that have jumped in over the last 
couple of days to help with the puppetization, etc... I just feel like 
we're taking a very wrong approach here.


Paul Belanger wrote:

Right, and I don't have an issue with that approach.  Based on the work we did
yesterday, anybody can do that via our workflow. Please submit a patch to
puppet-mediawiki[1] and ping an infra-root in #openstack-infra IRC.
What I'm proposing is the workflow is really meant for software, not for 
web applications. It's tedious and time consuming when what's needed 
here is a set of tests on the server. Submitting a patch, waiting for a 
+1, then getting on IRC to find someone with access (and time) to paste 
the logs is a pretty time consuming process for what should be a series 
of rapid-fire changes/fixes on the server. Especially when we're dealign 
with an active attack.


We can then have somebody look at the logs.  I think it is more about scheduling
the task since more infra-root as travling back from the mid-cycle last night
and today.
Right, this is my point. This has been going on for 3 weeks (or more). 
Tom Fifeldt was asking for help without response. And here we are 
through another week and no closer to stemming the flow.


I'm fully aware what I'm proposing goes against what Infra and the 
OpenStack workflow is all about, but I'd ask you all to look at this 
from a web development perspective instead of a software development 
perspective.


Jimmy


Last email from me, just on a plane.  Will follow up when I land.

[1] https://git.openstack.org/cgit/openstack-infra/puppet-mediawiki



J.P. Maxwell | tipit.net [http://tipit.net] | fibercove.com
[http://www.fibercove.com]
On Fri, Feb 26, 2016 at 11:25 AM, Paul Belanger
wrote:
On Fri, Feb 26, 2016 at 11:08:18AM -0600, Jimmy McArthur wrote:

Given the state of the wiki a the moment, I think taking the quickest path
to get it fixed would be prudent. Is there a way we can get JP root access
to this server, even temporarily? We get 25% of our website traffic (2
million visitors) to the wiki. I realize we're all after the same thing,

but

spammers are not going to hit the dev environment, so there's really no

way

to tell if teh problem is fixed without actually working directly on the
production machine. This should be a 30 minute fix.


I am still unclear what the 30min fix is. If really 30mins, then it
shouldn't be
hard to get the fix into our workflow. Could somebody please elaborate.

If we are talking about deploying new versions of php or mediawiki manually,
I
not be in-favor of this. To me, while the attack sucks, we should be working
on
2 fronts. Getting the help needed to mitigate the attack, then adding the
changes into -infra workflow in parallel.


I realize there is a lot of risk in giving ssh access to infra machines,

but

I think it's worth taking a look at either putting this machine in a place
where a different level of admin could access it without giving away the
keys to the entire OpenStack infrastructure or figuring out a way to set

up

credentials with varying levels of access.


As a note, all the work I've been doing to help with the attack hasn't
require
SSH access for me to wiki.o.o. I did need infra-root help to expose our
configuration safely. I'd rather take some time to see what the fixes are,
having infra-root apply changes, then move them into puppet.

It also has been discussed to simply disable write access to the wiki if we
really want spamming to stop, obviously that will affect normal usage.


Jimmy

Paul Belanger wrote:

On Fri, Feb 26, 2016 at 10:12:12AM -0600, JP Maxwell wrote:

But if you wanted to upgrade everything, remove the mobile view

extension,

test in a dev/staging environment then deploy to production fingers
crossed, I think that would be a valid approach as well.


Current review up[1]. I'll launch a node tonight / tomorrow locally to

see
how

puppet reacts. I suspect there will be some issues.

If infra-roots are fine with this approach, we can use that box to test

against.

[1] https://review.openstack.org/#/c/285405/


J.P. Maxwell | tipit.net | fibercove.com
On Feb 26, 2016 10:08 AM, "JP Maxwell"  wrote:


Plus one except in this case it is much easier to know if our efforts

are

working on production because the spam either stops or not.

J.P. Maxwell | tipit.net | fibercove.com
On Feb 26, 2016 9:48 AM, "Paul Belanger"  wrote:


On Fri, Feb 26, 2016 at 09:18:00AM -0600, JP Maxwell wrote:

I really think you might consider the option that there is a

vulnerability

in one of the extensions. If that is the case black listing IPs will

be

an

ongoing wild goose chase.

I think this would be easily proven or disproven by making the questy
question impossible and see if the spam continues.


We'll have to let an infra-root make that call. Since nobody would be
able to
use th

Re: [OpenStack-Infra] Wiki.o.o sustaining spam attack

[Jimmy McArthur]

Given the state of the wiki a the moment, I think taking the quickest 
path to get it fixed would be prudent. Is there a way we can get JP root 
access to this server, even temporarily? We get 25% of our website 
traffic (2 million visitors) to the wiki. I realize we're all after the 
same thing, but spammers are not going to hit the dev environment, so 
there's really no way to tell if teh problem is fixed without actually 
working directly on the production machine. This should be a 30 minute fix.


I realize there is a lot of risk in giving ssh access to infra machines, 
but I think it's worth taking a look at either putting this machine in a 
place where a different level of admin could access it without giving 
away the keys to the entire OpenStack infrastructure or figuring out a 
way to set up credentials with varying levels of access.


Jimmy

Paul Belanger wrote:

On Fri, Feb 26, 2016 at 10:12:12AM -0600, JP Maxwell wrote:

But if you wanted to upgrade everything, remove the mobile view extension,
test in a dev/staging environment then deploy to production fingers
crossed, I think that would be a valid approach as well.


Current review up[1]. I'll launch a node tonight / tomorrow locally to see how
puppet reacts.  I suspect there will be some issues.

If infra-roots are fine with this approach, we can use that box to test against.

[1] https://review.openstack.org/#/c/285405/


J.P. Maxwell | tipit.net | fibercove.com
On Feb 26, 2016 10:08 AM, "JP Maxwell"  wrote:


Plus one except in this case it is much easier to know if our efforts are
working on production because the spam either stops or not.

J.P. Maxwell | tipit.net | fibercove.com
On Feb 26, 2016 9:48 AM, "Paul Belanger"  wrote:


On Fri, Feb 26, 2016 at 09:18:00AM -0600, JP Maxwell wrote:

I really think you might consider the option that there is a

vulnerability

in one of the extensions. If that is the case black listing IPs will be

an

ongoing wild goose chase.

I think this would be easily proven or disproven by making the questy
question impossible and see if the spam continues.


We'll have to let an infra-root make that call. Since nobody would be
able to
use the wiki. Honestly, I'd rather spend the time standing up a mirror dev
instance for us to work on, rather then production.


J.P. Maxwell | tipit.net | fibercove.com
On Feb 26, 2016 9:12 AM, "Paul Belanger"  wrote:


On Thu, Feb 25, 2016 at 08:10:34PM -0800, Elizabeth K. Joseph wrote:

On Thu, Feb 25, 2016 at 6:35 AM, Jeremy Stanley

wrote:

On 2016-02-25 02:46:13 -0600 (-0600), JP Maxwell wrote:

Please be aware that you can now create accounts under the mobile
view in the wiki native user table. I just created an account for
JpMaxMan.  Not sure if this matters but wanted to make sure you
were aware.

Oh, yes I think having a random garbage question/answer was in

fact

previously preventing account creation under the mobile view. We
probably need a way to disable mobile view account creation as it
bypasses OpenID authentication entirely.

So that's what it was doing! We'll have to tackle the mobile view

issue.

Otherwise, quick update here:

The captcha didn't appear to help stem the spam tide. We'll want to
explore and start implementing some of the other solutions.

I did some database poking around today and it does seem like all

the

users do have launchpad accounts and email addresses.


So, I have a few hours before jumping on my plane and checked into

this.

We are
using QuestyCaptcha which according to docs, should almost be

impossible

for
spammers to by pass in an automated fashion.  So, either our captcha

is too

easy, or we didn't set it up properly.  I don't have SSH on wiki.o.o

so

others
will have to check logs.  I did test new pages and edits, and was

promoted

by
captcha.

As a next step, we might need to add additional apache2 configuration

to

blacklist IPs.  I am reading up on that now.


--
Elizabeth Krumbach Joseph || Lyz || pleia2

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] userName Mapping Between Storyboard / Launchpad and Phabricator

[Jimmy McArthur]

I'm coming in a little blind on this, but it seems you could use
OpenStackID for this. Ultimately Gerrit will move to this service and
it supports OpenID2.0, oAuth2.0 and OpenID Connect (soon).

Thanks,
Jimmy McArthur 
512.965.4846


> On Nov 11, 2015, at 11:29 PM, Craige McWhirter  
> wrote:
>
> Storyboard does not have a field that maps directly to the userName
> field of Phabricator.
>
> However Launchpad does have the launchpad id field which does.
>
> For a production migration, I was considering using launchpadlib[1] to
> take the email address from Storyboard and use it to discover the
> launchpad id of the user so it can be applied to userName in Phabricator.
>
> I was orignally mapping email addresses to the userName field but
> Phabricator would not accept this solution. It absolutely choked on it.
>
> However I've discovered that some punters do not have a public email
> address listed in launchpad which could be an impediment to immediate
> access post migration and will require manual exception handling.
>
> While this won't really be needed for authentication once OpenID is
> enabled, the userName field ought to contain data that Phabricator
> considers valid.
>
> Any thoughts on whether hitting up launchpad is an ideal way to get
> usernames?
>
> Should I target another service for this information?[2]
>
> [1] https://help.launchpad.net/API/launchpadlib
> [2] How about Gerrit?
>
> --
> Craige McWhirter
> M: +61 4685 91819
> W: https://mcwhirter.com.au/
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Permissions for refstack project to use openstackid.org as identity provider

[Jimmy Mcarthur]

Sergey,

Can you clarify the ask? We've already been working with you and 
refstack on getting set up with OpenStackID.


Thanks,
Jimmy

Sergey Slypushenko wrote:

Hi, all!

Refstack project need to use openstackid.org  
as identity provider (OpenID). Whom I should ask for such permission 
or maybe some special procedure exits for it?



Regards,
Sergey Slipushenko,


Software Developer,
Kharkiv, Ukraine,
Mirantis Inc.
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Refstack workflow discussion. Using OpenstackID as auth provider for application with Web UI and CLI client

[Jimmy McArthur]

Thank you for a really interesting discussion. You can code something and
think you planned for everything, but there is always a corner case to keep
you in check! I think adding ppk is a fine idea, but definitely something
that needs to be custom developed and thought through. Hopefully the lack
of it won't be a blocker for refstack.

Thanks,
Jimmy McArthur 
512.965.4846


On Apr 23, 2015, at 2:58 PM, Sergey Slypushenko 
wrote:

It is interesting, that it is possible to receive OpenID token just with
curl and a parser. In any way, for successful authorization with curl you
should put our OpenID credentials in CLI. It is requires deep trust to our
application (which we actually  we don't have). We try to avoid that kind
of issues.

We decided to change  authorization with OpenID creds to auth with pubkeys
for CLI client. It is a single reason why refstack needs pubkeys
management. So, here we don't discuss a way how to manage pubkeys with
OpenStackID. I mentioned pubkeys only as a alternative for CLI auth. It
would be great if some other appropriate alternative exists.

On Thu, Apr 23, 2015 at 7:43 PM, Jimmy Mcarthur  wrote:

> No question openID and oAuth are meant as web solutions. OpenStackID was
> designed for integration, authentication, and data auth for OpenStack web
> projects. Leaving public key auth aside for a moment, it's still possible
> with curl and a parser to authenticate from the command line by posting to
> openID, receiving a token, then posting back to oAuth for authorization.
> Maybe it's not pretty, but it's working within the confines of OpenStackID
> as it exists.
>
> Could we/should we talk about adding ppk to OpenStackID is probably a
> separate discussion that should be had. One which you've started here:
> http://lists.openstack.org/pipermail/openstack-infra/2015-April/002673.html
>
> IMO, it would be best to work within the existing system, even if it's a
> bit cumbersome, and discuss how we can improve or change OpenStackID once
> we get additional community input on the need for ppk.
>
>
>
>
>
> Sergey Slypushenko wrote:
>
> Thanks that our discussion was brought back to mailing list.
>
> The most hard use case here is providing access to some private resources
> from CLI client without using any GUI tools. As far as you understand, CLI
> tool can not pass through common OpenID auth procedure without
> workarounds(like opening browser, for example). Also, I think that passing
> user creds in CLI client it isn't appropriate solution, too.
>
> Using key pairs for auth from CLI looks like a good solution, because any
> sensitive information won't be shared in this case. Also it should be
> pretty secure. As for me, main disadvantage of this kind of auth, that it
> is not implemented in OpenID/oAuth workflow(or I don't know about that).
> Maybe I am missing something about OpenID/oAuth?
>
> On. Wed, Apr 22, 2015 at 11:28 PM, Jimmy McArthur  wrote:
>
>> Sergey,
>>
>> I looks like this mailing thread is broken. I didn't receive your
>>> response.
>>>
>>
>> I think a lot of the responses aren't getting through b/c the Infra list
>> was dropped from the discussion. I think it's important to have this
>> discussion on a public forum, so adding back in.
>>
>>>
>>> We thought about using tokens generated by OpenstackID, but I didn't
>>> find how a CLI client can get such kind of token.
>>> If you know how to get oAuth token from CLI tool, please shared it with
>>> me.
>>>
>>
>> At the moment, we have not implemented that oauth2 workflow:
>> https://tools.ietf.org/html/rfc6749#section-4.3 There are some security
>> concerns about passing credentials:
>>
>> The resource owner password credentials grant type is suitable in
>>cases where the resource owner has a trust relationship with the
>>client, such as the device operating system or a highly privileged
>>
>>application.  The authorization server should take special care when
>>enabling this grant type and only allow it when other flows are not
>>viable.
>>
>>
>> As you can see, this is doable, but not something we'd prefer for
>> security reasons. Perhaps if you could clarify the use case? Maybe with a
>> bit more information, we could understand why you need to get a token for
>> the CLI app. It feels like this is still a desire to use oauth2 for some
>> type of authentication.
>>
>>
>> --
>> Jimmy McArthur / Tipit.net <http://tipit.net/> < ji...@tipit.net>
>> 512.965.4846
>>
>>
>>> On Mon, Apr 20, 2015 at 6:49 PM, Sergey Slypus

Re: [OpenStack-Infra] Refstack workflow discussion. Using OpenstackID as auth provider for application with Web UI and CLI client

[Jimmy Mcarthur]

No question openID and oAuth are meant as web solutions. OpenStackID was 
designed for integration, authentication, and data auth for OpenStack 
web projects. Leaving public key auth aside for a moment, it's still 
possible with curl and a parser to authenticate from the command line by 
posting to openID, receiving a token, then posting back to oAuth for 
authorization. Maybe it's not pretty, but it's working within the 
confines of OpenStackID as it exists.


Could we/should we talk about adding ppk to OpenStackID is probably a 
separate discussion that should be had. One which you've started here: 
http://lists.openstack.org/pipermail/openstack-infra/2015-April/002673.html


IMO, it would be best to work within the existing system, even if it's a 
bit cumbersome, and discuss how we can improve or change OpenStackID 
once we get additional community input on the need for ppk.






Sergey Slypushenko wrote:

Thanks that our discussion was brought back to mailing list.

The most hard use case here is providing access to some private 
resources from CLI client without using any GUI tools. As far as you 
understand, CLI tool can not pass through common OpenID auth procedure 
without workarounds(like opening browser, for example). Also, I think 
that passing user creds in CLI client it isn't appropriate solution, too.


Using key pairs for auth from CLI looks like a good solution, because 
any sensitive information won't be shared in this case. Also it should 
be pretty secure. As for me, main disadvantage of this kind of auth, 
that it is not implemented in OpenID/oAuth workflow(or I don't know 
about that). Maybe I am missing something about OpenID/oAuth?


On. Wed, Apr 22, 2015 at 11:28 PM, Jimmy McArthur <mailto:ji...@tipit.net>> wrote:


Sergey,

I looks like this mailing thread is broken. I didn't receive
your response.

I think a lot of the responses aren't getting through b/c the
Infra list was dropped from the discussion. I think it's important
to have this discussion on a public forum, so adding back in.


We thought about using tokens generated by OpenstackID, but I
didn't find how a CLI client can get such kind of token.
If you know how to get oAuth token from CLI tool, please
shared it with me.

At the moment, we have not implemented that oauth2 workflow:
https://tools.ietf.org/html/rfc6749#section-4.3 There are some
security concerns about passing credentials:

The resource owner password credentials grant type is suitable in
cases where the resource owner has a trust relationship with the
client, such as the device operating system or a highly privileged

application.  The authorization server should take special care when
enabling this grant type and only allow it when other flows are not
viable.


As you can see, this is doable, but not something we'd prefer for
security reasons. Perhaps if you could clarify the use case? Maybe
with a bit more information, we could understand why you need to
get a token for the CLI app. It feels like this is still a desire
to use oauth2 for some type of authentication.


--
Jimmy McArthur / Tipit.net <http://tipit.net/>< ji...@tipit.net
<mailto:ji...@tipit.net>>
512.965.4846 


On Mon, Apr 20, 2015 at 6:49 PM, Sergey Slypushenko
mailto:sslypushe...@mirantis.com>>
wrote:

Jimmy,

Thank you for your comment! That diagram was kind of
outdated. I have updated it already.
We are planning to use OpenID for authentication and we
have been already working on it.

Regards,
Sergey



On Mon, Apr 20, 2015 at 6:30 PM, Jimmy McArthur
mailto:ji...@tipit.net>> wrote:

Sergey,

The biggest thing that stands out is the lack of
authentication through OpenID. It appears that you're
still authenticating through oAuth2, which is against
security best practices and not how OpenStackID is
designed. For a primer on the difference and why it's
set up this way:

http://nat.sakimura.org/2011/05/15/dummys-guide-for-the-difference-between-oauth-authentication-and-openid/
(forgive the title, but it does a nice job of
illustrating the issue)

I'm adding Sebastian here to chime in on potential
technical details and the possibility of setting up
your own resource server. The important thing though
is to follow the steps outlined in the OpenStackID
documentation for proper authentication.

--
Jimmy McArthur

Re: [OpenStack-Infra] Refstack workflow discussion. Using OpenstackID as auth provider for application with Web UI and CLI client

[Jimmy McArthur]

Sergey,

I looks like this mailing thread is broken. I didn't receive your response.
>

I think a lot of the responses aren't getting through b/c the Infra list
was dropped from the discussion. I think it's important to have this
discussion on a public forum, so adding back in.

>
> We thought about using tokens generated by OpenstackID, but I didn't find
> how a CLI client can get such kind of token.
> If you know how to get oAuth token from CLI tool, please shared it with me.
>

At the moment, we have not implemented that oauth2 workflow:
https://tools.ietf.org/html/rfc6749#section-4.3 There are some security
concerns about passing credentials:

The resource owner password credentials grant type is suitable in
   cases where the resource owner has a trust relationship with the
   client, such as the device operating system or a highly privileged

   application.  The authorization server should take special care when
   enabling this grant type and only allow it when other flows are not
   viable.


As you can see, this is doable, but not something we'd prefer for security
reasons. Perhaps if you could clarify the use case? Maybe with a bit more
information, we could understand why you need to get a token for the CLI
app. It feels like this is still a desire to use oauth2 for some type of
authentication.


--
Jimmy McArthur / Tipit.net <http://tipit.net/> < ji...@tipit.net>
512.965.4846


> On Mon, Apr 20, 2015 at 6:49 PM, Sergey Slypushenko <
> sslypushe...@mirantis.com> wrote:
>
>> Jimmy,
>>
>> Thank you for your comment! That diagram was kind of outdated. I have
>> updated it already.
>>
>> We are planning to use OpenID for authentication and we have been already
>> working on it.
>>
>> Regards,
>> Sergey
>>
>>
>>
>> On Mon, Apr 20, 2015 at 6:30 PM, Jimmy McArthur  wrote:
>>
>>> Sergey,
>>>
>>> The biggest thing that stands out is the lack of authentication through
>>> OpenID. It appears that you're still authenticating through oAuth2, which
>>> is against security best practices and not how OpenStackID is designed. For
>>> a primer on the difference and why it's set up this way:
>>> http://nat.sakimura.org/2011/05/15/dummys-guide-for-the-difference-between-oauth-authentication-and-openid/
>>> (forgive the title, but it does a nice job of illustrating the issue)
>>>
>>> I'm adding Sebastian here to chime in on potential technical details and
>>> the possibility of setting up your own resource server. The important thing
>>> though is to follow the steps outlined in the OpenStackID documentation for
>>> proper authentication.
>>>
>>> --
>>> Jimmy McArthur / Tipit.net < ji...@tipit.net>
>>> 512.965.4846
>>>
>>>
>>> On Thu, Apr 16, 2015 at 4:49 AM, Sergey Slypushenko <
>>> sslypushe...@mirantis.com> wrote:
>>>
>>>> Here you can find slides with general user stories:
>>>>
>>>>- create user account
>>>>- access to resource required user auth in Web UI
>>>>- access to resource required user auth in CLI client
>>>>
>>>>
>>>> https://docs.google.com/presentation/d/1v7exKKL1zSA102Xu8FkY1u9rMVUE6BjwUCoWGYYvbaI/edit#slide=id.g9870fa983_0_0
>>>>
>>>> Any comments related to this topic will be very appreciated.
>>>>
>>>> Regards,
>>>> Sergey Slipushenko,
>>>>
>>>> Software Developer,
>>>> Kharkiv, Ukraine,
>>>> Mirantis Inc.
>>>>
>>>>
>>>> ___
>>>> OpenStack-Infra mailing list
>>>> OpenStack-Infra@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>>>
>>>>
>>>
>>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Refstack workflow discussion. Using OpenstackID as auth provider for application with Web UI and CLI client

[Jimmy Mcarthur]

Sergey,

Great news! Thanks for the update on OpenID.

Our other question is around the workflow for the Authorization tokens. 
It seems like you're bypassing oAuth2 on OpenStackID in order to manage 
the authorization on the refstack client. Why not utilize OpenStackID 
for both openid and oAuth2? Basically create the authorization tokens on 
the OpenStackID side and create your own resources server as gatekeeper 
of you API and validate oauth2 tokens against introspection endpoint 
(http://ci.openstack.org/openstackid/oauth2.html#token-introspection).


Thoughts?

Thanks,
Jimmy



Sergey Slypushenko wrote:

Jimmy,

Thank you for your comment! That diagram was kind of outdated. I have 
updated it already.
We are planning to use OpenID for authentication and we have been 
already working on it.


Regards,
Sergey



On Mon, Apr 20, 2015 at 6:30 PM, Jimmy McArthur <mailto:ji...@tipit.net>> wrote:


Sergey,

The biggest thing that stands out is the lack of authentication
through OpenID. It appears that you're still authenticating
through oAuth2, which is against security best practices and not
how OpenStackID is designed. For a primer on the difference and
why it's set up this way:

http://nat.sakimura.org/2011/05/15/dummys-guide-for-the-difference-between-oauth-authentication-and-openid/
(forgive the title, but it does a nice job of illustrating the issue)

I'm adding Sebastian here to chime in on potential technical
details and the possibility of setting up your own resource
server. The important thing though is to follow the steps outlined
in the OpenStackID documentation for proper authentication.

--
Jimmy McArthur / Tipit.net <http://Tipit.net>< ji...@tipit.net
<mailto:ji...@tipit.net>>
512.965.4846 


On Thu, Apr 16, 2015 at 4:49 AM, Sergey Slypushenko
mailto:sslypushe...@mirantis.com>> wrote:

Here you can find slides with general user stories:

  * create user account
  * access to resource required user auth in Web UI
  * access to resource required user auth in CLI client


https://docs.google.com/presentation/d/1v7exKKL1zSA102Xu8FkY1u9rMVUE6BjwUCoWGYYvbaI/edit#slide=id.g9870fa983_0_0

Any comments related to this topic will be very appreciated.

Regards,
Sergey Slipushenko,

Software Developer,
Kharkiv, Ukraine,
Mirantis Inc.


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
<mailto:OpenStack-Infra@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Proposal for improvements OpenstackID

[Jimmy Mcarthur]

Vlad,

In our opinion this would not be a good change. Validating the domain 
name is part of our security measures and would apply to both dev and 
production. If you just update your hosts file, you can get around this, 
or just make sure you're using a valid Top Level Domain.


Jimmy McArthur

Vladislav Kuzmin wrote:

Hi, folks!

I continue working with openstackid and found one things. When I send 
request to OpenID endpoint I had exception in openstackid logs(Invalid 
TLD).
I spent more time for found this stuff. I propose use validation of 
domain name only with production enviroment. But in development 
enviroment we can disable that feature in OpenID helper 
https://github.com/openstack-infra/openstackid/blob/master/app/libs/openid/helpers/OpenIdUriHelper.php#L374

What do you think about it?
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] A problem with unique identifier on openstackid.org

[Jimmy Mcarthur]

Vlad,

The relevant information is documented here: 
http://docs-draft.openstack.org/99/165199/7/check/gate-openstackid-docs/8797c5d//doc/build/html/openid.html#openid-2-0-request-authentication-response


You must first make the OpenID request in order to get the correct 
identifier. As Sebastian mentioned, oAuth should not be used for 
authentication.  If there are additional questions on this, please let 
us know.


--
Jimmy McArthur






Sebastian Marcet wrote:
Vladislav  , oauth2 is not meant for authentication, is meant for 
authorization, if you use oauth2 for authentication, then you are 
introducing some security issues on your app

http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

if you want to authenticate your users in a safe way, you should use 
openid endpoint first, then the oauth2 proctected api to get 
additional user info, that is not provided by openid netiher its 
extensions (SREG/AX) by default


regards

2015-04-16 9:57 GMT-03:00 Vladislav Kuzmin <mailto:vkuz...@mirantis.com>>:


Sebastian, I've used only OAuth2.0 (not OpenID) for obtain an
access_token and I've used this documentation

http://docs-draft.openstack.org/99/165199/7/check/gate-openstackid-docs/8797c5d//doc/build/html/oauth2.html
. When I got the access_token, I called "OAuth 2.0 Rest API" for
get info about the user

http://docs-draft.openstack.org/99/165199/7/check/gate-openstackid-docs/8797c5d//doc/build/html/restapi/v1.html
. But "OAuth 2.0 Rest API" don't provide unique identifier for user.
My main goal is to get a unique ID for a user that I can use in my
application.
How I can get ID for user with OAuth2.0?

On Thu, Apr 16, 2015 at 1:13 PM, Sebastian Marcet
mailto:smar...@gmail.com>> wrote:

Vladislav  in order to user oauth 2.0, i am assuming that you
are doing first an openid request, on the openid response (
possitive assertion

http://openid.net/specs/openid-authentication-2_0.html#positive_assertions)
you will get param "openid.claimed_id", that one contains the
openid url that after this patch is unique per user

regards

2015-04-16 4:44 GMT-03:00 Vladislav Kuzmin
mailto:vkuz...@mirantis.com>>:

In this ticket
https://storyboard.openstack.org/#!/story/2000239
<https://storyboard.openstack.org/#%21/story/2000239> is
mentioned only about OpenID. If I will be use OAuth2.0,
how I can distinguish between users?
I guess that User API

http://docs-draft.openstack.org/99/165199/7/check/gate-openstackid-docs/8797c5d//doc/build/html/restapi/v1.html#user-api
should provide an ID for each user.

On Wed, Apr 15, 2015 at 9:17 PM, Sebastian Marcet
mailto:smar...@gmail.com>> wrote:

Hello!

here is the ticket that we opened
https://storyboard.openstack.org/#!/story/2000239
<https://storyboard.openstack.org/#%21/story/2000239>

regards

2015-04-15 12:54 GMT-03:00 Jeremy Stanley
mailto:fu...@yuggoth.org>>:

    On 2015-04-15 10:08:08 -0500 (-0500), Jimmy
McArthur wrote:
> Hello!  We are trying to open a ticket for this,
but it looks like
> Launchpad for OpenStackID isn't configured yet.
Can you let us
> know what we need to do to set that up?
[...]

Task tracking for all "openstack-infra" repos
moved from Launchpad
to Storyboard late last year once its development
grew closer to
general usability. Log in at
https://storyboard.openstack.org/ and
then add a story at
https://storyboard.openstack.org/#!/project/728
<https://storyboard.openstack.org/#%21/project/728>
for the openstack-infra/openstackid repo (looks
like there are none
active for that Git repo currently).
--
Jeremy Stanley




-- 
Ing. Sebastian Marcet


SKYPE: sebastian.marcet





-- 
Ing. Sebastian Marcet


SKYPE: sebastian.marcet





--
Ing. Sebastian Marcet

SKYPE: sebastian.marcet




___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] A problem with unique identifier on openstackid.org

[Jimmy McArthur]

Hello!  We are trying to open a ticket for this, but it looks like
Launchpad for OpenStackID isn't configured yet. Can you let us know what we
need to do to set that up?

I believe we can correct the problem and allow the user to change their
email address, but maintain their original profile ID. We'll be publishing
more info on the ticket, once we can submit it.

Thank you !

--
Jimmy McArthur / Tipit.net < ji...@tipit.net>
512.965.4846


On Wed, Apr 15, 2015 at 7:58 AM, Vladislav Kuzmin 
wrote:

> I've been trying to use OAuth2.0 from openstackid.org with User REST API
> on it in Refstack  project https://github.com/stackforge/refstack. User
> REST API  from openstackid.org provide following fields: name,
> family_name, nickname, picture, birthdate, gender, and email. But on
> https://www.openstack.org/profile/ I can change all fields including
> email. If I changed my email I get new OPENID. For example before changes:
> https://openstackid.org/vladislav.kuzmin after changes:
> https://openstackid.org/vladislav.kuzmin
> <https://openstackid.org/vladislav.kuzmin.1>.1
>
> I think, that primary email and OPENID can not be changed
>
> How can I distinguish between users in my application?
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Better Corporate CLA management

[Jimmy Mcarthur]

Hi all - The OpenStack Foundation has already worked up at least a 
portion of this solution by allowing one or more users with an 
OpenStackID to be set as a CCLA Admin for their organization. The CCLA 
Admin can designate one or more CCLA teams for their company. And then 
each team can be comprised of multiple members. Members can be assigned 
as long as they have a Foundation Membership and have a GerritID. If 
they don't, they will be prompted to register and get a GerritID.


We also regularly run an ingest from Gerrit to retrieve Last Commit, 
Gerrit ID, based on the Foundation Member email address. It may not be 
possible, but perhaps we could offer the same check that we offer for 
Foundation Members. Just a True/False if the user is a valid CCLA member.


We are also flexible enough to add or ingest ANY info from Gerrit that 
you need to associate with a Company (CCLA Agreement #, etc...)


Just throwing this out there for discussion.

Thank you,

--
Jimmy McArthur / Tipit.net <http://Tipit.net>< ji...@tipit.net 
<mailto:ji...@tipit.net>>

m: 512.965.4846
o: 512.481.1161



Clark Boylan wrote:

On Thu, Mar 12, 2015, at 05:41 PM, Stefano Maffulli wrote:

hello folks,

We would like to provide a greater degree of freedom to individuals who
contribute on behalf of corporations who signed the Corporate CLA. By
allowing corporate managers to maintain list of their authorized
contributors we may be able to remove the need for every individual to
sign an iCLA.

Currently, corporate managers sign the CCLA on echosign and provide a
list of approved contributors on the "Schedule A". That list is kept
only as an archived 'paperwork' since it's not machine readable. OTOH to
make sure that we have a track of who is authorized to commit code, we
require every individual to sign the iCLA whether their name is in a
Schedule A or not. This has been confusing a lot of people, creates
unnecessary manual work and duplication of information.

How would the infra team suggest we tackle this problem?


Based on the success of projects self managing third party CI voting
rights, I think we can solve this in a way very similar to how Gerrit
does it for contributions to Gerrit itself.

For each company that has signed a CCLA two groups would be created in
gerrit:
* companyname-ccla-owner, this group would be self owned and have
membership of company representatives that decide who can push to
Gerrit.
* companyname-ccla-members, this group would be owned by
companyname-ccla-owner and its membership would include those users can
can push to Gerrit.
Then each companyname-ccla-members would be added to the super group for
all CCLA signers

This will give companies greater tracking over who is covered by their
CCLA and remove the need for the ICLA as a proxy for that.

The one hurdle we need to get over is delegating the group creation,
initial ownership and membership config, and addition to the super CCLA
group to a group that isn't the Gerrit admins. I don't want to become
the bottleneck that has to decide when a CCLA is properly signed.

Options for this:
1. Potentially Gerrit ACLs be made rich enough to delegate these
activities to groups other than Gerrit admins (perhaps Zaro can comment
on this).
2. We could write a tool that used a serialized set of group info and
enforced that in Gerrit. Then have a repo for this data whose core team
was able to validate the CCLA process is complete before updating Gerrit
via updates to this repo.

Thoughts? Particularly interested in thoughts on the two options just
above and any other ideas people may have to tackle that particular
implementation detail.

Clark

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Groups portal SSL certificates

[Jimmy Mcarthur]

Hey all -

Just wanted to add a little clarity to this so that the rest of the 
Infra team is up to speed about how we got here. OAuth2 was included as 
part of OpenStackID for this exact reason. As you all know OpenID has 
limited standard claims 
(http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims), 
which didn't seem to meet the long term needs of the community. As a 
result, our original proposal was to use OpenID Connect since it 
hadOAuth baked in. Since that was a no go from the Gerrit side, we 
ultimately pursued OpenID + OAuth2 so we could have similar 
functionality, even if the lift was a little heavier.


The idea is that ultimately you'll be able to share pieces of 
information across the many OpenStack properties (e.g. the last Gerrit 
commit, # of commits per user, profile picture, CLA signature, messages 
to encourage members to vote, etc..) In the end, this is meant to 
connect all of the properties through a single OpenStackID and allow for 
greater data sharing amongst them.


Thanks and please let me know if you have further questions or concerns.

--
Jimmy McArthur / Tipit.net <http://Tipit.net>< ji...@tipit.net 
<mailto:ji...@tipit.net>>

m: 512.965.4846






Marton Kiss <mailto:marton.k...@gmail.com>
November 18, 2014 at 9:22 AM
Hi All,

I want to replace the groups portal authentication mechanism from 
openid to oauth2, because the actual openid implementation not 
supports retrieval of profile picture urls. The side-effect of the 
migration that OpenStackID enforce using SSL for oauth2 communication. 
So we need to issue an x509 ssl cert for groups.openstack.org 
<http://groups.openstack.org> and groups-dev.openstack.org 
<http://groups-dev.openstack.org> domains, and need to add SSL based 
vhosts to Apache webserver. I'll prepare the required apache 
system-config changes.


I've added a blueprint for this at openstack-ci launchpad:
https://blueprints.launchpad.net/openstack-ci/+spec/groups-oauth2-authentication

Brgds,
  Marton Kiss
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Unable to check-in code due to missing contact info in ICLA agreement

[Jimmy Mcarthur]

Juigil,

Good afternoon! The issue with your membership is you were registered as 
a Presentation User, but have not completed the Foundation Membership. 
If you can agree in writing to the terms outlined at 
https://www.openstack.org/join/register, I can manually complete the 
membership for you and  you should be good to go.


Thanks!

--
Jimmy McArthur / Tipit.net <http://Tipit.net>< ji...@tipit.net 
<mailto:ji...@tipit.net>>

m: 512.965.4846
o: 512.481.1161



Kishore, Juigil <mailto:juigil.kish...@hp.com>
October 30, 2014 at 9:35 AM
Hi,
In the openstack review site _https://review.openstack.org_, I have 
submitted the ICLA agreement without providing the contact details. I 
am facing the flowing error during git review


fatal: ICLA contributor agreement requires current contact information.
Please review your contact information:
https://review.openstack.org/#/settings/contact
fatal: The remote end hung up unexpectedly

Then when I tried to update the contact info in the mentioned link, 
but  I am getting a Server error. I provided valid information in the 
required fields.
I have also joined the openstack 
foundation(_https://www.openstack.org/profile/_ ), but not able be 
view my public profile. And in the Legal Agreements tab, the ICLA 
agreement is missing.
My name is not present in the members list 
_http://www.openstack.org/community/members_
My Launchpad link is _https://launchpad.net/~juigil-kishore_ 
<https://launchpad.net/%7Ejuigil-kishore>

Preferred email-id _juigil.kishore@hp.com_ <mailto:juigil.kish...@hp.com>
Kindly help me in resolving this issue
Thanks
Juigil Kishore
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] OpenStack.org endpoint - outage at Rackspace

[Jimmy McArthur / tipit.net]

Faster than I could send the email, the issue resolved. Thanks Rackers! 

Jimmy McArthur / tipit.net  
o: 512.481.1161 
m: 512.965.4846 
- Original Message -

> From: "Jimmy McArthur / tipit.net" 
> To: openstack-infra@lists.openstack.org
> Cc: "Todd Morey" 
> Sent: Sunday, August 17, 2014 12:02:38 PM
> Subject: [OpenStack-Infra] OpenStack.org endpoint - outage at Rackspace

> Just a heads up that there has been an outage at Rackspace that could prevent
> the endpoint at OpenStack.org from working properly when Gerrit/Launchpad is
> attempting to check for Foundation Member status. Rackspace is working on
> the issue and hope to have it resolved soon, however, there isn't a lot of
> detail at this point. If you have reports of users having trouble creating
> new Gerrit accounts or updating existing, that's likely what the problem is.
> I'll update this as soon as we find the matter resolved from Rackspace.

> Thanks,

> Jimmy McArthur / tipit.net 
> o: 512.481.1161
> m: 512.965.4846

> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] OpenStack.org endpoint - outage at Rackspace

[Jimmy McArthur / tipit.net]

Just a heads up that there has been an outage at Rackspace that could prevent 
the endpoint at OpenStack.org from working properly when Gerrit/Launchpad is 
attempting to check for Foundation Member status. Rackspace is working on the 
issue and hope to have it resolved soon, however, there isn't a lot of detail 
at this point. If you have reports of users having trouble creating new Gerrit 
accounts or updating existing, that's likely what the problem is. I'll update 
this as soon as we find the matter resolved from Rackspace. 

Thanks, 

Jimmy McArthur / tipit.net  
o: 512.481.1161 
m: 512.965.4846 
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Improving the way we handle Corporate CLAs

[Jimmy McArthur / tipit.net]

> I'm hesitant to suggest that any of our CLAs solves any real problem
> (after all, I'm not a lawyer, so I only know what I've heard them
> say). That aside, I agree the member database sounds like it would
> be a sane place to deal with that, but until we actually see the
> source code for that site it's hard to be sure.

I can speak to this a little bit. OpenStack.org already has the data model in 
place to handle agreements and contracts amongst user groups associated with an 
organization. The intention is to leverage this information to shape the user 
experience and drive data sharing amongst the OpenStack properties.  Extending 
a corporate CLA to the user base is a nominal change.

Setting up a specific set of users that are tied to a particular company, with 
a particular set of permissions, is right in line for the vision we are working 
towards for OpenStack.org and the coming OpenID/OAuth setup.  Some of these 
pieces are in place already, but we can expect most of them to be ready when we 
launch with OpenID.  

Long term, we aim to share this data, and more with all OpenStack web 
properties given the appropriate permissions.  For example, an OpenStack user 
employed by Tycoon Corp that logs into the Beijing User Group could receive a 
message prompting them to notify Tycoon Corp to update their CCLA to include 
them as a user that's authorized to commit code on their behalf.  

Of course, with OAuth in place, pretty much any piece of data that OpenStack 
and your contributors authorize to share will be available. CCLAs and CLA 
controversy or usefulness aside, it's a good opportunity for OpenStack to drive 
development on your web properties with real and useful user data.

Thanks!

Jimmy McArthur / tipit.net  
o: 512.481.1161 
m: 512.965.4846 

- Original Message -
> From: "Jeremy Stanley" 
> To: "Stefano Maffulli" 
> Cc: openstack-infra@lists.openstack.org
> Sent: Monday, October 28, 2013 6:09:19 PM
> Subject: Re: [OpenStack-Infra] Improving the way we handle Corporate CLAs
> 
> On 2013-10-28 10:00:03 -0700 (-0700), Stefano Maffulli wrote:
> [...]
> > Probably then we should keep the notion of the CCLA in the User/Member
> > database then? The manager of the CCLA would click-sign the agreement on
> > our site, we keep the historic record of that signature and the manager
> > herself declares who works for her, authorized to commit. It would still
> > not prevent people to commit code without a CCLA but I htink it would
> > improve the situation. What do you think?
> 
> I'm hesitant to suggest that any of our CLAs solves any real problem
> (after all, I'm not a lawyer, so I only know what I've heard them
> say). That aside, I agree the member database sounds like it would
> be a sane place to deal with that, but until we actually see the
> source code for that site it's hard to be sure.
> --
> Jeremy Stanley
> 
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra