FBR (?) STAGING: Support Fedora ELN for Greenwave
From 6c9da110bdb380beb0192d4188725e91d2dc3549 Mon Sep 17 00:00:00 2001
From: Stephen Gallagher
Date: Thu, 23 Apr 2020 16:23:00 -0400
Subject: [PATCH] STAGING: Support Fedora ELN for Greenwave
Signed-off-by: Stephen Gallagher
---
roles/openshift-apps/greenwave/templates/fedora.yaml | 12
1 file changed, 12 insertions(+)
diff --git a/roles/openshift-apps/greenwave/templates/fedora.yaml b/roles/openshift-apps/greenwave/templates/fedora.yaml
index a927ae500a1c8a3d9ab2a56542d7ebea74de82dd..68738dce40900ef081003af13f3fe0bfe66dd90b 100644
--- a/roles/openshift-apps/greenwave/templates/fedora.yaml
+++ b/roles/openshift-apps/greenwave/templates/fedora.yaml
@@ -52,10 +52,13 @@ rules:
--- !Policy
id: "taskotron_release_critical_tasks_for_testing"
product_versions:
- fedora-rawhide
+{% if env == 'staging' %}
+ - fedora-eln
+{% endif %}
- fedora-33
- fedora-32
- fedora-31
- fedora-30
- fedora-29
@@ -67,10 +70,13 @@ rules:
--- !Policy
id: "taskotron_release_critical_tasks_for_stable"
product_versions:
- fedora-rawhide
+{% if env == 'staging' %}
+ - fedora-eln
+{% endif %}
- fedora-33
- fedora-32
- fedora-31
- fedora-30
- fedora-29
@@ -131,10 +137,13 @@ rules: []
--- !Policy
# openQA policies
id: "openqa_release_critical_tasks_for_testing"
product_versions:
- fedora-rawhide
+{% if env == 'staging' %}
+ - fedora-eln
+{% endif %}
- fedora-32
- fedora-31
- fedora-30
- fedora-29
decision_context: bodhi_update_push_testing
@@ -145,10 +154,13 @@ rules:
--- !Policy
id: "openqa_release_critical_tasks_for_stable"
product_versions:
- fedora-rawhide
+{% if env == 'staging' %}
+ - fedora-eln
+{% endif %}
- fedora-32
- fedora-31
- fedora-30
- fedora-29
decision_context: bodhi_update_push_stable
--
2.26.0
___
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: Fedora Hubs brainstorming meetup?
- Original Message - From: David Gay d...@redhat.com To: Fedora Infrastructure infrastructure@lists.fedoraproject.org, Ryan Lerch rle...@redhat.com, Stephen Gallagher sgall...@redhat.com, Kushal Das k...@redhat.com, Chris Roberts chrob...@redhat.com, Amita Sharma amsha...@redhat.com, Matthew Miller mat...@redhat.com, Pierre-Yves Chibon pchi...@redhat.com, Laura Novich lnov...@redhat.com, Remy DeCausemaker rdeca...@redhat.com Sent: Thursday, May 7, 2015 10:44:26 AM Subject: Fwd: Fedora Hubs brainstorming meetup? Hi, sending this along to folks listed on the PiratePad, and the infra list, as well. At this point, this is looking like something that will happen next week. However, only three people have filled out the WhenIsGood so far. This was the first I saw of the WhenIsGood request. I'd like to be there if possible, yeah. *responds* ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Ask Fedora being badgered by spam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/2014 10:29 AM, Kevin Fenzi wrote: On Thu, 29 May 2014 06:11:36 -0400 Rahul Sundaram methe...@gmail.com wrote: Hi FWIW, I have deleted well over a dozen accounts and hundred questions in the last few days and several new user accounts even after this mail was posted. It is likely a single persistent spammer and perhaps scripted. Some serious measures are needed at this point since some of us constantly deleting users accounts and postings just isn't scalable. Yeah, I have blocked a number of their accounts and deleted rafts of posts too. ;( Possible options * Block by IP address I looked at this a few days ago, and it didn't seem they were coming from any IP in particular. :( I can look again tho. * Limit open id signs to just Fedora accounts We could. How much outcry would this get from the people that use other providers though? I think there's lots of people using google/etc... When I looked at a few of this spammers accounts they seemed to all be yahoo? I'd be perfectly fine blocking yahoo auth, but then they could just use another one. * https://pypi.python.org/pypi/stopforumspam/ * https://www.djangopackages.com/grids/g/anti-spam/ Would need packaging and testing... If they're all coming in through Yahoo, then disabling that would be a stopgap at least until we can find a more effective anti-spam solution. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOHTwgACgkQeiVVYja6o6PRcgCfVedbZh1Nq9p4OYZe64+6p4jV wvUAni3aUtcUbVQaUz3CD4JXsG4aVmqC =ggBg -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: I have to log in twice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/04/2014 11:37 AM, Robert Mayr wrote: Il 04/mar/2014 17:17 Miro Hrončok mhron...@redhat.com mailto:mhron...@redhat.com ha scritto: When I login to e.g. trac, I see only attached image and I am not redirected to the app, I have to go back and do it for ssecond time. It happens quite a lot. Is that a bug? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- websites mailing list websi...@lists.fedoraproject.org mailto:websi...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/websites Yes it's a known issue, it depends also on the browser you use. There was a fix a few days ago but it didn't worked as it should. I'm copying in the infra team here to have a look on this again. Thank you Miro. See you Robert I spoke to Patrick about this yesterday. Once you have hit this, on some browsers (at least Chrome, probably others), you will need to remove fedoraproject.org cookies before things will go back to normal. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMXOFwACgkQeiVVYja6o6PLeQCcCFbnapTP1UoSvYdzSphlEYjQ nKIAoJnqA6ydotY0RFlpr/oJfI6Bh01I =PFmg -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Admin of Copr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/29/2013 08:20 PM, Nick Bebout wrote: I would be glad to help. nb You can count me in as well. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLFg3EACgkQeiVVYja6o6NweQCeJkw5waRzJs3hmmCewXhmiBWI 1VkAoKPWl5vl0aJ9plTmx5ZqrGKuxanC =fNOu -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: 2014 dreaming
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/19/2013 09:48 PM, Toshio Kuratomi wrote: On Fri, Dec 20, 2013 at 07:43:50AM +0800, Christopher Meng wrote: Is it possible to use gitlab to replace cgit? I would say no. gitlab would really be more of a trac replacement. cgit is a lightweight web frontend for git repositories. Two different purposes. Also, gitlab does not have the ability to retrieve git blobs by hash (currently), so it would make it impossible for us to use tools like ReviewBoard without keeping a local clone up to date. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlK0RuIACgkQeiVVYja6o6PGlQCgmuK/gBBYtK94NHn2rb8M9pUH QlIAn3Kb841rUuZrbLA7Nz8OGbQgX4/n =xClQ -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Some questions around coprs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/04/2013 03:52 PM, matt_dom...@dell.com wrote: FESCo would have to change their rules prohibiting shipping non-official repo files in the main repository. Assuming that political battle is successful… We (FESCo) seemed to be fairly agreed on that point (wrt COPR) if we can solve the technical issues that Kevin brought up in this thread. I think signing must be done by the copr creator (personally). As each copr repo is independently timed and created, I’d be OK with a frequently scheduled rsync that pulls all coprs and drops them into the master mirrors, for downstreams to pick up at will. Probably in the pub/alt tree please. That will minimize the # of mirrors that are looking for them too. We don't want to do ALL COPRs. There will definitely be a hierarchy. At the FESCo meeting, we had the general sense that we would only want to allow a limited set that FESCo has approved be available in the main repo. I think the purgatory problem is one for each copr to decide. Some may be bleeding edge, some may be backports of good stuff that changes infrequently. I’d say _/no/_ to the meta-repo, for exactly the above reasons, and so 2 coprs may conflict and/or compete. That’s their right. Exactly; hence the need for a FESCo approval to elevate one repo to acceptable to have a repo-providing RPM in the main Fedora repositories. -- Matt Domsch Distinguished Engineer, Director Dell | Software Group -Original Message- From: infrastructure-boun...@lists.fedoraproject.org [mailto:infrastructure-boun...@lists.fedoraproject.org] On Behalf Of Kevin Fenzi Sent: Wednesday, December 04, 2013 2:20 PM To: infrastructure@lists.fedoraproject.org Subject: Some questions around coprs So, at todays fesco meeting there was some discussion about coprs. http://meetbot.fedoraproject.org/meetbot/fedora-meeting/2013-12-04/fesco.2013-12-04-17.59.log.html#l-52 In particular some folks want to be able to ship copr repo files in the main Fedora repository. This would allow users to easily install software from there without having to discover how to enable it. However, copr packages are not signed or mirrored currently. So, this brings up thoughts around if we can somehow sign them, and how we could mirror them, or even if we want to go down this road at all. (as it seems like not a use case copr's was designed for anyhow). So: 1. Do we even want to persue this? 2. If so, do we have any ideas how signing copr packages could work? 3. Mirroring doesn't seem like it would be that hard, just rsync off the repos and push them out in our regular mirroring system. Could be a fair bit of churn tho, and there's no set schedule, so we would have to decide on frequency, etc. 4. If coprs moves to being inside koji, could we at that point have a better time with these needs? 5. Perhaps we could propose some kind if pergatory type setup between coprs (experemental, just builds, may set your house on fire, may update incompatibly every day) and fedora repository packages (with all the updates guidelines, reviews, etc). Thoughts? comments? Possibly related to this: I wonder if copr could grow a 'meta repo' that has all the repodata of all existing coprs. Then you could just enable one thing and be able to install any coprs? kevin ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKgdUYACgkQeiVVYja6o6PQsACfdcxttqo0tFG07TYDjUNP4YCv 5w0An1KlbvjEZLxSWU5H0pG6Go97EgZz =26mQ -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Some questions around coprs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/04/2013 04:03 PM, Stephen John Smoogen wrote: On 4 December 2013 13:20, Kevin Fenzi ke...@scrye.com mailto:ke...@scrye.com wrote: So, at todays fesco meeting there was some discussion about coprs. http://meetbot.fedoraproject.org/meetbot/fedora-meeting/2013-12-04/fesco.2013-12-04-17.59.log.html#l-52 And then you run into the politics of who gets shipped and who doesn't and if you don't ship all of them then how do you add new ones that get added and ones that go away.. Too much cart, too little horse. As discussed at the FESCo meeting, this should be entirely up to FESCo. My proposal would be that COPR repository owners would petition FESCo (via a ticket), it would get voted on or we'd come back and tell them what changes they'd need to make before it would be accepted (e.g. Please don't downgrade glibc, etc.) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKgdawACgkQeiVVYja6o6OygQCfZCxV7xfrDzU/4A4ku1YdeqQ8 3BUAnjUV0v7ZOo+VSJvujmf3q7nwbqUo =X9Tu -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Where to keep the badges repo?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/17/2013 02:50 PM, seth vidal wrote: On Mon, 17 Jun 2013 11:40:35 -0700 Toshio Kuratomi a.bad...@gmail.com wrote: On Mon, Jun 17, 2013 at 01:45:09PM -0400, Ralph Bean wrote: I spent some time last week learning ansible and setting up the new badges-backend01.stg. There's a daemon that runs there that reads in a number of yaml files. Each one defines a badge and a set of rules that must pass for the badge to be automatically awarded to a contributor (based on fedmsg activity). Up to now, I've been keeping all these badges in the ansible repo; ansible copies them into /usr/share/badges on the managed node. You can find the ones I have so far here: http://infrastructure.fedoraproject.org/infra/ansible/roles/badges-backend/files/badges/ I need to get them out of the ansible repo. There's going to be too many of them, and we're going to be iterating on them and changing them often. I was thinking of creating another git repo on lockbox at /git/badges/ for this. In the longrun though, we want contributors from every corner of the community to contribute new badge ideas (come up with some artwork, make their own yaml definition -- and make it real). We'll have a process for debating and vetting new badges. GitHub's pull request work flow could be a good fit here. It would however set a new precedent for our degree of integration with gh.com. Any thoughts? I agree with the implied nervousness towards this degree of integration. Repository-wise, I think we need a public repository so, although lockbox can have public repos, something already doing public repos is probably better (fedorahosted, for instance). Workflow-wise, it sounds like comps.xml has similar requirements. That's hosted at fedorahosted and changes are discussed o nthe mailing lists. So it's possible to shoehorn that into our existing infrastructure. I bet that both comps.xml and badges would be more efficient on github, though. The problem with both gh and hosted for comps or for this is that it means those resources need to 'freeze' when we freeze. That's rotten, imo, for comps alone - but if we needed to freeze and were counting on gh being up right before a release? It would be painful to have that dep hung up that way. I think we cannot rely on external services and I'm not even enamored of relying on fedorahosted b/c, ostensibly, it doesn't freeze. It doesn't freeze, but thanks to git we *can* just lock it to a commit ID. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHAV08ACgkQeiVVYja6o6MyjwCfaI5miePnEXgaSsonGH0DeOaV TNkAnRUxnsOzKZoVnWjMPkksxwxIH8wg =zE6Z -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: 2factor auth
On Tue, 2011-10-18 at 15:36 -0700, Toshio Kuratomi wrote: On Tue, Oct 18, 2011 at 08:19:28AM -0400, Stephen Gallagher wrote: It might be worth revisiting the discussion about a potential FAS3 built atop the upcoming FreeIPA v3 (which will have this support). We discussed on IRC the blockers for this. Hopefully at FUDCon the immediately known blockers will have been resolved and we'll get a demo of what a system with freeipa could look like. Once question that popped into my mind right now is will we have the ability to specify that different groups and different users have different requirements/access methods? In the talks that we've had so far... it looks like we're desiring something similar to this: sysasmin-main and possibly sysadmin* = Mandatory two factor. Password + any supported otp solution (yubikey or some otp via android). all others non-mandatory two-factor. Same technologies as above. User selects whether to make two-factor mandatory or not. May need to allow single factor to login at times in the web application as well -- this is a big unknown. If someone loses half of their two-factor auth, how are we going to reset their account. For sysadmin-main, we figure the pool is small enough that we can call each other or otherwise arrange some way to verify that the person is really who we think they are. So it would be manually verify and manually reset. For other Fedora groups, the knowledge we have of a person and their connections to others inside Fedora Infrastructure is much less. It may be that for some of those groups we allow them to reset their own 2nd factor auth with only a single factor (after all, we're allowing their colleagues to use only a single factor all the time) We've been talking about how to handle this. We haven't really touched on the idea of requiring a different level of assurance for different applications, but we are aware of the lost token problem. The current plan is for us to store an attribute with the user's challenge requirements in the user's LDAP entry (with appropriate ACLs to make it difficult for an attacker to learn). Right now we only have plans for a single method, but if you think that method-application mappings are necessary, please speak up (and preferably help propose a mechanism to store that information in LDAP). As for lost token, the idea would be that the admin would be able to reset the user's login requirements to password or similar until a new token can be mailed out. (Leaving it up to the admin to perform proper verification that the token was actually lost vs. a social-engineering attempt). signature.asc Description: This is a digitally signed message part ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: 2factor auth
On Tue, 2011-10-18 at 08:19 -0400, Stephen Gallagher wrote: On Tue, 2011-10-18 at 00:27 -0400, seth vidal wrote: On Mon, 2011-10-17 at 22:50 +0100, Tristan Santore wrote: On 17/10/11 22:11, seth vidal wrote: The biggest problems with the yubikeys is: It might be of interest to this mailing list to be made aware of some work being done jointly between the SSSD, FreeIPA, MIT Kerberos and Yubico development teams. The plan is for SSSD and FreeIPA to support (via extensions made to MIT Kerberos) Yubikey as a mechanism for acquiring a Kerberos TGT from FreeIPA. We have a proof-of-concept already available (demonstrated at this past Red Hat Summit) and work is ongoing on this. It might be worth revisiting the discussion about a potential FAS3 built atop the upcoming FreeIPA v3 (which will have this support). ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure Replying to myself: I want to draw attention to the https://fedorahosted.org/AuthHub/ project and diagrams there. We're planning to support multiple pluggable OTP methods, which would make it possible to A) roll it out gradually and B) make it possible to select which approach works better for a particular contributor (e.g. Yubikey vs. smartphone app). I'd like to suggest that Fedora Infrastructure become involved in the AuthHub project directly and help guide this effort. signature.asc Description: This is a digitally signed message part ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Hosted plans
On Mon, 2011-08-08 at 10:54 -0600, Kevin Fenzi wrote: Hosted01 has the following items on it: * apache/httpd gitweb other scm web trac mailman archive http access source downloads (tar.gz, etc) loggerhead reviewboard I've been talking with Mike McGrath about ReviewBoard. I really want to get ReviewBoard off of Hosted, as the performance is incredibly poor and the FAS integration causes problems that I have not had a chance to identify. Furthermore, starting with ReviewBoard 1.5.6 (being released upstream soon), I've submitted patches to make it possible to use ReviewBoard against any FedoraHosted git repository remotely. The main reason that ReviewBoard was located on FedoraHosted to begin with is because it needed direct access to the git repositories. So I'd like to move ReviewBoard to one of the app servers or into an OpenShift instance. Of course, we still have issues regarding the FAS integration. For reasons I've still not been able to nail down, it causes us to lose access to the server. I was hoping to switch over to using OpenID with the release of ReviewBoard 1.6, but unfortunately they've deferred that feature until 1.7. So I'm proposing the following options: 1) Move our existing ReviewBoard instance to one of the app servers. This will significantly improve the performance and responsiveness, but we'll still have no email notification support (due to as-yet-unknown negative interaction with FAS integration) 2) Move ReviewBoard to an app server and drop integration with FAS and allow standard enrollment for users, be they Fedora users or not. This will solve the performance and email issues, but results in a server running on Fedora systems that is not using Fedora accounts. Also I'm not sure we can maintain the existing review histories for the few projects currently using the system. 3) Turn ReviewBoard into a turnkey OpenShift virtual instance and allow any Fedora Hosted project to spin one up. This instance would use standard enrollment (rather than FAS integration, which is impossible outside the Infra firewall). Each project could have its own complete instance to maintain on its own. Upsides: less work for Fedora Admins, support for email and better performance. Downsides: no centrally-managed user accounts and projects need to do more of the maintaining of the system themselves. I'm all ears for a fourth (or fifth...) option. signature.asc Description: This is a digitally signed message part ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: retiring blogs.fedoraproject.org on 2011-07-01
On Tue, 2011-05-31 at 09:58 -0600, Kevin Fenzi wrote: We will be happy to help any user wishing to transition their blog to another service. We will provide web site redirects and dumps of their posts. I've transferred my blog to sgallagh.wordpress.com. While I don't have a great number of entries on my blog, I do have several that are linked to from a number of places, and I would much appreciate having redirects available. signature.asc Description: This is a digitally signed message part ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Updates for 2010-10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/10/2010 03:20 PM, Stephen John Smoogen wrote: Ok it looks like there have been updates to Django/Turbogeats in EPEL/EPEL-test. This is usually a lot of tears and gnashing of teeth when in the various sub-apps and I would like to make sure we test them thoroughly in staging before doing any updates on main. So we will be only updating security packages which are fairly few this time. For what it's worth, the Django update was a bugfix-only point release from 1.1.1 to 1.1.2. I deployed it on Hosted for ReviewBoard with no regressions. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyy+hMACgkQeiVVYja6o6MnXQCbB7w/JHIMSczrchIZCxH5tMXf lVMAoJvvILnxlZi7l04dzYMbDFH6BESi =mzgn -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
[PATCH] Update ReviewBoard config
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Because Fedora's FAS auth requires us to make a copy of the INSTALLED_APPS and MIDDLEWARE_CLASSES in ReviewBoard's settings_local.py, we need to manually update this list whenever ReviewBoard adds a new option to its primary settings.py in these tuples. In this case, they added 'djblets.log' and 'reviewboard.admin.middleware.X509AuthMiddleware' - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkykgtwACgkQeiVVYja6o6N/wACfXollnL7N7ctD2GxDQWEhMd3s /8AAn2/ABhS5V5aNaseumlsgagvUo/ht =4qD1 -END PGP SIGNATURE- From 4fd3fb23f6d005d8cdd24d788ba0fb6923ee4b4d Mon Sep 17 00:00:00 2001 From: Stephen Gallagher sgall...@puppet01.phx2.fedoraproject.org Date: Thu, 30 Sep 2010 12:24:43 + Subject: [PATCH] Update ReviewBoard config We were missing entries for the admin dashboard log reader and the X509 auth middleware --- .../reviewboard/templates/settings_local.py.erb|2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/modules/reviewboard/templates/settings_local.py.erb b/modules/reviewboard/templates/settings_local.py.erb index 3d2bbbc6a72747f204cb00976aee2ec127e56b45..5728621a13457cb235c5fb23e8632616850f95ea 100644 --- a/modules/reviewboard/templates/settings_local.py.erb +++ b/modules/reviewboard/templates/settings_local.py.erb @@ -42,6 +42,7 @@ INSTALLED_APPS = ( 'django.contrib.sessions', 'djblets.datagrid', 'djblets.feedview', +'djblets.log', 'djblets.siteconfig', 'djblets.util', 'djblets.webapi', @@ -75,4 +76,5 @@ MIDDLEWARE_CLASSES = ( 'djblets.log.middleware.LoggingMiddleware', 'reviewboard.admin.middleware.CheckUpdatesRequiredMiddleware', +'reviewboard.admin.middleware.X509AuthMiddleware', ) -- 1.5.5.6 0001-Update-ReviewBoard-config.patch.sig Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
[PATCH] Create SRPM repository entry in new_repo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When creating new fedorapeople yum repos, we should also include a link
to the SRPM repo.
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxsJO8ACgkQeiVVYja6o6PvWACfSx3DllXDVPWhOV3QVfzIdCjt
6W0AoIorHe3BnpH5qGZYXc3T3ysAROVb
=1w6l
-END PGP SIGNATURE-
From cd9c720c2f9877335a621a0a94ae7e1d530ef70c Mon Sep 17 00:00:00 2001
From: Stephen Gallagher sgall...@puppet01.phx2.fedoraproject.org
Date: Wed, 18 Aug 2010 15:50:26 +
Subject: [PATCH] Create SRPM repository entry in new_repo
---
modules/scripts/files/new_repo | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/modules/scripts/files/new_repo b/modules/scripts/files/new_repo
index 9bb4f2b0af2f9cda76cd2f0cc32c60bcd29fe521..da0175222a7ac33755f7a56ef3982a5eb2956d74 100755
--- a/modules/scripts/files/new_repo
+++ b/modules/scripts/files/new_repo
@@ -137,12 +137,20 @@ name=%(description)s
baseurl=%(repo_base_url)s/%(group)s/%(repo_name)s/%(repo_type)s-$releasever/$basearch/
enabled=1
skip_if_unavailable=1
-gpgcheck=0''' % { 'repo_name' : repo_name,
-'repo_type' : repo_type,
-'description' : description,
-'group' : group,
-'repo_base_url': REPO_BASE_URL })
-file.close()
+gpgcheck=0
+
+[%(repo_type)s-%(repo_name)s-source]
+name=%(description)s - Source
+baseurl=%(repo_base_url)s/%(group)s/%(repo_name)s/%(repo_type)s-$releasever/SRPMS
+enabled=0
+skip_if_unavailable=1
+gpgcheck=0
+''' % { 'repo_name' : repo_name,
+'repo_type' : repo_type,
+'description' : description,
+'group' : group,
+'repo_base_url': REPO_BASE_URL })
+file.close()
if __name__ == '__main__':
print
print
--
1.5.5.6
0001-Create-SRPM-repository-entry-in-new_repo.patch.sig
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [PATCH] Create SRPM repository entry in new_repo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/18/2010 03:08 PM, Mike McGrath wrote: On Wed, 18 Aug 2010, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/18/2010 02:28 PM, Mike McGrath wrote: This seems ok to me. Don't forget to update the wiki :) No wiki update needed. This doesn't change any file locations, it just allows yumdownloader --source to work with things as they are. My next patch (when I get to it) to allow debuginfo-install to work will require wiki changes. Ahh, fancy. Well it looked fine to me, feel free to push it whenever, the pre-release freeze doesn't cover fedorapeople. Pushed. Thanks! - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxsMD0ACgkQeiVVYja6o6On2QCgrPzU7X8W3Sb9IDXx0rtVRFu3 M4YAoK4fdceEsoOR6U2akPFVG4AQEB/y =19zS -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
[MERGE] Handle groups more gracefully in Django
This supersedes the patch I sent earlier today. I tested this by manually modifying the user database and confirming that FAS overrode all settings I made locally, either removing or adding group memberships as appropriate. When the groups are unchanged, we will only require a single lookup into the database, as opposed to one per group the user was a member of. It also addresses a bug where users whose group membership was revoked would still appear to be a member within Django apps. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ # Bazaar merge directive format 2 (Bazaar 0.90) # revision_id: sgall...@fedoraproject.org-20100419205648-\ # 3dk1bybf81j8hho3 # target_branch: bzr://bzr.fedorahosted.org/bzr/python-fedora/python-\ # fedora-devel/ # testament_sha1: 60093b7f5710c3234061f0bf5991f5ae0604e748 # timestamp: 2010-04-19 16:56:57 -0400 # base_revision_id: tos...@fedoraproject.org-20100408181520-\ # 7mzxred8mrovqu9m # # Begin patch === modified file 'fedora/django/auth/models.py' --- fedora/django/auth/models.py 2010-03-15 23:22:05 + +++ fedora/django/auth/models.py 2010-04-19 20:56:48 + @@ -83,9 +83,29 @@ if getattr(settings, 'FAS_GENERICEMAIL', True): u.email = u._get_email() u.save() +known_groups = [] +for group in u.groups.values(): +known_groups.append(group['id']) + +fas_groups = [] for group in user['approved_memberships']: -g = _new_group(group) -u.groups.add(g) +fas_groups.append(group['id']) + +# This user has been added to one or more FAS groups +for group in (g for g in user['approved_memberships'] if g['id'] not in known_groups): +newgroup = _new_group(group) +u.groups.add(newgroup) + +# This user has been removed from one or more FAS groups +for id in known_groups: +found = False +for g in user['approved_memberships']: +if g['id'] == id: +found = True +break +if not found: +u.groups.remove(authmodels.Group.objects.get(id=id)) + u.save() return u # Begin bundle IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWdShxTgABNJ/gAVUQABZ4/// d8IOCrBgCA8t8PvYUAGNrZWm2qlVRsNDRNQIyaGgyaHqAAAIJRtR6npNqBo0GIaBoDQG mg0YjQc0xMmTRhMExNMAmAQwRgRgEUSU09Jqep7Rqh+k9JHkNTCbU0GjTBNqaACKSaaSp7ZKfkNF T2o8qbaMqZ4lP1INGTRgR6gRSCAJkCaam01JPMIKeUe0UNAeoMajREA8KZiOCkdGFZPGXDv0jDaz PQDQI4JCKbzhTjVgbI+EGEFUf75fPBC4YQysBx08cYtisoKcbNeITaYRSmNVmXtQQyKn1P7+l+8f g52FiIIn8l+02iZoHYJTBMkCfNjqFiFcVR8xXzIL4Cshknmc7aMPMkqJI8ZMt4XhTZphICFioD4E xgOVZlSAWIy5EkVAg6AUuJ3PDHbtwL7XGG6AiCOukrKDGcSHG0zIfD2c9nT3e96tXg2udHyjC+/2 3ynFLvy9nBArWyr0aqvwDu2x5PHjDB917JcKV6yOc5Hh6ypxurHpHYJ0er0HZq7RIAMBweLA9wlj ghK8LJWUxCqm1SX6MtIRKCmYetvv0UB8+a6ZmZnms07yMjCZQozODxtFa0KiUhWwS0hCn4Uo1IuJ KxTeQNpPEmS+NzchaSGmByPh/ITMuNFIhkkhWUsT3ynp4nV13xdTLOrqa4ckKkspDnow1Eg34MT1 E3HC8whzJ3PnmYCQI7TEpx0HyGmwjIKlTcJxMhvQwdIdyocNAC0gplmhVCdn3Fhnbi8pj11BQSZQ xLiZ9Teh2oU5FZn11BuQxE36aZlbTQwQ2ky+++KlhghzpXkSMzsG8xEnhwKs6iTQpD6i+5oM7yYj 2FNgkPyEsvPUcC4sN6HNoMids3mOIlxzNBJhXCWgcYMBKbbcx2HK6paBs2F4koJiVMjAK1HQoamp gQYFxRyC4qcDES0yLjlBbfcbiZhkQNXZYYlDCRmbyhkbFkcC0yJFSw1rdZnOqwVmWND9otuMi3VC hifgTEzQ7ChgZkiCAzOQ34MGM2mFR0sKUZuo7zQ2CdiUMzAo5t9oXBmbSCh+o2s0M79hFgmxDM2k xGZpQ4Xl5qalKXFrBOVhaXkjE8fqhBUT4/HykS2mpnAYus4HkhSjuQ2CSqZeY+iHawIfVgbU+Jpe hyEtY8pTK1MsMtI90EQxDWRre4ehztGtkd1hlo+852ACIU2vjlDBBAERBtxltJCYNkztYxEBlfme kofQ8V6bbYiIgztjKECa3JU16aamEoG2HmcCrvLAeho9lZ0OhBvMChebTxO1kfw24FN/b07LuDB2 DaJ/FRPSn/dp9bzqgn0OH/Xjubn7bvaaDe1onou1CFh3OmQMLrr1PbX15y4ocJWVGI0m8YmT2D9d lqmR8vgOwGA6hNoeZ9Tce4mQYn2MfhaWEHAvPty/eex9nnzqSeKk28UsIae+UgiZHSfchI5aGhM7 iBILlqh/hJcLGFAluE4ews3zEdomgqpoEm+/pNBjU5ZjQddeVgD+7L59/j5FrEdJYH9pevt+NrLj 7b+ATnOUjzjlfY1j1HRoC5gtZiWnAwtL9xvLzoKaN+zrBc0YU0AcvIm22iZ7mhI3HQm4IQriVOZd xozDFuBu4c+4c0J5d8APNxQq2OjHYZDGXElDMSXFQOswDq1ajgLywSDw2eXMdW4PK/4ieo0mI/F5 voc0FuYJLLxkZ3ZhUbUSDegnmAYfLnNRNKFhxgPxLBmTIIboII/V9p7Q3hIBIuBiwnvUjCOJYbRy D5GSnrGHpXsQn4Icjg3fYPvLerx3Xj+1e/rUePghaNiHT6Cbce5k1uLsxAZJ4gOuXR91bPoPyP2R OHNDC0MRlzE9BO3hu5x3iaECaoSUT6Ye5ygZWwKlA8/l8BKe9vZd4kqcfnCkIR4rjR0QpUuHS/N9 LeO1sd35tGG1tOx8B5O3q2tHKyJRhD98TB+aQD8shyfUXlokp2Jv6d/0EtsdH8xPMT8kLnamYHJC sIcrzlsH2oVh39xuE7VTip6v0k2t7CJofzbUdizLnMSETByRKrtP1ohyUht4u2Vjao9hA5aJuEmw XB4PB8EPxYOhmDzJdTCAG9vGGjQeLCHBD/j7hOr1ExMhghykeaEDN9cCc2AGuM/7uSnkxxsEPxvf Ro8GEJuKJnfJcu/iidKyB1Q+8IEudwuEgYgeyWYGpLCKb5LMOuHzShgUqZsxhoy7hpmTb49VPIxK gibBJiqCQRUhnG573VeAzbkPehMvGyGmRSd5W++uk1MPUianQzHg7ho1EmV56y9zDkdQSY5t9gzX IJlQxzkvNA0hDBw2THr7svxY514eb0hCt8KxvtTsTwqmqGiDeJMJVgkmv5oX/NqhZcE3uQkyYfP+ I/0JW6BLrQ7HU/+LuSKcKEhqUOKcAA== ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman
Re: RFR - A kerberos and ldap server available for participants of the SSSD test day
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/24/2010 07:48 AM, Jenny Galipeau wrote: Stephen John Smoogen wrote: On Tue, Feb 23, 2010 at 5:49 PM, James Laska jla...@redhat.com wrote: Apologies, forgot to include sgallagh and jgalipea to the initial cc list. On Tue, 2010-02-23 at 14:45 -0700, Stephen John Smoogen wrote: On Tue, Feb 23, 2010 at 2:36 PM, James Laska jla...@redhat.com wrote: A kerberos and ldap server available for participants of the SSSD test day Project plan (Detailed): We need both a kerberos and LDAP server available to test F-13 SSSDbyDefault changes. Specifically (provided by sgallagh): A couple of questions: This needs to be publicly accessible versus inside of colo Yes, this would be publicly accessible and needed only for the test day. The LDAP needs to be added/controlled by? I believe we may need to provide you with an initial data set to populate. Alternatively, we request permissions so that information can be added as we go. Stephen (cc'd) may have a preference here. I am guessing that we would be setting up FreeIPA is what is wanted? I am just trying to get an idea of what is needed and if how much are wanted from infrastructure and what will be done by people. Sorry for the many questions. FreeIPA would work, but it can be just a 389 Directory Server and a Kerberos server. As for initial data, there should be at least one user. Copying what I just sent to the Infrastructure list: On 02/23/2010 04:56 PM, Mike McGrath wrote: On Tue, 23 Feb 2010, Stephen John Smoogen wrote: On Tue, Feb 23, 2010 at 2:36 PM, James Laska jla...@redhat.com wrote: A kerberos and ldap server available for participants of the SSSD test day Project plan (Detailed): We need both a kerberos and LDAP server available to test F-13 SSSDbyDefault changes. Specifically (provided by sgallagh): A couple of questions: This needs to be publicly accessible versus inside of colo The LDAP needs to be added/controlled by? I believe they just need an external publictest server for people to hit while testing things. -Mike Yeah, the SSSD supports LDAP for identity lookups, LDAP and Kerberos as authentication providers. So we want to set up an LDAP server providing schema rfc2307 (for providing users and for doing LDAP simple bind authentication) It needs to provide access both over LDAP/TLS and LDAPS. Beyond that, we need a Kerberos KDC set up with user principals the same as those provided by the LDAP server. In a separate email thread, someone asked if FreeIPA would be acceptable for this setup. It would make an excellent second data point, but FreeIPA uses rfc2307bis for its schema, rather than rfc2307. This will require a more detailed setup for this test than the basic case. I am currently communicating with the authconfig developer to determine whether we will be able to add the rfc2307bis option in time for the Test Day. If so, a FreeIPA server would also be an excellent idea. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkuFIMsACgkQeiVVYja6o6MeUwCePg9I83SLSqnP8tEwOZbVUnqj l7wAn3QJogUsBrXuImVbZW97Y0cU4RwY =UBpv -END PGP SIGNATURE- ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
