Re: func logrotate fix
On Sun, Sep 28, 2008 at 7:28 PM, Jon Stanley [EMAIL PROTECTED] wrote: I'll throw a -1 in here (not that my vote matters for anything :) ). Not because of any risk in the change, but rather it violates the concept of a change freeze. It doesn't affect service, so if I went to our change management meeting at work with something like this during a change freeze I'd be laughed out of the room and told to wait. In my mind, we either have change freezes and stick to them, or we just forgo the charade. I thought the point of a change freeze is so that we are more cautious about changes we have to make. Since everyone seems to approve the idea of making such a change during the change freeze, it seems acceptable to do so. -Yaakov On 9/28/08, Xavier Lamien [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 12:29 AM, Mike McGrath [EMAIL PROTECTED] wrote: I'd like to implement the following global fix (its generating cron spam) in /etc/logrotate.d/func_rotate I'd like to change line 8 from /etc/init.d/funcd condrestart to /etc/init.d/funcd condrestart /dev/null Can I get 2 +1's? +1 ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: RFC: script to run sqlalchemy migrations on the db
On Mon, Aug 11, 2008 at 4:31 PM, Mike McGrath [EMAIL PROTECTED] wrote: On Mon, 11 Aug 2008, Yaakov Nemoy wrote: 2008/8/9 Toshio Kuratomi [EMAIL PROTECTED]: FAS started using the python-migrate package to update its db. This is a good thing for third-parties that want to install their own FAS server as it lets us ship the database changes in a way that is easy for those users to apply to their own production databases. However, it doesn't work very well in our particular environment because we're a bit more strict about our permissions than the migrate authors envision. In order to perform migrations, you need to have a user that can modify the schema for the db. This is either hte owner of the db or the superuser. In our setup, we create the db with the superuser and then run our web apps with another user. This prevents the normal web app from modifying the db schema. To work around this I propose writing a script that does this: # 1) Create a db user. # 2) grant access to all the values in the specified db # 3) run the migrate commands to create the manage.py script and run it with the new username and password # 4) Reassign any new tables to the postgres user # 5) Remove the temporary db user The command line to invoke it would then look like this: sudo -u postgres migrate-runner -h DBHOST -d DBNAME MIGRATE_REPO Does this look: 1) Doable -- loupgaroublond I'm looking at you to tell me what the migrate commands will be and if there's any caveats to this 2) Secure -- the point of this would be to keep protecting the db superuser with a sudo account on db2 and not being able to use it without a shell on db2. If the security of this solution is less than what giving a password to a superuser account would be then we might as well do that instead. If this looks good, I'll work on coding something up. I don't see how this is any more secure than just either granting some user sudo or creating a long term admin DB role just for the FAS DB that is well protected. You must be a developer ;-) As I see it: 1) the FAS run time itself has not been security audited and vetted, therefore the least damage it can do to the DB the better. Even if it had... You shouldn't consider it 'secure'. We've done plenty of audits. AFAIK there is no industry standard for vetting. 2) Most of the admins, or rather the people in charge of upgrading FAS on our servers have been security audited and vetted through a system of mutual respect in a meritocracy. Why do we need a temporary superuser account every time we upgrade? Those users don't have db accounts, fas does. And we don't want to give the fas user more rights then it needs. 3) If we store the long term superuser account for FAS somewhere so upgrade scripts can be done automatically, then all I think we need is some SELinux / file perm policy that prevents FAS from accessing those files itself. If the upgrade script can create a temporary user and get rid of it. Why risk having that account used during a non-upgrade time. I'm fine with using SElinux as a backup to primary security policies. But using SELinux as a primary security of some kind. No thanks, we've had to disable it in the past for various reasons before we were able to re-enable it even in permissive mode. I see then. My recommendation is to have an outside wrapper that just takes random db url stuff, including a superuser username and password, creates a new superuser, passes the new user to migrate.py and lets migrate.py take over from there. It's doable, I just don't see what security we gain, over having certain dedicated users (namely toshio and/or ricky) who are the only ones who can run migrate.py, using the superuser password. -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: doing FAS2 with sqlalchemy-migrate
On Sun, Jul 20, 2008 at 9:06 AM, Luke Macken [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 05:45:44PM +0200, Yaakov Nemoy wrote: On Thu, Jul 17, 2008 at 4:40 PM, Luke Macken [EMAIL PROTECTED] wrote: I reviewed and approved python-migrate yesterday. It's currently waiting to be built. https://bugzilla.redhat.com/show_bug.cgi?id=452388 How long does that take? I'll have to change the docs once it's done. python-migrate is now in updates-testing I'll modify the documentation to presume it's already in Fedora then, namely just adding 'python-migrate' to the list of dependencies. -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
doing FAS2 with sqlalchemy-migrate
Hey List, There are alot of tickets for FAS2 outstanding that require some changes to the DB. Toshio is working on getting sqlalchemy-migrate into Fedora now, so I felt it would be fitting to get FAS2 to be an example of how to do it right. (This means I am probably doing something wrong.) http://git.fedorahosted.org/git/fas.git?p=fas.git;a=commitdiff;h=21643256e4840aa2179b8f2d6cf230ab714603a9 This git commit sets up migration for us. The instructions how to use it are there. In short, the overlying design is to assume the DB has already been configured and deployed using the old method. This will manage changes we do on top. This will make it easier for people with working development trees to simply migrate their dev systems over without having to start their DB fresh. Please poke holes in this plan, so we can have something more solid that can be used as a gold standard for Fedora Infrastructure development. -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: doing FAS2 with sqlalchemy-migrate
On Thu, Jul 17, 2008 at 4:40 PM, Luke Macken [EMAIL PROTECTED] wrote: I reviewed and approved python-migrate yesterday. It's currently waiting to be built. https://bugzilla.redhat.com/show_bug.cgi?id=452388 How long does that take? I'll have to change the docs once it's done. -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
syntax colouring on the wiki
Hey List, Is there any chance the new wiki can do syntax hilighting and colouring for source code. I presume it would look something like this: pre style='Python' def foo(bar, baz): return bar + baz /pre -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Blog syndication for GSoC - ers
On Mon, May 26, 2008 at 3:01 AM, Karsten Wade [EMAIL PROTECTED] wrote: It would be but I get the feeling that some aren't joining or aren't allowed to because of google rules (I have no idea about either of these, someone please correct me) Well, AIUI Google's whole point of getting the students connected months ago was so they could join the projects and so forth. If there are any students who haven't got their FAS account ... why? Etc. Google mainly wants the students to fit in with the project, under our own regular processes. Where they exert influence is in, for example, requiring the students to work on their own code and not be a a team working on a module, etc. I presume this is mainly to let them tie expenditure to effort directly, without team effects. This is more or less 'it' in a nutshell. There is one extra requirement that they have a uploadable set of files, mainly for legal reasons. That's pretty much all there is to it. In my case, I've asked pavel to email me patches for git. The reasoning is that we'll have a log of emails complete with files that can be tarballed and submitted to Google easily. I've asked him not to ask for permission to participate in our git instance, although he really does need to sign up for our trac. He also needs to be signed up for the wiki, and a few mailing lists. His participation is supposed to be the same as anyone else's with the notable exception of the 'hgsmolt' group. -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Notice of awayness
Hi lists, I'm probably not important enough that it warrants a full message, but this is to inform you that I will be out of touch from May 26th 2008 through May 31st 2008. I will have limited access to internet and email, and will be busy interacting with people in meatspace anyways. If there are any major problems with Smolt, or anything else that requires my attention, the best person to reach is probably Mike McGrath. -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Blog syndication for GSoC - ers
On Sat, May 24, 2008 at 10:04 PM, Eugene Teo [EMAIL PROTECTED] wrote: Sankarshan Mukhopadhyay wrote: With the new process for getting (and staying) on Planet Fedora in place, how does it affect GSoC-ers ? Do we have their blogs on the Planet ? And, do they get FedoraPeople.org accounts ? Is it possible to waive the requirement that my mentee has to be sponsored to a group other than the CLA group? I remember there were discussion about syndicating our mentees blogs to Planet Fedora? I'm going to forward this to seth vidal, who is in charge of such things, and the Fedora Infrastructure team. Personally I think that the students/mentees will need access to the wiki at some point or another. That can definitely count as a second group. I've made it a point for my mentee to have a biography on the wiki, and with the new wiki, it has it's own group in FAS. To actually put a blog on Planet Fedora, the mentees need to follow the instructions seth posted a few days ago. They can be found here http://skvidal.wordpress.com/2008/05/19/changes-at-planet-fedora/ -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: changes at planet fedora
On Mon, May 19, 2008 at 12:33 PM, seth vidal [EMAIL PROTECTED] wrote: Hi all, I'm making some changes with how we build up the list of folks/rss feeds for the fedora planet. We're making it more self-service and a bit easier to maintain for the admin group (and specifically easier for me to put up with). For all the people currently on the planet please follow these instructions to make sure your feed stays on there: http://skvidal.fedorapeople.org/docs/planet-addition.html These instructions will be added to the wiki after the wiki migration happens next week. Let me know what problems you have, too. How do we test these changes. Namely, once I've configured everything, how do I make sure my config file is good, and displays what I want it to display? -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Collaboration Servers!
On Wed, Feb 20, 2008 at 4:38 PM, Luke Macken [EMAIL PROTECTED] wrote: On Wed, Jan 30, 2008 at 03:15:22PM -0600, Mike McGrath wrote: collab1.fedoraproject.org is up and running. Yahoo! So whats missing? Well, it doesn't actually do anything yet. Plans for it include 1) gobby (its AMAZING) 2) pastebin or something like it (also amazing) 3) mailman. So who wants to set up what? Luke, you'd mentioned you might be able to get gobby up sometime this week / next. Is that still the case? If so I'll open a ticket and assign it to you. Sobby (the standalone obby server) is now running on gobby.fedoraproject.org. I also setup a cronjob to `git add . ; git commit -a` everything in the session hourly, and changes can be viewed via gitweb[0]. luke [0]: http://gobby.fedoraproject.org/git/gitweb.cgi?p=sobby/.git;a=summary I get a 403 error from trying to view that gitweb repo. Otherwise, pretty awesome. -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Haskell Packaging Guidelines Review
On Feb 12, 2008 7:18 PM, Jens Petersen [EMAIL PROTECTED] wrote: Hi Yaakov, Sorry for the late followup. Glad to have you join our Haskell SIG. :) I've been working on writing up guidelines for packaging Haskell packages. I need some input from people who know their way around Fedora very well. Some of the issues involved nuances of Haskell, but many of them are questions because I don't know enough about Fedora myself. If any one has the time to give these a looking over, and comment on some of the points where I've left question marks, it would be very helpful so that hopefully I might have a few interesting things in for Fedora 9 Beta. http://fedoraproject.org/wiki/PackagingDrafts/Haskell Thanks for working on this. It is something that the Haskell SIG had not got round to doing yet. Though we are not that big, I think it would help to make a fedora-haskell-list for the SIG, so that we can focus more on the discussion there, since there is so much traffic on f-d-l. I will try to review your draft carefully soon, and provide some feedback. Thanks Jens. I'm glad to see that people are finally picking up on this. I'm CCing this to infrastructure, hopefully they can create a list. -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: TurboGears-1.0.4/SQLAlchemy-0.4 upgrade
2008/2/11 Toshio Kuratomi [EMAIL PROTECTED]: Hello TurboGears application developers, We would like to upgrade the version of Turbogears and SQLAlchemy present on the Fedora Infrastructure app servers in the near future. There are a few details that make this an update that I would like to have people test heavily but overall it should be an easy upgrade for most people. Details: TurboGears 1.0.4 is an update that retains TG-1.0.x compatibility. We don't anticipate any problems with this portion. SQLAlchemy 0.4 is an incompatible update to SA-0.3.x. TurboGears-1.0.4 includes changes to allow us to use it with minimal porting. Most Fedora Web apps are using SQLObject so they shouldn't be affected by this update. python-fedora's tgfas, pkgdb, and smolt use SQLAlchemy. loupgaroublond has already ported smolt so porting tgfas and pkgdb should be all that is needed to enable this. I'll be testing ports of both of those this week. Smolt should still work on SQLAlchemy 0.3, maybe with some very minor changes. +1 for upgrading applications, as the new SA is very slick, and TurboGears takes full advantage of this (like session creation strategies that can be customized at a TurboGears level, so they can be very intelligent about user sessions, or user threads, etc). Even so, there's no rush if we don't need to. -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: fedora.org?
2008/2/3 Anand Capur [EMAIL PROTECTED]: On 2/3/08, Mike McGrath [EMAIL PROTECTED] wrote: On Sun, 3 Feb 2008, Anand Capur wrote: On 2/3/08, Matthew Galgoci [EMAIL PROTECTED] wrote: Date: Sun, 3 Feb 2008 17:05:23 -0500 From: Anand Capur [EMAIL PROTECTED] Reply-To: fedora-infrastructure-list@redhat.com To: fedora-infrastructure-list@redhat.com Subject: fedora.org? Is there any way we can get this domain back? Is Fedora a registered trademark of ours? I think it would much be better on our site, instead of yeah, you know what I mean. (See fedora.org) We never had that domain, so there is no getting it back. Well, can't you do trademark claims with ICANN? I didn't literally mean Get it back since yeah, we never had it. Nope, but without the project in fedora project, they could use it against us. I believe they existed before we did. -Mike Even though we use Fedora as our OS name now?..We can't even get them for using it against the TLD terms since .org's uses are Nonprofits; personal sites; open-source projects; Ugh, not this question again. ICANN removed that restriction on TLD's, so anyone can have a .com, org or a .net with impunity. The only restrictions are on .edu, .gov, and .XX where XX is your nation code, plus other less oft used TLDs. IANAL, but Fedora by itself is not a trademark. Fedora doesn't even have a perfect hold on the Fedora Project moniker either. Google it and you'll see what I mean. Bottom line: Who cares. Things like this are the hazards of having an open and free internet. Now quit clogging my tubes with this ;) -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Request for monotone
On Dec 12, 2007 10:33 PM, Mike McGrath [EMAIL PROTECTED] wrote: we've had a request to support monotone on hosted. Instead of having this conversation in private I thought it best to put it on the list. So thoughts? This is part do we want to support monotone and part do we want hosted to be more then svn, hg, git, bzr. In general I'm happy supporting only those 4, we can't be everything for everyone and AFAIK we're the only OSS project with a hosted offering that supports 4 SCM's. Thoughts? +0 ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Restart TG apps for high mem-usage
On Nov 25, 2007 4:00 PM, Toshio Kuratomi [EMAIL PROTECTED] wrote: Here's a short script to test our TG apps run via supervisor for excessive memory usage and restart them if necessary. We could run this via cron in alternate hours on each app server. Does this seem like a good or bad idea to people? -Tosjio +1, but does it make sure all transactions are finished? I know smolt does not have good transaction protection. If a transaction fails halfway through, we might have a mess. -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Restart TG apps for high mem-usage
On Nov 26, 2007 12:08 AM, Toshio Kuratomi [EMAIL PROTECTED] wrote: Yaakov Nemoy wrote: On Nov 25, 2007 4:00 PM, Toshio Kuratomi [EMAIL PROTECTED] wrote: Not if the app doesn't. From a brief test, TG apps do not do this. The script is asking supervisor to shutdown the application. supervisor sends a TERM to the TG app (we can configure it to send something other than TERM if we want but I don't see any documentation that leads me to believe it will be different with a HUP or QUIT). At that point it looks like a TG app will immediately shutdown and rollback any current transactions. It's got my vote then smolt is on shaky ground if it's not using transactions correctly... At the beginning of the month when smolt was getting hit hard we did pretty much this same thing except manually instead of via a script when we noticed that smolt was giving timeouts and taking up 1G+ of RAM. I think the current smolt code is using SQLAlchemy, correct? It's pretty easy to use transactions so that you don't leave the db in an inconsistent state with that configuration. Using the session's implicit transaction flushed just before the return should do the safe thing. You can look through the code later and find additional places where you can safely flush the transaction if there's a need. We do use transactions where we can, but since most of the code is not tested at all, let alone stress tested, i can't vouch for it doing The Right Thing. (Winter break is only a few weeks away) -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: The asterisk paradox
On 8/10/07, Mike McGrath [EMAIL PROTECTED] wrote: 2) Meetings in IRC are generally very slow, it might be worth it to do the meetings as normal but also have people log in to asterisk to bs and generally just chat, get to know each other a bit better. +1 for now 3) Do as we did last week, have people who can't talk join the conference anyway and ask questions in the chat room while having someone transcribe and provide minutes. +1 in the future -Yaakov ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
