Re: [OpenStack-Infra] Ask OpenStack Profile Picture Bug

[Marton Kiss]

Hi Gene,

The staging.ask.o.o is broken, because it relies on askbot's 0.7.x branch,
and sometimes it contains incompatible configuration changes that broke the
site. We have a patch for this in the queue waiting for review / approval:
https://review.openstack.org/#/c/352284/ Askbot add editor_deselector for
the staging settings

Actually the ask.o.o is not rely on 0.7.x due to config changes, and we
have a patch in the queue as a solution:
https://review.openstack.org/#/c/274032/

I suggest to setup a local development environment in a vm first, made
tests and your patches there and contribute back changes to
https://github.com/ASKBOT/askbot-devel If you want to change anything in
the config we have a puppet-askbot repo and a system-config under
openstack-infra and I suggest to check the not-yet merged patches at
review.o.o. Feel free to reach me on irc if you have questions.

Brgds,
  Marton Kiss
  irc: mrmartin

On Tue, Aug 16, 2016 at 8:05 AM g...@openstack.org 
wrote:

> Hi everyone,
>
> I’m a new intern in OpenStack Foundation and I’m currently working on the
> Ask OpenStack website.
> There’s a bug regarding changing profile picture on Ask OpenStack that is
> currently not fixed.
> I’ve read through the launchpad discussion but after the upgrade the bug
> still exists.
> https://bugs.launchpad.net/openstack-community/+bug/1441398
>
> Do anyone in the infra team has any idea on what may cause the bug?
> I’ve already gone through the askbot deployment source code and haven’t
> found anything suspicious.
>
> Also, ask-staging isn’t working by now.
> Error reports that stdout access is restricted so that the web app can’t
> function normally.
> Probably need to fix it for testing.
> Thanks a lot!
>
> Kind Regards,
>
> Gene Kuo
>
>
> ___
> 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] Logs for Ask.O.o - chasing false positive spam labeling

[Marton Kiss]

Jeremy, I can apply and test this patch in a current test environment, it
was sitting there for a while. Usually the config changes of askbot broke
the site.

Marton

On Wed, Nov 9, 2016 at 10:26 PM Jeremy Stanley  wrote:

> On 2016-11-09 19:53:27 + (+), Jeremy Stanley wrote:
> > On 2016-11-09 18:11:39 + (+), Jeremy Stanley wrote:
> > > On 2016-11-08 19:12:32 +0800 (+0800), Tom Fifield wrote:
> > > [...]
> > > > Upstream apparently revamped the spam system in the version marked
> > > > to upgrade to in:
> > > > https://review.openstack.org/#/c/274032/
> > >
> > > I've gone ahead and approved this just now... I was unaware it was
> > > out there waiting for approval. Sorry about that! I'll try to
> > > double-check that ask.o.o is still working correctly once it gets
> > > applied.
> > [...]
> >
> > Just to follow up, it looks like the git_resource for
> > /srv/dist/askbot did not get updated to the newly specified commit
> > in 274032 so we're digging into why that is. The site still seems to
> > be up and working for now.
>
> After a while, the site began to throw internal server errors, so
> I'm reverting with https://review.openstack.org/395797 for now until
> we can more thoroughly troubleshoot.
> --
> 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

Re: [OpenStack-Infra] Ask.o.o down

[Marton Kiss]

Tom,

You can find more details about the host here:
http://cacti.openstack.org/cacti/graph_view.php?action=tree&tree_id=1&leaf_id=156
It
had a network outage somewhere, if you check the eth0, the traffic was zero.

Marton

On Fri, Jan 13, 2017 at 8:05 AM Tom Fifield  wrote:

> ... and at 0700Z it is back ...
>
> On 13/01/17 14:41, Tom Fifield wrote:
> > As at 2017-01-13 0641Z, Ask.o.o is refusing connections (at least on
> > IPv4) - tried from a couple of different hosts
> >
> > fifieldt@docwork2:~$ wget ask.openstack.org
> > --2017-01-13 06:40:49--  http://ask.openstack.org/
> > Resolving ask.openstack.org (ask.openstack.org)... 23.253.72.95,
> > 2001:4800:7815:103:be76:4eff:fe05:89f3
> > Connecting to ask.openstack.org (ask.openstack.org)|23.253.72.95|:80...
> > failed: Connection refused.
> >
> > ___
> > 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] Ask.o.o down

[Marton Kiss]

Hi Tom

Still not working from your end? Works perfectly from here.

Marton

On Fri, Feb 10, 2017 at 9:14 AM Tom Fifield  wrote:

> On 10/02/17 16:08, Tom Fifield wrote:
> > On 13/01/17 14:41, Tom Fifield wrote:
> >> As at 2017-01-13 0641Z, Ask.o.o is refusing connections (at least on
> >> IPv4) - tried from a couple of different hosts
> >>
> >> fifieldt@docwork2:~$ wget ask.openstack.org
> >> --2017-01-13 06:40:49--  http://ask.openstack.org/
> >> Resolving ask.openstack.org (ask.openstack.org)... 23.253.72.95,
> >> 2001:4800:7815:103:be76:4eff:fe05:89f3
> >> Connecting to ask.openstack.org (ask.openstack.org)|23.253.72.95|:80...
> >> failed: Connection refused.
> >
> > Down again, this time with "Network is unreachable".
>
> Sorry, it is still connection refused as before. The network unreachable
> bit is my end's IPv6 connectivity :)
>
>
> ___
> 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] Groups portal SSL certificates

[Marton Kiss]

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

Re: [OpenStack-Infra] openstackid.org

[Marton Kiss]

Hi Dan,

Let's talk I can help you. You have two options here, implement an OpenID
authentication, or use the Oauth2 for the login. For community portal we
are just finishing the migration to oauth2 because it can additionally
provide user pictures. We also running a staging server at
openstackid-dev.openstack.org for development purposes.

Bgrds,
  Marton Kiss
  irc: mrmartin

2015-01-06 0:48 GMT+01:00 Dan Radez :

> We're trying to move TryStack.org away from facebook.
> Mark C and Chris H have suggested that we move to openstackid.org
>
> Is there any documentation I can follow for setting up openstackid.org
> as an authentication method for TryStack.org?
>
> Thanks
>
> Dan Radez
> irc: radez
>
> ___
> 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] openstackid.org

[Marton Kiss]

Hi Dan,

You can find an initial commit of OpenStackID vagrant dev environment here:
https://github.com/fremontlabs/vagrant-openstackid

Basically this vagrant scripts sets a full test environment including
Apache, PHP, Redis and Mysql. I suggest to do some test, and if you have
any questions, feel free to ask me on irc. The default user account is
ad...@example.com and the password is admin.

Brgds,
  Marton

2015-01-06 19:29 GMT+01:00 Dan Radez :

> On 01/06/2015 01:24 PM, Jeremy Stanley wrote:
> > On 2015-01-06 07:13:27 +0100 (+0100), Marton Kiss wrote:
> >> Let's talk I can help you. You have two options here, implement an
> >> OpenID authentication, or use the Oauth2 for the login. For
> >> community portal we are just finishing the migration to oauth2
> >> because it can additionally provide user pictures. We also running
> >> a staging server at openstackid-dev.openstack.org for development
> >> purposes.
> >
> > Based on Morgan's response in IRC that Keystone doesn't support
> > OAuth2 (only a "funky" 1.1 implementation), it sounds like you're
> > stuck using the OpenID (oidc) support in Keystone's master branch.
> >
>
> Thx for bringing this up, I didn't see the comment about 1.1 only.
>
> Dan
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [infra] OpenStackID in console

[Marton Kiss]

Hi Vladislav,

The integration doc is under construction as I know. I have experience with
the web based auth, where the redirection works well, but never played with
the headless login.

When I register a new Oauth2 application in OpenID I see a field called
"Application Type" with the following options:
- Web Server Application
- Client Side (JS)
- Service Account

I've added Sebastian as CC, I hope he can help us.

Brgds,
  Marton

2015-03-17 4:27 GMT-07:00 Vladislav Kuzmin :

> We want to use openstackid in refstack (
> https://github.com/stackforge/refstack) and refstack-client (
> https://github.com/stackforge/refstack-client/) for authentication.
>
> Refstack-client is CLI utility. Can we use openstackid without a browser?
> I know that services like google provides authorization for devices with
> limited input capabilities
> https://developers.google.com/accounts/docs/OAuth2ForDevices Has
> openstackid such functionality? It's authorization(not authentication) but
> it's the best way in a console I think.
>
> But we have no idea about an endpoint and parameters for OAuth and OpenID
> on openstackid.org. Has openstackid a documentation?
>
> ___
> 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] Biting the bullet on issue tracking

[Marton Kiss]

Hi,

Do we have a report about the major features we are missing from
Storyboard? As an SB user I missing those:
- proper notification system (email and / or in-app messages)
- story-id workflow integration with gerrit

Except this two, I don't have other concerns, I see smaller bugs that can
be fixed with a little work. I suggest to throw a little money to finish
those open issues in a reasonable time instead of jumping into unknown
again.

Brgds,
  Marton

2015-03-24 6:29 GMT+01:00 Christian Berendt :

> On 03/24/2015 12:02 AM, Monty Taylor wrote:
>
>> That is no longer true. Existing Open Source offerings not only can
>> represent a large portion of our data needs, but additionally can
>> support the additional features that have been requested by our
>> community today out of the box.
>>
>
> Monty, can you please list the appropriate alternatives?
>
> Christian.
>
>
> ___
> 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] Askbot-staging puppet venv update

[Marton Kiss]

Hi Jeremy,

thanks for quickly accepting the venv patch. When I wake up in the morning,
I checked the ask-staging host and see no sign of the changes by the new
puppet module, nor on the host and the puppet board logs. That was a bit
strange, because the patch was applied several hours before.

Then I invoked a 'puppet agent', and the changeset was magically applied:
http://puppetboard.openstack.org/report/ask-staging.openstack.org/d0dbf46e36443acd61cf59c672b032e25b145737

Do you think that the puppet-agent was disabled on that host due the
smartcn failure? The last update was on July 15. I put back the agent into
disabled state, until we resolve this issue.

Anyway the venv patch seems to be non disruptive, so the ask-staging.o.o is
running with python virtualenv now. I need to update the op docs to reflect
the changes. (the python manage.py must be invoked as
/usr/askbot-env/bin/python manage.py)

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

Re: [OpenStack-Infra] Askbot-staging puppet venv update

[Marton Kiss]

Yeap, it is an open issue, because a patch is required for vamsee-solr, my
pull request was accepted there, and I asked the maintainer to make a 0.0.8
release of solr module. It will solve this issue.

M.

On Sun, Jul 19, 2015 at 1:09 PM Jeremy Stanley  wrote:

> On 2015-07-19 06:58:17 + (+), Marton Kiss wrote:
> [...]
> > Do you think that the puppet-agent was disabled on that host due the
> > smartcn failure? The last update was on July 15. I put back the agent
> into
> > disabled state, until we resolve this issue.
> [...]
>
> Nope, as I explained in IRC last week, the cloudflare implementation
> breaks assumptions made by our puppetry (specifically, that our
> puppetmaster will be able to SSH to the server by its
> fully-qualified domain name, which is now a CNAME to some Web
> proxies somewhere). If there is a desire to actually use that, we
> would need to deploy a new server so that the hostname can be
> something other than the Web site name.
>
> However, when updating it manually, I do still get:
>
> Could not evaluate: Could not retrieve information from
> environment production source(s)
>
> file:/tmp/solr-4.10.4/contrib/analysis-extras/lucene-libs/lucene-analyzers-smartcn-4.10.4.jar
>
> --
> 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

Re: [OpenStack-Infra] Request for server for developer.openstack.org

[Marton Kiss]

Jekyll as an option for pre-rendering the html?

http://jekyllrb.com

Brgds,
  Marton Kiss

On Thu, Sep 3, 2015 at 8:31 PM Jeremy Stanley  wrote:

> On 2015-08-27 16:13:29 -0500 (-0500), Anne Gentle wrote:
> [...]
> > In order to serve API reference docs, we need a Pecan server on a cloud
> > server of some sort. I'm guessing this server could be deployed with
> Puppet
> > but I really don't know.
> >
> > The specification for revising API docs [1] gives some detail about the
> > fairy-slipper tool [2] being developed that gets us out of WADL and into
> > JSON. The JSON needs a Python web framework to host the reference
> content.
> > An example of the output is at [3].
> [...]
>
> Trying to summarize some of the subsequent discussion[1] which took
> place last week in #openstack-infra: while not ruling out the
> benefits of a separate server (particularly for interesting future
> additions like an interactive API sandbox), there are still good
> reasons to prefer processes which independently build static content
> for upload instead of regenerating the same content on demand on the
> server where it's hosted (since it can also be easily packaged and
> redistributed if it has a known state).
>
> An option worth looking into is whether fairy-slipper could be
> pointed at running services in a devstack-gate job to generate that
> JSON, and also perhaps whether the resulting JSON could be
> pre-rendered into its final state prior to upload to the Web site or
> if necessary integrated into a page template client-side with some
> Javascript.
>
> [1]  http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2015-08-28.log.html#t2015-08-28T20:20:45
> >
> --
> 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

[OpenStack-Infra] vcsrepo upstream

[Marton Kiss]

Dear all,

Actually openstack-infra/system-config is using the
openstack-infra/puppet-vcsrepo module for handling git repositories.

With Jeremy and Clark we found an issue related this vcsrepo module which
is a fork of original puppetlabs-vcsrepo, but not follow the upstream. I
made a little poc to demonstrate the issue, which is related to the refresh
event invocation of github repositories.

https://github.com/mkissam/puppet-vcsrepo-refresh-poc/blob/master/vcsrepo-refresh-poc.md

The story here, if we checking out a specific commit ref, every puppet run
will trigger a refresh event, even the repository not changed when we use
the ensure => latest class parameter.

The upstream have a patch that resolve this specific issue:
(MODULES-660) Correct detached HEAD on latest
https://github.com/puppetlabs/puppetlabs-vcsrepo/commit/6624f40651f44e184878a9fbb862bda886d899e8

I see to options here: backport the patch from upstream or as an
alternative, drop openstack-infra/puppet-vcsrepo and use upstream one.

The question here, what was the exact reason of forking vcsepo? Can we go
with backport, or freely upgrade the system-config to consume upstream
vcsrepo?

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

Re: [OpenStack-Infra] vcsrepo upstream

[Marton Kiss]

The git puppet module requires some additional work, not looks stable for
me. It have RedHat support only, and it won't work for askbot, because
those instances based on Ubuntu 14.04LTS actually. I guess we need a stable
solution within a reasonable timeframe. Git puppet should evolve, but I see
no new commits in the last 6months.

Brgds,
  Marton

On Tue, Sep 15, 2015 at 9:05 PM Paul Belanger  wrote:

> On Tue, Sep 15, 2015 at 06:09:45PM +, Marton Kiss wrote:
> > Dear all,
> >
> > Actually openstack-infra/system-config is using the
> > openstack-infra/puppet-vcsrepo module for handling git repositories.
> >
> > With Jeremy and Clark we found an issue related this vcsrepo module which
> > is a fork of original puppetlabs-vcsrepo, but not follow the upstream. I
> > made a little poc to demonstrate the issue, which is related to the
> refresh
> > event invocation of github repositories.
> >
> >
> https://github.com/mkissam/puppet-vcsrepo-refresh-poc/blob/master/vcsrepo-refresh-poc.md
> >
> > The story here, if we checking out a specific commit ref, every puppet
> run
> > will trigger a refresh event, even the repository not changed when we use
> > the ensure => latest class parameter.
> >
> > The upstream have a patch that resolve this specific issue:
> > (MODULES-660) Correct detached HEAD on latest
> >
> https://github.com/puppetlabs/puppetlabs-vcsrepo/commit/6624f40651f44e184878a9fbb862bda886d899e8
> >
> > I see to options here: backport the patch from upstream or as an
> > alternative, drop openstack-infra/puppet-vcsrepo and use upstream one.
> >
> > The question here, what was the exact reason of forking vcsepo? Can we go
> > with backport, or freely upgrade the system-config to consume upstream
> > vcsrepo?
> >
> I think a 3rd option is to remove the dependency on vcsrepo all together.
> IIRC,
> nibalizer has started the ball rolling on the migration.  A new puppet
> module,
> puppet-git, has been added into our modules for the purpose of replacing
> vcsrepo.
>
> I am unsure of the progress, but maybe this issue can help move it along.
>
> [1] https://github.com/nanliu/puppet-git
> > 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
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] vcsrepo upstream

[Marton Kiss]

Thanks, I'll retry from this puppet-community repo.

Brgds,
  Marton

On Wed, Sep 16, 2015 at 6:01 PM Colleen Murphy  wrote:

> On Wed, Sep 16, 2015 at 2:00 AM, Marton Kiss 
> wrote:
> 
>
>> It have RedHat support only
>>
> 
>
> It supports Ubuntu as well. The git class, which only supports RedHat,
> just installs git from repoforge. On Ubuntu we would just manage this with
> a package resource. The git resource, which is the replacement for the
> vcsrepo resource, supports anything with git installed.
>
> 
>
>>  I see no new commits in the last 6months.
>>
> 
>
> The module was moved to puppet-community (and the class was split out) and
> has seen activity in the last two months:
>
> https://github.com/puppet-community/puppet-git_resource
>
> Colleen
> ___
> 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] vcsrepo upstream

[Marton Kiss]

Hi Colleen,

Have you ever tried this puppet-community puppet-git_resource module? It
seems to be that it is not ready, the resource auto-depends on a git class
here:
https://github.com/puppet-community/puppet-git_resource/blob/04ec35488c4d0d5374c736daa4a7e89fbf3e8d84/lib/puppet/type/git.rb#L86

but it was never declared anywhere, the whole manifests directory is
missing from the repo. (it was present in nanliu's version)

Brgds,
  Marton

On Wed, Sep 16, 2015 at 6:04 PM Marton Kiss  wrote:

> Thanks, I'll retry from this puppet-community repo.
>
> Brgds,
>   Marton
>
> On Wed, Sep 16, 2015 at 6:01 PM Colleen Murphy 
> wrote:
>
>> On Wed, Sep 16, 2015 at 2:00 AM, Marton Kiss 
>> wrote:
>> 
>>
>>> It have RedHat support only
>>>
>> 
>>
>> It supports Ubuntu as well. The git class, which only supports RedHat,
>> just installs git from repoforge. On Ubuntu we would just manage this with
>> a package resource. The git resource, which is the replacement for the
>> vcsrepo resource, supports anything with git installed.
>>
>> 
>>
>>>  I see no new commits in the last 6months.
>>>
>> 
>>
>> The module was moved to puppet-community (and the class was split out)
>> and has seen activity in the last two months:
>>
>> https://github.com/puppet-community/puppet-git_resource
>>
>> Colleen
>> ___
>> 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] vcsrepo upstream

[Marton Kiss]

Colleen,

Thank you for the infos, sowe have three options now, and
- openstack-infra/puppet-vcsrepo requires a patch backport
- puppet-community/puppet-git_resource require some extra work
- upstream puppet-vcsrepo: what are the arguments against that?

M.

On Wed, Sep 16, 2015 at 8:23 PM Colleen Murphy  wrote:

> On Wed, Sep 16, 2015 at 11:12 AM, Marton Kiss 
> wrote:
>
>> Hi Colleen,
>>
>> Have you ever tried this puppet-community puppet-git_resource module? It
>> seems to be that it is not ready, the resource auto-depends on a git class
>> here:
>>
>> https://github.com/puppet-community/puppet-git_resource/blob/04ec35488c4d0d5374c736daa4a7e89fbf3e8d84/lib/puppet/type/git.rb#L86
>>
>> but it was never declared anywhere, the whole manifests directory is
>> missing from the repo. (it was present in nanliu's version)
>>
>> Brgds,
>>   Marton
>>
> I've not personally used it, no.
>
> An autorequire will add a require relationship to a resource only if that
> resource is in the catalog, so autorequiring a class that is no longer in
> the module will not cause any problems.
>
> I have not seen the discussion, but what I suspect happened is that there
> is another module from puppetlabs that is also called 'git', but it manages
> the installation and configuration of git, not git repositories. I expect
> they renamed the module and removed the class in order to be compatible
> with the other module.
>
> #puppet-community would be a good place to inquire about this module.
>
> Colleen
> ___
> 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] vcsrepo upstream

[Marton Kiss]

I was playing with an alternative workaround, where the askbot exec
resources extended with a conditional check of git HEAD status. I made a
quick poc, you can find it here:
https://github.com/mkissam/puppet-vcsrepo-refresh-poc/blob/master/vcsrepo-refresh-workaround.md

The test results are the following:
pros:
  - it is skipping the execution of exec commands when the git HEAD was not
changed since the last successfull run
cons:
  - it is doing the command exception skip in a silent way, and it is
impossible to determine from the report whether the command was executed or
not
  - the report is still full with refresh event triggers on dependent
resources

So my personal opinion that this workaround not solves our original problem
of refresh event triggers, basically it is working, but totally hiding
relevant information, and makes later debugging or problem discovery
impossible.

If we fear that switching to upstream vcsrepo, or even back porting the fix
from upstream can harm our existing infrastructure, I suggest to finish the
puppet-git module suggested by Colleen, deploy it next to our vcsrepo
module in system-config. So we can easily switch on a per-project basic,
and won't risk ruining the whole infrastructure.

Brgds,
  Marton

On Wed, Sep 16, 2015 at 8:48 PM Marton Kiss  wrote:

> Colleen,
>
> Thank you for the infos, sowe have three options now, and
> - openstack-infra/puppet-vcsrepo requires a patch backport
> - puppet-community/puppet-git_resource require some extra work
> - upstream puppet-vcsrepo: what are the arguments against that?
>
> M.
>
> On Wed, Sep 16, 2015 at 8:23 PM Colleen Murphy 
> wrote:
>
>> On Wed, Sep 16, 2015 at 11:12 AM, Marton Kiss 
>> wrote:
>>
>>> Hi Colleen,
>>>
>>> Have you ever tried this puppet-community puppet-git_resource module? It
>>> seems to be that it is not ready, the resource auto-depends on a git class
>>> here:
>>>
>>> https://github.com/puppet-community/puppet-git_resource/blob/04ec35488c4d0d5374c736daa4a7e89fbf3e8d84/lib/puppet/type/git.rb#L86
>>>
>>> but it was never declared anywhere, the whole manifests directory is
>>> missing from the repo. (it was present in nanliu's version)
>>>
>>> Brgds,
>>>   Marton
>>>
>> I've not personally used it, no.
>>
>> An autorequire will add a require relationship to a resource only if that
>> resource is in the catalog, so autorequiring a class that is no longer in
>> the module will not cause any problems.
>>
>> I have not seen the discussion, but what I suspect happened is that there
>> is another module from puppetlabs that is also called 'git', but it manages
>> the installation and configuration of git, not git repositories. I expect
>> they renamed the module and removed the class in order to be compatible
>> with the other module.
>>
>> #puppet-community would be a good place to inquire about this module.
>>
>> Colleen
>> ___
>> 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] vcsrepo upstream

[Marton Kiss]

Yeah, this temporary fix solves the going offline thingy:
https://review.openstack.org/#/c/222653/

Sitting in the queue for a while, a +2 approval could help to stop refresh
triggers on ask.o.o

M.

On Wed, Sep 23, 2015 at 2:12 PM Jeremy Stanley  wrote:

> On 2015-09-23 07:40:38 + (+), Marton Kiss wrote:
> [...]
> > So my personal opinion that this workaround not solves our
> > original problem of refresh event triggers, basically it is
> > working, but totally hiding relevant information, and makes later
> > debugging or problem discovery impossible.
> [...]
>
> It wasn't being suggested as a permanent fix, just as a quick
> workaround so that ask.openstack.org will stop going offline for
> several minutes every hour while we have an opportunity to carefully
> work through a better but possibly more risky transition to more
> recent version of the vcsrepo module or to another module entirely.
> --
> 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

Re: [OpenStack-Infra] vcsrepo upstream

[Marton Kiss]

I hope we can fix that refresh issue within a reasonable timeframe, and
this change won't affect the new releases of production ask.o.o.

M.

On Wed, Sep 23, 2015 at 4:56 PM Jeremy Stanley  wrote:

> On 2015-09-23 12:19:22 + (+), Marton Kiss wrote:
> > Yeah, this temporary fix solves the going offline thingy:
> > https://review.openstack.org/#/c/222653/
> >
> > Sitting in the queue for a while, a +2 approval could help to stop
> refresh
> > triggers on ask.o.o
>
> As a very temporary measure I've approved it, but Clark expressed a
> concern that this results in no longer updating automatically (so
> any change to the ref for ask.openstack.org will need setting
> askbot_ensure=>latest briefly and then =>present again once the
> upgrade takes place). This also means ask-staging will stop
> following the development branch unless we override
> askbot_ensure=>latest for it.
> --
> 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

Re: [OpenStack-Infra] vcsrepo upstream

[Marton Kiss]

+1 to git_resource module. Anyway it needs some care to fix issues, and it
is a bit more then documentation things. For example this direct dependency
on a non-existent git class:
https://github.com/puppet-community/puppet-git_resource/blob/master/lib/puppet/type/git.rb#L86

The git class was included in nanilu's original repo, but was tied directly
to RedHat, and the puppet run failed on a non-rh environment.

M.

On Wed, Sep 23, 2015 at 8:24 PM Spencer Krum  wrote:

> My preference is to use the puppet-community-git_resource module, it
> provides an easy way to transition and can be opinionated about the git
> functionality we want. I've heard from many people that the module only
> supports redhat, which isn't true. But I think we should view that as a
> documentation bug and fix it if we can.
>
> On Wed, Sep 23, 2015 at 8:31 AM, Marton Kiss 
> wrote:
>
>> I hope we can fix that refresh issue within a reasonable timeframe, and
>> this change won't affect the new releases of production ask.o.o.
>>
>> M.
>>
>> On Wed, Sep 23, 2015 at 4:56 PM Jeremy Stanley  wrote:
>>
>>> On 2015-09-23 12:19:22 + (+), Marton Kiss wrote:
>>> > Yeah, this temporary fix solves the going offline thingy:
>>> > https://review.openstack.org/#/c/222653/
>>> >
>>> > Sitting in the queue for a while, a +2 approval could help to stop
>>> refresh
>>> > triggers on ask.o.o
>>>
>>> As a very temporary measure I've approved it, but Clark expressed a
>>> concern that this results in no longer updating automatically (so
>>> any change to the ref for ask.openstack.org will need setting
>>> askbot_ensure=>latest briefly and then =>present again once the
>>> upgrade takes place). This also means ask-staging will stop
>>> following the development branch unless we override
>>> askbot_ensure=>latest for it.
>>> --
>>> 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
>>
>>
>
>
> --
> Spencer Krum
> (619)-980-7820
> ___
> 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] Moving wiki.o.o to OpenStackID login?

[Marton Kiss]

Hey Jeremy,

The askbot have an alternate solution for login mapping, the only drawback
that you cannot do it automatically. So if you login with your launchpad
account, and you login with your openstackid account meanwhile the
launchpad session is active, the user account will be tied for both login
providers. So this is the technical part.

I think we can enforce moving users with a proper communication:
- define a migration period (1 year for example)
- send this update around on mailing lists, social channels, superuser
magazine, user groups, summits, events, etc.
- add a notification about this upgrade period to login UI of every site.

If someone won't login within the 1year period it means, he is not an
active user, so we cannot lost any important users. So after 1yr, we can
disable the launchpad login, and support a manual migration way. Usually it
is very easy to tie together the user accounts based on email address,
because most of the sites are getting this information from the provider.
It is possible to automate account merge based on emails, but it requires
much more development from our side. (I think even gerrit have the email
address somewhere internally)

Brgds,
  Marton

On Thu, Feb 11, 2016 at 4:12 PM Jeremy Stanley  wrote:

> On 2016-02-11 22:38:34 +0800 (+0800), Tom Fifield wrote:
> > I believe a while back we talked about moving wiki.o.o to use the
> > OpenStackID.
> >
> > Knowing MediaWiki it's probably pretty hard, but is it something
> > that's on the radar these days?
>
> As with migrating any of the existing systems from
> login.launchpad.net to openstackid.org, the biggest complication is
> coming up with a means of mapping accounts on one to accounts on the
> other. This is especially challenging as the two do not necessarily
> share any common key and may in the cases of many accounts share no
> common data at all. What we need to decide is whether we make some
> best-effort attempt to map up what accounts we can, or just punt and
> expect everyone to end up with new accounts. I'm open to either
> option but others may have stronger opinions on continuity there.
> --
> 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

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

[Marton Kiss]

Tom,

I can help in infra contribution if required, but don't expect a quick
resolution, as the infra team is hell overloaded. This is the process:
- setup the same wiki in local dev env using infra puppet to make sure we
are not breaking anything irreversible in production
- create the patch
- deliver the patch to ci
- nagging infra core reviewers (hardest part)
- we can beg for an account to execute cleanup scripts to remove spam
content automagically

Cheers,
Marton
JP Maxwell  (időpont: 2016. febr. 23., K, 8:59) ezt írta:

> One final thought, I recall on the mobile view there is a secret word
> request in the account creation page:
>
>
> https://wiki.openstack.org/w/index.php?title=Special:UserLogin&type=signup&returnto=Main+Page&returntoquery=mobileaction%3Dtoggle_view_mobile%26welcome%3Dyes
>
> So, this is probably already setup.  It's possible you only need to add
> the triggers.   Though I might make the question something a human could
> reasonably figure out if you want people to continue to be able to edit the
> wiki in the meantime:
>
>
> $wgCaptchaTriggers['edit']  = true;
> $wgCaptchaTriggers['create']= true;
>
> J.P. Maxwell / tipit.net 
>
>
> On Tue, Feb 23, 2016 at 1:48 AM, JP Maxwell  wrote:
>
>> Hah. Well, I'm not entirely sure how this is setup to manage code
>> changes.  I looked in GitHub and just see the puppet configs.  Not sure
>> where or how I could push changes into LocalSettings.php, otherwise I'd be
>> happy to do it :D   Gotta catch a little rest now, but will check in on
>> this in a few hours.
>>
>> J.P. Maxwell / tipit.net 
>>
>>
>> On Tue, Feb 23, 2016 at 1:43 AM, Tom Fifield  wrote:
>>
>>> Cheers, that's exactly what we need someone to do.
>>>
>>>
>>> On 23/02/16 15:34, JP Maxwell wrote:
>>>
 OK - so per the info here, you have to set the type of Captcha and add
 in editing and create page as triggers requiring Captcha.

 As an example to use QuestyCaptcha a the bottom of the LocalSettings.php
 file:

 https://www.mediawiki.org/wiki/Extension:ConfirmEdit#QuestyCaptcha

 And make sure the triggers are set:

 https://www.mediawiki.org/wiki/Extension:ConfirmEdit#Configuration

 So, for example (you might want to change the questions), but the below
 should at least stop the bleeding?

 require_once "$IP/extensions/ConfirmEdit/ConfirmEdit.php";

 // Use this line ONLY if your MediaWiki version is 1.25 or newer:
 //wfLoadExtension( 'ConfirmEdit/QuestyCaptcha' );
 // Use this line ONLY if your MediaWiki version is older than 1.25:
 require_once "$IP/extensions/ConfirmEdit/QuestyCaptcha.php";

 $wgCaptchaClass = 'QuestyCaptcha';

 // Add your questions in LocalSettings.php using this format
 $wgCaptchaQuestions[] = array( 'question' => "A question?", 'answer' =>
 "An Answer");
 $wgCaptchaQuestions[] = array( 'question' => 'How much wood would a
 woodchuck chuck if a woodchuck could chuck wood?', 'answer' => 'as much
 wood as...' );
 $wgCaptchaQuestions[] = array( 'question' => "What is this wiki's
 name?", 'answer' => "$wgSitename" );
 // You can also provide several acceptable answers to a given question
 (the answers shall be in lowercase):
 $wgCaptchaQuestions[] = array( 'question' => "2 + 2 ?", 'answer' =>
 array( '4', 'four' ) );

 $wgCaptchaTriggers['edit']  = true;
 $wgCaptchaTriggers['create']= true;


 J.P. Maxwell / tipit.net 


 On Tue, Feb 23, 2016 at 12:55 AM, Tom Fifield >>> > wrote:

 For wiki.o.o, I believe this is at:

 https://wiki.openstack.org/wiki/Special:Version

 On 23/02/16 14:51, JP Maxwell wrote:

 I did setup a wiki and have a look at this briefly.   Can you
 confirm
 what extensions you are loading?  When you setup the wiki it
 generates a
 localsettings.php file that lists the extensions:



 Inline image 1

 # Enabled Extensions. Most extensions are enabled by including
 the base
 extension file here
 # but check specific extension documentation for more details
 # The following extensions were automatically enabled:
 wfLoadExtension( 'ConfirmEdit' );
 wfLoadExtension( 'InputBox' );
 wfLoadExtension( 'SpamBlacklist' );
 wfLoadExtension( 'TitleBlacklist' );
 wfLoadExtension( 'WikiEditor' );

 I think if you have that ConfirmEdit extension you can enable
 captcha
 when creating new pages / editing existing ones.  In addition,
 there do
 seem to be some spam extensions that come built in.



>>>
>>
> _

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

[Marton Kiss]

It is using the openstack-infra's puppet-mediawiki module, and for first
sight this setting seems to be unmanaged by puppet. I not found any related
entries in system-config's wiki.pp. Would be great to ssh in, but just an
infra core have access for this instance. Maybe we could replace rlane's
account with mine, he is not maintaining the server as I know, but infra
reviewers used to refuse those changes. As I see this LocalSettings.php was
generated during the application installation process, but it could be
moved somehow to puppet modules.

I don't have this experience with mediawiki, but I think it is a typical
php app, and if it not implements an anti-pattern, we can add the config
file to puppet. But first of all we need to retrieve the existing file from
an infra member.

M.

On Tue, Feb 23, 2016 at 3:31 PM JP Maxwell  wrote:

> Thanks Marton. So is there a Git repo for the code or are you just relying
> on an upstream wiki media repository directly?  If so is this setting file
> populated by puppet or unmanaged?
>
> If the latter I would suggest we just ssh in and make the change to the
> file as the  wiki is being effectively owned by the spammers otherwise.
>
> Happy to do this or work with somebody on this...
>
> J.P. Maxwell | tipit.net | fibercove.com
> On Feb 23, 2016 3:40 AM, "Marton Kiss"  wrote:
>
>> Tom,
>>
>> I can help in infra contribution if required, but don't expect a quick
>> resolution, as the infra team is hell overloaded. This is the process:
>> - setup the same wiki in local dev env using infra puppet to make sure we
>> are not breaking anything irreversible in production
>> - create the patch
>> - deliver the patch to ci
>> - nagging infra core reviewers (hardest part)
>> - we can beg for an account to execute cleanup scripts to remove spam
>> content automagically
>>
>> Cheers,
>> Marton
>> JP Maxwell  (időpont: 2016. febr. 23., K, 8:59) ezt írta:
>>
>>> One final thought, I recall on the mobile view there is a secret word
>>> request in the account creation page:
>>>
>>>
>>> https://wiki.openstack.org/w/index.php?title=Special:UserLogin&type=signup&returnto=Main+Page&returntoquery=mobileaction%3Dtoggle_view_mobile%26welcome%3Dyes
>>>
>>> So, this is probably already setup.  It's possible you only need to add
>>> the triggers.   Though I might make the question something a human could
>>> reasonably figure out if you want people to continue to be able to edit the
>>> wiki in the meantime:
>>>
>>>
>>> $wgCaptchaTriggers['edit']  = true;
>>> $wgCaptchaTriggers['create']= true;
>>>
>>> J.P. Maxwell / tipit.net <http://www.tipit.net>
>>>
>>>
>>> On Tue, Feb 23, 2016 at 1:48 AM, JP Maxwell  wrote:
>>>
>>>> Hah. Well, I'm not entirely sure how this is setup to manage code
>>>> changes.  I looked in GitHub and just see the puppet configs.  Not sure
>>>> where or how I could push changes into LocalSettings.php, otherwise I'd be
>>>> happy to do it :D   Gotta catch a little rest now, but will check in on
>>>> this in a few hours.
>>>>
>>>> J.P. Maxwell / tipit.net <http://www.tipit.net>
>>>>
>>>>
>>>> On Tue, Feb 23, 2016 at 1:43 AM, Tom Fifield  wrote:
>>>>
>>>>> Cheers, that's exactly what we need someone to do.
>>>>>
>>>>>
>>>>> On 23/02/16 15:34, JP Maxwell wrote:
>>>>>
>>>>>> OK - so per the info here, you have to set the type of Captcha and add
>>>>>> in editing and create page as triggers requiring Captcha.
>>>>>>
>>>>>> As an example to use QuestyCaptcha a the bottom of the
>>>>>> LocalSettings.php
>>>>>> file:
>>>>>>
>>>>>> https://www.mediawiki.org/wiki/Extension:ConfirmEdit#QuestyCaptcha
>>>>>>
>>>>>> And make sure the triggers are set:
>>>>>>
>>>>>> https://www.mediawiki.org/wiki/Extension:ConfirmEdit#Configuration
>>>>>>
>>>>>> So, for example (you might want to change the questions), but the
>>>>>> below
>>>>>> should at least stop the bleeding?
>>>>>>
>>>>>> require_once "$IP/extensions/ConfirmEdit/ConfirmEdit.php";
>>>>>>
>>>>>> // Use this line ONLY if your 

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

[Marton Kiss]

I've deployed the mediawiki using our puppet modules to my dev machine, and
we have more problems here:
[image: The MediaWiki logo] MediaWiki 1.27 internal error

MediaWiki 1.27 requires at least PHP version 5.5.9, you are using PHP
5.3.10-1ubuntu3.21.
Supported PHP versions

Please consider upgrading your copy of PHP
. PHP versions less than 5.5.0 are no
longer supported by the PHP Group and will not receive security or bugfix
updates.

If for some reason you are unable to upgrade your PHP version, you will
need to download  an older version
of MediaWiki from our website. See our compatibility page
 for details of which
versions are compatible with prior versions of PHP.

The wiki.o.o seems to be running on precise, meanwhile the git consumed
repo simply not supporting the PHP version provided there.

M.

On Fri, Feb 26, 2016 at 5:19 AM JP Maxwell  wrote:

> Is it an option to put the question back to an impossible answer for even
> a little while? I think it would be very telling if the spam continues then
> there may be an exploit possibly tied to the launchpad SSO.  It would at
> least give a clue where to focus.
>
> J.P. Maxwell | tipit.net | fibercove.com
> On Feb 25, 2016 10:10 PM, "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.
>>
>> --
>> 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

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

[Marton Kiss]

Yeah, I'm waiting for my ssh access, it will arrive soon, so I can do a
proper clone of the site. Anyway it is interesting that mediawiki is
rendering a different output based on user agent.

M.

On Fri, Feb 26, 2016 at 2:41 PM JP Maxwell  wrote:

> Marton
>
> Make sure you are using the right upstream repository. They are in version
> 1.25. Check out: https://wiki.openstack.org/wiki/Special:Version
>
> Not that it shouldn't all be upgraded ;) be aware there seem to be config
> file formatting differences in the latest version vs 1.25 as well.
>
> J.P. Maxwell | tipit.net | fibercove.com
> On Feb 26, 2016 4:35 AM, "Marton Kiss"  wrote:
>
>> I've deployed the mediawiki using our puppet modules to my dev machine,
>> and we have more problems here:
>> [image: The MediaWiki logo] MediaWiki 1.27 internal error
>>
>> MediaWiki 1.27 requires at least PHP version 5.5.9, you are using PHP
>> 5.3.10-1ubuntu3.21.
>> Supported PHP versions
>>
>> Please consider upgrading your copy of PHP
>> <http://www.php.net/downloads.php>. PHP versions less than 5.5.0 are no
>> longer supported by the PHP Group and will not receive security or bugfix
>> updates.
>>
>> If for some reason you are unable to upgrade your PHP version, you will
>> need to download <https://www.mediawiki.org/wiki/Download> an older
>> version of MediaWiki from our website. See our compatibility page
>> <https://www.mediawiki.org/wiki/Compatibility#PHP> for details of which
>> versions are compatible with prior versions of PHP.
>>
>> The wiki.o.o seems to be running on precise, meanwhile the git consumed
>> repo simply not supporting the PHP version provided there.
>>
>> M.
>>
>> On Fri, Feb 26, 2016 at 5:19 AM JP Maxwell  wrote:
>>
>>> Is it an option to put the question back to an impossible answer for
>>> even a little while? I think it would be very telling if the spam continues
>>> then there may be an exploit possibly tied to the launchpad SSO.  It would
>>> at least give a clue where to focus.
>>>
>>> J.P. Maxwell | tipit.net | fibercove.com
>>> On Feb 25, 2016 10:10 PM, "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.
>>>>
>>>> --
>>>> 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

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

[Marton Kiss]

Oh, I can login. So what we need?

M.

On Fri, Feb 26, 2016 at 6:33 PM JP Maxwell  wrote:

> I think what Jimmy is referring to is what I was suggesting by removing
> the extensions / making the question impossible to answer.  Basically a
> series of rapid fire changes while tailing the logs and seeing what stops
> the spam.  Once you know what worked then you can submit as an official
> patch.  But being able to quickly try these things on a server actually
> under attack is the fastest path toward identifying the fix.
>
> *J.P. Maxwell* | tipit.net | 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 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 u

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

[Marton Kiss]

I see a ton of incoming post requests:

POST
/w/index.php?title=Special%3ARunJobs&tasks=jobs&maxjobs=1&sigexpiry=1456508270&signature=571cfb216f944b15d2eee1c0253d08b77003328e

M.

On Fri, Feb 26, 2016 at 6:35 PM Marton Kiss  wrote:

> Oh, I can login. So what we need?
>
> M.
>
> On Fri, Feb 26, 2016 at 6:33 PM JP Maxwell  wrote:
>
>> I think what Jimmy is referring to is what I was suggesting by removing
>> the extensions / making the question impossible to answer.  Basically a
>> series of rapid fire changes while tailing the logs and seeing what stops
>> the spam.  Once you know what worked then you can submit as an official
>> patch.  But being able to quickly try these things on a server actually
>> under attack is the fastest path toward identifying the fix.
>>
>> *J.P. Maxwell* | 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 ext

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

[Marton Kiss]

On the wiki instance, my ssh access is working now. What I see in the logs
are the continuous POST requests.

M.

On Fri, Feb 26, 2016 at 6:42 PM JP Maxwell  wrote:

> Marton
>
> Where are you seeing the logs?
>
> Paul
>
> The point is that to comment out a line in VI and watch the logs in
> another window takes about a minute or two.  To submit a patch, get
> approval, push, ask someone to share the logs takes a lot longer and relies
> on other people.
>
> I understand the need for openness and I appreciate the process and the
> automation.  I think Jimmy’s point was if we want a quick fix….
>
> *J.P. Maxwell* | tipit.net | fibercove.com <http://www.fibercove.com>
>
> On Fri, Feb 26, 2016 at 11:38 AM, Marton Kiss 
> wrote:
>
> I see a ton of incoming post requests:
>
> POST
> /w/index.php?title=Special%3ARunJobs&tasks=jobs&maxjobs=1&sigexpiry=1456508270&signature=571cfb216f944b15d2eee1c0253d08b77003328e
>
> M.
>
> On Fri, Feb 26, 2016 at 6:35 PM Marton Kiss  wrote:
>
>> Oh, I can login. So what we need?
>>
>> M.
>>
>> On Fri, Feb 26, 2016 at 6:33 PM JP Maxwell  wrote:
>>
>>> I think what Jimmy is referring to is what I was suggesting by removing
>>> the extensions / making the question impossible to answer. Basically a
>>> series of rapid fire changes while tailing the logs and seeing what stops
>>> the spam. Once you know what worked then you can submit as an official
>>> patch. But being able to quickly try these things on a server actually
>>> under attack is the fastest path toward identifying the fix.
>>>
>>> *J.P. Maxwell* | 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
>>

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

[Marton Kiss]

I'm going to get a dinner, but I'll be on irc after, so if I can help
somehow, I will be here. #openstack-infra mrmartin

M.

On Fri, Feb 26, 2016 at 6:51 PM Paul Belanger  wrote:

> On phone but patch puppet-mediawiki and enable captcha for all pages. We
> only did edit and create
> On Feb 26, 2016 10:38 AM, Marton Kiss  wrote:
>
> I see a ton of incoming post requests:
>
> POST
> /w/index.php?title=Special%3ARunJobs&tasks=jobs&maxjobs=1&sigexpiry=1456508270&signature=571cfb216f944b15d2eee1c0253d08b77003328e
>
> M.
>
> On Fri, Feb 26, 2016 at 6:35 PM Marton Kiss  wrote:
>
>> Oh, I can login. So what we need?
>>
>> M.
>>
>> On Fri, Feb 26, 2016 at 6:33 PM JP Maxwell  wrote:
>>
>>> I think what Jimmy is referring to is what I was suggesting by removing
>>> the extensions / making the question impossible to answer.  Basically a
>>> series of rapid fire changes while tailing the logs and seeing what stops
>>> the spam.  Once you know what worked then you can submit as an official
>>> patch.  But being able to quickly try these things on a server actually
>>> under attack is the fastest path toward identifying the fix.
>>>
>>> *J.P. Maxwell* | 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 F

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

[Marton Kiss]

Yeah, I checked it and it is internal job runner:
https://www.mediawiki.org/wiki/Manual:Job_queue

M.

On Fri, Feb 26, 2016 at 7:00 PM JP Maxwell  wrote:

> A quick google indicates this may be an unrelated issue that should be
> fixed, but I don’t *think* it is related to the spam.
>
> *J.P. Maxwell* | tipit.net | fibercove.com <http://www.fibercove.com>
>
> On Fri, Feb 26, 2016 at 11:56 AM, Marton Kiss 
> wrote:
>
> I'm going to get a dinner, but I'll be on irc after, so if I can help
> somehow, I will be here. #openstack-infra mrmartin
>
> M.
>
> On Fri, Feb 26, 2016 at 6:51 PM Paul Belanger  wrote:
>
>> On phone but patch puppet-mediawiki and enable captcha for all pages. We
>> only did edit and create
>> On Feb 26, 2016 10:38 AM, Marton Kiss  wrote:
>>
>> I see a ton of incoming post requests:
>>
>> POST
>> /w/index.php?title=Special%3ARunJobs&tasks=jobs&maxjobs=1&sigexpiry=1456508270&signature=571cfb216f944b15d2eee1c0253d08b77003328e
>>
>> M.
>>
>> On Fri, Feb 26, 2016 at 6:35 PM Marton Kiss 
>> wrote:
>>
>>> Oh, I can login. So what we need?
>>>
>>> M.
>>>
>>> On Fri, Feb 26, 2016 at 6:33 PM JP Maxwell  wrote:
>>>
>>>> I think what Jimmy is referring to is what I was suggesting by removing
>>>> the extensions / making the question impossible to answer. Basically a
>>>> series of rapid fire changes while tailing the logs and seeing what stops
>>>> the spam. Once you know what worked then you can submit as an official
>>>> patch. But being able to quickly try these things on a server actually
>>>> under attack is the fastest path toward identifying the fix.
>>>>
>>>> *J.P. Maxwell* | 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

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

[Marton Kiss]

Hi,

I created the following patch, infra cores must approve that:
https://review.openstack.org/285641 Add ssh key of JP Maxwell to wiki.o.o

Marton

On Sat, Feb 27, 2016 at 6:41 AM JP Maxwell  wrote:

> Marton has SSH access and applied a patch earlier today.  It appears the
> spam continues to flow:
>
>
> https://wiki.openstack.org/wiki/40_Thoughts_Of_Using_Open_Shelves_On_A_Kitchen
>
> Marton let me know if you can look at it some more or Infra if you want to
> give me SSH I'll do so as well in the morning (public key attached).
>
>
>
> ssh-rsa
> B3NzaC1yc2EBIwAAAQEA2b5I7Yff9FCrtRmSjpILUePi54Vbc8zqJTbzrIAQZGFLBi3xd2MLlhV5QVgpDBC9H3lGjbdnc81D3aFd3HwHT4dvvvyedT12PR3VDEpftdW84vw3jzdtALcayOQznjbGnScwvX5SgnRhNxuX9Rkh8qNvOsjYPUafRr9azkQoomJFkdNVI4Vb5DbLhTpt18FPeOf0UuqDt/J2tHI4SjZ3kjzr7Nbwpg8xGgANPNE0+2pJbwCA8YDt4g3bzfzvVafQs5o9Gfc9tudkR9ugQG1M+EWCgu42CleOwMTd/rYEB2fgNNPsZAWqwQfdPajVuk70EBKUEQSyoA09eEZX+xJN9Q==
> jpmax...@tipit.net
>
>
>
>
> J.P. Maxwell / tipit.net 
>
>
> On Fri, Feb 26, 2016 at 12:09 PM, Jimmy McArthur 
> wrote:
>
>> 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 

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

[Marton Kiss]

I made some investigation, and it seems to be that the spam pages are
created by accounts registered with password accounts, and the launchpad
openid auth is not affected at all.

So the spam script is creating accounts like this:
mysql> select * from user where user_name = 'CedricJamieson'\G;
*** 1. row ***
 user_id: 7494
   user_name: CedricJamieson
  user_real_name: Cedric Jamieson
   user_password:
:pbkdf2:sha256:1:128:Mlo9tdaP+38niZrrEka7Ow==:jEVnrTclkwIpE1RzJywDlrSvkY5G3idYwOwYRkv5O0J/MSHjY+gdhtKmArQ53v6/w7o8E1wXb2QOR6HdL5TPfOI1bswS/fYXVVYjPjkEEdxqZ8q9L5p2f3N6rEYpMfT5tk+wDiy+j5aimrHrGSga44hndAHgX9/SnqUyxlutDVY=
user_newpassword:
   user_newpass_time: NULL
  user_email: balashkina.evdok...@mail.ru
user_touched: 20160227052454
  user_token: 7c39e44e849fb0e2bfae8790d6cc1379
user_email_authenticated: NULL
user_email_token: be963ac3bd43e70ff2f323063c61e320
user_email_token_expires: 20160305052441
   user_registration: 20160227052441
  user_editcount: 2
   user_password_expires: NULL

The user_password field is always filled with a value, meanwhile this field
of non-infected user accounts with openid logins is empty.
We have 423 total accounts with passwords:
mysql> select count(*) from user where user_password != '';
+--+
| count(*) |
+--+
|  423 |
+--+
1 row in set (0.00 sec)

Mediawiki logs-in the newly created users without any preliminary email
confirmation, right after the registration. I disabled the standard user
login page, as described here:
https://www.mediawiki.org/wiki/Manual:Special_pages#Disabling_Special:UserLogin_and_Special:UserLogout_pages

And I made this patch to make it permanent:
https://review.openstack.org/285669 Disable standard password based auth

Just for the record, the last spam user account:
7536 | EarthaChester22

Marton


On Sat, Feb 27, 2016 at 8:31 AM Marton Kiss  wrote:

> Hi,
>
> I created the following patch, infra cores must approve that:
> https://review.openstack.org/285641 Add ssh key of JP Maxwell to wiki.o.o
>
> Marton
>
> On Sat, Feb 27, 2016 at 6:41 AM JP Maxwell  wrote:
>
>> Marton has SSH access and applied a patch earlier today.  It appears the
>> spam continues to flow:
>>
>>
>> https://wiki.openstack.org/wiki/40_Thoughts_Of_Using_Open_Shelves_On_A_Kitchen
>>
>> Marton let me know if you can look at it some more or Infra if you want
>> to give me SSH I'll do so as well in the morning (public key attached).
>>
>>
>>
>> ssh-rsa
>> B3NzaC1yc2EBIwAAAQEA2b5I7Yff9FCrtRmSjpILUePi54Vbc8zqJTbzrIAQZGFLBi3xd2MLlhV5QVgpDBC9H3lGjbdnc81D3aFd3HwHT4dvvvyedT12PR3VDEpftdW84vw3jzdtALcayOQznjbGnScwvX5SgnRhNxuX9Rkh8qNvOsjYPUafRr9azkQoomJFkdNVI4Vb5DbLhTpt18FPeOf0UuqDt/J2tHI4SjZ3kjzr7Nbwpg8xGgANPNE0+2pJbwCA8YDt4g3bzfzvVafQs5o9Gfc9tudkR9ugQG1M+EWCgu42CleOwMTd/rYEB2fgNNPsZAWqwQfdPajVuk70EBKUEQSyoA09eEZX+xJN9Q==
>> jpmax...@tipit.net
>>
>>
>>
>>
>> J.P. Maxwell / tipit.net <http://www.tipit.net>
>>
>>
>> On Fri, Feb 26, 2016 at 12:09 PM, Jimmy McArthur 
>> wrote:
>>
>>> 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 

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

[Marton Kiss]

And the mobile frontend will be disabled permanently with this patch:
https://review.openstack.org/285672 Disable mobile frontend

M.

On Sat, Feb 27, 2016 at 1:39 PM Marton Kiss  wrote:

> I made some investigation, and it seems to be that the spam pages are
> created by accounts registered with password accounts, and the launchpad
> openid auth is not affected at all.
>
> So the spam script is creating accounts like this:
> mysql> select * from user where user_name = 'CedricJamieson'\G;
> *** 1. row ***
>  user_id: 7494
>user_name: CedricJamieson
>   user_real_name: Cedric Jamieson
>user_password:
> :pbkdf2:sha256:1:128:Mlo9tdaP+38niZrrEka7Ow==:jEVnrTclkwIpE1RzJywDlrSvkY5G3idYwOwYRkv5O0J/MSHjY+gdhtKmArQ53v6/w7o8E1wXb2QOR6HdL5TPfOI1bswS/fYXVVYjPjkEEdxqZ8q9L5p2f3N6rEYpMfT5tk+wDiy+j5aimrHrGSga44hndAHgX9/SnqUyxlutDVY=
> user_newpassword:
>user_newpass_time: NULL
>   user_email: balashkina.evdok...@mail.ru
> user_touched: 20160227052454
>   user_token: 7c39e44e849fb0e2bfae8790d6cc1379
> user_email_authenticated: NULL
> user_email_token: be963ac3bd43e70ff2f323063c61e320
> user_email_token_expires: 20160305052441
>user_registration: 20160227052441
>   user_editcount: 2
>user_password_expires: NULL
>
> The user_password field is always filled with a value, meanwhile this
> field of non-infected user accounts with openid logins is empty.
> We have 423 total accounts with passwords:
> mysql> select count(*) from user where user_password != '';
> +--+
> | count(*) |
> +--+
> |  423 |
> +--+
> 1 row in set (0.00 sec)
>
> Mediawiki logs-in the newly created users without any preliminary email
> confirmation, right after the registration. I disabled the standard user
> login page, as described here:
> https://www.mediawiki.org/wiki/Manual:Special_pages#Disabling_Special:UserLogin_and_Special:UserLogout_pages
>
> And I made this patch to make it permanent:
> https://review.openstack.org/285669 Disable standard password based auth
>
> Just for the record, the last spam user account:
> 7536 | EarthaChester22
>
> Marton
>
>
> On Sat, Feb 27, 2016 at 8:31 AM Marton Kiss  wrote:
>
>> Hi,
>>
>> I created the following patch, infra cores must approve that:
>> https://review.openstack.org/285641 Add ssh key of JP Maxwell to wiki.o.o
>>
>> Marton
>>
>> On Sat, Feb 27, 2016 at 6:41 AM JP Maxwell  wrote:
>>
>>> Marton has SSH access and applied a patch earlier today.  It appears the
>>> spam continues to flow:
>>>
>>>
>>> https://wiki.openstack.org/wiki/40_Thoughts_Of_Using_Open_Shelves_On_A_Kitchen
>>>
>>> Marton let me know if you can look at it some more or Infra if you want
>>> to give me SSH I'll do so as well in the morning (public key attached).
>>>
>>>
>>>
>>> ssh-rsa
>>> B3NzaC1yc2EBIwAAAQEA2b5I7Yff9FCrtRmSjpILUePi54Vbc8zqJTbzrIAQZGFLBi3xd2MLlhV5QVgpDBC9H3lGjbdnc81D3aFd3HwHT4dvvvyedT12PR3VDEpftdW84vw3jzdtALcayOQznjbGnScwvX5SgnRhNxuX9Rkh8qNvOsjYPUafRr9azkQoomJFkdNVI4Vb5DbLhTpt18FPeOf0UuqDt/J2tHI4SjZ3kjzr7Nbwpg8xGgANPNE0+2pJbwCA8YDt4g3bzfzvVafQs5o9Gfc9tudkR9ugQG1M+EWCgu42CleOwMTd/rYEB2fgNNPsZAWqwQfdPajVuk70EBKUEQSyoA09eEZX+xJN9Q==
>>> jpmax...@tipit.net
>>>
>>>
>>>
>>>
>>> J.P. Maxwell / tipit.net <http://www.tipit.net>
>>>
>>>
>>> On Fri, Feb 26, 2016 at 12:09 PM, Jimmy McArthur 
>>> wrote:
>>>
>>>> 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 

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

[Marton Kiss]

Yes, applied them manually. Let's wait a few hours, and check for new spam
content / user accounts.

M.
JP Maxwell  (időpont: 2016. febr. 27., Szo, 13:50) ezt írta:

> Cool. Are these applied? Any indication it has stopped the spam? Should we
> clear out these non launchpad accounts from the DB?
>
> J.P. Maxwell | tipit.net | fibercove.com
> On Feb 27, 2016 6:47 AM, "Marton Kiss"  wrote:
>
>> And the mobile frontend will be disabled permanently with this patch:
>> https://review.openstack.org/285672 Disable mobile frontend
>>
>> M.
>>
>> On Sat, Feb 27, 2016 at 1:39 PM Marton Kiss 
>> wrote:
>>
>>> I made some investigation, and it seems to be that the spam pages are
>>> created by accounts registered with password accounts, and the launchpad
>>> openid auth is not affected at all.
>>>
>>> So the spam script is creating accounts like this:
>>> mysql> select * from user where user_name = 'CedricJamieson'\G;
>>> *** 1. row ***
>>>  user_id: 7494
>>>user_name: CedricJamieson
>>>   user_real_name: Cedric Jamieson
>>>user_password:
>>> :pbkdf2:sha256:1:128:Mlo9tdaP+38niZrrEka7Ow==:jEVnrTclkwIpE1RzJywDlrSvkY5G3idYwOwYRkv5O0J/MSHjY+gdhtKmArQ53v6/w7o8E1wXb2QOR6HdL5TPfOI1bswS/fYXVVYjPjkEEdxqZ8q9L5p2f3N6rEYpMfT5tk+wDiy+j5aimrHrGSga44hndAHgX9/SnqUyxlutDVY=
>>> user_newpassword:
>>>user_newpass_time: NULL
>>>   user_email: balashkina.evdok...@mail.ru
>>> user_touched: 20160227052454
>>>   user_token: 7c39e44e849fb0e2bfae8790d6cc1379
>>> user_email_authenticated: NULL
>>> user_email_token: be963ac3bd43e70ff2f323063c61e320
>>> user_email_token_expires: 20160305052441
>>>user_registration: 20160227052441
>>>   user_editcount: 2
>>>user_password_expires: NULL
>>>
>>> The user_password field is always filled with a value, meanwhile this
>>> field of non-infected user accounts with openid logins is empty.
>>> We have 423 total accounts with passwords:
>>> mysql> select count(*) from user where user_password != '';
>>> +--+
>>> | count(*) |
>>> +--+
>>> |  423 |
>>> +--+
>>> 1 row in set (0.00 sec)
>>>
>>> Mediawiki logs-in the newly created users without any preliminary email
>>> confirmation, right after the registration. I disabled the standard user
>>> login page, as described here:
>>> https://www.mediawiki.org/wiki/Manual:Special_pages#Disabling_Special:UserLogin_and_Special:UserLogout_pages
>>>
>>> And I made this patch to make it permanent:
>>> https://review.openstack.org/285669 Disable standard password based auth
>>>
>>> Just for the record, the last spam user account:
>>> 7536 | EarthaChester22
>>>
>>> Marton
>>>
>>>
>>> On Sat, Feb 27, 2016 at 8:31 AM Marton Kiss 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I created the following patch, infra cores must approve that:
>>>> https://review.openstack.org/285641 Add ssh key of JP Maxwell to
>>>> wiki.o.o
>>>>
>>>> Marton
>>>>
>>>> On Sat, Feb 27, 2016 at 6:41 AM JP Maxwell  wrote:
>>>>
>>>>> Marton has SSH access and applied a patch earlier today.  It appears
>>>>> the spam continues to flow:
>>>>>
>>>>>
>>>>> https://wiki.openstack.org/wiki/40_Thoughts_Of_Using_Open_Shelves_On_A_Kitchen
>>>>>
>>>>> Marton let me know if you can look at it some more or Infra if you
>>>>> want to give me SSH I'll do so as well in the morning (public key
>>>>> attached).
>>>>>
>>>>>
>>>>>
>>>>> ssh-rsa
>>>>> B3NzaC1yc2EBIwAAAQEA2b5I7Yff9FCrtRmSjpILUePi54Vbc8zqJTbzrIAQZGFLBi3xd2MLlhV5QVgpDBC9H3lGjbdnc81D3aFd3HwHT4dvvvyedT12PR3VDEpftdW84vw3jzdtALcayOQznjbGnScwvX5SgnRhNxuX9Rkh8qNvOsjYPUafRr9azkQoomJFkdNVI4Vb5DbLhTpt18FPeOf0UuqDt/J2tHI4SjZ3kjzr7Nbwpg8xGgANPNE0+2pJbwCA8YDt4g3bzfzvVafQs5o9Gfc9tudkR9ugQG1M+EWCgu42CleOwMTd/rYEB2fgNNPsZAWqwQfdPajVuk70EBKUEQSyoA09eEZX+xJN9Q==
>>>>> jpmax...@tipit.net
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> J.P. Maxwell / tipit.net <http://www.tipit.net>
>>>>>
&

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

[Marton Kiss]

Yeah, the Settings.php was overriden by the latest puppet run. We need to
wait for some infra guys to approve my patches and make it permanent:
https://review.openstack.org/285669 Disable standard password based auth
https://review.openstack.org/285672 Disable mobile frontend

M.

On Sat, Feb 27, 2016 at 2:27 PM JP Maxwell  wrote:

> FYI. Still seeing the mobile view...
>
> J.P. Maxwell | tipit.net | fibercove.com
> On Feb 27, 2016 6:53 AM, "Marton Kiss"  wrote:
>
>> Yes, applied them manually. Let's wait a few hours, and check for new
>> spam content / user accounts.
>>
>> M.
>> JP Maxwell  (időpont: 2016. febr. 27., Szo, 13:50) ezt
>> írta:
>>
>>> Cool. Are these applied? Any indication it has stopped the spam? Should
>>> we clear out these non launchpad accounts from the DB?
>>>
>>> J.P. Maxwell | tipit.net | fibercove.com
>>> On Feb 27, 2016 6:47 AM, "Marton Kiss"  wrote:
>>>
>>>> And the mobile frontend will be disabled permanently with this patch:
>>>> https://review.openstack.org/285672 Disable mobile frontend
>>>>
>>>> M.
>>>>
>>>> On Sat, Feb 27, 2016 at 1:39 PM Marton Kiss 
>>>> wrote:
>>>>
>>>>> I made some investigation, and it seems to be that the spam pages are
>>>>> created by accounts registered with password accounts, and the launchpad
>>>>> openid auth is not affected at all.
>>>>>
>>>>> So the spam script is creating accounts like this:
>>>>> mysql> select * from user where user_name = 'CedricJamieson'\G;
>>>>> *** 1. row ***
>>>>>  user_id: 7494
>>>>>user_name: CedricJamieson
>>>>>   user_real_name: Cedric Jamieson
>>>>>user_password:
>>>>> :pbkdf2:sha256:1:128:Mlo9tdaP+38niZrrEka7Ow==:jEVnrTclkwIpE1RzJywDlrSvkY5G3idYwOwYRkv5O0J/MSHjY+gdhtKmArQ53v6/w7o8E1wXb2QOR6HdL5TPfOI1bswS/fYXVVYjPjkEEdxqZ8q9L5p2f3N6rEYpMfT5tk+wDiy+j5aimrHrGSga44hndAHgX9/SnqUyxlutDVY=
>>>>> user_newpassword:
>>>>>user_newpass_time: NULL
>>>>>   user_email: balashkina.evdok...@mail.ru
>>>>> user_touched: 20160227052454
>>>>>   user_token: 7c39e44e849fb0e2bfae8790d6cc1379
>>>>> user_email_authenticated: NULL
>>>>> user_email_token: be963ac3bd43e70ff2f323063c61e320
>>>>> user_email_token_expires: 20160305052441
>>>>>user_registration: 20160227052441
>>>>>   user_editcount: 2
>>>>>user_password_expires: NULL
>>>>>
>>>>> The user_password field is always filled with a value, meanwhile this
>>>>> field of non-infected user accounts with openid logins is empty.
>>>>> We have 423 total accounts with passwords:
>>>>> mysql> select count(*) from user where user_password != '';
>>>>> +--+
>>>>> | count(*) |
>>>>> +--+
>>>>> |  423 |
>>>>> +--+
>>>>> 1 row in set (0.00 sec)
>>>>>
>>>>> Mediawiki logs-in the newly created users without any preliminary
>>>>> email confirmation, right after the registration. I disabled the standard
>>>>> user login page, as described here:
>>>>> https://www.mediawiki.org/wiki/Manual:Special_pages#Disabling_Special:UserLogin_and_Special:UserLogout_pages
>>>>>
>>>>> And I made this patch to make it permanent:
>>>>> https://review.openstack.org/285669 Disable standard password based
>>>>> auth
>>>>>
>>>>> Just for the record, the last spam user account:
>>>>> 7536 | EarthaChester22
>>>>>
>>>>> Marton
>>>>>
>>>>>
>>>>> On Sat, Feb 27, 2016 at 8:31 AM Marton Kiss 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I created the following patch, infra cores must approve that:
>>>>>> https://review.openstack.org/285641 Add ssh key of JP Maxwell to
>>>>>> wiki.o.o
>>>>>>
>>>>>> Marton
>>>>>>
>>>>>> On Sat, Feb 27, 2016 at 6:41 AM JP Maxwell  wrote:
>>>>>>
>>>>&g

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

[Marton Kiss]

Ok, I'll be there.

M.

On Sat, Feb 27, 2016 at 5:15 PM Elizabeth K. Joseph 
wrote:

> We'll be getting together on Monday around 1700 UTC to work through this
> together in a debug session in #openstack-infra (I'm too sick this weekend,
> plus we need a time when more infra-root folks with the institutional
> knowledge are around).
> On Feb 27, 2016 05:37, "Marton Kiss"  wrote:
>
>> Yeah, the Settings.php was overriden by the latest puppet run. We need to
>> wait for some infra guys to approve my patches and make it permanent:
>> https://review.openstack.org/285669 Disable standard password based auth
>> https://review.openstack.org/285672 Disable mobile frontend
>>
>> M.
>>
>> On Sat, Feb 27, 2016 at 2:27 PM JP Maxwell  wrote:
>>
>>> FYI. Still seeing the mobile view...
>>>
>>> J.P. Maxwell | tipit.net | fibercove.com
>>> On Feb 27, 2016 6:53 AM, "Marton Kiss"  wrote:
>>>
>>>> Yes, applied them manually. Let's wait a few hours, and check for new
>>>> spam content / user accounts.
>>>>
>>>> M.
>>>> JP Maxwell  (időpont: 2016. febr. 27., Szo, 13:50) ezt
>>>> írta:
>>>>
>>>>> Cool. Are these applied? Any indication it has stopped the spam?
>>>>> Should we clear out these non launchpad accounts from the DB?
>>>>>
>>>>> J.P. Maxwell | tipit.net | fibercove.com
>>>>> On Feb 27, 2016 6:47 AM, "Marton Kiss"  wrote:
>>>>>
>>>>>> And the mobile frontend will be disabled permanently with this patch:
>>>>>> https://review.openstack.org/285672 Disable mobile frontend
>>>>>>
>>>>>> M.
>>>>>>
>>>>>> On Sat, Feb 27, 2016 at 1:39 PM Marton Kiss 
>>>>>> wrote:
>>>>>>
>>>>>>> I made some investigation, and it seems to be that the spam pages
>>>>>>> are created by accounts registered with password accounts, and the
>>>>>>> launchpad openid auth is not affected at all.
>>>>>>>
>>>>>>> So the spam script is creating accounts like this:
>>>>>>> mysql> select * from user where user_name = 'CedricJamieson'\G;
>>>>>>> *** 1. row ***
>>>>>>>  user_id: 7494
>>>>>>>user_name: CedricJamieson
>>>>>>>   user_real_name: Cedric Jamieson
>>>>>>>user_password:
>>>>>>> :pbkdf2:sha256:1:128:Mlo9tdaP+38niZrrEka7Ow==:jEVnrTclkwIpE1RzJywDlrSvkY5G3idYwOwYRkv5O0J/MSHjY+gdhtKmArQ53v6/w7o8E1wXb2QOR6HdL5TPfOI1bswS/fYXVVYjPjkEEdxqZ8q9L5p2f3N6rEYpMfT5tk+wDiy+j5aimrHrGSga44hndAHgX9/SnqUyxlutDVY=
>>>>>>> user_newpassword:
>>>>>>>user_newpass_time: NULL
>>>>>>>   user_email: balashkina.evdok...@mail.ru
>>>>>>> user_touched: 20160227052454
>>>>>>>   user_token: 7c39e44e849fb0e2bfae8790d6cc1379
>>>>>>> user_email_authenticated: NULL
>>>>>>> user_email_token: be963ac3bd43e70ff2f323063c61e320
>>>>>>> user_email_token_expires: 20160305052441
>>>>>>>user_registration: 20160227052441
>>>>>>>   user_editcount: 2
>>>>>>>user_password_expires: NULL
>>>>>>>
>>>>>>> The user_password field is always filled with a value, meanwhile
>>>>>>> this field of non-infected user accounts with openid logins is empty.
>>>>>>> We have 423 total accounts with passwords:
>>>>>>> mysql> select count(*) from user where user_password != '';
>>>>>>> +--+
>>>>>>> | count(*) |
>>>>>>> +--+
>>>>>>> |  423 |
>>>>>>> +--+
>>>>>>> 1 row in set (0.00 sec)
>>>>>>>
>>>>>>> Mediawiki logs-in the newly created users without any preliminary
>>>>>>> email confirmation, right after the registration. I disabled