Re: Bug 2033624 (Bodhi, Suggestion) - Feature Suggestion Bodhi (Add edit / delete feedback button after we post feedback)

[Matthew Miller]

On Mon, Dec 20, 2021 at 12:05:00AM -, Reon Beon wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2033624
> 
> You are not authorized to access bug #2033624.


For some reason, it was marked as restricted to logged-in Fedora
contributors. I changed that -- but as you can see, the resolution here was
to redirect to upstream: https://github.com/fedora-infra/bodhi/issues

But also note that you can just submit new feedback and it will replace
whatever feedback score you gave before. Perhaps it's just a matter of
making that more clear.


-- 
Matthew Miller

Fedora Project Leader
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Bug 2033624 (Bodhi, Suggestion) - Feature Suggestion Bodhi (Add edit / delete feedback button after we post feedback)

[Ahmed Almeleh]

Please may you check my feature suggestion for Bodhi. On Bugzilla.

https://bugzilla.redhat.com/show_bug.cgi?id=2033624







Thanks,
Ahmed Almeleh
He / Him / His
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

post

[khadija khalki]

hi Dear
my email is
laila.hajar.jan...@gmail.com
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [FBR] Add kerneltest.fp.o reverse proxy + post-fact FBR

[Kevin Fenzi]

+1, but note that staging is never frozen... so as long as you make sure
to include when: for staging only, go to town. ;) 

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [FBR] Add kerneltest.fp.o reverse proxy + post-fact FBR

[Clement Verna]

On Tue, 14 Apr 2020 at 16:38, Pierre-Yves Chibon 
wrote:

> On Tue, Apr 14, 2020 at 04:03:59PM +0200, Clement Verna wrote:
> >On Tue, 14 Apr 2020 at 14:33, Pierre-Yves Chibon <[1]
> pin...@pingoured.fr>
> >wrote:
> >
> >  Good Morning,
> >
> >  While working on [2]
> https://pagure.io/fedora-infrastructure/issue/8035
> >  to help
> >  Kevin I ended up adding the following commit to the proxies and
> running
> >  the
> >  proxy playbook for it:
> >
> >  commit d6fe2e08a6897470cdaf3ecd191c5329dca49b3c
> >  Author: Pierre-Yves Chibon <[3]pin...@pingoured.fr>
> >  Date:   Tue Apr 14 11:25:17 2020 +0200
> >
> >  proxies-website: Add kerneltest to the proxies
> >
> >  Signed-off-by: Pierre-Yves Chibon <[4]pin...@pingoured.fr>
> >
> >  diff --git a/playbooks/include/proxies-websites.yml
> >  b/playbooks/include/proxies-websites.yml
> >  index a18f7a3a3..5159ecdff 100644
> >  --- a/playbooks/include/proxies-websites.yml
> >  +++ b/playbooks/include/proxies-websites.yml
> >  @@ -996,6 +996,13 @@
> >   cert_name: "{{wildcard_cert_name}}"
> >   tags: calendar
> >
> >  +  - role: httpd/website
> >  +site_name: [5]kerneltest.fedoraproject.org
> >  +sslonly: true
> >  +server_aliases: [[6]kerneltest.stg.fedoraproject.org]
> >  +cert_name: "{{wildcard_cert_name}}"
> >  +tags: kerneltest
> >  +
> >   # fedorahosted is retired. We have the site here so we can
> redirect it.
> >
> > - role: httpd/website
> >
> >  I had totally forgot proxies were frozen, so my apologies for
> pushing
> >  this
> >  through and I'd like to ask for a post-fact FBR.
> >
> >  With this I got kerneltest mostly working expect that it doesn't
> send
> >  back the
> >  expected html page.
> >  Clément took a look at it and pointed me to the reverse proxy which
> >  haven't been
> >  configured for kerneltest.
> >  So I'd like to apply the following patch and run the corresponding
> >  playbook
> >
> >I think there is a copy/paste error, the commit below is the same as
> the
> >one above :-)
>
> Indeed, here is the correct one:
>
> commit ad1224c3f09d75f02362e721110a565676575e99 (HEAD -> master)
> Author: Pierre-Yves Chibon 
> Date:   Tue Apr 14 14:19:30 2020 +0200
>
> proxies: add kerneltest.fp.o reverse proxy so it points to openshift
>
> Signed-off-by: Pierre-Yves Chibon 
>
> diff --git a/playbooks/include/proxies-reverseproxy.yml
> b/playbooks/include/proxies-reverseproxy.yml
> index dd80b5e34..1bb5cf87a 100644
> --- a/playbooks/include/proxies-reverseproxy.yml
> +++ b/playbooks/include/proxies-reverseproxy.yml
> @@ -234,6 +234,15 @@
>  balancer_name: app-os
>  targettype: openshift
>  keephost: true
> +
> +  - role: httpd/reverseproxy
> +website: kerneltest.fedoraproject.org
> +destname: kerneltest
> +balancer_name: app-os
> +targettype: openshift
> +keephost: true
> +tags: kerneltest
> +header_scheme: true
>

I think this was from the previous block, so the block should be added
after that :)

>  when: env == "staging"
>
   - role: httpd/reverseproxy
>
>
one small thing to fix, but +1 from me.


>
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [FBR] Add kerneltest.fp.o reverse proxy + post-fact FBR

[Pierre-Yves Chibon]

On Tue, Apr 14, 2020 at 04:03:59PM +0200, Clement Verna wrote:
>On Tue, 14 Apr 2020 at 14:33, Pierre-Yves Chibon <[1]pin...@pingoured.fr>
>wrote:
> 
>  Good Morning,
> 
>  While working on [2]https://pagure.io/fedora-infrastructure/issue/8035
>  to help
>  Kevin I ended up adding the following commit to the proxies and running
>  the
>  proxy playbook for it:
> 
>  commit d6fe2e08a6897470cdaf3ecd191c5329dca49b3c
>  Author: Pierre-Yves Chibon <[3]pin...@pingoured.fr>
>  Date:   Tue Apr 14 11:25:17 2020 +0200
> 
>      proxies-website: Add kerneltest to the proxies
> 
>      Signed-off-by: Pierre-Yves Chibon <[4]pin...@pingoured.fr>
> 
>  diff --git a/playbooks/include/proxies-websites.yml
>  b/playbooks/include/proxies-websites.yml
>  index a18f7a3a3..5159ecdff 100644
>  --- a/playbooks/include/proxies-websites.yml
>  +++ b/playbooks/include/proxies-websites.yml
>  @@ -996,6 +996,13 @@
>       cert_name: "{{wildcard_cert_name}}"
>       tags: calendar
> 
>  +  - role: httpd/website
>  +    site_name: [5]kerneltest.fedoraproject.org
>  +    sslonly: true
>  +    server_aliases: [[6]kerneltest.stg.fedoraproject.org]
>  +    cert_name: "{{wildcard_cert_name}}"
>  +    tags: kerneltest
>  +
>   # fedorahosted is retired. We have the site here so we can redirect it.
> 
>     - role: httpd/website
> 
>  I had totally forgot proxies were frozen, so my apologies for pushing
>  this
>  through and I'd like to ask for a post-fact FBR.
> 
>  With this I got kerneltest mostly working expect that it doesn't send
>  back the
>  expected html page.
>  Clément took a look at it and pointed me to the reverse proxy which
>  haven't been
>  configured for kerneltest.
>  So I'd like to apply the following patch and run the corresponding
>  playbook
> 
>I think there is a copy/paste error, the commit below is the same as the
>one above :-)

Indeed, here is the correct one:

commit ad1224c3f09d75f02362e721110a565676575e99 (HEAD -> master)
Author: Pierre-Yves Chibon 
Date:   Tue Apr 14 14:19:30 2020 +0200

proxies: add kerneltest.fp.o reverse proxy so it points to openshift

Signed-off-by: Pierre-Yves Chibon 

diff --git a/playbooks/include/proxies-reverseproxy.yml 
b/playbooks/include/proxies-reverseproxy.yml
index dd80b5e34..1bb5cf87a 100644
--- a/playbooks/include/proxies-reverseproxy.yml
+++ b/playbooks/include/proxies-reverseproxy.yml
@@ -234,6 +234,15 @@
 balancer_name: app-os
 targettype: openshift
 keephost: true
+
+  - role: httpd/reverseproxy
+website: kerneltest.fedoraproject.org
+destname: kerneltest
+balancer_name: app-os
+targettype: openshift
+keephost: true
+tags: kerneltest
+header_scheme: true
 when: env == "staging"

   - role: httpd/reverseproxy


Pierre
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [FBR] Add kerneltest.fp.o reverse proxy + post-fact FBR

[Clement Verna]

On Tue, 14 Apr 2020 at 14:33, Pierre-Yves Chibon 
wrote:

> Good Morning,
>
> While working on https://pagure.io/fedora-infrastructure/issue/8035 to
> help
> Kevin I ended up adding the following commit to the proxies and running the
> proxy playbook for it:
>
> commit d6fe2e08a6897470cdaf3ecd191c5329dca49b3c
> Author: Pierre-Yves Chibon 
> Date:   Tue Apr 14 11:25:17 2020 +0200
>
> proxies-website: Add kerneltest to the proxies
>
> Signed-off-by: Pierre-Yves Chibon 
>
> diff --git a/playbooks/include/proxies-websites.yml
> b/playbooks/include/proxies-websites.yml
> index a18f7a3a3..5159ecdff 100644
> --- a/playbooks/include/proxies-websites.yml
> +++ b/playbooks/include/proxies-websites.yml
> @@ -996,6 +996,13 @@
>  cert_name: "{{wildcard_cert_name}}"
>  tags: calendar
>
> +  - role: httpd/website
> +site_name: kerneltest.fedoraproject.org
> +sslonly: true
> +server_aliases: [kerneltest.stg.fedoraproject.org]
> +cert_name: "{{wildcard_cert_name}}"
> +tags: kerneltest
> +
>  # fedorahosted is retired. We have the site here so we can redirect it.
>
>- role: httpd/website
>
>
> I had totally forgot proxies were frozen, so my apologies for pushing this
> through and I'd like to ask for a post-fact FBR.
>
> With this I got kerneltest mostly working expect that it doesn't send back
> the
> expected html page.
> Clément took a look at it and pointed me to the reverse proxy which
> haven't been
> configured for kerneltest.
> So I'd like to apply the following patch and run the corresponding playbook
>

I think there is a copy/paste error, the commit below is the same as the
one above :-)

>
> commit d6fe2e08a6897470cdaf3ecd191c5329dca49b3c
> Author: Pierre-Yves Chibon 
> Date:   Tue Apr 14 11:25:17 2020 +0200
>
> proxies-website: Add kerneltest to the proxies
>
> Signed-off-by: Pierre-Yves Chibon 
>
> diff --git a/playbooks/include/proxies-websites.yml
> b/playbooks/include/proxies-websites.yml
> index a18f7a3a3..5159ecdff 100644
> --- a/playbooks/include/proxies-websites.yml
> +++ b/playbooks/include/proxies-websites.yml
> @@ -996,6 +996,13 @@
>  cert_name: "{{wildcard_cert_name}}"
>  tags: calendar
>
> +  - role: httpd/website
> +site_name: kerneltest.fedoraproject.org
> +sslonly: true
> +server_aliases: [kerneltest.stg.fedoraproject.org]
> +cert_name: "{{wildcard_cert_name}}"
> +tags: kerneltest
> +
>  # fedorahosted is retired. We have the site here so we can redirect it.
>
>- role: httpd/website
>
> +1s?
>
>
> Thanks,
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

[FBR] Add kerneltest.fp.o reverse proxy + post-fact FBR

[Pierre-Yves Chibon]

Good Morning,

While working on https://pagure.io/fedora-infrastructure/issue/8035 to help
Kevin I ended up adding the following commit to the proxies and running the
proxy playbook for it:

commit d6fe2e08a6897470cdaf3ecd191c5329dca49b3c
Author: Pierre-Yves Chibon 
Date:   Tue Apr 14 11:25:17 2020 +0200

proxies-website: Add kerneltest to the proxies

Signed-off-by: Pierre-Yves Chibon 

diff --git a/playbooks/include/proxies-websites.yml 
b/playbooks/include/proxies-websites.yml
index a18f7a3a3..5159ecdff 100644
--- a/playbooks/include/proxies-websites.yml
+++ b/playbooks/include/proxies-websites.yml
@@ -996,6 +996,13 @@
 cert_name: "{{wildcard_cert_name}}"
 tags: calendar

+  - role: httpd/website
+site_name: kerneltest.fedoraproject.org
+sslonly: true
+server_aliases: [kerneltest.stg.fedoraproject.org]
+cert_name: "{{wildcard_cert_name}}"
+tags: kerneltest
+
 # fedorahosted is retired. We have the site here so we can redirect it.

   - role: httpd/website


I had totally forgot proxies were frozen, so my apologies for pushing this
through and I'd like to ask for a post-fact FBR.

With this I got kerneltest mostly working expect that it doesn't send back the
expected html page.
Clément took a look at it and pointed me to the reverse proxy which haven't been
configured for kerneltest.
So I'd like to apply the following patch and run the corresponding playbook:

commit d6fe2e08a6897470cdaf3ecd191c5329dca49b3c
Author: Pierre-Yves Chibon 
Date:   Tue Apr 14 11:25:17 2020 +0200

proxies-website: Add kerneltest to the proxies

Signed-off-by: Pierre-Yves Chibon 

diff --git a/playbooks/include/proxies-websites.yml 
b/playbooks/include/proxies-websites.yml
index a18f7a3a3..5159ecdff 100644
--- a/playbooks/include/proxies-websites.yml
+++ b/playbooks/include/proxies-websites.yml
@@ -996,6 +996,13 @@
 cert_name: "{{wildcard_cert_name}}"
 tags: calendar
 
+  - role: httpd/website
+site_name: kerneltest.fedoraproject.org
+sslonly: true
+server_aliases: [kerneltest.stg.fedoraproject.org]
+cert_name: "{{wildcard_cert_name}}"
+tags: kerneltest
+
 # fedorahosted is retired. We have the site here so we can redirect it.
 
   - role: httpd/website

+1s?


Thanks,
Pierre


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: POST FBR : Bodhi XSS vulnerability

[Leigh Griffin]

Great job addressing this Clément

On Mon, Mar 2, 2020 at 5:26 PM Clement Verna 
wrote:

> Hi all,
>
> An XSS vulnerability was reported against Bodhi, I have patched the
> staging and production instances [0][1] until I get the fix upstream and
> deploy a new release.
>
> [0] -
> https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=9b1336960b307a2a81d6232f0ce40f40dfb0f83a
> [1] -
> https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=1a901aba52a780328f48f7c271f6f84a5333b4f8
>
> Thanks
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

POST FBR : Bodhi XSS vulnerability

[Clement Verna]

Hi all,

An XSS vulnerability was reported against Bodhi, I have patched the staging
and production instances [0][1] until I get the fix upstream and deploy a
new release.

[0] -
https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=9b1336960b307a2a81d6232f0ce40f40dfb0f83a
[1] -
https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=1a901aba52a780328f48f7c271f6f84a5333b4f8

Thanks
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [Post Fact FBR] update repoSpanner's SSL cert for pagure01

[Kevin Fenzi]

On Thu, Oct 17, 2019 at 10:08:30AM +0200, Pierre-Yves Chibon wrote:
...snip...
> > 2) we need nagios monitoring those certs, or we need to just tear
> > down that cluster if we aren't going to use it (which we are currently
> > not). 
> > 
> > 3) We could also 'unrepospanner' that repo since we aren't using it
> > and put the old one back.
> 
> This may be wise, especially considering that I may not have fixed everything
> (see the end of this email).

I'm not entirely sure how to do this. Just unset repospanner in the
pagure settings?

> > 4) pagure perhaps should gracefully print 'sorry, the repo is not
> > available right now due to a repospanner problem' but otherwise work?
> 
> +1 for this, I'm not sure of the size of the work in there but worth looking
> into.

Shall I file a pagure ticket? Or you want to?
> 
> 
> Also: Patrick said that the cert needs to be upgraded in other places (nodes) 
> as
> well, I do not know if running the repospanner playbook fixed it or not 
> though,
> so we may still have something broken.
> I have received emails from pagure yesterday with:
> """
> ...
> PagurePushDenied: Remote hook declined the push: Performing pre-check...
> ...
> ERR Error syncing object out to enough nodes
> """
> 
> Which make me think we are still missing some fix, but I don't know which :(

There's 3 nodes defined in this cluster: 

pagure01
batcave01
repospanner-phx2

So, I think we need to run the playbook on batcave and repospanner-phx2. 

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [Post Fact FBR] update repoSpanner's SSL cert for pagure01

[Pierre-Yves Chibon]

On Wed, Oct 16, 2019 at 09:41:03AM -0700, Kevin Fenzi wrote:
> On Wed, Oct 16, 2019 at 10:47:00AM +0200, Pierre-Yves Chibon wrote:
> > Good Morning Everyone,
> > 
> > This morning I found out that https://pagure.io/fedora-infrastructure was 
> > not
> > available, it was throwing a 500 error on every page/call.
> > 
> > I checked the logs and found:
> > GitError: Error performing curl request: (60): Peer certificate cannot be
> > authenticated with given CA certificates
> > 
> > The combination and "GitError" and a SSL related error led me to 
> > repoSpanner.
> > So with the help of Patrick, we confirmed that the SSL cert for pagure01 was
> > expiring on Oct 15th 2019.
> > We then regenerated that SSL cert.
> > 
> > We thought the repospanner playbook was going to redeploy that cert so I 
> > ran it,
> > but it did not change anything (both in its run as well as in the symptoms
> > observed).
> > 
> > We then found out that this piece is actually part of the pagure.yml 
> > playbook,
> > so I've ran it with `-t repospanner/server` to limit its effect.
> > Then I've restarted httpd, stunnel and repospanner@ansible.service on 
> > pagur01.
> > The first two were likely not necessary, the last one was to get the new 
> > cert in
> > use.
> > 
> > So I would like retro-active approval for my actions since the systems I've
> > touched are frozen.
> 
> So a few things: 
> 
> 1) +1 to the actions... thanks for fixing that!

Thanks for the +1!

> 2) we need nagios monitoring those certs, or we need to just tear
> down that cluster if we aren't going to use it (which we are currently
> not). 
> 
> 3) We could also 'unrepospanner' that repo since we aren't using it
> and put the old one back.

This may be wise, especially considering that I may not have fixed everything
(see the end of this email).

> 4) pagure perhaps should gracefully print 'sorry, the repo is not
> available right now due to a repospanner problem' but otherwise work?

+1 for this, I'm not sure of the size of the work in there but worth looking
into.


Also: Patrick said that the cert needs to be upgraded in other places (nodes) as
well, I do not know if running the repospanner playbook fixed it or not though,
so we may still have something broken.
I have received emails from pagure yesterday with:
"""
...
PagurePushDenied: Remote hook declined the push: Performing pre-check...
...
ERR Error syncing object out to enough nodes
"""

Which make me think we are still missing some fix, but I don't know which :(


Thanks,
Pierre


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [Post Fact FBR] update repoSpanner's SSL cert for pagure01

[Patrick Uiterwijk]

On Wed, 16 Oct 2019 at 20:55 Stephen John Smoogen  wrote:

> On Wed, 16 Oct 2019 at 12:41, Kevin Fenzi  wrote:
> >
> > On Wed, Oct 16, 2019 at 10:47:00AM +0200, Pierre-Yves Chibon wrote:
> > > Good Morning Everyone,
> > >
> > > This morning I found out that https://pagure.io/fedora-infrastructure
> was not
> > > available, it was throwing a 500 error on every page/call.
> > >
> > > I checked the logs and found:
> > > GitError: Error performing curl request: (60): Peer certificate cannot
> be
> > > authenticated with given CA certificates
> > >
> > > The combination and "GitError" and a SSL related error led me to
> repoSpanner.
> > > So with the help of Patrick, we confirmed that the SSL cert for
> pagure01 was
> > > expiring on Oct 15th 2019.
> > > We then regenerated that SSL cert.
> > >
> > > We thought the repospanner playbook was going to redeploy that cert so
> I ran it,
> > > but it did not change anything (both in its run as well as in the
> symptoms
> > > observed).
> > >
> > > We then found out that this piece is actually part of the pagure.yml
> playbook,
> > > so I've ran it with `-t repospanner/server` to limit its effect.
> > > Then I've restarted httpd, stunnel and repospanner@ansible.service on
> pagur01.
> > > The first two were likely not necessary, the last one was to get the
> new cert in
> > > use.
> > >
> > > So I would like retro-active approval for my actions since the systems
> I've
> > > touched are frozen.
> >
> > So a few things:
> >
> > 1) +1 to the actions... thanks for fixing that!
> >
>
> Agreed +1
>
>
> > 2) we need nagios monitoring those certs, or we need to just tear
> > down that cluster if we aren't going to use it (which we are currently
> > not).
> >
>
> Yep. These are difficult to monitor and build because we don't use
> openssl to build them like other certs.. but the repospanner command
> itself.


Just a note that the difference is purely when generating the certificates.
They’re standard PEM encoded certificates, and you could use OpenSSL for
parsing or generating them.


>
> > 3) We could also 'unrepospanner' that repo since we aren't using it
> > and put the old one back.
> >
>
> Agreed.
>
> > 4) pagure perhaps should gracefully print 'sorry, the repo is not
> > available right now due to a repospanner problem' but otherwise work?
> >
>
> Might be good also
>
> > For 2 and 3, perhaps we should discuss and decide.
> >
> > For 4, can you file a pagure bug (if you agree).
> >
> > kevin
> > ___
> > infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> > To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
>
>
> --
> Stephen J Smoogen.
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
>
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [Post Fact FBR] update repoSpanner's SSL cert for pagure01

[Stephen John Smoogen]

On Wed, 16 Oct 2019 at 12:41, Kevin Fenzi  wrote:
>
> On Wed, Oct 16, 2019 at 10:47:00AM +0200, Pierre-Yves Chibon wrote:
> > Good Morning Everyone,
> >
> > This morning I found out that https://pagure.io/fedora-infrastructure was 
> > not
> > available, it was throwing a 500 error on every page/call.
> >
> > I checked the logs and found:
> > GitError: Error performing curl request: (60): Peer certificate cannot be
> > authenticated with given CA certificates
> >
> > The combination and "GitError" and a SSL related error led me to 
> > repoSpanner.
> > So with the help of Patrick, we confirmed that the SSL cert for pagure01 was
> > expiring on Oct 15th 2019.
> > We then regenerated that SSL cert.
> >
> > We thought the repospanner playbook was going to redeploy that cert so I 
> > ran it,
> > but it did not change anything (both in its run as well as in the symptoms
> > observed).
> >
> > We then found out that this piece is actually part of the pagure.yml 
> > playbook,
> > so I've ran it with `-t repospanner/server` to limit its effect.
> > Then I've restarted httpd, stunnel and repospanner@ansible.service on 
> > pagur01.
> > The first two were likely not necessary, the last one was to get the new 
> > cert in
> > use.
> >
> > So I would like retro-active approval for my actions since the systems I've
> > touched are frozen.
>
> So a few things:
>
> 1) +1 to the actions... thanks for fixing that!
>

Agreed +1


> 2) we need nagios monitoring those certs, or we need to just tear
> down that cluster if we aren't going to use it (which we are currently
> not).
>

Yep. These are difficult to monitor and build because we don't use
openssl to build them like other certs.. but the repospanner command
itself.

> 3) We could also 'unrepospanner' that repo since we aren't using it
> and put the old one back.
>

Agreed.

> 4) pagure perhaps should gracefully print 'sorry, the repo is not
> available right now due to a repospanner problem' but otherwise work?
>

Might be good also

> For 2 and 3, perhaps we should discuss and decide.
>
> For 4, can you file a pagure bug (if you agree).
>
> kevin
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: [Post Fact FBR] update repoSpanner's SSL cert for pagure01

[Kevin Fenzi]

On Wed, Oct 16, 2019 at 10:47:00AM +0200, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
> 
> This morning I found out that https://pagure.io/fedora-infrastructure was not
> available, it was throwing a 500 error on every page/call.
> 
> I checked the logs and found:
> GitError: Error performing curl request: (60): Peer certificate cannot be
> authenticated with given CA certificates
> 
> The combination and "GitError" and a SSL related error led me to repoSpanner.
> So with the help of Patrick, we confirmed that the SSL cert for pagure01 was
> expiring on Oct 15th 2019.
> We then regenerated that SSL cert.
> 
> We thought the repospanner playbook was going to redeploy that cert so I ran 
> it,
> but it did not change anything (both in its run as well as in the symptoms
> observed).
> 
> We then found out that this piece is actually part of the pagure.yml playbook,
> so I've ran it with `-t repospanner/server` to limit its effect.
> Then I've restarted httpd, stunnel and repospanner@ansible.service on pagur01.
> The first two were likely not necessary, the last one was to get the new cert 
> in
> use.
> 
> So I would like retro-active approval for my actions since the systems I've
> touched are frozen.

So a few things: 

1) +1 to the actions... thanks for fixing that!

2) we need nagios monitoring those certs, or we need to just tear
down that cluster if we aren't going to use it (which we are currently
not). 

3) We could also 'unrepospanner' that repo since we aren't using it
and put the old one back.

4) pagure perhaps should gracefully print 'sorry, the repo is not
available right now due to a repospanner problem' but otherwise work?

For 2 and 3, perhaps we should discuss and decide. 

For 4, can you file a pagure bug (if you agree).

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

[Post Fact FBR] update repoSpanner's SSL cert for pagure01

[Pierre-Yves Chibon]

Good Morning Everyone,

This morning I found out that https://pagure.io/fedora-infrastructure was not
available, it was throwing a 500 error on every page/call.

I checked the logs and found:
GitError: Error performing curl request: (60): Peer certificate cannot be
authenticated with given CA certificates

The combination and "GitError" and a SSL related error led me to repoSpanner.
So with the help of Patrick, we confirmed that the SSL cert for pagure01 was
expiring on Oct 15th 2019.
We then regenerated that SSL cert.

We thought the repospanner playbook was going to redeploy that cert so I ran it,
but it did not change anything (both in its run as well as in the symptoms
observed).

We then found out that this piece is actually part of the pagure.yml playbook,
so I've ran it with `-t repospanner/server` to limit its effect.
Then I've restarted httpd, stunnel and repospanner@ansible.service on pagur01.
The first two were likely not necessary, the last one was to get the new cert in
use.

So I would like retro-active approval for my actions since the systems I've
touched are frozen.


Thanks,
Pierre
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: Post-FBR: Force openvpn to use tun1

[Stephen John Smoogen]

On Tue, 18 Sep 2018 at 00:13, Patrick Uiterwijk  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi all,
>
> For compatibility with openshift, we need openvpn to use tun1 on the 
> openshift nodes.
> While this does happen automatically if openvpn starts after the openshift 
> SDN pod,
> this is not always the case.
> Can I get +1s for the patches I rolled out to make sure this happens?
> (The second one was because I had the variable name wrong.)
>

Retroactive +1


>
> commit 8ad630412f6abd082d08a628260b408d88d99b21
> Author: Patrick Uiterwijk 
> Date:   Tue Sep 18 05:49:15 2018 +0200
>
> Make OpenVPN use tun1 for os-node's
>
> Signed-off-by: Patrick Uiterwijk 
>
> diff --git a/roles/openvpn/client/tasks/main.yml 
> b/roles/openvpn/client/tasks/main.yml
> index 27c150d16..1ed3d173b 100644
> - --- a/roles/openvpn/client/tasks/main.yml
> +++ b/roles/openvpn/client/tasks/main.yml
> @@ -19,14 +19,24 @@
>- openvpn
>when: ansible_distribution_major_version|int > 7 and 
> ansible_cmdline.ostree is not defined
>
> +- name: Install main config file (rhel7 and fedora)
> +  template: src=client.conf
> +dest=/etc/openvpn/client/openvpn.conf
> +owner=root group=root mode=0644
> +  tags:
> +  - install
> +  - openvpn
> +#  notify:
> +#  - restart openvpn (Fedora)
> +#  - restart openvpn (RHEL7)
> +#  - restart openvpn (RHEL6)
> +  when: ( ansible_distribution_major_version|int != 6 and 
> ansible_distribution_major_version|int != 24) and ansible_cmdline.ostree is 
> not defined
> +
>  - name: Install configuration files (rhel7 and fedora)
>copy: src={{ item.file }}
>  dest={{ item.dest }}
>  owner=root group=root mode={{ item.mode }}
>with_items:
> - -  - { file: client.conf,
> - -  dest: /etc/openvpn/client/openvpn.conf,
> - -  mode: '0644' }
>- { file: "{{ private }}/files/vpn/pki/issued/{{ inventory_hostname 
> }}.crt",
>dest: "/etc/openvpn/client/client.crt",
>mode: '0600' }
> diff --git a/roles/openvpn/client/files/client.conf 
> b/roles/openvpn/client/templates/client.conf
> similarity index 70%
> rename from roles/openvpn/client/files/client.conf
> rename to roles/openvpn/client/templates/client.conf
> index 5042ed6e2..f398c9a39 100644
> - --- a/roles/openvpn/client/files/client.conf
> +++ b/roles/openvpn/client/templates/client.conf
> @@ -1,6 +1,11 @@
>  client
>
> +{% if hostname.startswith("os-node") %}
> +# OpenShift REALLY wants tun0. Let's make sure openvpn doesn't claim it
> +dev tun1
> +{% else %}
>  dev tun
> +{% endif %}
>
>  proto udp
>
>
>
> commit 325155810b8a0f0bbf929587316e1ae97d2b6565 (HEAD -> master, 
> origin/master, origin/HEAD)
> Author: Patrick Uiterwijk 
> Date:   Tue Sep 18 05:51:46 2018 +0200
>
> Actually use the ansible hostname
>
> Signed-off-by: Patrick Uiterwijk 
>
> diff --git a/roles/openvpn/client/templates/client.conf 
> b/roles/openvpn/client/templates/client.conf
> index f398c9a39..11372910b 100644
> - --- a/roles/openvpn/client/templates/client.conf
> +++ b/roles/openvpn/client/templates/client.conf
> @@ -1,6 +1,6 @@
>  client
>
> - -{% if hostname.startswith("os-node") %}
> +{% if ansible_hostname.startswith("os-node") %}
>  # OpenShift REALLY wants tun0. Let's make sure openvpn doesn't claim it
>  dev tun1
>  {% else %}
> -BEGIN PGP SIGNATURE-
>
> iQIcBAEBCgAGBQJboHsaAAoJEIZXmA2atR5QJ1MP/Rm8T8GFuIznzGo80ypxb891
> x310k+PrOkJ0kOxnY086dqCqNxPsFLVnFpGHWUAo3Y/8q/85HeJHHP/6iDuxYb37
> /dghRacim8PIEsf4PAAMulqOhpGDKfZ/bMTJrQOp/eOSc8MQkdkabXYAPgH6RyrX
> uJXrHn4Xx+REZEjOR5dbZJahqfeRbUpU84TNfVPgu5NCgCyYg/eGZr0MaV06Fxcp
> T4m9VbN1MCxn/aX6I4yq7EO3QWhfe5iB3tNKa0emZYqkTTwYWImK6m+bEfA8FWzn
> gyyeS1m2nPQm2vjPefp+k//oFo9JARUHCpR9HBJb+A3ctJVXiZAr3W0PgXhYdPNp
> Ocrhd2TvHfQP62mOh7UwIrPuheFxxY3P8OPNWmkTyLtAfQN/5zSwaig/fX4A+XqP
> 4z/TXdMMWVBrq5a4pH8vn8jwDeI4Q4dgpH7Nj4WlAQ3TUFssiEki5MPiCLU8R6/B
> xqvwVl4DqxERS1nUlB5TANTdyDYYTbpA4Tukr8qhQxXnbWD1VezeoE+WCZn+94jL
> bX1J86g2hJz8xBJWWfSHoSI2ncBzPUScSyJkGxSozBSbvcKzPumF3FGHcsoFIZwa
> KDRXALPsXm5t15EnY1Ylg/ILxIaZNygxyDGq6Ryu1giTjZEnCyFWwl5Vvjq+hewO
> ZqdNr3jnf8pQLsTdxcKT
> =siP7
> -END PGP SIGNATURE-
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.f

Re: Post-FBR: Force openvpn to use tun1

[Pierre-Yves Chibon]

On Tue, Sep 18, 2018 at 06:12:10AM +0200, Patrick Uiterwijk wrote:
> Hi all,
> 
> For compatibility with openshift, we need openvpn to use tun1 on the 
> openshift nodes.
> While this does happen automatically if openvpn starts after the openshift 
> SDN pod,
> this is not always the case.
> Can I get +1s for the patches I rolled out to make sure this happens?
> (The second one was because I had the variable name wrong.)
> 
> 
> commit 8ad630412f6abd082d08a628260b408d88d99b21
> Author: Patrick Uiterwijk 
> Date:   Tue Sep 18 05:49:15 2018 +0200
> 
> Make OpenVPN use tun1 for os-node's
> 
> Signed-off-by: Patrick Uiterwijk 
> 
> diff --git a/roles/openvpn/client/tasks/main.yml 
> b/roles/openvpn/client/tasks/main.yml
> index 27c150d16..1ed3d173b 100644
> --- a/roles/openvpn/client/tasks/main.yml
> +++ b/roles/openvpn/client/tasks/main.yml
> @@ -19,14 +19,24 @@
>- openvpn
>when: ansible_distribution_major_version|int > 7 and 
> ansible_cmdline.ostree is not defined
>  
> +- name: Install main config file (rhel7 and fedora)
> +  template: src=client.conf
> +dest=/etc/openvpn/client/openvpn.conf
> +owner=root group=root mode=0644
> +  tags:
> +  - install
> +  - openvpn
> +#  notify:
> +#  - restart openvpn (Fedora)
> +#  - restart openvpn (RHEL7)
> +#  - restart openvpn (RHEL6)
> +  when: ( ansible_distribution_major_version|int != 6 and 
> ansible_distribution_major_version|int != 24) and ansible_cmdline.ostree is 
> not defined
> +
>  - name: Install configuration files (rhel7 and fedora)
>copy: src={{ item.file }}
>  dest={{ item.dest }}
>  owner=root group=root mode={{ item.mode }}
>with_items:
> -  - { file: client.conf,
> -  dest: /etc/openvpn/client/openvpn.conf,
> -  mode: '0644' }
>- { file: "{{ private }}/files/vpn/pki/issued/{{ inventory_hostname 
> }}.crt",
>dest: "/etc/openvpn/client/client.crt",
>mode: '0600' }
> diff --git a/roles/openvpn/client/files/client.conf 
> b/roles/openvpn/client/templates/client.conf
> similarity index 70%
> rename from roles/openvpn/client/files/client.conf
> rename to roles/openvpn/client/templates/client.conf
> index 5042ed6e2..f398c9a39 100644
> --- a/roles/openvpn/client/files/client.conf
> +++ b/roles/openvpn/client/templates/client.conf
> @@ -1,6 +1,11 @@
>  client
>  
> +{% if hostname.startswith("os-node") %}
> +# OpenShift REALLY wants tun0. Let's make sure openvpn doesn't claim it
> +dev tun1
> +{% else %}
>  dev tun
> +{% endif %}
>  
>  proto udp
>  
> 
> 
> commit 325155810b8a0f0bbf929587316e1ae97d2b6565 (HEAD -> master, 
> origin/master, origin/HEAD)
> Author: Patrick Uiterwijk 
> Date:   Tue Sep 18 05:51:46 2018 +0200
> 
> Actually use the ansible hostname
> 
> Signed-off-by: Patrick Uiterwijk 
> 
> diff --git a/roles/openvpn/client/templates/client.conf 
> b/roles/openvpn/client/templates/client.conf
> index f398c9a39..11372910b 100644
> --- a/roles/openvpn/client/templates/client.conf
> +++ b/roles/openvpn/client/templates/client.conf
> @@ -1,6 +1,6 @@
>  client
>  
> -{% if hostname.startswith("os-node") %}
> +{% if ansible_hostname.startswith("os-node") %}
>  # OpenShift REALLY wants tun0. Let's make sure openvpn doesn't claim it
>  dev tun1
>  {% else %}

+1 for me


Pierre


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Post-FBR: Force openvpn to use tun1

[Patrick Uiterwijk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all,

For compatibility with openshift, we need openvpn to use tun1 on the openshift 
nodes.
While this does happen automatically if openvpn starts after the openshift SDN 
pod,
this is not always the case.
Can I get +1s for the patches I rolled out to make sure this happens?
(The second one was because I had the variable name wrong.)


commit 8ad630412f6abd082d08a628260b408d88d99b21
Author: Patrick Uiterwijk 
Date:   Tue Sep 18 05:49:15 2018 +0200

Make OpenVPN use tun1 for os-node's

Signed-off-by: Patrick Uiterwijk 

diff --git a/roles/openvpn/client/tasks/main.yml 
b/roles/openvpn/client/tasks/main.yml
index 27c150d16..1ed3d173b 100644
- --- a/roles/openvpn/client/tasks/main.yml
+++ b/roles/openvpn/client/tasks/main.yml
@@ -19,14 +19,24 @@
   - openvpn
   when: ansible_distribution_major_version|int > 7 and ansible_cmdline.ostree 
is not defined
 
+- name: Install main config file (rhel7 and fedora)
+  template: src=client.conf
+dest=/etc/openvpn/client/openvpn.conf
+owner=root group=root mode=0644
+  tags:
+  - install
+  - openvpn
+#  notify:
+#  - restart openvpn (Fedora)
+#  - restart openvpn (RHEL7)
+#  - restart openvpn (RHEL6)
+  when: ( ansible_distribution_major_version|int != 6 and 
ansible_distribution_major_version|int != 24) and ansible_cmdline.ostree is not 
defined
+
 - name: Install configuration files (rhel7 and fedora)
   copy: src={{ item.file }}
 dest={{ item.dest }}
 owner=root group=root mode={{ item.mode }}
   with_items:
- -  - { file: client.conf,
- -  dest: /etc/openvpn/client/openvpn.conf,
- -  mode: '0644' }
   - { file: "{{ private }}/files/vpn/pki/issued/{{ inventory_hostname }}.crt",
   dest: "/etc/openvpn/client/client.crt",
   mode: '0600' }
diff --git a/roles/openvpn/client/files/client.conf 
b/roles/openvpn/client/templates/client.conf
similarity index 70%
rename from roles/openvpn/client/files/client.conf
rename to roles/openvpn/client/templates/client.conf
index 5042ed6e2..f398c9a39 100644
- --- a/roles/openvpn/client/files/client.conf
+++ b/roles/openvpn/client/templates/client.conf
@@ -1,6 +1,11 @@
 client
 
+{% if hostname.startswith("os-node") %}
+# OpenShift REALLY wants tun0. Let's make sure openvpn doesn't claim it
+dev tun1
+{% else %}
 dev tun
+{% endif %}
 
 proto udp
 


commit 325155810b8a0f0bbf929587316e1ae97d2b6565 (HEAD -> master, origin/master, 
origin/HEAD)
Author: Patrick Uiterwijk 
Date:   Tue Sep 18 05:51:46 2018 +0200

Actually use the ansible hostname

Signed-off-by: Patrick Uiterwijk 

diff --git a/roles/openvpn/client/templates/client.conf 
b/roles/openvpn/client/templates/client.conf
index f398c9a39..11372910b 100644
- --- a/roles/openvpn/client/templates/client.conf
+++ b/roles/openvpn/client/templates/client.conf
@@ -1,6 +1,6 @@
 client
 
- -{% if hostname.startswith("os-node") %}
+{% if ansible_hostname.startswith("os-node") %}
 # OpenShift REALLY wants tun0. Let's make sure openvpn doesn't claim it
 dev tun1
 {% else %}
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJboHsaAAoJEIZXmA2atR5QJ1MP/Rm8T8GFuIznzGo80ypxb891
x310k+PrOkJ0kOxnY086dqCqNxPsFLVnFpGHWUAo3Y/8q/85HeJHHP/6iDuxYb37
/dghRacim8PIEsf4PAAMulqOhpGDKfZ/bMTJrQOp/eOSc8MQkdkabXYAPgH6RyrX
uJXrHn4Xx+REZEjOR5dbZJahqfeRbUpU84TNfVPgu5NCgCyYg/eGZr0MaV06Fxcp
T4m9VbN1MCxn/aX6I4yq7EO3QWhfe5iB3tNKa0emZYqkTTwYWImK6m+bEfA8FWzn
gyyeS1m2nPQm2vjPefp+k//oFo9JARUHCpR9HBJb+A3ctJVXiZAr3W0PgXhYdPNp
Ocrhd2TvHfQP62mOh7UwIrPuheFxxY3P8OPNWmkTyLtAfQN/5zSwaig/fX4A+XqP
4z/TXdMMWVBrq5a4pH8vn8jwDeI4Q4dgpH7Nj4WlAQ3TUFssiEki5MPiCLU8R6/B
xqvwVl4DqxERS1nUlB5TANTdyDYYTbpA4Tukr8qhQxXnbWD1VezeoE+WCZn+94jL
bX1J86g2hJz8xBJWWfSHoSI2ncBzPUScSyJkGxSozBSbvcKzPumF3FGHcsoFIZwa
KDRXALPsXm5t15EnY1Ylg/ILxIaZNygxyDGq6Ryu1giTjZEnCyFWwl5Vvjq+hewO
ZqdNr3jnf8pQLsTdxcKT
=siP7
-END PGP SIGNATURE-
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: FBR: Autosigning for post bodhi activation of F29

[Patrick Uiterwijk]

+1 though I'd like it moved to the correct section ("Gated bodhi
updates"), but I'll merge it so things get signed at least.
On Tue, 28 Aug 2018 at 23:19, Kevin Fenzi  wrote:
>
> +1
>
> kevin
>
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

Re: FBR: Autosigning for post bodhi activation of F29

[Kevin Fenzi]

+1

kevin



signature.asc
Description: OpenPGP digital signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

FBR: Autosigning for post bodhi activation of F29

[Mohan Boddu]

--- a/roles/robosignatory/files/robosignatory.production.py
+++ b/roles/robosignatory/files/robosignatory.production.py
@@ -132,28 +132,21 @@ config = {
 "keyid": "cfc659b9",
 "type": "modular"
 },
-{
-"from": "f29-pending",
-"to": "f29",
-"key": "fedora-29",
-"keyid": "429476b4"
-},
+
+# Gated bodhi updates
 {
 "from": "f29-modular-signing-pending",
-"to": "f29-modular",
+"to": "f29-modular-updates-testing-pending",
 "key": "fedora-29",
 "keyid": "429476b4",
 "type": "modular"
 },
 {
-"from": "f29-modular-updates-candidate",
-"to": "f29-modular",
+"from": "f29-signing-pending",
+"to": "f29-updates-testing-pending",
 "key": "fedora-29",
-"keyid": "429476b4",
-"type": "modular"
+"keyid": "429476b4"
 },
-
-# Gated bodhi updates
 {
 "from": "f28-modular-signing-pending",
 "to": "f28-modular-updates-testing-pending",
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org

fedora-tagger sunset - week post F29 beta freeze

[Clement Verna]

Dear all,

The Fedora Infrastructure is running the fedora-tagger [0] service,
however it gets little usage and also has no one really maintaining it
or fixing issues with it. Earlier this year [1] we have tried to
support community members who expressed their interests in maintaining
this application, unfortunately this effort did not results in a new
version being released.

During our last meeting [2], we agreed to retire this service a week
after the end of the F29 beta freeze (see F29 schedule [3]).

Once the F29 beta freeze is over, we will communicate a sunset date.

Regards,
Clément

[0] - https://apps.fedoraproject.org/tagger/
[1] - https://communityblog.fedoraproject.org/maintainers-package-tagger/
[2] - 
https://meetbot.fedoraproject.org/teams/infrastructure/infrastructure.2018-08-23-14.00.log.html
[3] - https://fedoraproject.org/wiki/Releases/29/Schedule?rd=Schedule
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/RY23KIVRXFVXMTGMXNDV4D7NXM2V2NUJ/

[PATCH 1/3] Add pagure's hook to the post-receive hook and point to the main hooks

[Pierre-Yves Chibon]

---
 roles/git/hooks/files/post-receive-chained | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/roles/git/hooks/files/post-receive-chained 
b/roles/git/hooks/files/post-receive-chained
index 4718f57..e61cb72 100755
--- a/roles/git/hooks/files/post-receive-chained
+++ b/roles/git/hooks/files/post-receive-chained
@@ -4,8 +4,10 @@
 # You need to explicitly add your hook to the following list
 # for it to be invoked.
 pee \
-$GIT_DIR/hooks/post-receive-chained.d/post-receive-fedmsg \
-$GIT_DIR/hooks/post-receive-chained.d/post-receive-alternativearch
+/usr/share/git-core/post-receive-fedmsg \
+/usr/share/git-core/post-receive-alternativearch \
+/usr/lib/python2.7/site-packages/pagure/hooks/files/default_hook.py \
+/usr/lib/python2.7/site-packages/pagure/hooks/files/pagure_hook.py
 
 # We used to send emails directly from the git hook here, but now we send to
 # fedmsg which routes to FMN which routes to packagers and the mailing list.
-- 
2.9.5
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

[PATCH 1/2] Add pagure's hook to the post-receive hook and point to the main hooks

[Pierre-Yves Chibon]

---
 roles/git/hooks/files/post-receive-chained | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/roles/git/hooks/files/post-receive-chained 
b/roles/git/hooks/files/post-receive-chained
index 4718f57..e61cb72 100755
--- a/roles/git/hooks/files/post-receive-chained
+++ b/roles/git/hooks/files/post-receive-chained
@@ -4,8 +4,10 @@
 # You need to explicitly add your hook to the following list
 # for it to be invoked.
 pee \
-$GIT_DIR/hooks/post-receive-chained.d/post-receive-fedmsg \
-$GIT_DIR/hooks/post-receive-chained.d/post-receive-alternativearch
+/usr/share/git-core/post-receive-fedmsg \
+/usr/share/git-core/post-receive-alternativearch \
+/usr/lib/python2.7/site-packages/pagure/hooks/files/default_hook.py \
+/usr/lib/python2.7/site-packages/pagure/hooks/files/pagure_hook.py
 
 # We used to send emails directly from the git hook here, but now we send to
 # fedmsg which routes to FMN which routes to packagers and the mailing list.
-- 
2.9.5
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Post Freeze break request: resize pagure01's drive

[Kevin Fenzi]

On Thu, 15 Dec 2016 17:01:31 +0100
Pierre-Yves Chibon  wrote:

> On Sun, Nov 20, 2016 at 08:52:07PM +, Patrick Uiterwijk wrote:
> > On Sun, Nov 20, 2016 at 6:49 PM, Pierre-Yves Chibon
> >  wrote:  
> > > On Sun, Nov 20, 2016 at 09:01:56AM -0500, Stephen John Smoogen
> > > wrote:  
> > >> PIngou how much disk space do you need?  
> > >
> > > It's a little hard to tell, how much are we using on fedorahosted
> > > atm? The disk was 17G so far, so with the 10G bump that makes it
> > > 27G.
> > >
> > > Maybe 50G would give us a little time, but I honestly do not
> > > really know.  
> > 
> > Note that extending a lot more is currently problematic, because
> > pagure01 has been created on
> > vg_server rather than vg_guests, which means it only has about 100GB
> > in total for the VG
> > instead of a few TB.
> > 
> > It should really be moved, and that needs to happen before we can
> > increase the size
> > significantly.  
> 
> We just almost reached the current size (due to some file left
> in /srv/tmp from failed PR/clone).
> 
> Now that we're out of freeze we may want to start planning on this.

Basically we just need to schedule an outage and do it. 

It would mean: 

* take down pagure.io
* create new lv on other pv
* dd / copy the existing drive over 
* grow the space

I would think it might take at most a few hours, but probibly should
say something like '4 hours' in the outage. 

I'd be happy to do this whenever, just pick a time. :) 

kevin


pgp69DJdhoQvS.pgp
Description: OpenPGP digital signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Post Freeze break request: resize pagure01's drive

[Pierre-Yves Chibon]

On Sun, Nov 20, 2016 at 08:52:07PM +, Patrick Uiterwijk wrote:
> On Sun, Nov 20, 2016 at 6:49 PM, Pierre-Yves Chibon  
> wrote:
> > On Sun, Nov 20, 2016 at 09:01:56AM -0500, Stephen John Smoogen wrote:
> >> PIngou how much disk space do you need?
> >
> > It's a little hard to tell, how much are we using on fedorahosted atm?
> > The disk was 17G so far, so with the 10G bump that makes it 27G.
> >
> > Maybe 50G would give us a little time, but I honestly do not really know.
> 
> Note that extending a lot more is currently problematic, because
> pagure01 has been created on
> vg_server rather than vg_guests, which means it only has about 100GB
> in total for the VG
> instead of a few TB.
> 
> It should really be moved, and that needs to happen before we can
> increase the size
> significantly.

We just almost reached the current size (due to some file left in /srv/tmp from
failed PR/clone).

Now that we're out of freeze we may want to start planning on this.


Pierre
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Post Freeze break request: resize pagure01's drive

[Patrick Uiterwijk]

On Sun, Nov 20, 2016 at 6:49 PM, Pierre-Yves Chibon  wrote:
> On Sun, Nov 20, 2016 at 09:01:56AM -0500, Stephen John Smoogen wrote:
>> PIngou how much disk space do you need?
>
> It's a little hard to tell, how much are we using on fedorahosted atm?
> The disk was 17G so far, so with the 10G bump that makes it 27G.
>
> Maybe 50G would give us a little time, but I honestly do not really know.

Note that extending a lot more is currently problematic, because
pagure01 has been created on
vg_server rather than vg_guests, which means it only has about 100GB
in total for the VG
instead of a few TB.

It should really be moved, and that needs to happen before we can
increase the size
significantly.

>
>
> Pierre
>
>
>> On 20 November 2016 at 08:22, Pierre-Yves Chibon  wrote:
>> > On Sun, Nov 20, 2016 at 09:59:45AM +0100, Patrick Uiterwijk wrote:
>> >> Hi,
>> >>
>> >> Since Pagure's virtual drive was almost full, and it already has
>> >> blocked git pushes more
>> >> than once, I decided to add 10GB to it so it won't cause any problems for 
>> >> now.
>> >>
>> >> Note that there's also no nagios monitoring seemingly for this. That
>> >> seems important to fix.
>> >>
>> >> Can I get post-FBR +1s for:
>> >> - 
>> >> http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=a6a525a
>> >> - Following 
>> >> https://infrastructure.fedoraproject.org/infra/docs/guestdisk.rst
>> >
>> > +1 for me, but 10G seems even a little low, but we can reconsider once 
>> > freeze is
>> > over.
>> >
>> >
>> > Pierre
>> > ___
>> > infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> > To unsubscribe send an email to 
>> > infrastructure-le...@lists.fedoraproject.org
>>
>>
>>
>> --
>> Stephen J Smoogen.
>> ___
>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
>> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Post Freeze break request: resize pagure01's drive

[Pierre-Yves Chibon]

On Sun, Nov 20, 2016 at 09:01:56AM -0500, Stephen John Smoogen wrote:
> PIngou how much disk space do you need?

It's a little hard to tell, how much are we using on fedorahosted atm?
The disk was 17G so far, so with the 10G bump that makes it 27G.

Maybe 50G would give us a little time, but I honestly do not really know.


Pierre

 
> On 20 November 2016 at 08:22, Pierre-Yves Chibon  wrote:
> > On Sun, Nov 20, 2016 at 09:59:45AM +0100, Patrick Uiterwijk wrote:
> >> Hi,
> >>
> >> Since Pagure's virtual drive was almost full, and it already has
> >> blocked git pushes more
> >> than once, I decided to add 10GB to it so it won't cause any problems for 
> >> now.
> >>
> >> Note that there's also no nagios monitoring seemingly for this. That
> >> seems important to fix.
> >>
> >> Can I get post-FBR +1s for:
> >> - 
> >> http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=a6a525a
> >> - Following 
> >> https://infrastructure.fedoraproject.org/infra/docs/guestdisk.rst
> >
> > +1 for me, but 10G seems even a little low, but we can reconsider once 
> > freeze is
> > over.
> >
> >
> > Pierre
> > ___
> > infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
> 
> 
> 
> -- 
> Stephen J Smoogen.
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Post Freeze break request: resize pagure01's drive

[Stephen John Smoogen]

PIngou how much disk space do you need?

On 20 November 2016 at 08:22, Pierre-Yves Chibon  wrote:
> On Sun, Nov 20, 2016 at 09:59:45AM +0100, Patrick Uiterwijk wrote:
>> Hi,
>>
>> Since Pagure's virtual drive was almost full, and it already has
>> blocked git pushes more
>> than once, I decided to add 10GB to it so it won't cause any problems for 
>> now.
>>
>> Note that there's also no nagios monitoring seemingly for this. That
>> seems important to fix.
>>
>> Can I get post-FBR +1s for:
>> - http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=a6a525a
>> - Following https://infrastructure.fedoraproject.org/infra/docs/guestdisk.rst
>
> +1 for me, but 10G seems even a little low, but we can reconsider once freeze 
> is
> over.
>
>
> Pierre
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Post Freeze break request: resize pagure01's drive

[Pierre-Yves Chibon]

On Sun, Nov 20, 2016 at 09:59:45AM +0100, Patrick Uiterwijk wrote:
> Hi,
> 
> Since Pagure's virtual drive was almost full, and it already has
> blocked git pushes more
> than once, I decided to add 10GB to it so it won't cause any problems for now.
> 
> Note that there's also no nagios monitoring seemingly for this. That
> seems important to fix.
> 
> Can I get post-FBR +1s for:
> - http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=a6a525a
> - Following https://infrastructure.fedoraproject.org/infra/docs/guestdisk.rst

+1 for me, but 10G seems even a little low, but we can reconsider once freeze is
over.


Pierre
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Post Freeze break request: resize pagure01's drive

[Patrick Uiterwijk]

Hi,

Since Pagure's virtual drive was almost full, and it already has
blocked git pushes more
than once, I decided to add 10GB to it so it won't cause any problems for now.

Note that there's also no nagios monitoring seemingly for this. That
seems important to fix.

Can I get post-FBR +1s for:
- http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=a6a525a
- Following https://infrastructure.fedoraproject.org/infra/docs/guestdisk.rst

Thanks,
Patrick
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Re: Post-freeze code update

[Aurelien Bompard]

> Is that too far out?
>

This is fine.  ;-)

A.
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: Post-freeze code update

[Kevin Fenzi]

On Mon, 22 Aug 2016 19:13:29 +0200
Aurelien Bompard  wrote:

> Hey people!
> 
> As you all know, Mozilla Persona is going down in the next few
> months. I've spent the last weeks since Flock updating the Mailman UI
> code to use a library that will allow us to support local accounts
> properly, on top of external services accounts. I'm currently testing
> it in staging, and I'd like to update to code in production after the
> alpha freeze. It's a pretty decent amount of code change so I'm being
> careful here, and the DB schema migration may take a couple minutes.
> There was also a big branch merged in Mailman (unrelated, but a
> pretty large code change).
> 
> I'm thinking a day or two after alpha is released, in my morning
> (UTC+2) so the US folks will be asleep and I can still get help from
> Patrick if necessary (Patrick doesn't seem to have a timezone anyway).
> 
> Does this seem OK to you?

Sure, but note that we slipped a week, so (unless we slip again) that
would be next week (the 30th for release).

Is that too far out? 

kevin


pgpbNvD3YlPpT.pgp
Description: OpenPGP digital signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Post-freeze code update

[Aurelien Bompard]

Hey people!

As you all know, Mozilla Persona is going down in the next few months. I've
spent the last weeks since Flock updating the Mailman UI code to use a
library that will allow us to support local accounts properly, on top of
external services accounts. I'm currently testing it in staging, and I'd
like to update to code in production after the alpha freeze. It's a pretty
decent amount of code change so I'm being careful here, and the DB schema
migration may take a couple minutes. There was also a big branch merged in
Mailman (unrelated, but a pretty large code change).

I'm thinking a day or two after alpha is released, in my morning (UTC+2) so
the US folks will be asleep and I can still get help from Patrick if
necessary (Patrick doesn't seem to have a timezone anyway).

Does this seem OK to you?

Aurélien
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: Post-action freeze break request: increase basset drive size

[Stephen John Smoogen]

+!

On 1 June 2016 at 17:39, Kevin Fenzi  wrote:
> +1
>
> ___
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: Post-action freeze break request: increase basset drive size

[Kevin Fenzi]

+1


pgpUNpfzblSv5.pgp
Description: OpenPGP digital signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Post-action freeze break request: increase basset drive size

[Patrick Uiterwijk]

Can I get +1s for increasing basset01's drive size?

Ansible commit:
http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=8039a85
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproject.org

Re: Post-freeze patch: remove Password: prompt after failed 2fa

[Stephen John Smoogen]

Same here.

On 16 September 2015 at 12:10, Kevin Fenzi  wrote:
> +1 provided it tests ok in stg. ;)
>
> kevin
>
> ___
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> http://lists.fedoraproject.org/postorius/infrastructure@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/postorius/infrastructure@lists.fedoraproject.org

Re: Post-freeze patch: remove Password: prompt after failed 2fa

[Kevin Fenzi]

+1 provided it tests ok in stg. ;) 

kevin


pgpYe87_x7XWv.pgp
Description: OpenPGP digital signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/postorius/infrastructure@lists.fedoraproject.org

Re: Post-freeze patch: remove Password: prompt after failed 2fa

[Patrick Uiterwijk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Corrected patch follows.
With the original one, it would still fall through to system-auth.

This patch removes that.
We don't need the original system-auth anymore, since we already have
pam_env, pam_succeed_if and pam_deny in the sudo pam.


diff --git a/files/2fa/sudo.pam b/files/2fa/sudo.pam
index aa59ebf..356a9db 100644
- --- a/files/2fa/sudo.pam
+++ b/files/2fa/sudo.pam
@@ -1,10 +1,9 @@
 #%PAM-1.0
 auth   required pam_env.so
- -auth   sufficient   pam_url.so config=/etc/pam_url.conf
+auth   requisitepam_url.so config=/etc/pam_url.conf
 auth   requisitepam_succeed_if.so uid >= 500 quiet
 auth   required pam_deny.so
 
- -auth   include  system-auth
 accountinclude  system-auth
 password   include  system-auth
 sessionoptional pam_keyinit.so revoke
diff --git a/roles/totpcgi/files/sudo.pam b/roles/totpcgi/files/sudo.pam
index aa59ebf..356a9db 100644
- --- a/roles/totpcgi/files/sudo.pam
+++ b/roles/totpcgi/files/sudo.pam
@@ -1,10 +1,9 @@
 #%PAM-1.0
 auth   required pam_env.so
- -auth   sufficient   pam_url.so config=/etc/pam_url.conf
+auth   requisitepam_url.so config=/etc/pam_url.conf
 auth   requisitepam_succeed_if.so uid >= 500 quiet
 auth   required pam_deny.so
 
- -auth   include  system-auth
 accountinclude  system-auth
 password   include  system-auth
 sessionoptional pam_keyinit.so revoke




On Wed, Sep 16, 2015 at 07:59:35PM +0200, Patrick Uiterwijk wrote:
> Hi,
> 
> Post-freeze I would like to merge the following patch, which will remove the
> Password: promot on RHEL7 boxes after a failed pasword+token.
> 
> 
> 
> 
> commit 17f4dce44a5f105cb2f7850085d42626e054c224
> Author: Patrick Uiterwijk 
> Date:   Wed Sep 16 17:57:02 2015 +
> 
> Remove the Password: promopt when 2fa failed
> 
> diff --git a/files/2fa/sudo.pam b/files/2fa/sudo.pam
> index aa59ebf..08f7630 100644
> --- a/files/2fa/sudo.pam
> +++ b/files/2fa/sudo.pam
> @@ -1,6 +1,6 @@
>  #%PAM-1.0
>  auth   required pam_env.so
> -auth   sufficient   pam_url.so config=/etc/pam_url.conf
> +auth   requisitepam_url.so config=/etc/pam_url.conf
>  auth   requisitepam_succeed_if.so uid >= 500 quiet
>  auth   required pam_deny.so
>  
> diff --git a/roles/totpcgi/files/sudo.pam b/roles/totpcgi/files/sudo.pam
> index aa59ebf..08f7630 100644
> --- a/roles/totpcgi/files/sudo.pam
> +++ b/roles/totpcgi/files/sudo.pam
> @@ -1,6 +1,6 @@
>  #%PAM-1.0
>  auth   required pam_env.so
> -auth   sufficient   pam_url.so config=/etc/pam_url.conf
> +auth   requisitepam_url.so config=/etc/pam_url.conf
>  auth   requisitepam_succeed_if.so uid >= 500 quiet
>  auth   required pam_deny.so
>  
> 
> 
> -- 
> With kind regards,
> Patrick Uiterwijk
> Fedora Infra
> ___
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> http://lists.fedoraproject.org/postorius/infrastructure@lists.fedoraproject.org

- -- 
With kind regards,
Patrick Uiterwijk
Fedora Infra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJV+a/DAAoJEIZXmA2atR5QeWcP/0EOvaFVaEHlVYdTvM7emzep
sAckQ0wsK8nVbu739OEQYJGzt1dNDiUCZISrpsaqxym8CwIfaE8FaFTpcPeGRmez
9lJjE0SZehqjEGPGJvIxrkWU434I3HBxwSfyOvVOgKdizwcNH1k9Rx+Y4tEsN5JJ
TDpc2kH6/0mv4ACt7JxGXNjtwcEInfVBiOHRspdaTyJginB2XLDTF4OH9xMnIDdE
NR4XySngUcscAZs4/vwb6ahRmv5rOh//72NhwAxVeYyrul6sIxe1NDmDg7/oHUKN
P08L4usJcDGTc0YUkYb+cChActo9TFGof3sAEF3pMEhkDt/qlE3odnE7z7ScMjrR
TESWs0kU72+auMuR4GUEFuN2dTRay+9oEHelBmZ3xMZVdG3wemYpVFXlOo1pa4sx
H1YdNseDUwxcXN7IP5MCXmm6eBOv6YA2z/LYoE+UseZ4TfYFDs5auZPJoDuTnYwe
8iC+obcHclQlpQ0WZNWFKzg4PFPD/IhbA6VljFAq+kZ4fYDjTyAiMYoF2eQbr2yq
7zZbucCNacaD4Nzi6CPmqT6forteL8OkNZLwYBYaFozjzD1p8E44i1wSsgcKoLaW
4Vz/6nMx0iPuOlvThkmC552fZ0hLZkzmgiDkG3Mi8yiXUCG0bcij+HSCVPQHzj33
JfOCCyOFCFW2e2Oe/H66
=wsm9
-END PGP SIGNATURE-
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/postorius/infrastructure@lists.fedoraproject.org

Post-freeze patch: remove Password: prompt after failed 2fa

[Patrick Uiterwijk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Post-freeze I would like to merge the following patch, which will remove the
Password: promot on RHEL7 boxes after a failed pasword+token.




commit 17f4dce44a5f105cb2f7850085d42626e054c224
Author: Patrick Uiterwijk 
Date:   Wed Sep 16 17:57:02 2015 +

Remove the Password: promopt when 2fa failed

diff --git a/files/2fa/sudo.pam b/files/2fa/sudo.pam
index aa59ebf..08f7630 100644
- --- a/files/2fa/sudo.pam
+++ b/files/2fa/sudo.pam
@@ -1,6 +1,6 @@
 #%PAM-1.0
 auth   required pam_env.so
- -auth   sufficient   pam_url.so config=/etc/pam_url.conf
+auth   requisitepam_url.so config=/etc/pam_url.conf
 auth   requisitepam_succeed_if.so uid >= 500 quiet
 auth   required pam_deny.so
 
diff --git a/roles/totpcgi/files/sudo.pam b/roles/totpcgi/files/sudo.pam
index aa59ebf..08f7630 100644
- --- a/roles/totpcgi/files/sudo.pam
+++ b/roles/totpcgi/files/sudo.pam
@@ -1,6 +1,6 @@
 #%PAM-1.0
 auth   required pam_env.so
- -auth   sufficient   pam_url.so config=/etc/pam_url.conf
+auth   requisitepam_url.so config=/etc/pam_url.conf
 auth   requisitepam_succeed_if.so uid >= 500 quiet
 auth   required pam_deny.so
 


- -- 
With kind regards,
Patrick Uiterwijk
Fedora Infra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJV+a4HAAoJEIZXmA2atR5QNM8P/RtSRb7i8ThDKunZ07MoDOJq
kQ9uI9l7OUkQmJEywxaMg73GhJdtSj0wYQ2qU+ILm3DAWR4zAOrITdrobdjj/RKm
6B7Pnzu6Hjtlqx7mzF6ZpkWzNLhDxSV5iGGSSEsSr9QxDew1FGLBf9Cy7qfL8s6A
tyYQ5BueUWElPK+N4q9trknbv9PkCnw9mriiAnzQECvKCPcKzNmV1nAwriFu6GA3
slhAfAnO5VijCv1LdOfftFZmH1c1TdSAZRUta1NYEEyaxuZCLT4YVtyv1SibRI2Q
zrhbFjgfJzWPMxlREFIXsKiYniBFay2fwmMed+jhimi4XyhlwcFgHXUKQL5ImlEE
a+UMBW3yNDOPkLbmoKZboP0uH4KxzSh5Lm6UnQ/2X/aKnjylFg6PwsSBlDlbax6x
5WN0jjGumrPdc1a1jN8lyG8Efdu/dFc0t14lsOYJUly6MWllq7RpNYLXh6KTwhyX
hrjiGiDZt3Y4gsO585xN3gSRIY0xqEFG5+B8IfSG0QD1GjGr8TZSJ16IMw6F+46a
D4JY8XgrR5la/+uISjey+GU2k4MhjP9gyL18dw1oQYX1bWZq2NPerfKvlGuHZz8l
bI85GObr3pM3Lbv1iyOFWbabZ2xpk0Dsf2ViYLy9zgusumAyhkIy4UMbQVsbMC9d
f9VLcgTfdjxW14Sx02yw
=itcm
-END PGP SIGNATURE-
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
http://lists.fedoraproject.org/postorius/infrastructure@lists.fedoraproject.org

Re: Freeze break request: [post] Add a pagure.org -> pagure.io redirect

[Peter Robinson]

On Wed, Jul 29, 2015 at 11:00 AM, Patrick Uiterwijk
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Could I get retroactive +1s for the following commit, which fixes
> pagure.org urls (instaad of getting them trapped in the docs.pagure.org 
> vhost).

Seems to work with testing so +1

>  1 files changed, 22 insertions(+), 0 deletions(-)
> [puiterwijk@lockbox01 templates]$ git show HEAD
> commit 0a7efdc4fb9fa7b14d2447294cae56100624f9b7
> Author: Patrick Uiterwijk 
> Date:   Wed Jul 29 09:57:44 2015 +
>
> Make a pagure.org -> pagure.io redirect
>
> diff --git a/roles/pagure/frontend/templates/0_pagure.conf 
> b/roles/pagure/frontend/templates/0_pagure.conf
> index ea81a92..05bb090 100644
> - --- a/roles/pagure/frontend/templates/0_pagure.conf
> +++ b/roles/pagure/frontend/templates/0_pagure.conf
> @@ -27,6 +27,28 @@ WSGIDaemonProcess paguredocs user=git group=git 
> maximum-requests=1000 display-na
>  {% endif %}
>  
>
> +
> +{% if env == 'pagure-staging' %}
> +  ServerName stg.pagure.org
> +{% else %}
> +  ServerName pagure.org
> +{% endif %}
> +
> +  SSLEngine on
> +  SSLProtocol all -SSLv2 -SSLv3
> +  # Use secure TLSv1.1 and TLSv1.2 ciphers
> +  Header always add Strict-Transport-Security "max-age=15768000; 
> includeSubDomains; preload"
> +
> +  SSLCertificateFile /etc/pki/tls/certs/docs.pagure.org.crt
> +  SSLCertificateChainFile /etc/pki/tls/certs/docs.pagure.org.intermediate.crt
> +  SSLCertificateKeyFile /etc/pki/tls/certs/docs.pagure.org.key
> +{% if env == 'pagure-staging' %}
> +  Redirect permanent / https://stg.pagure.io/
> +{% else %}
> +  Redirect permanent / https://pagure.io/
> +{% endif %}
> +
> +
>
>  
>  {% if env == 'pagure-staging' %}
>
> - --
> With kind regards,
> Patrick Uiterwijk
> Fedora Infra
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBCgAGBQJVuKQ5AAoJEIZXmA2atR5Q/voP/jm5JZtzX1StwAN07b8CxfRK
> 2dWxTL7nWagRqt+LcmootLNHb4GmH58wyS2XpEa+BlnDt33BeEK8AuoO4QdbISgI
> tWygWNQwyPaME4gPRdxCNhnJ8Xo+9S/ss5j98dMqQz31MnwclxXdMsz0NYlyE4NX
> DKgxfiJayelP6EjR1lfjnBTag7S+Hoj3QXBYU74ACky8Um0SKOLc/nRjX2ccHYFL
> q3qwz4VedunKFvCmlhybGXVs5CANA6Z+W846jXQSiBXx7WaoduvIIYzKVX9Zmdll
> ZMvjNk6ZmkKDuqKGG51FMyjMe4J0RMu9TW7pWWDYMz6+yOLcrJfUDp17w1JVbZ0g
> jnuA7XnsEGsvcWoLU4dtClE0SIkyRnrL+A44Ahpa+5Xo1M0eZxUZ+6kBq0LSl5Jo
> LhOpDhxQ25nVMqjMLjdmfn8+3usUl+8TkxSGnbeKljR6nnOtpA3wRCZ75UXmXf6/
> sr6eTCm7RF6+kbkovU7F8jS9aqMDP+Pvzz/GyB4eFuODhUGjPHVsvbh9XKY3YZfH
> hW3wH85tabaoQJrH3OS0QPpnHln67Ey57tH9ZUroeNVKTx1ulw/o6/Dwdc34iY/D
> YqWi6ak7QSkTWnuvpEumoM+Uk0BsgQSSa1gE2lObMCfTzC2jyO5lmghlO/ET3RCY
> rkiGx/E3qRJ3qfp0dnDE
> =Lbie
> -END PGP SIGNATURE-
> ___
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Freeze break request: [post] Add a pagure.org -> pagure.io redirect

[Pierre-Yves Chibon]

On Wed, Jul 29, 2015 at 12:00:26PM +0200, Patrick Uiterwijk wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Could I get retroactive +1s for the following commit, which fixes
> pagure.org urls (instaad of getting them trapped in the docs.pagure.org 
> vhost).
 
+1 for me, I saw the error before and the fix is working now.

Thanks!
Pierre

 
>  1 files changed, 22 insertions(+), 0 deletions(-)
> [puiterwijk@lockbox01 templates]$ git show HEAD
> commit 0a7efdc4fb9fa7b14d2447294cae56100624f9b7
> Author: Patrick Uiterwijk 
> Date:   Wed Jul 29 09:57:44 2015 +
> 
> Make a pagure.org -> pagure.io redirect
> 
> diff --git a/roles/pagure/frontend/templates/0_pagure.conf 
> b/roles/pagure/frontend/templates/0_pagure.conf
> index ea81a92..05bb090 100644
> - --- a/roles/pagure/frontend/templates/0_pagure.conf
> +++ b/roles/pagure/frontend/templates/0_pagure.conf
> @@ -27,6 +27,28 @@ WSGIDaemonProcess paguredocs user=git group=git 
> maximum-requests=1000 display-na
>  {% endif %}
>  
>  
> +
> +{% if env == 'pagure-staging' %}
> +  ServerName stg.pagure.org
> +{% else %}
> +  ServerName pagure.org
> +{% endif %}
> +
> +  SSLEngine on
> +  SSLProtocol all -SSLv2 -SSLv3
> +  # Use secure TLSv1.1 and TLSv1.2 ciphers
> +  Header always add Strict-Transport-Security "max-age=15768000; 
> includeSubDomains; preload"
> +
> +  SSLCertificateFile /etc/pki/tls/certs/docs.pagure.org.crt
> +  SSLCertificateChainFile /etc/pki/tls/certs/docs.pagure.org.intermediate.crt
> +  SSLCertificateKeyFile /etc/pki/tls/certs/docs.pagure.org.key
> +{% if env == 'pagure-staging' %}
> +  Redirect permanent / https://stg.pagure.io/
> +{% else %}
> +  Redirect permanent / https://pagure.io/
> +{% endif %}
> +
> +
>  
>  
>  {% if env == 'pagure-staging' %}
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Freeze break request: [post] Add a pagure.org -> pagure.io redirect

[Patrick Uiterwijk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Could I get retroactive +1s for the following commit, which fixes
pagure.org urls (instaad of getting them trapped in the docs.pagure.org vhost).


 1 files changed, 22 insertions(+), 0 deletions(-)
[puiterwijk@lockbox01 templates]$ git show HEAD
commit 0a7efdc4fb9fa7b14d2447294cae56100624f9b7
Author: Patrick Uiterwijk 
Date:   Wed Jul 29 09:57:44 2015 +

Make a pagure.org -> pagure.io redirect

diff --git a/roles/pagure/frontend/templates/0_pagure.conf 
b/roles/pagure/frontend/templates/0_pagure.conf
index ea81a92..05bb090 100644
- --- a/roles/pagure/frontend/templates/0_pagure.conf
+++ b/roles/pagure/frontend/templates/0_pagure.conf
@@ -27,6 +27,28 @@ WSGIDaemonProcess paguredocs user=git group=git 
maximum-requests=1000 display-na
 {% endif %}
 
 
+
+{% if env == 'pagure-staging' %}
+  ServerName stg.pagure.org
+{% else %}
+  ServerName pagure.org
+{% endif %}
+
+  SSLEngine on
+  SSLProtocol all -SSLv2 -SSLv3
+  # Use secure TLSv1.1 and TLSv1.2 ciphers
+  Header always add Strict-Transport-Security "max-age=15768000; 
includeSubDomains; preload"
+
+  SSLCertificateFile /etc/pki/tls/certs/docs.pagure.org.crt
+  SSLCertificateChainFile /etc/pki/tls/certs/docs.pagure.org.intermediate.crt
+  SSLCertificateKeyFile /etc/pki/tls/certs/docs.pagure.org.key
+{% if env == 'pagure-staging' %}
+  Redirect permanent / https://stg.pagure.io/
+{% else %}
+  Redirect permanent / https://pagure.io/
+{% endif %}
+
+
 
 
 {% if env == 'pagure-staging' %}

- -- 
With kind regards,
Patrick Uiterwijk
Fedora Infra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJVuKQ5AAoJEIZXmA2atR5Q/voP/jm5JZtzX1StwAN07b8CxfRK
2dWxTL7nWagRqt+LcmootLNHb4GmH58wyS2XpEa+BlnDt33BeEK8AuoO4QdbISgI
tWygWNQwyPaME4gPRdxCNhnJ8Xo+9S/ss5j98dMqQz31MnwclxXdMsz0NYlyE4NX
DKgxfiJayelP6EjR1lfjnBTag7S+Hoj3QXBYU74ACky8Um0SKOLc/nRjX2ccHYFL
q3qwz4VedunKFvCmlhybGXVs5CANA6Z+W846jXQSiBXx7WaoduvIIYzKVX9Zmdll
ZMvjNk6ZmkKDuqKGG51FMyjMe4J0RMu9TW7pWWDYMz6+yOLcrJfUDp17w1JVbZ0g
jnuA7XnsEGsvcWoLU4dtClE0SIkyRnrL+A44Ahpa+5Xo1M0eZxUZ+6kBq0LSl5Jo
LhOpDhxQ25nVMqjMLjdmfn8+3usUl+8TkxSGnbeKljR6nnOtpA3wRCZ75UXmXf6/
sr6eTCm7RF6+kbkovU7F8jS9aqMDP+Pvzz/GyB4eFuODhUGjPHVsvbh9XKY3YZfH
hW3wH85tabaoQJrH3OS0QPpnHln67Ey57tH9ZUroeNVKTx1ulw/o6/Dwdc34iY/D
YqWi6ak7QSkTWnuvpEumoM+Uk0BsgQSSa1gE2lObMCfTzC2jyO5lmghlO/ET3RCY
rkiGx/E3qRJ3qfp0dnDE
=Lbie
-END PGP SIGNATURE-
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Moving the codecs sticky post link on Ask Fedora to a sidebar to make it easier to find

[Ankur Sinha]

On Tue, 2015-05-12 at 10:08 -0600, Kevin Fenzi wrote:
> Fine with me.

Done :D

signature.asc
Description: This is a digitally signed message part
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Freeze Break Request: fedmenu on mirrormanager [post-act]

[Kevin Fenzi]

On Mon, 18 May 2015 11:39:00 +0200
Pierre-Yves Chibon  wrote:

> Hi all,
> 
> I realized while I had already started running the playbook that I
> should not have done this but it was too late.
> The changes are minor:
> http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=45d8e7e
> Changes the configuration file of the flask UI of mirrormanager2 to
> specify the fedmenu URLs
> http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=01c667b
> Adds tags to this role to allow running just this part (which is what
> I did)
> 
> So UI is up and running with fedmenu enabled:
> https://admin.fedoraproject.org/mirrormanager
> 
> However, this should have been through the freeze-break process or
> waited. Patrick already gave a post-action +1 on the changes.
> Could I have another one please?

+1

kevin



pgputtkGxm8QV.pgp
Description: OpenPGP digital signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Freeze Break Request: fedmenu on mirrormanager [post-act]

[Adrian Reber]

On Mon, May 18, 2015 at 11:39:00AM +0200, Pierre-Yves Chibon wrote:
> I realized while I had already started running the playbook that I should not
> have done this but it was too late.
> The changes are minor:
> http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=45d8e7e
> Changes the configuration file of the flask UI of mirrormanager2 to specify 
> the
> fedmenu URLs
> http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=01c667b
> Adds tags to this role to allow running just this part (which is what I did)
> 
> So UI is up and running with fedmenu enabled:
> https://admin.fedoraproject.org/mirrormanager
> 
> However, this should have been through the freeze-break process or waited.
> Patrick already gave a post-action +1 on the changes.
> Could I have another one please?

Simple fix and it seems to be working correctly. +1 from me.

Adrian


pgpq2QdFf4KZT.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Freeze Break Request: fedmenu on mirrormanager [post-act]

[Pierre-Yves Chibon]

Hi all,

I realized while I had already started running the playbook that I should not
have done this but it was too late.
The changes are minor:
http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=45d8e7e
Changes the configuration file of the flask UI of mirrormanager2 to specify the
fedmenu URLs
http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=01c667b
Adds tags to this role to allow running just this part (which is what I did)

So UI is up and running with fedmenu enabled:
https://admin.fedoraproject.org/mirrormanager

However, this should have been through the freeze-break process or waited.
Patrick already gave a post-action +1 on the changes.
Could I have another one please?


Thanks,
Pierre


pgp4sdfRiTqGy.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Moving the codecs sticky post link on Ask Fedora to a sidebar to make it easier to find

[Kevin Fenzi]

On Mon, 11 May 2015 23:40:22 +0100
Ankur Sinha  wrote:

> Hi all,
> 
> If you've been on the desktop ml, you'll know that we're trying to
> find ways to make installation of codecs and things easier. We already
> have a post on Ask Fedora that documents what needs to be done[1].
> Unfortunately, askbot does not have a "pin question" or similar option
> and this very important question seems to get lost as a result. 
> 
> Is it OK if I add this question to the right sidebar under "Common
> Post installation tasks" or similar so that it jumps out to everyone
> that comes to the site?

Fine with me. 

kevin


pgpqZLXsZjhx5.pgp
Description: OpenPGP digital signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Moving the codecs sticky post link on Ask Fedora to a sidebar to make it easier to find

[Ankur Sinha]

Hi all,

If you've been on the desktop ml, you'll know that we're trying to
find ways to make installation of codecs and things easier. We already
have a post on Ask Fedora that documents what needs to be done[1].
Unfortunately, askbot does not have a "pin question" or similar option
and this very important question seems to get lost as a result. 

Is it OK if I add this question to the right sidebar under "Common
Post installation tasks" or similar so that it jumps out to everyone
that comes to the site?

[1] https://ask.fedoraproject.org/en/question/9111/sticky-what-plugins
-do-i-need-to-install-to-watch-movies-and-listen-to-music/
-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD"

http://fedoraproject.org/wiki/User:Ankursinha



signature.asc
Description: This is a digitally signed message part
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: pkgdb2 post-mortem and strategy for future deployments

[Kevin Fenzi]

On Wed, 4 Jun 2014 11:44:54 -0700
Toshio Kuratomi  wrote:

> 
> This came up in a different venue and pingou and I have continued to
> talk about it.  Seemed that this was the right place to bring the
> discussion though.

...snip...

> Some ideas for doing major deployments in the future:
> 
> 1: We have to make people aware when a new deployment means API
> breaks.
>   * Be clear that the new deployment means API breaks in every call
> for testing.  Send announcements to infrastructure list and depending
> on the service to devel list.
>   * Have a separate announcement besides the standard outage
> notification that says that an API breaking update is planned for
> $date
>   * When we set a date for the new deployment, discuss it at least
> once in a weekly infrastructure meeting.
>   * See also the solution in #3 below

This seems good to me. 

> 2: It would be really nice for people to do more testing in stg.
>   * Increase rube coverage.  rube does end-to-end testing so it's
> better at catching cross-app issues where API changes better than
> unittests which try to be small and self-contained
> - A flock session where everyone/dev in infra gets to write one
> rube test so we get to know the framework

Yeah, that sounds good. Perhaps a badge for 'added a rube test' ? :) 

>   * Run rube daily
> - Could we run rube in an Xvfb on an infrastructure host?
>   * Continue to work towards a complete replica of production in the
> stg environment.

Yeah, if we can figure out a clean way to run it. It also needs some
credentials for some of the tests, so we would need to make a test
user, etc. 

> 3: "Mean time to repair is more important than mean time between
> failure." It seems like anytime there's a major update there's
> unexpected things that break.  Let's anticipate the unexpected
> happening.

I agree here too... 

>   * Explicitly plan for everyone to spend their day firefighting when
> we make a major new deployment.  If you've already found all the
> places your code is affected and pre-ported it and the deployment
> goes smoothly then hey, you've got 6 extra working hours to shift
> back to doing other things.  If it's not smooth, then we've planned
> to have the attention of the right people for the unexpected
> difficulties that arise.

Yep. 

>   * As part of this, we need to identify people outside of
> infrastructure that should also be ready for breakage.  Reach out to
> rel-eng, docs, qa, cvsadmins, etc if there's a chance that they will
> be affected.

Agreed. 
 ...snip...

> What should we apply this to?
> * Probably can skip if:
>   - Things that we don't think have API breaks
>   - Things that are minor releases (hopefully these would correlate
> with not having API breaks :-)
>   - Leaf services that are not essential to releasing Fedora.
> + ask, nuancier, elections, easyfix, badges, paste, nuancier
> + There's a lot of boderline cases too -- is fedocal essential
> enough to warrant being under this policy?  Since the wiki is used
> via its API should that fall under this as well?

yeah, there's going to be some fuzz, but discussing the update in at
least one infra meeting before pushing would mean we would have
time/people to hash out if it's a major update or what. 
 
> Comments, thoughts, other ideas?
>
> Do we need to "ratify" something like this at a meeting?

We could, but I think it's all quite sensable, so we could just do it
unless someone objects. 
 
> What's the next app deploy where we'll want to enact this?
> Maybe bodhi2 ;-)?

Yep. Althought it might be something before then... we talked about
trying to get bodhi2 in stg before too long, but we don't want to
disrupt the release process for f21 too much, so we thought targeting
landing it after f21 a few weeks might be best. That also gives lots of
time for testing in stg and getting api users switched over. 

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: pkgdb2 post-mortem and strategy for future deployments

[Pierre-Yves Chibon]

On Wed, Jun 04, 2014 at 05:27:44PM -0500, Dennis Gilmore wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
> this is something koji does, though we to date have not broken api, we
> expect we will do when we start on koji-2.0  so each app would provide
> a getAPIVersion() function, then the consumers validate that they know
> how to talk to that API version.
> 
> for bodhi for instance apps could check for api version if it fails
> assume version 1 and then be able to support both version 1 and 2, when
> we deploy live bodhi2 the clients like fedpkg update will transparently
> switch over.

After the call for testers in November that was one of the feedback I received
on the API, so it is there: https://admin.fedoraproject.org/pkgdb/api/version
Note that this is the API version which may be different from the Pkgdb2
version. With the decoupling of API and UI, I keep two different version number
and as long as the first number is the same, the API is backward compatible :)

And I have been using it just yesterday for pkgdb-cli to use a new API method or
fall back on the old one according to the version of the pkgdb API:
https://github.com/fedora-infra/packagedb-cli/commit/af10afd22a5f4370285ee84423c2ac5b8d283ccd


Pierre
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: pkgdb2 post-mortem and strategy for future deployments

[Toshio Kuratomi]

On Wed, Jun 04, 2014 at 05:27:44PM -0500, Dennis Gilmore wrote:
> 
> I have a suggestion make everything provide and validate api info.
> 
> this is something koji does, though we to date have not broken api, we
> expect we will do when we start on koji-2.0  so each app would provide
> a getAPIVersion() function, then the consumers validate that they know
> how to talk to that API version.
> 
> for bodhi for instance apps could check for api version if it fails
> assume version 1 and then be able to support both version 1 and 2, when
> we deploy live bodhi2 the clients like fedpkg update will transparently
> switch over.
>
  This would be nice.  I don't think it would have helped us with the
pkgdb2 update where people didn't port at all but if we gave more
information it could.  Ideally we'd want to see something like this:

>>> data = service.requestAPIVersion([(1, 2), (2, 0)],
...   'arbitrary-identification-string')
>>> print(data)
[[1, 2], [1, 4]]

In that example the client would be claiming compatibility with API version
1.2 or later and 2.0 or later.

The server would be telling the client that it can supply something
compatible with 1.2, namely 1.4.

If we got clients to update their code to make requestAPIVersion() calls
both the client and the server would be able to track what the other wanted
and was capable of.  Serverside, we could keep track of what identification
strings were making requests for something other than API version 2.0 and help
those people port to 2.0 before deployment.

Is that sort of API too confusing (because it's attempting to track
information in both directions but the person using the code really just
wants information in a single direction)?

-Toshio


pgpjsWSK6M1EP.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: pkgdb2 post-mortem and strategy for future deployments

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 4 Jun 2014 11:44:54 -0700
Toshio Kuratomi  wrote:

> 
> This came up in a different venue and pingou and I have continued to
> talk about it.  Seemed that this was the right place to bring the
> discussion though.
> 
> Some observations:
> 
> * Pkgdb2 and a call for testing in staging was announced well in
> advance of the deployment to production (good) but not everyone
> understood that we were going to be breaking API (bad).
> 
> * There were people inside of fedora infrastructure and outside of
>   infrastructure who were surprised by the API break.  There were
> also some community members and infrastructure members who heeded the
> call for testing and both gave feedback and ported before the
> deployment.
> 
> * There was a FAS2 update that pkgdb2 depended upon.  That was also
> pending in stg for a long time and also had some minor API changes
> (IIRC, all unintentional.  I hotfixed one of them that was simply a
> bug last week). These also caused issues for some scripts.
> 
> * Unexpected problems: we had things that we didn't know used the
> pkgdb API, things that weren't tested in stg because stg couldn't
> replicate that part of production, and things that were ported but
> mistakes caused the ported scripts to not be deployed or to point at
> stg instead of production. I saw that we had the right people on IRC
> throughout the day working on analyzing and patching all of the
> broken things so. However, this was somewhat by accident and some of
> those people were surprised that they spent their day doing this.
> 
> 
> Some ideas for doing major deployments in the future:
> 
> 1: We have to make people aware when a new deployment means API
> breaks.
>   * Be clear that the new deployment means API breaks in every call
> for testing.  Send announcements to infrastructure list and depending
> on the service to devel list.
>   * Have a separate announcement besides the standard outage
> notification that says that an API breaking update is planned for
> $date
>   * When we set a date for the new deployment, discuss it at least
> once in a weekly infrastructure meeting.
>   * See also the solution in #3 below

I have a suggestion make everything provide and validate api info.

this is something koji does, though we to date have not broken api, we
expect we will do when we start on koji-2.0  so each app would provide
a getAPIVersion() function, then the consumers validate that they know
how to talk to that API version.

for bodhi for instance apps could check for api version if it fails
assume version 1 and then be able to support both version 1 and 2, when
we deploy live bodhi2 the clients like fedpkg update will transparently
switch over.

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTj51hAAoJEH7ltONmPFDRZB4P/1R3cdAlSMPatOVoGw8QYgzq
khMZKCaNjQT0V3KI5b4yl0MA6VqUXjlhT9SuscWMuQD8eADkizXbVzyHUQxMAz/F
rlAeezgHss/LRt51TmrHhpBupuzDQKHtzh1wrlz1b6KQgnR7ZuyLF0pgdgN4EaiY
Ydtpj0pg7Bm+4x98TgmfoCcugiLuKNSFVyxYCc4Erkr4YB1BEF6VhGZJ1yvlkq23
hugsNbLx6/oGKg18U5QDKPmwl/AuOSOK7hVz+nHDQmjn9x24l2x/yq9KAN8++RMN
2kfqwM3QEJ+qqMoauZc8JiLxJYCATLk3xmrfUKlKF29D1Wy13riburt+VXmmCxyt
PP8QSRWgTesJzecN7YS58Q8HG8Fu209K9mpVLGExg9KEseAAU+Ccm+B2er02gDTw
VJKI/fP341IerEVtF2BFKd6FHhe3yPpzKpAe7pbOcTOi1rDmZSEI9Z7kuLucK/EE
tQSm5ZyXqgOdAvC3nhvTwm1OSRvjDb4zcg+p+Uwgxw/vs6V9c8cxcmQlGQGv6HDd
0VBKsyzhu1cVWJy0pCJHUa4qeztxTkBN167lISxtivTIGhdaIl/HrnEJjBDmXWCO
FMaM/sWVKxMPTetkFFJ96AoxV1E8qzSAXdq2+CqfVQpgPETMMnUsUO7sfTHXGX2i
UAVScMl0M1PBZos1upa6
=0xdj
-END PGP SIGNATURE-
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

pkgdb2 post-mortem and strategy for future deployments

[Toshio Kuratomi]

This came up in a different venue and pingou and I have continued to talk
about it.  Seemed that this was the right place to bring the discussion
though.

Some observations:

* Pkgdb2 and a call for testing in staging was announced well in advance of
  the deployment to production (good) but not everyone understood that we
  were going to be breaking API (bad).

* There were people inside of fedora infrastructure and outside of
  infrastructure who were surprised by the API break.  There were also some
  community members and infrastructure members who heeded the call for
  testing and both gave feedback and ported before the deployment.

* There was a FAS2 update that pkgdb2 depended upon.  That was also pending
  in stg for a long time and also had some minor API changes (IIRC, all
  unintentional.  I hotfixed one of them that was simply a bug last week).
  These also caused issues for some scripts.

* Unexpected problems: we had things that we didn't know used the pkgdb API,
  things that weren't tested in stg because stg couldn't replicate that part
  of production, and things that were ported but mistakes caused the ported
  scripts to not be deployed or to point at stg instead of production.
  I saw that we had the right people on IRC throughout the day working on
  analyzing and patching all of the broken things so. However, this was
  somewhat by accident and some of those people were surprised that they
  spent their day doing this.


Some ideas for doing major deployments in the future:

1: We have to make people aware when a new deployment means API breaks.
  * Be clear that the new deployment means API breaks in every call for
testing.  Send announcements to infrastructure list and depending on the
service to devel list.
  * Have a separate announcement besides the standard outage notification
that says that an API breaking update is planned for $date
  * When we set a date for the new deployment, discuss it at least once in
a weekly infrastructure meeting.
  * See also the solution in #3 below

2: It would be really nice for people to do more testing in stg.
  * Increase rube coverage.  rube does end-to-end testing so it's better at
catching cross-app issues where API changes better than unittests which
try to be small and self-contained
- A flock session where everyone/dev in infra gets to write one rube
  test so we get to know the framework
  * Run rube daily
- Could we run rube in an Xvfb on an infrastructure host?
  * Continue to work towards a complete replica of production in the stg
environment.

3: "Mean time to repair is more important than mean time between failure."
   It seems like anytime there's a major update there's unexpected things that
   break.  Let's anticipate the unexpected happening.
  * Explicitly plan for everyone to spend their day firefighting when we
make a major new deployment.  If you've already found all the places
your code is affected and pre-ported it and the deployment goes smoothly
then hey, you've got 6 extra working hours to shift back to doing other
things.  If it's not smooth, then we've planned to have the attention of
the right people for the unexpected difficulties that arise.
  * As part of this, we need to identify people outside of infrastructure
that should also be ready for breakage.  Reach out to rel-eng, docs, qa,
cvsadmins, etc if there's a chance that they will be affected.

4: Related to the FAS release: Buggy code happens.  How can we make it
   happen less?
  * More unittests would be good however we know from experience with bodhi
that unittests don't catch a lot of things that are changes in behaviour
rather than true "bugs".  Unexpected API changes that cause people
porting pain can be as simple as returning None instead of an empty list
which causes a no-op iteration in running code to fail while the
unittests survive because they're checking that "no results were
returned".
   * Pingou has championed making API calls and WebUI calls into separate
 URL endpoints. I think that coding style makes it easier to control
 bugs related to updating the webui while trying to preserve the API so
 we probably want to move to that model as we move onto the next major
 version of our apps.
   * Not returning json-ified versions of internal data structures (like
 database tables) but instead parsing the results and returning
 a specific structure would also help divorce internal changes from
 external API.

What should we apply this to?
* Probably can skip if:
  - Things that we don't think have API breaks
  - Things that are minor releases (hopefully these would correlate with not 
having API breaks :-)
  - Leaf services that are not essential to releasing Fedora.
+ ask, nuancier, elections, easyfix, badges, paste, nuancier
+ There's a lot of boderline cases too -- is fedocal essential enough
  to warrant being unde

test post, please ignore

[Kevin Fenzi]

Just testing, please go back to eating turkey or relaxing. 

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: clear pkgs01 cgit cache (post +1's)

[Toshio Kuratomi]

On Wed, Aug 29, 2012 at 08:52:30AM -0600, Kevin Fenzi wrote:
> On Wed, 29 Aug 2012 02:43:44 -0400
> Ricky Elrod  wrote:
> 
> > I just worked with puiterwijk on IRC to fix this infra ticket:
> > https://fedorahosted.org/fedora-infrastructure/ticket/3455
> > 
> > I forgot to get +1's, and would like to make up for it by asking for
> > them now.
> > 
> > All I did was:
> > 
> > mkdir /root/cgit-cache-20120829/
> > mv /var/cache/cgit/* /root/cgit-cache-20120829/
> > 
> > and checked that things still worked, then closed the ticket.
> > 
> > Sorry for not checking in advanced.
> 
> I don't know that this needs +1's, as it was a 'outage' of sorts... ;) 
> 
> But +1 anyhow. 
> 
+1

It might also be considered as working with the data on the system rather
than changing the system itself.

Always nice to get a heads up about what's happening though.

-Toshio


pgpO2KM9PPVWt.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: clear pkgs01 cgit cache (post +1's)

[Kevin Fenzi]

On Wed, 29 Aug 2012 02:43:44 -0400
Ricky Elrod  wrote:

> I just worked with puiterwijk on IRC to fix this infra ticket:
> https://fedorahosted.org/fedora-infrastructure/ticket/3455
> 
> I forgot to get +1's, and would like to make up for it by asking for
> them now.
> 
> All I did was:
> 
> mkdir /root/cgit-cache-20120829/
> mv /var/cache/cgit/* /root/cgit-cache-20120829/
> 
> and checked that things still worked, then closed the ticket.
> 
> Sorry for not checking in advanced.

I don't know that this needs +1's, as it was a 'outage' of sorts... ;) 

But +1 anyhow. 

Thanks for looking into it. 

kevin



signature.asc
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

clear pkgs01 cgit cache (post +1's)

[Ricky Elrod]

I just worked with puiterwijk on IRC to fix this infra ticket:
https://fedorahosted.org/fedora-infrastructure/ticket/3455

I forgot to get +1's, and would like to make up for it by asking for
them now.

All I did was:

mkdir /root/cgit-cache-20120829/
mv /var/cache/cgit/* /root/cgit-cache-20120829/

and checked that things still worked, then closed the ticket.

Sorry for not checking in advanced.

-Ricky



signature.asc
Description: OpenPGP digital signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Freeze break for post-update hook on pkgs01?

[Kevin Fenzi]

On Thu, 16 Aug 2012 15:01:34 -0500
"Jason L Tibbitts III"  wrote:

> > "KF" == Kevin Fenzi  writes:
> 
> KF> Yeah, we are in pre-alpha freeze.  See:
> KF> 
> https://fedorahosted.org/fedora-infrastructure/browser/architecture/Environments.png
> KF> pkgs01 (where this change would need to happen) is under the
> KF> freeze.
> 
> But that's precisely my confusion.  If we can't change a repository
> git hook without a freeze break, then should we also not be
> processing SCM requests?  If someone asked me to delete a branch from
> a repository or make some other SCM-admin-related change (which
> admittedly happens rather rarely), is that also a freeze break?

Freeze breaks are required to run things or make changes to existing
processes. The "normal" activities of a frozen host requires no freeze
break request. 

So, doing scm requests - fine. 
deleting a branch from a single project - fine. 

Changing the hooks for all projects - needs a freeze break. 
Changing config for the host thats in puppet - needs a freeze break. 
Migrating all git repos to darcs - needs a sanity check^W^Wfreeze
break. 

Does that help? 

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Freeze break for post-update hook on pkgs01?

[Jason L Tibbitts III]

> "KF" == Kevin Fenzi  writes:

KF> Yeah, we are in pre-alpha freeze.  See:
KF> 
https://fedorahosted.org/fedora-infrastructure/browser/architecture/Environments.png
KF> pkgs01 (where this change would need to happen) is under the freeze.

But that's precisely my confusion.  If we can't change a repository git
hook without a freeze break, then should we also not be processing SCM
requests?  If someone asked me to delete a branch from a repository or
make some other SCM-admin-related change (which admittedly happens
rather rarely), is that also a freeze break?

 - J<
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Freeze break for post-update hook on pkgs01?

[Ralph Bean]

Ok, this should be all fixed up now.
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Freeze break for post-update hook on pkgs01?

[Kevin Fenzi]

On Thu, 16 Aug 2012 09:17:40 -0500
"Jason L Tibbitts III"  wrote:

> >>>>> "RB" == Ralph Bean  writes:
> 
> RB>   1) Run "git check-perms /srv/git/rpms --check=post-update --fix"
> RB> on pkgs01 again to fix the handful of repos that are out of sync.
> 
> I wouldn't have realized that we were frozen in such a way as to
> prevent this kind of thing.  I'd +1 myself but I'm not sure if I have
> standing to do so.

Yeah, we are in pre-alpha freeze. 
See:
https://fedorahosted.org/fedora-infrastructure/browser/architecture/Environments.png
pkgs01 (where this change would need to happen) is under the freeze. 

The rule for +1's for freeze break is sysadmin-main and
sysadmin-releng only. However, feedback is very welcome from anyone. 
If you see a problem or have a concern, please do bring it up, or if
you think it's ok, thats good to to know too. 

> RB>   2) Apply the following patch in puppet which will add the hook
> RB> for new repos.
> 
> I'd +1 this as well, but if there's controversy I could also modify
> the SCM processing script to do this.  It's not, to my knowledge,
> subject to any freeze.

Yeah, best to do all the git setup in the same place tho... 

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Freeze break for post-update hook on pkgs01?

[Ralph Bean]

On Thu, Aug 16, 2012 at 08:55:16AM -0600, Kevin Fenzi wrote:
> (That just needs to run on the list of newer ones? or over the entire
> packages?)

Yeah, I can run it on only the newer ones.  That should lighten the
load.
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Freeze break for post-update hook on pkgs01?

[Kevin Fenzi]

On Thu, 16 Aug 2012 09:54:46 -0400
Ralph Bean  wrote:

> 
> I'm seeking +1s for a freeze break to make the following two changes:
> 
>   1) Run "git check-perms /srv/git/rpms --check=post-update --fix" on
> pkgs01 again to fix the handful of repos that are out of sync.

+1 

(That just needs to run on the list of newer ones? or over the entire
packages?)
>   2) Apply the following patch in puppet which will add the hook for
> new repos.

+1

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Freeze break for post-update hook on pkgs01?

[Toshio Kuratomi]

On Thu, Aug 16, 2012 at 10:45:56AM -0400, Ralph Bean wrote:
> 
> On Thu, Aug 16, 2012 at 07:32:39AM -0700, Toshio Kuratomi wrote:
> > On Thu, Aug 16, 2012 at 09:54:46AM -0400, Ralph Bean wrote:
> > >   1) Run "git check-perms /srv/git/rpms --check=post-update --fix" on 
> > > pkgs01
> > >  again to fix the handful of repos that are out of sync.
> > > 
> > Does this cause any end-user visible load on the server?
> 
> It takes a significant amount of time to run (a few hours).  But it
> does not appear to impact user performance:
> 
>  1) We received no complaints last time we ran it
>  2) I just tested cloning a package 3 times from pkgs.stg with and
> without "git check-perms" running on the server.  The times taken
> to complete the operations were indistinguishable.
>
+1 to the freeze break request.

-Toshio


pgpp5dG8Bl4dE.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Freeze break for post-update hook on pkgs01?

[Ralph Bean]

On Thu, Aug 16, 2012 at 07:32:39AM -0700, Toshio Kuratomi wrote:
> On Thu, Aug 16, 2012 at 09:54:46AM -0400, Ralph Bean wrote:
> >   1) Run "git check-perms /srv/git/rpms --check=post-update --fix" on pkgs01
> >  again to fix the handful of repos that are out of sync.
> > 
> Does this cause any end-user visible load on the server?

It takes a significant amount of time to run (a few hours).  But it
does not appear to impact user performance:

 1) We received no complaints last time we ran it
 2) I just tested cloning a package 3 times from pkgs.stg with and
without "git check-perms" running on the server.  The times taken
to complete the operations were indistinguishable.
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Freeze break for post-update hook on pkgs01?

[Toshio Kuratomi]

On Thu, Aug 16, 2012 at 09:54:46AM -0400, Ralph Bean wrote:
> When we were adding the fedmsg hooks to pkgs01 and pkgs01.stg, we decided it
> would be a nice "extra" to run "git update server-info" on each repo for each
> push.  This made cloning via http possible.
> 
> We ran a script "git check-perms /srv/git/rpms --check=post-update --fix" on
> pkgs01 that added this hook for every repo, but I forgot to add it to
> "setup_git_package" so that it would be added for every new repo.  Now there
> are a handful of repos that do not have the hook, while most others do.
> 
> Other than the inconsistency, this doesn't matter all too much.  It is
> annoying, however, due to a cron job that is checking for the new hook,
> failing to find it, and bothering sysadmins about it over email.
> 
> I'm seeking +1s for a freeze break to make the following two changes:
> 
>   1) Run "git check-perms /srv/git/rpms --check=post-update --fix" on pkgs01
>  again to fix the handful of repos that are out of sync.
> 
Does this cause any end-user visible load on the server?

>   2) Apply the following patch in puppet which will add the hook for new 
> repos.
> 
+1

-Toshio


pgpmG0mTsG0Ty.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Re: Freeze break for post-update hook on pkgs01?

[Jason L Tibbitts III]

>>>>> "RB" == Ralph Bean  writes:

RB>   1) Run "git check-perms /srv/git/rpms --check=post-update --fix"
RB> on pkgs01 again to fix the handful of repos that are out of sync.

I wouldn't have realized that we were frozen in such a way as to prevent
this kind of thing.  I'd +1 myself but I'm not sure if I have standing
to do so.

RB>   2) Apply the following patch in puppet which will add the hook for
RB> new repos.

I'd +1 this as well, but if there's controversy I could also modify the
SCM processing script to do this.  It's not, to my knowledge, subject to
any freeze.

 - J<
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

Freeze break for post-update hook on pkgs01?

[Ralph Bean]

When we were adding the fedmsg hooks to pkgs01 and pkgs01.stg, we decided it
would be a nice "extra" to run "git update server-info" on each repo for each
push.  This made cloning via http possible.

We ran a script "git check-perms /srv/git/rpms --check=post-update --fix" on
pkgs01 that added this hook for every repo, but I forgot to add it to
"setup_git_package" so that it would be added for every new repo.  Now there
are a handful of repos that do not have the hook, while most others do.

Other than the inconsistency, this doesn't matter all too much.  It is
annoying, however, due to a cron job that is checking for the new hook,
failing to find it, and bothering sysadmins about it over email.

I'm seeking +1s for a freeze break to make the following two changes:

  1) Run "git check-perms /srv/git/rpms --check=post-update --fix" on pkgs01
 again to fix the handful of repos that are out of sync.

  2) Apply the following patch in puppet which will add the hook for new repos.

diff --git a/modules/gitolite/files/distgit/setup_git_package 
b/modules/gitolite/files/distgit/setup_git_package
index bd42b95..eeaa16f 100755
--- a/modules/gitolite/files/distgit/setup_git_package
+++ b/modules/gitolite/files/distgit/setup_git_package
@@ -121,6 +121,9 @@ ln -s /usr/share/git-core/post-receive-fedmsg \
 ln -s /usr/share/git-core/post-receive-chained \
 $GITROOT/$PACKAGE.git/hooks/post-receive
 
+# This executes "git update-server-info" on each push for clone via http
+ln -s /usr/share/git-core/templates/hooks/post-update.sample \
+$GITROOT/$PACKAGE.git/hooks/post-update
 
 rm -rf $TMPDIR
 echo "Done."
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure

attempted hosted migration to gluster back end post-mortem

[seth vidal]

As most/all people know we attempted to migrate hosted to using a
gluster backend across two systems on wednesday evening. Thursday we
awoke to a host of problems and tackled solving them. Thursday evening
we migrated back to our previous configuration.

Thanks for the patience on thursday everyone. 
-sv


The below is the explanation of what all happened:


Hosted migration started on wednesday afternoon

plan was to move to glusterfs from a single node/drbd failover
configuration

hosted01 and hosted02 would become 'hosted' - both serving files
from /srv (our glusterfs share)

both systems were clients and servers (in glusters sense):
 - both systems exporting a brick of the same replica.
 - both systems mounting that replicated share.

when mounting with fuse we started seeing pretty serious performance
issues to the point that users were complaining it was not working. It
would take 20-30s to render a single ticket from trac.

We switched to nfs mounts and performance improved but we saw enormous
number of db locking issues on the servers. 

At this point we contacted the gluster upstream developers who were
outrageously helpful in tracking down the problems.

After some research it was determined that:

- gluster 3.2 over nfs doesn't support any remote locking at all
- if we brought things down to 1 node and local_lock=all then things
  would work and perform 'ok' but would not allow us to access from the
  other client
- this meant we could replicate the fs but not use it from both hosts

After moving to gluster over nfs we ran into a new problem:

  gluster's nfs server does not support --manage-gids so we were
restricted to 16 gids per user. No solution outside of new code for
this one - investigation into doing that for gluster ++ is occurring


jdarcy and pranithk given sysadmin-hosted access to look at logs
directly on hosted01/02 to look up on the split-brain reports we were
seeing.

jdarcy and pranithk tracked the self-heal/split brain problems back to
dirs with out of sync fattrs. The only way to solve this was to
manually remove the out of sync fattrs after verifying that ONLY the
fattrs were out of sync and not any data.
this involved looking at all dirs with self-heal problems and running:

> setfattr -x trusted.afr.hosted-client-0 /glusterfs/hosted/$dir
> setfattr -x trusted.afr.hosted-client-1 /glusterfs/hosted/$dir

to clear those settings then reaccessing the dir at:
 /srv/$dir
 
 to force the self-heal to complete correctly.
 
 
At this point we did not appear to be having self-heal issues but we
still have the group-ids limited to 16 under the nfs clients.

The only option to resolve that is to patch the gluster nfs server to
do the equivalent of --manage-gids.

We attempted to see if we could optimize the fuse mounts to work around
the nfs limitations. We set the fuse mount up hosted02 and did
performance tests - they were 'okay' but not really acceptable.
Additionally, after testing fuse enhancements we were informed that fuse
suffers from the same 16 gid limitation that nfs suffers from. so we
are completely dead in the water.

We punted back to hosted03 - re-rsyncing everything back.

We also setup a new host: hosted-list01.fedoraproject.org at internetx.
This will allow us to move the hosted mailing lists OFF of
fedorahosted.org which gains us a lot of latitude in how we move around
projects that we did not have before.


We will start on the gluster migration + testing if/when we get a patch
for 3.3 from jdarcy to handle > 16gids via nfs.

If that occurs we will be testing to handle the following problems:
 
Tests to run once we get 3.3 and the > 16 gid patch in place:
1. that nfs locking actually works (test with local_lock=none) and a
sqlite3 .dump rm -f /srv/trac/projects/fedora-infrastructure/db/fixed.db
sqlite3 /srv/trac/projects/fedora-infrastructure/db/trac.db |
sqlite3 /srv/trac/projects/fedora-infrastructure/db/fixed.db 
2. that writes with a gid beyond 16 works
3. that performance is palatable: cloning git repos
4. test trac with both systems
5. look for self-healing issues
6. failover testing. Kill one node and confirm other works with limited
problems.


Things to do before production of gluster:
- MOVE GITWEB CACHING OFF OF /srv


Much thanks to the gluster dev team in helping us track down where the
problems were coming from and attempting to help us fix them. Their
help was indispensable.

 
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure