Re: yslow website stats
On Fri, Jan 08, 2010 at 10:42:35AM -0800, Darren VanBuren wrote: > On the matter of Expires, here's what would need to be added to an > Apache config, assuming static stuff is in /srv/web/static: > > > ExpiresByType image/gif "access plus 1 month" > ExpiresByType image/png "access plus 1 month" > ExpiresByType text/css "access plus 1 month" > ExpiresByType text/javascript "access plus 1 month" > > > Of course we can tweak the times, I just made up 1 month. > Is this how Expires work? :: * Client requests fp.o/static/fedora.css * Client receives fedora.css with an Expires line of 1 month * For the next month, the client does not retrieve new versions of fedora.css. If so, we're either going to want to keep the Expires time pretty low (an hour or less) or start adding version information into all of our static resources. -Toshio pgpGuMnbQ6UMf.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Major dns issues
On Mon, Dec 14, 2009 at 09:27:18AM -0600, Mike McGrath wrote: > So I woke up today and we're still having dns issues on at least one of my > hosts. > > > Could everyone that has access please do a dig fedoraproject.org on all > their hosts and tell me if any of them cannot resolve? > Working from three US sites I have access to. -Toshio pgpU1JjWoIVHV.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
CSRF protection done!
I'd just like to say thanks to G_work, mdomsch, lmacken, ricky, ivazquez, mikem, and mbonnet. Thanks to the efforts of all of these people we have finally succeeded in adding csrf protection to all of the web apps we've coded for infrastructure[1]_. Congratulations guys on closing a security flaw that plagues other major proprietary sites [2]_ to this day! .. _[1]: https://fedorahosted.org/fedora-infrastructure/ticket/992 .. _[2]: http://www.internetnews.com/security/article.php/3849616/Facebook+Hit+With+New+CSRF+Worm.htm -Toshio pgpsg8KqA4kUP.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Is there F11/12 test boxes around?
On Tue, Nov 24, 2009 at 10:12:14PM +0530, susmit shannigrahi wrote: > > easy_install -U pysqlite > > is not working for last few hours. > > http://pastebin.com/m343eee84 > Thanks. > AFAIK, pysqlite has moved to googlecode -- if something is redirecting to pysqlite.org, then that needs to be fixed pysqlite side. In the meantime, is there a reason that yum install python-sqlite2 doesn't give you what you need? -Toshio pgpsNeBM1nT35.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Is there F11/12 test boxes around?
On Tue, Nov 24, 2009 at 09:15:32PM +0530, susmit shannigrahi wrote: > Hi, > > When I try to test TG2 apps on publictest machines, they shout about > python 2.4 and what not. > Is there a spare machine which runs python 2.6? If yes, I could use it. > Thanks. > Fedora Community is TG2 and it runs on python2.4... Is it a dep of the particular app that requires a newer python? -Toshio pgptHRFuEenax.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: introduction
On Sat, Nov 21, 2009 at 03:08:06PM -0500, pablomar wrote: > hi guys, > > my name is pablo martinez, I've been using fedora at home since version 3 > I'm C/C++ and Java programmer and I did a little of python some years ago (I > still use it for small things). I've also worked with Oracle and Pro*C > I want to collaborate as much as I can > Welcome! We do a fair amount of coding in Fedora Infrastructure creating web applications for the project. Most of that work is done in python. We're using the TurboGears1 and TurboGears2 frameworks for those. If you're interested in that we can help get you started. If you're more interested in doing some work in C++, there's a few upstream projects that would definitely benefit Fedora for getting some attention. For instance, we have been wanting to get a good open source whiteboarding tool working with Fedora so that we can make mockups, create diagrams, and make use of other pictorial things during meetings. Inkscape has the beginnings of a plugin but it needs someone to work on it to actually make it actually work. If you're interested in that, the upstream developers are quite interested in getting some help and one of the devs is willing to help get someone up to speed on what needs to be done: Blog post on getting the whiteboard plugin worked on: http://www.advogato.org/person/badger/diary/82.html The KDE SIG is another Fedora group that is in need of C++ coders. Right now we have a good group of KDE packagers but having a few more coders will let them work more closely on any bugs that occur and also help drive features upstream. If you use the KDE desktop, they'd be very happy to hear from more coders: https://fedoraproject.org/wiki/SIGs/KDE -Toshio pgpCL8cOE26vS.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
PackageDB 0.5.x branched
This is just a notice that PackageDB development is shifting to the 0.5.x branch and what that means if you have a checkout for hacking. First, the big news is that 0.5.x has been branched. We'll be working on stabilizing this with the goal of having a working version before Fedora 13 alpha (Currently scheduled for 2010-02-09). We'll have test releases on https://admin.stg.fedoraproject.org/pkgdb/ before that time. 0.4.x is in maintainance mode. There probably won't be another release off of this branch although I will be committing any hotfixes that we generate for Fedora Infrastructure to it. If you want to work with 0.5.x the command to check it out is:: bzr branch bzr+ssh://bzr.fedorahosted.org/bzr/packagedb/0.5.x If you presently have an 0.4.x branch that you'd like to switch over to the 0.5.x branch, you'll need to do:: cd 0.4.x bzr merge bzr+ssh://bzr.fedorahosted.org/bzr/packagedb/0.5.x # Take care of any conflicts bzr commit bzr pull --remember bzr+ssh://bzr.fedorahosted.org/bzr/packagedb/0.5.x # Next time you push, use --remember as well to switch the branch you push # to by default # bzr push --remember bzr+ssh://bzr.fedorahosted.org/bzr/packagedb/0.5.x If you have changes that are going to change the API, are big changes, or destabilize things, please let me know and we can decide whether there's time to push them to 0.5.x or if they should go to fedora-packagedb-devel. We will be pushing a few more planned features to the 0.5.x branch but in general, we have a schedule to hit so we need to concentrate on getting the required features stable by the deadline. There are several big new features in the 0.5.x version and a reorganization of quite a bit of the code so I'll be spending quite a lot of my time working on this. If you need me for something else, I'll be on IRC but this is just a warning that I may not be able to help with random things as much as usual. -Toshio pgpSdZMXrjnq1.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
PackageDB Update
Tomorrow, after change freeze is over, I'll be updating the PackageDB to 0.4.1. This is a bugfix release so I don't expect any problems but you never know :-) -Toshio pgpawAaTstfQq.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Change Request: Force SSL for /keys and /verify
On Mon, Nov 16, 2009 at 02:50:26PM -0500, Ricky Zhou wrote:
> Thanks to Sijis for pointing this need out.
>
> diff --git a/modules/fedora-web/files/redirects.conf
> b/modules/fedora-web/files/redirects.conf
> index a88613f..a679ebd 100644
> --- a/modules/fedora-web/files/redirects.conf
> +++ b/modules/fedora-web/files/redirects.conf
> @@ -9,3 +9,8 @@ RewriteRule ^/([^/]+/)?legal/trademarks/guidelines$
> http://fedoraproject.org/wik
>
> # Comment this out when there is a prerelease available
> #RewriteRule ^(/.*)?/get-prerelease$ $1/get-fedora [R=302]
> +
> +RewriteEngine On
> +RewriteCond %{HTTPS} off
> +RewriteRule ^/([^/]+/)?(keys|verify)$ https://%{HTTP_HOST}%{REQUEST_URI}
> [R=301,L]
> +
>
+1
-Toshio
pgpyR8eFJVcBl.pgp
Description: PGP signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: rsyncd: s/ignore unreadable/ignore nonreadable/
On Thu, Nov 12, 2009 at 11:47:46PM -0600, Matt Domsch wrote: > the syntax is actually 'ignore nonreadable'. man rsyncd.conf. > +1s? > > > diff --git a/modules/rsync/files/rsyncd.conf.secondary1 > b/modules/rsync/files/rsyncd.conf.secondary1 > index 0fbee6c..bc3c301 100644 > --- a/modules/rsync/files/rsyncd.conf.secondary1 > +++ b/modules/rsync/files/rsyncd.conf.secondary1 > @@ -4,7 +4,7 @@ dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.bz2 *.iso > *.ogg *.ogv > use chroot = false > transfer logging = false > timeout = 600 > -ignore unreadable = yes > +ignore nonreadable = yes > timeout = 3600 > read only = yes > exclude = .snapshot/ .~tmp~/ /.private/ /.private/** **/.nfs* > diff --git a/modules/rsync/files/rsyncd.conf.sync1 > b/modules/rsync/files/rsyncd.conf.sync1 > index d3a12eb..54aad56 100644 > --- a/modules/rsync/files/rsyncd.conf.sync1 > +++ b/modules/rsync/files/rsyncd.conf.sync1 > @@ -4,7 +4,7 @@ dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.bz2 *.iso > *.ogg *.ogv *.bz2 * > use chroot = false > transfer logging = false > timeout = 600 > -ignore unreadable = yes > +ignore nonreadable = yes > timeout = 3600 > read only = yes > exclude = .snapshot/ .~tmp~/ /.private/ /.private/** **/.nfs* > diff --git a/modules/rsync/files/rsyncd.conf.sync2 > b/modules/rsync/files/rsyncd.conf.sync2 > index d3a12eb..54aad56 100644 > --- a/modules/rsync/files/rsyncd.conf.sync2 > +++ b/modules/rsync/files/rsyncd.conf.sync2 > @@ -4,7 +4,7 @@ dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.bz2 *.iso > *.ogg *.ogv *.bz2 * > use chroot = false > transfer logging = false > timeout = 600 > -ignore unreadable = yes > +ignore nonreadable = yes > timeout = 3600 > read only = yes > exclude = .snapshot/ .~tmp~/ /.private/ /.private/** **/.nfs* > +1 -Toshio pgpn16ZROsWXX.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Suitability of Python for daemon processes
On Thu, Oct 29, 2009 at 12:04:08AM -0400, Ben Boeckel wrote: > Hopefully we have 2.4 as the minimum version. I'm pretty sure 2.4 is > ubiquitous > even on the enterprise-y distributions, but if we need older, we can try for > that as well. > Just a note. If you're targeting RHEL/CentOS4 as your minimum, you need to target python-2.3 as your minimum python version. -Toshio pgplAY2pBBlt5.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Suitability of Python for daemon processes
On Wed, Oct 28, 2009 at 05:08:03PM -0400, Mike McLean wrote: > On Mon, Oct 26, 2009 at 12:41 AM, Dennis Gilmore wrote: > > The daemon distinction might be wrong thing to fixate on here. There > is nothing in that distinction that should exclude python (or most any > language). I think the real factors of concern are: size, complexity, > speed, system load, robustness, and security. > By and large I agree with you. One thing further to think about is that becoming dependent on a tool written in an interpreted language means that you need to install that language on your system and may become tied to a specific version of that language. In theory, this shouldn't be worse than tying yourself to a specific C library but in practice I've found that parallel installing interpreters and their libraries is a lot less supported than parallel installing a C lib. Using python in Fedora Infrastructure probably isn't too big a deal as we have abundant python programmers here to port things forward if the main developers don't but it is something to consider with other languages or in other environments. -Toshio pgphNJhXYnri1.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Change request - Removing files
On Tue, Oct 20, 2009 at 03:47:35PM -0400, Seth Vidal wrote: > > > On Tue, 20 Oct 2009, Mike McGrath wrote: > >> I'd like to remove the following files from /srv/web/review-stats/ >> >> rm -rf tmppVPdGv tmpJYphwq tmp0OL7_T tmp_E_x5e ACCEPT.html REJECT.html >> REVIEW.html >> >> Very trivial, but we're still change frozen so 2 +1's? >> > > +1 and maybe add a tmpreaper? > +1 -Toshio pgpJeFMJS2L1p.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [CHANGE REQUEST] Open freemedia form for October
On Thu, Oct 08, 2009 at 12:11:13AM -0400, Ricky Zhou wrote: > On 2009-10-07 11:07:53 PM, Nick Bebout wrote: > > I'd like to request approval (on behalf of Susmit) to do the following > > (As outlined in the FreeMedia Infrastructure SOP): > > > > cd /puppet/modules/freemedia/files > > cp FreeMedia-form.html.orig FreeMedia-form.html > > git commit -a -m 'opening freemedia form for month `date +%B`' > > git push > > > > And a few days later, > > > > cd /puppet/modules/freemedia/files > > cp FreeMedia-close.html Freemedia-form.html > > git commit -a -m 'closing freemedia form for month `date +%B`' > > git push > > > > This is a routine activity normally done on the beginning of the month > > for a few days to allow individuals to submit requests to the freemedia > > project. > +1 > > Not a big deal, but watch out for the backticks inside of single quotes > :-) > +1 -Toshio pgpG4RXSkrBmK.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: FW: [Fedora Infrastructure] #1719: MM hotfix: crawler incorrectly creating dir entries for not up-to-date mirrors
On 10/05/2009 08:40 AM, matt_dom...@dell.com wrote: > Requesting +1s to apply this hotfix, which only affects the MM crawler. > > -- > Matt Domsch > Technology Strategist, Dell Office of the CTO > linux.dell.com & www.dell.com/linux > > > > > -Original Message- > From: Fedora Infrastructure [mailto:t...@fedorahosted.org] > Sent: Mon 10/5/2009 10:38 AM > To: mdom...@fedoraproject.org > Cc: ri...@fedoraproject.org; n...@fedoraproject.org > Subject: [Fedora Infrastructure] #1719: MM hotfix: crawler incorrectly > creating dir entries for not up-to-date mirrors > > #1719: MM hotfix: crawler incorrectly creating dir entries for not up-to-date > mirrors > -+-- > Reporter: mdomsch | Owner: mdomsch > Type: bug | Status: new > Priority: major| Milestone: Fedora 12 > Component: Web Application | Version: Production > Severity: Normal |Keywords: hotfix > -+-- > = phenomenon = > nb reported that running report_mirror would report hundreds of > directories deleted on each run. > > = reason = > crawler is creating HostCategoryDir entries for not up-to-date directories > (in fact, dirs that nb has excluded on his mirror). report_mirror then > deletes these entries. > > > = recommendation = > commit 20986e503db481d4760e6e3ea74b07863a8e1cf9 > Author: Matt Domsch > Date: Sun Oct 4 22:25:15 2009 -0500 > > crawler: don't create HCDs for directories which aren't up2date > > diff --git a/server/crawler_perhost b/server/crawler_perhost > index 9553fb8..8964c7e 100755 > --- a/server/crawler_perhost > +++ b/server/crawler_perhost > @@ -303,6 +303,9 @@ def sync_hcds(host, host_category_dirs): > if hcd.count() > 0: > hcd = hcd[0] > else: > +# don't create HCDs for directories which aren't up2date on > the mirror > +# chances are the mirror is excluding that directory > +if not up2date: continue > hcd = HostCategoryDir(host_category=hc, path=path, > directory=d) > > if hcd.directory is None: > Looks good to me +1. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New deltarpm -- who do I talk to about testing?
On 10/01/2009 11:25 AM, Bill Nottingham wrote: > Toshio Kuratomi (a.bad...@gmail.com) said: >> I have a new deltarpm package built for the rel-eng repo: >> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=1721745 >> >> I can put it into the rel-eng repository to update the servers but who >> do I talk to about testing it? We'll also need approval to brakinfra >> change freeze to deploy it once it's tested. > > If it's in rawhide, it's already being tested to produce rawhide deltas. > Cool. So is the deltarpm rpm in the releng repo: http://infrastructure.fedoraproject.org/releng/SRPMS/ just extraneous? -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
New deltarpm -- who do I talk to about testing?
I have a new deltarpm package built for the rel-eng repo: http://koji.fedoraproject.org/koji/taskinfo?taskID=1721745 I can put it into the rel-eng repository to update the servers but who do I talk to about testing it? We'll also need approval to brakinfra change freeze to deploy it once it's tested. Risk: This update affects creation of deltas between zlib compressed rpms. That should not affect F-12 except for packages which failed the mass rebuild and have not been updated since. It will affect the updates repository in previous releases where we are generating deltarpms. Reason: This update is a security fix. The previous release bundled a copy of zlib which had one unfixed vulnerability. The CVE says that it will just cause an application crash: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1849 but the CVE is also in candidate status which means it hasn't been thoroughly analyzed. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [OFF] About my collaborations.
On 09/28/2009 10:41 AM, Davi Vercillo C. Garcia wrote: > Hi, > > I'm writing this e-mail for explain why I'm away from the group, > avoiding bad speculations about my collaborations to Fedora Project. > > When I've started to try to help this team, I thought that my > knowledge was enough to do those things that you do. But I've > discovered that I need more experience and technical knowledge to do > that. > > To not leave the project, I tried to find something that I could do > better. So, I joined to Ambassadors' groups and to the Brazil > Infrastructure group. And, right now, I'm evangelizing the project for > people from communities that I participate, and helping the Brazilian > infra team with theirs web services. > > That doesn't means that I'll give up to try to help here, or leave > this group. But now, I'm preparing myself, learning more about this > project and this team, for come back and try again. > > Sorry about something that I did. > No problems! Working on Fedora Infrastructure can be a big commitment of learning as well as time. Helping the Brazilian Infrastructure group is as big a help to the project as a whole as working on the Infrastructure that we're hosting in PHX so no need to feel bad about anything :-) -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Wiki account removal needed?
On 09/23/2009 01:34 PM, Jon Stanley wrote: > On Wed, Sep 23, 2009 at 4:14 PM, Paul W. Frields wrote: > >> Looks like the user "Georgia10" just inserted spam on that page. >> Aiyiyi. > > What's our procedure for deleting/disabling a rogue FAS account? It > appears that the account in question was just created today, probably > for the express purpose of spamming the wiki and then disappearing. I > would like to think that only a human could create an accounts, > there's a variety of steps involved. But maybe some sort of CAPTCHA > on the signup page could reduce this in the future? > We added a captcha last week so this is definitely a person or smarter than average bot: https://admin.fedoraproject.org/accounts/user/new -Toshio ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Developers and sysadmins: Config settings in wsgi scripts
On 09/22/2009 05:27 PM, Mike McGrath wrote: > > We might want to send these suggestions to upstream docs > as well, certainly their example page :: cough cough :: :) > Do you remember where you got the examples from? > Toshio, can you think of any reason putting variables like this in the > wsgi script to be a good thing? > If it's configurable and you already have a config file then putting everything into the config file is how I'd design an app. it might be good to use as a teaching tool: you don't want to tell someone to edit their config file with X, then edit their wsgi file with Y so you put it all in a single file but then I'd make a prominent note in the documentation that using the config file is the way to go when the app has been tested and needs to be deployed. -Toshio ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Developers and sysadmins: Config settings in wsgi scripts
Due to some bad examples on how to port code to wsgi, pretty much all of
our apps put configuration information into the wsgi scripts that
startup our apps. This is bad practice and we should stop now. The
reasons this is bad:
* There should be only one place that a config is set.
* Config should live in files that rpm knows are marked %config.
Otherwise, when a TG1 application's rpm is updated the application will
be using its own version of the configuration until the next puppet run.
Case study:
Today I made some changes to the config files of all of our TG1
applications via puppet. The config changes had the desired effect in
almost every case except FAS. After several hours of debugging, I found
that a configuration variable wasn't set to what it should be according
to the config file. Intuition hit and I found that the wsgi script was
overwriting that particular variable.
To fix this, I looked in modules/fas/files/fas.wsgi and found all of the
lines like::
turbogears.config.update({'global': {'server.environment': 'production'}})
I made sure that those lines were reflected in
modules/fas/templates/fas-prod.cfg.erb::
server.environment = 'production'
Then committed those changes. I then made a patch for the upstream code
and applied it (could also open a bug report if you don't have commit)
so that other people using FAS know that this is bad practice and
shouldn't continue.
Wash, rinse, and repeat for pkgdb, bodhi, elections, and mirrormanager.
Just letting you all know that if you think you have to check a wsgi
script into puppet, chances are you should tell the developer or
packager should be making changes to the code so that it goes into the
config file instead.
-Toshio
signature.asc
Description: OpenPGP digital signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
TG1/Cherrypy config change to make redirects more robust
mirrormanager uses the TurboGears raise redirect('/new/url') idiom
heavily. Today we found that whenever such a redirect was occurring in
staging, the users browser would end up at the production mirrormanager
site instead of staging. mmcgrath traced this to cherrypy creating URLs
like this:
http://admin.stg.fedoraproject.org/mirrormanager/ instead of like this:
https://admin.stg.fedoraproject.org/mirrormanager/
When the http:// URL goes back to the server, the server rewrites it as
an https:// URL. Due to the way staging works, that ended up being
https://admin.fedoraproject.org instead of admin.stg.
This problem also affects production -- it's just that it isn't as
apparent there. In production we end up doing two requests instead of
one -- the first one requests the http:// URL. Then apache tells the
client to redirect to https:// and the second request is made. This
also has the potential to return information to the server over http://
instead of https://. Although we haven't found a case where we'd get to
that in a way that would reveal sensitive information yet (it has to be
a specific controller method where sensitive data is being passed
through a redirect() call) we want to close this potential for
unpleasant surprises.
Luckily, there's a quick config change that makes this problem go away:
base_url_filter.on = True
base_url_filter.base_url = "https://admin.fedoraproject.org/APPNAME";
base_url_filter.use_x_forwarded_host = False
(substitute "admin.stg" for "admin" if you're deploying to staging.)
.on Turns on the base_url filter in cherrypy. Because we're deploying
on one domain anyhow, this is on for almost all of our configs.
.base_url manually specifies the base_url to use with the app. This
gets substituted into redirects as the scheme, host, and initial path.
.use_x_forwarded_host is the unexpected one. This was set to True on
almost all of our apps before. When True, it tells cherrypy to
construct the redirect URL from the X_FORWARDED_FOR header sent by the
apache proxy instead of using the manually specified base_url. The
X_FORWARDED_FOR header contains the host that is being forwarded to the
proxy. It's combined with the scheme (http or https) that cherrypy is
serving. Since we're serving http from the app servers (https is on the
proxies only), that means the constructed urls use http. The algorithm
behind .use_x_forwarded_host is simply making assumptions that aren't
true in our environment. We have to set it False.
I've just deployed a config update to elections, bodhi, mirrormanager,
pkgdb, and fas that makes these changes. If I've missed any apps let me
know or update the config in puppet yourself.
Thanks,
Toshio
signature.asc
Description: OpenPGP digital signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Licensing policy for apps developed by Fedora Infrastructure now in effect
On 09/03/2009 11:38 PM, Karsten Wade wrote: > On Thu, Sep 03, 2009 at 02:17:44PM -0700, Toshio Kuratomi wrote: >> >> At last week's meeting we made a decision about which licenses would >> best fit our needs. The results are recorded here: >> https://fedoraproject.org/wiki/Infrastructure_Licensing > > I don't see any listing of content licenses. Other than what you put > on the wiki that is covered by that license (soon to be CC BY SA), > have you thought about specifying what you license content under? > For content inside of apps/libraries (Like the documentation for python-fedora http://fedorahosted.org/releases/p/y/python-fedora/doc/ generated from the tarball) I would think it would follow the app's licensing. If you can think of good reasons to put it under a different license, we should talk about it. (Note that parts of the documentation there are extracted from the source. Not sure if that affects things). For content on the wiki we're covered by the license for the whole wiki. For content like CSI, I don't think we had thought about it. I would lean towards going with the license that docs uses. mmcgrath has been the most prolific in that area, though. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Licensing policy for apps developed by Fedora Infrastructure now in effect
Over the past few months, Fedora Infrastructure has been discussing having a consistent set of licenses for applications and scripts we create for Fedora. The goals of doing this were to * Be able to share code among the various programs that we write. * Not have our libraries force a specific license on the apps that we write. * Not have conflicting licenses between our apps and our libraries * Have a clear understanding of the steps we must take whenever we want to move code from an application under one license to a library under a different one. * Protect the code we write from being taken proprietary (note, this is not the same for every author. Mirrormanager, for instance, is under the MIT/X11 License). * Be able to stay compliant with licenses within our production, staging, and publictest environments At last week's meeting we made a decision about which licenses would best fit our needs. The results are recorded here: https://fedoraproject.org/wiki/Infrastructure_Licensing The basics are: * license code that is meant to be used as a library as LGPLv2+. * license code that's meant to be used as an application as GPLv2+. * If we want to write something and use another license we should discuss it to figure out how it's going to impact us and whether there's a better way to achieve our goals first. Most of our apps are currently under GPLv2(only) so we're going to be working to change the licensing on those apps over time to reflect GPLv2 or later. If you find something that we've written that's not under GPLv2+ (or LGPLv2+) that you want to use, please let us know so we can either get to work on making the license match the guidelines or let you know why it's not being changed. The one other thing for Infrastructure developers and System Admins to note in the Policy is the section on handling AGPLv3 applications. During the discussions about whether to use AGPLv3+ for our web applications we found and delimited many issues that need to be addressed when deploying AGPLv3+ licensed code. The aGPL portion of the policy is our first attempt at keeping us compliant with any code that is under this license. Highlights are: * Apps deployed to production under AGPL must be deployed from RPMs. Any hotfixes to those apps must have the patch in a ticket in trac on http://fedorahosted.org/fedora-infrastructure with the keyword HOTFIX. * Any AGPL app deployed in infrastructure must have links in the footer to the fedora-infrastructure SRPM repo and the trac query that pulls up our hotfixes so that people can find the exact source that we're running at any given time. * Staging must follow the same rules regarding SRPM and hotfixes. Once again, failing to link to the exact source for what we have running would put us out of compliance. * No AGPL apps can be hosted on publictest boxes at this time as publictest boxes are intended for development and the high rate of change in development is not conducive for constantly updating RPMS or patches in trac. If there's demand for publictest hosting of AGPL apps we'll need to design some method of restricting who can access the applications running there to satisfy the legal requirements. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Introduction
On 08/26/2009 09:35 AM, Christian Del Pino wrote: > Hello everyone, > > My name is Chris. I am looking to contribute my skills and time to the > Fedora Infrastructure group. > > I started using Linux back in 1996 while in college. In 2005, I became a > system administrator at a small company helping them build, deploy, and > support Linux based laptops for use in capturing clinical data. Other > tasks included projects to help the company scale our operations. > > I have a Bachelor's in Computer Science, and I am currently pursuing a > Master's in Information Systems, with a couple of semesters to go. I > also became a Red Hat Certified Technician back in 2004. > > My skills include: > > Bash scripting > MySQL > C++ > HTML > CSS > Some Python > Some PostgreSQL > Started learning some Django. > > I want to be involved in the Fedora community by helping out where I > can, and also learn some more new skills along the way. > If you're interested in Django, one project that started off purely in Fedora but has become more of its own upstream is transifex (http://www.transifex.org, #transifex on irc.freenode.net). diegobz, glezos, and ivazquez are all Fedora community members as well as transifex hackers. Our particular transifex instance is at: https://translate.fedoraproject.org Most of the rest of our web apps are written for the TurboGears 1 framework. We're going to port them to TG2 at some point in the indefinite future (probably when someone volunteers to make it their pet project :-). If there's one particular web application that you're interested in, I can help get you started. If you just want someone to suggest something, I can have you look through the tickets for the packagedb and we can find something for you to work on :-) best way to reach me is abadger1999 on irc.freenode.net -- #fedora-admin but email to this list also works. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] Temporary setting for galgoci
On 08/24/2009 03:08 PM, Mike McGrath wrote:
> ---
> manifests/servergroups/proxy.pp |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/manifests/servergroups/proxy.pp b/manifests/servergroups/proxy.pp
> index bdea7b6..70bbcf4 100644
> --- a/manifests/servergroups/proxy.pp
> +++ b/manifests/servergroups/proxy.pp
> @@ -741,7 +741,8 @@ class proxy {
> # Firewall Rules, allow HTTP traffic through
> $tcpPorts = [ 80, 443, 873, 8080 ]
> $udpPorts = []
> -$custom = []
> +$custom = ['-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT',
> +'-A INPUT -p tcp -m tcp --sport 80 -j DROP']
>
> iptables { "/etc/sysconfig/iptables":
> content => template("system/iptables-template.conf.erb"),
+1
-Toshio
signature.asc
Description: OpenPGP digital signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Joining the Fedora Infrastructure team
On 08/24/2009 02:32 AM, Mathieu Bridon (bochecha) wrote: > Hi, > > I'd like to join the Infrastructure team, so here is my introduction. > > I'm a junior system engineer. I have a short (one year) experience > managing RHEL (2.1 to 5, yes we still have 2.1 in production :'( ) web > servers running J2EE applications with Apache/JOnAS (please, don't ask > me the versions of those two, you might have nightmares ^^'). > > I'm also getting familiar with TurboGears web applications as I'm > developing one myself. [1] > > Finally, for the skills that might be of interest to the > Infrastructure team, I'm a Fedora package maintainer. [2] > > My motivation for joining the Infrastructure team is that I feel like > I can help, even if only a little, and I'm sure I can learn a lot from > this (and I love learning :) > > I'll try to be around this thursday for the IRC meeting. Let me know > if there's something I can do in the meantime. > Hi bochecha! It seems like you can fit right in either working on the system admin or the development side of Fedora Infrastructure. If you need anything or want to find a project to start working on we do most of our communication in #fedora-admin. mmcgrath, smooge, and ricky can help you if you'd like to work on some system admin tasks. ricky and I are good resources for getting started on development tasks. The Infrastructure Orientation page is a good place to start looking for things to do: https://fedoraproject.org/wiki/Orientation_Infrastructure_SOP For more development oriented things, I can help you get started hacking on pkgdb or another project. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Change Request] Mercurial upgrade on app1
On 08/20/2009 10:59 AM, Diego Búrigo Zacarão wrote: > There is a bug related to Mercurial-1.2.x that is boring some of our > translators when using Transifex[1]. > > Could I have +1's for updating it with the following version? > https://admin.fedoraproject.org/updates/mercurial-1.3.1-3.el5 > > [1] http://transifex.org/ticket/279 > +1 -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Change Request] Update xz on the builders
On 08/19/2009 08:09 PM, Toshio Kuratomi wrote: > On 08/19/2009 07:10 PM, Jesse Keating wrote: >> The host xz wouldn't be used to produce any rpms, the rpm inside the >> chroot would. Does this come into play when initing the buildroot? >> > You're right, this wouldn't come into play unless it's a decompression > bug. And if that's so it would generate an error from the buildsystem > while trying to create the buildroot instead of a corrupted payload in > the built rpms. So not as severe. I'm checking to be sure it isn't a > decompression bug now. > Confirmed -- the compressor is the issue here, not the decompressor. So we don't need to update the builders at this time. Since rawhide is the only release building with xz payloads we don't need to worry about buildroot overrides either. It *is* possible that some of the packages built before this xz package was put into the buildroot are corrupt:: http://koji.fedoraproject.org/koji/buildinfo?buildID=127510 (build finished at 2009-08-17 10:32:19) I don't know if this is something releng wants to check for. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Change Request] Update xz on the builders
On 08/19/2009 07:10 PM, Jesse Keating wrote: > > > On Aug 19, 2009, at 18:36, Toshio Kuratomi wrote: > >> A data corruption bug was found in the current xz package for certain >> files. The xz package was updated to a snapshot in Fedora and EPEL. >> We'd like to update the builders with the new xz to make sure we aren't >> producing packages with corrupted payloads. >> >> The corruption bug report is here: >> https://bugzilla.redhat.com/show_bug.cgi?id=517806 >> >> which includes confirmation that it fixes the bug and jnovy's >> recommendation to update the buildsystem. >> >> The EPEL-5 update is here: >> >> https://admin.fedoraproject.org/updates/xz-4.999.8-0.10.beta.20090817git.el5 >> >> >> Can I get two +1's for this? >> > > The host xz wouldn't be used to produce any rpms, the rpm inside the > chroot would. Does this come into play when initing the buildroot? > You're right, this wouldn't come into play unless it's a decompression bug. And if that's so it would generate an error from the buildsystem while trying to create the buildroot instead of a corrupted payload in the built rpms. So not as severe. I'm checking to be sure it isn't a decompression bug now. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Seeking comments on my proposal
On 08/19/2009 06:29 PM, Steven M. Parrish wrote: >> On 08/18/2009 11:19 AM, Steven M. Parrish wrote: >>> Got the outline of my proposal here >>> https://fedoraproject.org/wiki/SugarZilla >>> >>> I welcome any comments >> >> I dislike the idea of anonymous opening of bugs and anonymous commenting >> in bugzilla. It's not clear from the proposal if that's a proposed >> feature or not. Can you clarify if it is and if so, how you'll minimize >> the problem of: >> 1) SPAM >> 2) Bug reports with insufficient information to fix the problem with no >> point of contact to get additional information. >> >> -Toshio > > I haven't had time to fully check out ABRT but are they requiring the user to > have a valid bugzilla account? If I remember the original discussion around > ABRT at FUDCon Boston was not to require one. > I can see that being a good thing but I'm not sure it got implemented. abrt-bugzilla has a config file in /etc/abrt/plugins/Bugzilla.conf that has this:: # your login has to exist, if you don have anyone, please create one Login = # your password Password = It looks like we (Fedora packager) could fill those in with a bz user and password pair to give the equivalent of anonymous reporting to users but have chosen not to at the moment. > SPAM can be handled through a captcha if needed. > . So that would be a requirement before hooking it up to production bz. > As far as not being able to contact the reporter, that is why they have the > option of being cc'd to the report. They will be advised when filing the bug > that without a point of contact if the developer has questions and cannot > contact them that the bug could be closed as insufficient info. > > There are still some finer points which need to be worked out. > That makes sense although finding better and better ways to get the reporter to CC will be good. Might also want to ask the triage team if they might want to go through these types of bugs and triage them for more information and close them if there's no reporter on CC right off the bat or something. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
[Change Request] Update xz on the builders
A data corruption bug was found in the current xz package for certain files. The xz package was updated to a snapshot in Fedora and EPEL. We'd like to update the builders with the new xz to make sure we aren't producing packages with corrupted payloads. The corruption bug report is here: https://bugzilla.redhat.com/show_bug.cgi?id=517806 which includes confirmation that it fixes the bug and jnovy's recommendation to update the buildsystem. The EPEL-5 update is here: https://admin.fedoraproject.org/updates/xz-4.999.8-0.10.beta.20090817git.el5 Can I get two +1's for this? -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Change Request] Set replace => false on some db files which I missed.
On 08/19/2009 04:41 PM, Ricky Zhou wrote:
> I missed a few files in my earlier change request.
>
> ---
> modules/sigul/manifests/init.pp |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/modules/sigul/manifests/init.pp b/modules/sigul/manifests/init.pp
> index 20a88bd..f613182 100644
> --- a/modules/sigul/manifests/init.pp
> +++ b/modules/sigul/manifests/init.pp
> @@ -88,6 +88,7 @@ class sigul::server inherits sigul {
> group => "sigul",
> mode=> 0600,
> source => "puppet:///config/secure/sigul_server_cert8.db",
> +replace => false,
> require => Package["sigul"],
> }
>
> @@ -96,6 +97,7 @@ class sigul::server inherits sigul {
> group => "sigul",
> mode=> 0600,
> source => "puppet:///config/secure/sigul_server_key3.db",
> +replace => false,
> require => Package["sigul"],
> }
>
> @@ -104,6 +106,7 @@ class sigul::server inherits sigul {
> group => "sigul",
> mode=> 0600,
> source => "puppet:///config/secure/sigul_server_secmod.db",
> +replace => false,
> require => Package["sigul"],
> }
>
+1
-Toshio
signature.asc
Description: OpenPGP digital signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Seeking comments on my proposal
On 08/18/2009 11:19 AM, Steven M. Parrish wrote: > > Got the outline of my proposal here > https://fedoraproject.org/wiki/SugarZilla > > I welcome any comments > I dislike the idea of anonymous opening of bugs and anonymous commenting in bugzilla. It's not clear from the proposal if that's a proposed feature or not. Can you clarify if it is and if so, how you'll minimize the problem of: 1) SPAM 2) Bug reports with insufficient information to fix the problem with no point of contact to get additional information. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Wan't to join and why
On 08/17/2009 03:48 PM, Steven M. Parrish wrote: > Hi guys and gals, > > I am looking to join both the sysadmin-test and sysadmin-cvs groups. Why you > might ask? Well I'll tell you. I wan't to get more involved in Fedora. > > Here is my current Fedora resume... > > - BugZapper for both KDE and Packagekit. > - Maintain 20+ packages and am a Sponsor in the packaging group. > - Work closely with the OLPC and Sugar folks at getting and maintaining the > > packages in Fedora > - Responsible for creating builds of F11 with Sugar specifically for the OLPC > XO-1 (Hope to get an XO-1.5 soon) see http://wiki.laptop.org/go/F11_for_XO-1 > for info on this. > > What I am looking to do now is create a very simplified bugzilla interface > that > can be used by OLPC users, mostly children, to report issues with Sugar > Activities in Fedora. Will develop in PHP and would like to develop and test > it on one of the publictest servers. > > Also would like to help maintain the cvs servers and projects contained there. > > Any questions just ask. > Is this intended to be deployed onto Fedora Infrastructure boxes eventually or just be developed/demoed on the publictest infrastructure? We haven't had development of known-non-Fedora stuff done previously but this might be a valid first case. If it's intended to run on Fedora Infrastructure, we very much prefer developing them in python. In fact, I don't think we have any non-python developed stuff. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
[Change Request] Enable rw /mnt/fedora on puppet1
Currently we're mounting /mnt/fedora ro on puppet1. I think that this
was a change committed in puppet that affected the /etc/fstab file.
That didn't come into play until we rebooted puppet1 last night -- the
reboot caused the new fstab to be used and mount /mnt/fedora ro.
Here's the changeset that caused that:
Date: Fri Jun 26 22:53:26 2009 +
e mount instead of nfs.
diff --git a/modules/puppet/manifests/init.pp
b/modules/puppet/manifests/init.pp
index 21b8d62..0af2273 100644
--- a/modules/puppet/manifests/init.pp
+++ b/modules/puppet/manifests/init.pp
@@ -75,9 +75,12 @@ class puppet::master::mounts {
ensure => directory,
}
-nfs { "/mnt/fedora":
+mount { "/mnt/fedora":
device => "ntap-fedora1.fedora.phx.redhat.com:/vol/fedora/",
-require => File["/mnt/fedora/"],
+fstype => "nfs",
+ensure => "mounted",
+options => "defaults,ro,soft,intr",
+require => File["/mnt/fedora"],
}
}
I'd like to make the following change to this:
-options => "defaults,ro,soft,intr",
+options => "defaults,rw,soft,intr",
Can I get two +1's for my change?
-Toshio
signature.asc
Description: OpenPGP digital signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Change Request] Spam l10n-admin-members instead.
On 08/13/2009 02:14 PM, Ricky Zhou wrote:
> The db connection limit errors were our fault, we'll look into those
> separately, the rest of the spam should go to l10n-admin-members instead
> :-)
>
> ---
> modules/transifex/templates/00-default.conf.erb |5 +
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/modules/transifex/templates/00-default.conf.erb
> b/modules/transifex/templates/00-default.conf.erb
> index 320fec0..067a1d4 100644
> --- a/modules/transifex/templates/00-default.conf.erb
> +++ b/modules/transifex/templates/00-default.conf.erb
> @@ -31,10 +31,7 @@ logging.basicConfig(
> )
>
> ADMINS = (
> - ('Diego Burigo Zacarao', 'dieg...@gmail.com'),
> - ('Dimitris Glezos', 'dimit...@glezos.com'),
> - ('Ignacio Vazquez-Abrams', 'ivazquez...@gmail.com'),
> - ('Fedora Admins', 'ad...@fedoraproject.org'),
> + ('Fedora Admins', 'l10n-admin-memb...@fedoraproject.org'),
> )
>
> MANAGERS = ADMINS
>
>
Sounds good.
+1
-Toshio
signature.asc
Description: OpenPGP digital signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Change Request] Bodhi masher update on releng2 and relepel1
On 08/13/2009 10:00 AM, Luke Macken wrote: > Hey Guys, > > I'd like to do a bodhi masher upgrade on releng2 and relepel1. There are no > critical changes for the app1-6 bodhi instances, so there is no need to > upgrade > those just yet. Effected code paths for releng2/relepel1 bodhi mashers: > > - Fix a bug that would cause duplicate update IDs across Fedora 10/11 > (#515853) > > https://fedorahosted.org/bodhi/changeset/ff2fa4f45b980f0ccbabb0dd40b213f25468f374 > - Fixes koji session timeout bug that has been lurking for a while > > https://fedorahosted.org/bodhi/changeset/da86a7a44fecb097ee1ffc40ba9614a04594cd31 > - Remove some noisy debugging statements > +1 If this breaks it can be reverted on releng2/relepel1 without an outage for packagers correct? -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Change Request] Move Fedora Community's beaker session secret
On 08/12/2009 11:10 AM, Luke Macken wrote: > Trivial change, > > I would like to move Fedora Community's beaker.session.secret into our > passwords git module (and change it, of course). > > --- a/modules/fedoracommunity/templates/fedoracommunity-prod.ini.erb > +++ b/modules/fedoracommunity/templates/fedoracommunity-prod.ini.erb > @@ -117,7 +117,7 @@ full_stack = true > #lang = ru > #cache_dir = /var/cache/fedoracommunity/data > beaker.session.key = fedoracommunity > -beaker.session.secret = ? > +beaker.session.secret = <%= fcommBeakerSessionSecret %> > > beaker.cache.type = ext:memcached > beaker.cache.url = memcached1;memcached2 > +1 -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Change Request] Don't try to restart iscsi{,d}
On 08/11/2009 09:09 PM, Stephen John Smoogen wrote:
> +1 to make this change. Things are screwey enought right now wihtout
> it accidently doing it .
>
+1
-Toshio
> On Tue, Aug 11, 2009 at 9:56 PM, Ricky Zhou wrote:
>> In light of what I just did to xen15, I'd like to make this change so
>> that puppet never makes the same mistake :-)
>>
>> ---
>> modules/iscsi-initiator-utils/manifests/init.pp |4 +++-
>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>
>> diff --git a/modules/iscsi-initiator-utils/manifests/init.pp
>> b/modules/iscsi-initiator-utils/manifests/init.pp
>> index 4fbd54c..193b377 100644
>> --- a/modules/iscsi-initiator-utils/manifests/init.pp
>> +++ b/modules/iscsi-initiator-utils/manifests/init.pp
>> @@ -33,7 +33,9 @@ class iscsi-initiator-utils::initiator {
>> file { '/etc/iscsi/initiatorname.iscsi':
>> content => template("iscsi-initiator-utils/initiatorname.iscsi.erb"),
>> require => Package['iscsi-initiator-utils'],
>> -notify => [Service['iscsi'], Service['iscsid']],
>> +# Never, ever notify this service - do any restarts manually
>> +# after making sure that nothing is using a disk on iscsi.
>> +#notify => [Service['iscsi'], Service['iscsid']],
>> }
>> }
>>
>> --
>> 1.5.5.6
>>
>>
>> ___
>> Fedora-infrastructure-list mailing list
>> Fedora-infrastructure-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
>>
>>
>
>
>
signature.asc
Description: OpenPGP digital signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Change request - Yum update
On 08/11/2009 06:30 PM, Mike McGrath wrote: > Turns out there's yet another kernel update available for RHEL5. Since > I've run into issues updating a kernel and not other packages I'd like us > to do a yum update of all the packages. We shouldn't be far off but > there's a kernel and glibc update available. We can run them through > staging first for good measure. > > The reboot is on Thursday, it'd be good to have this all done prior to > that. > +1 -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: RFR: Hosting for Beacon (DocBook Editor) Testing
On 08/07/2009 08:23 AM, Mike McGrath wrote: > On Wed, 5 Aug 2009, satya komaragiri wrote: > > K, so this is for the zikula deployment. Go ahead and apply for > sysadmin-test and we'll get this all taken care of. > > smooge, ricky or toshio, if I'm not around would one of you mind helping > answer questions and such with this. Yep, Satya, I'm abadger1999 on IRC. ricky and smooge's irc nicks are self-explanatory :-) -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Handling Undeliverable mail messages
On 08/02/2009 12:43 AM, Brennan Ashton wrote:
>
> This might be slightly off the topic, but I think it relates to the
> reported issue in the bounced email. I have been noticing that when I
> run this script:
>
> from bugzilla import Bugzilla
> from fedora.client import AccountSystem
>
> url = 'https://bugzilla.redhat.com/xmlrpc.cgi'
> fasUsername = #replace with real values
> fasPassword = #replace with real values
> bz = Bugzilla(url=url)
> fas = AccountSystem(username=fasUsername,password=fasPassword)
> emails = [elem['bugzilla_email'] for elem in
> fas.people_by_groupname('triagers')]
> triagers = []
> for email in emails:
> try:
> name =
> triagers.append(bz._proxy.User.get({'names':[email],'include_fields':['real_name']}))
> except:
> print email + " not found"
>
> That somehow some people have bug privileges in FAS and in there BZ
> account but the two can no longer be connected.
>
This isn't supposed to happen but the coupling between FAS and bugzilla
is loose enough that I can see where a bug could let it happen. There's
logic in FAS to add a user to a special table, bugzilla_queue if they
belong to the fedorabugs group and their email address changes. It's
supposed to remove the fedora_contrib permissions from the old email and
add them to the new one. There could be a breakdown either in adding to
the bugzilla_queue table or in the cron job that processes that table
(export_bugzilla).
Note that at one time triagers were manually added to fedora_bugs. This
isn't a remnant of that, is it?
-Toshio
signature.asc
Description: OpenPGP digital signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Handling Undeliverable mail messages
Sorry, I'm not receiving these bounces for some reason :-( On 08/01/2009 10:35 PM, Domsch, Matt wrote: > 1) typo "Mistmatch" in the subject line of these messages: > Subject: Undeliverable: Fedora Account System and Bugzilla Mistmatch > > 2) an insane number of these messages are being sent each day. There >must be a better way to handle this. There's no easy way to fix this generically as the script doesn't know whether the email address is good or not. ricky has changed this to send to nobod...@fedoraproject.org so that we stop getting bounces from bkonrath. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: transif user in packager group
On 07/28/2009 03:58 PM, Toshio Kuratomi wrote: > Today we added the transif user to the packager group because transifex > lost the ability to add translations for comps. At the moment, this > doesn't affect much -- packager group only gives you the ability to > commit to comps and what packages you are given explicit rights to. > However, it may become bigger in the future since we may allow people to > specify that anyone in packager can commit to their packages. > > transif's last commit to the comps files was around the 17th of July. > If anyone can recall some action or config change that they might have > performed that would have changed whether transif could commit to comps > between 17th of July and today or can think of a better way to give > transif access to the comps cvs repo please speak up! it would be > better long-term if transif was not in the packager group. > Correction: 17th of June, not July. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
AGPL compliancewith moksha
Okay, We've got to do some work for AGPL compliance with moksha. First, a few restrictions that we'll have to live with until we can figure out a legal way to do them better: * We cannot do development work directly fedoracommunity/moksha on staging for now. All fedoracommunity/moksha changes must be deployed to staging in the form of an rpm. * lmacken has confirmed that staging is currently deployed from rpm. * **The same for the publictest instances** * If legal approves of using Apache Basic Auth to fix this, we can use that to allow use of the publictest boxes again. Note, though, that that approval will still restrict us (for instance, ianweller is using pt7 to demo his fedora community stats branch. He won't be able to demo it to people outside of sysadmin-test with the Apache Basic Auth solution in place). Some things we need to code into Fedora Community: * We need to be able to customize the footer or front page of fedoracommunity to point to infrastructure.fedoraproject.org for the sources and to trac for hotfixes. * Note that for certain uses of publictest/staging, this can work as well. For instance, ianweller could run his demo strictly from a git checkout and the configuration can point people to that *specific* revision. * Upstream moksha/fedoracommunity might want to change their default footer/frontpage to point to the upstream tarballs as legal says the project page isn't good enough for people running it to be compliant. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
transif user in packager group
Today we added the transif user to the packager group because transifex lost the ability to add translations for comps. At the moment, this doesn't affect much -- packager group only gives you the ability to commit to comps and what packages you are given explicit rights to. However, it may become bigger in the future since we may allow people to specify that anyone in packager can commit to their packages. transif's last commit to the comps files was around the 17th of July. If anyone can recall some action or config change that they might have performed that would have changed whether transif could commit to comps between 17th of July and today or can think of a better way to give transif access to the comps cvs repo please speak up! it would be better long-term if transif was not in the packager group. The only solution we've come up with that doesn't use the packager group so far requires that we do two things: 1) add cvs acls for transif to commit to comps. 2) set filesystem acls so transif can commit to comps. Doing #2 isn't that great an idea as it's a one-off doing something not readily apparent (we don't use fs acls anywhere else in cvs). But if it could be puppet managed it might not be too bad. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: A discussion on licensing and the AGPLv3
On 07/28/2009 01:21 PM, Tom "spot" Callaway wrote: > On 07/28/2009 03:38 PM, Toshio Kuratomi wrote: >> Should we ask Legal if we could stick Apache Basic Auth (using >> mod_auth_postgres) in front of staging and then it would be okay? Or if >> we used openvpn to connect to http(s) on staging? > > These are both good ideas, would you like me to float them past RH Legal? > Yes, please. I think it would look something like this: sysadmin-XXX group can ssh into publictest boxes to work on applications. sysadmin-YYY group can ssh into staging boxes to work on applications. Not all the people in those groups will be working on the same applications (some work on Fedora Community, some on FAS, some don't work on developing applications at all) but they will all be part of the Fedora Infrastructure team. For legal: If we limit who can hit the web apps via apache basic auth or openvpn to the sysadmin-XXX and sysadmin-YYY groups, can we forgo having a direct pointer to the corresponding source? On the infrastructure side, we have to figure out if this is going to be too limiting. (ie, we need people specifically not in sysadmin-XXX or sysadmin-YYY to test our changes before we deploy). -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: A discussion on licensing and the AGPLv3
On 07/28/2009 12:09 PM, Tom "spot" Callaway wrote: > On 07/28/2009 12:06 PM, Toshio Kuratomi wrote: >> On 07/28/2009 08:16 AM, Tom "spot" Callaway wrote: >> >>> Hopefully, this will provide a solid groundwork for Thursday's discussions. >>> >> >> Excellent! I think this provides some good options for us wrt >> distributing changes for production. Are the questions about our >> staging and publictest environments still in discussion with legal? >> >> In case those questions were missed, here they are again: > > Q: Is the preamble legally binding/part of the AGPL or should we ignore > anything there? > > Red Hat Legal advises that the preamble is not legally binding. It is > there only to provide some guidance as to how to interpret the binding > parts of the license. In general, Red Hat Legal advises that no one > should think too much about (A/L)GPL preambles. ;) > > Q: admin.stg.fedoraproject.org is accessible by the general public but > it isn't meant for the general public's use -- it's for developers to > collaborate on what will be on the production site, > admin.fedoraproject.org. Those developers collaborate over the internet > which is why it's available on the internet. Does this excuse us from > providing source to people who do not have shell access to the server > itself? > > Red Hat Legal says: > No. However, I suppose you could solve the problem by writing an > additional permission that says that pushing the webapp to admin.stg.f.o > does not trigger AGPL sec. 13. (You could also word something more > broadly to allow downstream non-Fedora users to take advantage of the > same principle, in circumstances involving testing on public staging > sites, but it might be difficult to word that without creating a > loophole.) This doesn't work if you start using > upstream-of-Fedora AGPL code. > Okay guys, time to get creative :-) The exception would be one way we could go with this. It doesn't help if we deploy launchpad or similar. It also doesn't help third parties looking to deploy our code (without legal sitting down and working out something that doesn't have loopholes). Deploying to staging directly from a specific VCS branch could work -- but then we'd have to have different methods for VCS vs rpm (since we're using staging for both deployment testing and late development testing). Having a cron job that took differences between staging and baseline and uploaded it somewhere public could work but it would be hard to make the script generic enough, I think. Should we ask Legal if we could stick Apache Basic Auth (using mod_auth_postgres) in front of staging and then it would be okay? Or if we used openvpn to connect to http(s) on staging? -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: A discussion on licensing and the AGPLv3
On 07/28/2009 08:16 AM, Tom "spot" Callaway wrote: > Q: Do config changes count as code changes if the config file is marked > as being AGPL? > > Red Hat Legal feels that changes to configuration lines inside a script > do not represent a copyrightable change to the script, and therefore > they do not trigger the AGPLv3 section 13 requirement (this is the > requirement on sharing the AGPLv3 covered code), because the config > change does not result in a "modified version" as that term is used in > AGPLv3. > > They advise that it would be preferred if applications clearly separated > the configuration files from the actual web application code and > scripts, as it minimizes licensing concerns. > > Q: What do we have to do to make config files not be licensed under > AGPL? (We want to keep passwords private, for instance). > > Red Hat Legal advises that for config files included in an AGPLv3 > distribution, you can cause them to fall outside of the AGPLv3 (at least > section 13), by explicitly granting an additional permission stating > that such files (assuming that they are copyrightable) are covered by > the AGPLv3, but are not subject to the AGPLv3 section 13 requirement. > > Red Hat Legal would be happy to draft up wording for such an additional > permission for our needs. > I take these two to answers to mean roughly: Configuration is not copyrightable. Therefore changes to configuration files and configuration within scripts is not something that needs to be provided under the AGPLv3. If we are still concerned about them, Red Hat Legal will help us write a license for the config files that makes clear that changes to them do not have to be distributed. Is that a good summary? Thanks again spot! -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: A discussion on licensing and the AGPLv3
On 07/28/2009 08:16 AM, Tom "spot" Callaway wrote: > Hopefully, this will provide a solid groundwork for Thursday's discussions. > Excellent! I think this provides some good options for us wrt distributing changes for production. Are the questions about our staging and publictest environments still in discussion with legal? In case those questions were missed, here they are again: == Related to Staging == We use the staging environment for both some development duties and integration testing. Because of that we want to be able to deploy into staging things that we aren't providing exact corresponding source for at the moment. The staging environment is reachable by members of the general public but we'd like to find out if we can consider it an internal service that doesn't need to track every little change we make. Here's the portions of the AGPL we think is relevant: From the preamble: """ public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version. """ Section 13: """ Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. """ * Is the preamble legally binding/part of the AGPL or should we ignore anything there? * admin.stg.fedoraproject.org is accessible by the general public but it isn't meant for the general public's use -- it's for developers to collaborate on what will be on the production site, admin.fedoraproject.org. Those developers collaborate over the internet which is why it's available on the internet. Does this excuse us from providing source to people who do not have shell access to the server itself? * If we can run apps in staging without providing source to those without shell accounts there, can we also run apps on publictest boxes without providing source to those without shell accounts there? -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Fwd: Re: Is F-community using its FAS account?
Original Message Subject: Re: Is F-community using its FAS account? Date: Mon, 27 Jul 2009 14:35:50 -0400 (EDT) From: John Palmieri To: Toshio Kuratomi It is used for getting a user's info when you are not logged in similar to the functionality of the bots in #fedora-devel. Going to this link (https://admin.fedoraproject.org/community/?username=jkeating#people) works so the password change worked. ----- "Toshio Kuratomi" wrote: > Hey, > > lmacken and I realized that we probably hadn't changed Fedora > Community's password since moving it from the publictest machines to > production so I did that today. But when I went to test it we > couldn't > figure out where it would actually be used:: > > [10:00:02] abadger1999: hmm, I'm actually not sure if > that > account is getting used at all. It looks like it is only used when > the > user is not logged in, but in that case they can't view users or > anything FAS related as far as I can tell. J5 would know for sure > > So, is the account being used? If so how can I test that the > password > update worked okay? If not, can we disable the account? > > -Toshio -- -- John (J5) Palmieri Software Engineer Red Hat, Inc. signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
AGPL Licensing: Another "configuration" file example
This wsgi script also helps illustrate some of smooge's concerns about
what happens when configuration information is mixed into a script. It
has two areas that differ between upstream's distribution and our own:
The first is bad application design but I've seen this done frequently
in PHP apps (and it sounds like Java frameworks like JBoss promote this
as well). The fact that our apps are doing it shows it can occur in any
language although we should be able to change our apps to work around it
fairly easily:
The scripts that start up our web applications under mod_wsgi all seem
to have a bit of config tweaking. Historically, this is because we
deployed with a start-app.py script that used the config file
exclusively and started as a standalone daemon. The app.wsgi script
would load the standalone daemon config file and then make some config
changes in the wsgi script before starting the application server. This
can be seen in the attached wsgi script in lines like this::
turbogears.update_config(configfile="/home/ricky/work/fedora/fas/fas.cfg",
modulename="fas.config")
turbogears.config.update({'global': {'server.environment':
'development'}})
For our TurboGears apps it should be pretty easy for us to work around
that by moving all such lines into the config file instead of being in
the script. But for third party PHP scripts licensed under AGPL and
single file cgi scripts that we write what is our responsibility? I can
see several options:
1) We must patch every script/app/etc to put the config into its own
file. Those changes fall unde the AGPL and we try to get them upstream.
The config file falls outside of the AGPL either via explicit license
or some other way.
2) configuration, even embedded inside of an AGPL script is not subject
to the AGPL because it's not copyrightable data.
Second piece of code that varies between installations::
import sys
sys.path.append('/home/ricky/work/fedora/fas/fas/')
Setting the path at which to find the code must be done otherwise the
script won't be able to find the code related to the web application
itself. On different installations (our servers, developers' test
machines, etc) this path will vary. Are those changes that are covered
by the AGPL or are they non-copyrightable? Is there a difference if
this is done manually by the system administrator vs automatically by
the Makefiles/build scripts provided by upstream?
This issue is harder to work around in code since finding the path to
files is a chicken and egg problem. At some point, the executable has
to hardcode at least one path to be able to load the rest of its
information.
-Toshio
#!/usr/bin/python
import sys
sys.path.append('/home/ricky/work/fedora/fas/fas/')
sys.path.append('/home/ricky/work/fedora/fas/')
sys.path.append('/home/ricky/work/fedora/fas/plugins/fas-plugin-asterisk')
sys.stdout = sys.stderr
import pkg_resources
pkg_resources.require('CherryPy <= 3.0alpha')
import os
os.environ['PYTHON_EGG_CACHE'] = '/home/ricky/work/fedora/fas/fas.egg-info/'
import atexit
import cherrypy
import cherrypy._cpwsgi
import turbogears
import turbogears.startup
import fedora.tg.util
class MyNestedVariablesFilter(turbogears.startup.NestedVariablesFilter):
def before_main(self):
if hasattr(cherrypy.request, "params"):
cherrypy.request.params_backup = cherrypy.request.params
super(MyNestedVariablesFilter, self).before_main()
turbogears.startup.NestedVariablesFilter = MyNestedVariablesFilter
turbogears.update_config(configfile="/home/ricky/work/fedora/fas/fas.cfg",
modulename="fas.config")
turbogears.config.update({'global': {'server.environment': 'development'}})
turbogears.config.update({'global': {'debug': 'on'}})
turbogears.config.update({'global': {'autoreload.on': False}})
turbogears.config.update({'global': {'server.throw_errors': True}})
turbogears.config.update({'global': {'server.log_to_screen': False}})
turbogears.config.update({'global': {'server.webpath': '/accounts'}})
turbogears.config.update({'global': {'base_url_filter.on': True}})
turbogears.config.update({'global': {'base_url_filter.base_url':
'http://alpha.rzhou.org'}})
turbogears.startup.call_on_startup.append(fedora.tg.util.enable_csrf)
import fas.controllers
cherrypy.root = fas.controllers.Root()
# Uncomment this (and the below section) to use weberror for development
#from weberror.evalexception import EvalException
if cherrypy.server.state == 0:
atexit.register(cherrypy.server.stop)
cherrypy.server.start(init_only=True, server_class=None)
from webob import Request
def application(environ, start_response):
environ['SCRIPT_NAME'] = ''
return cherrypy._cpwsgi.wsgiApp(environ, start_response)
def fake_call(self, environ, start_response):
## FIXME: print better error message (maybe fall back on
## normal middleware, plus an error message)
assert not environ['wsgi.multiprocess'], (
"The EvalException middleware is not usable in a "
Is F-community using its FAS account?
Hey, lmacken and I realized that we probably hadn't changed Fedora Community's password since moving it from the publictest machines to production so I did that today. But when I went to test it we couldn't figure out where it would actually be used:: [10:00:02] abadger1999: hmm, I'm actually not sure if that account is getting used at all. It looks like it is only used when the user is not logged in, but in that case they can't view users or anything FAS related as far as I can tell. J5 would know for sure So, is the account being used? If so how can I test that the password update worked okay? If not, can we disable the account? -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] Setup sigul bridge and client
On 07/24/2009 10:07 PM, Jesse Keating wrote: > +# Include the builder infrastructure so that we get the same rpm versions > +include yum::repo::builder-infrastructure Not necessarily related to enabling the builder repo: Is having the same rpm versions as the builders necessary? -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Relicensing Part II (redux)
On 07/23/2009 11:48 AM, Matt Domsch wrote: > On Thu, Jul 23, 2009 at 01:46:45PM -0500, Matt Domsch wrote: >> On Tue, Jul 21, 2009 at 10:09:04AM -0700, Toshio Kuratomi wrote: >>> Resending since spot didn't get it the first time. >>> >>> Okay, at the infrastructure meeting this week we had a long discussion >>> about using AGPL in infrastructure and we decided we need more >>> information about what the AGPL requires of us. Here's a run down and >>> then the questions we had. >> >> I invited Bradley Kuhn of the Software Freedom Conservancy to join >> today's IRC meeting. Not sure if he can join, but he's well versed in >> the AGPLv3 and I had pointed him at this thread. He offered to join >> and discuss with us. > > He's at OSCON this week, so I invited him to attend future Thursday > meeting. > Excellent. Depending on when spot hears back from Red Hat legal and whether we have more questions after that, we may just be a case study for him or we may still be in the midst of figuring out what we want to do. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Relicensing Part II (redux)
Resending since spot didn't get it the first time. Okay, at the infrastructure meeting this week we had a long discussion about using AGPL in infrastructure and we decided we need more information about what the AGPL requires of us. Here's a run down and then the questions we had. == What we decided == We arrived at a few conclusions with the amount of knowledge we currently have: * Continue to deploy as rpms to production and as the basis of staging. * In production, hotfixes need to have tickets in trac (this is current policy). Those tickets may be required to contain patches applied to the server if we determine that's the best course under legal. - If that's not the best course, hotfix tickets still need to contain an indication of what the hotfix does but this could be "I reverted commit 12345" or "I changed three files to import simplejson instead of json (python-2.4 compatibility)" * In staging, we want to deploy with a base rpm and may add patches and local changes on top of that to test things. When we get to the point where we are satisfied, this needs to be turned into an rpm and be deployed to production/installed in the staging env. * In publictest, we want people to be able to deploy from SCM, make local changes, etc. publictest are pure development machines. == Explain the linking requirements == How the running app leads people to the source for the app is causing the most concerns. Here's a list of questions. There's a lot because we don't have a feel for what's allowed and not allowed yet. Where relevant, assume that the running applications have rpms/srpms present on infrastructure.fedoraproject.org, an upstream trac/scm instance on fedorahosted.org, and that we are running with some number of hotfixes to the live application. * Do we need to link to the source from every page of the app? * What are legal means of giving people access to the corresponding source? + Source repository at no particular version (assuming all of our patches are applied to trunk -- and trunk might contain other changes as well, including full or partial reversions of those changes in a later revision) + Source repository at no particular version (assuming all of our patches are applied to a branch that mirrors production) + Pointing exactly to source repository branch or tag of the exact version we're running + Home page of the project (example: http://fedorahosted.org/fas) + Just a page specifically linking to the sources and all of the patches we've applied + links to base srpm and page listing patches + links to base srpm and tickets in trac that have patches attached + links to base srpm and tickets in trac that point to commits in SCM that are applied against different versions (HEAD vs the last release, for instance) + A page linking to the sources and a page linking to any hotfixes we've applied to any of our apps (ie, a query in infrastructure's trac that gets all hotfixes for all of our apps). + I'm assuming these to be fine: tarball, srpm that matches what's running, actual links to base tarball and to all of the patches * Do config changes count as code changes if the config file is marked as being AGPL? - If yes, what do we have to do to make config files not be licensed under AGPL? (We want to keep passwords private, for instance). == Related to Other Apps == Our original impetus for relicensing is so we can freely share code with fedoracommunity. The cost of maintaining AGPL compliance with other apps needs to be weighed against the cost of reinventing code in fedoracommunity (or waiting for fedoracommunity developers to relicense their code for use elsewhere *cough CSRF middleware cough* :-) ). * Is it really "absolutely critical" that fedoracommunity be AGPL? * Can we get a clarification of what the consequences would be if fedora community stays AGPL but our apps stay as they are (GPLv2)? == Related to Staging == We use the staging environment for both some development duties and integration testing. Because of that we want to be able to deploy into staging things that we aren't providing exact corresponding source for at the moment. The staging environment is reachable by members of the general public but we'd like to find out if we can consider it an internal service that doesn't need to track every little change we make. Here's the portions of the AGPL we think is relevant: From the preamble: """ public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version. """ Section 13: """ Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at
Re: Bugzilla bot account / Fedora mail alias
On 07/18/2009 10:39 AM, Till Maas wrote: > On Fri July 17 2009, Toshio Kuratomi wrote: >>> So I guess I need a seperate FAS account for this and apply for >>> fedorabugs or is there some other way to do this? The ftbfs bugzilla >>> account is capable of changing the status iirc. >> >> Okay, I've taken care of this in FAS. It should sync to bugzilla within >> the hour. If not, let me know. > > I just checked again and the permissions are now there. Strangely it is still > not possible to create new bugs with status "ASSIGNED". It now returns an > exception: > status.'> > Previously it was silently ignored. > Setting them to ASSIGNED afterwards is now possible and also reporting them > with the FutureFeature keyword. > Excellent. I flipped a few bits manually this morning. Let me know if you have further problems. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Bugzilla bot account / Fedora mail alias
> So I guess I need a seperate FAS account for this and apply for > fedorabugs or is there some other way to do this? The ftbfs bugzilla > account is capable of changing the status iirc. > Okay, I've taken care of this in FAS. It should sync to bugzilla within the hour. If not, let me know. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Add patch to global.pp
On 07/16/2009 08:59 PM, Mike McGrath wrote: > +0 no opinion if it would be of some use. I've generally scp'd files > where needed and copied from there. Same number of commands and files > copied as if you were to patch > > scp blah.py app1: ; ssh app1 ; sudo cp blah.py /usr/blah > > scp blah.patch app1: ; ssh app1; sudo patch -p1 < blah.patch > Good point. Of more use when you're showing someone else your changes/receiving changes from someone else. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Add patch to global.pp
On 07/16/2009 08:50 PM, Jesse Keating wrote: > On Thu, 2009-07-16 at 19:59 -0700, Toshio Kuratomi wrote: >> What's the consensus here? > > If we install patch, will git come next, since people will want to git > am stuff? Not that I'm against having patch, it would make things > easier. Well I won't be adding that one :-) Thinking about this more seriously, patch can be useful on text files on any system. git is only useful on systems where we're making git checkouts. git-am, if I'm reading the man page right would only be useful where we have git checkouts and are receiving patches via mail? -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Add patch to global.pp
ricky and I were considering adding patch to global.pp and dennis brought up that it might be a command used to do malicious stuff. So what do you guys think? Pros: patch makes some things much easier to do. Want to cherrypick a change as a hotfix? Many times patch is needed to apply the diff. Want to replicate some changes from server1 to servers 2, 3, and 4? diff on server1, patch on the others. Need to review a change that someone else has done and then apply it? Read the diff they give you and apply it rather than grabbing the whole file, doing the diff yourself, and then applying it. Cons: patch is a commonly used utility that is often used to edit files. So the principle of not installing things that aren't needed makes it one more tool that an attacker won't have if they get remote execution on a box they shouldn't. However, there's many other things that an attacker can do if they gain remote execution. Rather than retrieving a diff and applying that to a file, the attacker can just retrieve a file and then replace the existing one; we have wget, curl, and scp installed. ed, sed, perl, python, and other text processing tools are available. I'm thinking if the attacker can gain the ability to execute a remote command and they have permission to touch files that are going to cause us harm, lack of patch isn't going to save us. Other: * patch doesn't have any deps that aren't already installed on one of our boxes. What's the consensus here? -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Relicensing Part II
On 07/16/2009 04:10 PM, Jesse Keating wrote: > On Thu, 2009-07-16 at 15:57 -0700, Toshio Kuratomi wrote: >> >> * admin.stg.fedoraproject.org is accessible by the general public but it >> isn't meant for the general public's use -- it's for developers to >> collaborate on what will be on the production site, >> admin.fedoraproject.org. Those developers collaborate over the internet >> which is why it's available on the internet. Does this excuse us from >> providing source to people who do not have shell access to the server >> itself? >> >> * Can we be just as liberal with what's running on the publictest >> machines as we are with staging? > > Its worth noting that Publictest instances are also accessible by the > public, so AGPL concerns may strike us there, just as they may strike us > with the staging environment. > I figure if it's going to hit us hard in staging, we may not want to go the AGPL route at all. If they don't hit us in staging, just want confirm that the same rationale will apply to the publictest instances. Maybe reword this question to: * If we can run apps in staging without providing source to those without shell accounts there, can we also run apps on publictest boxes without providing source to those without shell accounts there. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Relicensing Part II
Alright! So the last two weeks there wasn't much comment on: https://fedorahosted.org/fedora-infrastructure/ticket/1524 https://fedoraproject.org/wiki/Infrastructure_Licensing but I think people were either sleeping or didn't entirely understand what the AGPL's requirements mean for us as this week we filled the whole meeting with discussion[1]_. We arrived at a few conclusions about options we did not want to explore but got into a few questions that need answers from legal before we can continue. Please clarify the questions or add new ones if you can think of other things that we need to know from legal. Once that's done or tomorrow (whichever comes first) I'll make sure that spot gets the list so we can get some input and better consider our options. Questions follow: == What we decided == * Continue to deploy as rpms to production and as the basis of staging. * In production, hotfixes need to have tickets in trac. Those tickets may be required to contain patches applied to the server if we determine that's the best course under legal. - If that's not the best course, hotfix tickets still need to contain an indication of what the hotfix does but this could be "I reverted commit 12345" or "I changed three files to import simplejson instead of json (python-2.4 compatibility)" * In staging, we want to deploy with a base rpm and may add patches and local changes on top of that to test things. When we get to the point where we are satisfied, this needs to be turned into an rpm and be deployed to production/installed in the staging env. * In publictest, we want people to be able to deploy from SCM, make local changes, etc. publictest are pure development machines. == Explain the linking requirements == How the running app leads people to the source for the app is causing the most concerns. Here's a list of questions. There's a lot because we don't have a feel for what's allowed and not allowed yet. Where relevant, assume that the running applications have rpms/srpms present on infrastructure.fedoraproject.org, an upstream trac/scm instance on fedorahosted.org, and that we are running with some number of hotfixes to the live application. * Do we need to link to the source from every page of the app? * What are legal means of giving people access to the corresponding source? + Source repository at no particular version (assuming all of our patches are applied to trunk -- and trunk might contain other changes as well, including full or partial reversions of those changes in a later revision) + Source repository at no particular version (assuming all of our patches are applied to a branch that mirrors production) + Pointing exactly to source repository branch or tag of the exact version we're running + Home page of the project (example: http://fedorahosted.org/fas) + Just a page specifically linking to the sources and all of the patches we've applied + links to base srpm and page listing patches + links to base srpm and tickets in trac that have patches attached + links to base srpm and tickets in trac that point to commits in SCM that are applied against different versions (HEAD vs the last release, for instance) + A page linking to the sources and a page linking to any hotfixes we've applied to any of our apps (ie, a query in infrastructure's trac that gets all hotfixes for all of our apps). + I'm assuming these to be fine: tarball, srpm that matches what's running, actual links to base tarball and to all of the patches * Do config changes count as code changes if the config file is marked as being AGPL? - If yes, what do we have to do to make config files not be licensed under AGPL? (We want to protect passwords, for instance). == Related to Other Apps == Our original impetus for relicensing is so we can freely share code with fedoracommunity. The cost of maintaining AGPL compliance with other apps needs to be weighed against the cost of reinventing code in fedoracommunity (or waiting for fedoracommunity developers to relicense their code for use elsewhere *cough CSRF middleware cough* :-) ). * Is it really "absolutely critical" that fedoracommunity be AGPL? * Can we get a clarification of what the consequences would be if fedora community stays AGPL but our apps stay as they are (GPLv2)? == Related to Staging == We use the staging environment for both some development duties and integration testing. Because of that we want to be able to deploy into staging things that we aren't providing exact corresponding source for at the moment. The staging environment is reachable by members of the general public but we'd like to find out if we can consider it an internal service that doesn't need to track every little change we make. Here's the portions of the AGPL we think is relevant: From the preamble: """ public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version
Re: About me
On 07/15/2009 05:00 PM, Ricky Zhou wrote: > On 2009-07-15 01:41:52 AM, Davi Vercillo C. Garcia wrote: >> I would like to help Fedora community grow and keep moving... (Johnny >> Walker ? =P) > As you've seen already, we mostly hang out in #fedora-admin. We also > have weekly meetings on Thursdays at 20:00 UTC in #fedora-meeting, if > you can make the one tomorrow, make sure to introduce yourself there as > well :-) > > As I mentioned on IRC, we have a list of tickets at > https://fedorahosted.org/fedora-infrastructure/report/1, so feel free to > let us know if you find anything there that you'd be interested in > working on. We also always have a long list of tasks involving > development on a lot of our web applications (mostly using TurboGears > 1/2). > Individual app authors also hang out on IRC. So if you introduce yourself, we can point you at individual apps that need work as well! -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New rule
On 07/10/2009 03:44 PM, Mike McGrath wrote: > I'm going to document this somewhere, we talked about it on IRC a while > back but I never sent an email to the list. > > Hot patching servers is bad! Don't do it! But if you _must_ do it for > whatever reason, you _MUST_ open a ticket about it and leave it open until > the hot patch is removed: > > https://fedorahosted.org/fedora-infrastructure/ticket/1524 > We should have a keyword or a component to make searching easier as well. For now I've added Hotfix to the keywords for that bug but if people forget to use that we can use a component or something else. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: pkgdb -> bugzilla sync broken?
On 07/02/2009 05:07 AM, Michael Schwendt wrote: > How often is bugzilla.redhat.com updated with changes in Fedora pkgdb? > It has yet to sync the audacious* ownership changes from June 29th. > Perhaps it's broken? > > https://bugzilla.redhat.com/describecomponents.cgi?product=Fedora > This should be fixed now. The changes I made this morning weren't perfect so complete syncing of every package wasn't occurring until an hour ago. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Licensing Guidelines for apps we write
On 07/02/2009 07:03 AM, Rahul Sundaram wrote: > On 07/02/2009 08:53 AM, Toshio Kuratomi wrote: >> Hi, I've had a chance to talk to spot and I've drafted the following >> policy about licensing the things that we write in Fedora Infrastructure: >> >> https://fedoraproject.org/wiki/Infrastructure_Licensing >> >> Do people like it? Is a GPL family license pretty much everywhere good >> for everyone or are there places that we'd like the general rule to be >> "MIT" or something looser instead? > > Has Red Hat Legal been consulted on this? > I've consulted spot. Spot based his input on the policy on feedback he received while relicensing Fedora Community to AGPLv3+. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Licensing Guidelines for apps we write
On 07/01/2009 09:37 PM, Nigel Jones wrote: > > - "Toshio Kuratomi" wrote: > >> Hi, I've had a chance to talk to spot and I've drafted the following >> policy about licensing the things that we write in Fedora >> Infrastructure: >> >> https://fedoraproject.org/wiki/Infrastructure_Licensing >> >> Do people like it? Is a GPL family license pretty much everywhere >> good >> for everyone or are there places that we'd like the general rule to >> be >> "MIT" or something looser instead? >> >> I want to relicense python-fedora (GPLv2 => LGPLv2+), pkgdb and fas >> (GPLv2 => AGPLv3+) if we approve this. I'll talk to the contributors >> to >> those projects to make sure they have no objections first, but is >> that >> generally acceptable? Anyone else want to join in on the >> relicensing? >> Having things under compatible licenses will make code sharing >> possible. >> (GPLv2 only is not compatible with AGPLv3+) which is my incentive for >> migrating apps that I'm contributing to onto a common licensing >> scheme. >> >> I'm putting this on the meeting agenda for Thursday but discussion in >> the mailing list is also welcome. > > I definitely won't be at the meeting tomorrow, but yes, this is something > that must be done, +1 from me. > > I guess to fit in, we should do the some for the voting app. > That would be ideal. Relicensing all of our GPLv2-only apps to reflect these Guidelines would be good. Mirrormanager is MIT licensed and that doesn't need to be relicensed to fit in as MIT is compatible with all of the GPL family of licenses. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Licensing Guidelines for apps we write
Hi, I've had a chance to talk to spot and I've drafted the following policy about licensing the things that we write in Fedora Infrastructure: https://fedoraproject.org/wiki/Infrastructure_Licensing Do people like it? Is a GPL family license pretty much everywhere good for everyone or are there places that we'd like the general rule to be "MIT" or something looser instead? I want to relicense python-fedora (GPLv2 => LGPLv2+), pkgdb and fas (GPLv2 => AGPLv3+) if we approve this. I'll talk to the contributors to those projects to make sure they have no objections first, but is that generally acceptable? Anyone else want to join in on the relicensing? Having things under compatible licenses will make code sharing possible. (GPLv2 only is not compatible with AGPLv3+) which is my incentive for migrating apps that I'm contributing to onto a common licensing scheme. I'm putting this on the meeting agenda for Thursday but discussion in the mailing list is also welcome. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: memcached opinions
On 07/01/2009 05:39 PM, Mike McGrath wrote: > On Wed, 1 Jul 2009, Stephen John Smoogen wrote: > >> On Wed, Jul 1, 2009 at 6:08 PM, Mike McGrath wrote: >>> On Wed, 1 Jul 2009, Stephen John Smoogen wrote: >>> On Wed, Jul 1, 2009 at 3:33 PM, Mike McGrath wrote: > I'm not sure if we have any memcached experience on the list but I thought > I'd ask. Can anyone explain this: > > http://pastebin.ca/1481219 > > Notice how memcached1 has a much higher hit rate and memcached2 has a much > lower hit rate? > The time for memcached1 is 5x less than memcached2 being up. That can have an effect on caching as right after a system comes up its rates are usually much higher and then over time fall off (iirc). I think it would take bringing both up at the same time to figure out if there is a true disparity over caching. >>> >>> I thought that exact same thing :) >>> >>> memcahed1: >>> STAT uptime 9143 >>> STAT get_hits 311736 >>> STAT get_misses 11255 >>> >>> memcached2: >>> STAT uptime 9144 >>> STAT get_hits 49679 >>> STAT get_misses 6 >>> >> >> Now that shows something not kosher. My guess is some app is not >> talking to both? What apps use memcached for what? >> > > I was just talking to ricky about this a bit in IRC. So here's the scoop. > > We've got mediawiki using memcached for a couple of things, including > session data (which is weird and wrong but fast). > > The recent addition to the group is Fedora community, specifically in it's > implementation of beaker. I'm going to get ahold of luke tomorrow to > verify and test some stuff but I think this line in the config: > > beaker.cache.url = memcached1;memcached > > I'm not sure how beaker reads that, but I suspect it might be only sending > information to memcached1 and ignoring memcached2 altogether. If this > theory holds it'd explain why memcached1 not only has a higher request > rate but also a higher hit rate because I suspect fedoracommunity requests > some of the same info over and over again compared to the wiki which > probably has a broader data pool it pulls from. > easy test: reverse that: beaker.cache.url = memcached2;memcached1 and see if the cache hit ratio reverses itself. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Fwd: [puppet] Sign up for transifex error notifications.
Should we set this to send messages to an admin wide alias?
fedora-infrastructure-list might be a little broad but
ad...@fedoraproject.org or something?
---
diff --git a/modules/transifex/templates/00-default.conf.erb
b/modules/transifex/templates/00-default.conf.erb
index fa7ad88..172c750 100644
--- a/modules/transifex/templates/00-default.conf.erb
+++ b/modules/transifex/templates/00-default.conf.erb
@@ -23,6 +23,7 @@ ADMINS = (
('Diego Burigo Zacarao', 'dieg...@gmail.com'),
('Dimitris Glezos', 'dimit...@glezos.com'),
('Ignacio Vazquez-Abrams', 'ivazquez...@gmail.com'),
+ ('Ricky Zhou', 'ri...@fedoraproject.org'),
)
MANAGERS = ADMINS
-Toshio
signature.asc
Description: OpenPGP digital signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Packagedb 0.3.x branch closed; 0.4.x open
Hi, I've branched 0.4.x as the new stable development branch of the packagedb. If you have bugfixes you should commit them there. If you have features that do not remove or change the API incompatibly (ie, removing URLs served or changing the parameters that the URLs take) you may commit them to 0.4.x if you want. If you have API changing features to add, please use the fedora-packagedb-devel branch for that. This will branch for 0.5.x sometime in the Fall/Winter. Please do not use the 0.3.x branch. We won't be attempting to pull from it anymore. Thanks! -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Travelling
I'm going to be going to Brazil for FISL and a FUDCon this week. I'm not sure what my Internet situation is going to be but if anything comes up send me a message and I'll work on it once I get the message. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: PackageDB release candidate testing
On 06/14/2009 07:12 AM, Toshio Kuratomi wrote: > If anyone would like to test the PackageDB release for Monday, I now > have a release candidate running in the staging environment and packages > built for cvsadmins to install and test the admin client. > > The web interface is here: > https://admin.stg.fedoraproject.org/pkgdb > > > Client software for Fedora is built in koji: > python-fedora-0.3.13.1 for Fedora: > https://koji.fedoraproject.org/koji/packageinfo?packageID=5050 > EPEL-5 python-fedora: > > http://buildsys.fedoraproject.org/plague-results/fedora-5-epel/python-fedora/0.3.13.1-1.el5/ > > Fedora PackageDB Client Packages are being built in koji. When done, > you should be able to download the client packages from: > F-12 http://koji.fedoraproject.org/koji/taskinfo?taskID=1413140 > F-11 http://koji.fedoraproject.org/koji/taskinfo?taskID=1413141 > F-10 http://koji.fedoraproject.org/koji/taskinfo?taskID=1413142 > F-9 http://koji.fedoraproject.org/koji/taskinfo?taskID=1413143 > > For EL-5 fedora-packagedb, please get the packages from: > http://toshio.fedorapeople.org/pkgdb/ > Note: When testing the new pkgdb-client you'll want to set the server it talks to. This can be done by making the following entry in ~/.fedora/pkgdb-client.cfg:: [global] pkgdb.url = 'https://admin.stg.fedoraproject.org/pkgdb' -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
PackageDB release candidate testing
If anyone would like to test the PackageDB release for Monday, I now have a release candidate running in the staging environment and packages built for cvsadmins to install and test the admin client. The web interface is here: https://admin.stg.fedoraproject.org/pkgdb Client software for Fedora is built in koji: python-fedora-0.3.13.1 for Fedora: https://koji.fedoraproject.org/koji/packageinfo?packageID=5050 EPEL-5 python-fedora: http://buildsys.fedoraproject.org/plague-results/fedora-5-epel/python-fedora/0.3.13.1-1.el5/ Fedora PackageDB Client Packages are being built in koji. When done, you should be able to download the client packages from: F-12 http://koji.fedoraproject.org/koji/taskinfo?taskID=1413140 F-11 http://koji.fedoraproject.org/koji/taskinfo?taskID=1413141 F-10 http://koji.fedoraproject.org/koji/taskinfo?taskID=1413142 F-9 http://koji.fedoraproject.org/koji/taskinfo?taskID=1413143 For EL-5 fedora-packagedb, please get the packages from: http://toshio.fedorapeople.org/pkgdb/ -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: AGPLv3 and GPLv2
On 06/10/2009 09:28 PM, Luke Macken wrote: > On Wed, Jun 10, 2009 at 04:17:57PM -0500, Mike McGrath wrote: >> So without knowing it we started using AGPLv3 code in our environment >> recently for fedora community and moksha. In the past I think all of our >> stuff has been GPL(ish) mostly GPLv2 (toshio correct me if I'm wrong >> there) >> >> I want to make sure we're all aware of what we can and can'd do as far as >> mixing the code between the two as this could be very unfortunate. >> >> Luke, you described the AGPLv3 as "crucial". Can you let the rest of us >> know why the GPLv2 wouldn't work? > > Using GPLv2 would allow $BIG_EVIL_CORPORATION to take our code and run it > publicly on their servers without making the source available. The AGPL fixes > this issue, which is known as the "application service provider loophole", and > would require them to put a link to the source code if one existed in the > original copy. This is why you will see links to the Moksha and Fedora > Community source code at the bottom of every page. > > I am not a lawyer, nor do I play one on television. Someone smarter than I > can > elaborate further, or correct any false assumptions that we have made. > > More details from Wikipedia: > > """ > Both versions of the AGPL were designed to close a perceived application > service provider "loophole" (the "ASP loophole") in the ordinary GPL, where by > using but not distributing the software, the copyleft provisions are not > triggered. Each version differs from the version of the GNU GPL on which it is > based in having an additional provision addressing use of software over a > computer network. The additional provision requires that the complete source > code be made available to any network user of the AGPL-licensed work, > typically > a web application. > > The Free Software Foundation has recommended that the GNU AGPLv3 be considered > for any software that will commonly be run over a network.[2] The Open Source > Initiative approved the GNU AGPLv3[3] as an Open Source license in March 2008 > after Funambol submitted it for consideration[4] > > [...] > > Compatibility with the GPL > > Both versions of the AGPL, like the corresponding versions of the GNU GPL on > which they are based, are strong copyleft licenses. In the FSF's judgment, the > additional requirement in section 2(d) of AGPLv1 made it incompatible with the > otherwise nearly identical GPLv2. That is to say, one cannot distribute a > single work formed by combining components covered by each license. > > By contrast, GPLv3 and AGPLv3 each include clauses (in section 13 of each > license) that together achieve a form of mutual compatibility for the two > licenses. These clauses explicitly allow the "conveying" of a work formed by > linking code licensed under the one license against code licensed under the > other license.[7] In this way, the copyleft of each license is relaxed to > allow > distribution of such combinations. """ > Unfortunately, this section doesn't help us at all as we have no GPLv3 code to worry about at the moment. spot, we need a quick course on what the AGPL means for us WRT mixing code and whether it makes sense for us to relicense all of our web apps (where the copyright holders agree). -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Won't be around today
Hey guys, my wife's sick and I have to take over for her chaperoning a school field trip. I'm going to take the day off but I should be around late afternoon/tonight. If there's anything you need, just let me know via email or pinging on IRC tonight. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] the new package name is perl-DateManip
On 06/05/2009 12:23 PM, Mike McGrath wrote: > I should explain this better, I want to change it because it's causing > some issues in staging, but it will cause this package to get updated on > bapp1. Should be low risk. > +1 -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] This was causing issues, can I get 2 +1's?
On 06/04/2009 02:47 PM, Seth Vidal wrote: > > > On Thu, 4 Jun 2009, Mike McGrath wrote: > >> --- >> manifests/services/fedoracommunity.pp | 186 >> - >> 1 files changed, 0 insertions(+), 186 deletions(-) >> delete mode 100644 manifests/services/fedoracommunity.pp > > That's a lot of deletions - what do the fcommunity folks say? > > I'll give a +1 but I'm wondering what might be being broken by that > It was committed yesterday but probably shouldn't have been. Nothing depends on it yet as it's not deployed via puppet yet. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] This was causing issues, can I get 2 +1's?
On 06/04/2009 02:45 PM, Mike McGrath wrote:
> ---
> manifests/services/fedoracommunity.pp | 186
> -
> 1 files changed, 0 insertions(+), 186 deletions(-)
> delete mode 100644 manifests/services/fedoracommunity.pp
>
> diff --git a/manifests/services/fedoracommunity.pp
> b/manifests/services/fedoracommunity.pp
> deleted file mode 100644
> index 7b83e5b..000
> --- a/manifests/services/fedoracommunity.pp
> +++ /dev/null
> @@ -1,186 +0,0 @@
> -class bodhi-proxy inherits httpd {
> -apachefile { "/etc/httpd/conf.d/admin.fedoraproject.org/bodhi.conf":
> -source => "web/bodhi-proxy.conf"
> -}
> -
> -apachefile { "/etc/httpd/conf.d/admin.fedoraproject.org/bodhi-dev.conf":
> -source => "web/bodhi-dev-proxy.conf"
> -}
> -}
> -
> -class bodhi-supervised-server inherits turbogears {
> -include supervisorApp
> -
> -package { bodhi-server:
> -ensure => present
> -}
> -
> -templatefile { '/etc/bodhi/bodhi.cfg':
> -content => template('web/applications/bodhi-prod.cfg.erb'),
> -owner => 'apache',
> -group => 'apache',
> -notify => Service['supervisord'],
> -mode => '640',
> -require => Package['bodhi-server'],
> -}
> -}
> -
> -class bodhi-wsgi-server inherits turbogears {
> -include httpd
> -include mod_wsgi::module
> -
> -package { bodhi-server:
> -ensure => present
> -}
> -
> -templatefile { '/etc/bodhi/bodhi.cfg':
> -content => template('web/applications/bodhi-prod.cfg.erb'),
> -owner => 'apache',
> -group => 'apache',
> -notify => Service['httpd'],
> -require => Package['httpd'],
> -mode => '640',
> -require => Package['bodhi-server']
> -}
> -
> -apachetemplate { '/etc/httpd/conf.d/bodhi.conf':
> -content => template('web/applications/bodhi.conf.erb'),
> -require => Package['mod_wsgi']
> -}
> -
> -folder { "/etc/pki/bodhi/":
> -owner => 'apache',
> -group => 'apache',
> -mode => '0710',
> -source => "blank/"
> -}
> -
> -cert { '/etc/pki/bodhi/bodhi.pem':
> -source => 'secure/bodhi_key_and_cert.pem',
> -owner => 'apache',
> -mode => '0440'
> -}
> -
> -# The next two are actually public keys
> -configfile { '/etc/pki/bodhi/fedora-server-ca.cert':
> -source => 'secure/fedora-ca.cert',
> -}
> -
> -configfile { '/etc/pki/bodhi/fedora-upload-ca.cert':
> -source => 'secure/fedora-ca.cert',
> -}
> -
> -#apachefile { '/etc/bodhi.wsgi':
> -apachefile { '/usr/share/bodhi/bodhi.wsgi':
> -source => 'web/applications/bodhi.wsgi',
> -require => Package['mod_wsgi']
> -}
> -
> -}
> -
> -class bodhi-app inherits bodhi-wsgi-server {
> -
> -file { [ '/mnt/koji', '/mnt/koji/packages' ]:
> -ensure => directory
> -}
> -
> -case $datacenter {
> -'phx': {
> -mount { "/mnt/koji/packages":
> -device => "nfs1.fedora.phx.redhat.com:/mnt/koji/packages",
> -fstype => "nfs",
> -ensure => "mounted",
> -options => "defaults,ro,soft,intr,nfsvers=3",
> -atboot => true
> -}
> -}
> -}
> -
> -}
> -
> -class bodhi-masher inherits bodhi-wsgi-server {
> -
> -Templatefile['/etc/bodhi/bodhi.cfg'] {
> - content => template('web/applications/bodhi-masher.cfg.erb'),
> -owner => 'masher',
> -}
> -
> -file { '/etc/bodhi/f9-updates.mash':
> -owner => 'masher',
> -replace => false,
> - require => Package['bodhi-server'],
> -}
> -
> -file { '/etc/bodhi/f9-updates-testing.mash':
> -owner => 'masher',
> -replace => false,
> - require => Package['bodhi-server'],
> -}
> -
> -file { '/etc/bodhi/f8-updates.mash':
> -owner => 'masher',
> -replace => false,
> - require => Package['bodhi-server'],
> -}
> -
> -file { '/etc/bodhi/f8-updates-testing.mash':
> -owner => 'masher',
> -replace => false,
> - require => Package['bodhi-server'],
> -}
> -
> -file { '/etc/bodhi/mash.conf':
> -owner => 'masher',
> -replace => false,
> - require => Package['bodhi-server'],
> -}
> -
> -
> -Apachetemplate['/etc/httpd/conf.d/bodhi.conf'] {
> -content => template('web/applications/bodhi-masher.conf.erb'),
> -}
> -
> -folder { '/var/log/bodhi':
> - source => 'blank/',
> -ensure => directory,
> -owner => 'masher',
> -replace => false,
> -}
> -
> -folder { '/usr/share/bodhi':
> - source => 'blank/',
> -ensure => directory,
> -owner => 'masher',
> -replace => false,
> - require => Package['bodhi-server'],
> -}
> -
> -Folder["/etc/pki/bodhi/"] {
> -owner => 'masher',
> -group => 'masher',
> -mo
Re: [PATCH] Added hosted-content group to secondary1
On 06/04/2009 12:05 PM, Mike McGrath wrote:
> ---
> .../nodes/secondary1.fedora.phx.redhat.com.pp |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/manifests/nodes/secondary1.fedora.phx.redhat.com.pp
> b/manifests/nodes/secondary1.fedora.phx.redhat.com.pp
> index 0b98229..04701bf 100644
> --- a/manifests/nodes/secondary1.fedora.phx.redhat.com.pp
> +++ b/manifests/nodes/secondary1.fedora.phx.redhat.com.pp
> @@ -1,5 +1,5 @@
> node secondary1{
> -$groups='sysadmin-main,sysadmin-noc,alt-sugar,alt-k12linux,altvideos'
> +
> $groups='sysadmin-main,sysadmin-noc,alt-sugar,alt-k12linux,altvideos,hosted-content'
> include global
> include fas::fas
> include secondaryMirror
Seems to be low impact.
+1
-Toshio
signature.asc
Description: OpenPGP digital signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: httpd update on servers
On 05/29/2009 02:11 PM, Mike McGrath wrote: > I'd like to update httpd on our web servers and proxy boxes. > > https://rhn.redhat.com/errata/RHSA-2009-1075.html > > 2+1's? > +1 -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: haproxy update
On 05/29/2009 02:15 PM, Mike McGrath wrote: > while I'm doing the httpd update, I'd like to update haproxy as well as > there were a number of change fixes that would be good to have in place > for the release: > > http://haproxy.1wt.eu/download/1.3/src/CHANGELOG-1.3.18.X > > 2+1's? > +1 -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Change request - Proxy1 (x86_64)
On 05/29/2009 02:32 PM, Ricky Zhou wrote: > On 2009-05-29 04:31:18 PM, Mike McGrath wrote: >> This one's an oops, probably on me. I happened to notice proxy1 is an >> x86_64 box. We have two options. >> >> 1) double it's ram >> >> 2) rebuild it as x86 >> >> I'd prefer to do 2 since the release slipped again and we've generally got >> time for it. The concern is the boxes are tuned for i686 with 4G of ram >> and don't generally like to operate if either of those change. > +1 to 2 > +1 to 2 -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] Add requested redirects for release notes.
On 05/28/2009 11:05 AM, Mike McGrath wrote: On Thu, 28 May 2009, Ricky Zhou wrote: On 2009-05-28 09:22:09 AM, Mike McGrath wrote: I'm wondering if we should: RewriteRule ^/release-notes/f10preview(.*) /release-notes/f10$1 [R,L] RewriteRule ^/release-notes/f11preview(.*) /release-notes/f11$1 [R,L] What do you think? The plain Redirect will actually work as well, they were pretty smart about designing it, so it'll redirect /release-notes/f11preview/blah.html to /release-notes/f11/blah: http://httpd.apache.org/docs/2.2/mod/mod_alias.html#redirect K, then +1 from me. We need one more +1 if anyone is so inclined. +1 -Toshio ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] Make bacula backup to /bacula/, include db1's db3 dumps.
On 05/26/2009 08:47 AM, Mike McGrath wrote: On Tue, 26 May 2009, Ricky Zhou wrote: Sorry, the commit message wasn't as clear as it could have been. backup1 has been running out of space on catalog backup jobs, as it makes a temporary dump of the bacula database in /var/spool/bacula/bacula.sql. This commit moves this temporary dump to /bacula, which has more space. The other thing in this commit is that it adds /var/lib/mysql/backups into the include list, which makes bacula backup db1's backup of db3. Currently, we're excluding these files, but we're still backing up dumps of db3 in several other places. I'd like to commit these to puppet and run puppet on backup1. Can I get two +1s? +1 +1 -Toshio ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Problems with bugzilla and FAS account
On 05/23/2009 08:32 AM, Ricky Zhou wrote:
On 2009-05-23 12:08:30 PM, Michael Schwendt wrote:
If the FAS backend managed to create a new account in bugzilla, why would
I need to _change_ an existing one myself? Can't it sync bugzilla with my
email change in FAS? (which is what I expected it to do)
This is because at the time of writing, there was no XMLRPC method
exposed for changing a user's email. I just checked now, and there
might be a new method available that we can use. I'll look at
adding this to our scripts soon.
Anyone who changes email in FAS gets a new bugzilla account for the changed
email address? Is that how it's implemented currently?
This is currently implemented as follows: When a user changes their
email in FAS, or changes their membership in the fedorabugs group, a
trigger runs which adds the user to a special queue table. We then run
a script periodically that empties out the queue and creates a BZ
account if one doesn't already exist, and grants privileges to the
accounts. The relevant code for this is in the FAS repo:
git://git.fedorahosted.org/git/fas.git
in scripts/export-bugzilla.* and fas2.sql.
Apologies for not joining in sooner. What ricky's outlined as the
current situation is correct. Michael, what you outlined as a way to
keep the accounts straight would work. I think making the script not
create new accounts (forcing the user to reconcile the fas email and
lack of bugzilla account manually) is the way to go.
Here's an untested, updated export-bugzilla.py script. It emails the
users when an account mismatch occurs (I believe this runs in cron
hourly, so this would send an email once an hour). Does this look good
to you guys?
I'm going to a family reunion this weekend. If someone wants to update
the script sooner, they can (It will need an infrastructure change
request if we put this in place before the release but should be fairly
low risk/easy to revert.)
-Toshio
#!/usr/bin/python -t
__requires__ = 'TurboGears'
import pkg_resources
pkg_resources.require('CherryPy >= 2.0, < 3.0alpha')
import sys
import getopt
import xmlrpclib
import smtplib
from email.Message import Message
import turbogears
import bugzilla
from turbogears import config
turbogears.update_config(configfile="/etc/export-bugzilla.cfg")
from turbogears.database import session
from fas.model import BugzillaQueue
BZSERVER = config.get('bugzilla.url',
'https://bugdev.devel.redhat.com/bugzilla-cvs/xmlrpc.cgi')
BZUSER = config.get('bugzilla.username')
BZPASS = config.get('bugzilla.password')
MAILSERVER = config.get('mail.server', localhost)
ADMINEMAIL = config.get(mail.admin_email, 'ad...@fedoraproject.org')
if __name__ == '__main__':
opts, args = getopt.getopt(sys.argv[1:], '', ('usage', 'help'))
if len(args) != 2 or ('--usage','') in opts or ('--help','') in opts:
print """
Usage: export-bugzilla.py GROUP BUGZILLA_GROUP
"""
sys.exit(1)
ourGroup = args[0]
bzGroup = args[1]
server = bugzilla.Bugzilla(url=BZSERVER, user=BZUSER, password=BZPASS)
bugzilla_queue = BugzillaQueue.query.join('group').filter_by(
name=ourGroup)
no_bz_account = []
for entry in bugzilla_queue:
# Make sure we have a record for this user in bugzilla
if entry.action == 'r':
# Remove the user's bugzilla group
try:
server.updateperms(entry.email, 'rem', (bzGroup,))
except xmlrpclib.Fault, e:
if e.faultCode == 504:
# It's okay, not having this user is equivalent to setting
# them to not have this group.
pass
else:
raise
elif entry.action == 'a':
# Make sure the user exists
try:
server.getuser(entry.email)
except xmlrpclib.Fault, e:
if e.faultCode == 51:
# This user doesn't have a bugzilla account yet
# add them to a list and we'll let them know.
no_bz_account.append(entry)
continue
else:
print 'Error:', e, entry.email, entry.person.human_name
raise
server.updateperms(entry.email, 'add', (bzGroup,))
else:
print 'Unrecognized action code: %s %s %s %s %s' % (entry.action,
entry.email, entry.person.human_name,
entry.person.username, entry.group.name)
# Remove them from the queue
session.delete(entry)
session.flush()
# Mail the people without bugzilla accounts
msg = Message()
for person in no_bz_account:
smtplib.SMTP(MAILSERVER)
message = '''Hello, %(name)s,
As a Fedora packager, we grant you permissions to make changes to bugs in
bugzilla to all Fedora bugs. This lets you work together with other Fedora
developers in an easier fashion. However, t
Change Request - email alias handling
Right now FAS constructs email aliases only for accounts that are
active. This is causing us two problems.
1) We have recently implemented a "bot" status for accounts that makes
it so the account can't be logged into and don't go inactive. This
status needs to be allowed to get email as well.
2) inactive accounts are bouncing mail, not just from the pkgdb which
I've been handling and have a mid-term and long-term plan for fixing but
also for the wiki watch-page function which we currently don't have a
good mid-term plan for. Restoring aliases for inactive accounts seems
like the best short-term solution for this.
Fixing these requires updating the fas server code. Attaching a patch
to hotfix our servers with to do this. The patch has been tested on
fas1.stg successfully.
-Toshio
diff --git a/fas/user.py b/fas/user.py
index 236187b..627cb8e 100644
--- a/fas/user.py
+++ b/fas/user.py
@@ -534,7 +534,7 @@ https://admin.fedoraproject.org/accounts/user/edit/%(username)s
search = unicode(search, 'utf-8', 'replace')
re_search = search.translate({ord(u'*'): ur'%'}).lower()
-people = People.query.filter(and_(People.username.like(re_search), People.status == 'active')).order_by('username')
+people = People.query.filter(and_(People.username.like(re_search), People.status.in_('active', 'bot', 'inactive'))).order_by('username')
emails = {}
# Run filter_private via side effect
for person, discard in ((p, p.filter_private()) for p in people):
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] Creating sftp disable mechanism
Mike McGrath wrote:
> Also disabling sftp on fedorahosted boxes
> ---
> manifests/servergroups/hosted.pp |1 +
> modules/ssh/manifests/init.pp |6 ++
> modules/ssh/templates/sshd_config.erb |2 +-
> 3 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/manifests/servergroups/hosted.pp
> b/manifests/servergroups/hosted.pp
> index 30142e2..24d3720 100644
> --- a/manifests/servergroups/hosted.pp
> +++ b/manifests/servergroups/hosted.pp
> @@ -4,6 +4,7 @@ class hosted {
> $restrictedApp = '/usr/bin/run-git'
> $sshd_config_PasswordAuthentication = 'no'
> $sshd_config_AllowTcpForwarding = 'no'
> +$sshd_config_sftp = '/bin/false'
> include global
> include hosted-server
> include fas::fas
> diff --git a/modules/ssh/manifests/init.pp b/modules/ssh/manifests/init.pp
> index 9c8b62d..4972851 100644
> --- a/modules/ssh/manifests/init.pp
> +++ b/modules/ssh/manifests/init.pp
> @@ -17,6 +17,12 @@ class ssh::sshd {
> default => $sshd_config_StrictModes
> }
>
> +$sshd_config_sftp = $sshd_config_sftp ? {
> +'' => "/usr/libexec/openssh/sftp-server",
> +default => $sshd_config_sftp
> +}
> +
> +
> file { "/etc/ssh/sshd_config":
> content => template("ssh/sshd_config.erb"),
> mode => 0600,
> diff --git a/modules/ssh/templates/sshd_config.erb
> b/modules/ssh/templates/sshd_config.erb
> index ea656ec..2e90a99 100644
> --- a/modules/ssh/templates/sshd_config.erb
> +++ b/modules/ssh/templates/sshd_config.erb
> @@ -116,4 +116,4 @@ X11Forwarding yes
> #Banner /some/path
>
> # override default of no subsystems
> -Subsystemsftp/usr/libexec/openssh/sftp-server
> +Subsystemsftp<%= sshd_config_sftp %>
+1
-Toshio
signature.asc
Description: OpenPGP digital signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Change Freeze (telia1 reboot)
Mike McGrath wrote: > This is a multi-part change request. I'd like to reboot telia1 which > would take app6 noc2 pb14 pt16 smtp-mm1 proxy5 pt15 offline. To do this > I'll mark it dead in the dns servers for the reboot. > > The cause is this box didn't get rebooted during a recent update so the > running xen and xen kernels aren't compatable. We have other servers in > this situation too (that one's on me) but as long as we don't have > problems I don't see any need to reboot them yet. We can wait till after > the freeze to avoid downtime. > > > The impact of this freeze will only impact our test servers and noc2. > > 2+1's? > Looks like lmacken is on board with this (f-community test is on pt16) so +1. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: db2
Mike McGrath wrote: > So xen13 actually seems (might be) fixed now. Hasn't rebooted since the > tech went out. So I want to move the databases that should be on db2, > back to db2. I know lots of work is being done right now though on > various systems so I want to coordinate with everyone. > > Would scheduling downtime for Sunday afternoon work for everyone? > Sunday is Mother's Day. So I won't be doing any work involving the db then but also might not be available to help out. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Any C coders want to help me with something?
Mike McGrath wrote: > On Thu, 30 Apr 2009, Ricky Zhou wrote: >> In some distant future version of FAS, I'd >> like to play with the idea of storing the data in LDAP while handling >> our group sponsorship system in postgres. >> > > Ick > heh :-) I think ricky's approach could work but it would need planning. The idea would be to increase the complexity of FAS but decrease the complexity for everything we deploy that needs authentication. We'd want to examine that assumption in the planning phase to make sure it's actually true for us. For instance, there was the thought that having cached credentials on our servers was preferable to what happens to when the LDAP server goes down. Still a concern? We currently mask a lot of information for the privacy policy, can we do that with LDAP? (Or just not put the information in there?) We let third parties (like the hosts to let packagers try building on ppc, x86_64, etc) use fas to get ssh keys. Would we let them connect to and get that information from the LDAP server instead? We let people use their normal accounts to get a subset of data for authenticating to their web apps while they're developing them. Would we enable the same setup with LDAP? -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: fix u-m-d-l
Matt Domsch wrote: > On Fri, Apr 24, 2009 at 11:48:16PM -0500, Matt Domsch wrote: >> On Fri, Apr 24, 2009 at 07:44:50PM -0500, Matt Domsch wrote: >>> If you see me monkey with u-m-d-l on bapp1, that's what I'm trying to >>> figure out... >> Found it... >> >> update-master-directory-list was trying to be smart and failed. If it >> saw that a directory's ctime hadn't changed, it skipped it and moved >> on. But, a directory's ctime won't change if one of its _subdirectories' >> ctime_ >> changes. Because u-m-d-l runs every 30 minutes or so, it appears to >> catch tree updates mid-flight. In one run it sees updates/10/x86_64/ >> has changed, but that repodata/ under that has not (yet). So it >> marks updates/10/x86_64 as changed and moves on. On the next pass, >> updates/10/x86_64 of course _has not changed_, but it's repodata >> subdir has. This is what it was missing... It would skip processing >> the repodata subdir. >> >> (and yes, this would throw off the crawler too, which people have been >> complaining about being added and removed from the list somewhat >> randomly...) >> >> I'm working on a fix, which will involve changing >> update-master-directory-list. But that should be the only change. > > This is the patch I want to apply on bapp1 to > update-master-directory-list. It ensures that changes in repodata/ > directories are handled, even if the parent directories don't appear > to have changed. It still tries to be smart by not stat()ing files in > a directory which hasn't changed it's ctime. > > Oh what I would give if inotify/dnotify worked on NFS... > > Can I get some +1s? > We'll want this working by release no matter what so +1 to getting the fix out there. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: App3 reboot (request)
Mike McGrath wrote: > Can I get 2 +1's to reboot app3 (which is currently frozen) > > I'd like to power down xen13 and power it back up now that the BMC has > been flashed. There shouldn't be any impact to the users except that > /transifex/ will go down during the reboot. Which shouldn't be a problem > as I believe most people are using /tx/ now anyway. > > 2 +1's ? > pinged glezos and diegobz. Okay from their side as long as we make sure ssh-agent comes back properly afterwards. +1 -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Change Request: database cleanup
A couple weeks ago we were having problems with xen13. db2 was on
xen13. We moved the databases that lived on db2 onto db3. That's been
working out pretty well as db3 was sized to run koji before the latest
round of koji optimizations so it's a pretty powerful box.
However, when we moved the databases we left out the scripts that clean
up the session tables for FAS. This means that everytime a user hits
one of our websites, it makes the FAS database grow. Currently the FAS
db is over 2GB in size with 860MB of that in the visit table.
We can't reclaim the space without running a vacuum full (or dropping
and recreating that table) which would mean downtime. However, we don't
seem to have any performance issues at this time so I'm mostly concerned
with the table continuing to grow rather than getting the space back.
I'd like to apply the following change in puppet which just installs the
cleanup script and cron job onto db3 where it can start working to keep
the visit table at its present level. When we switch back to having db2
separate from db3 we can disable this script on db3 and drop the fas2
database there (which will recover the space).
diff --git a/manifests/services/db.pp b/manifests/services/db.pp
index 8e7587f..e5a6409 100644
--- a/manifests/services/db.pp
+++ b/manifests/services/db.pp
@@ -52,6 +52,17 @@ class kojiDb inherits postgresServer {
source => "system/koji-cleanup-sessions.cron"
}
+cron { db-cleanup-sessions:
+command => "/usr/local/bin/db-cleanup-sessions",
+user => postgres,
+minute => 10,
+ensure => present,
+}
+
+script { '/usr/local/bin/db-cleanup-sessions':
+source => 'db/db-cleanup-sessions',
+require => Package['postgresql8.3-server'],
+}
}
class appDB inherits postgresServer {
-Toshio
signature.asc
Description: OpenPGP digital signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [MirrorManager PATCH] Fix killall path, add requires on psmisc for killall.
Ricky Zhou wrote:
> We recently got some cron mail about a wrong killall path, so here's a
> patch to mirrormanager to fix it.
> ---
> mirrormanager.spec.in |2 +-
> server/logrotate.conf |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mirrormanager.spec.in b/mirrormanager.spec.in
> index cc154b9..8c3d08f 100644
> --- a/mirrormanager.spec.in
> +++ b/mirrormanager.spec.in
> @@ -10,7 +10,7 @@ URL:http://fedorahosted.org/mirrormanager
> Source0:
> https://fedorahosted.org/releases/m/i/%{name}/%{name}-%{version}.tar.bz2
> BuildRoot: %(mktemp -ud
> %{_tmppath}/%{name}-%{version}-%{release}-XX)
> BuildRequires: python
> -Requires: TurboGears, python-IPy, python-GeoIP, wget, yum
> +Requires: TurboGears, python-IPy, python-GeoIP, wget, yum, psmisc
>
> %define py_ver %(echo `python -c "import sys; print
> sys.version[:3]"`)
> %if "%{py_ver}" < "2.5"
> diff --git a/server/logrotate.conf b/server/logrotate.conf
> index ec473e7..733de26 100644
> --- a/server/logrotate.conf
> +++ b/server/logrotate.conf
> @@ -13,6 +13,6 @@
> dateext
> rotate 15
> postrotate
> - /sbin/killall -HUP crawler_perhost
> + /usr/bin/killall -HUP crawler_perhost
> endscript
> }
>
+1
Thanks, ricky
-Toshio
signature.asc
Description: OpenPGP digital signature
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Change Request] Add dirsec to rsyncd.conf on cvs1 for ticket 1327
Kevin Fenzi wrote: > This seems like a pretty safe change, but it's my first puppet change, > so I might have messed something up. ;) > > I also changed the comment on the pkgs rsync target as it was wrongly > saying it was the lookaside cache as well. I could revert that part if > it's thought to risky. ;) > > --- > modules/rsync/files/rsyncd.conf.cvs1 |9 - > 1 files changed, 8 insertions(+), 1 deletions(-) > > diff --git a/modules/rsync/files/rsyncd.conf.cvs1 > b/modules/rsync/files/rsyncd.conf.cvs1 index 356ffc8..93881dc 100644 > --- a/modules/rsync/files/rsyncd.conf.cvs1 > +++ b/modules/rsync/files/rsyncd.conf.cvs1 > @@ -13,7 +13,14 @@ read only = yes > > [pkgs] > path = /cvs/pkgs/ > -comment = CVS Lookaside cache > +comment = Fedora packages CVS > +uid = nobody > +gid = nobody > +read only = yes > + > +[dirsec] > +path = /cvs/dirsec/ > +comment = Dirsec CVS > uid = nobody > gid = nobody > read only = yes > Looks fine +1 -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: sysadmin sponsoring
Ionuț Arțăriși wrote: > Hello, > > I've recently become interested in the openid part of FAS and have > already setup a server on my laptop and began hacking. > > However, I think I would be much more productive using one of the test > servers in the infrastructure as this way I could actually test against > the different openid consumers "in the wild". > > I've already applied to sysadmin-test and am now going to apply to > sysadmin as these seem to be the required steps. > Please sponsor me :) > I'll sponsor you. This is certainly a good thing to look into. You'll have sudo access on the publictest machines. I believe that publictest15 has a test fas instance running. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Change Request] Transifex 0.5.1-2
Xavier Lamien wrote: > 2009/3/30 Mike McGrath : >> On Mon, 30 Mar 2009, Diego Búrigo Zacarão wrote: >> >>> I'm sorry guys, but we had a minor problem with the tar.gz on the previous >>> RPM. >>> Can I have +1's for a new update on app1 to the 0.5.1-2 building? >>> >>> http://buildsys.fedoraproject.org/plague-results/fedora-5-epel/transifex/0.5.1-2.el5/noarch/ >>> >> +1 > > +1 > +1 -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
