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

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_id=1_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] 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] 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 <l...@princessleia.com>
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" <marton.k...@gmail.com> 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 <j...@tipit.net> wrote:
>>
>>> FYI. Still seeing the mobile view...
>>>
>>> J.P. Maxwell | tipit.net | fibercove.com
>>> On Feb 27, 2016 6:53 AM, "Marton Kiss" <marton.k...@gmail.com> wrote:
>>>
>>>> Yes, applied them manually. Let's wait a few hours, and check for new
>>>> spam content / user accounts.
>>>>
>>>> M.
>>>> JP Maxwell <j...@tipit.net> (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" <marton.k...@gmail.com> 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 <marton.k...@gmail.com>
>>>>>> 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 
>>>>>>> sta

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 <j...@tipit.net> wrote:

> FYI. Still seeing the mobile view...
>
> J.P. Maxwell | tipit.net | fibercove.com
> On Feb 27, 2016 6:53 AM, "Marton Kiss" <marton.k...@gmail.com> wrote:
>
>> Yes, applied them manually. Let's wait a few hours, and check for new
>> spam content / user accounts.
>>
>> M.
>> JP Maxwell <j...@tipit.net> (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" <marton.k...@gmail.com> 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 <marton.k...@gmail.com>
>>>> 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 <marton.k...@gmail.com>
>>>>> 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
>>>>>

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 <j...@tipit.net> (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" <marton.k...@gmail.com> 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 <marton.k...@gmail.com>
>> 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 <marton.k...@gmail.com>
>>> 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 <j...@tipit.net> 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
>>>>>
>>>>>
>>>>>
>>>>&g

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 <marton.k...@gmail.com> 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 <marton.k...@gmail.com> 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 <j...@tipit.net> 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 <ji...@openstack.org>
>>> 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 pr

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 <marton.k...@gmail.com> 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 <j...@tipit.net> 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 <ji...@openstack.org>
>> 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 cl

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:

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 <j...@tipit.net> 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 <marton.k...@gmail.com>
> 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 <pbela...@redhat.com> 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 <marton.k...@gmail.com> wrote:
>>
>> I see a ton of incoming post requests:
>>
>> POST
>> /w/index.php?title=Special%3ARunJobs=jobs=1=1456508270=571cfb216f944b15d2eee1c0253d08b77003328e
>>
>> M.
>>
>> On Fri, Feb 26, 2016 at 6:35 PM Marton Kiss <marton.k...@gmail.com>
>> wrote:
>>
>>> Oh, I can login. So what we need?
>>>
>>> M.
>>>
>>> On Fri, Feb 26, 2016 at 6:33 PM JP Maxwell <j...@tipit.net> 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 <pabelan...@redhat.com>
>>>> 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

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 <pbela...@redhat.com> 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 <marton.k...@gmail.com> wrote:
>
> I see a ton of incoming post requests:
>
> POST
> /w/index.php?title=Special%3ARunJobs=jobs=1=1456508270=571cfb216f944b15d2eee1c0253d08b77003328e
>
> M.
>
> On Fri, Feb 26, 2016 at 6:35 PM Marton Kiss <marton.k...@gmail.com> wrote:
>
>> Oh, I can login. So what we need?
>>
>> M.
>>
>> On Fri, Feb 26, 2016 at 6:33 PM JP Maxwell <j...@tipit.net> 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 <pabelan...@redhat.com>
>>> 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 | fiber

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 <j...@tipit.net> 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 <marton.k...@gmail.com>
> wrote:
>
> I see a ton of incoming post requests:
>
> POST
> /w/index.php?title=Special%3ARunJobs=jobs=1=1456508270=571cfb216f944b15d2eee1c0253d08b77003328e
>
> M.
>
> On Fri, Feb 26, 2016 at 6:35 PM Marton Kiss <marton.k...@gmail.com> wrote:
>
>> Oh, I can login. So what we need?
>>
>> M.
>>
>> On Fri, Feb 26, 2016 at 6:33 PM JP Maxwell <j...@tipit.net> 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 <pabelan...@redhat.com>
>>> 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.
>>> > >>
>>> > >

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=jobs=1=1456508270=571cfb216f944b15d2eee1c0253d08b77003328e

M.

On Fri, Feb 26, 2016 at 6:35 PM Marton Kiss <marton.k...@gmail.com> wrote:

> Oh, I can login. So what we need?
>
> M.
>
> On Fri, Feb 26, 2016 at 6:33 PM JP Maxwell <j...@tipit.net> 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 <pabelan...@redhat.com>
>> 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"<j...@tipit.net> 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"<pabelan...@redhat.com>
>> 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
>&g

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, 

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 <j...@tipit.net> 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" <marton.k...@gmail.com> 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 <j...@tipit.net> (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=signup=Main+Page=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 <j...@tipit.net> 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 <t...@openstack.org> 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 MediaW

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] 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 <krum.spen...@gmail.com> 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 <marton.k...@gmail.com>
> 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 <fu...@yuggoth.org> 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] 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 <fu...@yuggoth.org> 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]

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 <pabelan...@redhat.com> wrote:

> On Tue, Sep 15, 2015 at 06:09:45PM +0000, 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 <coll...@gazlene.net> wrote:

> On Wed, Sep 16, 2015 at 2:00 AM, Marton Kiss <marton.k...@gmail.com>
> 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 <marton.k...@gmail.com> wrote:

> Thanks, I'll retry from this puppet-community repo.
>
> Brgds,
>   Marton
>
> On Wed, Sep 16, 2015 at 6:01 PM Colleen Murphy <coll...@gazlene.net>
> wrote:
>
>> On Wed, Sep 16, 2015 at 2:00 AM, Marton Kiss <marton.k...@gmail.com>
>> 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 <coll...@gazlene.net> wrote:

> On Wed, Sep 16, 2015 at 11:12 AM, Marton Kiss <marton.k...@gmail.com>
> 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

[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] 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 <fu...@yuggoth.org> 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] 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 jer...@openstack.org 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] 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 dra...@redhat.com:

 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] 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 dra...@redhat.com:

 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

[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