Won't be around off-hours
My wife is going to a funeral out of state for a week so I'm home with the kids. I'll still be here normal working hours but not so much outside of those. -Toshio pgp8K38B4jki9.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
FYI, toshio and lmacken going to pycon
Hi guys, lmacken, dmalcolm, and I will be away at Pycon from the 17th thru the 25th. The first half of that will be conference days with meetings, presentations, etc. The second half will be a hackfest. Depending on the reliability of internet there (never a given when you get over a thousand people hitting the wireless network at once ;-) we'll be somewhat available during the second half. The first part less so. If you have any questions for python, turbogears, distribute(setuptools++) people that you think I might get answered, let us know. -Toshio pgpJB6CEVVdEb.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: FYI, toshio and lmacken going to pycon
On Fri, Feb 12, 2010 at 12:00:09PM -0700, Kevin Fenzi wrote: > On Fri, 12 Feb 2010 12:41:57 -0500 > Toshio Kuratomi wrote: > > > Hi guys, lmacken, dmalcolm, and I will be away at Pycon from the 17th > > thru the 25th. The first half of that will be conference days with > > meetings, presentations, etc. The second half will be a hackfest. > > Depending on the reliability of internet there (never a given when > > you get over a thousand people hitting the wireless network at > > once ;-) we'll be somewhat available during the second half. The > > first part less so. > > My Co-worker Sean is running the wireless setup there again, so > hopefully all will go well and the net will hold up fine. ;) There's > new AP hardware this year and in general more infrastructure. > > Say hi to him for me. :) > I sure will! I've noticed that when Sean sets up the wireless infrastructure all goes well and when someone else does it, no one seems to be able to connect ;-) -Toshio pgp9CzR31blkS.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Change Request - Bodhi bugfix
On Tue, Feb 16, 2010 at 06:25:01PM -0500, Luke Macken wrote: > Hey guys, > > I pushed out a new version of bodhi yesterday, which has been working so > far as expected. However, I did break the metrics section of the > application. It doesn't break the core functionality of the > application, and isn't crucial for the No Frozen Rawhide stuff, but it's > a regression with a trivial fix. I'd like to push it out before PyCon, > if possible. > +1 if you can leave the admins with instructions on how to revert if necessary. -Toshio pgpcGq6dwykmc.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
New version of PackageDB in staging
Hello all, The first beta of the new PackageDB is running in our staging environment now. https://admin.stg.fedoraproject.org/pkgdb/ All the features for 0.5.x should be present but there's definitely bugs to be found in the implementation. When you across one, feel free to find me on IRC to report it (abadger1999) or send email to me tos...@fedoraproject.org. If it's not something that I feel will be fixed for 0.5.0, I'll open a ticket on the fedorahosted trac instance for it. URLs should no longer change position but a few minor changes in query parameters may still occur. Many scripts may need to be updated for use with the new version of the packagedb. I'd recommend taking this opportunity to port to the python-fedora client library if at all possible as I'll be maintaining the clientside API there for a while even if the serverside changes. If you need additional serverside URLs wrapped in python-fedora, let me know (code snippets welcomed) and I'll get them into python-fedora for you. The current python-fedora package, 0.3.16 works with what's currently in production. I'm currently testing python-fedora-0.3.16.90 which works with the version in staging. Depending on how many bugs are found and how quickly they're squashed, I'll push python-fedora-0.3.17 or 0.3.18 with the 0.5.x packagedb. python-fedora-0.3.16.90 packages for F-11, F12, F-13, and EL-5 are available here: http://toshio.fedorapeople.org/packages/python-fedora They're signed with my personal gpg key. -Toshio pgpBzTx5XDTgG.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Potential pkgdb-0.5.x release on staging
After a round of bug reports and bug fixing I have a new pkgdb up in the staging environment for testing. I do not know of any problems with this version at the moment so I'd appreciate people who use the pkgdb to change acls frequently or query it for data give it a try and see that everything is working for them. If there's no reports of problems I'll be pushing this to production soon. If I'm available for part of the weekend I'll push it Friday. If not, I'll push it out on Monday. A new python-fedora based on 0.3.16.90 which works with the new pkgdb will be built and pushed into updates-testing at that time as well:: http://toshio.fedorapeople.org/packages/python-fedora/ -Toshio pgpWRP7FFCFiI.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Fwd: Broken dependencies: linphone
On Tue, Mar 16, 2010 at 11:14:55AM -0500, Jeffrey Ollie wrote: > Can the script that generates the mail aliases for the package owners > be modified to only look at owners for current versions? I used to > own linphone and ortp but transferred ownership around the Fedora 8 > timeframe. I'm still listed as an owner for earlier Fedora versions > but it's annoying to get bothered about packages I no longer control. > > I've just committed a fix for this in the pkgdb code. I'm pulling together other easy fixes to the 0.5.1 release that we deployed on Monday and will roll them out before we go into the freeze for the beta. -Toshio pgp5gXjDkH5nQ.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [PATCH] rate limiting rsync copies
On Tue, Mar 23, 2010 at 10:45:43AM -0700, Jesse Keating wrote: > On Tue, 2010-03-23 at 17:26 +, Mike McGrath wrote: > > This is causing disk contention without a limit > > --- > > configs/db/backup-dbs |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/configs/db/backup-dbs b/configs/db/backup-dbs > > index a3a12fa..83ed6c8 100755 > > --- a/configs/db/backup-dbs > > +++ b/configs/db/backup-dbs > > @@ -22,7 +22,7 @@ mv $DEST/$HOSTNAME.new $DEST/$HOSTNAME > > for host in db01 db02 db03; do > > if [ "$host" != $HOSTNAME ]; then > > su - dbbackup -c "ssh $host mkdir -p $DEST/$HOSTNAME" > > -su - dbbackup -c "rsync -azr -e ssh $DEST/$HOSTNAME/* > > $host:$DEST/$HOSTNAME/" > > +su - dbbackup -c "rsync -azr --bwlimit=5000 -e ssh > > $DEST/$HOSTNAME/* $host:$DEST/$HOSTNAME/" > > fi > > done > > > > ACK > +1 -Toshio pgpdmFHnjgOoY.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [PATCH] Ensure that rsync backups are only running one at a time
On Wed, Mar 24, 2010 at 10:54:07AM -0500, Mike McGrath wrote: > --- > configs/db/backup-dbs |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/configs/db/backup-dbs b/configs/db/backup-dbs > index 83ed6c8..7af66fb 100755 > --- a/configs/db/backup-dbs > +++ b/configs/db/backup-dbs > @@ -20,6 +20,8 @@ mv $DEST/$HOSTNAME.new $DEST/$HOSTNAME > > # Sync out > for host in db01 db02 db03; do > +# Sleep if any other rsyncs are already > +while ssh $host "pgrep rsync" | grep -q [0-9]; do sleep 10; done > if [ "$host" != $HOSTNAME ]; then > su - dbbackup -c "ssh $host mkdir -p $DEST/$HOSTNAME" > su - dbbackup -c "rsync -azr --bwlimit=5000 -e ssh $DEST/$HOSTNAME/* > $host:$DEST/$HOSTNAME/" > So this means that among the three db hosts, db01, db02, and db03 we'll have at most one rsync running at any one time. That's going to increase the time to sync some more. I think that this code wonn't quite function properly when more than one backup-dbs script runs on a box at a time... what gets transferred to the remote host will be a mixture of what was in $DEST/$HOSTNAME when the rsync starts and what's in there when the rsync ends.. We would get errors if filenames were removed (ie: a database is removed while the rsync is still procesing). Do to copying the directory prior to rsyncing, I don't think we'll get corruption of the actual dump files -- we'll just get dump files from two separate runs intermingled on the host being backed up to. It doesn't look like the scripts are currently stacking on a single host. They run at every six hours on db01 and db02 (every 12 hours on db03). So the risk of problems at this time doesn't seem too bad. +1 -Toshio pgpctqXPJAa7l.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Change request: smolt_new db
On Wed, Mar 24, 2010 at 11:52:36AM -0500, Dennis Gilmore wrote: > On Wednesday 24 March 2010 11:38:08 am Mike McGrath wrote: > > I forgot to cleanup after myself on db1 a few weeks back. as a result > > there's a smolt_new database that doesn't need to be there. > > > > 2 +1's to drop it? > > > > -Mike > > > > ___ > > infrastructure mailing list > > infrastructure@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/infrastructure > +1 > +1 -Toshoi pgpi6O0Z2DV1y.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Trac logs..
On Thu, Mar 25, 2010 at 09:30:05AM -0500, Mike McGrath wrote: > So our trac syncing has been failing lately. After some debugging I > discovered that A) some projects are logging to projects/*/log/trac.log > and B) we're doing so with debug enabled. Some of these files are HUGE. > Pungi's is over 1.1G. So here's what I'd like to propose. > > 1) Remove all of those log files. > 2) Disable logging (only a small handful have enabled it) > 3) Set the default log level on all future and current projects to ERROR > instead of DEBUG > 4) After the freeze look at how to properly log rotate these files. > > Hosted1 is currently frozen but seeing as how this is impacting backups, > can I get two +1's ? > +1 -Toshio pgpYGet3XbfYO.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Change request: add old pkgdb url to robots.txt
Google and other search engines are currently directing people to the old packagedb urls of:: https://admin.fedoraproject.org/pkgdb/packages/name/[PACKAGENAME] In an effort to get them to stop doing that, I'd like to add this to the admin.fp.o robots.tx file temporarily (maybe a month or so... long enough for search engines to pick up the new urls) Can I get two +1s? diff --git a/modules/httpd/files/robots/robots.txt.admin.fedoraproject.org b/modules/httpd/files/robots/robots.txt.a index 13c9ec8..5a60376 100644 --- a/modules/httpd/files/robots/robots.txt.admin.fedoraproject.org +++ b/modules/httpd/files/robots/robots.txt.admin.fedoraproject.org @@ -1,3 +1,4 @@ User-agent: * Disallow: /voting Disallow: /mirrormanager +Disallow: /pkgdb/packages/name -Toshio pgpTM6rBiSvMv.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Change Request: theme priorities in pkgdb
Christopher Aillon brought up a problem in the current icon code for
PackageDB. It seems that mozilla is sensitive to the icon that is
associated with the firefox web browser. So we shouldn't be showing icons
other than the default or hicolor icon set for firefox or risk trademark
repurcussions.
I've removed the other icons from the pkgdb for now but newer packages with
icons for firefox that get imported into the database could potentially
occur at any time.
Martin Bacovsky has a small patch for pkgdb that prioritises the themes that
are used when choosing an icon. That should be enough to always choose
a proper icon for displaying alongside firefox.
Could I get two +1s for applying this to the app servers?
=== modified file 'pkgdb/applications.py'
--- pkgdb/applications.py 2010-03-15 16:26:59 +
+++ pkgdb/applications.py 2010-03-25 12:30:12 +
@@ -38,7 +38,7 @@
from pkgdb.model import Comment, Application, Icon, IconName, PackageBuild
from pkgdb.model import Tag, Usage, ApplicationUsage, ApplicationTag
-from pkgdb.model import MimeType
+from pkgdb.model import MimeType, Theme
from pkgdb.lib.utils import mod_grp
from pkgdb import release, _
from pkgdb.lib.text_utils import excerpt
@@ -531,15 +531,18 @@
def show(self, *app_name):
app_name = '/'.join(app_name)
-# TODO: themes
-icon_data = session.query(Icon.icon)\
-.join(Icon.name, IconName.applications)\
+icon_data = session.query(Theme.name, Icon.icon)\
+.join(Icon.name, IconName.applications, Icon.theme)\
.filter(Application.name==app_name)\
-.first()
+.all()
+
if not icon_data:
redirect('/static/images/noicon.png')
-return str(icon_data[0])
+icons = dict(icon_data)
+
+# icon theme priority: default > hicolor > whatever
+return str(icons.get('default', None) or icons.get('hicolor', None) or
icons[icons.keys()[0]])
-Toshio
pgpujnplPVhB4.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Change request: add old pkgdb url to robots.txt
On Thu, Mar 25, 2010 at 11:30:02AM -0500, matt_dom...@dell.com wrote: > +1 > > Assuming you don't just want to do a permanent redirect on that pattern > instead... > I thought about it but there are drawbacks: * The URL could be used again... it would just have a different meaning (associated with built packages instead of srpms/source control) * Because of the former, people need to fix the code they have that references it before the meaning is changed. They'll likely ignore a 301 but a 500 forces them to make changes. * Redirects are simple changes but this is even simpler. I may still decide a redirect is appropriate but probably not until after the beta change freeze. Thanks! -Toshio pgpismDkTBrnQ.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Change Request: theme priorities in pkgdb
On Thu, Mar 25, 2010 at 11:55:27AM -0500, Dennis Gilmore wrote: > -1 I think that is a bug in how mozilla as a organisation works and we should > not do anything about it. > Well.. this is a legal issue; we could always stop distributing firefox. But that's really a board call. If we're going to continue distributing firefox then we need to play by the terms of the licenses we've been granted which means that our software has to take care not to violate them. -Toshio pgpgcPe1UvWbN.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Change Request: fedoracommunity upgrade
On Thu, Mar 25, 2010 at 01:25:55PM -0500, Mike McGrath wrote: > On Thu, 25 Mar 2010, Luke Macken wrote: > > > The recent pkgdb update broke fedoracommunity. I have since applied a a > > couple of simple, low-risk fixes to get things working again. I wish to > > push the version in staging out into production. > > > > https://admin.stg.fedoraproject.org/community/ > > > > This code also contains a fix for the bug that caused fedoracommunity to > > flip out when it couldn't access fedorapeople.org, as well as a new > > 'Statistics' section. > > > > Can I get some +1's? > > > > Thanks, > > > > +1 bring 'er back online. > +1 as well. -Toshio pgp5BbdFBVo9l.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Change Request: theme priorities in pkgdb
On Thu, Mar 25, 2010 at 04:19:17PM -0500, Mike McGrath wrote: > On Thu, 25 Mar 2010, Toshio Kuratomi wrote: > > > Christopher Aillon brought up a problem in the current icon code for > > PackageDB. It seems that mozilla is sensitive to the icon that is > > associated with the firefox web browser. So we shouldn't be showing icons > > other than the default or hicolor icon set for firefox or risk trademark > > repurcussions. > > > > I've removed the other icons from the pkgdb for now but newer packages with > > icons for firefox that get imported into the database could potentially > > occur at any time. > > > > Martin Bacovsky has a small patch for pkgdb that prioritises the themes that > > are used when choosing an icon. That should be enough to always choose > > a proper icon for displaying alongside firefox. > > > > Could I get two +1s for applying this to the app servers? > > > > I don't see this as harmful. > > +1 > > -Mike Got a second +1 from lmacken on IRC as well as discussion between dgilmore and caillon about the issues surrounding this. Change applied to app and bapp servers. -Toshio pgpST5fHGA01F.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [PATCH] Removing db2 from commit list
On Thu, Apr 8, 2010 at 2:06 PM, Mike McGrath wrote: > On Thu, 8 Apr 2010, Seth Vidal wrote: > >> >> >> On Thu, 8 Apr 2010, Mike McGrath wrote: >> >> > This still causes our db backups to go to multiple locations. Just one >> > fewer then before >> > db02 is having problems keeping up and it's causing issues to our web >> > services layer >> > in particular with fas. >> > >> > Very low risk, very easy to revert. Can I get 2 +1's? >> >> +1 > +1 -Toshio ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Hosted02 puppet off
Hey, I'm disabling puppet on hosted02 while I test the bzr upgrade. -Toshio pgpJrIZwNG3Ke.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: hotfix request - bump MM max_stale_days back to 7
On Tue, Apr 13, 2010 at 12:16:47AM -0400, Ricky Zhou wrote: > On 2010-04-12 11:03:17 PM, Matt Domsch wrote: > > As we've slowed down releasing updates for existing releases, it can > > be longer than 2 days between pushing updates. In this case, we run > > into the propogation delay between when content gets posted on the > > master, MM picking it up an hour later, and then "drops" the > > now-historical metadata that's older than 2 days - mirrors who haven't > > updated within that hour get ignored by yum with a pretty loud error > > message. > > > > I've got a fix, but await end of change freeze to roll out a new MM > > with the fix. Until then, I'd like to return the config value back to > > 7 days, which papers over the propogation delay much better. > +1 > +1 -Toshio pgpghZiz4XWf8.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [MERGE] Don't crash if user's full name is unset
On Tue, Apr 20, 2010 at 10:22:17AM -0400, Stephen Gallagher wrote: > === modified file 'fedora/django/auth/models.py' > --- fedora/django/auth/models.py 2010-04-19 20:56:48 + > +++ fedora/django/auth/models.py 2010-04-20 14:19:07 + > @@ -122,4 +122,6 @@ > objects = FasUserManager() > > def get_full_name(self): > -return self.name.strip() > +if self.name: > +return self.name.strip() > +return self.username.strip() > Would we rather return username or empty string (u"") in case of error? -Toshio pgpxLLNP4X0P3.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Elections for next terms
On Tue, Apr 20, 2010 at 10:29:55AM -0400, Paul W. Frields wrote: > Hi Infra team, > > With whom should the Board, FESCo, and other elections folks be > coordinating to set up the next round of voting? I believe that > Toshio might have picked this up from Nigel, but I wanted to make > sure. > I haven't. I can help someone else get acquainted since I likely have more access but that's about it. -Toshio pgp6anvvjlUC8.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Elections for next terms
On Tue, Apr 20, 2010 at 07:34:36PM -0400, Paul W. Frields wrote: > On Tue, Apr 20, 2010 at 12:53:47PM -0400, Toshio Kuratomi wrote: > > On Tue, Apr 20, 2010 at 10:29:55AM -0400, Paul W. Frields wrote: > > > Hi Infra team, > > > > > > With whom should the Board, FESCo, and other elections folks be > > > coordinating to set up the next round of voting? I believe that > > > Toshio might have picked this up from Nigel, but I wanted to make > > > sure. > > > > > I haven't. I can help someone else get acquainted since I likely have more > > access but that's about it. > > OK, let's consider this a CTA for Infrastructure participants then. I > know there are several people who have showed up just recently, > looking for things to do. > > If you're interested in helping on the Infrastructure team, one thing > you could help with is setting up and running the upcoming elections. > We have three elections coming up: > > * one for our release name for F14 in just a couple weeks > > * two for the Board and FESCo shortly after that > > The election system is not too difficult to learn or run. Toshio can > help you learn the system, and then you'll need to set up the > elections to run at the appointed time, a couple days ahead of that > time. > > Are there any volunteers? > > Toshio, could you write up those get-acquainted instructions on the > wiki? I can incorporate them into the official elections guide if > people agree that's desirable. > No, I can't. I'm sorry I didn't make it clear above -- I don't currently have experience with the current election software. I can help someone by poking at the running code and examining the database when someone asks me questions about it since i have access to those and they probably do not. Nigel is really the only one who's dealt with the election system as an administrator at all. I've dealt with it as a coder when we first started with it and took another brief look at the login section only when we were working on CSRF fixes to all of our apps. -Toshio pgps06ZjErITT.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Elections for next terms
On Wed, Apr 21, 2010 at 11:58:18AM -0400, Paul W. Frields wrote: > On Wed, Apr 21, 2010 at 10:48:43AM +0100, Mark Chappell wrote: > > Paul W. Frields wrote: > > > > > The election system is not too difficult to learn or run. Toshio can > > > help you learn the system, and then you'll need to set up the > > > elections to run at the appointed time, a couple days ahead of that > > > time. > > > > > > Are there any volunteers? > > > > I'd be interested in helping. (and have read Toshio's disclaimer) > > I did find the /admin/newe and /admin/newc functions which seem pretty > self-explanatory. I didn't want to try them on the production system > obviously, but could we get something on a pt system for noodling just > while I'm formulating that HOWTO? > https://admin.stg.fedoraproject.org/voting Let me know if that's not adequate for our needs -Toshio pgpMX3vYG56b8.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: hosted to rhel6
On Thu, Apr 22, 2010 at 07:48:44AM -0400, Jon Stanley wrote: > also gets us a bzr upgrade, which aiui is an incompatible on-disk > format??? Toshio can you elaborate? The SCM versions that we pick up > in RHEL6 are (all of these are in RHEL proper now): > > bzr-2.0.2-1.1.el6.x86_64 > So... I've already upgrade EPEL-5 to bzr-2.1 which may be longer lived than bzr-2.0 (it's in Ubuntu Lucid; their next long term release). This means we're going to have to rebuild the EPEL-5 packages for Fedora Infrastructure's EL-6 repository. bzr-2.0 is not fully API compatible with bzr-2.1 is not fully API compat with bzr-2.2(in beta). The bzr apps we're running right now work with bzr-2.1, i'm not sure that there's a 2.0 branch for all of them. The on-disk format is no problem -- bzr retains the ability to operate on old on-disk formats. Once we have bzr-2.0 or greater on all released Fedoras and in EPEL-5, though, I'm going to upgrade the ondisk format for the bzr repositories on the server which will cause bzr-1.x clients to break and people to need to run bzr upgrade on their checkouts. (launchpad already uses the 2a format so most people already need to have a more modern client). -Toshio pgpyfAVeTurcu.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Newcomer - Hello world!
On Tue, May 04, 2010 at 04:55:11PM -0400, Rick Elrod wrote: > Hello everyone, my name is Ricky Elrod, and I am looking to participate in an > open source project that allows me to use my knowledge of networking and > programming, and is a good community to work with. After doing some reading, > the fedora infrastructure team looks like the place for me. I am a senior in > high school, and already registered at a local university (The University of > Akron) to major in Computer Science in Fall of this year (immediately after > high school). > > In high school, I participated in a Cisco class which gave me knowledge of > networking concepts, such as dealing with Cisco-specific technologies, along > with general networking, such as subnetting. In the programming world, I know > quite a few scripting languages, such as PHP, Python, and Perl, and I am > currently learning my first compiled language, Java. In the future I plan on > learning C and C++, as time permits. I am active on IRC under the nick > CodeBlock, on freenode and a few other networks, such as slashnet, and a > small network I help administrate, Ninthbit. > > mmcgrath is willing to sponsor me, after I spoke to him on IRC. He listed a > few FIGs in need of help, and I would like to join sysadmin-hosted, and help > out with fedorahosted. > > Any other questions, just ask! I look forward to working with everyone. > Welcome aboard! I'm ababdger1999 on freenode if you need any help with python coding or packaging I can help or at least, point you towards a better resource :-) -Toshio pgpIQIIn2EtWj.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [Change Request] Add trac xmlrpc plugin.
On Thu, May 06, 2010 at 08:18:09AM -0500, Mike McGrath wrote:
> On Thu, 6 May 2010, Ricky Zhou wrote:
>
> > ---
> > manifests/services/hosted.fedoraproject.org.pp |5 +
> > modules/trac/manifests/init.pp |1 +
> > 2 files changed, 6 insertions(+), 0 deletions(-)
> >
> > diff --git a/manifests/services/hosted.fedoraproject.org.pp
> > b/manifests/services/hosted.fedoraproject.org.pp
> > index 3d14cfc..9e2c06b 100644
> > --- a/manifests/services/hosted.fedoraproject.org.pp
> > +++ b/manifests/services/hosted.fedoraproject.org.pp
> > @@ -101,6 +101,11 @@ class hosted-server {
> > package { trac-tickettemplate-plugin:
> > ensure => present,
> > }
> > +
> > +package { "trac-xmlrpc-plugin":
> > +ensure => installed,
> > +}
> > +
> > package { babel:
> > ensure => present,
> > }
> > diff --git a/modules/trac/manifests/init.pp b/modules/trac/manifests/init.pp
> > index 6197ed1..c755ea5 100644
> > --- a/modules/trac/manifests/init.pp
> > +++ b/modules/trac/manifests/init.pp
> > @@ -14,6 +14,7 @@ class trac::app {
> > "trac-privateticketsplugin",
> > "trac-customfieldsadmin-plugin",
> > "trac-peerreview-plugin",
> > +"trac-xmlrpc-plugin",
> > "email2trac",
> > ]:
> > ensure => installed,
>
> +1
>
+1
-Toshio
pgpFpE0wdtgj0.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Change Request: Race condition syncing static websites to proxies
mmcgrath noted that we have a race condition in our syncStatic.sh script that is leading to proxies not having copies of the website. Here's a patch to the syncStatic script to fix that: diff --git a/modules/fedora-web/files/syncStatic.sh b/modules/fedora-web/files/syncStatic.sh index 23f5181..9c1b7ac 100644 --- a/modules/fedora-web/files/syncStatic.sh +++ b/modules/fedora-web/files/syncStatic.sh @@ -26,7 +26,7 @@ cd fedora-web pushd fedoraproject.org > /dev/null make > /dev/null 2>&1 -rsync -qa --delete out/* /srv/web/fedoraproject.org/ +rsync -qa --delete out/ /srv/web/fedoraproject.org/ popd > /dev/null # Make sure everything else builds from master. @@ -34,26 +34,22 @@ popd > /dev/null /usr/bin/git checkout -q master || exit 1 pushd spins.fedoraproject.org > /dev/null -/bin/rm -rf /srv/web/spins.fedoraproject.org/* make > /dev/null 2>&1 -rsync -qa --delete out/* /srv/web/spins.fedoraproject.org/ +rsync -qa --delete out/ /srv/web/spins.fedoraproject.org/ popd > /dev/null pushd talk.fedoraproject.org > /dev/null -/bin/rm -rf /srv/web/talk.fedoraproject.org/* make > /dev/null 2>&1 -rsync -qa --delete out/* /srv/web/talk.fedoraproject.org/ +rsync -qa --delete out/ /srv/web/talk.fedoraproject.org/ popd > /dev/null pushd boot.fedoraproject.org > /dev/null -/bin/rm -rf /srv/web/boot.fedoraproject.org/* make > /dev/null 2>&1 -rsync -qa --delete out/* /srv/web/boot.fedoraproject.org/ +rsync -qa --delete out/ /srv/web/boot.fedoraproject.org/ popd > /dev/null pushd start.fedoraproject.org > /dev/null -/bin/rm -rf /srv/web/start.fedoraproject.org/* make > /dev/null 2>&1 -rsync -qa --delete out/* /srv/web/start.fedoraproject.org/ +rsync -qa --delete out/ /srv/web/start.fedoraproject.org/ popd > /dev/null The patch does two things: 1) Removes the rm -rf step as that is causing the race (when proxies sync data after the rm -rf and before hte rsync, they get an empty directory) 2) Removes the wildcard from the rsync. The wildcard was preventing the --delete from functioning as expected. I believe (but ricky can confirm) that the --delete not removing files that are no longer needed from the final output directory is why we had the rm -rf in the first place. Could I get two +1's for this change? -Toshio pgpsf0Sfk80Ef.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Change Request: Race condition syncing static websites to proxies
On Tue, May 11, 2010 at 02:21:38PM -0500, Dennis Gilmore wrote: > On Tuesday 11 May 2010 01:19:09 pm Mike McGrath wrote: > > On Tue, 11 May 2010, Toshio Kuratomi wrote: > > > mmcgrath noted that we have a race condition in our syncStatic.sh script > > > that is leading to proxies not having copies of the website. Here's a > > > patch to the syncStatic script to fix that: > > > [ old patch snipped] > > > The patch does two things: > > > > > > 1) Removes the rm -rf step as that is causing the race (when proxies sync > > > data after the rm -rf and before hte rsync, they get an empty directory) > > > > > > 2) Removes the wildcard from the rsync. The wildcard was preventing the > > > --delete from functioning as expected. I believe (but ricky can confirm) > > > that the --delete not removing files that are no longer needed from the > > > final output directory is why we had the rm -rf in the first place. > > > > > > Could I get two +1's for this change? > > > > > > -Toshio > > > > +1 from me, this was causing problems. > +1 With feedback from mdomsch and skvidal, here's a new version of the patch that does --delay-update and --delete-after. This will trade space (which we currently seem to have enough of on bapp01) for less chance of races while the changes are being put into place. Two +1's to this version? diff --git a/modules/fedora-web/files/syncStatic.sh b/modules/fedora-web/files/syncStatic.sh index 23f5181..8affac3 100644 --- a/modules/fedora-web/files/syncStatic.sh +++ b/modules/fedora-web/files/syncStatic.sh @@ -26,7 +26,7 @@ cd fedora-web pushd fedoraproject.org > /dev/null make > /dev/null 2>&1 -rsync -qa --delete out/* /srv/web/fedoraproject.org/ +rsync -qa --delete-after --delay-update out/ /srv/web/fedoraproject.org/ popd > /dev/null # Make sure everything else builds from master. @@ -34,26 +34,22 @@ popd > /dev/null /usr/bin/git checkout -q master || exit 1 pushd spins.fedoraproject.org > /dev/null -/bin/rm -rf /srv/web/spins.fedoraproject.org/* make > /dev/null 2>&1 -rsync -qa --delete out/* /srv/web/spins.fedoraproject.org/ +rsync -qa --delete-after --delay-update out/ /srv/web/spins.fedoraproject.org/ popd > /dev/null pushd talk.fedoraproject.org > /dev/null -/bin/rm -rf /srv/web/talk.fedoraproject.org/* make > /dev/null 2>&1 -rsync -qa --delete out/* /srv/web/talk.fedoraproject.org/ +rsync -qa --delete-after --delay-update out/ /srv/web/talk.fedoraproject.org/ popd > /dev/null pushd boot.fedoraproject.org > /dev/null -/bin/rm -rf /srv/web/boot.fedoraproject.org/* make > /dev/null 2>&1 -rsync -qa --delete out/* /srv/web/boot.fedoraproject.org/ +rsync -qa --delete-after --delay-update out/ /srv/web/boot.fedoraproject.org/ popd > /dev/null pushd start.fedoraproject.org > /dev/null -/bin/rm -rf /srv/web/start.fedoraproject.org/* make > /dev/null 2>&1 -rsync -qa --delete out/* /srv/web/start.fedoraproject.org/ +rsync -qa --delete-after --delay-update out/ /srv/web/start.fedoraproject.org/ popd > /dev/null -Toshio pgpc2HdCBTQvV.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [PATCH] haproxy & mirrorlist processes
On Tue, May 11, 2010 at 02:48:23PM -0500, Matt Domsch wrote: > The mirrorlists are falling over - haproxy keeps marking app servers > as down, and some requests are getting HTTP 503 Server Temporarily > Unavailable responses. This happens every 10 minutes, for 2-3 > minutes, as several thousand EC3 instances request the mirrorlist > again. > > For reference, we're seeing a spike of over 2000 simultaneous requests > across our 6 proxy and 4 app servers, occuring every 10 minutes, > dropping back down to under 20 simultaneous requests inbetween. > > Trying out several things. > > 1) increase number of mirrorlist WSGI processes on each app server >from 45 to 100. This is the maximum number of simultaneous >mirrorlist requests that each server can serve. I've tried this >value on app01, and running this many still keeps the >mirrorlist_server back end (which fork()s on each connection) >humming right along. I think this is safe. Increasing much beyond >this though, the app servers will start to swap, which we must >avoid. We can watch the swapping, and if it starts, lower this >value somewhat. The value was 6 just a few days ago, which wasn't >working either. > >This gives us 400 slots to work with on the app servers. > This seems okay as a temporary measure but we won't want this as a permanent fix unless we can get more RAM for the app servers or separate app servers for the mirrorlist processes. The reason is that running close to swap means that we don't have room to grow the other services if they need it, increase the mirrorlist processes if we need even more slots, or add new services. +1 > 2) try limiting the number of connections from each proxy server to >each app server, to 25 per. Right now we're seeing a max of >between 60 and 135 simultaneous requests from each proxy server to >each app server. All those over 25 will get queued by haproxy and >then served as app server instances become available. I did this >on proxy03, and it really helped out the app servers and kept them >humming. There were still some longish response times (some >30 >seconds). > >We're still oversubscribing app server slots here though, but >oddly, not by as much as you'd think, as proxy03 is taking 40% of >the incoming requests itself for some reason. > This does seem like a good thing to try and then decide if we want it permanently. +1 > 3) bump the haproxy timeout up to 60 seconds. 5 seconds (the global >default) is way too low when we get the spikes. This was causing >haproxy to think app servers were down, and start sending load to >the other app servers, which would then overload, and then start >sending to the first backup server, ... Let's be nicer. If during >a spike it takes 60 seconds to get an answer, or be told HTTP 503, >so be it. > 60 seconds seems a bit long when something does happen to a single server that should take it out of rotation for a bit. We aren't likely to purposefully be doing things that take down app server during change freeze but it's probably not a good idea to be quite this high in the long run. Something to do for now but tweak some after the release? +1 > 4) have haproxy use all the backup servers when all the app servers >are marked down. Right now it sends all the requests to a single >backup server, and if that's down, all to the next backup server, >etc. We know one server can't handle the load (even 4 aren't >really), so don't overload a single backup either. > +1 > 5) the default mirrorlist_server listen backlog is only 5, meaning >that at most 5 WSGI clients get queued up if all the children are >busy. To handle spikes, bump that to 300 (though it's limited by >the kernel to 128 by default). This was the intent, but the code was > buggy. > +1 > 6) bug fix to mirrorlist_server to not ignore SIGCHLD. Amazing this >ever worked in the first place. This should resolve the problem >where mirrorlist_server slows down and memory grows over time. > +1 > > diff --git a/modules/haproxy/files/haproxy.cfg > b/modules/haproxy/files/haproxy.cfg > index 6e538ed..5a6fda0 100644 > --- a/modules/haproxy/files/haproxy.cfg > +++ b/modules/haproxy/files/haproxy.cfg > @@ -43,15 +43,17 @@ listen fp-wiki 0.0.0.0:10001 > > listen mirror-lists 0.0.0.0:10002 > balance hdr(appserver) > -server app1 app1:80 check inter 5s rise 2 fall 3 > -server app2 app2:80 check inter 5s rise 2 fall 3 > -server app3 app3:80 check inter 5s rise 2 fall 3 > -server app4 app4:80 check inter 5s rise 2 fall 3 > -server app5 app5:80 backup check inter 10s rise 2 fall 3 > -server app6 app6:80 backup check inter 10s rise 2 fall 3 > -server app7 app7:80 check inter 5s rise 2 fall 3 > -server bapp1 bapp1:80 backup check inter 5s rise 2 fall 3 > +timeout connect 60s > +server app1 app1:80 check
Re: [PATCH] haproxy & mirrorlist processes (root cause, more fixes)
On Tue, May 11, 2010 at 11:20:58PM -0500, Matt Domsch wrote: > On Tue, May 11, 2010 at 02:48:23PM -0500, Matt Domsch wrote: > > The mirrorlists are falling over - haproxy keeps marking app servers > > as down, and some requests are getting HTTP 503 Server Temporarily > > Unavailable responses. This happens every 10 minutes, for 2-3 > > minutes, as several thousand EC3 instances request the mirrorlist > > again. > > > > For reference, we're seeing a spike of over 2000 simultaneous requests > > across our 6 proxy and 4 app servers, occuring every 10 minutes, > > dropping back down to under 20 simultaneous requests inbetween. > > > > Trying out several things. > > > > 1) increase number of mirrorlist WSGI processes on each app server > >from 45 to 100. This is the maximum number of simultaneous > >mirrorlist requests that each server can serve. I've tried this > >value on app01, and running this many still keeps the > >mirrorlist_server back end (which fork()s on each connection) > >humming right along. I think this is safe. Increasing much beyond > >this though, the app servers will start to swap, which we must > >avoid. We can watch the swapping, and if it starts, lower this > >value somewhat. The value was 6 just a few days ago, which wasn't > >working either. > > > >This gives us 400 slots to work with on the app servers. > > I don't have to do this anymore. I found the source of the problem > (the CPU on the app servers was at 100% utilization, due to another > bug in MM's handling of user input). Fixing that, we don't need > nearly as many workers. > > > > > 2) try limiting the number of connections from each proxy server to > >each app server, to 25 per. Right now we're seeing a max of > >between 60 and 135 simultaneous requests from each proxy server to > >each app server. All those over 25 will get queued by haproxy and > >then served as app server instances become available. I did this > >on proxy03, and it really helped out the app servers and kept them > >humming. There were still some longish response times (some >30 > >seconds). > > > >We're still oversubscribing app server slots here though, but > >oddly, not by as much as you'd think, as proxy03 is taking 40% of > >the incoming requests itself for some reason. > > I'm not going to do these either. > > > > > 3) bump the haproxy timeout up to 60 seconds. 5 seconds (the global > >default) is way too low when we get the spikes. This was causing > >haproxy to think app servers were down, and start sending load to > >the other app servers, which would then overload, and then start > >sending to the first backup server, ... Let's be nicer. If during > >a spike it takes 60 seconds to get an answer, or be told HTTP 503, > >so be it. > > I did bump the timeout to 30 seconds instead of 60. We'll see how > that works. > > > > 4) have haproxy use all the backup servers when all the app servers > >are marked down. Right now it sends all the requests to a single > >backup server, and if that's down, all to the next backup server, > >etc. We know one server can't handle the load (even 4 aren't > >really), so don't overload a single backup either. > > Done. > > > > > 5) the default mirrorlist_server listen backlog is only 5, meaning > >that at most 5 WSGI clients get queued up if all the children are > >busy. To handle spikes, bump that to 300 (though it's limited by > >the kernel to 128 by default). This was the intent, but the code was > > buggy. > > Will do. > > > > 6) bug fix to mirrorlist_server to not ignore SIGCHLD. Amazing this > >ever worked in the first place. This should resolve the problem > >where mirrorlist_server slows down and memory grows over time. > > Will do. > > The root cause of the CPU utilization by mirrorlist_client.wsgi was > that mirrorlist_server.py couldn't deal with malformed arch=i386%80%E2 > style query strings, and was crashing. mirrorlist_client.wsgi would > then spin forever waiting for the server to respond, which it never > would. This patch addresses the malformed input. > > >From 621af2882e984459a23d1e7af3ef1854ea6f0ba1 Mon Sep 17 00:00:00 2001 > From: Matt Domsch > Date: Tue, 11 May 2010 22:57:19 -0500 > Subject: [PATCH 1/2] mirrorlist_client: sanitize input into UTF-8 > > Users may put all sorts of odd URL-escaped characters onto the URLs. > When this happens, mirrorlist_server.py child thread would crash > trying to write the byte string with escaped '\x80' characters inside > it into the error report header. When the child crashes, > mirrorlist_client.wsgi would spin forever eating 100% CPU waiting for > a response from the server that would never come. > > This patch sanitizes the input query args into a byte string that only > contains UTF-8 characters. This fixes this particular source of crash > in the server and subsequ
Re: Change request - remove email2trac from hosted
On Wed, May 12, 2010 at 11:08:29AM -0700, Jesse Keating wrote: > Currently the only consumers of email2trac setup were pungi and rel-eng. > At one time I had somehow disabled email2trac for rel-eng due to the > spam, although I can't remember how I disabled it. Unfortunately > something changed in the past week or two that re-enabled it and a bunch > more spam came through. I'd like to just remove email2trac from our > hosted environment all together. > +1 pgp8GCXb08MFR.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [PATCH] avoid \xZZ in mirrorlist urls
On Wed, May 12, 2010 at 11:05:33PM -0500, Matt Domsch wrote:
> On Wed, May 12, 2010 at 08:59:18PM -0500, Matt Domsch wrote:
> > On Wed, May 12, 2010 at 08:56:12PM -0500, Matt Domsch wrote:
> > > > Hey is there a way to test this on staging first to make sure it grabs
> > > > the URLs. RewriteRules's make my head hurt and I get things backwards
> > > > all the time.
> > >
> > > In staging, I can test whether or not \x gets caught. I can't test
> > > whether it'll catch the ones that are causing the problems from
> > > outside users though. (If I could, I would have been able to find and
> > > fix the root cause, which clearly this isn't).
> > >
> > > I'm open to other ideas. Perhaps what I see in the URL logs isn't
> > > what's actually being sent? I don't know...
> >
> > Here's the symptom. admin.fp.o/status/app01
> >
> > 16-030536 0/1113/1113 W
> > 18.42 11020 0 0.0 10.07 10.07 192.168.1.7
> > app01.phx2.fedoraproject.orgGET
> > /mirrorlist?repo=\xc2\xadfedora-8&arch=i386 HTTP/1.0
> > 63-030713 0/2151/2151 W
> > 38.47 3819 0 0.0 21.13 21.13 192.168.1.7 app01.phx2.fedoraproject.org
> > GET /mirrorlist?repo=\xc2\xadfedora-8&arch=i386 HTTP/1.0
> >
> > In both cases, the jobs are in W state from apache's POV (so
> > responding to the client request), see how long they've been sitting
> > there (11020 and 3819 seconds respectively), and the format of the
> > query args. I send the same thing via wget, and it succeeds, no failure.
>
> OK, having spent a few more hours, I don't need the RewriteRule. Yea!
>
> I just need to convert to unicode, and leave it in unicode. Malformed
> requests fail lookups as would be expected and return the "you asked
> for an invalid repo or arch" message. Good requests return the
> mirrorlist. All is swimmingly.
>
>
> commit 9251a20e8ff8239bae2c74e64ad20a4645423ae9
> Author: Matt Domsch
> Date: Wed May 12 22:59:46 2010 -0500
>
> mirrorlist_client: leave query params as utf8
>
> diff --git a/mirrorlist-server/mirrorlist_client.wsgi
> b/mirrorlist-server/mirrorlist_client.wsgi
> index 3508f19..36077a1 100755
> --- a/mirrorlist-server/mirrorlist_client.wsgi
> +++ b/mirrorlist-server/mirrorlist_client.wsgi
> @@ -93,7 +93,7 @@ def request_setup(request):
>
> for k, v in d.iteritems():
> try:
> -d[k] = unicode(v, 'utf8', 'ignore').encode('utf8')
> +d[k] = unicode(v, 'utf8', 'replace')
> except:
> pass
> return d
>
+1
-Toshio
pgpaDgkKnkkKT.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: change request, create maps for ppc64
On Thu, May 13, 2010 at 10:24:55AM -0500, Dennis Gilmore wrote:
> On Thursday 13 May 2010 10:16:22 am Dennis Gilmore wrote:
> > I want to apply the following patch to make ppc64 a valid arch.
> >
> > I noticed that there were no el6 maps for ppc64 el-6 we are shipping
> > ppc64, i386 and x86_64 this is because RHEL switched the base userland
> > from 32 bit to 64 bit
> >
> > Dennis
> >
> > diff --git a/modules/maps/files/parse9.pl b/modules/maps/files/parse9.pl
> > index 5d35e01..2cfd65d 100755
> > --- a/modules/maps/files/parse9.pl
> > +++ b/modules/maps/files/parse9.pl
> > @@ -47,6 +47,8 @@ sub valid_arch {
> > return 1;
> >} elsif("$arch" eq "ppc") {
> > return 1;
> > + } elsif("$arch" eq "ppc64") {
> > +return 1;
> >} elsif("$arch" eq "ia64") {
> > return 1;
> >} elsif("$arch" eq "sparc") {
>
>
> i want to actually make the change
> diff --git a/modules/maps/files/parse9.pl b/modules/maps/files/parse9.pl
> index 5d35e01..eb8602e 100755
> --- a/modules/maps/files/parse9.pl
> +++ b/modules/maps/files/parse9.pl
> @@ -47,6 +47,8 @@ sub valid_arch {
> return 1;
>} elsif("$arch" eq "ppc") {
> return 1;
> + } elsif("$arch" eq "ppc64") {
> +return 1;
>} elsif("$arch" eq "ia64") {
> return 1;
>} elsif("$arch" eq "sparc") {
> @@ -59,6 +61,10 @@ sub valid_arch {
> return 1;
>} elsif("$arch" eq "arm") {
> return 1;
> + } elsif("$arch" eq "s390") {
> +return 1;
> + } elsif("$arch" eq "s390x") {
> +return 1;
>} else {
> return 0;
>}
>
> the s390 arches are missing also
+1
-Toshio
pgpnkODAn45wb.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [CHANGE REQUEST] Move to new Publican 2.0-generated docs.fedoraproject.org site
On Wed, May 19, 2010 at 08:39:29PM -0400, Nick Bebout wrote: > Thanks to Rudi Landmann's hard work, the Publican-2.0 generated version of > the docs.fedoraproject.org site is now ready to be deployed. We (the docs > team) would really like to get this up before the Fedora 13 release. This > will be a usability and visual improvement, as well as making it so that > docs authors no longer have to manually edit html to add a new document or > a new release, etc. This will be handled by Publican. > > I am asking for 2 +1's for the following patches, all are to > puppet/modules/fedora-docs/files/fedora-docs-proxy.conf: > > [PATCH] Add /public_html onto the end of DocumentRoot > [PATCH] Indexes are not needed for docs.fedoraproject.org > [PATCH] Redirect 404s to the root for docs.fedoraproject.org > [PATCH] Remove old rewrites which are no longer needed > > The other (main) part of the change is merging the Publican-2.0 branch of > /git/docs/web.git into master > > The new site is up at http://docs.stg.fedoraproject.org if anyone wants to > see it. > These are currently deployed in staging? If so +1. -Toshio pgpSq4gXXSoOy.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [CHANGE REQUEST] Fix ErrorDocument
On Thu, May 20, 2010 at 10:03:39PM -0400, Ricky Zhou wrote: > On 2010-05-20 10:00:41 PM, Nick Bebout wrote: > > I need to amend my previous change request, the line about ErrorDocument > > should read > > ErrorDocument 404 http://docs.fedoraproject.org/ > +1 > +1 -Toshio pgpnhRmcfHRYt.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Change Request: redirects on proxy
+1 -Toshio On Tue, May 25, 2010 at 03:50:59PM -0600, Stephen John Smoogen wrote: > --- > modules/fedora-docs/files/redirects.conf |6 -- > 1 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/modules/fedora-docs/files/redirects.conf > b/modules/fedora-docs/files/redirects.conf > index 4937a78..47832af 100644 > --- a/modules/fedora-docs/files/redirects.conf > +++ b/modules/fedora-docs/files/redirects.conf > @@ -1,12 +1,14 @@ > ## > ## Due to a lot of configuration changes right before F13 we have to fix > ## links > + > +Redirect 301 /accessibility-guide > /en-US/Fedora/13/html/Accessibility_Guide > +Redirect 301 /deployment-guide > /en-US/Fedora/13/html/Deployment_Guide > Redirect 301 /install-guide > /en-US/Fedora/13/html/Installation_Guide > Redirect 301 /installation-quick-start-guide > /en-US/Fedora/13/html/Installation_Quick_Start_Guide > Redirect 301 /readme-burning-isos > /en-US/Fedora/13/html/Burning_ISO_images_to_disc > Redirect 301 /readme-live-image > /en-US/Fedora/13/html/Fedora_Live_Images > -Redirect 301 /accessibility-guide > /en-US/Fedora/13/html/Accessibility_Guide > -Redirect 301 /deployment-guide > /en-US/Fedora/13/html/Deployment_Guide > +Redirect 301 /release-notes > /en-US/Fedora/13/html/Release_Notes > Redirect 301 /security-guide > /en-US/Fedora/13/html/Security_Guide > Redirect 301 /selinux-faq > /en-US/Fedora/13/html/SELinux_FAQ > Redirect 301 /selinux-managing-confined-services-guide > /en-US/Fedora/13/html/Managing_Confined_Services > -- > 1.5.5.6 > > > -- > Stephen J Smoogen. > “The core skill of innovators is error recovery, not failure avoidance.” > Randy Nelson, President of Pixar University. > "We have a strategic plan. It's called doing things."" > — Herb Kelleher, founder Southwest Airlines > ___ > infrastructure mailing list > infrastructure@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/infrastructure pgpng7PsVZGAj.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Staging rebuild
On Tue, Jun 01, 2010 at 03:05:06PM -0500, Mike McGrath wrote: > On Tue, 1 Jun 2010, Josh wrote: > > > On 06/01/2010 02:39 PM, Mike McGrath wrote: > > > Once we're confident 5.5 is done and happy (smooge is working on this now. > > > thanks smooge!) I'd like to rebuild the staging environment. Mostly > > > because it'd be nice for this to be a regular thing that happens during a > > > release cycle. > > > > > > Anyone have a problem with that? > > > > > > -Mike > > > > > > ___ > > > infrastructure mailing list > > > infrastructure@lists.fedoraproject.org > > > https://admin.fedoraproject.org/mailman/listinfo/infrastructure > > > > > Would we then upgrade the remaining systems during the next release > > cycle or try to upgrade in this cycle too? > > > > In this case smooge is already working on the 5.5 upgrade and production > will get upgraded too once we're confident the staging environment is > stable. > > After that point we'd then format all of staging and rebuild from scratch > to make sure we have a clean staging environment (this might involve some > puppet rebasing as well) > Fine with me. Figuring out how to use puppet to simulate bapp01 in staging might be another thing to do while we're at it. -Toshio pgpqpPeqkCmIq.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: TG2 and RHEL-6
On Tue, Jun 08, 2010 at 02:13:22PM -0500, Mike McGrath wrote: > On Tue, 8 Jun 2010, Dennis Gilmore wrote: > > > So one of the things moving from EPEL to RHEL in EL-6 is the TurboGears 2 > > stack. We recently had TG-2.1 pushed into EPEL-5 testing. this is newer > > than > > what is in EL-6. TG-2.1 broke a couple of things in Moksha(community) > > because its using internal api's that changed, the public api is stable. > > but > > it brings up the maintenance burden for when we start migrating to EL-6 on > > app > > servers. Moksha would ethier need to work with 2.0 and 2.1? not sure if its > > doable. or the version for EL-6 will need to use the old api. or something > > else ive not mentioned/thought of. > > > > FWIW, when I tested 2.1 with virt_web (it was written against 2.0) so I > suspect the changes are small. > > > > > another option is replace the TG stack. which then means for the life of us > > using EL-6 we will need to maintain the TG stack in the infra repo and any > > packages we use on top of it. it also means we cant put TG apps into EPEL-6 > > since they wont work. > > > > alternatively we could use some fedora app servers where we can put > > everything > > into fedora. maintain an updated stack in fedora, but have the additional > > cost of greater maintenance needed for the fedora based servers. > > > > I don't have the answer but we need to start the discussion now so that we > > have a plan and dont get blindsided by this. > > > > Also right now we only have one tg2 app/stack deployed in community. It > exists fine with the 1.x tree. Luke's already got a working moksha with > 2.1 so I think keeping our apps in line will be pretty easy, the bigger > question is what will ship with RHEL. if they do ship 2.0, will EPEL > allow a 2.1 fork or will we have to run our own? Will it not matter? I > think I have more questions then answers on that but yeah thanks for > getting the conversation started. > Just judging by the way the infrastructure repo has grown over the course of RHEL5, I think that it's inevitable that we eventually roll our own version of tings that we are developing against. However, for the sake of reducing the maintainance burden we carry, I think it would be great if we could defer this for as long as possible. In TG2 vs TG2.1's case, most of the improvements seem to be speed. If we aren't having problems keeping up with the number of requests, perhaps we want to wait to switch to TG-2.1 on the app servers. Luke, does that sound right for now? -Toshio pgp21TiJAmpNq.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: TG2 and RHEL-6
On Wed, Jun 09, 2010 at 01:54:13PM -0400, Luke Macken wrote: > On Wed, 2010-06-09 at 12:22 -0400, Toshio Kuratomi wrote: > > Just judging by the way the infrastructure repo has grown over the course of > > RHEL5, I think that it's inevitable that we eventually roll our own version > > of tings that we are developing against. However, for the sake of reducing > > the maintainance burden we carry, I think it would be great if we could > > defer this for as long as possible. > > > > In TG2 vs TG2.1's case, most of the improvements seem to be speed. If we > > aren't having problems keeping up with the number of requests, perhaps we > > want to wait to switch to TG-2.1 on the app servers. Luke, does that sound > > right for now? > > Speed, and a lot of bugfixes. > > http://trac.turbogears.org/wiki/2.0/ChangeLog > Since there's a lot of bugfixes, it seems likely that we'll just have to suck it up and maintain our own copy in the infrastructure repo > Also, TG2.1, which is in EL-5 testing, is already on our app servers as > of yesterday. If we need to pull 2.1 out of EL-5, we'll want to > downgrade. > Yeah -- EPEL is somewhat of a separate issue but we (EPEL) may not want to have EPEL-5 at a higher evr than RHEL-6 when we can help it. I don't know that there's actually a policy on this, though. I'll ask around on #epel. -Toshio pgpr0ABCG8WwE.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: TG2 and RHEL-6
On Wed, Jun 09, 2010 at 02:44:00PM -0400, Toshio Kuratomi wrote: > On Wed, Jun 09, 2010 at 01:54:13PM -0400, Luke Macken wrote: > > > Also, TG2.1, which is in EL-5 testing, is already on our app servers as > > of yesterday. If we need to pull 2.1 out of EL-5, we'll want to > > downgrade. > > > Yeah -- EPEL is somewhat of a separate issue but we (EPEL) may not want to > have EPEL-5 at a higher evr than RHEL-6 when we can help it. I don't know > that there's actually a policy on this, though. I'll ask around on #epel. > Sounds like people usually need to reinstall between RHEL major releases, upgrades are not possible. So we can have versions go backwards if we want to. From that standpoint, EL-5 can go to a higher version than what's in base RHEL-6. Whether the internal API was widely enough used by third parties to warrant not pushing to EPEL I don't know. Sounds like the template API changes, at least, would be esoteric enough to not affect too many people. (Unless, people writing their own connectors between templating languages and TG2 depend on those internal APIs.) -Toshio pgpUuauByo38d.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: discussions on statistics in fedora: new list, or use this one?
On Wed, Jun 16, 2010 at 10:03:26AM -0400, Ian Weller wrote: > (regarding https://fedorahosted.org/fedora-infrastructure/ticket/2223) > > I was going to create a new list for statistics discussions within > Fedora -- datanommer development, requests for numbers from > applications, and general talk about what data should/could be > collected. > > The list topic seems to fall under the general topic of the > infrastructure list, so it was suggested that I just have that > discussion on this list. However, I talked with a few people that were > interested in Fedora's statistics projects and they were more keen on > joining a list just for stats discussions. > > I don't particularly care one way or another, so I'd like to know if you > all are OK with having these sorts of discussions on this list. I'm not > sure how much noise to anticipate. > I'm okay with discussion happening here. Here's a pro and a con to a new list though: If you're going to try to get other, non-Fedora, projects using this, having a new mailing list might be a better fit. People from other projects might not be especially keen to get the fedora-infra list discussion just to work on datanommer. The worry I have when a project that Fedora is relying on heavily gets its own mailing list is that the communication between the project and Fedora Admins tends to degrade. Schedules for deployment, resources to host the service, people to maintain applications, etc all seem to get talked about on the other list and the infrastructure group gets pulled in at the last minute when we have to resolve conflicts, try to fix code unfamiliar to us, or simply say no. -Toshio pgpwgieyzl9xO.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Cleaning out sysadmin- groups
On Mon, Jun 21, 2010 at 05:40:07PM -0600, Stephen John Smoogen wrote: > We have a lot of requests for access that have historically piled up. > I would like to go through and clear them all out later this week, but > figured I should ask first. > It's fine with me. One thing that would be good (take this as a wishlist, not as a blocker): Get a new fas release out that has invite-only groups. that way once we clean the groups, we can set them invite-only nad not have to do it again. This was going to be an item for ricky to do this summer but he's been occupied with more important matters at home. If we could get someone else to step up to do the bit of coding that's left and get the release out the door, it would help all the FAS groups from having to do these periodic cleanings. -Toshio pgpxLjMrI8eeO.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Introduction
On Sat, Jul 03, 2010 at 08:41:58AM +1000, Liam Dunn wrote: > Development would be better at this stage, as I have more experience there. > If you're looking at doing development we have a variety of web apps in Fedora that we need to maintain. We tend to write everything we do in python. Quick question -- do you have any experience making releases of software? Particularly software that uses python's distutils? We currently have a bottleneck getting a few releases out the door and making some alpha candidate tarballs might be a good way to start. -Toshio (abadger1999 on irc) pgpUQP5QDQcVL.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Sponsored groups
On Thu, Jul 08, 2010 at 09:03:30AM -0500, Mike McGrath wrote: > On Thu, 8 Jul 2010, Paul W. Frields wrote: > > > Hi Infra team, > > > > Earlier I recall Mike and Toshio had been discussing the issue of > > scalable and meaningful group membership, and making group memberships > > by invitation in FAS to address it. Is this still something that's > > being working on? > > > > AFAIK it's already in there but other bugs are (and have been) blocking > the release for several months now. Particularly around SA. > We're kind of without a release manager/owner for FAS right now. Someone who can stay abreast of the state of the code, lay out what needs to be fixed in order to move to a new version, etc. I think that we can make a new point release with the invite-only functionality and not break anything but I'm not 100% certain on that -- the SA brokenness, I think lives on its own branch -- it's part of upgrading from SA-0.4 to SA-0.5. -Toshio pgpvHLK4O6qug.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Verifying a FAS instance via JSON?
On Sun, Jul 11, 2010 at 12:52:33PM -0400, Paul Frields wrote: > This is probably going to be a very naive question, so bear with me. > I'm trying my hand at an AuthFAS plugin for Drupal. > Note: If this is going to run outside of infrastructure it's probably best not to auth against FAS due to the insecurity of getting people used to typing their FAS credentials into third party websites.. If it's going to run inside of infrastructure we should think about whether we want to run Drupal. If it's going to run on some third party against some third party FAS then we'd like to know who else is running FAS :-) > As part of that > code, I'm trying to verify the setting of a FAS instance URL, by using > curl to hit https:///json/ (like > https://admin.fedoraproject.org/accounts/json/). I give the > administrator an opportunity to enter FAS credentials to be used in > the curl process. > > The code is found here (in the authfas_admin_validate() function): > http://fedorapeople.org/gitweb?p=pfrields/public_git/drupal-authfas-6x.git;a=summary > > If I'm at a browser and I hit https://admin.fp.o/accounts/json/ > directly, I have to enter my username/passphrase, and then I get a > JSON result that includes a 'help' element, which is what I'm checking > for in the code. This is sort of an optional step, really. I wanted to > make it possible for people to know if they made a typo in the URL. > But if I have to drop that validation step, and simply depend on the > admin to get it right, that's probably acceptable. Maybe I'm trying to > be too clever. > > In any case, regardless of the username and password I use, I don't > get back a positive result. It's possible that's because I'm getting a > login or some sort of CSRF intermediary request. I confess I haven't > had a ton of time to dig deeply into the problem. I was hoping someone > here would be able to say, "Here's something you need to do if you're > using curl like that...". The curl code here is drawn from the > original Auth_FAS.php on the wiki, but I'm not sure if the changes I > made are all kosher. > Are you just trying to get username/password verification from fas? or are you trying to get fas to give you a cookie that fas verifies is correct everytime? I believe our mediawiki install does the former. A quick look at the code leads me to believe that you aren't requesting json data explicitly and therefore the login page is being returned as html rather than json. Requesting json should make fas return an error if you aren't logged in/handing in valid credentials. A few other differences between the python-fedora implementation and this: * I think that giving "username=XXX" as a param will yield an error. * I think you need to have FOLLOWLOCATION=True so you follow redirects. Here's what I *think* is php to implement that: - curl_setopt($ch, CURLOPT_USERAGENT, "Drupal AuthFAS 0.1"); - curl_setopt($ch, CURLOPT_POSTFIELDS, "username=".urlencode($username)."&user_name=".urlencode($username). "&password=".urlencode($password)."&login=Login"); + curl_setopt($ch, CURLOPT_HEADERS, "user-agent: Drupal AuthFAS 0.1; Accept: application/json;"); + curl_setopt($ch, CURLOPT_POSTFIELDS, "user_name=".urlencode($username). "&password=".urlencode($password)."&login=Login"); + curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1) + curl_setopt($ch, CURLOPT_MAXREDIRS, 5) I could be off in the bushes with this, though. If so, here's the python-fedora code that connects to FAS. Checking for differences in what you're giving curl and what it's giving curl is pretty straightforward: http://bzr.fedorahosted.org/bzr/python-fedora/python-fedora-devel/annotate/head%3A/fedora/client/proxyclient.py#L146 -Toshio pgp2Z6M7tAxvj.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Change request (already done :-/)
On Fri, Aug 06, 2010 at 02:27:51PM -0400, seth vidal wrote: > On Fri, 2010-08-06 at 13:26 -0500, Mike McGrath wrote: > > Sorry guys, I just pushed out a change that I think will also hit the app > > servers and koji01, I didn't realize it until after I did it. The change > > was just to disable mod_cache which the app servers weren't using anyway. > > If it does break something by chance, the revert is as simple as adding > > the lines back. > > > > +1 - retroactively > +1 as well -Toshio pgpPCkTu9jNx3.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Change Request: fas=>bugzilla sync script that does not email invalid users
We've had a few complaints about our bugzilla sync script sending out too
much email. I'd like to apply this hotfix to the export-bugzilla script on
fas01 (where the cron job runs) and the associated config change to stop
sending out email to the invalid users.
Can I get two +1's?
-Toshio
diff --git a/scripts/export-bugzilla.py b/scripts/export-bugzilla.py
index 413cd27..2306b6f 100755
--- a/scripts/export-bugzilla.py
+++ b/scripts/export-bugzilla.py
@@ -14,7 +14,7 @@ from email.Message import Message
import turbogears
import bugzilla
from turbogears import config
-turbogears.update_config(configfile="/etc/export-bugzilla.cfg")
+turbogears.update_config(configfile="./export-bugzilla.cfg")
from turbogears.database import session
from fas.model import BugzillaQueue
@@ -23,6 +23,7 @@ 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')
+NOTIFYEMAIL = config.get('mail.notify_email', ['ad...@fedoraproject.org'])
if __name__ == '__main__':
opts, args = getopt.getopt(sys.argv[1:], '', ('usage', 'help'))
@@ -77,39 +78,66 @@ if __name__ == '__main__':
session.delete(entry)
session.flush()
-# Mail the people without bugzilla accounts
-for person in no_bz_account:
-smtplib.SMTP(MAILSERVER)
-msg = Message()
-message = '''Hello %(name)s,
+# Mail the people without bugzilla accounts
+if '$USER' in NOTIFYEMAIL:
+for person in no_bz_account:
+smtplib.SMTP(MAILSERVER)
+msg = Message()
+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, to enable this functionality, we
+need to have your bugzilla email address stored in the Fedora Account
System.
+At the moment you have:
-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, to enable this functionality, we
-need to have your bugzilla email address stored in the Fedora Account System.
-At the moment you have:
+%(email)s
-%(email)s
+which bugzilla is telling us is not an account in bugzilla. If you could
+please set up an account in bugzilla with this address or change your email
+address on your Fedora Account to match an existing bugzilla account this
would
+let us go forward.
-which bugzilla is telling us is not an account in bugzilla. If you could
-please set up an account in bugzilla with this address or change your email
-address on your Fedora Account to match an existing bugzilla account this would
-let us go forward.
+Note: this message is being generated by an automated script. You'll
continue
+getting this message until the problem is resolved. Sorry for the
+inconvenience.
-Note: this message is being generated by an automated script. You'll continue
-getting this message until the problem is resolved. Sorry for the
-inconvenience.
+Thank you,
+The Fedora Account System
+%(admin_email)s
+''' % {'name': person.person.human_name, 'email': person.email,
+'admin_email': ADMINEMAIL}
+
+msg.add_header('To', person.email)
+msg.add_header('From', ADMINEMAIL)
+msg.add_header('Subject', 'Fedora Account System and Bugzilla
Mismatch')
+msg.set_payload(message)
+smtp = smtplib.SMTP(MAILSERVER)
+smtp.sendmail(ADMINEMAIL, [person.email], msg.as_string())
+smtp.quit()
+#print 'Message to %s: %s' % (person.email, message,)
+recipients = ', '.join([e for e in NOTIFYEMAIL if e != '$USER'])
+if recipients and no_bz_account:
+smtplib.SMTP(MAILSERVER)
+msg = Message()
+people = []
+for person in no_bz_account:
+people.append(' %(user)s -- %(name)s -- %(email)s' %
+{'name': person.person.human_name, 'email': person.email,
+ 'user': person.person.username})
+people = '\n'.join(people)
+message = '''
+The following people are in the packager group but do not have email addresses
+that are valid in bugzilla:
+%s
-Thank you,
-The Fedora Account System
-%(admin_email)s
-''' % {'name': person.person.human_name, 'email': person.email,
-'admin_email': ADMINEMAIL}
+''' % people
-msg.add_header('To', person.email)
msg.add_header('From', ADMINEMAIL)
+msg.add_header('To', recipients)
msg.add_header('Subject', 'Fedora Account System and Bugzilla
Mismatch')
msg.set_payload(message)
diff --git a/scripts/export-bugzilla.cfg b/scripts/export-bugzilla.cfg
ind
Re: Change Request: Have fedoracommunity.org work with genshi
On Tue, Aug 17, 2010 at 11:01:54PM -0500, Sijis Aviles wrote:
> Hi,
>
> I'm requesting this change so that we can start putting the mocked up
> site[1] together with genshi on the fedora-web repo.
>
>
> diff --git a/modules/fedora-web/files/syncStatic.sh
> b/modules/fedora-web/files/syncStatic.sh
> index 9f1d8a6..f5f2005 100644
> --- a/modules/fedora-web/files/syncStatic.sh
> +++ b/modules/fedora-web/files/syncStatic.sh
> @@ -58,5 +58,6 @@ rsync -qa --delete-after --delay-updates .
> /srv/web/mirrors.fedoraproject.org/
> popd > /dev/null
>
> pushd fedoracommunity.org > /dev/null
> -rsync -qa --delete-after --delay-updates . /srv/web/fedoracommunity.org/
> +make > /dev/null 2>&1
> +rsync -qa --delete-after --delay-updates out/ /srv/web/fedoracommunity.org/
> popd > /dev/null
> diff --git a/modules/fedora-web/manifests/init.pp
> b/modules/fedora-web/manifests/init.pp
> index 5f39a7d..ba7a98b 100644
> --- a/modules/fedora-web/manifests/init.pp
> +++ b/modules/fedora-web/manifests/init.pp
> @@ -288,4 +288,15 @@ define fedora-web::fedoracommunity-org::proxy($website) {
> notify => Service["httpd"],
> require => Httpd::Website[$website],
> }
> +
> +file { "/etc/httpd/conf.d/$website/languages.conf":
> +owner => "root",
> +group => "root",
> +mode=> 0644,
> +source => "puppet:///fedora-web/fedoracommunity.org-languages.conf",
> +notify => Service["httpd"],
> +require => Httpd::Website[$website],
> +}
> +
> +
> }
>
>
> I'm also attaching the "fedoracommunity.org-languages.conf" file.
>
> I would also make necessary changes in fedora-web.git for this to work
> correctly.
>
> Could I get the approvals (2 +1's) needed to do this?
>
What's the risk/benefit? Which servers does this run on? Is it very easy
to revert or do you have to revert a bunch of commits in fedora-web as well
if this breaks? Is starting on the mockups time critical? Can we not use
staging for this?
Other risk/benefit things you can think of.
-Toshio
pgpxahsGZs9HT.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [PATCH] Update remainder of staging and dev and publictest
On Fri, Aug 20, 2010 at 08:25:34AM -0500, Mike McGrath wrote: > +1 > > +1 -Toshio > On Fri, 20 Aug 2010, n...@fedoraproject.org wrote: > > > From: Nick Bebout > > > > --- > > modules/ssh/files/ssh_known_hosts | 36 > > +++- > > 1 files changed, 15 insertions(+), 21 deletions(-) > > > > diff --git a/modules/ssh/files/ssh_known_hosts > > b/modules/ssh/files/ssh_known_hosts > > index 2e9d2fc..e05fa5c 100644 > > --- a/modules/ssh/files/ssh_known_hosts > > +++ b/modules/ssh/files/ssh_known_hosts > > @@ -67,13 +67,12 @@ > > 10.5.126.70,value02.phx2.fedoraproject.org,value02,value2 ssh-rsa > > B3NzaC1yc2EBIwAAAQEA5T/3fQANOMMarlcshVg9Iyk9qsIzh4Bs81ea6T7FzMEPhOXTtUtkFOyPLoYk2Ts7tHVhFs5H+UfCvNrmQpc/80jpgk9Kg2HpZFvqR4qdhgC0JeVprwqKVdaTamwhbzCgsIHW+eV5oC5y2fKptgmEJ4XYpEeiIgMuesNJty/ubhnYgz2mbEhhp1tRu1C8/canc4wdvNiZjEHqYkAgJVuUB6/aItGpTVMEw5TYiJYoHX86cwVBXdjlPPhjW7uoCRHCRczrr60NVauNK+gBVdLLraCgB5OCMUNsLUR0G7Gyr8MXamW63s6exNt5/nXgl4NmvqwRbw/dkEB7BAsStVZ8mQ== > > 10.5.126.71,db01.phx2.fedoraproject.org,db01,db1 ssh-rsa > > B3NzaC1yc2EBIwAAAQEAyBOYzV6AmoOwRrD1IbXy0Mtk3wlbTxa81TRUc6sPlZOUyGANrHhVgGCwwim/gYmZdFx9aSglfZGTAacZ2lQsttnLGBCMif75aeKa9PFXyKR2bL5cZPI1PDJck1dIaXKN5bVvg6EQwJfQkalFB5r2LWkSZdEsskcbxlbstKYGmZSQ68H3FFiYWKhIhGvy+g6B1/uJgL1OxnHELXjIpQ6Fq1PM33xxDEj3uTgVGrbIO3CKL/Rn9da7RDRad01n7b0tiLJftSGBaTWGX0Ws/R1zVNiSx+miuyWg/84Kqfu12sW9q6O1fMj9LEuD+jR5DeU6RL0FVGuFVGLmL0uyzn4F1Q== > > 10.5.126.72,db02.phx2.fedoraproject.org,db02,db2 ssh-rsa > > B3NzaC1yc2EBIwAAAQEAw+xqJiF9fUkmJkHOliFiPk+z0fyEY0gx6VKR6+94JsmQkfFKrl+iwC95+HZFuY8xI6aps8HthSrdoIdn1UyhDMjqAFFLDr7ob0VLNNAXf/eb7XRtm6UHlaaCxQET6tMav33qeGR+vQ61FdwXpPJodiNiW+QjMYUl0dovcL06nLBTqLVP+drWxHiWyGaRI4bMCuqvpHyLhnCMj6bIUFoivW2WANrIxIlKZW8I1NBggZeNbg+kW9gEVyZ2zrSPhyF+6YBjg0UGE1ADdRJ9nJW9okjPcZWjL+Hfg6+SKOpy/pkj9y1ilLrScHbajshSiFU27/O/kEb1cUVlCmBc/Qqi8Q== > > -10.5.126.81,app01.stg.phx2.fedoraproject.org,app01,app1 ssh-rsa > > B3NzaC1yc2EBIwAAAQEAzZrlCOjEMo4NjPltlu8AZCeQaDg/HnHsSyuzTQwQ4GVmFzV5mcFYS66bMoocYNabQF3xy+chtWbrZmOl+RsbOdZohF4BY85Kd6fJxUsudSbEVq2sIRc7FFqJHZKUpli8Ddr/z8nHIz52Cj5mJU4ATiZMVZVhsWkbPNv7ny+SXoNouLVfQcnklygBcCmQBOzNumCLn+L0lIDaYidCbZiwsvWTRiDHgAL/K/xCXv+RdHSY7C+GYvReByam6mtaK21rc0rqNdJqnIBO6Ru7p3nBngvB+uwifYoek33yCYdW9xbntkTIyVBpJEgHHGux/rCx11/R0EiTd1v8FWMmIBQ/Gw== > > -10.5.126.84,db01.stg.phx2.fedoraproject.org,db01,db1 ssh-rsa > > B3NzaC1yc2EBIwAAAQEAuDwuuglb3gezy8iyUTX5uFrcx6DPbAxeWuoUBDmzW+fCYwCjSuQ4nIsNa4ZyUbcUY8UYdZ7/k24faMLKZ5mDA3mIH6OPCc8PBG12qj9zU4dS89lnDEP5vhrQPm7Cnqwnt+xAShA+sw1il8wFiLdAXkYJ3bwjGjyIFHZ36jD6vpxqM8Igr28BpzGIyXN7lbvCHA96AfP+fQpRtLjTB3EpTAkWkg1cxZibWa/+ycVrcnB2bZk/hmpS7WSu5xOUMrmyJnSPP9QiwrrMffTstHMCHxVpzBxGANbsyXC8Yvx0UJrSxVtljQkCuPBsQStiHnzALWS9Vt9n5jhbCFkS9aUipw== > > -10.5.126.86,fas01.stg.phx2.fedoraproject.org,fas01,fas1 ssh-rsa > > B3NzaC1yc2EBIwAAAQEAxtSw7TXoHnTEnydCAswiQfidCg3aVq6WJGUjs6mze+QulKNSpQKepivdkde7hkbjhsyV/IoEx53bVcyB0emU8O/a6p3tkxdCfC9mmCpNLzqO/ifcU+eGdszY4y8eGIAU7fc99TnK80W/vlsXZvwpXgXr9bW94XVUsUk/q4Ltiut+5i8LRByyw0fivZ6cJNX240Lw0eFWs0kf3jRtKFO6S/bevjVKtSflSavPl66ZRlcGoImf39HiD+8scJ9LG5EmXmn2HSq2uhNLZw45PKuvjnm3vPXfqfjk0frREgQSwISqot555crGCcZaWD0t3Wem9ET8zoY3Cpmp1Ud2Vbt6dw== > > +10.5.126.81,app01.stg.phx2.fedoraproject.org,app01.stg,app1.stg ssh-rsa > > B3NzaC1yc2EBIwAAAQEAoSdooI1oUVyiQheQLadapXnSnPTT2EZRoWrsSQejjfsUeKsw5ED4FOMi6LfsoIs57gREJi51pYrnWThtNCrigB39cb9I39GVCQXqJzmNhFSRH2C5CVRWzL2DOTEor5VomcuMqmfH+lBeA7H3qGJ5lGkLbk958Bbjr01/Yo5Z6BBZatndtsqpQ563fp15jYgbxyVBF4RVRX86/H77LbgNAebhnbfvcUMv67zl3vS+pXEYvgorTniC7AaXDoFg2l1n0Hx/0c9kZUn86K+FDLxSc0PGQtBmCp/zxliYzHoeiI3cPezduRyfAF9uI/BJMTiGVRfVeELkZMR3HgcigtaBYw== > > +10.5.126.84,db01.stg.phx2.fedoraproject.org,db01.stg,db1.stg ssh-rsa > > B3NzaC1yc2EBIwAAAQEAppUyUD78rSh+lom8xetoKYi9FGM/rWW/asMaLND5rJbQBQxOD4ZU72MCX2UdHrFcgBUxR/c5v4tbEppKxL58dsonGaVoUfg68BlZjtpEKXxGJQLlEU7wV0ruSy3fiBH1JJ1WEYR/0WEMx/Uw/CqXE+XV651edvxWtZsrIU14tcobKOFjCx160PKZmqAw5Kwwq2Hi6AoIw7T/JaPX/f3rDKIHKHsakKcKTKpzpsnhXpF/EuJihocbM39UBb8yj3Wai+n1r1mt4lQFodRdgXBAEx8XTUqEOL4PmymV7Y3/fMembzDQXN3QqbxTiHXU5zNK/JDReEyvV7U5Jh2S/bHmBw== > > +10.5.126.86,fas01.stg.phx2.fedoraproject.org,fas01.stg,fas1.stg ssh-rsa > > B3NzaC1yc2EBIwAAAQEA4cS0sdFPb5pRQNiZlBIJf+jX0dCY2C+5MxixHtXsvtMkZn1XPNmj/T0f4zSFSw/CUSmzTQmf+CWD4mumnNKf/GYrnQB+D14WR+/xFynYU+KQCYFQDLSu6w/c+cXkJeEAMtOK6Jtp6RuPN+iXEdLsQ9w+6+QHRzFfQE4vxAHczDLQvhI+6PYgjnwmoc7pLIjOir2IDN4S7Hz1AD7UGChNdlgGi+LtOYd4Lr455xbZ3O1AjRkim1UvYcI2kORKvzXzbDTzvMPY9rovOrZCAqRBPsa1+27fi3sJbAJJ5WNYNFRqiTb4h/xy0qR0BgEoT0vywnNc6htjWo5KYY2lM9RitQ== > > 10.5.126.88,proxy01.stg.phx2.fedoraproject.org,proxy01.stg,proxy1.stg > > ssh-rsa > > B3NzaC1yc2EBIwAAAQEAxcdm7XpfrCfTu+lELYzE0l2fgvoYZGHH7fTTcbD2hFjgRvTAxLMoMemji3yUxF8UH6kBQLDZ7izFJszgwlL1EqhCFmoJnpBKN2JBwXLOM6k5h8iM0cUptliLBb8b/0EyuFxkzzRe6EOd1tndUxTNLDKT/sWJV7E06yjehozLLdUpYRA2WQEP5LYCuJcm9L9XzclkzTlDkAnnBNynzY7YRZ+oWu58YLj+Ng+je/UMbjqma8juAP30kVofdRD74uDHl/cZ+AilITNCwFiwzKvlk9kITqyx++
Re: speeding up the group/dump query in FAS
On Mon, Sep 06, 2010 at 09:53:55PM -0500, Mike McGrath wrote: > On Mon, 6 Sep 2010, matt_dom...@dell.com wrote: > > > Currently this query takes several minutes. HAProxy (or something in the > > proxy series) times out the request, and returns a 500 to the client. > > https://admin.fedoraproject.org/accounts/group/dump/ > > > > Any chance that could be optimized? FWIW, I use this query in my ftbfs > > script to convert package owner names to email addresses, so I can send the > > FTBFS report to the owner's emails directly (on bcc). > > > > This must be related to the alchemy alterations we did recently. I'll > take a look and see what it would take. I was under the assumption this > particular dump was memcached so it should be very quick but I could be > wrong on that. > I took a look and we should be able to do something similar to what we did for /groups/list => switch from using code that targets the ORM layer to code that targets the SQL layer and do the privacy_filtering type of stuff manually. The tough part is that we probably should figure out how to make that type of code more generic so that /gorups/list and groups/dump and anything else that needs it can use the same thing. It took roughly a day to create the changes to /groups/list -- since we could copy and paste if we don't figure out how to genericify, probably less time to get this up and running. -Toshio pgpYTiModZYLz.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [PATCH] adding fas and transifex, 2+1's please
On Tue, Sep 14, 2010 at 02:29:29PM -0500, Mike McGrath wrote:
> ---
> manifests/nodes/db02.phx2.fedoraproject.org.pp |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/manifests/nodes/db02.phx2.fedoraproject.org.pp
> b/manifests/nodes/db02.phx2.fedoraproject.org.pp
> index 09fe72b..13f5f3a 100644
> --- a/manifests/nodes/db02.phx2.fedoraproject.org.pp
> +++ b/manifests/nodes/db02.phx2.fedoraproject.org.pp
> @@ -7,7 +7,7 @@ node db02{
> include postgresql-pgpool-ii::pgpool
> collectd::collectd { 'log01': }
> collectd::postgres { 'postgres':
> -databases => ['mirrormanager', 'bodhi', 'election', 'pkgdb',
> 'transifex']
> +databases => ['mirrormanager', 'bodhi', 'elections', 'pkgdb',
> 'transifex', 'fas', 'transifex']
> }
>
> sysctl { 'kernel.shmmax':
>
With the change for transifex listed twice, +1. If it'll help us figure
out some of our fas issues it's worth the risk atm.
-Toshio
pgpWsfboYISkH.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [PATCH] Enable icon caching for pkgdb
On Wed, Sep 15, 2010 at 10:13:17AM -0500, Mike McGrath wrote:
> Toshio and I worked through this yesterday and agreed the change was worth
> it. It's very easy to revert. Can I get 2 +1's?
>
> diff --git a/manifests/servergroups/proxy.pp
> b/manifests/servergroups/proxy.pp
> index 43e0c69..099305c 100644
> --- a/manifests/servergroups/proxy.pp
> +++ b/manifests/servergroups/proxy.pp
> @@ -401,7 +401,7 @@ class proxy {
> fedora-packagedb::proxy { "admin.fedoraproject.org/pkgdb":
> website => "admin.fedoraproject.org",
> path => "/pkgdb",
> -proxyurl => "http://localhost:10003";,
> +proxyurl => "http://localhost:6081";,
> }
>
> bodhi::proxy { "admin.fedoraproject.org/updates":
> diff --git a/modules/varnish/files/proxy.vcl
> b/modules/varnish/files/proxy.vcl
> index 2ba7414..327e1be 100644
> --- a/modules/varnish/files/proxy.vcl
> +++ b/modules/varnish/files/proxy.vcl
> @@ -112,8 +112,9 @@ sub vcl_recv {
> if (req.url ~ "^/w/") {
> set req.backend = wiki;
> }
> -if (req.url ~ "^/pkgdb/") {
> +if (req.url ~ "^/pkgdb/appicon/show/") {
> set req.backend = pkgdb;
> +unset req.http.cookie;
> }
> if (req.url ~ "^/mirrorlist/") {
> set req.backend = mirrorlists;
> @@ -187,6 +188,13 @@ sub vcl_recv {
> lookup;
> }
>
> +# When requesting application icons, don't allow cherrypy to set cookies
> +sub vcl_fetch {
> +if (req.url ~ "^/pkgdb/appicon/show/") {
> +unset obj.http.set-cookie;
> +}
> +}
> +
> # Called if the cache has a copy of the page.
> #sub vcl_hit {
> #if (req.request == "PURGE")
>
>
+1
-Toshio
pgpi1R9tWRZLu.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Change request: new bodhi release
On Wed, Sep 15, 2010 at 12:32:51PM -0400, Luke Macken wrote:
> I've been trying to get this new bodhi release out the door for a while
> now. It fixes a lot of important bugs and adds a bunch of new features.
>
> I've added many new unit tests for a lot of these fixes/features, i've
> been poking it in staging for a while, and it does not contain any db
> schema changes so it can be reverted with a `yum downgrade bodhi-server`
> if things go south.
>
+1
Since the QA people have the systemd reversion cutting into their schedule,
we might want to put a low bar on the "should we revert this" question if
any problems crop up.
-Toshio
> Thanks,
> luke
>
> =
>
> bodhi v0.7.9
> - Email the proventesters with stale unapproved critical path
> updates after 2 weeks
> - Allow people to revert their karma vote more than once
> - Download and inject the pkgtags sqlite db into our repodata from
> the pkgdb (which will be used by `yum search`)
> - Improved editing functionality
> - Only unpush edited updates when builds are added/removed
> - Make a note in the comments of which builds were added/removed
> - Add the new 'dist-fN-updates{-testing,}-pending' tags to builds
> so AutoQA can start testing them before they get pushed
> - Get the 'suggest reboot' flag working again
> - List security & critpath testing updates in our updates-testing
> digest emails
> - Allow non-critpath updates to be pushed to stable after meeting
> our critpath requirements
> - Add mouseover tooltips to the update status with more details
> - Prevent conflicting builds from being added to the same update
> (eg: 2 different versions of the same package)
> - Handle more types of bugzilla auto-linking in comments
> - Link to newer update in the obsoleted one
> - Remove our pagination query limit of 1000
> - Add a new 'author_group' field to each comment in our JSON API
> - Properly capture stderr from our mash subprocess
> - Add --stablekarma, --unstablekarma, and --disable-autokarma
> client args
> - Fix a bug in using `bodhi --push-build=` on multi-build updates
> - Link to gitweb instead of viewvc
> - Set default (un)stable karma values if autokarma re-enabled
> - Mark anonymous karma as being ignored
> - Add a --bodhi-url command-line option
> - Instead of requiring only one arg with a comma separated list of
> updates, support several builds as several args.
> - Improved metrics report generator (soon to be integrated into the
> web interface)
> ___
> infrastructure mailing list
> infrastructure@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
pgp1GNvBfbjQm.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [PATCH] Fix noc02 IP in global iptables/nrpe templates.
+1 -Toshio On Tue, Sep 14, 2010 at 1:14 PM, Ricky Zhou wrote: > --- > configs/system/nrpe.cfg | 2 +- > modules/iptables/templates/iptables.erb | 1 - > 2 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/configs/system/nrpe.cfg b/configs/system/nrpe.cfg > index 04f2e4a..ae69684 100644 > --- a/configs/system/nrpe.cfg > +++ b/configs/system/nrpe.cfg > @@ -70,7 +70,7 @@ nrpe_group=nrpe > # NOTE: This option is ignored if NRPE is running under either inetd or > xinetd > > #allowed_hosts=127.0.0.1,192.168.0.2 > -allowed_hosts=10.5.126.41,127.0.0.1,192.168.1.10,192.168.1.20,209.132.182.50,192.168.1.75 > +allowed_hosts=10.5.126.41,127.0.0.1,192.168.1.10,192.168.1.20,209.132.182.50,192.168.1.20 > > > > diff --git a/modules/iptables/templates/iptables.erb > b/modules/iptables/templates/iptables.erb > index b38615a..74319ae 100644 > --- a/modules/iptables/templates/iptables.erb > +++ b/modules/iptables/templates/iptables.erb > @@ -137,7 +137,6 @@ COMMIT > -A INPUT -p tcp -m tcp -s 10.5.126.41 --dport 5666 -j ACCEPT > -A INPUT -p tcp -m tcp -s 192.168.1.10 --dport 5666 -j ACCEPT > -A INPUT -p tcp -m tcp -s 192.168.1.20 --dport 5666 -j ACCEPT > --A INPUT -p tcp -m tcp -s 192.168.1.75 --dport 5666 -j ACCEPT > -A INPUT -p tcp -m tcp -s 209.132.182.50 --dport 5666 -j ACCEPT > > # SNMP allows from our monitoring systems > -- > 1.5.5.6 > > > ___ > infrastructure mailing list > infrastructure@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/infrastructure > ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Yubikeys are now supported
On Thu, Oct 07, 2010 at 08:54:12PM -0400, Paul Wouters wrote: > > I have one and I've played with it in fedora. There is however an important > catch. The server and the yubikey share the same AES symmetric key. This means > that if the yubikey is used for multiple sites by one user, that user is > sharing is his "private key" over various external sites. > > So if fedoraproject would accept it, and the same user uses this yubikey for > another site, and that other site gets hacked, then fedoraproject could be > hacked as well. > > I guess in a way it is like using the same password, but people might not be > thinking of that when they have a "device" on them that they use. > [..] > > http://www.yubico.com/files/Security_Evaluation_2009-09-09.pdf > > Section 5.2. > So I see what you're saying but I think some people are misinterpreting it. The one time passwords generated by the yubikey can safely be used with multiple services. The thing that is unsafe is using the same AES key with multiple ykksm's. Yubico runs a ykksm for people to use with some third party websites that support yubikeys. The fedoraproject provides its own ykksm server. If you use the same AES key with both of these then if one of the servers is compromised, both are compromised. If you only use your key with one of the ykksm's then you can safely use your otps on other sites and there will be no negative ramifications (other than not being able to authenticate). The newer yubikey hardware has provision for two AES keys but I'm not sure how that works and whether it actually allows you to use separate keys with separate servers. Someone will need to look into this. -Toshio pgpXKxmD1sZxX.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Yubikeys are now supported
On Fri, Oct 08, 2010 at 12:07:34AM -0400, Matthew Miller wrote: > On Thu, Oct 07, 2010 at 11:30:43PM -0400, Toshio Kuratomi wrote: > > The newer yubikey hardware has provision for two AES keys but I'm not sure > > how that works and whether it actually allows you to use separate keys with > > separate servers. Someone will need to look into this. > > Yes, separate keys -- basically two separate configurations in one device. > After a bit of trial and error, I got this working. I now have my yubikey-v2 to send a otp that's associated with fas if I hold the contact for 0.3 – 1.5 seconds and a otp that's registered with yubico's servers if I press for 2.5 – 5 seconds. The sparsity of introductory docs on ykpersonalize made this harder than it should have been. I pieced together the necessary information from this page: http://www.teaparty.net/technotes/yubikey.html and the official upload instructions linked from here: http://www.yubico.com/developers/aeskeys/ and the user's manual http://yubico.com/files/YubiKey_manual-2.0.pdf Writing the second key slot was kinda like this: sudo ykpersonalize -2 -o fixed=vv -a KEY -o -static-ticket -o -strong-pw1 -o -strong-pw2 -o -man-update -o -append-cr -ouid=Y Figuring out ,KEY, and YYY were what I needed to read those documents for. -Toshio pgpRem6eMGmfK.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Yubikeys are now supported
On Fri, Oct 08, 2010 at 11:47:43AM +0200, Maxim Burgerhout wrote: > > If there is anything I can do to help out and make the use of > Yubikey's in the Fedora project into a success, just holler. It might > be interesting to add a README.Fedora to the ykpers package explaining > how to configure it for both Fedora and Yubico's servers like on the > page Toshio linked to. I'll look into that later. > That would be excellent. having the command line arguments for ykpersonalize and instructions/examples on how to construct the key, fixed string and uid string are what's needed. The hex <=> modhex portion threw me off for a while as did the length of the strings and I think there might be a third nonintuitive thing that I never was completely clear on (some modhex strings didn't seem to be valid for the fixed field). -Toshio pgpI2ajj2CQ6F.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Review Needed: fas02 /var/log/httpd overloaded
On Sun, Oct 24, 2010 at 09:24:30PM -0600, Stephen John Smoogen wrote: > Due to the many reboots it looks like the /var/log/httpd on the fas > servers are in a 'weird' state. Some of the files were compressed and > some were sort of compressed when the box rebooted itself. [In fact it > looks like the reboots seem to occur often during logrotate. Since the > files have not been compressed, the logrotate cleanup hasn't removed > them. I would like to compress and let logrotate remove all the old > ones. +1 Simple enough change... this is a change to the data hosted on the server rather than the code or configs. I don't know if this needs a formal change freeze request at all (although another set of eyes is always good.) -Toshio pgphP566cZbmp.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: fpo allowed programming\coding?
On Tue, Nov 09, 2010 at 03:47:08PM -0500, Ricky Elrod wrote: > > > As far as any custom stuff we do - since we like Python, I'll throw > another shout out for Django. I am pretty much in love with Django :) > > PHP can get annoying because security isn't the default (as people like > mmcgrath have pointed out to me several times :) -- though things like > Facebook's XHP (https://github.com/facebook/xhp) are helping to change > that. Note that currently, all of our custom stuff is written on either TurboGears1 or TurboGear2. Things I can remember we're deploying upstreams of: transifex and reviewboard (django), collectd (?) mediawiki, wordpress, and drupal (php) awstats moinmoin (python -- read-only) koji (mod_python) trac -- mod_wsgi(python) -Toshio pgps0yGlcqSRG.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: RFR sponsor for Upstream Release Monitoring wanted
On Thu, Nov 18, 2010 at 07:24:20PM +0100, Till Maas wrote: > Hi, > > I would like to ask if someone would sponsor me to host Upstream Release > Monitoring[0] on a Infrastructure machine. > > To host this, an account with cron and unrestricted internet access > would be needed and some python packages. The accound would need to > store a plain text Red Hat bugzilla password with fedorabugs privileges, > therefore everyone with root access to that box (or the host of the > virtual machine, if it is one) should be allowed to know it and have at > least the same bugzilla privileges. I would prefer some Fedora or at > least a RHEL 6 machine to have some more up to date python available. > > If anyone would sponsor this request, I will write up a formal Request > For Resources[1]. > > Regards > Till > > [0] https://fedoraproject.org/wiki/Upstream_Release_Monitoring > [1] RequestForResources Hi Till, I'll be happy to sponsor you and show you around the infrastructure hosts. I'm on #fedora-admin anytime you want to ask questions and get started. (Note that there's a holiday in the United States next week so I might not be available the whole week). For Upstream Release Monitoring, which you've been prototyping successfully on your own, we probably want to have it run on bapp01 in our infrastructure and put the configuration into puppet (where we can use templates to keep the password in a separate repository from the rest of the config) eventually. Currently, that's running RHEL5.5, though. One possibility is to pull in the python2.6 package from EPEL onto that box but I don't know if you are using a lot of third party modules (in which case, it might be easier to port the code to run on python-2.4 than it is to port away from the modules that do not have python26 packages.) We'll also update all the app servers to RHEL6 at some point but that will require a lot of testing to be sure that everything still runs (mediawiki, transifex, and all of our home-grown TurboGears apps) so we don't have a definite timeline yet. A formal RfR will be good so that we can know who to contact should it go down and could possibly provide some hints as to who can take over should something happen to you. Put me down as the Infrastructure Sponsor and then contact me so we can tlak about getting you the necessary privileges to do the work. -Toshio pgpl0s4wmqv2R.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Want to help
On Tue, Nov 30, 2010 at 08:25:14AM +0100, boogy wrote: > Same here ... :) > > 2010/11/30 strong > > Thanks Stephen, > > i'm interested in sysad work. > > regards, > > Marlon > Do either of you use IRC? By far the easiest way to get involved with Fedora Infrastructure is to hop into #fedora-admin on irc.freenode.net and say howdy. Much of our communication is done via IRC. I'm abadger1999 on #fedora-admin and smooge is probably the best person to talk to about sysadmin stuff. You can also read the introductory material: http://fedoraproject.org/wiki/Orientation_Infrastructure_SOP and take a look in our ticketing system to see if there's anything you might like to work on: https://fedorahosted.org/fedora-infrastructure/report/3 -Toshio pgp38PZoFxWyr.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: fpo allowed programming\coding?
On Sun, Dec 05, 2010 at 12:49:16PM +, Frank Murphy wrote: > On 09/11/10 20:47, Ricky Elrod wrote: > > > > > > > PHP is growing inside our infrastructure, however I would like to keep > > it to an easily audit-able amount. Mainly I would prefer that we > > standardize on our frameworks so that it is either Drupal and > > Mediawiki. The same on the Python side.. keeping the frameworks to an > > amount that we know what we have and how they 'interact' with each > > other. > > > > Will be hoping to learn Drupal, on my own time and with the aid of > Drupal-Groups Ireland. > > In college will be learning these relevant bits?: > Java > Javascript > PHP > xhtml > css > > as part of: > http://tinyurl.com/qrrggo > Fedora Insight is planning to use Drupal. Talk to smooge or stickster on IRC or see if you can make one of their meetings: http://fedoraproject.org/wiki/Fedora_Insight -Toshio pgpGAPZENKlm7.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Transifex update - intltool requirement (was: Need a Sysadmin Greeter)
On Thu, Dec 09, 2010 at 06:21:49PM +0200, Dimitris Glezos wrote: > On Thu, Dec 9, 2010 at 4:59 PM, wrote: > > Can you ask tx upstream why they need that level of intltool, > > and if there is a way to work around it? > > IIRC it was to support translation contexts. > > http://help.transifex.net/technical/releases/0.8.html#lotte-improvements > > Transifex 1.0 no longer has this requirement. > > > If the package may not reach RHEL5 updates-testing, I guess we may > > use the fedora-admin repo for this exception. > > I guess this could be done. > /me coming into this without having read everything before it I think that we do this already:: http://infrastructure.fedoraproject.org/el/5/i386/intltool-0.40.5-1.i386.rpm Do we just need to update that package to a newer version? -Toshio pgpkJzHw4nSMK.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: delta rpm compose debugging change
On Thu, Dec 30, 2010 at 10:36:23AM -0700, Kevin Fenzi wrote: > Greetings. > > Of late openoffice.org and a few other packages have been not > generating delta rpms in pushes. ;( > > They error with: > > Error genDeltaRPM for chunkd: exitcode was 256 - Reported Error: bad cpio > archive > > But looking later at both rpms, things seem fine. ;( > > I've talked with jdieter and we would like to add in more debugging: > > nirik: We're still having the "bad cpio archive" with > openoffice.org updates > I have a patched version of deltarpm available at: > http://www.lesloueizeh.com/jdieter/deltarpm-3.6-0.1.20101230git.fc14.src.rpm > If run with -vv, it will report old rpm, new rpm, and tell us what > the actual first six bytes of what's actually in the rpm > vs the 070701 that it's supposed to be > I don't have an el6 system, so it will have to be rebuilt for > releng2 > /usr/lib/python2.4/site-packages/createrepo/deltarpms.py needs to > modified as well > The line with "makedeltarpm -v" needs to be changed to > "makedeltarpm -vv" > > epel5 scratch build at: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2694315 > (releng02 is rhel5). > > If I can get enough +'s I'd be happy to put this in place whenever. > Otherwise we can wait until next week after the freeze. > If this totally breaks, it won't break creation of repositories just the creation of deltarpms for the repos, correct? If that's correct, +1 from me. -Toshio pgp3IFfHs8hDw.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: REMINDER: publictest box motd [this means you :)]
On Tue, Jan 04, 2011 at 11:50:43AM -0700, Clint Savage wrote: > Smooge, > > At one point, modifying the wiki page corresponding with the > appropriate publictest server was the proper way to have it show up in > the motd. Has this changed? > > https://fedoraproject.org/wiki/Infrastructure/Server/publictest7 is > where I made my modifications, but it does not seem to appear anymore. > I think the script did a little wget/curl magic to grab the data from > the wiki page. > I think I've fixed this now -- The script that was updating motd's was unable to find the hosts when we renamed from publictest7 to publictest07. So the single digit version wiki pages were broken. If anyone notices that updating the wiki page doesn't reflect in the server's motd let me (or anyone in infra) know. -Toshio pgpEEr58nCjQd.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Turbogears downgraded on fas servers
I've re-downgraded TurboGears to 1.0.9 on the fas servers. Another incompatibility was discovered i nthe TG-.1.1.x series. EPEL6 is going out of beta soon so on Monday I'll need to decide whether to revert TG in EPEL6 to TG-1.0.x or work on fixing fas further. -Toshio pgpXeifltsogX.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Turbogears downgraded on fas servers
On Sat, Jan 08, 2011 at 07:52:13PM -0500, seth vidal wrote: > On Sat, 2011-01-08 at 17:17 -0700, Jonathan Steffan wrote: > > On Fri, 2011-01-07 at 22:01 -0800, Toshio Kuratomi wrote: > > > EPEL6 is going out of beta soon so on Monday I'll need to decide > > > whether to revert TG in EPEL6 to TG-1.0.x or work on fixing fas > > > further. > > > > Please don't restrict version upgrades in public repos because of FAS. > > That is not fair to our downstream. Worse case we can maintain an > > internal 1.0.x TG until we have all the bugs worked out for 1.1.x. > > > > It's not just about fas - the issue seems to be that the TG update is > NOT backward compatible which was the presumption on the pushed update > AIUI. > Yep. Most people are moving onto TurboGears-2. So the only reason I want to have TurboGear-1.x is for compat with apps not yet ported. Currently both TG-1.0 and TG-1.1 are supported branches by upstream. Soon upstream is going to release TG-1.5.x as well. TG-1.5.x is definitely not compatible (it's built on top of cherrypy3 instead of cherrypy2) but upstream told me (and in their release announcements, etc) that TG-1.1 was going to be compatible with TG-1.0.x. Sadly, this isn't the case. > Toshio, do we have any other info about upgrade issues from other apps, > not just fas? > We've run pkgdb against TG-1.1.1 successfully but haven't done exhaustive testing. We've also run bodhi against it and tried it's unittests. It failed some of them but those were all traced to incompatibilities in TG-1.1's testing framework rather than incompatibilities in the framework itself. So, I'm divided. I wanted to get TG-1.1.x into EPEL6 since upstream TG will eventually get tired of supporting TG-1.0.x but the incompatibilities undermine the primary reason to have a TG1 package in the first place. We also don't have any assurances that upstream will maintain TG-1.1.x longer than TG-1.0.x rather than deprecating both in favor of TG-1.5 (or TG-2-only) at the same time. -Toshio pgpPGlelStFgc.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Turbogears downgraded on fas servers
On Sun, Jan 09, 2011 at 09:43:34AM -0700, Stephen John Smoogen wrote: > On Sat, Jan 8, 2011 at 18:50, Toshio Kuratomi wrote: > > On Sat, Jan 08, 2011 at 07:52:13PM -0500, seth vidal wrote: > >> On Sat, 2011-01-08 at 17:17 -0700, Jonathan Steffan wrote: > >> > On Fri, 2011-01-07 at 22:01 -0800, Toshio Kuratomi wrote: > >> > > EPEL6 is going out of beta soon so on Monday I'll need to decide > >> > > whether to revert TG in EPEL6 to TG-1.0.x or work on fixing fas > >> > > further. > >> > > >> > Please don't restrict version upgrades in public repos because of FAS. > >> > That is not fair to our downstream. Worse case we can maintain an > >> > internal 1.0.x TG until we have all the bugs worked out for 1.1.x. > >> > > >> > >> It's not just about fas - the issue seems to be that the TG update is > >> NOT backward compatible which was the presumption on the pushed update > >> AIUI. > >> > > Yep. Most people are moving onto TurboGears-2. So the only reason I want to > > have TurboGear-1.x is for compat with apps not yet ported. Currently both > > TG-1.0 and TG-1.1 are supported branches by upstream. Soon upstream is > > going to release TG-1.5.x as well. TG-1.5.x is definitely not compatible > > (it's built on top of cherrypy3 instead of cherrypy2) but upstream told me > > (and in their release announcements, etc) that TG-1.1 was going to be > > compatible with TG-1.0.x. Sadly, this isn't the case. > > > > So how much of infrastructure is still using TG-1.0.x and how much > work will it be to move to TG2 since that may sooner or later be our > only alternative. > bodhi, mirrormanager, packagedb, elections, fas, smolt -- everything that's written in TG except fedoracommunity is TG1. The amount of work I don't know precisely -- I want to port elections to TG2 since that's the simplest app that we run. After that, mirrormanager is also simple but it is using SQLObject and kid which we probably want to move off of when we move to TG2 so the amount of porting work is a lot higher. lmacken has ported bodhi to TG2 but he hasn't released the new version (continuing to make releases off of the TG1 tree instead) so I don't know if the porting is hard or something else is the holdup there. -Toshio pgpulWkvqu4xs.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Turbogears downgraded on fas servers
On Sun, Jan 09, 2011 at 09:24:37PM +0100, Athmane Madjoudj wrote: > On 01/09/2011 08:04 PM, seth vidal wrote: > > On Sun, 2011-01-09 at 10:21 -0800, Toshio Kuratomi wrote: > > > >... > > > > I would be willing to wager the delay in porting is the same delay in > > porting anything - it just sucks to rewrite code you wrote before and > > sift around new details of the new system. > > > > It's just not fun. > > What about using "homemade" stacks without mega-framework ie: > > CherryPy + SQLObject or SQLAlchemy + Kid or Cheetah ...etc > > Will this cost much effort ? > I would say yes. TurboGears1.0 and 1.1 are basically CherryPy2 + (SQLObject or SQLAlchemy) + (Kid or genshi). TurboGears-1.5 is CherryPy3 + SQLAlchemy + genshi. TurboGears2 is Pylons + SQLAlchemy + genshi By building on top of TG we get a little bit of abstraction from the underlying layers (for instance, we could go with kid on all of those frameworks even though it's not the default. Same with SQLObject, at least for the TG-1.x's). We also get some niceties (like setup of some of the components done for us). If we built out own framework on top of the same underlying components I think we'd just end up reinventing a lot of TurboGears code and still having to deal with upstream version change... just at the level of upgrading from CherryPy2 to CherryPy3 or kid to genshi instead of at the level of TurboGears. -Toshio pgpDSMk9aWhp7.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Turbogears downgraded on fas servers
On Mon, Jan 10, 2011 at 10:38:24AM -0500, Michael Semcheski wrote: > On Sun, Jan 9, 2011 at 1:21 PM, Toshio Kuratomi wrote: > >> So how much of infrastructure is still using TG-1.0.x and how much > >> work will it be to move to TG2 since that may sooner or later be our > >> only alternative. > >> > > bodhi, mirrormanager, packagedb, elections, fas, smolt -- everything that's > > written in TG except fedoracommunity is TG1. > > > > I wonder if TG2 is the best target - will that just be punting the > problem down a few years? > You are correct that its porting to something that we'll later have to port again. However, one thing I've found in open source is that there are no platforms where you can write something and never have to port again. So, for me, it's a question of how long we'll be able to remain on TG2 before we have to port again. If we can get three years out of it, that would be acceptable, I think. If we can get five years that would be awesome. > Maybe pyramid + sqlalchemy + [genshi | mako] is a better target. I'm > not sure if that's what TurboGears2 actually is, or will be. > > But it seems like there's a bit of upheaval going on with pylons and > pyramid. Maybe that should shake out a little? > That's basically what TurboGears 3 will be. But my understanding is both pyramid and TG3 are still figuring out what they're going to look like in the next year. > Either way, I've written a bit of TurboGears and CherryPy apps, and > I'd like to help with the transition. That would be great! If you use IRC, I'm abadger1999 on irc.freenode.net. I'll get you started porting elections to TG2 and get you sponsored into whatever groups are necessary. -Toshio pgpQnk5mo0JbS.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [FAS auth] - question
On Mon, Feb 21, 2011 at 06:39:14PM +1300, Jose Mathew Manimala wrote: > Umm, I maybe on the wrong side of things but can there be a hash > generation api or something for FAS using OAUTH as the base? Its an idea > so that we can collaborate with external applications. > > Good idea or bad? > We probably only need openid -- ie: authentication, not authorization. FAS does provide OpenID at this time although we hesitate to officially take it out of beta as there's still reports of sites that don't work with FAS's openid provider (although a few months ago I reset my password on all of my open-source related bug trackers/etc and everyone that was an openid client worked with FAS). Transifex can't do openid authentication at this time but if it did then we should be able to link FAS accounts with transifex accounts. -Toshio pgphUUXGe7nxE.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
[Change Request] Disable transifex logins
As the next step in migrating to transifex.net we would like to disable
logging in to the Fedora transifex instance and put up a banner that tells
people to use http://fedora.transifex.org/ instead.
Can I get to +1's to push this change out to the app servers?
-Toshio
From b1e42bcd827a68a9918484e5e11ea5f2a141ca3e Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Toshio=20=E3=81=8F=E3=82=89=E3=81=A8=E3=81=BF?=
Date: Mon, 21 Feb 2011 22:34:24 +
Subject: [PATCH] Disable logins to transifex
---
manifests/servergroups/appRhel.pp |1 +
.../hotfix/files/transifex/tx-simpleauth-views.py | 40 ++
.../files/transifex/tx-templates-base-sample.html | 126
.../hotfix/files/transifex/tx-templates-index.html | 34 ++
.../transifex/tx-templates-migration_notice.html |1 +
.../transifex/tx-templates-simpleauth-signin.html | 33 +
modules/hotfix/manifests/init.pp | 28 +
7 files changed, 263 insertions(+), 0 deletions(-)
create mode 100644 modules/hotfix/files/transifex/tx-simpleauth-views.py
create mode 100644 modules/hotfix/files/transifex/tx-templates-base-sample.html
create mode 100644 modules/hotfix/files/transifex/tx-templates-index.html
create mode 100644
modules/hotfix/files/transifex/tx-templates-migration_notice.html
create mode 100644
modules/hotfix/files/transifex/tx-templates-simpleauth-signin.html
diff --git a/manifests/servergroups/appRhel.pp
b/manifests/servergroups/appRhel.pp
index efbc053..b953070 100644
--- a/manifests/servergroups/appRhel.pp
+++ b/manifests/servergroups/appRhel.pp
@@ -29,6 +29,7 @@ class appRhel {
if $datacenter == "phx" {
include transifex::app
+include hotfix::transifex
mediawiki::instance { "fp":
wpath=> "w",
wikipath => "wiki",
diff --git a/modules/hotfix/files/transifex/tx-simpleauth-views.py
b/modules/hotfix/files/transifex/tx-simpleauth-views.py
new file mode 100644
index 000..f38234c
--- /dev/null
+++ b/modules/hotfix/files/transifex/tx-simpleauth-views.py
@@ -0,0 +1,40 @@
+from django.conf import settings
+from django.http import HttpResponseRedirect
+from django.shortcuts import render_to_response
+from django.template import RequestContext
+from django.contrib.auth.decorators import login_required
+from django.contrib.auth.views import (logout as auth_logout,
+ login as auth_login)
+from simpleauth.util import clean_next
+
+
+@login_required
+def logout(request, template_name='simpleauth/logged_out.html'):
+"""Logout the user from the website and redirect back."""
+next = clean_next(request.GET.get('next'))
+auth_logout(request, next_page=next, template_name=template_name)
+return HttpResponseRedirect(next)
+
+
+def login(request, template_name='simpleauth/signin.html'):
+"""Login the user to the website and redirect back."""
+# Migration to fedora.transifex.net
+request.user.message_set.create(
+message=_("Login is disabled due to migration to
fedora.transifex.net."))
+return HttpResponseRedirect(reverse('transifex.home'))
+#next = clean_next(request.GET.get('next'))
+## By default keep the user logged in for 3 weeks
+## TODO: Make this an option with a checkbox (#129)
+#login_duration = getattr(settings, 'LOGIN_DAYS', 21) * 60 * 60 * 24
+#request.session.set_expiry(login_duration)
+#return auth_login(request, template_name=template_name,
+# redirect_field_name='next')
+
+
+@login_required
+def account_settings(request, template_name='simpleauth/settings.html'):
+"""Account settings page."""
+msg = request.GET.get('msg', '')
+return render_to_response(template_name,
+ {'msg': msg,},
+ context_instance=RequestContext(request))
diff --git a/modules/hotfix/files/transifex/tx-templates-base-sample.html
b/modules/hotfix/files/transifex/tx-templates-base-sample.html
new file mode 100644
index 000..da4862f
--- /dev/null
+++ b/modules/hotfix/files/transifex/tx-templates-base-sample.html
@@ -0,0 +1,126 @@
+{% load i18n %}
+{% load txcommontags %}
+http://www.w3.org/TR/html4/strict.dtd";>
+
+
+
+ {% block title %}{% trans "Transifex" %}{% endblock %}
+
+ {% block basecss %}
+
+
+
+
+
+ {% endblock %}
+ {% block basejs %}
+
+
+
+
+ {% endblock %}
+ {% block shortcut_icon %}
+
+ {% endblock %}
+ {% block extracss %}{% endblock %}
+ {% block extrajs %}{% endblock %}
+ {% block extra_head %}{% endblock %}
+
+
+
+
+
+
+{% block logo %}{% endblock %}
+
+
+
+ {% trans "Projects" %}
+ | {% trans "Collections" %}
+ | {% trans "Languages" %}
+
+
+
+{% url django.views.i18n.set_language as set_language_url %}
+
+
+
+{% for lang in LANGUAGES %}
+ {{
lang.0 }}
+{% endfor %}
+
+
+
+
[Change Request] Fix transifex disablement to not traceback w/ search engines
Search engines are hitting the login page and tripping a traceback. I'd
like to apply this patch to our hotfix from yesterday in order to fix that.
Issue reported here:
https://fedorahosted.org/fedora-infrastructure/ticket/2638
Can I get two +1's?
-Toshio
From 26a5cc3de7b397dfd00903ea2659b73b966f15c8 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Toshio=20=E3=81=8F=E3=82=89=E3=81=A8=E3=81=BF?=
Date: Tue, 22 Feb 2011 17:09:49 +
Subject: [PATCH] Fix search engines hitting the login page and causing a
traceback
---
.../hotfix/files/transifex/tx-simpleauth-views.py |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/modules/hotfix/files/transifex/tx-simpleauth-views.py
b/modules/hotfix/files/transifex/tx-simpleauth-views.py
index f38234c..d4ccb48 100644
--- a/modules/hotfix/files/transifex/tx-simpleauth-views.py
+++ b/modules/hotfix/files/transifex/tx-simpleauth-views.py
@@ -19,8 +19,11 @@ def logout(request,
template_name='simpleauth/logged_out.html'):
def login(request, template_name='simpleauth/signin.html'):
"""Login the user to the website and redirect back."""
# Migration to fedora.transifex.net
-request.user.message_set.create(
-message=_("Login is disabled due to migration to
fedora.transifex.net."))
+try:
+request.user.message_set.create(
+message=_("Login is disabled due to migration to
fedora.transifex.net."))
+ except:
+ pass
return HttpResponseRedirect(reverse('transifex.home'))
#next = clean_next(request.GET.get('next'))
## By default keep the user logged in for 3 weeks
--
1.5.5.6
pgpAWMtbiE0Do.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [Fwd: [puppet] Fix more indenting]
On Tue, Feb 22, 2011 at 09:02:37PM -0600, Dennis Gilmore wrote:
> On Tuesday, February 22, 2011 07:56:03 pm Nick Bebout wrote:
> > The last two patches should fix the root cause of the spams, and extra
> > space before except and pass.
> >
> > I applied these as "emergency" patches also, to avoid flooding root@redhat
> > with like ~20-30 errors per minute
> >
> > Nick
> >
> > Original Message
> > Subject: [puppet] Fix more indenting
> > From:"Nick Bebout"
> > Date:Tue, February 22, 2011 7:51 pm
> > To: sysadmin-memb...@fedoraproject.org
> > --
> >
> > commit da94ee041dfe914c90669365feac08c03f1302a6
> > Author: Nick Bebout
> > Date: Wed Feb 23 01:51:00 2011 +
> >
> > Fix more indenting
> >
> > .../hotfix/files/transifex/tx-simpleauth-views.py |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> > ---
> > diff --git a/modules/hotfix/files/transifex/tx-simpleauth-views.py
> > b/modules/hotfix/files/transifex/tx-simpleauth-views.py
> > index 02bf8e1..e26751e 100644
> > --- a/modules/hotfix/files/transifex/tx-simpleauth-views.py
> > +++ b/modules/hotfix/files/transifex/tx-simpleauth-views.py
> > @@ -22,7 +22,7 @@ def login(request,
> > template_name='simpleauth/signin.html'): try:
> > request.user.message_set.create(
> > message=_("Login is disabled due to migration to
> > fedora.transifex.net."))
> > - except:
> > +except:
> > pass
> > return HttpResponseRedirect(reverse('transifex.home'))
> > #next = clean_next(request.GET.get('next'))
> >
> >
> > ___
> > infrastructure mailing list
> > infrastructure@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/infrastructure
> +1
+1
Thans nb
-Toshio
pgpsDp6uXQ08f.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Change Request
On Wed, Mar 02, 2011 at 10:06:05PM -0600, Dennis Gilmore wrote: > I just made a change to the rsync modules on the dl boxes to make sure the > regular modules run as nobody. this is to make sure we are not a source of > leaking a release. can i get some +1's please > +1 -Toshio pgpjoZWQiDXKO.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Freeze change request: increase varnish timeout for pkgdb to 90s
On Mon, Mar 07, 2011 at 11:45:53AM -0700, Kevin Fenzi wrote: > On Mon, 7 Mar 2011 12:32:37 -0600 > wrote: > > > Not horribly opposed, but why? > > Sorry, cut off my explanatory text there. ;( > > Basically owner-sync-pkgdb hits a pkgdb url to get vcs into to populate > into koji from releng02. This cron job is hitting the default 60 second > timeout sometimes and failing. Increasing the timeout to 90s should > allow it to always complete. > > Upsides: No cron spam emails from the failed job. New package owners > don't need to wait for packages to be buildable in koji until the job > finishes correctly. > > Downsides: not sure if there are any off hand. > +1 from me. Should be easy to revert if it causes problems too. -Toshio pgp22rlUFtFZM.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
RFR Owner Expectations
https://fedorahosted.org/fedora-infrastructure/ticket/2674 https://fedoraproject.org/wiki/Infrastructure/RFR_Responsibilities%28draft%29 We're currently suffering under the weight of too many services and too few admins. Some of that is because the expectations of people submitting RFR's isn't well defined. Here's the start of a document to address that. You're welcome to brainstorm additions to that and later we can work at organization/making it better reading for people making an RFR. I've made it a meeting discussion item to gain visibility and more feedback, but there's no decisions to be made at this time. Just need to be fleshed out more. -Toshio pgpS35lUDSTLM.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: changing a few things in our host mgmt tools
On Fri, Mar 18, 2011 at 11:04:32AM -0400, seth vidal wrote: > Hi folks, > some thoughts have been slowly coalescing in my head about how we're > managing our boxes/services and I have some suggestions I've passed by > various folks but I wanted to check them out with everyone: > > > 1. puppetd sucks. memory. Right now we have puppetd running on every > box and it wakes up every half hour and runs itself. This is fine but in > the time where it is not doing anything it just eats memory for no good > reason. I'd like to suggest we move to a cron-driven model instead of > puppetd. I'd write a simple cron job that runs every half hour to run > puppetd, if a lock file is not found. Pretty straightforward, of > course. > +1 Might need to update kickstarts and/or the SOP pages: http://fedoraproject.org/wiki/Kickstart_Infrastructure_SOP http://fedoraproject.org/wiki/Puppet_Infrastructure_SOP > 2. monitoring if puppetd has run properly: >two things we want to know about puppet runs: >a. when they last happened per-box >b. if they fell over in a horrible way. > > (a) can be known by looking at the $nodename.yaml file which lives > on the puppetmaster. I've written a script to check if that file is > older than 1 hour and report the nodename if it is. > (b) can be done via the cron job - ie: taking error output from the > puppet run and mailing to people until we fix it! :) > +1 > 3. sign** boxes. problems here: >a. These boxes are falling out of date, repeatedly, b/c they aren't > in our normal updating path. >b. these boxes don't email out to the same locations as the other > boxes >c. these boxes don't get faspassword updates properly >d. these boxes don't get config changes normally via puppet > >(a) I'd like to suggest that they be put into a normal updating path > and/or we setup a nag mail to tell us about them >(b) obviously, fix their mail configs >(c) fasclient is failing b/c of a missing token b/c, most likely, of > (d) > > I'm open to suggestions on those but it is a bit annoying b/c while I > understand their 'sensitivity' I think our way of treating them is > making the problem WORSE not better. > I agree with your assessment. I guess we need to tell releng our concerns and figure out what needs to be done For a: perhaps have releng okay us/a specific subset of sysadmins to run updates along with all the other updates. -Toshio pgpeh0e2c5arR.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
loggerhead updated for a CVE
I've updated loggerhead on hosted01/02 due to an XSS flaw. This is using the new EPEL5 builds. The changes are not large but (since el5 was on 1.17 and the fix is in 1.18.1) the changes do touch things that aren't related to the XSS fix. Likely, only projects that I'm involved in use bzr on fedorahosted (and thus loggerhead as the web viewer), but in case someone complains about problems, this is a likely culprit. PS: Thanks to ricky for making sure I saw this. -Toshio pgptnEKk2wjon.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: updating func and certmaster on puppet1
On Thu, Apr 7, 2011 at 9:55 AM, seth vidal wrote: > Hey folks, > I've got a new bug-fix and feature-improving test pkg of func and > certmaster. I'd like to try it out on puppet1. It's fully reversible - > I'll just put the old pkgs back if it breaks things. But I don't think > it will break things. > > so... - can I get 2 +1's to doing it? > +1 -Toshio ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Infrastructure repo
On Tue, Apr 12, 2011 at 01:47:52PM -0600, Kevin Fenzi wrote: > > In looking at whats in there now, there's a ton of old packages, many > of which I suspect we are no longer using anywhere at all. Do we want > to clean this out and move old packages to an archive repo or delete > them? I guess they are only taking up disk space really... > For things that we're no longer using because there's a newer version in EPEL/RHEL/etc, we probably want to delete them. Sometimes we have newer versions there because we need to deploy some changes immediately and they need a newer package of a dependency (or we pull a new build from koji directly instead of waiting for the build to enter EPEL-testing). Once those sorts of packages make it into the official repos, we no longer need to keep the old packages in infra.fp.o -Toshio pgp9nw6aduACI.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Infrastructure repo
On Wed, Apr 13, 2011 at 10:28:22AM -0600, Kevin Fenzi wrote: > On Tue, 12 Apr 2011 20:40:34 -0700 > Toshio Kuratomi wrote: > > > On Tue, Apr 12, 2011 at 01:47:52PM -0600, Kevin Fenzi wrote: > > > > > > In looking at whats in there now, there's a ton of old packages, > > > many of which I suspect we are no longer using anywhere at all. Do > > > we want to clean this out and move old packages to an archive repo > > > or delete them? I guess they are only taking up disk space > > > really... > > > > > For things that we're no longer using because there's a newer version > > in EPEL/RHEL/etc, we probably want to delete them. Sometimes we have > > newer versions there because we need to deploy some changes > > immediately and they need a newer package of a dependency (or we pull > > a new build from koji directly instead of waiting for the build to > > enter EPEL-testing). Once those sorts of packages make it into the > > official repos, we no longer need to keep the old packages in > > infra.fp.o > > How about this: > > * always keep the src.rpm around for anything in the SRPMS repo. Since > this repo isn't used directly much it shouldn't matter that it grows. > If we need an old package for some reason we can just rebuild it. > We can probably age out and discard those SRPMS as well... I do try to clean out old releases for fas and pkgdb, for instance. I do tend to keep at least one older version around -- I suppose that we could just do that in the SRPM repo and only keep newest in the RPM repo... although the primary reason to keep older packages is to be able to revert within the first week or so of a new release in case something is wrong with an update. Quick reversion means having the last binary packages stick around. > * Once per cycle we clean out the i386/x86_64 packages that are no > longer installed on any machine. > +1 > (As a side note, I am thinking we should setup a Housekeeping SOP for > once per cycle a few weeks after release... we can then do this, prune > people who don't need to be in sysadmin groups anymore, prune hosted > projects or lists, etc. Of course thats another topic). Also +1. -Toshio pgpuq6aMfMjr6.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: System Naming Schema
On Fri, Apr 29, 2011 at 12:20:11AM -0400, seth vidal wrote: > On Thu, 2011-04-28 at 15:25 -0600, Kevin Fenzi wrote: > > Well, here's the simple way I imagine: > > > > - new machines increment number. > > - we setup CNAME aliases. > > - CNAMEs change when new machine is placed in service. > > > > For example: > > > > We have a log01. We make a new log02, get it all setup, working, etc. > > We have a 'collectd-server' cname that points to log01 > > We have a 'syslog-server' cname that points to log01 > > We have (optionally) a 'log-server' cname that points to log01. > > > > When changing things, we just change the cnames. Admins learn to login > > to the cname and it always goes to the live one. Although that doesn't > > help for puppet. > > > > > I am in favor of the above wholeheartedly - it is, implicitly, what I've > been doing with the single-server instances - like people. > > we have people01 - which is accessed by people.fp.o or fedorapeople.org > > when people02 is happy it will be where people.fp.o points to. > Do CNAMES in our internal network propogate instantly or does it depend on the DNS TTL? If the latter, I could see us having problems with things like db servers where we need to switch over from one db server to another and we really can't have any requests going to the old host. > now - what about for services which have more than one machine > backending them. > > if we have, for example, x86-01 -> x86-19 - which are builders - should > we go to 20-25 and remove 01-06? or should we just replace and keep the > same range. > > I don't mind either, I just want a decision on those. > The thing that I do like about the CNAME proposal above is that it allows most configuration to stay the same (since the configured services point at the host's CNAMES). With that in mind, we wouldn't want x86-01 to change here either. With things like the builders we also have the ability to rebuild a subset of the redundant hosts, try it out, and then decide whether to revert to the old build or move everything to the new build so replace works better here. -Toshio pgpY9h4ycOCzp.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Outage: FAS and dependent web apps - 2011-05-02 21:00 UTC
Outage: FAS and dependent web apps - 2011-05-02 21:00 UTC There will be an outage starting at 2011-05-02 21:00 UTC, which will last approximately 1 hour. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2011-05-02 21:00 UTC' Reason for outage: Performing an upgrade of the Fedora Account System (FAS) which will require database schema changes. This requires taking down FAS while the schema is updated. While FAS is down, the dependent web application services will be unavailable. Affected Services: Bodhi - https://admin.fedoraproject.org/updates/ Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ Additionally, the following services will be available for reading but not available for making changes: Fedora Hosted - https://fedorahosted.org/ Fedora Insight - https://insight.fedoraproject.org/ Translation Services - http://translate.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Unaffected Services: BFO - http://boot.fedoraproject.org/ Buildsystem - http://koji.fedoraproject.org/ GIT / Source Control DNS - ns1.fedoraproject.org, ns2.fedoraproject.org Docs - http://docs.fedoraproject.org/ Email system Fedora People - http://fedorapeople.org/ Fedora Talk - http://talk.fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Smolt - http://smolts.org/ Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Main Website - http://fedoraproject.org/ Ticket: https://fedorahosted.org/fedora-infrastructure/ticket/2748 Contact Information: Please join #fedora-admin in irc.freenode.net or add comments to the ticket for this outage above. -Toshio Kuratomi pgpgd5Sjss1Lj.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: change request - move from '*' in cron spec in puppet to 'absent'
On Tue, May 10, 2011 at 12:42:02PM -0400, seth vidal wrote:
> noticed a change happening everytime on people02 for no good reason.
>
> found this:
>
>
> http://www.mail-archive.com/puppet-bugs@googlegroups.com/msg17577.html
>
> I wanna make this change
> diff --git a/modules/clamav/manifests/init.pp
> b/modules/clamav/manifests/init.pp
> index e6aa2a4..5a93c89 100644
> --- a/modules/clamav/manifests/init.pp
> +++ b/modules/clamav/manifests/init.pp
> @@ -26,8 +26,8 @@ class clamav::freshclam {
> define clamav::clamscan ($paths,
> $minute=35,
> $hour=4,
> -$monthday="*",
> -$month="*",
> +$monthday=absent,
> +$month=absent,
> $weekday=5,
> $excludes=[]) {
> # $name is the mailto address
>
+1
-Toshio
pgpWguUJ3IQIH.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: change request - make robots.txt work on fho
On Tue, May 10, 2011 at 02:02:11PM -0400, Ricky Elrod wrote: > Wanted to do this before freeze, but never had a chance -- let's get > robots.txt > working on hosted1 and try to bring down cpu load and improve page load times > a > bit. > > Thoughts/+1's please. robots.txt is already there and has been for a long > time, > but nothing has told apache to use it, because apache requests go straight to > trac. > > robots.txt is set to block crawlers from accessing fh.o/*/browser/* (which is > the trac source code browser) -- as per https://fedorahosted.org/ > fedora-infrastructure/ticket/1848 > +1 The web interfaces at git.fedorahosted.org/git/, bzr.fp.o/bzr, and hg.fp.o/hg take care of this I think. The one question I have in regards to this is do we have an svn web viewer? -Toshio > > > diff --git a/configs/web/fedorahosted.org.conf b/configs/web/ > fedorahosted.org.conf > index d0f7139..8f1f2e1 100644 > --- a/configs/web/fedorahosted.org.conf > +++ b/configs/web/fedorahosted.org.conf > @@ -2,6 +2,9 @@ > ServerName fedorahosted.org > ServerAlias www.fedorahosted.org > > +# Make robots.txt be used. > +Alias /robots.txt /srv/web/fedorahosted.org/robots.txt > + > Redirect 301 / https://fedorahosted.org/ > > > ___ > infrastructure mailing list > infrastructure@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/infrastructure pgpK5AYpq1LEz.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: update puppet to 2.6.6. from epel-test on a handful of boxes
On Tue, May 10, 2011 at 02:29:35PM -0400, seth vidal wrote: > Boxes that were installed AFTER the puppet migration did not get the > latest puppet - so they have not been sending reports. > > so I need to run: > > func-command --host=db05.phx2.fedoraproject.org \ > --host=memcached03.phx2.fedoraproject.org \ > --host=ns04.phx2.fedoraproject.org \ > --host=secondary02.phx2.fedoraproject.org \ > "yum --enablerepo=epel-test -y update puppet" > > > to be fair - I actually already ran it - I just need two +1's. > +1 -Toshio pgpgjzZcj30kS.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: change request - make robots.txt work on fho
On Tue, May 10, 2011 at 03:45:15PM -0400, Ricky Elrod wrote: > Hm... maybe not. Is that something we want to look into before hand? I'm not > sure what kind of options exist for that, as I don't use svn that often (or at > all). > I'm +1 even without a separate, indexed-by-google web viewer for svn. svn can be configured to be browsable by http with just svn itself, not sure if there's a reason we aren't (apparently) doing that. -Toshio > On Tue, May 10, 2011 at 3:01 PM, Toshio Kuratomi wrote: > > On Tue, May 10, 2011 at 02:02:11PM -0400, Ricky Elrod wrote: > > Wanted to do this before freeze, but never had a chance -- let's get > robots.txt > > working on hosted1 and try to bring down cpu load and improve page load > times a > > bit. > > > > Thoughts/+1's please. robots.txt is already there and has been for a > long > time, > > but nothing has told apache to use it, because apache requests go > straight to > > trac. > > > > robots.txt is set to block crawlers from accessing fh.o/*/browser/* > (which is > > the trac source code browser) -- as per https://fedorahosted.org/ > > fedora-infrastructure/ticket/1848 > > > +1 > > The web interfaces at git.fedorahosted.org/git/, bzr.fp.o/bzr, and > hg.fp.o/hg take care of this I think. The one question I have in regards > to > this is do we have an svn web viewer? > > -Toshio > > > > > > diff --git a/configs/web/fedorahosted.org.conf b/configs/web/ > > fedorahosted.org.conf > > index d0f7139..8f1f2e1 100644 > > --- a/configs/web/fedorahosted.org.conf > > +++ b/configs/web/fedorahosted.org.conf > > @@ -2,6 +2,9 @@ > > ServerName fedorahosted.org > > ServerAlias www.fedorahosted.org > > > > +# Make robots.txt be used. > > +Alias /robots.txt /srv/web/fedorahosted.org/robots.txt > > + > > Redirect 301 / https://fedorahosted.org/ > > > > > > > ___ > > infrastructure mailing list > > infrastructure@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/infrastructure > > > ___ > infrastructure mailing list > infrastructure@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/infrastructure > > > ___ > infrastructure mailing list > infrastructure@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/infrastructure pgpbIs6ikf087.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
[Change Request] fasClient fix
The hotfix for fasClient that I applied just before change freeze has
a small bug that causes SELinux labels to not be applied to the
authorized_keys files when fasClient runs. I'd like to apply this fix to
the fasClient hotfix:
diff --git a/modules/hotfix/files/fas/fasClient
b/modules/hotfix/files/fas/fasClient
index 59bff7d..fe2ab6e 100755
--- a/modules/hotfix/files/fas/fasClient
+++ b/modules/hotfix/files/fas/fasClient
@@ -567,7 +567,8 @@ class MakeShellAccounts(AccountSystem):
os.remove(key_file)
except OSError:
pass
-subprocess.call(['/sbin/restorecon', '-R', os.path.join(home_dir_base,
'*', '.ssh')], shell=True)
+ subprocess.call(' '.join(['/sbin/restorecon', '-R',
+ os.path.join(home_dir_base, '*', '.ssh')]), shell=True)
def install_passwd_db(self):
'''Install the password database'''
Can I get two +1's?
-Toshio
pgpdXDsqkWFP0.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: change request - make robots.txt work on fho
On Wed, May 11, 2011 at 06:33:43PM -0400, Ricky Elrod wrote: > So apparently our redirect from http:// to https:// overrides Aliases in the > http:// vhost. > > Two new +1's to move this over to the https:// vhost please. > > +1 -Toshio pgpYSkv843zJI.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Change request - pkgs01 items
On Thu, May 12, 2011 at 01:42:16PM -0600, Kevin Fenzi wrote: > I have 2 items (feel free to vote on them separately if you prefer, as > they are independent). > > 1. The patched gitolite we had installed on pkgs01 in the recent outage > was incomplete. When someone tries to push changes on an old style > branch it says: > > remote: refs/heads/f15/master > remote: Please see URL for more info > remote: error: hook declined to update refs/heads/f15/master > > But has no actual URL in it. ;) > The updated patch says: > > remote: NOTE: Branch naming scheme has changed. You attempted to push > remote: to: refs/heads/f15/master > remote: Please see https://fedoraproject.org/wiki/Dist_Git_Branch_Redux for > more info. > > Fixing this requires us to upgrade gitolite to the new patched version. > I take it this is the only change to the package? If so, +1. If not, let's apply this as a hotfix via puppet instead. > 2. The pkgdb2branch.py script on pkgs01 still creates new packages with the > old style branch names, > causing them to not work at all for maintainers. ;( > > This fix to the script fixes that: > > --- > modules/gitolite/files/distgit/pkgdb2branch.py |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/modules/gitolite/files/distgit/pkgdb2branch.py > b/modules/gitolite/files/distgit/pkgdb2branch.py > index dee7e4e..8bc0503 100755 > --- a/modules/gitolite/files/distgit/pkgdb2branch.py > +++ b/modules/gitolite/files/distgit/pkgdb2branch.py > @@ -187,7 +187,8 @@ class Brancher(object): > (branch, pkgname)) > > # Add the master to the branch > -branch = '%s/master' % branch > +# No longer add this after the new branching setup. > +#branch = '%s/master' % branch > # If branchFrom is None, this is an EOL release > # If the directory already exists, no need to invoke mkbranch > if branchFrom: +1 -Toshio pgpT6rwD8oDgG.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [Change Request] Fix fasClient restorecon issue
On Thu, May 12, 2011 at 07:04:42PM -0400, Ricky Zhou wrote: > Ricky and Toshio noticed that the restorecon call in fasClient was > hitting file descriptor limits on hosted01. I'd like to apply this > hotfix (to all machines). > > http://git.fedorahosted.org/git/?p=fas.git;a=blobdiff;f=client/fasClient;h=d30b811c1b903a97bd7270ea87b51024c0969798;hp=3e71f9507d7bdf976aedb200b47382eac8179b3e;hb=11be93da05b84848066659e1f0c8a188fa1e1b4f;hpb=7a8d218ff006d598a4f7ec73e7973af8c3bf5331 > +1 -Toshio pgpBBvJ6hvqa5.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Change request - pkgs01 items
On Thu, May 12, 2011 at 05:19:55PM -0600, Kevin Fenzi wrote: > On Thu, 12 May 2011 14:23:30 -0700 > Jesse Keating wrote: > > > It is the only change. I built the package. I also hotfixed the system > > before realizing that we were in an outage. > > Ah, so, we can: > > a) Just not worry about it right at the moment. > > b) add a hotfix for the file in puppet and match it up with whats on > there now. > > c) Apply the package update so no hotfix or local mod is there. > I'd do c). The package exists, let's use it. -Toshio pgp0MLoNA4oTC.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: [Change Request] Fix FAS Chinese translation
On Fri, May 13, 2011 at 09:07:18PM -0400, Ricky Zhou wrote:
> Currently, selecting the Chinese translation of FAS causes FAS to
> traceback, due to an bug in Python's gettext implementation
> (http://bugs.python.org/issue1448060). I'd like to hotfix this by
> replacing the Chinese MO file with a newer version. This is pretty low
> risk, since the Chinese translation can't become any more broken than it
> is now :-)
>
> Upstream commit:
> http://git.fedorahosted.org/git/?p=fas.git;a=commit;h=8a55ecb7d887014dabddc3ce23be53cff31b7c9c
>
> Puppet patch:
> diff --git a/modules/hotfix/files/fas/zh_CN.mo
> b/modules/hotfix/files/fas/zh_CN.mo
> new file mode 100644
> index 000..dba956f
> Binary files /dev/null and b/modules/hotfix/files/fas/zh_CN.mo differ
> diff --git a/modules/hotfix/manifests/init.pp
> b/modules/hotfix/manifests/init.pp
> index 5e83163..179d687 100644
> --- a/modules/hotfix/manifests/init.pp
> +++ b/modules/hotfix/manifests/init.pp
> @@ -14,6 +14,13 @@ class hotfix::python-fedora-fas2 {
> }
>
> class hotfix::fas {
> +file { "/usr/share/locale/zh_CN/LC_MESSAGES/fas.mo":
> +owner=> "root",
> +group=> "root",
> +mode => 0644,
> +source => "puppet:///hotfix/fas/zh_CN.mo",
> +requires => Package["fas"],
> +}
> }
>
> class hotfix::pkgdb {
>
+1
Thanks for fixing this,
-Toshio
pgp3AfUHD11IY.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: compress old puppet reports
On Mon, May 16, 2011 at 03:17:46PM -0600, Kevin Fenzi wrote: > On Mon, 16 May 2011 16:55:27 -0400 > seth vidal wrote: > > > Puppet reports have grown since we switched from 0.25 to 2.6.X by > > roughly 10x their original size. > > > > so they are sucking the disk space out of puppet1 b/c we keep them > > there. > > > > When I reduced the number we keep it didn't have as nice of an impact > > on our free space as I would like. > > > > So - I wrote this to modify our reports clean up to compress all .yaml > > files except for the latest 24hours worth of them. > > > > It keeps 1month present - but much, much, smaller > > > > and it keeps the latest 24 hours worth immediately available. > > > > here's the patch: > > > > > > diff --git a/modules/puppet/files/puppet-report-clean.sh > > b/modules/puppet/files/puppet-report-clean.sh > > index d274e2b..d4af330 100755 > > --- a/modules/puppet/files/puppet-report-clean.sh > > +++ b/modules/puppet/files/puppet-report-clean.sh > > @@ -2,3 +2,11 @@ > > > > # clean up all but the last 1 month of puppet reports > > /usr/sbin/tmpwatch --mtime 720 /var/lib/puppet/reports/ > > + > > +# compress all the .yaml files per host dir, except for the latest 24 > > hours worth. > > +# since they are txt files and compress really well > > + > > +for host in `echo /var/lib/puppet/reports/*` > > +do > > + /bin/ls -1 $host/*.yaml | head --lines=-48 | xargs --no-run-if-empty > > xz -9 > > +done > > > > > > > > need two +1's please > > +1. xz for the win. > +1 -Toshio pgpUoa4ExLJi7.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: Fix people logs/awstats
On Mon, May 16, 2011 at 05:23:32PM -0400, seth vidal wrote:
> On Mon, 2011-05-16 at 15:22 -0600, Kevin Fenzi wrote:
> > When we moved to people02 from people01, we didn't change where we
> > pulled the logs from and ran awstats on on log02.
> >
> > Should be a pretty safe change:
> >
> > diff --git a/manifests/nodes/log02.phx2.fedoraproject.org.pp
> > b/manifests/nodes/log02.phx2.fedor
> > index 2599866..64d8b4c 100644
> > --- a/manifests/nodes/log02.phx2.fedoraproject.org.pp
> > +++ b/manifests/nodes/log02.phx2.fedoraproject.org.pp
> > @@ -39,7 +39,7 @@ node log02 {
> > log_dir => "secondary01",
> > }
> > awstats::site { "fedorapeople.org":
> > -log_dir => "people01",
> > +log_dir => "people02",
> > }
> > iptables::firewall { 'ipv4':
> > #precustom => [ '-A INPUT -p udp -m udp --dport 25826 -j ACCEPT'],
> > diff --git a/modules/scripts/files/syncHttpLogs.sh
> > b/modules/scripts/files/syncHttpLogs.sh
> > index 3e5ad55..9856d68 100644
> > --- a/modules/scripts/files/syncHttpLogs.sh
> > +++ b/modules/scripts/files/syncHttpLogs.sh
> > @@ -50,7 +50,7 @@ syncHttpLogs value01
> > syncHttpLogs value02
> > syncHttpLogs secondary01
> > syncHttpLogs hosted01 old
> > -syncHttpLogs people01 old
> > +syncHttpLogs people02
> > syncHttpLogs noc01
> > syncHttpLogs download01
> > syncHttpLogs download02
> >
> > ___
> > infrastructure mailing list
> > infrastructure@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/infrastructure
>
>
> +1
> -sv
>
+1
-Toshio
pgpMZJkvS7cs3.pgp
Description: PGP signature
___
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: New RFR -- Zanata instance
On Tue, Jun 14, 2011 at 12:44:54PM +0200, Kévin Raymond wrote: > On Tue, Jun 14, 2011 at 12:33 PM, Dimitris Glezos wrote: > > On Tue, Jun 14, 2011 at 12:21 AM, Ruediger Landmann > > wrote: > >> Zanata[1] is a web-based translation interface that I would like to test > >> on Fedora infrastructure over the next six months. You can see a running > >> instance at https://translate.jboss.org > >> > >> I have filed an RFR[2] and would appreciate your feedback -- or better > >> still, your support! I feel confident that I will be able to get a > >> Zanata instance up and running, and that I will be able to recruit the > >> necessary project maintainers and translators necessary to test the > >> software. > > > > *sigh* > > > > Are there any specific concerns the Fedora translation community has > > raised about the existing, proven infrastructure which weren't > > addressed? Why do we need to test a new software? > > > > -d > > > > > > > > -- > > Dimitris Glezos > > > > I don't think so, this has not been discussed in the trans mailing list. > Since we've been paring down unused services in infrastructure recently, I'm inclined to wait for a need to arise/the translation community to ask for a new service before deploying something new. While theoretically someone in infrastructure could step forward to sponsor a zanata testing instance onto publictest boxes, it doesn't seem like a good use of time unless it addresses some need within Fedora -Toshio pgpmtuTprK2mp.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: New RFR -- Zanata instance
On Thu, Jun 16, 2011 at 10:11:19AM -0400, Jared Smith wrote: > 2) Some people have expressed concerns to me personally that they're > uncomfortable having a core piece of Fedora infrastructure hosted by a > third-party, even if we have a great relationship with that third > party. > The thing about this is that I don't think anyone on the present infrastructure team sees this as a problem; unless I've forgotten someone I think that we're unanimous in thinking of this as an opportunity. So the foundation of this argument carries less than zero weight with us (less as this argument just gets people to feeling that the people proposing the change are doing so because of fundamental disagreements that we'll never agree with.) Any change to production infrastructure will need to have reasons that transifex.net is a less desirable solution than something else that we manage. > 3) At the same time, there's always been a lack of community > involvement in the day-to-day maintenance (from a infrastructure > standpoint) of Fedora's translation infrastructure. If we go back to > any soft of self-hosted translation system (Transifex, Zanata, or > anything else), it's going to need a small team of folks from the > Fedora community to step up and dedicate themselves to keeping it > running, keeping it patched, and keeping it upgraded. The ongoing > maintenance burden is a something that keeps folks like me awake at > night, and shouldn't be taken lightly. > Noting here that you earn a greater degree of trust and freedom to make decisions when you join the Infrastructure team and happen to focus on a project rather than working on a project within infrastructure. The shift in emphasis there is whether you are around on IRC, contribute to other areas that aren't your primary focus, and generally, have a presence that says, I'm not just going to disappear and leave my projects resting on your shoulders in the future. > 4) Another thing to consider is whether a self-hosted solution has > been packaged for Fedora. I know that Transifex is packaged for > Fedora, but I don't see Zanata in the package list. > Zanata is built on the JBoss framework and JBoss hasn't even been packaged in Fedora. > 6) While this concept is currently being discussed here on the > infrastructure list, I think it's really a subject that needs to be > discussed with a wider audience. It's a topic that affects > infrastructure, translation, packagers, and documentation at a > minimum. My plan is to kick of some discussions in those groups, and > then try to schedule a wider meeting in the next two weeks (similar to > the meetings we held before the transition to tx.net). > So... having been a part of the multi-year insight development from the infrastructure side, there's two aspects: Consuming groups: 1) What features do we need? 2) What features do we desire? 3) What manpower can we pony up to deploy this? 4) What manpower can we pony up to maintain this? 5) What is out there that might satisfy our needs? Providing groups (infra): 1) What computing resources are needed to support this? 2) What manpower resources are needed to support this? 2.a) What security implications does running this entail? 2.b) Do we have inhouse knowledge that will support running this? 2.c) Do we have in-Fedora knowledge to fall back on? 2.e) Is this something we need to run? 3) What is the effect on Fedora if we find that we cannot continue to support this in the future? 4) What is out there that's going to be easiest to support? In the early stages, the consuming groups are really doing the most evaluation since they have to determine what features they must have and what features they desire to have. However, they either need to understand the support burden so they have something decent to present to infrastructure or (probably preferably) they need to stop their evaluation short of trying actual products and get someone in infrastructure interested in their list of features at that point so that they can evaluate the choices together. -Toshio pgpHrohnfyj55.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Re: puppet01 to lockbox01 migration
On Tue, Jun 21, 2011 at 03:21:52PM -0600, Stephen John Smoogen wrote: > On Tue, Jun 21, 2011 at 12:29, Kevin Fenzi wrote: > > Greetings. > > > > I've installed a new instance (lockbox01, which might be an amusing > > joke to folks who have been around for a while) to replace out puppet01 > > instance. > > > > I'd like to look at migrating early next week sometime if possible. > > > > Here's a tenative checklist: > > > > 1. Get new machine as ready as possible > > rsync over: > > /home/ > > /srv (excluding netapp mount points) > > /git > > Would it be too hard to get rid of /git and make it /srv/git ? > > > /var/www > > /var/lib/puppet > > Hmmm I was hoping we could resign systems and get rid of any mention > of our old certificate puppet.fedora.phx.redhat.com (or whatever it > thinks it is). > While I like both of these changes, I seem to recall when we renamed systems to have "0" in the names we figured out that it's better to make one major change at a time. Makes it easier to test what could be broken and what's not broken and makes it easier to troubleshoot the root cause of any new issues. -Toshio pgpZ71oYETwWR.pgp Description: PGP signature ___ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
