Freeze Broken by Accident: pagure02.fedoraproject.org

[Stephen John Smoogen]

I ran `dnf update` on pagure02.fedoraproject.org thinking I was working on
a different system. The box has been updated to the latest packages. Once I
realized my mistake I reviewed the changes and did not see anything that I
felt would affect pagure's operation.

-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Sourcegraph and exploded sources

[Stephen John Smoogen]

On Sat, 20 Nov 2021 at 15:05, Matthew Miller  wrote:
>
> I mentioned on devel list that Sourcegraph is going to be indexing
> source.fedoraproject.org.
>
> So I guess, first — heads-up! if you see their traffic, it's not malicious.
> (I asked them to provide us with the user agent they use, and I'll pass that
> on.)
>
> But then, I'd actually like to go a step further, and have them index _the
> actual source for every build_. They're open to doing that, but what they
> need is a git repo.
>
> So.. how hard / ridiculous / bad would it be to have a step in the build
> process in koji which, between the %prep and %build phases, push the
> unpacked-and-prepped source tree to Gitlab, under, say,
> https://gitlab.com/fedora/exploded-build-sources/package-name/?
>

0. When you mean %prep and %build you mean where koji builds a src.rpm
and then the builders get it versus the prep/build stage of mock?
1. I don't think the builders don't have access to the internet to do
that. Koji would have access but it is a limited resource.
2. I don't think you want any and every build to be broken because we
could not get to gitlab for a push due to timeouts, problems with
snips in the code etc.

You would want to plumb this into the build process as a completely
new tool. It would need a dedicated box which does this and it would
need to be able to
a) not stop builds and composes
b) be able to queue these actions so a mass rebuild doesn't take weeks
c) be able to resend/redo when we hit gitlab max actions per
second/hour. [Even paid accounts have quotas to keep overall service
working]
d) deal with MBS issues.

Otherwise you are going to run into various limitations that could
break the koji+mbs+pdc+bodhi+composer+etc which are all built with
certain tolerances and break when something slows things down.



> I'm imaginging this would work something like this:
>
> 1. If remote repo doesn't exist, create it with the gitlab api
>
> 2. Do a shallow, no-checkout clone of that remote repo, using
>--git-dir and --work-tree so that the .git directory isn't created inside
>the working directory
>
> 3. copy the unpacked source tree from %prep into the work-tree dir
>(are we building on btrfs? cp -l if not, to save io?)
>
> 4. git add --all
>
> 5. git commit -m "Build ID: ${buildID} 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=${buildID};
>
> 6. git push
>
>
> With some details to be worked out. :) Like, repo tags as branches, maybe?
> And, do this on all arches, or just one of them? Or maybe run up through
> %prep as part of the src build rather than any of the binary builds? Make
> the commit as the Fedora username of the person who did the build?
>
> But those kinds of implementation details aside -- does this seem like
> something we might be able to do?
>
> Or, any ideas for an alternate approach? I mean, obviously, source-git would
> be one such alternative, but getting that for _everything_ would require a
> big rework of how everyone works. (I think we should get to that eventually,
> but that's a long way off.)
>
> --
> 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



-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
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

Re: Fedorapeople webspace

[Stephen John Smoogen]

On Fri, 5 Nov 2021 at 09:22, James Smith  wrote:
>
> That is an old account, the new account is osiris2600
>

OK I found the problem, and my apologies for missing the obvious. Your
account was created in /home/osiris2600 and I was looking where all
the other accounts are (/home/fedora//). Apache is looking for
your account to be in that tree so your web page isn't showing up.
Please open a ticket in
https://pagure.io/fedora-infrastructure/new_issue so that the issue
can be corrected in the config files and/or your account.



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

Re: Fedorapeople webspace

[Stephen John Smoogen]

On Fri, 5 Nov 2021 at 09:11, James Smith  wrote:
>
> My FAS account is osiris2600 - 
> https://accounts.fedoraproject.org/user/osiris2600/
>

[2021-11-05-09:14]  .fasinfo smittix
[2021-11-05-09:14]  User: smittix, Name: James Smith, Email:
jamessmi...@outlook.com, Creation: 2012-02-14T11:28:32, IRC Nicks:
osiris2600, Timezone: Europe/London, Locale: en-GB, GPG Key IDs: None,
Status: None
[2021-11-05-09:14]  Groups: fedora-contributor, ambassadors, fedora-uk
[2021-11-05-09:14]  .fasinfo osiris2600
[2021-11-05-09:14]  User: osiris2600, Name: James Smith,
Email: fed...@lsass.co.uk, Creation: 2021-11-04T19:24:59, IRC Nicks:
osiris2600 and osiris, Timezone: GB, Locale: en-GB, GPG Key IDs: None,
Status: None
[2021-11-05-09:14]  Groups: fedora-contributor, ambassadors, fedora-uk

[root@people02 fedora][PROD]# ls -l osiris2600
ls: cannot access osiris2600: No such file or directory
[root@people02 fedora][PROD]# ls -l smittix
total 0
drwxrwxr-x. 2 smittix smittix 21 Jan 13  2014 public_html

The account you set permissions to was smittix.


> -Original Message-
> From: Stephen John Smoogen 
> Sent: 05 November 2021 12:58
> To: Fedora Infrastructure 
> Subject: Re: Fedorapeople webspace
>
> On Fri, 5 Nov 2021 at 06:54, James Smith  wrote:
> >
> > Good morning, all,
> >
> > I'm having a small issue with the fedorapeople webspace. I've created a 
> > public_html directory with permissions set to 755 however I'm still getting 
> > a forbidden message when navigating to 
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fosiris2600.fedorapeople.org%2Fdata=04%7C01%7C%7C7bc3407e1a944d87e7a108d9a05bfbd2%7C84df9e7fe9f640afb435%7C1%7C0%7C637717139219464101%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=BGfUzWYHUhHD7sa0nuWtW3S%2F4xBwpk2oscgDwbboBxc%3Dreserved=0.
> >
>
> Fedora people web pages are aligned to your FAS username which is not 
> osiris2600. So you need to go to https://.fedorapeople.org
> like 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsmooge.fedorapeople.org%2Fdata=04%7C01%7C%7C7bc3407e1a944d87e7a108d9a05bfbd2%7C84df9e7fe9f640afb435%7C1%7C0%7C637717139219474063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=61jM8umPdnGMFyEk8KYxT7OtOIbPcZgNj4RFZpRi41c%3Dreserved=0
>
>
> > Any ideas?
> >
> > thanks in advance
> >
> > James Smith
> > ___
> > infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> > To unsubscribe send an email to
> > infrastructure-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc
> > s.fedoraproject.org%2Fen-US%2Fproject%2Fcode-of-conduct%2Fdata=04
> > %7C01%7C%7C7bc3407e1a944d87e7a108d9a05bfbd2%7C84df9e7fe9f640afb435
> > %7C1%7C0%7C637717139219474063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
> > sdata=Begs%2BgbT0AKERWsTJXcRdnYiq0bZcSGtgs0%2Fdqvzoo8%3Dreserved=
> > 0 List Guidelines:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffed
> > oraproject.org%2Fwiki%2FMailing_list_guidelinesdata=04%7C01%7C%7C
> > 7bc3407e1a944d87e7a108d9a05bfbd2%7C84df9e7fe9f640afb435%7C
> > 1%7C0%7C637717139219474063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA
> > iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=GfdMX
> > NmqmOc%2BmE9IAPAFJYPFFr8B4exDJc2BtHk%2BkTE%3Dreserved=0
> > List Archives:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
> > ts.fedoraproject.org%2Farchives%2Flist%2Finfrastructure%40lists.fedora
> > project.orgdata=04%7C01%7C%7C7bc3407e1a944d87e7a108d9a05bfbd2%7C8
> > 4df9e7fe9f640afb435%7C1%7C0%7C637717139219474063%7CUnknown
> > %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> > XVCI6Mn0%3D%7C1000sdata=QkKow8d3ywcVSL%2Ba25UXOHythb2t9MpWTurrytM
> > o6zU%3Dreserved=0 Do not reply to spam on the list, report it:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpag
> > ure.io%2Ffedora-infrastructuredata=04%7C01%7C%7C7bc3407e1a944d87e
> > 7a108d9a05bfbd2%7C84df9e7fe9f640afb435%7C1%7C0%7C637717139
> > 219474063%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=t7uytI6WpCYm%2FGlKZB1V
> > 4ft7kspWFTCgDnUIe%2Bm%2Fdtk%3Dreserved=0
>
>
>
> --
> Stephen J Smoogen.
> I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. 
> I have seen SPAM filter

Re: Fedorapeople webspace

[Stephen John Smoogen]

On Fri, 5 Nov 2021 at 06:54, James Smith  wrote:
>
> Good morning, all,
>
> I'm having a small issue with the fedorapeople webspace. I've created a 
> public_html directory with permissions set to 755 however I'm still getting a 
> forbidden message when navigating to https://osiris2600.fedorapeople.org.
>

Fedora people web pages are aligned to your FAS username which is not
osiris2600. So you need to go to https://.fedorapeople.org
like https://smooge.fedorapeople.org


> Any ideas?
>
> thanks in advance
>
> James Smith
> ___
> 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



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

Re: FBR: fix download cron on download-cc-rdu

[Stephen John Smoogen]

Merging and deploying.

On Mon, 18 Oct 2021 at 16:53, Kevin Fenzi  wrote:
>
> +1 here.
>
> kevin
> --
> On Mon, Oct 18, 2021 at 03:12:44PM -0400, Stephen John Smoogen wrote:
> > https://pagure.io/fedora-infra/ansible/pull-request/834
> >
> > -- Forwarded message -
> > From: (Cron Daemon) 
> > Date: Mon, 18 Oct 2021 at 15:00
> > Subject: Cron  /usr/local/bin/lock-wrapper
> > sync-up-downloads "/usr/local/bin/sync-up-centos"
> > To: 
> >
> >
> > /usr/local/bin/lock-wrapper: line 50: /usr/local/bin/sync-up-centos:
> > No such file or directory
> >
> >
> > --
> > Stephen J Smoogen.
> > I've seen things you people wouldn't believe. Flame wars in
> > sci.astro.orion. I have seen SPAM filters overload because of Godwin's
> > Law. All those moments will be lost in time... like posts on a BBS...
> > time to shutdown -h now.
> > ___
> > 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
> ___
> 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



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

FBR: fix download cron on download-cc-rdu

[Stephen John Smoogen]

https://pagure.io/fedora-infra/ansible/pull-request/834

-- Forwarded message -
From: (Cron Daemon) 
Date: Mon, 18 Oct 2021 at 15:00
Subject: Cron  /usr/local/bin/lock-wrapper
sync-up-downloads "/usr/local/bin/sync-up-centos"
To: 


/usr/local/bin/lock-wrapper: line 50: /usr/local/bin/sync-up-centos:
No such file or directory


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

Re: Freeze break request: revert docs redirect

[Stephen John Smoogen]

+1 to fix.

On Mon, 11 Oct 2021 at 13:06, Kevin Fenzi  wrote:
>
> I'd like to revert this commit and remove
> /etc/httpd/conf.d/docs.fedoraproject.org/workstation-main on all proxies
> and reload httpd on them.
>
> This redirect never worked, and they are going to fix it by just
> renaming the branch for now. ;(
>
> +1s?
>
> kevin
> --
> commit decf1ed65e3f7266d14f5592c60ed6d3dee6f9c2
> Author: Kevin Fenzi 
> Date:   Wed Sep 29 15:33:56 2021 -0700
>
> proxies: redirect / to /main for workstation-working-group
>
> Right now there's a issue in the docs pipeline where it's not handling
> the main branch right, add this temp redirect to work around that until
> it's fixed properly in docs.
>
> See https://pagure.io/fedora-infrastructure/issue/10243
>
> Signed-off-by: Kevin Fenzi 
>
> diff --git a/playbooks/include/proxies-redirects.yml 
> b/playbooks/include/proxies-redirects.yml
> index 6747dc581..114ef7567 100644
> --- a/playbooks/include/proxies-redirects.yml
> +++ b/playbooks/include/proxies-redirects.yml
> @@ -884,3 +884,9 @@
>  website: qa.fedoraproject.org
>  path: /
>  target: https://fedoraproject.org/wiki/QA
> +
> +  - role: httpd/redirectmatch
> +shortname: workstation-main
> +website: docs.fedoraproject.org
> +regex: ^(.*)/workstation-working-group/
> +target: https://docs.fedoraproject.org/$1/main/
>
>
> ___
> 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



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

Re: Retroactive freeze break: httpd update

[Stephen John Smoogen]

On Tue, 5 Oct 2021 at 18:04, Kevin Fenzi  wrote:
>
> I've updated all our fedora 34 hosts to httpd-2.4.50-1.fc34
> in order to protect us from CVE-2021-41773.
>
> Since this was a security issue, I just went ahead and did it.
>

I would have done the same thing but forgotten to say I did.. so +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://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



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

Re: Freeze break request: disable fedmsg-irc bots in most channels

[Stephen John Smoogen]

I am ok with this. +1

On Thu, 23 Sept 2021 at 17:09, Kevin Fenzi  wrote:
>
> Currently, the fedmsg-irc role connects a number of IRC bots to
> libera.chat IRC. (Usually 2 per channel, one for production and one for
> staging). These bots then send fedmsgs that match a specific regex to
> the channel they are in.
>
> As part of setting up matrix rooms and bridging them to IRC, we have
> realized how noisy these bots tend to be. In almost all cases the
> tickets/message/event is sent to people who care about it via email or
> personal FMN notification, so the message in the channel is just noise.
>
> Additionally, these fedmsg-irc bots don't have a ton of flexability in
> what they match on, for example if you say 'perhaps we should add a
> badge for this' in a ticket, it will then forever notify the
> #fedora-badges channel about any changes to that ticket.
>
> Additionally, fedmsg-irc is python2 and tied to fedmsg (not
> fedora-messaging). If we can get rid of all use of them that saves us
> some replacement costs.
>
> So, I would like to drop all these bots, except for #fedora-fedmsg and
> #fedora-fedmsg-stg. I personally think those channels are useful as you
> can watch the bus flow and tell things about it's health and see overall
> changes you might not otherwise notice. They might be replaceable by a
> more simple bot someday.
>
> Of course there may be some use case I am not seeing here, so if you
> _DO_ want these messages in your channel/room still, please tell us!
> Or if there's some other set of messages that would be of use that would
> be good to know too, so we could take it into account when/if we work on
> a matrix bot.
>
> Affected channels:
>
> #fedora-admin
> #fedora-commops
> #fedora-python
> #fedora-releng
> #fedora-latam
> #fedora-g11n
> #ipsilon
> #pagure
> #fedora-design
> #fedora-docs
> #fedora-websites
> #fedora-mktg
> #fedora-modularity-bots
> #fedora-diversity
> #fedora-magazine
> #fedora-rust
> #rit-foss
> #fedora-workstation
> #koji
> #fedora-join
> #fedora-neuro
> #fedora-badges
> #centos-ci
> #fedora-podcast
>
> https://pagure.io/fedora-infra/ansible/pull-request/811 is the PR with
> the changes.
>
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

Re: (retroactive) Freeze break: Proxy adjustments

[Stephen John Smoogen]

On Wed, 22 Sept 2021 at 15:19, Kevin Fenzi  wrote:
>
> Yesterday we were having lots of issues with proxy01/10 in IAD2.
> They would stop processing connections. Restarting httpd seemed to clear
> it up for a while, then it would get stuck again.
>
> My current theory is that we were hitting the limit of 900 clients for
> some reason and it wasn't processing them correctly when it got to that
> point.
>
> So, I increased that limit to 1500 and also setup a SSL session cache
> (which it was complaining about that we didn't have). Since then,
> proxy01/10 with those changes have been running ok.
>
> I'd like to push this out to the other proxies now as well, as some of
> them have been alerting from time to time and it could be this same
> issue.
>
> I already pushed this commit because I wanted 01/10 to be in sync/in
> git.
>
> +1's to push it to the rest of the proxies?
>

There is a second part to your change:

>  SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
> +SSLSessionCache shmcb:/run/httpd/sslcache(1024)

Is that part of this or something that got pulled in by accident?


> commit 313674646df60fc0e8342eff26094f694105cf76
> Author: Kevin Fenzi 
> Date:   Tue Sep 21 16:19:14 2021 -0700
>
> proxies: increase max workers
>
> Also add a ssl connection cache.
> These changes are live on proxy01/10 and seem to have made them stable
> again. Will look at pushing to the rest tomorrow.
>
> Signed-off-by: Kevin Fenzi 
>
> diff --git a/inventory/group_vars/proxies b/inventory/group_vars/proxies
> index c04531a57..5b0a25fee 100644
> --- a/inventory/group_vars/proxies
> +++ b/inventory/group_vars/proxies
> @@ -7,7 +7,7 @@ num_cpus: 6
>  # This is used in the httpd.conf to determine the value for serverlimit and
>  # maxrequestworkers. On 8gb proxies, 900 seems fine. But on 4gb proxies, this
>  # should be lowered in the host vars for that proxy.
> -maxrequestworkers: 900
> +maxrequestworkers: 1500
>
>  tcp_ports: [
>  # For apache, generally.
> diff --git a/roles/httpd/proxy/templates/httpd.conf.j2 
> b/roles/httpd/proxy/templates/httpd.conf.j2
> index 00947131f..5b1e0debf 100644
> --- a/roles/httpd/proxy/templates/httpd.conf.j2
> +++ b/roles/httpd/proxy/templates/httpd.conf.j2
> @@ -773,3 +773,5 @@ EnableSendfile on
>
>  # Configure a location for OCSP stapling
>  SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
> +SSLSessionCache shmcb:/run/httpd/sslcache(1024)
> +SSLSessionCacheTimeout  600
>
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

Re: Freeze break request: Add second datanommer server dns

[Stephen John Smoogen]

On Wed, 15 Sept 2021 at 12:53, Stephen John Smoogen  wrote:
>
> +1 from sysadmin-main smoogen

thanks for doing reverse DNS.
>
> On Wed, 15 Sept 2021 at 12:13, Mark O'Brien  wrote:
> >
> > Hi All,
> >
> > I have a dns patch for review.
> >
> > We would like to add a second datanommer db server
> > so that we can migrate the current database to it and
> > make some changes such as adding the timescaledb
> > plugin to improve performance. This second server would
> > allow the migration to happen without affecting the main
> > prod server.
> >
> > The patch is available to view here:
> > https://gist.github.com/markobrien1/1b242fb8e27da07253550abf328a5e8e
> >
> > Please chime in with comments or +1's
> >
> >
> > Thanks,
> > Mark
> > ___
> > 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
>
>
>
> --
> Stephen J Smoogen.
> I've seen things you people wouldn't believe. Flame wars in
> sci.astro.orion. I have seen SPAM filters overload because of Godwin's
> Law. All those moments will be lost in time... like posts on a BBS...
> time to shutdown -h now.



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

Re: Freeze break request: Add second datanommer server dns

[Stephen John Smoogen]

+1 from sysadmin-main smoogen

On Wed, 15 Sept 2021 at 12:13, Mark O'Brien  wrote:
>
> Hi All,
>
> I have a dns patch for review.
>
> We would like to add a second datanommer db server
> so that we can migrate the current database to it and
> make some changes such as adding the timescaledb
> plugin to improve performance. This second server would
> allow the migration to happen without affecting the main
> prod server.
>
> The patch is available to view here:
> https://gist.github.com/markobrien1/1b242fb8e27da07253550abf328a5e8e
>
> Please chime in with comments or +1's
>
>
> Thanks,
> Mark
> ___
> 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



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

Re: Freeze Break Request: Update rbac permissions for openshift apps

[Stephen John Smoogen]

On Tue, 14 Sept 2021 at 15:58, Mark O'Brien  wrote:
>
> Hi All,
>
> This is a request to run the batcave playbook to update rbac permissions to 
> allow the sysadmin-openshift group to run all the openshift playbooks in 
> ansible.
>
> The group currently contains the people who are putting up the new openshift 
> 4 cluster along with myself. This would give the group a large amount of 
> permissions so in future there would be a relatively high bar for joining the 
> group.
>

+1 as this is limited to systems not in production.

> Please feel free to share thoughts or +1's
>
> Mark
> ___
> 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



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

Re: another ipsilon freeze break

[Stephen John Smoogen]

On Mon, 13 Sept 2021 at 15:06, Stephen John Smoogen  wrote:
>
> On Mon, 13 Sept 2021 at 14:58, Kevin Fenzi  wrote:
> >
> > This time I just want +1s to run the ipsilon playbook.
> >
> > This will deploy the OIDC client data for the production ocp cluster we
> > are working on bringing up. It shouldn't cause any problems and woud be
> > easy to back out.
> >
> > +1s?
> >
>

I am ok with your plan. +1/



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

Re: Freeze Break Request: more ipsilon/sssd debugging

[Stephen John Smoogen]

On Mon, 13 Sept 2021 at 13:34, Kevin Fenzi  wrote:
>
> So, it turns out the additional debugging we setup in that sssd package
> on the ipsilon servers isn't sufficent to show what the problem is. ;(
>
> sssd developers would like us to crank up debugging to try and get logs
> of whats happening. Unfortunately, this will use a ton of disk space,
> which these vm's do not have much of. ;(
>
> I was going to ask to grow the disk on ipsilon02, but I think perhaps
> cleaner would be to create a NFS volume and mount it on /var/log/sssd/
> on ipsilon02. This way we don't need to actually take the machine down
> and it's really easy to back out.
>

Yeah either do an NFS or a seperate vmdisk to mount as that and then
blow away when done.

> So, can I get +1s to:
>
> * make a NFS volume and mount it on /var/log/sssd on ipsilon02
> * adjust ipsilon02's sssd to enable crazy levels of debug.
> * restart sssd and wait for the next failure.
> * profit!
>

I would try this and if NFS fails then go with a seperate disk for this.


> +1s? other ideas?
>
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

Re: Freeze Break Request: debugging sssd on ipsilon

[Stephen John Smoogen]

+1 as the alternative is still outage


On Thu, 9 Sept 2021 at 15:28, Kevin Fenzi  wrote:
>
> Greetings everyone.
>
> We have been having a sporadic issue for a while now where sssd on
> ipsilon01 and/or ipsilon02 goes into a error state and starts rejecting
> everyone's logins. ;( See https://fedorastatus.org and the ticket on
> this. It's really quite irritating.
>
> We have raised a ticket with sssd upstream and they need more
> information to find the bug. Toward that end, they have made a build of
> sssd that has debugging particular to this failure in it.
>
> So, I'd like to upgrade ipsilon01/02 to this debugging sssd build and
> wait for the problem to re-occur and get them the info they hopefully
> need to fix it.
>
> This build just has a small debugging patch on top of the existing
> fedora 34 build we are using now. We should be able to dnf distro-sync
> anytime to get back to the stock one.
>
> Can I get +1s to do this? :)
>
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

Re: FBR: add fedora-messaging queues for CentOS Stream robosignatory

[Stephen John Smoogen]

On Wed, 1 Sept 2021 at 14:40, kevin  wrote:
>
> On Wed, Sep 01, 2021 at 09:25:02AM -0500, Brian Stinson wrote:
> > Hi Folks,
> >
> > We'd like to have a separate fedora-messaging queue for our robosignatory 
> > installation in CentOS Stream:
> > https://pagure.io/fedora-infra/ansible/pull-request/772
> >
> > I hope this turns out to be low impact, and Mark was also looking at 
> > generating certificates for this.
> >
> > +1s from sysadmins or releng are greatly appreciated
>
> +1 here.

This can be merged.

-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

Re: Freeze Break Request: increase memory on s390x kvm builders

[Stephen John Smoogen]

On Fri, 27 Aug 2021 at 11:57, Kevin Fenzi  wrote:
>
> Not long ago we were given more memory and disk space for our s390x kvm
> lpar (logical partition). I have on my list to redo those builders and
> figure out the best number to have and what resources, etc...
> I still plan to do this after beta freeze.
>
> In the mean time some packagers are hitting out of memory conditions on
> those builders and the memory is there idle, so I'd like to just double
> all the memory on them.
>
> This would entail:
>
> * disable buildvm-s390x-15 to buildvm-s390x-24 in koji
> * wait for all ongoing jobs to finish, or just free them
> * take all those buildvm's down and double memory in their config
> * bring back up and re-enable in koji.
>
> Should be a quick and easy thing, will help packagers now and shouldn't
> break anything.
>
> Can I get +1s from sysadmin-main or releng folks?
>

+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://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



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

Re: Questions about the Fedora Release Life Cycle

[Stephen John Smoogen]

On Thu, 22 Jul 2021 at 10:48, Beatriz Michelson Reichert
 wrote:
>
> Hi, I'm Beatriz and I'm a student at the Santa Catarina State University.
>

Hi Beatriz and welcome to Fedora Infrastructure.


> Currently, I'm studying the Fedora Release Life Cycle, and would like to know 
> if anyone could help me with some questions about this subject:
>
> I understand that the services used to build composes (e.g., Koji, Bodhi, 
> Pungi) use TLS. But it was unclear whether these certificates are generated 
> internally or whether they are generated by a public CA (e.g., letsencrypt).
> Do clients use the trust anchors from the ca-certificates package or do they 
> have a list of their own?
>

When you say 'use TLS' what parts are you meaning? Most of the
connections go through dedicated proxies so are using the same
certificates you see at
https://koji.fedoraproject.org/koji/
https://kojipkgs.fedoraproject.org//work/

so would be using the Digicert certs. I am not sure about other places
in the infrastructure and how they interact. The release engineers and
security officer would know better.


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on  BBS...
time to reboot.
___
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

Re: DNS patch to rename ocp4 clusters, and revert vhmost-ocp changes

[Stephen John Smoogen]

On Thu, 15 Jul 2021 at 04:53, David Kirwan  wrote:
>
> The previous changes to those management hosts, were a name change so I think 
> we should probably leave those as they where so they are still accessible on 
> the management network. The hosts themselves are older hardware Kevin was 
> suggesting that we might throw out or retire soon.
>
> Think the idea is instead of using those, is to use the existing 
> vmhost-x86-05/06/07/11 staging as all free capacity/newer boxes.
>

OK as long as the hosts ping/respond on that network, they should have
ip addresses in DNS. Otherwise the following happens:
1. We try to use those ips for a new box and both systems go dead.
[That usually needs someone to go onto the hardware via a KVM and
fix.]
2. We get a scan/audit from RH and they want to know what hardware is
on that address and is it an attacker/etc.
3. The box gets turned off and then comes back on somehow. Then we may
have an ip conflict.

So until the hardware is physically removed from the racks.. keep its
mgmt ip in DNS. Maybe change the name to oldhost or retired .. but
keep it there until then.

> On Thu, 15 Jul 2021 at 09:22, Stephen John Smoogen  wrote:
>>
>> On Thu, 15 Jul 2021 at 04:18, David Kirwan  wrote:
>> >
>> > https://gist.github.com/davidkirwan/ecc1c135b6f2c82b1ef337ebdcd8414b
>> >
>> > Hi folks if someone would be so kind as to take a look over our changes 
>> > here, we want to revert some vhmost-ocp4 changes and rename the ocp hosts.
>> >
>> > Just two things to be aware:
>> >
>> > This is commented out line is intentional, as we wish to reuse the 
>> > bootstrap.ocp node to become the worker01.ocp node after the control plane 
>> > has been installed.
>> > +;worker01.ocp IN A 10.3.166.118
>> >
>> > Second question, we've removed the vmhost-ocp nodes from the 160. 
>> > management network, not sure if we should have done that.
>> >
>>
>> Where are the management ports for these boxes going to be? Is
>> 10.3.160.40 really unused?
>>
>>
>> > cheers,
>> > David
>> >
>> >
>> >
>> > --
>> > David Kirwan
>> > Software Engineer
>> >
>> > Community Platform Engineering @ Red Hat
>> >
>> > T: +(353) 86-8624108 IM: @dkirwan
>> >
>> > ___
>> > 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
>>
>>
>>
>> --
>> Stephen J Smoogen.
>> I've seen things you people wouldn't believe. Flame wars in
>> sci.astro.orion. I have seen SPAM filters overload because of Godwin's
>> Law. All those moments will be lost in time... like posts on  BBS...
>> time to reboot.
>> ___
>> 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
>
>
>
> --
> David Kirwan
> Software Engineer
>
> Community Platform Engineering @ Red Hat
>
> T: +(353) 86-8624108 IM: @dkirwan
>
> ___
> 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



-- 
Stephen J Smoogen.
I've seen things you people wouldn't 

Re: DNS patch to rename ocp4 clusters, and revert vhmost-ocp changes

[Stephen John Smoogen]

On Thu, 15 Jul 2021 at 04:18, David Kirwan  wrote:
>
> https://gist.github.com/davidkirwan/ecc1c135b6f2c82b1ef337ebdcd8414b
>
> Hi folks if someone would be so kind as to take a look over our changes here, 
> we want to revert some vhmost-ocp4 changes and rename the ocp hosts.
>
> Just two things to be aware:
>
> This is commented out line is intentional, as we wish to reuse the 
> bootstrap.ocp node to become the worker01.ocp node after the control plane 
> has been installed.
> +;worker01.ocp IN A 10.3.166.118
>
> Second question, we've removed the vmhost-ocp nodes from the 160. management 
> network, not sure if we should have done that.
>

Where are the management ports for these boxes going to be? Is
10.3.160.40 really unused?


> cheers,
> David
>
>
>
> --
> David Kirwan
> Software Engineer
>
> Community Platform Engineering @ Red Hat
>
> T: +(353) 86-8624108 IM: @dkirwan
>
> ___
> 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



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on  BBS...
time to reboot.
___
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

Re: RHEL8 for Copr builders

[Stephen John Smoogen]

On Fri, 28 May 2021 at 07:49, Miroslav Suchý  wrote:

> With the sunset of CentOS8 we want to allow builds on top real RHEL in
> Copr. Now that the RH Developer program is known,
> what are the option? Do we already use it somewhere? Or I will be the
> first to use it? :)
>
> I need it accessible from AWS so the repos we use in Koji are likely out
> of the question and I need to use real
> subscription.
>
>
The developer account is limited to 16 systems and is tied to an
individual. You are going to need more than that for COPR, and having it
tied to Frosty or you or Pavel means that they can never leave the group
:). [You know the mock internals much better than me ... but if you are
using the mock subscription method for the certs to get the items in AWS,
doesn't that mean that you would need to have those boxes be RHEL-8 and
their system key be used.]

For mass access like a project you will need to explore a different account
for a 'project' subscription. I think you work with Bex or others to get
that in place with the business units but I am not sure. Something like the
koji method might be possible but it would require a dedicated 'mirror'
host in AWS or other places which would mirror the packages and then allow
the clients to use them. [This is mainly to cut down the network transfer
fees in and out of AWS.] This would have a dedicated IP address to allow
for ip rules so that pulls could be allowed. Transient copr build guests
would just talk to that box.



> Miroslav
> ___
> 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
>


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law.
All those moments will be lost in time... like posts on  BBS... time to
reboot.
___
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

Re: status.fp.org concept

[Stephen John Smoogen]

On Mon, 3 May 2021 at 10:53, Vít Ondruch  wrote:

> I like it. Nevertheless, I'll be missing the current page, which lists the
> various services Fedora provides.
>
>
>
The reason we are changing is because of that list. Too many people expect
us to know instantly that something is broken, something like
https://uptimerobot.com/ that rocky linux uses. They also expect us to be
24x7x365 coverage of every service on that list when we are more of a 8
hour US-East M-F sysadmin.


> Vít
>
>
> Dne 30. 04. 21 v 14:23 Ryan Lerch napsal(a):
>
> Hi all,
>
> I have been working on this ticket for an updated version of
> status.fedoraproject.org.
>
> https://pagure.io/fedora-infrastructure/issue/9858
>
> I have come up with a proof of concept that fills all the requirements
> specified in the the ticket, and looking for feedback / thoughts on this
> new approach.
>
> The source of the POC is here:
>
> https://github.com/ryanlerch/status-playground/
>
> and a recent build version of what it looks like is here:
>
> https://ryanlerch.github.io/status-playground/
>
> cheers,
> ryanlerch
>
>
>
> ___
> 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
>
> ___
> 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
>


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law.
All those moments will be lost in time... like posts on  BBS...
___
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

Re: Host DOWN alert for vmhost-x86-copr01.rdu-cc.fedoraproject.org!

[Stephen John Smoogen]

On Mon, 26 Apr 2021 at 16:22, Pavel Raiskup  wrote:

> This is (probably) my fault.  I played a bit with ipv6 && libvirt, and I
> rebooted the machine, and it doesn't boot up now :-( sorry for the noise.
>
> If there's some console (VPN?) access that we could use to fix such
> problems
> within our (CPT) team?
>
>
There is currently no way to get to the consoles for these systems. That is
part of the bring up of that environment.


> Pavel
>
> On Monday, April 26, 2021 10:06:41 PM CEST Nagios Monitoring User wrote:
> > * Nagios  *
> >
> > Notification Type: PROBLEM
> > Host: vmhost-x86-copr01.rdu-cc.fedoraproject.org
> > State: DOWN
> > Address: vmhost-x86-copr01.rdu-cc.fedoraproject.org
> > Info: CHECK_NRPE STATE CRITICAL: Socket timeout after 30 seconds.
> > Source: noc01.iad2.fedoraproject.org
> >
> > Date/Time: Mon Apr 26 20:06:41 GMT 2021
> >
>
>
>
> ___
> 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
>


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FREEZE BREAK: Remove sysadmin-gnome to fix playbooks

[Stephen John Smoogen]

+1

On Wed, 21 Apr 2021 at 16:59, Nick Bebout  wrote:

> [nebebout@GLFW5M2 fedora-ansible]$ git diff HEAD^
> diff --git a/inventory/group_vars/batcave b/inventory/group_vars/batcave
> index 40c2b393a..5af3b70f7 100644
> --- a/inventory/group_vars/batcave
> +++ b/inventory/group_vars/batcave
> @@ -26,7 +26,6 @@ ipa_client_shell_groups:
>  - sysadmin-debuginfod
>  - sysadmin-fedimg
>  - sysadmin-fpdc
> -- sysadmin-gnome
>  - sysadmin-koschei
>  - sysadmin-libravatar
>  - sysadmin-mbs
> ___
> 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
>


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: About JS framework

[Stephen John Smoogen]

It is spam. I am blocking/removing

On Fri, 16 Apr 2021 at 09:44, Vipul Siddharth 
wrote:

> On Wed, Apr 14, 2021 at 6:15 PM Tom Jenner 
> wrote:
> >
> > Hi! Check out this article to find description of Angular and React:
> https://itechcraft.com/angular-vs-reactjs/ . It describes pros, cons and
> reasons to choose one or another framework. Hope it will help you!
>
> Someone please help me understand this thread, is this a low key spam? :)
> Sorry to misjudge if there is an actual need or reason behind this
>
> > ___
> > 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
>
>
>
> --
> Vipul Siddharth
> He/His/Him
> Fedora | CentOS CI Infrastructure Team
> ___
> 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
>


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: otp resets

[Stephen John Smoogen]

On Sat, 10 Apr 2021 at 02:46, Aurelien Bompard 
wrote:

>
> > > * If they are Red Hat employees we can use the internal verify thing
> >
> > Yes. Is there a way we could extend something similar to non-RHers?
>
> That would be interesting, how does it work? Can we replicate it in some
> way?
>
>
This internal verify only works if both people can login and send back and
forth a secret. It does not work if one party can not log in. The backup
method requires IT to have access to certain personal information from HR
which they can use to work out how trustworthy the person on the other side
is. This is cost prohibitive for us (in both time and wanting to store PII
safely).



> > > * We could use gpg signed email if there is a gpg key assigned to the
> > > account.
> > > * Could we use ssh key to verify them?
>
> Like asking them to edit a file on people.fp.o? But I suppose not
> everybody will have an ssh key either.
>
> A.
> ___
> 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
>


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Congrats to Nick Bebout

[Stephen John Smoogen]

Congratulations Nick.

On Mon, 5 Apr 2021 at 11:48, Kevin Fenzi  wrote:

> Greetings.
>
> I'm happy to announce that Nick Bebout(fas: nb, irc: nb)
> has been added to our sysadmin-main group.
>
> This is the core group of trusted folks that high level access to most
> everything in fedora infrastructure.
>
> Nick has been doing infrastructure tasks for various groups for many
> years in sysadmin-noc, sysadmin-web, and too many other groups to list.
>
> He's proved his dedication, trustworthiness, and ability.
>
> Congrats!
>
> Use your powers for good! :)
>
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Postgresql server in aws.f.o

[Stephen John Smoogen]

On Mon, 15 Mar 2021 at 12:00, Miroslav Suchý  wrote:

> Hi.
> In Copr we use postgresql on copr-frontend. I decide that it is time to
> split it off to separate server. I am going to
> create new machine in AWS and deploy postgresql there. I have several open
> questions:
>
>   * is there interest in having it as general sql server in AWS datacenter
> for some other fedora-infra projects? Or
> should I not bother about it and just keep it for Copr?
>
>
I would keep it just for COPR. I think we would prefer to have all our
databases be a single server for auditing, cleanup and downtime. Having
combined postgreses like db01/db03 have been nothing but a pain. We have no
DBA in our group so tuning and such for different needs is not something we
know how to do correctly versus caveman hack style.



>   * I plan to reuse roles/postgresql_server for that - any issue with this?
>
>   * if the server will be open for other Fedora project (first question)
> should I amend
> playbooks/groups/postgresql-server.yml or should I rather create new
> playbook?
>
>   * I would love to run the server on RHEL 8. That should be completely
> fine according to
>
> https://www.redhat.com/en/blog/extending-no-cost-red-hat-enterprise-linux-open-source-organizations
>do we have stored somewhere role or credentials which configure
> subscription-manager?
>
>
No we are not using this program. The various CentOS/Fedora/etc
organizations come under different legal parameters because we are not
'independent' of Red Hat.


>   * I plan to use arm64 for that server - mostly because I can and it can
> be fun :) (and it is a bit cheaper) -  any
> issue with this?
>
>
And another reason why it should be just for your server :).. you can run
what you want and need versus worry what anyone else wants.


> --
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager, Community Packaging Tools, #brno,
> #fedora-buildsys
> ___
> 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
>


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Infra technos

[Stephen John Smoogen]

On Tue, 9 Mar 2021 at 15:31, Patrick Vavrina  wrote:

> Thank you.
>
> Have I got the right permissions in Pagure?
>
>
>
The people in the fi-apprentice group should be able to when they log in.
Your account was in the list of people I could assign it to..


>
> Le 9 mars 2021 à 21:15, Stephen John Smoogen  a écrit :
>
> 
>
> OK I am assigning the ticket to you. I don't know what is causing this not
> to work.
>
> On Tue, 9 Mar 2021 at 14:46, Patrick Vavrina 
> wrote:
>
>> I haven’t “Take” after “None”.
>>
>>
>> Le 9 mars 2021 à 20:31, Stephen John Smoogen  a écrit :
>>
>> 
>>
>>
>> On Tue, 9 Mar 2021 at 14:20, Patrick Vavrina 
>> wrote:
>>
>>> Hi Stephen John,
>>>
>>> I need to assign myself to ticket to start working on it but I don’t see
>>> where I can do it.
>>>
>>> I am new to Pagure.
>>>
>>> Cheers,
>>> Patrick
>>>
>>>
>> When you log into pagure, you should see in the right hand column
>> something like
>>
>> *Assignee*
>> None — Take
>>
>> click on Take and it should assign it to you.
>>
>>
>>>
>>> Le 9 mars 2021 à 18:41, Stephen John Smoogen  a
>>> écrit :
>>>
>>> 
>>>
>>>
>>> On Tue, 9 Mar 2021 at 10:37, Patrick Vavrina 
>>> wrote:
>>>
>>>> Hi Kevin,
>>>>
>>>> Thanks a lot for your response.
>>>>
>>>> I’m interested in participating to package Ansible.
>>>>
>>>> As Fedora apprentice I saw that ticket concerns me:
>>>> https://pagure.io/fedora-infrastructure/issue/9693
>>>>
>>>> Could I fix it?
>>>>
>>>> Have a nice day!
>>>>
>>>>
>>> You should be able to assign the ticket to yourself. In any case I would
>>> say go ahead and start working on it. What do you need help with to start
>>> on this?
>>>
>>>
>>>
>>> --
>>> 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
>>> Do not reply to spam on the list, report it:
>>> https://pagure.io/fedora-infrastructure
>>> ___
>>> 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
>>>
>>
>>
>> --
>> 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
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>> ___
>> 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
>>
>
>
> --
> Stephen J Smoogen.
>
>

-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Infra technos

[Stephen John Smoogen]

On Tue, 9 Mar 2021 at 14:20, Patrick Vavrina  wrote:

> Hi Stephen John,
>
> I need to assign myself to ticket to start working on it but I don’t see
> where I can do it.
>
> I am new to Pagure.
>
> Cheers,
> Patrick
>
>
When you log into pagure, you should see in the right hand column something
like

*Assignee*
None — Take

click on Take and it should assign it to you.


>
> Le 9 mars 2021 à 18:41, Stephen John Smoogen  a écrit :
>
> 
>
>
> On Tue, 9 Mar 2021 at 10:37, Patrick Vavrina 
> wrote:
>
>> Hi Kevin,
>>
>> Thanks a lot for your response.
>>
>> I’m interested in participating to package Ansible.
>>
>> As Fedora apprentice I saw that ticket concerns me:
>> https://pagure.io/fedora-infrastructure/issue/9693
>>
>> Could I fix it?
>>
>> Have a nice day!
>>
>>
> You should be able to assign the ticket to yourself. In any case I would
> say go ahead and start working on it. What do you need help with to start
> on this?
>
>
>
> --
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> ___
> 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
>


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Infra technos

[Stephen John Smoogen]

On Tue, 9 Mar 2021 at 10:37, Patrick Vavrina  wrote:

> Hi Kevin,
>
> Thanks a lot for your response.
>
> I’m interested in participating to package Ansible.
>
> As Fedora apprentice I saw that ticket concerns me:
> https://pagure.io/fedora-infrastructure/issue/9693
>
> Could I fix it?
>
> Have a nice day!
>
>
You should be able to assign the ticket to yourself. In any case I would
say go ahead and start working on it. What do you need help with to start
on this?



-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ssh git access to src.fedoraproject.org feedback

[Stephen John Smoogen]

On Wed, 3 Mar 2021 at 17:13, Matthew Miller 
wrote:

> On Wed, Mar 03, 2021 at 01:53:28PM -0800, Kevin Fenzi wrote:
> > 4) We could add some kind of GSSAPI/Kerberos support to pagure, so
> > people could use https and a kerberos ticket.
>
> What's amount of effort required for this option? Because other than "it
> might be a lot of work", it seems ideal, and would resolve a lot of other
> cases where it's an extra step to have to configure an access token for
> pagure. But "it might be a lot of work" is a pretty big con.
>
> If the answer is "yeah, it's a lot", I vote for whichever other option
> makes
> this a logical next step when there is time to do such work.
>
>
>
The real question is 'can any of the choices be fully done in a very short
schedule with many of the people who could work on it are working on
meeting the first AAA deadline or F34 beta?' Basically it needs to do the
following:

0. Code needs to be written and tested in sandboxes.
1. It needs to be made to work in staging and tested by people. (1 week)
2. Does the same method need to be made to work with CentOS src staging if
so probably (1 week) [We are a combined auth system and git/pagure is used
in both for central work. Changes we make tend to roll out over both CentOS
and Fedora.]
3. It needs to be made ready to roll out in production (1 week)
4. It needs to be documented new workflow with posts and 'yes I know
yesterday you did this but today you are doing this' before a F34 release
5. Rolled out.
6. What is the fall back if production doesn't work?



-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: server updates

[Stephen John Smoogen]

On Mon, 15 Feb 2021 at 20:56, Kevin Fenzi  wrote:

> Greetings all. I thought I would let everyone know that I have applied
> updates all around on our servers, excepting a few:
>
> copr*
> retrace*
> os*
> notifs*
>
> I have also rebooted stg hosts.
>
> I am going to be doing some more (non outage causing) reboots this week
> as well.
>
> Please keep an eye out for any odd behavior or problems that might have
> been caused by updates.
>
>
At the moment we have found that koji and some other build services had
problems that needed a reboot to fix. httpd and other apps were segfaulting
even after a clean systemctl restart so I think glibc and other updates
changed the world too much 'ABI' wise somewhere deep down.




> After Beta is out, we can look at doing a normal update/reboot cycle.
>
> I just wanted to make sure we are mostly updated going into freeze.
>
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ancient backups of the moinmoin wiki?

[Stephen John Smoogen]

On Mon, 16 Nov 2020 at 12:58, Matthew Miller 
wrote:

> This is a long shot, I know. When we converted to MediaWiki from MoinMoin
> in
> 2008, pages were imported, but history was lost. I often like to go
> spelunking in the past, and it's often frustrating to hit this barrier.
>
> As I recall, MoinMoin stored everything in flat files, so it wouldn't even
> really need to be stood up again to get a look at the history. If someone
> happened to keep it, that is. Is there any chance we have a tarball
> snapshot
> of the wiki circa 2008?
>
>
You are probably going to have to ask Mike McGrath if he kept any copies..
that is before I got here and the tapes from that time are shredded. I will
see if I can find anything


-- 
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: best place to run an email-forwarding bot account?

[Stephen John Smoogen]

On Thu, 12 Nov 2020 at 18:13, Matthew Miller 
wrote:

> On Thu, Nov 12, 2020 at 02:56:10PM -0800, Kevin Fenzi wrote:
> > I'm not sure I like this from a security point of view... is there any
> > way we could use the discourse api and pull a digest from a script and
> > have it post to the list? (getting rid of the email in part)?
>
> I mean, probably? That suddenly escalates it to "much bigger project that
> I'm not sure is worth it".
>
> As for security -- it's no worse than we have now, right? I mean, email
> coming into lists is just secured by it claiming to be from a list member,
> right?
>
> (The email address the the bot user takes incoming messages at could be
> something entirely different from the address subscribed to the mailing
> list.)
>
>
>
I am not as much worried about the security around dealing with procmail
filtering (which in my experience has had problems.) I am more worried
about these emails having to go through the multiple layers of Red Hat
filtering we have to send email in and out of Fedora. Then dealing with all
the ways that these sorts of emails break various people's DMARC rules.

Then there is the fact that people are going to reply to the list and never
see any replies, get told to post it in discourse, get into an argument
that they shouldn't need to and why can't Fedora parse this stuff over. [I
say this from the other tools where we start on a "this sounds like a good
idea" and end up with a lot of make work to patch together two systems
which are actively hostile to each other.]  And finally, this is not going
to be a one-off. This is going to be a lot of lists over time and those
groups are going to want to go to various places and have similar levels of
whatever we put into this.

The council wants to move any lists to discourse.. then they should move
them to discourse and be done with it. Many of the people who don't want to
head over aren't going to be happy with any partial solution. If people
want to follow via email they can set up their own digests.



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


-- 
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: Planned Outage: 2020-11-11 21:00 UTC Fedora Services

[Stephen John Smoogen]

On Mon, 9 Nov 2020 at 17:31, Stephen John Smoogen  wrote:

>
> There will be an outage starting at 2020-11-11 21:00UTC,
> which will last approximately 6 hours.
>
> To convert UTC to your local time, take a look at
> http://fedoraproject.org/wiki/Infrastructure/UTCHowto
> or run:
>
> date -d '2017-05-03 21:00UTC'
>

date -d 2020-11-11 21:00UTC'

> Reason for outage:
>
> Apply updates and new kernels for all systems running RHEL7/RHEL8 and
> Fedora 32
>
> Affected Services:
>
> Most services in IAD2 will see downtime as we run updates and reboot
> systems.
>
> Ticket Link:
>


> https://pagure.io/fedora-infrastructure/issue/9440
>


> Please join #fedora-admin or #fedora-noc on irc.freenode.net
> or add comments to the ticket for this outage above.
>
> --
> Stephen J Smoogen.
>
>

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

Planned Outage: 2020-11-11 21:00 UTC Fedora Services

[Stephen John Smoogen]

There will be an outage starting at 2020-11-11 21:00UTC,
which will last approximately 6 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2017-05-03 21:00UTC'

Reason for outage:

Apply updates and new kernels for all systems running RHEL7/RHEL8 and
Fedora 32

Affected Services:

Most services in IAD2 will see downtime as we run updates and reboot
systems.

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/

Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.

-- 
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: Another Rust MirrorManager experiment

[Stephen John Smoogen]

On Tue, 6 Oct 2020 at 03:46, Adrian Reber  wrote:

> On Mon, Oct 05, 2020 at 08:30:12AM -0400, Stephen John Smoogen wrote:
> > On Mon, 5 Oct 2020 at 02:24, Adrian Reber  wrote:
> >
>
> > We are not wanting to deploy new EL7 systems but would probably install
> an
> > EL8 box for this. Does this change the need for moving to Fedora on it?
>
> I just asked on #fedora-rust, but it seems it is not easily possible to
> build the Fedora Rust packages for EL8. If I am understanding it
> correctly it seems we need to run the Rust based mirrorlist cache
> generation on a Fedora host. If we have a second mm-backend system
> (mm-backend02) that is Fedora based to generate the mirrorlist cache we
> could decrease the amount of RAM (32GB) on mm-backend01 to something
> like 8GB.
>
>
OK that makes sense. This will be something that needs upgrading every 6
months like our proxies, but it is what it is.



> Adrian
> ___
> 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: Another Rust MirrorManager experiment

[Stephen John Smoogen]

On Mon, 5 Oct 2020 at 02:24, Adrian Reber  wrote:

> On Wed, Jul 01, 2020 at 09:16:05AM -0700, Kevin Fenzi wrote:
> > On Tue, Jun 30, 2020 at 02:17:30PM +0200, Adrian Reber wrote:
> > > On Mon, Jun 15, 2020 at 03:36:23PM -0700, Kevin Fenzi wrote:
> > > > On Wed, Jun 10, 2020 at 11:09:49AM +0200, Adrian Reber wrote:
> > > > >
> > > > > Then I just have to wait a bit. No problem.
> > > > >
> > > > > > > Having the possibility to generate the mirrorlist input data
> in about a
> > > > > > > minute would significantly reduce the load on the database
> server and
> > > > > > > enable us to react much faster if broken protobuf data has
> been synced
> > > > > > > to the mirrorlist servers on the proxies.
> > > > > >
> > > > > > Yeah, and I wonder if it would let us revisit the entire
> sequence from
> > > > > > 'update push finished' to updated mirrorlist server.
> > > >
> > > > This would help us with the case of:
> > > > - updates push/rawhide finishes, master mirror is updated.
> > > > - openqa/other internal thing tries to get images or updates in that
> > > >   change and gets a metalink with the old checksum so it can't get
> the
> > > >   new stuff.
> > > > - mm-backend01 generates and pushes out a new protobuf.
> > > > >
> > > > > Probably. As the new code will not run on the current RHEL 7 based
> > > > > mm-backend01 would it make sense to run a short running service
> like
> > > > > this on Fedora's OpenShift? We could also create a new read-only
> (SELECT
> > > > > only) database account for this.
> > > >
> > > > We could, or as smooge suggests make a mm-backend02?
> > > >
> > > > But I guess now mm-backend02 just generates new proobuf files and
> copies
> > > > them to mirrorlists? If thats all it's doing, perhaps we could indeed
> > > > replace it with an openshift project.
> > >
> > > We need a system to run the tool and copy the data to all proxies.
> > >
> > > I would like to see a new MirrorManager database user who can only do
> > > selects as that is all we need.
> > >
> > > Currently we copy the files via SSH to the proxies, if we continue
> doing
> > > it that way, then we would also need the existing SSH key to copy the
> > > data to the proxies.
> > >
> > > Easiest would probably be a small Fedora 32 based VM with 2GB of
> memory.
> >
> > I'm not sure f32 will work with 2gb memory anymore. I dont think it
> > installs at any rate.
> >
> > I do like the idea of just making it an openshift pod. Perhaps this
> > could even fit with pingous 'toddlers' setup. ie:
>
> I tried to create a toddler, but that setup is too complicated for me.
> Especially if something is not working it will be almost impossible for
> me to debug it if it is running somewhere I cannot reach via SSH.
>
> I just tried to build the generate-mirrorlist-cache on RHEL 7 (using
> Rust from EPEL) and it works fine. Instead of 20 minutes it needs 30
> seconds to generate the mirrorlist cache file on mm-backend01.
>
> Although a RPM is available in Fedora I am not sure the RPM can be made
> available in EPEL 7.
>
> RPM Fusion is using the Rust based generate-mirrorlist-cache for some
> months already and I do not see any problems with it.
>
>
We are not wanting to deploy new EL7 systems but would probably install an
EL8 box for this. Does this change the need for moving to Fedora on it?



> I would like to use this also for Fedora and a dedicated Fedora based VM
> or building from source on RHEL 7 is both possible. Building from source
> does not sound like something used in Fedora Infrastructure so setting
> up a Fedora based VM would be necessary. Would that be possible?
>
> Adrian
> ___
> 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: FBR: put new proxies in action

[Stephen John Smoogen]

+1 after review.

On Mon, 28 Sep 2020 at 09:22, Mark O'Brien  wrote:

> Hi All,
>
> Attached is a DNS patch to put some new proxy servers in Europe, Asia
> Pacific and Africa. The servers are up and running and passing all nagios
> checks. This patch would start directing the regional traffic toward the
> servers
>
> Just a note, the do-domains script would also need to be run on this. I
> left it out so as not to clutter the patch.
>
>
> Any +1's or comments are appreciated.
>
> Thanks,
> Mark
>
> ___
> 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: FBR

[Stephen John Smoogen]

On Thu, 24 Sep 2020 at 10:24, Pierre-Yves Chibon 
wrote:

> On Thu, Sep 24, 2020 at 10:11:11AM -0400, Stephen John Smoogen wrote:
> > Need to fix opendkim on bastion
> >
> > I merged a fix in https://pagure.io/fedora-infrastructure/issue/9250 but
> > have not run the playbook for bastion to push this out yet. I would like
> to
> > get a +1 or -1 on this before doing that. [I can remove the merge also if
> > that is better.]
>
> Would you have a link to the commit(s) with the fix?
>
>
Durh

https://pagure.io/fedora-infra/ansible/pull-request/260


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


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

FBR

[Stephen John Smoogen]

Need to fix opendkim on bastion

I merged a fix in https://pagure.io/fedora-infrastructure/issue/9250 but
have not run the playbook for bastion to push this out yet. I would like to
get a +1 or -1 on this before doing that. [I can remove the merge also if
that is better.]

-- 
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: FBR: increase koji ram to 32 GB

[Stephen John Smoogen]

This has been done.

On Mon, 21 Sep 2020 at 16:02, Kevin Fenzi  wrote:

> On Mon, Sep 21, 2020 at 03:51:31PM -0400, Stephen John Smoogen wrote:
> > Currently koji01 and koji02 are using 16 GB and need 32 GB . Bump each
> > guest in ansible and via virsh commands.
>
> +1. we have tons of free memory there, should use it.
>
> 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: FBR: increase koji ram to 32 GB

[Stephen John Smoogen]

On Mon, 21 Sep 2020 at 15:51, Stephen John Smoogen  wrote:

>
> Currently koji01 and koji02 are using 16 GB and need 32 GB . Bump each
> guest in ansible and via virsh commands.
>
> --
> Stephen J Smoogen.
>
>
diff --git a/inventory/group_vars/koji b/inventory/group_vars/koji
index 91d7c1b3b..ec3d910b0 100644
--- a/inventory/group_vars/koji
+++ b/inventory/group_vars/koji
@@ -1,7 +1,7 @@
 ---
 # Define resources for this group of hosts here.
 lvm_size: 3
-mem_size: 16384
+mem_size: 32768
 num_cpus: 16



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

FBR: increase koji ram to 32 GB

[Stephen John Smoogen]

Currently koji01 and koji02 are using 16 GB and need 32 GB . Bump each
guest in ansible and via virsh commands.

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

FBR: Fix DKIM signing for aws and fedorahosted

[Stephen John Smoogen]

diff --git a/roles/opendkim/files/SigningTable
b/roles/opendkim/files/SigningTable
index 84cb8f78f..81cad91f3 100644
--- a/roles/opendkim/files/SigningTable
+++ b/roles/opendkim/files/SigningTable
@@ -15,6 +15,10 @@
 *@fedoraproject.org bastion-iad._domainkey.fedoraproject.org
 *@lists.fedoraproject.org bastion-iad._domainkey.fedoraproject.org
 *@stg.fedoraproject.org bastion-iad._domainkey.fedoraproject.org
+*@aws.fedoraproject.org bastion-iad._domainkey.fedoraproject.org
+*@fedorahosted.org bastion-iad._domainkey.fedoraproject.org
+*@lists.fedorahosted.org bastion-iad._domainkey.fedoraproject.org
+pag...@pkgs.fedoraproject.org bastion-iad._domainkey.fedoraproject.org
 pag...@pagure.io bastion._domainkey.pagure.io

 # NON-WILDCARD EXAMPLE


-- 
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: IPAM/DCIM for Fedora Infrastructure

[Stephen John Smoogen]

On Tue, 1 Sep 2020 at 02:36, Manu Hernandez 
wrote:

> Hi!
>
> I was going to suggest NetBox as well.
>
> NetBox is also a data center management infrastructure tool (DCIM) too,
> so it can be used to document racks, circuits, power, etc.
>
> https://netbox.readthedocs.io/en/stable/
>
>
This is a useful tool and one I could have used during the move.. However I
have a couple of concerns.

One issue is that we would only be able to use it as a reactive tool. We do
not control the physical layout, the network, the power and other items for
any of our 'clusters' of systems. For most of our systems in different
datacenters I have never seen where they are, how they are laid out, etc.
Instead I need to rely on different tools at each site to keep that data in
place (and for several places that can change regularly).

Secondly I don't know how useful this data would be to apprentices if it
was kept up to date. The more data in it, the more we would need to lock it
down because it would contain non-disclosure data (various sites who lend
us systems have different rules for what information they consider
public/private.. what limited we have in ansible is generally what is
considered what we could share.) Other things like serial numbers of
systems are considered sensitive because they can be used to defraud our
warranty. [Having had parts ordered for a system we had under warranty to a
third party for resale is not something I want to deal with again.]

Neither of these concerns are end-of-the-world but they need to be dealt
with in any plan to install this service somewhere and then populate it
with data.


> If we use this tool as a "source of truth" (desired state vs operational
> state), the change flow should be:
>
> 1. Update the NetBox data to reflect the change
> 2. Change the Ansible code to make it so
>
> When reviewing the Ansible code (roles/playbooks), if a discrepancy
> between the Ansible tasks and the NetBox data is found, NetBox should be
> used as the correct one (because it's the intended config.) and the
> Ansible tasks corrected.
>
> A tool like this will help, not only experienced members, but new
> candidates like me, giving us a lot of structured information about the
> Fedora infra.
>
> Do we have something like NetBox running at the moment? If that's not
> the case, please, consider adding it.
>
> Thanks for packaging it, ignatenkobrain!
>
> Regards,
>
> Manu
> ___
> 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

Freeze Break Request (Fix 2factor on builders)

[Stephen John Smoogen]

Currently the builders are trying to contact os-node boxes on port 8443 but
that is not where fas-all lives.

diff --git a/roles/base/templates/iptables/iptables.kojibuilder
b/roles/base/templates/iptables/iptables.kojibuilder
index a3819777c..805cf735f 100644
--- a/roles/base/templates/iptables/iptables.kojibuilder
+++ b/roles/base/templates/iptables/iptables.kojibuilder
@@ -78,10 +78,12 @@
 -A OUTPUT -p tcp -m tcp -d 10.3.163.76 --dport 443 -j ACCEPT
 -A OUTPUT -p tcp -m tcp -d 10.3.163.77 --dport 80 -j ACCEPT
 -A OUTPUT -p tcp -m tcp -d 10.3.163.77 --dport 443 -j ACCEPT
-# for 2 facter auth
--A OUTPUT -p tcp -m tcp -d 10.3.163.69 --dport 8443 -j ACCEPT
--A OUTPUT -p tcp -m tcp -d 10.3.163.70 --dport 8443 -j ACCEPT
--A OUTPUT -p tcp -m tcp -d 10.3.163.71 --dport 8443 -j ACCEPT
+# for 2 facter auth (fas-all)
+-A OUTPUT -p tcp -m tcp -d 10.3.163.74 --dport 8443 -j ACCEPT
+-A OUTPUT -p tcp -m tcp -d 10.3.163.75 --dport 8443 -j ACCEPT
+-A OUTPUT -p tcp -m tcp -d 10.3.163.76 --dport 8443 -j ACCEPT
+-A OUTPUT -p tcp -m tcp -d 10.3.163.77 --dport 8443 -j ACCEPT
+

 #nfs to vtap-fedora-nfs01.storage.phx2.redhat.com - a little to wide-open
- but
 # kinda necessary


-- 
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: Freeze Break Request: koji update for all builders

[Stephen John Smoogen]

+1

On Thu, 27 Aug 2020 at 16:40, Mohan Boddu  wrote:

> On Thu, Aug 27, 2020 at 2:36 PM kevin  wrote:
> >
> > The koji 1.22.0 update added handling for the '--extra-boot-args'
> > kickstart option. UNfortunately, this support wasn't working right and
> > causes all our images specifying such options to fail.
> >
> > The good news is that the fix is just a one-liner:
> >
> > -cmd.extend(['--extra-boot-args',
> > -'--append=\"%s\"' % b_append])
> > +cmd.extend(['--extra-boot-args', '\"%s\"' % b_append])
>
> LGTM +1
>
> >
> > I've built a new rpm with this patch applied and would like to do a
> > freeze break to apply it to the 'builders' ansible group.
> > (This applies to kojid).
> >
> > See:
> > https://pagure.io/koji/pull-request/2452
> > https://pagure.io/fedora-infrastructure/issue/9271
> >
> > +1s?
> >
> > 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
> ___
> 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: Hosting Options for QA Projects

[Stephen John Smoogen]

On Mon, 17 Aug 2020 at 13:17, Frantisek Zatloukal  wrote:
>
>
>
> On Mon, Aug 17, 2020 at 4:36 PM Pierre-Yves Chibon  
> wrote:
>>
>> What about email addresses? I figure they are needed for the bugzilla
>> integration, no?
>
>
> No, we don't store/need any email addresses. We store the package list for 
> username and then ask bugzilla for bugs per package.
>
>>
>>
>>
>> (which raises a question: how do you handle the bugzilla email overrides we
>> currently have in place? ie: people who do not use the same email address in 
>> FAS
>> and in bugzilla, for example to be able to use their @fedoraproject.org 
>> alias in
>> bugzilla).
>
>
> We get package list from this json and pair it with FAS usernames: 
> https://src.fedoraproject.org/extras/pagure_owner_alias.json (+group packages 
> from pagure api endpoint which is also username based).
>
> So we technically don't care about emails at all.

I think we need to be clearer than 'email address'. We need to know if
the app connects a 'user' with a 'data'. If it does then it probably
falls under something we need to track to either delete regularly,
alert them when that system gets hacked, etc etc etc.




-- 
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: s390x for EPEL

[Stephen John Smoogen]

On Wed, 29 Jul 2020 at 08:03, Pavel Raiskup  wrote:
>
> On Tuesday, July 28, 2020 3:17:56 PM CEST Stephen John Smoogen wrote:
> > On Mon, 27 Jul 2020 at 15:46, Kevin Fenzi  wrote:
> > >
> > > On Mon, Jul 27, 2020 at 04:45:58PM +0200, Miroslav Suchý wrote:
> > > > What is using Koji to build EPEL builds for s390x.
> > >
> > > We are using 2 LPARS on a z13 mainframe in a Red Hat lab in Westford, MA.
> > >
> > > > We want to enable s390x in Copr. It is without problem for Fedora, but 
> > > > we cannot do that for EPEL, because there is no
> > >
> > > Can you explain how you plan to do Fedora s390x builds? Emulation?
> > >
> > > > CentOS for s390x. Do we have entitlements for RHEL I can use? Or we 
> > > > have some local repo? Something completely different?
> > >
> > > We have local repo synced from RHN with our Fedora Org.
> > >
> > > I don't think we can give external access to that repo.
> > >
> > > It might also be weird to have just one arch of something be against
> > > RHEL instead of Centos. Is there no Centos port in progress?
> > >
> >
> > CentOS does not have access to an s390 to do a port.
>
> You mean no access to IBM _hardware_, right?
>

My understanding is limited to what CentOS has access to and probably
wrong. Yes you could try building it all through emulation.. I do not
know how well it would work.
-- 
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: s390x for EPEL

[Stephen John Smoogen]

On Mon, 27 Jul 2020 at 15:46, Kevin Fenzi  wrote:
>
> On Mon, Jul 27, 2020 at 04:45:58PM +0200, Miroslav Suchý wrote:
> > What is using Koji to build EPEL builds for s390x.
>
> We are using 2 LPARS on a z13 mainframe in a Red Hat lab in Westford, MA.
>
> > We want to enable s390x in Copr. It is without problem for Fedora, but we 
> > cannot do that for EPEL, because there is no
>
> Can you explain how you plan to do Fedora s390x builds? Emulation?
>
> > CentOS for s390x. Do we have entitlements for RHEL I can use? Or we have 
> > some local repo? Something completely different?
>
> We have local repo synced from RHN with our Fedora Org.
>
> I don't think we can give external access to that repo.
>
> It might also be weird to have just one arch of something be against
> RHEL instead of Centos. Is there no Centos port in progress?
>

CentOS does not have access to an s390 to do a port.


> 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: s390x for EPEL

[Stephen John Smoogen]

On Mon, 27 Jul 2020 at 10:46, Miroslav Suchý  wrote:
>
> What is using Koji to build EPEL builds for s390x.
>

EPEL uses RHEL for all its builds. The problem is that the license we
have for RHEL is meant just for this and we have not been able to
extend it to COPR in the past. The issues are legal, accounting and a
couple of other ones. Can you use CleFOS for s390x?


> We want to enable s390x in Copr. It is without problem for Fedora, but we 
> cannot do that for EPEL, because there is no
> CentOS for s390x. Do we have entitlements for RHEL I can use? Or we have some 
> local repo? Something completely different?
> --
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
> ___
> 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: What is our technical debt?

[Stephen John Smoogen]

On Tue, 7 Jul 2020 at 08:51, Eduard Lucena  wrote:
>
> Maybe I'm far out, but it's interesting to me that nobody had said 
> ELK+Kibana+Logtash for monitoring. AFAIK there are ready to use containers 
> with it, the configuration it's easy to do and the work needs to be done 
> entirely for the dashboards you want to monitor.
>
> Sorry if the suggestion is silly.
>
It isn't silly.. it is just a lot more complicated than people realize.

The front end set up is easy.. tuning it to be what you want and
setting up the backend is not easy. There is a reason why data
analysts for ELK are fulltime jobs and the backend usually requires a
multitude of servers. A lot of the setups are built around where the
data is already in the cloud so you spin up more elastic backends to
spread out the load, but our data is in a centralized area. Shipping
our data into Amazon/MS/etc cloud is a legal blackhole due to GDPR and
other regulations.


> Br,
> x3mboy
> ___
> 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: What is our technical debt? (fedora integration service)

[Stephen John Smoogen]

On Tue, 7 Jul 2020 at 05:23, Pavel Raiskup  wrote:
>
> Hi all,
>
> as a Copr contributor, I am missing a _standard_ design for integrating
> our cool infrastructure into the _upstream_ work-flows.  We have a lot of
> teams trying to implement the same thing:
>

I think we need to work out what technical debt means. When I think of
technical debt, I am thinking of:

1. All our infrastructure relies on PDC which has a dead upstream, no
working replacement and more stuff needing to work from it.
2. Our mailing lists run on a beta of mailman3 and the current tools
are not packaged completely
3. mailman3 vm has possible disk issues
4. We have other servers we found we could not install to newer
versions but have to run on dead OS versions
5. Our account system, FAS2 runs on RHEL-6 (but is happier on RHEL5)
6. Our openshift is running on an older version but the newer version
needs a lot of planning of what hardware is going where.
7. ... etc etc etc

I expect there are other items of technical debt but a lot of these
take up most of my 50 to 60 hour weeks so it is what I think of versus
new workflows or other items.


-- 
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: What is our technical debt?

[Stephen John Smoogen]

On Wed, 1 Jul 2020 at 14:46, Miroslav Suchý  wrote:
>
> Dne 30. 06. 20 v 9:44 Pierre-Yves Chibon napsal(a):
> > What are you talking about here? The Fedora release process? The 
> > mass-branching
> > in dist-git?
>
> This. And creating new gpg keys, new mock configs, new tags in Koji, add 
> release to retrace.f.o, Copr, ... I have a
> dream where you just bump up number in - let say - PDC and everything else 
> will happen automagically. At right time.
>

I think choosing the one tool which is so end of life to do it in.. is
a sign of why we can't do this. Every release some set of tools in
Fedora get added by some team who have been working on their own
schedules and their own API without any idea of any other teams
working on. We then have to do a lot of integration and make it work
before the release deadline to make it work. Then usually after 1 or 2
releases that software team is no longer in existence and we have to
continue with it waiting for the promised replacement which will do
all those things you list above.. but instead get some other tool
which has to be shoved in.

Every attempt to stop this has been given great 'that sounds great,
but you have to  wait until we land OUR important tool which won't
actually meet any of those needs but has to be in place.' I think for
this to actually work, we need to redesign our entire application flow
and product lines.. which 20 years of Stockholm syndrome makes it hard
for me to see ever happening.

> --
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
> ___
> 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: What is our technical debt?

[Stephen John Smoogen]

On Fri, 26 Jun 2020 at 07:51, Stephen John Smoogen  wrote:
>
> On Thu, 25 Jun 2020 at 15:27, Pierre-Yves Chibon  wrote:
> >
> > Good Morning Everyone,
> >
> > Just like every team we have technical debt in our work.
> > I would like your help to try to define what it is for us.
> >
> > So far, I've come up with the following:
> > - python3 support/migration
> > - fedora-messaging
> > - fedora-messaging schema
> > - documentation
> > - (unit-)tests
> > - OpenID Connect
> >
> > What else would we want in there?
> >
>
> 1. mailman3. currently running in a broken vm which was transported from PHX2.
> 2. OpenShift is currently running in openshift 3 and may need to move
> to OS4 (I do not know eol for OS3)
> 3. PDC is EOL software with a replacement needing to be dealt with
> 4. Our website setup and running is a multi hour ansible run mess
> 5. Our docs on website setup is a multi-hour mess
> 6. We have NO working monitoring. It is going to take me a week to get
> it working and several months to replace it with something else
> 7. Any other vm's we shifted over from PHX2 to IAD2 versus rebuild
> from scratch should be considered unmaintained debt
> 8. Our staging needs to be designed from scratch and put in place with
> a rollout plan to replicate it in prod
> 9. OpenQA that Adam needs some specing out and work on it. It
> currently requires running on a 10.0.0.0/16 network.. The problem is
> that those IPs are also our running networks. This is causing leaks
> which are causing problems with our switch and routers.
> 10. Our deployment infrastructure of kickstarts/pxe/tftp falls under
> technical debt. It is based off of what we have been doing for 10+
> years and it has broken a lot in this transition. When it works its
> fine, and when it doesn't nothing works.

11. monitoring... which should have been higher. Our monitoring is
currently very broken. It is a set of jinja nagios templates I wrote
while trying to do 2 other things and not knowing jinja very well.
Updating it to work with nagios and our current infrastructure is
going to be a big job.. moving to a different monitoring.. is going to
be a big job. Having it not just be me who knows how it 'works'
(insert insane laughter) would be a great idea.

-- 
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: What is our technical debt?

[Stephen John Smoogen]

On Sat, 27 Jun 2020 at 08:05, Peter Robinson  wrote:
>
> > > 10. Our deployment infrastructure of kickstarts/pxe/tftp falls under
> > > technical debt. It is based off of what we have been doing for 10+
> > > years and it has broken a lot in this transition. When it works its
> > > fine, and when it doesn't nothing works.
> >
> > I'm not sure any more 'modern' thing here would be much better on the
> > hardware level. For vm's, yeah, there's some annoyances with
> > virt-installs which we should either track down and fix, or just go to
> > the 'use a cloud image and adjust it' mode.
>
> HTTP Boot would be the "new" replacement for PXE/tftp in this context.
> Most modern HW should support it, whether it supports HTTPS is less
> sure, in the IoT gateway space we've had some rather dubious options,
> but HTTP worked. Over all it's more secure and more straightforward
> for firewalls etc as HTTP(S) is generally allowed.
>

The only thing I have found which supports it in our modern HW is our
Power systems which do it via petitboot. Everything else (even stuff
bought 3 months ago) has needed to get enough over pxe/tftp so that it
could do the http after. It may need some finagling somewhere in the
systems but it is buried or not clearly labeled in the Lenovo EMAGs or
Dell boxes. I spent a couple of hours trying to find it on these and
ended up going with what I knew worked. If someone can help me on this
I would appreciate it.

> From a VM PoV it should "just work" for VMs that use tianocore/UEFI on
> x86, not sure what the default is for the infra VMs, but I would
> suggest that any VMs that currently use the old "BIOS" firmware be
> moved over to UEFI as they're rebuilt as in the general industry UEFI
> is now the default, some cloud providers aside, and it's certainly the
> case for x86/aarch64 HW.
>
> Not sure what the status is for Power/Z-series in this context.
>
> Also does the new DC support IPv6 for external services now?
>

It does, but our services do not so they would sometimes talk back
over ipv6 and sometimes over ipv4 to the same system and things
wouldn't work. We turned it off until we could get our basic
infrastructure in place so we were not debugging yet another thing
that was not working. We expect to turn it back on in August.


> Peter
> ___
> 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: What is our technical debt?

[Stephen John Smoogen]

On Thu, 25 Jun 2020 at 15:27, Pierre-Yves Chibon  wrote:
>
> Good Morning Everyone,
>
> Just like every team we have technical debt in our work.
> I would like your help to try to define what it is for us.
>
> So far, I've come up with the following:
> - python3 support/migration
> - fedora-messaging
> - fedora-messaging schema
> - documentation
> - (unit-)tests
> - OpenID Connect
>
> What else would we want in there?
>

1. mailman3. currently running in a broken vm which was transported from PHX2.
2. OpenShift is currently running in openshift 3 and may need to move
to OS4 (I do not know eol for OS3)
3. PDC is EOL software with a replacement needing to be dealt with
4. Our website setup and running is a multi hour ansible run mess
5. Our docs on website setup is a multi-hour mess
6. We have NO working monitoring. It is going to take me a week to get
it working and several months to replace it with something else
7. Any other vm's we shifted over from PHX2 to IAD2 versus rebuild
from scratch should be considered unmaintained debt
8. Our staging needs to be designed from scratch and put in place with
a rollout plan to replicate it in prod
9. OpenQA that Adam needs some specing out and work on it. It
currently requires running on a 10.0.0.0/16 network.. The problem is
that those IPs are also our running networks. This is causing leaks
which are causing problems with our switch and routers.
10. Our deployment infrastructure of kickstarts/pxe/tftp falls under
technical debt. It is based off of what we have been doing for 10+
years and it has broken a lot in this transition. When it works its
fine, and when it doesn't nothing works.




>
> Looking forward to your thoughts,
> 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



-- 
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: Another Rust MirrorManager experiment

[Stephen John Smoogen]

On Wed, 10 Jun 2020 at 05:10, Adrian Reber  wrote:

> On Thu, Jun 04, 2020 at 07:02:41PM -0700, Kevin Fenzi wrote:
> > On Mon, Jun 01, 2020 at 04:18:35PM +0200, Adrian Reber wrote:
> > > Our MirrorManager setup exports the current state of all mirrors every
> > > hour at :30 to a protobuf based file which is then used by the
> > > mirrorlist servers to answer the requests from yum and dnf.
> > >
> > > The Python script requires up to 10GB of memory and takes between 35
> and
> > > 50 minutes. The script does a lot of SQL queries and also some really
> > > big SQL queries joining up to 6 large MirrorManager tables.
> > >
> > > I have rewritten this Python script in Rust and now it only needs
> around
> > > 1 minute instead of 35 to 50 minutes and only 600MB instead of 10GB.
> >
> > Wow. nice!
> >
> > > I think the biggest difference is that I am almost not doing any joins
> > > in my SQL request. I download all the tables once and then I do a lot
> of
> > > loops over the downloaded tables and this seems to be massively faster.
> > >
> > > As the mirrorlist-server in Rust has proven to be extremely stable over
> > > the last months we have been using it I would also like to replace the
> > > mirrorlist protbuf input generation with my new Rust based code.
> > >
> > > I am planing to try out the new protobuf file in staging in the next
> > > days and would then try to get my new protobuf generation program into
> > > Fedora. Once it is packaged I would discuss here how and if we want to
> > > deploy in Fedora's infrastructure.
> >
> > Cool. You will need to hurry as staging goes off on monday, and back in
> > a few weeks. :)
>
> Then I just have to wait a bit. No problem.
>
> > > Having the possibility to generate the mirrorlist input data in about a
> > > minute would significantly reduce the load on the database server and
> > > enable us to react much faster if broken protobuf data has been synced
> > > to the mirrorlist servers on the proxies.
> >
> > Yeah, and I wonder if it would let us revisit the entire sequence from
> > 'update push finished' to updated mirrorlist server.
>
> Probably. As the new code will not run on the current RHEL 7 based
> mm-backend01 would it make sense to run a short running service like
> this on Fedora's OpenShift? We could also create a new read-only (SELECT
> only) database account for this.
>
>
We can do that or we can make a mm-backend02 which is el8 for this


-- 
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: RFC: How to deal with account creation

[Stephen John Smoogen]

On Fri, 15 May 2020 at 08:34, Patrick Uiterwijk 
wrote:

> On Fri, May 15, 2020 at 1:58 PM Stephen John Smoogen 
> wrote:
> >
> >
> > Currently I am dealing with 1-3 failed account creations a day due to
> our spam checking tool, basset.
> >
> > Basset is the tool which sits in the account system creation path and
> tries to check to see if an account is semi-valid or not. This was written
> by Patrick Uiterwijk about 4 to 5 years ago to deal with a large increase
> of spam accounts from a group who were paying people to get past other spam
> tools versus using scripts. We came up with various heuristics and tools to
> make for a general 'oh you are using a one-time-email system.. no account
> for you' and other checks.
> >
> > However it is almost a full time job to keep up with all the various
> spam groups methods for creating fake accounts for whatever they want. I
> haven't put much time into since 2018 and the heuristics that basset is
> using to judge whether a person has a valid account or not are way out of
> date. The spam groups have also gotten more sophisticated in creating
> accounts so we are more likely to allow a spammer in than a 'ham'-mer.
> >
> > I am not sure what to do.. I do not know how hard it would be to pull
> basset out of the system and I do not have the time to update/fix/improve
> Patrick's code on this. So I figured it would be good to get some feedback
> on this.
>
> Disabling it is very simple.
> Just remove all the config lines at
>
> https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/fas_server/templates/fas.cfg.j2#n135
> .
>
> An alternative could be to just increase the required spam-score from
> Basset to *very* high numbers (in the thousands), so it never sees
> someone as spam.
> That last one would mean it also doesn't need changes in the other
> apps that might be integrated with it, and it would still get all the
> useful info.
>

That is probably the better plan. The tool has been very useful.. it is
just needing someone to do the tuning work  or to expand it to do that
learning itself. I do not have that time, and I would prefer that people
knew that versus expecting to improve by itself.

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

RFC: How to deal with account creation

[Stephen John Smoogen]

Currently I am dealing with 1-3 failed account creations a day due to our
spam checking tool, basset.

Basset is the tool which sits in the account system creation path and tries
to check to see if an account is semi-valid or not. This was written by
Patrick Uiterwijk about 4 to 5 years ago to deal with a large increase of
spam accounts from a group who were paying people to get past other spam
tools versus using scripts. We came up with various heuristics and tools to
make for a general 'oh you are using a one-time-email system.. no account
for you' and other checks.

However it is almost a full time job to keep up with all the various spam
groups methods for creating fake accounts for whatever they want. I haven't
put much time into since 2018 and the heuristics that basset is using to
judge whether a person has a valid account or not are way out of date. The
spam groups have also gotten more sophisticated in creating accounts so we
are more likely to allow a spammer in than a 'ham'-mer.

I am not sure what to do.. I do not know how hard it would be to pull
basset out of the system and I do not have the time to update/fix/improve
Patrick's code on this. So I figured it would be good to get some feedback
on this.

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

Meeting Agenda for 2020-04-30 1500 UTC

[Stephen John Smoogen]

## Preamble
The infrastructure team will be having its weekly meeting tomorrow,
2020-04-30 at 15:00 UTC in #fedora-meeting-1 on the freenode network.
We have a document at https://board.net/p/fedora-infra
Please try and review and edit that document before the meeting and we
will use it to have our agenda of things to discuss. A copy as of today
is included in this email.

If you have something to discuss, add the topic to the discussion area
with your name. If you would like to teach other folks about some
application or setup in our infrastructure, please add that topic and
your name to the learn about section.

## Introduction
We will use it over the week before the meeting to gather status and
info and discussion items and so forth, then use it in the irc meeting
to transfer information to the meetbot logs.

### Meeting start stuff
```
#startmeeting Infrastructure (2020-04-30)
#meetingname infrastructure
#chair nirik pingou smooge cverna mizdebsk mkonecny abompard
#info Agenda is at: https://board.net/p/fedora-infra
#info About our team: https://docs.fedoraproject.org/en-US/cpe/
#topic aloha
```

### Let new people say hello
```
#topic New folks introductions
#info This is a place where people who are interested in Fedora
Infrastructure can introduce themselves
#info Getting Started Guide:
https://fedoraproject.org/wiki/Infrastructure/GettingStarted
```

### Determine who the next chair is
#topic Next chair
#info magic eight ball says:
#info 2020-04-30 - smooge
#info 2020-05-07 - cverna
#info 2020-05-14 - siddharthvipul
#info 2020-05-21 - ???

### Status / Information / Trivia / Announcements

(We put things here we want others on the team to know, but don't need
to discuss)
(Please use ```#info (the thing - your name)```

```
#topic announcements and information
#info CPE Sustaining EU-hours team has standups on Tuesday and
Thursday at 1400 UTC in #fedora-admin - please join
#info CPE Sustaining NA-hours team has a Monday through Friday 30
minute meeting going through tickets at 1800 UTC in #fedora-admin
#info Fedora Infrastructure will be moving in 2020-06 from its Phoenix
Az datacenter to one near Herndon Va. A lot of planning will be
involved on this. Please watch out for announcements on changes.
#info Fedora Communishift move has started but will take longer than
expected. Current estimate for bringing back into production is TBD
#info F32 final freeze is in effect!
#info Taskotron will EOL in 2020-05
```

### Things we should discuss

We use this section to bring up discussion topics. Things we want to talk about
as a group and come up with some consensus /suor decision or just brainstorm a
problem or issue. If there are none of these we skip this section.
(Use ```#topic your discussion topic - your username)```
```

#topic Oncall
#info https://fedoraproject.org/wiki/Infrastructure/Oncall

#info siddharthvipul is oncall 2020-04-16 -> 2020-04-23
#info cverna is oncall 2020-04-23-> 2020-04-30
#info siddharthvipul is oncall 2020-04-30 -> 2020-05-07
#info  ??? is oncall 2020-05-07 -> 2020-05-14
#info ??? is oncall 2020-05-14 -> 2020-05-21

## .oncalltakeeu .oncalltakeus

#info Summary of last week: (from current oncall )
#info

#topic Monitoring discussion [nirik]
#info https://nagios.fedoraproject.org/nagios
#info Go over existing out items and fix


### Put all topics for discussion under here

Here we will discuss any apprentice questions, try and match up people looking
for things to do with things to do, progress, testing anything like that.

### Learn about some application or setup in infrastructure

(This section, each week we get 1 person to talk about an application
or setup that we have. Just going over what it is, how to contribute,
ideas for improvement, etc. Whoever would like to do this, just add
the i/nfo in this section. In the event we don't find someone to teach
about something, we skip this section and just move on to open floor.)
```
#info
```
### Meeting end stuff
```
#topic Open Floor

#endmeeting
```

-- 
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: FBR: Fix DNS to match closer zones

[Stephen John Smoogen]

On Sun, 26 Apr 2020 at 14:40, Kevin Fenzi  wrote:

> On Sun, Apr 26, 2020 at 11:33:45AM -0400, Stephen John Smoogen wrote:
> > Currently several countries are getting routed to proxies which are
> timing
> > out for them. This should 'fix' some though I expect we will need to
> break
> > this out further per continental region.
>
> Is there somewhere you are getting these values?
>
> It seems fine enough to me, but also potentially disruptive... but I
> guess we can back it out soon if it causes problems.
>
>
So it looks like the original list was made from
https://github.com/lukes/ISO-3166-Countries-with-Regional-Codes which put
most of the Middle East in Asia. I compared it to
https://gist.github.com/richjenks/15b75f1960bc3321e295 which listed things
a little closer to major regional networks. I then grepped, sorted from the
first list Western Asia and looked to see if they were EMEA in the second
list.



> So, +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://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

FBR: Fix DNS to match closer zones

[Stephen John Smoogen]

Currently several countries are getting routed to proxies which are timing
out for them. This should 'fix' some though I expect we will need to break
this out further per continental region.

diff --git a/roles/dns/files/named.conf b/roles/dns/files/named.conf
index c8b95b9..135ec69 100644
--- a/roles/dns/files/named.conf
+++ b/roles/dns/files/named.conf
@@ -610,7 +610,7 @@ view "RDU2" {

 // The zones
 view "NA" {
-match-clients { US; CA; MX; };
+match-clients { US; CA; MX; BM; GL; };
 recursion no;
 // no rate-limit on internal requests
 rate-limit {
@@ -636,9 +636,10 @@ view "NA" {
 };


-// This is not "EU" countries, I just wanted a short way to represent
Europe.
+// This should have been EME and during the next freeze break should be
made as such.
 view "EU" {
-match-clients { AT; BE; BG; CY; CZ; DE; DK; EE; ES; FI; FR; GR;
HU; IT; LT; LU; LV; MT; NL; PL; PT; RO; RU; SE; UA; GB; IE; IS; NO; };
+   match-clients { AD; AL; AT; AX; BA; BE; BG; CH; CZ; DE; DK; EE; ES;
FI; FO; FR; GB; GG; GI; GR; HR; HU; IE; IM; IS; IT; JE; LI; LT; LU; LV; MC;
ME; MK; MT; NL; NO; PL; PT; RO; RS; RU; SE; SI; SJ; SK; SM; UA; VA; AE; AM;
AZ; BH; CY; GE; IL; IQ; JO; KW; LB; OM; QA; SA; TR; YE; };
+
 recursion no;
 zone "fedoraproject.org" {
 type master;
@@ -660,7 +661,7 @@ view "EU" {
 };

 view "APAC" {
-match-clients { AE; AF; AM; AU; AZ; BD; BH; BN; BT; CC; CN; CX;
CY; GE; HK; ID; IL; IN; IO; IQ; IR; JO; JP; KG; KH; KP; KR; KW; KZ; LA; LB;
LK; MM; MN; MO; MV; MY; NP; NZ; OM; PH; PK; PS; QA; RU; SA; SG; SY; TH; TJ;
TL; TM; TR; TW; UZ; VN; YE; };
+match-clients { AF; BD; BN; BT; CN; HK; ID; IN; JP; KG; KH; KZ;
LA; LK; MM; MN; MO; MV; MY; NP; PH; PK; SG; TH; TJ; TL; TM; UZ; VN; AS; AU;
CC; CK; CX; FJ; FM; GU; HM; KI; MH; MP; NC; NF; NR; NU; NZ; PF; PG; PN; PW;
SB; TK; TO; TV; UM; VU; WF; WS; }
 recursion no;
 zone "fedoraproject.org" {
 type master;


-- 
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: FBR: reboot ppc9-02

[Stephen John Smoogen]

+!

On Fri, 24 Apr 2020 at 18:24, Kevin Fenzi  wrote:

> ppc9-02 is in a odd state. Guests are running ok, but the host itself is
> hanging any ansible runs against it. :( Usually this is a sign of some
> stuck hardware.
>
> I've disabled the builders on it and once builds finish on them I would
> like to update and reboot ppc9-02. Due to existing builds this may be
> later this weekend...
>
> +1s?
>
> 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

FBR: Reboot of ppc09-02

[Stephen John Smoogen]

Server has some problems with services and guests. We would like to reboot
the system to clear some issues being seen.

-- 
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: FBR: Pre GA tasks

[Stephen John Smoogen]

Reviewed updated diff. +1


On Fri, 24 Apr 2020 at 12:41, Mohan Boddu  wrote:

> Hi,
>
> On Fri, Apr 24, 2020 at 12:33 PM Kevin Fenzi  wrote:
> >
> > On Fri, Apr 24, 2020 at 12:26:06PM -0400, Mohan Boddu wrote:
> > > Hi,
> > >
> > > The following changes are needed for pre ga tasks, please review them.
> > >
> > > Thanks.
> >
> > 2 things:
> >
> > I do not think we want to change pkgdb-gnome-software-collections.json
> > today. If we do, gnome-software will start offering f32 updates to
> > people before release.
> >
> > I don't think we want to set Frozen: False yet, thats the infra freeze,
> > it's still on until next wed.
>
> Thanks Kevin, here's the updated diff.
>
> >
> > Otherwise looks ok to me.
> >
> > 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
> ___
> 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: Mirror the ansible repo from pagure in the batcave

[Stephen John Smoogen]

On Thu, 23 Apr 2020 at 16:37, Kevin Fenzi  wrote:

> On Thu, Apr 23, 2020 at 11:46:25AM +0200, Pierre-Yves Chibon wrote:
> > Good Morning Everyone,
> >
> > Kevin and I had a discussion on IRC the other day about mirroring the
> ansible
> > repo.
> > The options we considered are:
> ...snip...
> >
> >   For a first step I went with a third approach: a small python service
> that
> >   runs every 3 minutes (configurable): git fetch && git fsck (to ensure
> the git
> >   is in a correct state). It actually doesn't run every 3 minutes, it
> calls git,
> >   then wait for 3 minutes then calls git again and so on. So if git was
> ever to
> >   takes 4 minutes to run, there is no risk of the program stepping on
> its own
> >   toes.
>
> ok.
>
> I'm wondering if that might be overkill.
>
> Really if pagure.io blows up, we want to be able to look at the repo we
> have on batcave01 and be able to still operate while we recover
> pagure.io. If someone pushed or merged some commits in between the last
> time we synced and blowup, someone should have them in their local repo
> right? so we could just push them to the repo on batcave and be back
> completly in sync, no?
>
> but I guess it doesn't hurt to do every 3minutes, just some BW.
>
> Another option I mentioned the other day when we were talking, but I
> didnt really explain well was that we could wrap ansible-playbook into a
> wrapper that runs a git pull then ansible-playbook... so it would always
> be in sync at first you run it. That could be messy tho if there's
> another process doing pulls, etc. So I guess scrap that idea.
>
>
If we were to do that I would put in a lock logic like we do with our
rsync's and such.

New workflow, everyone uses rbac-playbook and we add some lock code to
check, make a lockfile, do the git pull, run the playbook, remove the
lockfile.
Check to see if a lockfile exists exit unless a --dontcare was put in place
at which point it could do somehting like:
if lockfile is younger than 10 minutes, assume that the plays are fresh
enough and use that.
if lockfile is older than 10 minutes, exit saying "we seem to have a dead
git pull going, please manually check what the problem is"

And I think that wont' work well for our super long ansible runs... I am
beginning to think we have an unsolvable problem here and everything will
suck somewhere.



-- 
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: FBR: Allow RHEL8 systems to know about code-ready

[Stephen John Smoogen]

There were worries it might pull in things we do not want. I am going to
let that be dealt with outside of FBR season.

On Tue, 21 Apr 2020 at 11:05, Neal Gompa  wrote:

> On Tue, Apr 21, 2020 at 11:03 AM Stephen John Smoogen 
> wrote:
> >
> >
> > diff --git a/files/common/rhel8.repo b/files/common/rhel8.repo
> > index 162848d..9686500 100644
> > --- a/files/common/rhel8.repo
> > +++ b/files/common/rhel8.repo
> > @@ -25,3 +25,10 @@ baseurl=
> https://infrastructure.fedoraproject.org/repo/rhel/rhel8/$basearch/rhel-
> >  gpgkey =
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta,file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
> >  enabled=1
> >  gpgcheck=1
> > +
> > +[rhel8-CRB]
> > +name = rhel8 CodeReadyBuilder $basearch
> > +baseurl=
> https://infrastructure.fedoraproject.org/repo/rhel/rhel8/$basearch/codeready-builder-for-rhel-8-$basearch-rpms/
> > +gpgkey =
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta,file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
> > +enabled=0
> > +gpgcheck=1
> >
> > --
>
> Generally +1, but why not just enable it? We're going to need it
> basically everywhere...
>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> 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

FBR: Allow RHEL8 systems to know about code-ready

[Stephen John Smoogen]

diff --git a/files/common/rhel8.repo b/files/common/rhel8.repo
index 162848d..9686500 100644
--- a/files/common/rhel8.repo
+++ b/files/common/rhel8.repo
@@ -25,3 +25,10 @@ baseurl=
https://infrastructure.fedoraproject.org/repo/rhel/rhel8/$basearch/rhel-
 gpgkey =
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta,file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
 enabled=1
 gpgcheck=1
+
+[rhel8-CRB]
+name = rhel8 CodeReadyBuilder $basearch
+baseurl=
https://infrastructure.fedoraproject.org/repo/rhel/rhel8/$basearch/codeready-builder-for-rhel-8-$basearch-rpms/
+gpgkey =
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta,file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
+enabled=0
+gpgcheck=1

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

FBR: add more ips to batcave allows

[Stephen John Smoogen]

This is for the RDU-CC expansion. We have these "zones" but these are not
subroutes (aka 8.43.85.40 is live and not a network high)

Fedora   68.43.85.40/29
Fedora   78.43.85.48/29
Fedora   88.43.85.56/29
Fedora   98.43.85.64/29
Fedora  10   8.43.85.72/29
Fedora  11   8.43.85.80/29

diff --git a/roles/batcave/files/allows b/roles/batcave/files/allows
index 793718f..850c5e0 100644
--- a/roles/batcave/files/allows
+++ b/roles/batcave/files/allows
@@ -98,6 +98,31 @@ require ip 67.219.144.69
 require ip 67.219.144.70

 # rdu2 community cage machines
+# this doesn't sit on network boundaries and from no longer exists in 2.4
+require ip 8.43.85.40
+require ip 8.43.85.41
+require ip 8.43.85.42
+require ip 8.43.85.43
+require ip 8.43.85.44
+require ip 8.43.85.45
+require ip 8.43.85.46
+require ip 8.43.85.47
+require ip 8.43.85.48
+require ip 8.43.85.49
+require ip 8.43.85.50
+require ip 8.43.85.51
+require ip 8.43.85.52
+require ip 8.43.85.53
+require ip 8.43.85.54
+require ip 8.43.85.55
+require ip 8.43.85.56
+require ip 8.43.85.57
+require ip 8.43.85.58
+require ip 8.43.85.59
+require ip 8.43.85.60
+require ip 8.43.85.61
+require ip 8.43.85.62
+require ip 8.43.85.63
 require ip 8.43.85.64
 require ip 8.43.85.65
 require ip 8.43.85.66
@@ -114,6 +139,14 @@ require ip 8.43.85.76
 require ip 8.43.85.77
 require ip 8.43.85.78
 require ip 8.43.85.79
+require ip 8.43.85.80
+require ip 8.43.85.81
+require ip 8.43.85.82
+require ip 8.43.85.83
+require ip 8.43.85.84
+require ip 8.43.85.85
+require ip 8.43.85.86
+require ip 8.43.85.87


 # ec2 instances

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

FBR: add sysadmin-analysis to bastion

[Stephen John Smoogen]

The sysadmin-analysis group is used on data-analysis01 for people to log in
and work there. Because everyone in that group was in an existing group, I
forgot to add it to bastion. However a new person joined and they don't
have access.

[smooge@batcave01 ansible (master)]$ git diff
diff --git a/inventory/group_vars/bastion b/inventory/group_vars/bastion
index 8e63d1a..160f1d1 100644
--- a/inventory/group_vars/bastion
+++ b/inventory/group_vars/bastion
@@ -23,7 +23,7 @@ custom_rules: [

 # TODO - remove modularity-wg membership here once it is not longer needed:
 # https://fedorahosted.org/fedora-infrastructure/ticket/5363
-fas_client_groups:
sysadmin-ask,sysadmin-atomic,sysadmin-web,sysadmin-main,sysadmin-cvs,sysadmin-noc,sysadmin-releng,sysadmin-dba,sysadmin-hosted,sysadmin-tools,sysadmin-spin,sysadmin-cloud,fi-apprentice,sysadmin-badges,sysadmin-troubleshoot,sysadmin-qa,sysadmin-centos,sysadmin-ppc,sysadmin-koschei,sysadmin-secondary,sysadmin-fedimg,sysadmin-veteran,sysadmin-mbs,modularity-wg,pungi-devel,sysadmin-upstreamfirst,sysadmin-releasemonitoring,sysadmin-gnome,sysadmin-copr,sysadmin-coreos,sysadmin-dbgserver,sysadmin-osbs,sysadmin-odcs
+fas_client_groups: sysadmin-analysis,
sysadmin-ask,sysadmin-atomic,sysadmin-web,sysadmin-main,sysadmin-cvs,sysadmin-noc,sysadmin-releng,sysadmin-dba,sysadmin-hosted,sysadmin-tools,sysadmin-spin,sysadmin-cloud,fi-apprentice,sysadmin-badges,sysadmin-troubleshoot,sysadmin-qa,sysadmin-centos,sysadmin-ppc,sysadmin-koschei,sysadmin-secondary,sysadmin-fedimg,sysadmin-veteran,sysadmin-mbs,modularity-wg,pungi-devel,sysadmin-upstreamfirst,sysadmin-releasemonitoring,sysadmin-gnome,sysadmin-copr,sysadmin-coreos,sysadmin-dbgserver,sysadmin-osbs,sysadmin-odcs

 #
 # This is a postfix gateway. This will pick up gateway postfix config in
base
-- 
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: [PATCH] fas_client: fix template to correctly apply on pkgs02 and add people02

[Stephen John Smoogen]

On Mon, 20 Apr 2020 at 11:13, Pierre-Yves Chibon 
wrote:

> On Mon, Apr 20, 2020 at 02:41:51PM +, Kevin Fenzi wrote:
> > The ansible_hostname variable is actually the short name of the host,
> > not the fqdn, so this conditional didn't match before. Switch it to use
> > startswith and also add people02 as thats the other host people try and
> > login to often after changing ssh keys.
> >
> > With this, pkgs02 and people02 should hopefully update ssh keys from fas
> > every 15min and avoid manual sync requests to the team.
> >
> > Signed-off-by: Kevin Fenzi 
> > ---
> >  roles/fas_client/templates/fas-client.cron.j2 | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/roles/fas_client/templates/fas-client.cron.j2
> b/roles/fas_client/templates/fas-client.cron.j2
> > index c0de939..8dd0a78 100644
> > --- a/roles/fas_client/templates/fas-client.cron.j2
> > +++ b/roles/fas_client/templates/fas-client.cron.j2
> > @@ -1,4 +1,4 @@
> > -{% if ansible_hostname == 'pkgs02.phx2.fedoraproject.org' %}
> > +{% if ansible_hostname.startswith(('pkgs02', 'people02')) %}
> >  */15 * * * * root /usr/local/bin/lock-wrapper fasClient
> "/usr/bin/fasClient -i |& grep -vi deprecation | /usr/local/bin/nag-once
> fassync 1d 2>&1"
> >  {% else %}
> >  00 20 * * * root /usr/local/bin/lock-wrapper fasClient "/bin/sleep
> $(($RANDOM \% 3600)); /usr/bin/fasClient -i |& grep -vi deprecation |
> /usr/local/bin/nag-once fassync 1d 2>&1"
>
> +1 for me, should we include pkgs01 for stg?
>

+1 with the same caveat?



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


-- 
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: FBR: Update all systems to nrpe-4.0.4

[Stephen John Smoogen]

On Sun, 19 Apr 2020 at 14:46, Kevin Fenzi  wrote:

> On Sun, Apr 19, 2020 at 01:55:56PM -0400, Stephen John Smoogen wrote:
> > NRPE for Fedora was updated to 4.0.4 which got auto-updated on many of
> the
> > infrastructure systems. However, the noc servers are still running a much
> > older version of nrpe which is causing some issues with monitoring.
> >
> > Plan: run on batcave01
> >
> > sudo ansible -i noc:batcave:bastion:people -m shell -a 'yum
> > --enablerepo=epel-testing update nagios* nrpe*'
> > sudo ansible -i noc:batcave:bastion:people -m shell -a 'rkhunter
> --propupd'
>
> +1, but note the problem is all rhel7 hosts. Fedora got a stable update
> and we applied it, but rhel7 still doesn't have it (still in testing).
>
> So, how about:
>
> ansible -m shell -a 'yum -y --enablerepo=epel-testing update nagios*
> nrpe*' distro_RedHat
>
>
I implemented this final version  and ran it. This FBR is complete.


> That will get only all the rhel7/8 machines. :)
>
> 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

FBR: Update all systems to nrpe-4.0.4

[Stephen John Smoogen]

NRPE for Fedora was updated to 4.0.4 which got auto-updated on many of the
infrastructure systems. However, the noc servers are still running a much
older version of nrpe which is causing some issues with monitoring.

Plan: run on batcave01

sudo ansible -i noc:batcave:bastion:people -m shell -a 'yum
--enablerepo=epel-testing update nagios* nrpe*'
sudo ansible -i noc:batcave:bastion:people -m shell -a 'rkhunter --propupd'

-- 
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: FBR: To enable signing on eln builds

[Stephen John Smoogen]

On Wed, 15 Apr 2020 at 16:21, Mohan Boddu  wrote:

> Hi,
>
> The following patch will enable signing on eln builds and for now it
> will be used only in stg.
>
> For more info: https://pagure.io/releng/issue/9154
>
>
The patch comes with different spacing  so not sure if that makes a
difference... it could also be gmail.. so +1 if that is not a problem.



> diff --git a/roles/robosignatory/templates/robosignatory.toml.j2
> b/roles/robosignatory/templates/robosignatory.toml.j2
> index 884f21c..27a12c8 100644
> --- a/roles/robosignatory/templates/robosignatory.toml.j2
> +++ b/roles/robosignatory/templates/robosignatory.toml.j2
> @@ -321,6 +321,14 @@ handlers = ["console"]
>  key = "{{ (env == 'production')|ternary('epel-6', 'testkey')
> }}"
>  keyid = "{{ (env == 'production')|ternary('0608b895',
> 'd300e724') }}"
>
> +# ELN signing
> +
> +[[consumer_config.koji_instances.primary.tags]]
> +from = "eln-pending"
> +to = "eln-candidate"
> +key = "{{ (env == 'production')|ternary('fedora-33',
> 'testkey') }}"
> +keyid = "{{ (env == 'production')|ternary('9570ff31',
> 'd300e724') }}"
> +
>
>  [consumer_config.ostree_refs]
>  [consumer_config.ostree_refs."fedora/rawhide/x86_64/iot"]
> ___
> 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: FBR: remove elections from inventory and run noc.yml playbook

[Stephen John Smoogen]

On Tue, 14 Apr 2020 at 15:49, Kevin Fenzi  wrote:

> On Tue, Apr 14, 2020 at 03:08:25PM -0400, Stephen John Smoogen wrote:
> > The following patch should do a minimal removal of the elections app from
> > ansible inventory so that a run of noc.yml will remove the systems from
> > being monitored. Then we can turn off the elections systems.
>
> Wrong patch attached? Or something going on with my email client?
>
> It looks like pingou's kerneltest patch?
>
>
Honestly.. you would think I knew how computers work by now . I have
attached correct patch (I hope).



> 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.
diff --git a/inventory/inventory b/inventory/inventory
index e632b1c..db9f77c 100644
--- a/inventory/inventory
+++ b/inventory/inventory
@@ -249,7 +249,6 @@ blockerbugs01.stg.phx2.fedoraproject.org
 bodhi-backend01.stg.phx2.fedoraproject.org
 busgateway01.stg.phx2.fedoraproject.org
 datagrepper01.stg.phx2.fedoraproject.org
-elections01.stg.phx2.fedoraproject.org
 fedocal01.stg.phx2.fedoraproject.org
 koji01.stg.phx2.fedoraproject.org
 os-node01.stg.phx2.fedoraproject.org
@@ -292,13 +291,6 @@ download_ibiblio
 download_rdu2
 download_cc_rdu
 
-[elections]
-elections01.phx2.fedoraproject.org
-elections02.phx2.fedoraproject.org
-
-[elections_stg]
-elections01.stg.phx2.fedoraproject.org
-
 [fas]
 fas01.phx2.fedoraproject.org
 
@@ -666,7 +658,6 @@ db01.stg.phx2.fedoraproject.org
 db03.stg.phx2.fedoraproject.org
 oci-candidate-registry01.stg.phx2.fedoraproject.org
 oci-registry01.stg.phx2.fedoraproject.org
-elections01.stg.phx2.fedoraproject.org
 #fas01.stg.phx2.fedoraproject.org
 fedimg01.stg.phx2.fedoraproject.org
 fedocal01.stg.phx2.fedoraproject.org
@@ -1246,7 +1237,6 @@ bodhi-backend01.phx2.fedoraproject.org
 mailman01.phx2.fedoraproject.org
 people02.fedoraproject.org
 db-datanommer02.phx2.fedoraproject.org
-elections01.phx2.fedoraproject.org
 fedocal02.phx2.fedoraproject.org
 nuancier01.phx2.fedoraproject.org
 pagure01.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: remove elections from inventory and run noc.yml playbook

[Stephen John Smoogen]

The following patch should do a minimal removal of the elections app from
ansible inventory so that a run of noc.yml will remove the systems from
being monitored. Then we can turn off the elections systems.

-- 
Stephen J Smoogen.
From acd374d1ba95aba044fc3417bb8a1ce191fe510b Mon Sep 17 00:00:00 2001
From: Pierre-Yves Chibon 
Date: Tue, 14 Apr 2020 14:19:30 +0200
Subject: [PATCH] proxies: add kerneltest.fp.o reverse proxy so it points to
 openshift

Signed-off-by: Pierre-Yves Chibon 
---
 playbooks/include/proxies-reverseproxy.yml | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/playbooks/include/proxies-reverseproxy.yml b/playbooks/include/proxies-reverseproxy.yml
index dd80b5e..680b055 100644
--- a/playbooks/include/proxies-reverseproxy.yml
+++ b/playbooks/include/proxies-reverseproxy.yml
@@ -237,6 +237,16 @@
 when: env == "staging"
 
   - 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
 website: qa.fedoraproject.org
 destname: blockerbugs
 remotepath: /blockerbugs
-- 
1.8.3.1

___
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: Big patch to dhcpd to move all mgmt interfaces to dhcp for move

[Stephen John Smoogen]

Kevin and I found all the mac addresses for the mgmt boxes and are putting
them onto dhcp so when they show up in new location.. they should come up
without trying to use 'dead' networks.



-- 
Stephen J Smoogen.
From a2bc61f49793893d9e771c64b777047a53d6063f Mon Sep 17 00:00:00 2001
From: Stephen Smoogen 
Date: Fri, 10 Apr 2020 21:09:36 +
Subject: [PATCH] initial big patch to mgmt dhcp

---
 .../files/dhcpd.conf.noc01.phx2.fedoraproject.org  | 1081 +++-
 1 file changed, 608 insertions(+), 473 deletions(-)

diff --git a/roles/dhcp_server/files/dhcpd.conf.noc01.phx2.fedoraproject.org b/roles/dhcp_server/files/dhcpd.conf.noc01.phx2.fedoraproject.org
index 5364603..d93f5ff 100644
--- a/roles/dhcp_server/files/dhcpd.conf.noc01.phx2.fedoraproject.org
+++ b/roles/dhcp_server/files/dhcpd.conf.noc01.phx2.fedoraproject.org
@@ -15,57 +15,57 @@ subnet 10.5.125.0 netmask 255.255.255.0 {
 host sign-vault01 {
 hardware ethernet 00:1a:64:67:a3:38;
 fixed-address 10.5.125.70;
-	next-server 10.5.126.41;
+next-server 10.5.126.41;
 option host-name "sign-vault01";
-	filename "pxelinux.0";
+filename "pxelinux.0";
 }
 
 host sign-vault03 {
  hardware ethernet fc:99:47:49:43:84;
  fixed-address 10.5.125.73;
  option host-name "sign-vault03";
-	 next-server 10.5.126.41;
-	 filename "pxelinux.0";
+ next-server 10.5.126.41;
+ filename "pxelinux.0";
 }
 
 host sign-vault04 {
  hardware ethernet fc:99:47:49:8d:fc;
  fixed-address 10.5.125.74;
  option host-name "sign-vault04";
-	 next-server 10.5.126.41;
-	 filename "pxelinux.0";
+ next-server 10.5.126.41;
+ filename "pxelinux.0";
 }
 
 host sign-vault05 {
-	 hardware ethernet D0:94:66:45:87:C1;
+ hardware ethernet D0:94:66:45:87:C1;
  fixed-address 10.5.125.83;
  option host-name "sign-vault05";
-	 next-server 10.5.126.41;
-	 filename "uefi/grubx64.efi";
+ next-server 10.5.126.41;
+ filename "uefi/grubx64.efi";
 }
 
 host sign-vault06 {
-	 hardware ethernet D0:94:66:45:A1:62;
+ hardware ethernet D0:94:66:45:A1:62;
  fixed-address 10.5.125.84;
  option host-name "sign-vault06";
-	 next-server 10.5.126.41;
-	 filename "uefi/grubx64.efi";
+ next-server 10.5.126.41;
+ filename "uefi/grubx64.efi";
 }
 
 host bkernel03 {
-	 hardware ethernet D0:94:66:45:8C:0F;
+ hardware ethernet D0:94:66:45:8C:0F;
  fixed-address 10.5.125.81;
  option host-name "bkernel03";
-	 next-server 10.5.126.41;
-	 filename "uefi/grubx64.efi";
+ next-server 10.5.126.41;
+ filename "uefi/grubx64.efi";
 }
 
 host bkernel04 {
-	 hardware ethernet D0:94:66:45:A7:E4;
+ hardware ethernet D0:94:66:45:A7:E4;
  fixed-address 10.5.125.82;
  option host-name "bkernel04";
-	 next-server 10.5.126.41;
-	 filename "uefi/grubx64.efi";
+ next-server 10.5.126.41;
+ filename "uefi/grubx64.efi";
 }
 
 host bvirthost01 {
@@ -73,7 +73,7 @@ subnet 10.5.125.0 netmask 255.255.255.0 {
 fixed-address 10.5.125.124;
 next-server 10.5.125.43;
 option host-name "bvirthost01";
-	filename "pxelinux.0";
+filename "pxelinux.0";
 }
 
 host bvirthost04 {
@@ -81,7 +81,7 @@ subnet 10.5.125.0 netmask 255.255.255.0 {
 fixed-address 10.5.125.76;
 next-server 10.5.126.41;
 option host-name "bvirthost04";
-	filename "pxelinux.0";
+filename "pxelinux.0";
 }
 
 host bvirthost05 {
@@ -89,7 +89,7 @@ subnet 10.5.125.0 netmask 255.255.255.0 {
 fixed-address 10.5.125.121;
 next-server 10.5.125.43;
 option host-name "bvirthost05.phx2.fedoraproject.org";
-	filename "pxelinux.0";
+filename "pxelinux.0";
 }
 
 
@@ -98,47 +98,47 @@ subnet 10.5.125.0 netmask 255.255.255.0 {
 fixed-address 10.5.125.2;
 next-server 10.5.126.41;
 option host-name "test-box01-b";
-	filename "pxelinux.0";
+filename "pxelinux.0";
 }
 
 host bvirthost07 {
 hardware ethernet 90:B1:1C:32:7E:8E;
 fixed-address 10.5.125.122;
-	next-server 10.5.126.41;
+next-server 10.5.126.41;
 option host-name "bvirthost07";
-	filename "pxelinux.0";
+filename "pxelinux.0";
 }
 
 host bvirthost12 {
-	 hardware ethernet 24:6E:96:B1:61:C4;
+ hardware ethernet 24:6E:96:B1:61:C4;
  fixed-address 10.5.125.10;
  option host-name "bvirthost12";
-	 next-server 10.5.126.41;
-	 filename "pxelinux.0";
+ next-server 10.5.126.41;
+ filename "pxelinux.0";
 }
 
 host bvirthost13 {
-	 hardware ethernet 24:6E:96:B1:5E:B4;
+ hardware ethernet 24:6E:96:B1:5E:B4;
  fixed-address 10.5.125.11;
  option host-name "bvirthost13";
-	 next-server 10.5.126.41;
-	 filename "pxelinux.0";
+   

Re: Issue with Fedora GeoIP service

[Stephen John Smoogen]

On Thu, 9 Apr 2020 at 12:35, Tomasz Torcz  wrote:

> On Thu, Apr 09, 2020 at 04:55:20PM +0200, Adrian Reber wrote:
> >
> > We finally pushed it to Fedora's staging environment. Please try it
> > using https://geoip.stg.fedoraproject.org/city if you have a chance.
>
>   It seems to have only IPv4 address. It provides correct city in
> my case, but IPv6 testing would be nice, too.
>
>
staging is ipv4 only.



>
> --
> Tomasz Torcz   “(…) today's high-end is tomorrow's embedded
> processor.”
> to...@pipebreaker.pl  — Mitchell Blank on LKML
> ___
> 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: Update geoip-city

[Stephen John Smoogen]

Let me know when you want to run the playbook.

On Tue, 31 Mar 2020 at 05:45, Adrian Reber  wrote:

> Attached is the patch to take the upstream update of geoip-city to
> Fedora infrastructure.
>
> I would like to try this first in staging and need some help to run the
> corresponding playbook to see if it works in our environment.
>
> Adrian
> ___
> 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: [PATCH] s3-mirror: fix missing trailing /

[Stephen John Smoogen]

This is an FBR and I +1 it

On Mon, 16 Mar 2020 at 13:01, Kevin Fenzi  wrote:

> This is causing f31 updates to not be synced. The cron job reports:
>
> Subject: Cron  /usr/local/bin/lock-wrapper
> s3sync-updates-current "/usr/local/bin/s3-sync-path.sh
> /pub/fedora/linux/updates/31/Everything/x86_64/os" 2>&1 |
> /usr/local/bin/nag-once s3-updates-current.sh 1d 2>&1
>
> Syntax: /usr/local/bin/s3-sync-path.sh /pub/path/to/sync/
> NOTE! Path must end with a trailing /
>
> Signed-off-by: Kevin Fenzi 
> ---
>  roles/s3-mirror/tasks/main.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/roles/s3-mirror/tasks/main.yml
> b/roles/s3-mirror/tasks/main.yml
> index 5da7a02..395679b 100644
> --- a/roles/s3-mirror/tasks/main.yml
> +++ b/roles/s3-mirror/tasks/main.yml
> @@ -69,7 +69,7 @@
>
>  - name: s3sync cron - updates for current
>cron: name="s3sync-updates-current" minute="0" hour="3,9,15,21"
> user="s3-mirror"
> -job='/usr/local/bin/lock-wrapper s3sync-updates-current
> "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/updates/{{
> FedoraCycleNumber|int }}/Everything/x86_64/os" 2>&1 |
> /usr/local/bin/nag-once s3-updates-current.sh 1d 2>&1'
> +job='/usr/local/bin/lock-wrapper s3sync-updates-current
> "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/updates/{{
> FedoraCycleNumber|int }}/Everything/x86_64/os/" 2>&1 |
> /usr/local/bin/nag-once s3-updates-current.sh 1d 2>&1'
>  cron_file=s3-updates-current.sh
>when: env != 'staging' and
> inventory_hostname.startswith('mm-backend01.')
>tags:
> --
> 1.8.3.1
> ___
> 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: Freeze break request: rabbitmq-cluster-adjustments

[Stephen John Smoogen]

At this point I think we are in full outage and this doesn't need +1's in
order to make things go. But I have +1 it

On Thu, 12 Mar 2020 at 15:32, Kevin Fenzi  wrote:

> I'd apply this later tonight when things were not very busy,
> or early tomorrow morning. (given +1s)
> ___
> 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: Weekly Backlog Refinement - Week Mar 09 2020

[Stephen John Smoogen]

On Mon, 9 Mar 2020 at 14:20, Mattia Verga  wrote:

> Just my thoughts:
>
> > Hi all,
> >
> > This is the first email with trying to better prioritize our backlog of
> > ticket ( https://pagure.io/fedora-infrastructure/issues ).
> >
> > So let's look at 5 tickets and rate them using the following categories :
> > * low-trouble, medium-trouble, high-trouble
> > * low-gain, medium-gain, high-gain
> >
> > #8455 Move mailman to newer release of Fedora or CentOS -
> > https://pagure.io/fedora-infrastructure/issue/8455
> > Trouble : high
> > Gain : high
> This one blocks other two issues and as reported in comments the currently
> deployed version suffers of at least one XSS leak, so I would mark as
> really high priority.
> But if we have to put very high effort to fix it, it could be better to
> make the effort to upgrade to mailman3 that is actively developed.
> >
>
>
The effort is upgrading to mailman3 which is actively developed.. getting
it and everything related to it packaged into RPMs is the problem.



> > #7919 Fix fas fedmsg sending in openshift -
> > https://pagure.io/fedora-infrastructure/issue/7919
> > Trouble : ?
> > Gain : low
> fas is being replaced, I don't think it worths to have it fixed.
> >
>

The issue is that we have to manually update password on various servers by
telling a box to update its FAS db's. It is more a 'how much do you want to
deal with people complaining they can't login to various services after
updating keys or passwords'.


> >
> > Let's also use this thread to ask questions and clarifications if needed.
> > Also if you have any ideas or feedback on how to improve that process I
> am
> > happy to hear about it :-).
> >
> >
> > Thanks
> > Clément
> ___
> 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: Freeze Break Request: s3-mirror adjustments

[Stephen John Smoogen]

+1

On Sat, 7 Mar 2020 at 05:17, Adrian Reber  wrote:

> Looks correct from my point of view, for both scripts we are now doing:
>
> 1. sync everything besides repodata
> 2. sync everything including (or only) repodata
> 3. invalidate repodata
> 4. delete files
>
> The only problem I can see now is that the files on the master are
> changing between those steps. Not sure how often the master is updated,
> but probably not more often than once or twice a day, right?
>
> In theory this should help with the problems we have been seeing in
> COPR.
>
> +1
>
> Adrian
>
> On Fri, Mar 06, 2020 at 02:04:21PM -0800, Kevin Fenzi wrote:
> > Final version? You be the judge. :)
> >
> > kevin
> > --
>
> > From bd3c100e3a5fdd453ebbd4b88cc3bba365d260c3 Mon Sep 17 00:00:00 2001
> > From: Kevin Fenzi 
> > Date: Thu, 5 Mar 2020 20:46:53 +
> > Subject: [PATCH] s3-mirror: Split things into 2 sync runs, one without
> >  repodata and delete, the other with both.
> >
> > In order to make sure the s3 mirror always is consistent, split out the
> commands
> > to make it sync without repodata and delete, then do another run with
> those, then finally
> > invalidate all the repodata/* files.
> >
> > Some of the cron jobs are adjusted to allow the repodata invalidation.
> >
> > Signed-off-by: Kevin Fenzi 
> > ---
> >  roles/s3-mirror/files/s3-sync-path.sh |  42 +
> >  roles/s3-mirror/files/s3.sh   | 114
> --
> >  roles/s3-mirror/tasks/main.yml|   4 +-
> >  3 files changed, 140 insertions(+), 20 deletions(-)
> >
> > diff --git a/roles/s3-mirror/files/s3-sync-path.sh
> b/roles/s3-mirror/files/s3-sync-path.sh
> > index e6ac994..79b4d63 100644
> > --- a/roles/s3-mirror/files/s3-sync-path.sh
> > +++ b/roles/s3-mirror/files/s3-sync-path.sh
> > @@ -9,7 +9,30 @@ if [[ "$1" == "" ]] || [[ $1 != /pub* ]] || [[ $1 != */
> ]]; then
> >exit 1
> >  fi
> >
> > -CMD="aws s3 sync   \
> > +# first run do not delete anything or copy the repodata.
> > +CMD1="aws s3 sync   \
> > +  --exclude */repodata/* \
> > +  --exclude *.snapshot/*  \
> > +  --exclude *source/* \
> > +  --exclude *SRPMS/*  \
> > +  --exclude *debug/*  \
> > +  --exclude *beta/*   \
> > +  --exclude *ppc/*\
> > +  --exclude *ppc64/*  \
> > +  --exclude *repoview/*   \
> > +  --exclude *Fedora/* \
> > +  --exclude *EFI/*\
> > +  --exclude *core/*   \
> > +  --exclude *extras/* \
> > +  --exclude *LiveOS/* \
> > +  --exclude *development/rawhide/* \
> > +  --no-follow-symlinks\
> > +  --only-show-errors  \
> > +  "
> > +  #--dryrun \
> > +
> > +# second we delete old content and also copy the repodata
> > +CMD2="aws s3 sync   \
> >--delete \
> >--exclude *.snapshot/*  \
> >--exclude *source/* \
> > @@ -32,19 +55,12 @@ CMD="aws s3 sync   \
> >
> >  #echo "$CMD /srv$1 s3://s3-mirror-us-west-1-02.fedoraproject.org$1"
> >  echo "Starting $1 sync at $(date)" >> /var/log/s3-mirror/timestamps
> > -$CMD /srv$1 s3://s3-mirror-us-west-1-02.fedoraproject.org$1
> > -echo "Ending $1 sync at $(date)" >> /var/log/s3-mirror/timestamps
> > -
> > +$CMD1 /srv$1 s3://s3-mirror-us-west-1-02.fedoraproject.org$1
> > +$CMD1 /srv$1/repodata/ s3://s3-mirror-us-west-1-02.fedoraproject.org
> $1/repodata/
> >  # Always do the invalidations because they are quick and prevent issues
> >  # depending on which path is synced.
> > -for file in $(echo /srv/pub/epel/6/*/repodata/repomd.xml | sed
> 's#/srv##g'); do
> > -  aws cloudfront create-invalidation --distribution-id E2KJMDC0QAJDMU
> --paths "$file" > /dev/null
> > -done
> > -
> > -for file in $(echo /srv/pub/epel/7/*/repodata/repomd.xml | sed
> 's#/srv##g'); do
> > -  aws cloudfront create-invalidation --distribution-id E2KJMDC0QAJDMU
> --paths "$file" > /dev/null
> > -done
> > -
> > -for file in $(echo
> /srv/pub/fedora/linux/updates/*/*/*/repodata/repomd.xml | sed 's#/srv##g');
> do
> > +for file in $(echo $1/repodata/* ); do
> >aws cloudfront create-invalidation --distribution-id E2KJMDC0QAJDMU
> --paths "$file" > /dev/null
> >  done
> > +$CMD2 /srv$1 s3://s3-mirror-us-west-1-02.fedoraproject.org$1
> > +echo "Ending $1 sync at $(date)" >> /var/log/s3-mirror/timestamps
> > diff --git a/roles/s3-mirror/files/s3.sh b/roles/s3-mirror/files/s3.sh
> > index 55c1940..c70defb 100644
> > --- a/roles/s3-mirror/files/s3.sh
> > +++ b/roles/s3-mirror/files/s3.sh
> > @@ -3,8 +3,10 @@
> >  # LGPL
> >  # Author: Rick Elrod 
> >
> > -CMD="aws s3 sync   \
> > -  --delete \
> > +# first run this command that syncs, but does not delete.
> > +# It also excludes repodata.
> > +CMD1="aws s3 sync   \
> > +  --exclude 

Re: Freeze Break Request: s3-mirror adjustments

[Stephen John Smoogen]

+1 ok so the s3sync does allow for delete. I thought from previous
conversations it didn't work that way so my view of what was needed was
wrong.

On Thu, 5 Mar 2020 at 16:06, Kevin Fenzi  wrote:

> First, I noticed we are running the full sync twice right now, at the
> same time:
>
> [root@mm-backend01 cron.d][PROD]# cat /etc/cron.d/s3.sh
> #Ansible: s3sync
> 0 0,11 * * * s3-mirror /usr/local/bin/lock-wrapper s3sync
> /usr/local/bin/s3.sh 2>&1 | /usr/local/bin/nag-once s3.sh 1d 2>
> &1
> #Ansible: s3sync-main
> 0 0 * * * s3-mirror /usr/local/bin/lock-wrapper s3sync-main
> /usr/local/bin/s3.sh 2>&1 | /usr/local/bin/nag-once s3.sh 1d
> 2>&1
>
> Second, the attached patch changes the sync scripts to:
>
> * do one sync with no --delete and excluding repodata
> * do another one with --delete and including repodata
> * invalidate the repodata
>
> I adjusted the cron jobs to handle the repodata invalidate (I think).
>
> TODO: only sync when things have changed.
>
> +1s?
>
> 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: Freeze break request: koji autovacuum_freeze_max_age

[Stephen John Smoogen]

On Wed, 4 Mar 2020 at 04:00, Julen Landa Alustiza 
wrote:

> Is there an ETA for the next vacuum process? If we can wait for some
>

There is no ETA as it depends on the number of builds that have been done
since the last autovac. A large number means it is further into the future
but takes much longer to do. A smaller number means it will happen sooner
but shorter in time. The number of builds per time is not something that
averages very well.. you have days where things seem regular and then a
mass of modules and koschei and other items all hit for a couple of days,
etc etc.



> months it might worth to upgrade to newer rhel and postgres after dc
> migration but before next autovacuum process instead of lowering now the
> max age and forcing another autovacuum process with current old postgres
>
> 20/3/4 09:41(e)an, Clement Verna igorleak idatzi zuen:
> >
> >
> > On Tue, 3 Mar 2020 at 22:39, Kevin Fenzi  > > wrote:
> >
> > And our lazyness and indecision pays off!
> >
> > The autovac is finally done and load should be back to normal.
> >
> >
> > Should we lower down the autovacuum max age ? so that next times it runs
> > it does not take that long ?
> >
> >
> > I am going to re-enable backups.
> >
> > Thanks everyone.
> >
> > 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
> >
> >
> > ___
> > 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
>


-- 
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: FBR: Change the retirement date to yesterday in pdc

[Stephen John Smoogen]

Reviewed. Covers the problems I could think of. +1

On Tue, 3 Mar 2020 at 14:37, Mohan Boddu  wrote:

> Currently when a package is retired, it sets the eol date to today's
> date in pdc, but that enables people to revert the git retirement
> commit until the end of the day and that causes a couple of problems
>
> 1. When fedpkg retire is called, it sets the eol date in pdc but when
> people revert it on the very same day, the eol date is not changed
> back.
>
> 2. Since the eol date is not change back, the package gets blocked in
> koji and people have to request releng to fix it manually and it
> causes some confusion.
>
> To fix this issue, we decided to change the retirement date to
> yesterday's date and that disables people to revert the commit.
>
> Issues: https://pagure.io/releng/issue/8851 and
> https://pagure.io/releng/issue/9169
>
> Fix:
>
> diff --git a/pdcupdater/handlers/retirement.py
> b/pdcupdater/handlers/retirement.py
> index 3ccda5a..1fbf23b 100644
> --- a/pdcupdater/handlers/retirement.py
> +++ b/pdcupdater/handlers/retirement.py
> @@ -1,5 +1,5 @@
>  import logging
> -from datetime import datetime
> +from datetime import datetime, timedelta
>  import requests
>
>  import pdcupdater.services
> @@ -189,9 +189,12 @@ def _is_retired_in_dist_git(namespace, repo,
> branch, requests_session=None):
>  @pdcupdater.utils.retry(wait_on=requests.exceptions.ConnectionError)
>  def _retire_branch(pdc, branch):
>  """ Internal method for retiring a branch in PDC. """
> -today = datetime.utcnow().date()
> +# To disable immediate git reverts
> +# Fixes: https://pagure.io/releng/issue/8851 - Better solution
> required
> +# Fixes: https://pagure.io/releng/issue/9169 - Not ideal, but works
> +yesterday = datetime.utcnow().date() - timedelta(days=1)
>  for sla in branch['slas']:
>  sla_eol = datetime.strptime(sla['eol'], '%Y-%m-%d').date()
> -if sla_eol > today:
> +if sla_eol > yesterday:
>  pdc['component-branch-slas'][sla['id']]._ \
> -+= {'eol': str(today)}
> ++= {'eol': str(yesterday)}
>
>
> This will be a hotfix in pdc-backend01.phx2.fp.o where pdc-updater is
> running.
>
> Thanks,
> Mohan Boddu.
> ___
> 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: FBR: Add monitoring for website build fails

[Stephen John Smoogen]

On Thu, 27 Feb 2020 at 00:47, Rick Elrod  wrote:

> I'd like to apply the following which does:
> - Adds a script I wrote for reading a timestamp from a file on disk
> and alerting if the timestamp within it is NOT within a particular
> delta to now.
> - Applies this to sundries01 and uses it to check
> /srv/websites/getfedora.org/build.timestamp.txt which now gets
> generated as part of the websites build.
>
> The purpose is because sometimes someone will commit something to the
> websites repo which breaks the build, but because of how we have
> things set up in openshift (cronjob), we don't get any kind of alert
> when that happens.
>
> Right now this sets the delta to 3 hours. In theory it should be 1,
> but I figure let it try to build a few times before we start alerting.
>
> Rick
>
>
>
Patch has been reviewed and looks correct for nagios and nrpe.



> commit 657d050f6d699bc43973d968cd93d12131fca7f2
> Author: Rick Elrod 
> Date:   Thu Feb 27 05:29:24 2020 +
>
> nagios: Add script and check for checking that a timestamp within
> a file is within a delta of now, and then use this for alerting when
> websites stop building
>
> Signed-off-by: Rick Elrod 
>
> diff --git a/roles/nagios_client/files/scripts/check_timestamp_from_file
> b/roles/nagios_client/files/scripts/check_timestamp_from_file
> new file mode 100644
> index 000..9064337
> --- /dev/null
> +++ b/roles/nagios_client/files/scripts/check_timestamp_from_file
> @@ -0,0 +1,43 @@
> +#!/usr/bin/env python
> +
> +# Takes a path to a file and a delta. The file must simply contain an
> epoch
> +# timestamp. It can be an integer or a float, as can the delta.
> +#
> +# Alerts critical if (now - timestamp contained in file) > delta.
> +#
> +# Rick Elrod 
> +# MIT
> +
> +import sys
> +import time
> +
> +if len(sys.argv) != 3:
> +print('UNKNOWN: Pass path to file and delta as parameters')
> +sys.exit(3)
> +
> +filename = sys.argv[1]
> +delta = float(sys.argv[2])
> +
> +timestamp = None
> +
> +try:
> +with open(filename, 'r') as f:
> +timestamp = float(f.read().strip())
> +except Exception as e:
> +print('UNKNOWN: Unable to open/read file path')
> +sys.exit(3)
> +
> +difference = round(time.time() - timestamp, 2)
> +if difference > delta:
> +print(
> +'CRITICAL: Timestamp in file (%.2f) exceeds delta (%.2f) by
> %.2f seconds' % (
> +timestamp,
> +delta,
> +difference - delta))
> +sys.exit(2)
> +
> +print('OK: Timestamp in file (%.2f) is within delta (%.2f) of now, by
> %.2f seconds' % (
> +timestamp,
> +delta,
> +abs(difference - delta)))
> +sys.exit(0)
> diff --git a/roles/nagios_client/tasks/main.yml
> b/roles/nagios_client/tasks/main.yml
> index 2e5e0df..8e71a3b 100644
> --- a/roles/nagios_client/tasks/main.yml
> +++ b/roles/nagios_client/tasks/main.yml
> @@ -47,6 +47,7 @@
>- check_osbs_api.py
>- check_ipa_replication
>- check_redis_queue.sh
> +  - check_timestamp_from_file
>when: not inventory_hostname.startswith('noc')
>tags:
>- nagios_client
> @@ -226,6 +227,16 @@
>tags:
>- nagios_client
>
> +- name: install nrpe checks for sundries/websites
> +  template: src={{ item }}.j2 dest=/etc/nrpe.d/{{ item }} owner=root
> group=root mode=0644
> +  with_items:
> +  - check_websites_buildtime.cfg
> +  when: inventory_hostname.startswith('sundries')
> +  notify:
> +  - restart nrpe
> +  tags:
> +  - nagios_client
> +
>  - name: install nrpe config for the RabbitMQ checks
>template:
>  src: "rabbitmq_args.ini.j2"
> diff --git a/roles/nagios_client/templates/check_websites_buildtime.cfg.j2
> b/roles/nagios_client/templates/check_websites_buildtime.cfg.j2
> new file mode 100644
> index 000..ff5639d
> --- /dev/null
> +++ b/roles/nagios_client/templates/check_websites_buildtime.cfg.j2
> @@ -0,0 +1,2 @@
> +# Alert if websites haven't been built in 3 hours
> +command[check_websites_buildtime]={{ libdir
> }}/nagios/plugins/check_timestamp_from_file
> /srv/websites/getfedora.org/build.timestamp.txt 10800
> diff --git a/roles/nagios_server/templates/nagios/services/websites.cfg.j2
> b/roles/nagios_server/templates/nagios/services/websites.cfg.j2
> index 85e8f8e..c8958d7 100644
> --- a/roles/nagios_server/templates/nagios/services/websites.cfg.j2
> +++ b/roles/nagios_server/templates/nagios/services/websites.cfg.j2
> @@ -316,4 +316,14 @@ define service {
>use   ppc-secondarytemplate
>  }
>
> +## Auxillary to websites but necessary to make them happen
> +
> +define service {
> +  host_name sundries01.phx2.fedoraproject.org
> +  service_description   websites build happened recently
> +  check_command check_by_nrpe!check_websites_buildtime
> +  use   websitetemplate
> +}
> +
> +
>  {% endif %}
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to
> 

Freeze Break Request: update wildcard cert to new one

[Stephen John Smoogen]

This patch should make the changes to the appropriate files so that various
playbooks will use the newer certificate wildcard-2020

-- 
Stephen J Smoogen.
From 40a3b08e2120f7e43bd5352b16f8717da64a828f Mon Sep 17 00:00:00 2001
From: Stephen Smoogen 
Date: Thu, 27 Feb 2020 21:19:54 +
Subject: [PATCH] put in patches to use wildcard2020

---
 files/httpd/website_id_fp_o_zanata.conf  | 6 +++---
 inventory/group_vars/all | 8 
 playbooks/include/proxies-certificates.yml   | 4 ++--
 playbooks/include/proxies-websites.yml   | 2 +-
 roles/download/tasks/main.yml| 6 +++---
 roles/fedmsg/gateway/slave/tasks/main.yml| 4 ++--
 roles/fedmsg/gateway/slave/templates/stunnel-conf.j2 | 4 ++--
 roles/httpd/website/defaults/main.yml| 2 +-
 roles/kojipkgs/files/squid.conf  | 2 +-
 9 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/files/httpd/website_id_fp_o_zanata.conf b/files/httpd/website_id_fp_o_zanata.conf
index f2c9322..871be0e 100644
--- a/files/httpd/website_id_fp_o_zanata.conf
+++ b/files/httpd/website_id_fp_o_zanata.conf
@@ -14,9 +14,9 @@ Listen 44342 https
 
   SSLEngine on
   SSLUseStapling on
-  SSLCertificateFile /etc/pki/tls/certs/wildcard-2017.fedoraproject.org.cert
-  SSLCertificateKeyFile /etc/pki/tls/private/wildcard-2017.fedoraproject.org.key
-  SSLCertificateChainFile /etc/pki/tls/certs/wildcard-2017.fedoraproject.org.intermediate.cert
+  SSLCertificateFile /etc/pki/tls/certs/wildcard-2020.fedoraproject.org.cert
+  SSLCertificateKeyFile /etc/pki/tls/private/wildcard-2020.fedoraproject.org.key
+  SSLCertificateChainFile /etc/pki/tls/certs/wildcard-2020.fedoraproject.org.intermediate.cert
 
   SSLHonorCipherOrder On
 
diff --git a/inventory/group_vars/all b/inventory/group_vars/all
index f862897..ef0057e 100644
--- a/inventory/group_vars/all
+++ b/inventory/group_vars/all
@@ -235,10 +235,10 @@ max_cpu: "{{ num_cpus * 5 }}"
 
 # This is the wildcard certname for our proxies.  It has a different name for
 # the staging group and is used in the proxies.yml playbook.
-wildcard_cert_name: wildcard-2017.fedoraproject.org
-wildcard_crt_file: wildcard-2017.fedoraproject.org.cert
-wildcard_key_file: wildcard-2017.fedoraproject.org.key
-wildcard_int_file: wildcard-2017.fedoraproject.org.intermediate.cert
+wildcard_cert_name: wildcard-2020.fedoraproject.org
+wildcard_crt_file: wildcard-2020.fedoraproject.org.cert
+wildcard_key_file: wildcard-2020.fedoraproject.org.key
+wildcard_int_file: wildcard-2020.fedoraproject.org.intermediate.cert
 
 # This is the openshift wildcard cert. Until it exists set it equal to wildcard
 os_wildcard_cert_name: wildcard-2017.app.os.fedoraproject.org
diff --git a/playbooks/include/proxies-certificates.yml b/playbooks/include/proxies-certificates.yml
index 1225570..4d494fe 100644
--- a/playbooks/include/proxies-certificates.yml
+++ b/playbooks/include/proxies-certificates.yml
@@ -16,8 +16,8 @@
   - role: httpd/mod_ssl
 
   - role: httpd/certificate
-certname: wildcard-2017.fedoraproject.org
-SSLCertificateChainFile: wildcard-2017.fedoraproject.org.intermediate.cert
+certname: wildcard-2020.fedoraproject.org
+SSLCertificateChainFile: wildcard-2020.fedoraproject.org.intermediate.cert
 
   # - role: httpd/certificate
   #   certname: wildcard-2017.fedorahosted.org
diff --git a/playbooks/include/proxies-websites.yml b/playbooks/include/proxies-websites.yml
index 0dee3e7..9c8beb2 100644
--- a/playbooks/include/proxies-websites.yml
+++ b/playbooks/include/proxies-websites.yml
@@ -903,7 +903,7 @@
   - role: httpd/website
 site_name: nagios.fedoraproject.org
 server_aliases: [nagios.stg.fedoraproject.org]
-SSLCertificateChainFile: wildcard-2017.fedoraproject.org.intermediate.cert
+SSLCertificateChainFile: wildcard-2020.fedoraproject.org.intermediate.cert
 sslonly: true
 cert_name: "{{wildcard_cert_name}}"
 
diff --git a/roles/download/tasks/main.yml b/roles/download/tasks/main.yml
index d9c6146..914f30b 100644
--- a/roles/download/tasks/main.yml
+++ b/roles/download/tasks/main.yml
@@ -62,13 +62,13 @@
   - selinux
 
 - name: Copy wildcard cert from puppet private
-  copy: src="{{private}}/files/httpd/wildcard-2017.fedoraproject.org.cert" dest=/etc/pki/tls/certs/wildcard-2017.fedoraproject.org.cert owner=root group=root mode=0644
+  copy: src="{{private}}/files/httpd/wildcard-2020.fedoraproject.org.cert" dest=/etc/pki/tls/certs/wildcard-2020.fedoraproject.org.cert owner=root group=root mode=0644
 
 - name: Copy wildcard key from puppet private
-  copy: src="{{private}}/files/httpd/wildcard-2017.fedoraproject.org.key" dest=/etc/pki/tls/private/wildcard-2017.fedoraproject.org.key owner=root group=root mode=0600
+  copy: src="{{private}}/files/httpd/wildcard-2020.fedoraproject.org.key" dest=/etc/pki/tls/private/wildcard-2020.fedoraproject.org.key owner=root group=root mode=0600
 
 - name: Copy intermediate 

Re: State of FMN (FedMSG Notifications) and Replacement

[Stephen John Smoogen]

On Wed, 26 Feb 2020 at 15:58, Kevin Fenzi  wrote:

> On Wed, Feb 26, 2020 at 08:26:09AM +0100, Clement Verna wrote:
> > Hi all,
> >
> > FMN (https://apps.fedoraproject.org/notifications) is currently one of
> the
> > main blocking point for dropping fedmsg in favour of fedora-messaging.
> > FMN is quite important to the community and the composition of Fedora
> > because it gives emails and notifications on commits, composes, builds
> and
> > updates via email and other tools.
> >
> > However, the code base is written in Python 2.7 and not maintained
> anymore.
> > Currently the service has to run on a Fedora 28 system to continue
> running.
> > This causes multiple problems and concerns, and needs to be addressed
> > before the datacenter move in June.
> >
> > In order to start putting together a specification for a replacement, we
> > should try to look at the minimum requirements for a notification system.
> > For example the current system supports sending notifications to IRC,
> > emails and SSE (Server Sent Event), Can we live without SSE ? Can we live
> > without IRC ? Do we need it to monitor everything it does currently or
> just
> > a subset of items that the community has found useful.
> >
> > Let's use this thread to brainstorm ideas on what we need.
>
> First I can add a bit of history/background for everyone here:
>
> Long ago every app in fedora infrastructure (koji, bodhi, etc)
> implemented it's own notification system (usually via email). So, in
> order to change things a user would have to go to each system, find
> prefs, find how it's ui was implemented and try and adjust things.
> Additionally, this was a massive duplication of effort, with every app
> implementing these same things over and over differently.
>
> As soon as fedmsg bus came along, we were able to turn off the old apps
> notification systems (except for bodhi, which I think still emails
> itself) and have a app that sits and listens for fedmsgs and notifies
> users. This is a win for users in that there's one place to go to change
> things and a win for developers because they don't need to implement a
> notification system at all, just make sure they emit messages for
> everything that is of interest in their app.
>
> Personally, I think both email and IRC are part of a minimal
> replacement. I think SSE was for the planned android app, which we never
> really deployed.
>
> The current FMN app is SUPER flexable, which is awsome, but also makes
> it really confusing for people. I think a more simple interface that
> lets you choose topics you want to get notified about would do.
>
> I think it's vital to have several 'predefined' profiles:
> * packager - if you are in the packager group, get all your packages
> commits, etc.
>
> * sysadmin - you want to know about nagios alerts, ansible playbook
> runs, etc.
>
> * releng - you get signing, compose info, etc.
>
> * qa - updates pushes info? openqa results? rc composes?
>
> * Possibly some more defaults for other groups?
>
> I think the current FMN batching options are too much. Just say 'daily
> digest' 'as they happen' or some small subset.
>
> I don't think we need to allow validating and using arbitrary email
> addresses in the first cut, just use the fas account one.
>
> Probibly we should make a wiki page and collect everything and then
> order importance and see what we NEED to have in a first replacement.
>
>
If we have email, I would like to request that the tool tracks bounces and
puts people who have a large bounce rate on hold. I have to at least once
every couple of  months go onto bastion and clean out a large queue of
emails which are never going to be delivered but we try to do day after
day.  There are 3 problems with us trying to continue delivering mail to
nonexistant accounts:
a) When there is a storm of activity, legitimate deliveries can get behind
b) we every now and then have postfix run out of room
c) various spam tools check to see if you keep delivering things and then
score you higher as a possible spammer. Our biggest clients of gmail do
this regularly where they will start putting our other deliveries at a
later time and once I clean out the 10k never going to deliver ones.. they
start allowing deliveries.

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

Meeting agenda for 2020-02-20

[Stephen John Smoogen]

## Preamble
The infrastructure team will be having its weekly meeting tomorrow,
2020-02-20 at 15:00 UTC in #fedora-meeting-1 on the freenode network.
We have a document at https://board.net/p/fedora-infra
Please try and review and edit that document before the meeting and we
will use it to have our agenda of things to discuss. A copy as of today
is included in this email.

If you have something to discuss, add the topic to the discussion area
with your name. If you would like to teach other folks about some
application or setup in our infrastructure, please add that topic and
your name to the learn about section.

## Introduction
We will use it over the week before the meeting to gather status and
info and discussion items and so forth, then use it in the irc meeting
to transfer information to the meetbot logs.

### Meeting start stuff
```
#startmeeting Infrastructure (2020-02-20)
#meetingname infrastructure
#chair nirik pingou relrod smooge tflink cverna mizdebsk mkonecny
abompard bowlofeggs
#info Agenda is at: https://board.net/p/fedora-infra
#topic aloha
```

### Determine who the next chair is
#topic Next chair
#info magic eight ball says:
#info 2020-02-20 - bowlofeggs
#info 2020-02-27 - ???

### Let new people say hello
```
#topic New folks introductions
#info This is a place where people who are interested in Fedora
Infrastructure can introduce themselves
#info Getting Started Guide:
https://fedoraproject.org/wiki/Infrastructure/GettingStarted
```

### Status / Information / Trivia / Announcements

(We put things here we want others on the team to know, but don't need
to discuss)
(Please use ```#info (the thing - your name)```

```
#topic announcements and information
#info ops folks are doing a 30min ticket triage every day at 19UTC in
#fedora-admin - please join
#info Fedora Infrastructure will be moving in 2020-06 from its Phoenix
Az datacenter to one near Herndon Va. A lot of planning will be
involved on this. Please watch out for announcements on changes.
#info Old openstack cloud is being decommissioned 2020-03-01. Working
with instance owners to make sure everyone is migrated off.
#info New blog post about release-monitoring.org is now out
https://communityblog.fedoraproject.org/stories-from-the-amazing-world-of-release-monitoring-org-9/
#info We say thank you to bowlofeggs who is leaving Red Hat for other places.
#info We say thank you to relrod who is leaving CPE to go to Ansible.
```

### Things we should discuss

We use this section to bring up discussion topics. Things we want to talk about
as a group and come up with some consensus /suor decision or just brainstorm a
problem or issue. If there are none of these we skip this section.
(Use ```#topic your discussion topic - your username)```
```
#topic Oncall
#info https://fedoraproject.org/wiki/Infrastructure/Oncall

#info nirik is oncall 2020-02-13 -> 2020-02-20
#info cverna is oncall 2020-02-20 -> 2020-02-27
#info pingou is oncall 2020-02-28 -> 2020-03-05

## .oncalltakeeu .oncalltakeus

#info Summary of last week: (from current oncall )
#info

#topic Monitoring discussion [nirik]
#info https://nagios.fedoraproject.org/nagios
#info Go over existing out items and fix

#topic Tickets discussion [nirik]
#info https://pagure.io/fedora-infrastructure/report/Meetings%20ticket

#topic backlog discussion
#info go over our backlog and discuss and determine priority
```
Go thru each ticket one by one

### Put all topics for discussion under here

Here we will discuss any apprentice questions, try and match up people looking
for things to do with things to do, progress, testing anything like that.

### Learn about some application or setup in infrastructure

(This section, each week we get 1 person to talk about an application
or setup that we have. Just going over what it is, how to contribute,
ideas for improvement, etc. Whoever would like to do this, just add
the i/nfo in this section. In the event we don't find someone to teach
about something, we skip this section and just move on to open floor.)
```
#info
```
### Meeting end stuff
```
#topic Open Floor

#endmeeting
```

-- 
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: When adding hosts to ansible please first update DNS

[Stephen John Smoogen]

On Wed, 19 Feb 2020 at 06:59, Miroslav Suchý  wrote:
>
> Dne 17. 02. 20 v 21:50 Stephen John Smoogen napsal(a):
> > Because ip addresses can change, and we do not have time to fix it in 
> > multiple places,
>
> That was me.
> We will be adding 9 machines. One by one. So my intention was to go with IP 
> and then after we are done (one week) flip
> it to dns.
>
> But OK, I will use dns, though that will mean more generated issues from me.

That is fine. I will be working on setting of a dns zone and getting
you rights to add dns entries to them.

> --
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
> ___
> 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

When adding hosts to ansible please first update DNS

[Stephen John Smoogen]

When bringing up a new host,

1. Edit the appropriate dns file in the Fedora Infrastructure DNS
repository.
2. Commit the changes and wait for them to sync out to dns.
3. Test that the hostname and ip address match.
4. Add the hostname to the ansible inventory file in the appropriate group.
5. Continue the deployment from then on.

Because ip addresses can change, and we do not have time to fix it in
multiple places, we are asking that no 'naked' ip addresses be used in the
ansible inventory from now on. We will be working on removing all entries
by Wednesday and after that any 'naked' ip address commit to the inventory
will be reverted.



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

Fedora Infrastructure Meeting Agenda for 2020-02-13

[Stephen John Smoogen]

## Preamble
The infrastructure team will be having its weekly meeting tomorrow,
2020-02-13 at 15:00 UTC in #fedora-meeting-1 on the freenode network.
We have a document at https://board.net/p/fedora-infra
Please try and review and edit that document before the meeting and we
will use it to have our agenda of things to discuss. A copy as of today
is included in this email.

If you have something to discuss, add the topic to the discussion area
with your name. If you would like to teach other folks about some
application or setup in our infrastructure, please add that topic and
your name to the learn about section.

## Introduction
We will use it over the week before the meeting to gather status and info
and discussion items and so forth, then use it in the irc meeting to
transfer information to the meetbot logs.

### Meeting start stuff
```
#startmeeting Infrastructure (2020-02-13)
#meetingname infrastructure
#chair nirik pingou relrod smooge tflink cverna mizdebsk mkonecny abompard
bowlofeggs
#info Agenda is at: https://board.net/p/fedora-infra
#topic aloha
```

### Determine who the next chair is
#topic Next chair
#info magic eight ball says:
#info 2020-02-13 - smooge
#info 2020-02-20 - bowlofeggs
#info 2020-02-27 - ???

### Let new people say hello
```
#topic New folks introductions
#info This is a place where people who are interested in Fedora
Infrastructure can introduce themselves
#info Getting Started Guide:
https://fedoraproject.org/wiki/Infrastructure/GettingStarted
```

### Status / Information / Trivia / Announcements

(We put things here we want others on the team to know, but don't need to
discuss)
(Please use ```#info (the thing - your name)```

```
#topic announcements and information
#info ops folks are trying a 30min ticket triage every day at 19UTC in
#fedora-admin
#info Fedora Infrastructure will be moving in 2020-06 from its Phoenix Az
datacenter to one near Herndon Va. A lot of planning will be involved on
this. Please watch out for announcements on changes.
#info Fedora 32 has been branched from rawhide.
#info

```

### Things we should discuss

We use this section to bring up discussion topics. Things we want to talk
about
as a group and come up with some consensus /suor decision or just
brainstorm a
problem or issue. If there are none of these we skip this section.
(Use ```#topic your discussion topic - your username)```
```
#topic Oncall
#info https://fedoraproject.org/wiki/Infrastructure/Oncall

#info smooge is oncall 2020-02-06 -> 2020-02-13
#info nirik is oncall 2020-02-13 -> 2020-02-20
#info cverna is oncall 2020-02-20 -> 2020-02-27
#info ??? is oncall 2020-02-27 -> 2020-03-05

## .oncalltakeeu .oncalltakeus

#info Summary of last week: (from current oncall )
#info DNS broke on 2020-02-11 due to signing problems.

#topic Monitoring discussion [nirik]
#info https://nagios.fedoraproject.org/nagios
#info Go over existing out items and fix

#topic Tickets discussion [nirik]
#info https://pagure.io/fedora-infrastructure/report/Meetings%20ticket

#topic backlog discussion
#info go over our backlog and discuss and determine priority
```
Go thru each ticket one by one

### Put all topics for discussion under here

Here we will discuss any apprentice questions, try and match up people
looking
for things to do with things to do, progress, testing anything like that.

### Learn about some application or setup in infrastructure

(This section, each week we get 1 person to talk about an application or
setup that we have. Just going over what it is, how to contribute, ideas
for improvement, etc. Whoever would like to do this, just add the i/nfo in
this section. In the event we don't find someone to teach about something,
we skip this section and just move on to open floor.)
```
#info
```
### Meeting end stuff
```
#topic Open Floor

#endmeeting
```

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

Turning off keys.fedoraproject.org

[Stephen John Smoogen]

Fedora has been part of an GPG sks service[1] for a number of years running
off of keys.fedoraproject.org. Last year, there were a number of attacks
made on the service which due to its 'write-only' nature makes it
impossible to clean up [2] [3]. When the attacks came up, and it was clear
it was not easily fixable, we moved keys to a proxy only mode. However this
mode has not been too stable and caused other issues.

Fedora Infrastructure has tried to figure out ways to run a service
replacement, but currently has not found one which we can with the
resources we have available. We plan to turn off and decommission
keys.fedoraproject.org on 2020-02-10.

We currently recommend people to use https://keys.openpgp.org/ which offers
lookup capabilities.

[1] https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home
[2] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
[3]
https://www.zdnet.com/article/openpgp-flooded-with-spam-by-unknown-hackers/

-- 
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 Meeting Agenda 2020-01-30

[Stephen John Smoogen]

## Preamble
The infrastructure team will be having its weekly meeting tomorrow,
2020-01-30 at 15:00 UTC in #fedora-meeting-1 on the freenode network.
We have a document at https://board.net/p/fedora-infra
Please try and review and edit that document before the meeting and we
will use it to have our agenda of things to discuss. A copy as of today
is included in this email.

If you have something to discuss, add the topic to the discussion area
with your name. If you would like to teach other folks about some
application or setup in our infrastructure, please add that topic and
your name to the learn about section.

## Introduction
We will use it over the week before the meeting to gather status and
info and discussion items and so forth, then use it in the irc meeting
to transfer information to the meetbot logs.

### Meeting start stuff
```
#startmeeting Infrastructure (2020-01-30)
#meetingname infrastructure
#chair nirik pingou relrod smooge tflink cverna mizdebsk mkonecny
abompard bowlofeggs
#info Agenda is at: https://board.net/p/fedora-infra
#topic aloha
```

### Determine who the next chair is
#topic Next chair
#info magic eight ball says:
#info  2020-01-30 - cverna
#info  2020-02-06 - mkonecny

### Let new people say hello
```
#topic New folks introductions
#info This is a place where people who are interested in Fedora
Infrastructure can introduce themselves
#info Getting Started Guide:
https://fedoraproject.org/wiki/Infrastructure/GettingStarted
```

### Status / Information / Trivia / Announcements

(We put things here we want others on the team to know, but don't need
to discuss)
(Please use ```#info (the thing - your name)```

```
#topic announcements and information
#info ops folks are trying a 30min ticket triage every day at 19UTC in
#fedora-admin
#info the following people will be AFK for Devconf: cverna, pingou,
mkonecny, mboddu, nirik, relrod, nils
#info the following people will be AFK for FOSDEM: pingou, mboddu
#info Anitya (release-monitoring.org) 0.18.0 is now deployed to production
#info https://xkcd.com/2261/
#info most of staff has been in Brno at DevConf
```

### Things we should discuss

We use this section to bring up discussion topics. Things we want to talk about
as a group and come up with some consensus /suor decision or just brainstorm a
problem or issue. If there are none of these we skip this section.
(Use ```#topic your discussion topic - your username)```
```
#topic Oncall
#info https://fedoraproject.org/wiki/Infrastructure/Oncall

#info cverna is oncall 2020-01-23 -> 2020-01-30
#info bowlofeggs is oncall 2020-01-30 -> 2020-02-06
#info  is oncall 2020-02-06 -> 2020-02-13

## .oncalltakeeu .oncalltakeus

#info Summary of last week: (from current oncall )
#info

#topic Monitoring discussion [nirik]
#info https://nagios.fedoraproject.org/nagios
#info Go over existing out items and fix

#topic Tickets discussion [nirik]
#info https://pagure.io/fedora-infrastructure/report/Meetings%20ticket


#topic ResultsDB Ownership Going Forward
#link https://pagure.io/fedora-infrastructure/issue/8415 (revist post DevConf)

#topic backlog discussion
#info go over our backlog and discuss and determine priority
```
Go thru each ticket one by one

### Put all topics for discussion under here

Here we will discuss any apprentice questions, try and match up people looking
for things to do with things to do, progress, testing anything like that.

### Learn about some application or setup in infrastructure

(This section, each week we get 1 person to talk about an application
or setup that we have. Just going over what it is, how to contribute,
ideas for improvement, etc. Whoever would like to do this, just add
the i/nfo in this section. In the event we don't find someone to teach
about something, we skip this section and just move on to open floor.)
```
#info
```
### Meeting end stuff
```
#topic Open Floor

#endmeeting
```
-- 
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