Re: Goals for F13?
On 01/06/2010 05:35 PM, Mike McGrath wrote: So F13 is underway, we should get our list of F13 goals together. So what would you like to see (and will be working on) for F13? For example, I know Jon and Dennis are working on the mail man migration. The major features include: 1) Getting virt_web into Fedora 2) download.fedoraproject.org (based on boot.kernel.org) Oh... who's working on this? -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Goals for F13?
On 01/06/2010 05:48 PM, Mike McGrath wrote: On Wed, 6 Jan 2010, Jeroen van Meeuwen wrote: On 01/06/2010 05:35 PM, Mike McGrath wrote: So F13 is underway, we should get our list of F13 goals together. So what would you like to see (and will be working on) for F13? For example, I know Jon and Dennis are working on the mail man migration. The major features include: 1) Getting virt_web into Fedora 2) download.fedoraproject.org (based on boot.kernel.org) Oh... who's working on this? Right now just me - http://publictest8.fedoraproject.org/boot/gpxe.iso boot from that. The larger goal is to get people using it, raise awareness of it and prove it's a viable solution. I'm interested in working on it with you -from the composing side as well. I'm assuming I'm gonna need to read up a lot, is there a Fedora reference page somewhere or would we need to create one still? -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Goals for F13?
On Wed, 6 Jan 2010 11:09:56 -0600 (CST), Mike McGrath mmcgr...@redhat.com wrote: On Wed, 6 Jan 2010, Jeroen van Meeuwen wrote: I'm interested in working on it with you -from the composing side as well. I'm assuming I'm gonna need to read up a lot, is there a Fedora reference page somewhere or would we need to create one still? not yet, I'm going to put a features page together shortly but ping me in #fedora-admin. I can make sure to get you access to the bits and what's going on. It should be fairly easy to put together, at a minimum 1 new package in Fedora though I think a couple of others would be useful. And it was fairly easy ;-) For those interested: - https://bugzilla.redhat.com/show_bug.cgi?id=553055 - http://www.kanarip.com/custom/f12/SRPMS/gpxe-0.9.9-2.src.rpm -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Goals for F13?
On 01/07/2010 12:34 AM, Todd Zullinger wrote: Jeroen van Meeuwen wrote: And it was fairly easy ;-) For those interested: - https://bugzilla.redhat.com/show_bug.cgi?id=553055 $ curl -I http://www.kanarip.com/custom/SPECS/gpxe.spec HTTP/1.1 403 Forbidden Date: Wed, 06 Jan 2010 23:33:18 GMT Grmbl that's what I get for using a restrictive umask on my laptop :/ Fixed now. -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [FOSDEM'10] Community infrastructure talk
That's all nice and dandy, but not much of a topic to discuss no matter what your thoughts are. When it concerns how and through what mirror your data is available to your consumers you also have entirely different motives compared to making sure your *own* infrastructure runs fashionably well. If it were up to me, I have zero interest in discussing this specific topic presented as such. -- Jeroen Frederic Hornain fhorn...@gmail.com wrote: Dear *, FYI, Ralph from CentOS community is going to so a talk about infrastructure. *Hi, I'd like to propose a talk/discussion panel around mirror infrastructure management: - How are new mirrors accepted? - How do you administer / attend to the database of mirrors? - How are mirrors checked for freshness? - How do you work with Geo localization? As before. I can tell something about how the CentOS project is doing this, but I see this more as a panel, where other distributions also talk shortly about how they manage their mirrors and then things can be discussed. This also should be interesting for other projects taking care of their own mirrors (maybe someone from a large project might add to that discussion, too). Regards, Ralph * As you have got the same problems, If you are interested to join him in this talk and have discussion/brainstorming about it feel free to contact me.* * Best Regards Frederic* ;) * On Tue, Dec 15, 2009 at 10:10 AM, Frederic Hornain fhorn...@gmail.comwrote: Dea Thanks a lot On Mon, Dec 14, 2009 at 10:52 PM, Jeroen van Meeuwen kana...@kanarip.comwrote: On 12/14/2009 10:46 PM, Jeroen van Meeuwen wrote: On 12/14/2009 09:36 PM, Frederic Hornain wrote: Dear *, Would someone be interested to make a talk on Fedora Community infrastructure at FOSDEM'10 - Belgium -? * FedoraCommunity, opensourced LaunchPad, Bugzilla extensions, etc... BTW, as the rule have changed at FOSDEM, you will do your talk with other distributions on the same subject. Thanks for your time and your help. Sure, here's a candidate! I already asked permission from our fearless leader; [22:51:30] kanarip mmcgrath, that is, if you'll let me go tete-a-tete with other distributions on the topic of infrastructure ;-))) -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list -- - Fedora-ambassadors-list mailing list fedora-ambassadors-l...@redhat.com Olpc mailing list olpc-o...@laptop.org -- - Fedora-ambassadors-list mailing list fedora-ambassadors-l...@redhat.com Olpc mailing list olpc-o...@laptop.org ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Major dns issues
On 12/14/2009 10:27 AM, Mike McGrath wrote: So I woke up today and we're still having dns issues on at least one of my hosts. Could everyone that has access please do a dig fedoraproject.org on all their hosts and tell me if any of them cannot resolve? I'm fine from 7 different locations in the Netherlands (including +trace), but not from the U.S. (digging on unity04.fedoraunity.org at server 64.122.217.133). -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [FOSDEM'10] Community infrastructure talk
On 12/14/2009 09:36 PM, Frederic Hornain wrote: Dear *, Would someone be interested to make a talk on Fedora Community infrastructure at FOSDEM'10 - Belgium -? * FedoraCommunity, opensourced LaunchPad, Bugzilla extensions, etc... BTW, as the rule have changed at FOSDEM, you will do your talk with other distributions on the same subject. Thanks for your time and your help. Sure, here's a candidate! -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [FOSDEM'10] Community infrastructure talk
On 12/14/2009 10:46 PM, Jeroen van Meeuwen wrote: On 12/14/2009 09:36 PM, Frederic Hornain wrote: Dear *, Would someone be interested to make a talk on Fedora Community infrastructure at FOSDEM'10 - Belgium -? * FedoraCommunity, opensourced LaunchPad, Bugzilla extensions, etc... BTW, as the rule have changed at FOSDEM, you will do your talk with other distributions on the same subject. Thanks for your time and your help. Sure, here's a candidate! I already asked permission from our fearless leader; [22:51:30] kanarip mmcgrath, that is, if you'll let me go tete-a-tete with other distributions on the topic of infrastructure ;-))) -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Creating a trusted sha256sum.exe binary for verifying *-CHECKSUM files on Windows
On 11/24/2009 05:25 PM, Jesse Keating wrote: On Tue, 2009-11-24 at 10:33 -0500, Todd Zullinger wrote: (I really don't want to maintain the mingw32-sha256sum package for Fedora, as it's just a quick and dirty hack to built a small subset of of coreutils for Windows.) Thoughts? Well, if you have to use a tool from the project, to verify other bits from the project, the verification just became a lot less trusted. If you don't trust the bits you got from the project, why would you trust the tool the project gives you to verify the bits? Here use this tool to verify our bits. Trust us, we swear! While this is completely true for, say winxpsp2.iso vs. m$-md5um.exe, mind that the sources to sha256sum.exe are actually available and can be verified on a completely verifiable stack one does already trust (verifiable except for x86 CPU inaccuracy of course). If not the transparency helps to boost the trustworthiness, or if that's not trustworthy enough, then how does one verify a binary rpm actually comes from the source that is shipped alongside with it, not to even mention gnupg shipped by Fedora against RPMs shipped by Fedora. Then, if trust was anything worth being concerned about why would you even need a .exe in the first place? For all you know the OS itself makes the .exe say OK or NOT OK in very, very arbitrary ways you can't verify. The goal is, of course, to verify the .iso against what is listed as it's sha256sum. Whether the tools ultimately come from the same source doesn't matter. It should, though, be advisable to not include the sha246sum.exe on the mirrors, and only serve the file over http over ssl. -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Permission for an off-site copy of CVS
On 11/23/2009 06:12 AM, Jon Stanley wrote: In an effort to work on the cvs side of https://fedorahosted.org/packagedb/ticket/165 I'd like to have an offsite copy of cvs1:/cvs/pkgs to test on. Being that this is in violation of our security policy (http://infrastructure.fedoraproject.org/csi/security-policy/en-US/html/EndUser-Standard-Introduction.html) and requires written permission, I'm asking for that permission here :) I just need two sysadmin-main members to +1 it, and I'll rsync it off tomorrow or so, Just curious, what part of the policy does a local copy from a public rsync location conflict with? ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Permission for an off-site copy of CVS
On 11/23/2009 05:18 PM, Jeroen van Meeuwen wrote: On 11/23/2009 06:12 AM, Jon Stanley wrote: In an effort to work on the cvs side of https://fedorahosted.org/packagedb/ticket/165 I'd like to have an offsite copy of cvs1:/cvs/pkgs to test on. Being that this is in violation of our security policy (http://infrastructure.fedoraproject.org/csi/security-policy/en-US/html/EndUser-Standard-Introduction.html) and requires written permission, I'm asking for that permission here :) I just need two sysadmin-main members to +1 it, and I'll rsync it off tomorrow or so, Just curious, what part of the policy does a local copy from a public rsync location conflict with? Having pressed Ctrl+Enter before I was done typing the message, I wanted to ask whether it was something I was missing, or something other then cvs1:/cvs/pkgs/ that conflicted with the security policy? Kind regards, -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Permission for an off-site copy of CVS
On 11/23/2009 06:27 PM, Mike McGrath wrote: On Mon, 23 Nov 2009, Jeroen van Meeuwen wrote: On 11/23/2009 05:18 PM, Jeroen van Meeuwen wrote: Just curious, what part of the policy does a local copy from a public rsync location conflict with? Having pressed Ctrl+Enter before I was done typing the message, I wanted to ask whether it was something I was missing, or something other then cvs1:/cvs/pkgs/ that conflicted with the security policy? Not everything under /cvs/pkgs/ world readable, in particular: /cvs/pkgs/CVSROOT/admin/ Aha! Thanks Mike ;-) -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Suitability of Python for daemon processes
On 10/25/2009 11:51 PM, Mike McGrath wrote: With all my babbling I forgot to mention we do already run python daemons in Fedora Infrastructure. Func is one, TurboGears (though it's wrapped in mod_wsgi) and one that we wrote ourselves[1] is our mirrorlist server. It's the backend that powers: http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-11arch=i386 And koji.fedoraproject.org, no? And translation is going through Django these days? -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Suitability of Python for daemon processes
On 10/26/2009 12:37 AM, Mike McGrath wrote: On Mon, 26 Oct 2009, Jeroen van Meeuwen wrote: On 10/25/2009 11:51 PM, Mike McGrath wrote: With all my babbling I forgot to mention we do already run python daemons in Fedora Infrastructure. Func is one, TurboGears (though it's wrapped in mod_wsgi) and one that we wrote ourselves[1] is our mirrorlist server. It's the backend that powers: http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-11arch=i386 And koji.fedoraproject.org, no? Yes but I think it's more along the lines of a python script that gets called when a page gets loaded, it doesn't actually run statefully like our tg apps do. But the backend does run python foo, right? And translation is going through Django these days? That's true, django is another one we run. I bet there's a few more sitting around that we haven't thought of yet :) I bet too ;-)) -- Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: mobile phone + password = 2 factor auth?
On 05/26/2009 05:44 PM, Till Maas wrote: On Tuesday 26 May 2009 15:50:49 Seth Vidal wrote: I was changing some settings with my mobile phone company and in order to change my password they made me use what looks a lot like 2 factor auth: something I know: my current password something I have: my phone I logged in with my current password - then they txt'd me a temporary password which I had to type in to verify I was me. Which got me to wondering - if most people have a mobile phone and/or have access to one - why couldn't we use that as the second factor for our auth? A problem with phones is, that they are typically not as secure as hardware tokens. Users can install custom software on them. Also the phone may be compromised via bluetooth. It might be even possible to directly access text messages via bluetooth or maybe also wifi nowadays. Although this is entirely true, my bank sure considers my phone safe enough to send me one-time transaction confirmation codes that are only valid with the existing session. So, to hack this, you would need access to my phone as well as my current session. -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: How to generate a .template and .jigdo from an iso image?
On 05/08/2009 08:35 AM, Marcelo M. Garcia wrote:
Hi
I read the man page. It says that I have to specify only one of the
options -i, -j or -t. OK. If I use only -i, my template has the
same size of image, then there is no point in using jigdo. There must be
something more.
My question is how Fedora generates the .template with only 11.1M? The
command jigdo-file -i CentOS-5.3-i386-bin-DVD.iso it's not enough.
Attached is the script Fedora Unity uses to jigdofy it's Re-Spins. Note
the function jigdofy() in the top that may just help you get the
syntax right.
Note the double slash in the two directories passed to the jigdo-file
make-template command, which functions as a delimiter for jigdo-file,
so that in the --label parameter, we can 'label' the path and then
attach a URI (--uri) to be used in the resulting .jigdo file instead.
$1 is the (fully qualified) path to the .iso image,
$2 is the base architecture for the .iso image (i386, x86_64 or ppc in
our case), and
${version} is the Fedora $releasever (9 or 10 right now).
Also note that /data/os/distr/fedora is a local, full mirror and that
/data/os/archive/fedora is a local, full archive (with package files
that have been removed from the mirror because for example they've
expired and have been superseeded by another update to said package).
Kind regards,
Jeroen van Meeuwen
-kanarip
jigdofy_everything.sh
Description: Bourne shell script
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: cgit to replace gitweb?
seth vidal wrote: On Fri, 2009-02-13 at 15:49 -0500, Bill Nottingham wrote: Well, a URL that was: /git/?p=initscripts.git;a=commitdiff;h=252c7c1bf9779dbdba94abe47350c866ba8ca421 is now (in the test instance): /cgit/initscripts.git/commit/?id=252c7c1bf9779dbdba94abe47350c866ba8ca421 We may be able to do a rewriterule? for the simple cases, sure. I doubt we'll be able to do all the tag/branch cases easily.. How about the old location is kept intact for a while while we attempt to gain some statistics on it's usage? -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Calendaring system?
Adam Williamson wrote: Hi, guys. Uh, quick intro for those who see the redhat.com and wonder who I am - I'm Adam Williamson. I'm new in the Fedora QA department here at RH, my job is to drive community involvement in Fedora QA. I came over from Mandriva where I was the community manager. I'll be working from my home in Vancouver, Canada. I'm new on the list so this may have come up before, in which case apologies :). Something I thought would be nice to have for QA community is a public calendar system where dates of events like test days can be published. Obviously it's silly for me personally or the QA team to take on the job of hosting a calendar server, but it was suggested that it would be a good project for the infrastructure team, and other groups within Fedora could probably benefit from it. Does it sound like a good idea? Anyone want to have a go? Or is there something already, that I don't know about? Thanks! I've not seen anything in this thread yet, so it may have been mentioned before; MediaWiki has a couple of calendering plugins that will allow days to be allocated; I looked into this for our meeting schedule but since none of them include any times for appointments I found it to be useless. Nonetheless, it could be worthwhile for allocating Test days and Events -and things of the sort. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Calendaring system?
Clint Savage wrote: On Mon, Feb 9, 2009 at 12:36 PM, Jeroen van Meeuwen kana...@kanarip.com wrote: Adam Williamson wrote: Hi, guys. Uh, quick intro for those who see the redhat.com and wonder who I am - I'm Adam Williamson. I'm new in the Fedora QA department here at RH, my job is to drive community involvement in Fedora QA. I came over from Mandriva where I was the community manager. I'll be working from my home in Vancouver, Canada. I'm new on the list so this may have come up before, in which case apologies :). Something I thought would be nice to have for QA community is a public calendar system where dates of events like test days can be published. Obviously it's silly for me personally or the QA team to take on the job of hosting a calendar server, but it was suggested that it would be a good project for the infrastructure team, and other groups within Fedora could probably benefit from it. Does it sound like a good idea? Anyone want to have a go? Or is there something already, that I don't know about? Thanks! I've not seen anything in this thread yet, so it may have been mentioned before; MediaWiki has a couple of calendering plugins that will allow days to be allocated; I looked into this for our meeting schedule but since none of them include any times for appointments I found it to be useless. Nonetheless, it could be worthwhile for allocating Test days and Events -and things of the sort. Kind regards, Jeroen van Meeuwen -kanarip I think the point I'm continuing to make is that it should support caldav or something similar. The protocol defines a protocol, so the client applications themselves shouldn't matter, but we do need to have a way to communicate with the calendar server. My intention isn't to discount MediaWiki or Zikula as a possible platform for a calendaring client, but to say that the features you suggest are not what we're after here. Instead I'd say that those two applications could push/pull data from the calendar server (using caldav). The events listed in the caldav server can be manipulated by these other applications and probably through an API which could include Access Control Lists based upon FAS rights. I can see this being a bit of an undertaking, but it can really benefit the Fedora Project as a whole. As I stated in my previous email, I've got a draft up of all the features we'd like to see (it's pretty empty right now) and I'll probably go ahead and list some of this email there. But for those of you who are interested in helping me get that wiki page more complete, feel free to visit: https://fedoraproject.org/wiki/User:Herlo/Fedora_Calendar_Project_Desired_Features_(Draft) Keep the thoughts coming, I want to see this project succeed! Dude, I'm sorry I even brought it up. Good luck! -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: get Fedora puppet modules
Mike McGrath wrote: On Thu, 5 Feb 2009, Fabrizio Buratta wrote: Hi all! Is it possible to get the fedora infrastructure puppet modules? If so, how to get them? We don't currently publish them but we have plans to. If you're interested in specific modules let me know and I can make sure to get them to you. The main issue is ensuring they're properly sanatized. We used to store passwords in configs and manifests way back when. Also we do some things in a messy way still, I'd hate to give people the idea that its the right way to do it :) Could the effort of cleaning them up be aligned with development on commonly available modules, such as puppetmanaged.org (potentially move/copy the git repos for each module to fedorahosted infra?). Not only would I be very happy if that happens, it'd also mean a little more involvement in development of the Fedora Infra modules from my side. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Change request
Hey,
I'd like the following patch to be applied. It fixes the redirects for
RPM-GPG-KEY files for secondary arches not to be redirected to
/pub/fedora-secondary/, so that Jigdo's can find the files.
Kind regards,
Jeroen van Meeuwen
-kanarip
commit b240e804a23e4171d21de19f0de0ec4b34586654
Author: Jeroen van Meeuwen kana...@puppet1.fedora.phx.redhat.com
Date: Tue Dec 30 01:02:00 2008 +
Fix the rewrite for secondary architectures.
The rewrite caused GPG keys in primary architecture install trees
matching the name of a secondary architecture to be rewritten to
secondary-archs.
diff --git a/configs/web/download.fedoraproject.org/rewrite.conf
b/configs/web/download.fedoraproject.org/rewrite.conf
index 63f2e45..adc7a3c 100644
--- a/configs/web/download.fedoraproject.org/rewrite.conf
+++ b/configs/web/download.fedoraproject.org/rewrite.conf
@@ -4,8 +4,8 @@ RequestHeader set CP-Location /mirrormanager
RewriteEngine On
-RewriteCond %{REQUEST_URI} ^/pub/fedora/linux/.*ia64.* [OR]
-RewriteCond %{REQUEST_URI} ^/pub/fedora/linux/.*sparc.*
+RewriteCond %{REQUEST_URI} ^/pub/fedora/linux/.*[/]+ia64.* [OR]
+RewriteCond %{REQUEST_URI} ^/pub/fedora/linux/.*[/]+sparc.*
RewriteRule ^/pub/fedora/linux/(.*) /pub/fedora-secondary/$1
RewriteRule ^/(.+)$
balancer://mirrorsCluster//mirrorlist?path=$1redirect=1 [P]
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Introduction Teb (Zikula / Documentation project)
Teb (Zikula NL) wrote: Hi all, I have just subscribed to both the fedora-infrastructure-list and the fedora-docs-list to keep you (and myself) updated about the documentation project. Hello Arjen, good to hear we have another Dutchman on board ;-) Welkom! Kind regards, Jeroen van Meeuwen -the Other Dutchman ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Automating hosted projects?
Stephen John Smoogen wrote: Fedora Unity and Cooperation KDE- Gnome might raise some eyebrows but would not be easy to auto-sanity-check. /me raises one or two eyebrows... I see we're being used as an example but I'm not sure I understand what you're saying ;-) Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Why puppet uses config instead of configs?
susmit shannigrahi wrote: Hi, In puppet when we add a new file, we use this lines in the .pp files: source = 'puppet:///config/web/applications/FreeMedia-error.html', where as the actual location of the file (FreeMedia-error.html) is [sus...@puppet1 puppet]$ find -name FreeMedia-error.html ./configs/web/applications/FreeMedia-error.html So the source in the .pp file should be 'puppet:///configs/web/applications/FreeMedia-error.html' Why this discrepancy? Just curious... The [config] fileserver mount may point to /path/to/configs/, which would allow this discrepancy to exist. If you are going to change anything, maybe consider using [files] vs. /path/to/files/ since that name for the mount appears to be most commonly used. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: func logrotate fix
Mike McGrath 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? Sounds reasonable to me, +1. -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: func logrotate fix
Jon Stanley 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. When such a thing happens, and it does, I wait for the big outage I can't recover from without changing stuff during a change freeze, and drag their sorry asses back in the conference room. First thing on the agenda of course is appending /dev/null to the condrestart of some logrotate file, not the outage. -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Stale Fedora Hosted Projects (revisited)
Toshio Kuratomi wrote: Nigel Jones wrote: On Wed, 2008-09-24 at 01:59 +0200, Jeroen van Meeuwen wrote: Nigel Jones wrote: IIRC the GPL at least requires that the code be kept for 3 years (hence why we can't clean the look-a-side cache from memory). AFAIK that only goes to /distribution/ under GPLv2 section 3b, not the upstream SCM, but then again I'm not sure and it may be worthwhile looking into the requirements of the Licenses of the software in these SCMs. Distribution is very loose in my terms. Technically by distributing the source code, we are errr acting as a distribution point. IANAL but that's my view. Perhaps. But the GPLv2 portion that has the three year clause deals with distributing binaries. Upstream SCM would be releasing source, so that doesn't apply. If the upstream on fedorahosted was releasing binary tarballs then it might be a little greyer. Although one would hope they were releasing both binary tarballs and source tarballs. Then it would fall under a different clause with no timeframe. Given that we alone can think of a couple of arguments for or against GPL distribution for 3 years or not, and there's other licenses as well, this might be more appropriately handled by the legally literate people (no offense to you, I just know I certainly am not) -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Stale Fedora Hosted Projects (revisited)
Mike McGrath wrote: Getting back to this. What should we do with code to which no one claims ownership or the owner cannot be found? Has something like an AWOL procedure been considered? -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Stale Fedora Hosted Projects (revisited)
Nigel Jones wrote: IIRC the GPL at least requires that the code be kept for 3 years (hence why we can't clean the look-a-side cache from memory). AFAIK that only goes to /distribution/ under GPLv2 section 3b, not the upstream SCM, but then again I'm not sure and it may be worthwhile looking into the requirements of the Licenses of the software in these SCMs. -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Stale Fedora Hosted Projects (revisited)
Mike McGrath wrote: For how long? Here's the concern. At some point between now and the end of time decisions are going to have to be made about these projects. I'm trying to have us learn a lesson from the elvis move as well trying to make sure other's lack of planning doesn't become Infrastructures problem. Something has to happen with bits that belong to no one, so far no one has put a time limit on any of these things. So what I was thinking is we have several processes in place in case this happens with a package, right? One can orphan a package in which case it get's removed almost instantaneously, or start AWOL for unresponsive maintainers, and (...), so maybe what we're looking for has already been thought of -it has just not been mixed up and stirred and applied to the specific case of an upstream SCM yet. -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New Key Repo Locations
Axel Thimm wrote: W/o knowing all details, why not move os to os.oldkey and use os as the new key's content? If the key is considered compromised what mirror admin would like to keep the old signed packages around anyhow? I think then the problem becomes that every existing installation points to os/ where it would need os.oldkey/ to get the packages it can check gpg keys on. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New Key Repo Locations
Jesse Keating wrote: On Fri, 2008-08-29 at 02:32 +0200, Jeroen van Meeuwen wrote: I'm not sure how that solves the net install use case, especially if mirrormanager is going to redirect to os.newkey/, as signatures used on os.newkey/ packages will not meet what the installer expects the signature to be on these files. See bug 998. Installer doesn't expect keys. Right, that one slipped my mind. I guess that addresses the concern of net installations as well. For the other part, where mirrormanager directs requests to mirrors we have ultimate control over... is this going to interfere with the local mirrors someone like myself may have set up at home and at multiple customer sites? E.g., will clients in these netblocks be redirected to mirrors the Fedora Project has ultimate control over, or am I misunderstanding what you are saying? It's only for the queries for the old location. This drives all queries for the old locations to our server so that we can get them the transition fedora-release, pk and nothing else. This invalidates the .jigdo files then, right? These query the mirrorlist for the old location and need an old RPM file (or the checksums won't match). Once they get the new fedora-release, they'll be hitting the new url, which mirror manager will do the normal thing, drive them to site local, or drive them to geo locations. As to what to do about site local mirrors for the old location, I don't think that has been fully discussed, that's probably a good item for nit-picking. I guess if queries for the old location is redirected to a mirror fp.o has ultimate control over, just to update fedora-release and pk, it would not really pose a big problem as the clients will be redirected back to their local mirrors once they get these two updates. I'm sure there's some situations that block access to mirrors other then their own local mirror, but the admins at these locations should be smart enough to rewrite the requested URL in a (transparent?) proxy (which I presume they'll have anyway). It's a lot of work for little gain. What you're downloading, the isos, and what you start using, the content from the isos, will be matching, the same. It's the updates or extra packages you install after that which will have a new key on them. Rpm doesn't currently possess a way to verify the GPG keys on installed packages, so I'm told, so those installed from isos having the old key doesn't much matter. It's the new packages one would fetch over the internet that matter. Given that one bug that slipped my mind, you're right... Not even including the updates/ and/or updates.newkey/ repository during the installation would form a problem. For the composing part, I don't see how including os.newkey/ and updates.newkey/ would form a problem (even though it might). Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New Key Repo Locations
Axel Thimm wrote: On Fri, Aug 29, 2008 at 12:54:40PM +0200, Jeroen van Meeuwen wrote: Axel Thimm wrote: W/o knowing all details, why not move os to os.oldkey and use os as the new key's content? If the key is considered compromised what mirror admin would like to keep the old signed packages around anyhow? I think then the problem becomes that every existing installation points to os/ where it would need os.oldkey/ to get the packages it can check gpg keys on. But isn't this desired behaviour? We don't actually want os.oldkey/ to be used anymore (mid-term) as we need to revoce the key in case it has been stolen. Maybe we don't need os.*key at all. E.g. if a key has been stolen, burn all signed stuff and recreate them with a new key. The problem then becomes that a fedora-release package update needs to come from the old location which is the only location a currently running client knows about, signed with the old key (which again is all the running client knows about at this point). In addition, I think they are burning everything-but-the-relevant pieces (such as a fedora-release file with an updated repo config, and the packagekit update that is able to gpg key import). Kind regards, Jeroen van Meeuwen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New Key Repo Locations
Axel Thimm wrote: If ATM the key is considered stolen, the users need to stop using the key immediately anyway. Issuing a new package signed with the old key is just keeping the racing window open. (...snip...) I agree with you for the most part, but I'll leave the risk assessment and corresponding consequential response paradigm to the ones that know best what happened and are actually in a position to decide whether or not to revoke keys and nuke content or to make it an easy transition now just to be safe rather then sorry. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: rawhide, /mnt/koji and /pub/fedora
Nigel Jones wrote: On Wed, 2008-08-27 at 21:52 -0700, Jesse Keating wrote: On Wed, 2008-08-27 at 21:44 -0700, Jesse Keating wrote: Comments? One comment just made on IRC by G: G f13: can't be allow masher to sudo to ftpsync and run a sync command? G = $me :) We would have to allow masher to sudo with no password in order to run the rsync command. I'm not sure how far we can narrow it down since the rsync source changes each day, only the dest (and other options) remain the same. Why not something like: sudo /usr/local/bin/rawhideftpsync.sh random bit that runs: rsync ...normal path.random bit ... Just a thought. You could configure sudoers to allow the masher user to only be able to execute whatever it sudo's as the ftpsync user: masher hostname.domain.tld=(ftpsync) NOPASSWD: rsync $rsync_opts foo.wildcardmatch-source bar Does that narrow it down sufficiently? Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New Key Repo Locations
Warren Togami wrote: This is the latest draft of New Key repo locations. Jesse Keating points out that the deep levels are necessary because mirrors exclude releases by directory name like 9/. Please let me know if you see any errors in the below. If 9/ is excluded, wouldn't that mean 9/$releasever/*/os.newkey is also excluded? If it's not, then I guess there's no point in the new directory being created either. Will the ISOs be respun to reflect the changes as well so that what is in os/ or in os.newkey/ meets what each of the ISO expects? I guess this is primarily relevant to respins, netinstalls and so forth, as the old RPM-GPG-KEYs will be in the root of those ISOs and I can only presume they are used, and people will want to use os.newkey/ as the tree to install from. Has creating/composing an entirely new 9.1/ release tree been considered? I guess recreating the entire release tree is a PITA (jigdo, iso, torrent, foo) even though updates would not be included other then maybe the updated fedora-release package (with the new rpm-gpg-keys and new repo configuration files)? Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New Key Repo Locations
Jesse Keating wrote: On Fri, 2008-08-29 at 01:51 +0200, Jeroen van Meeuwen wrote: If 9/ is excluded, wouldn't that mean 9/$releasever/*/os.newkey is also excluded? If it's not, then I guess there's no point in the new directory being created either. Yes, if 9 is excluded (or included) that means the admin either doesn't care about 9 and doesn't want to mirror it, or explicitly cares about it and only wants to mirror it. Either way I wish to honor those choices by not changing the top level directory where 9 or 8 will be. This also means we won't have to re-file our export approval. So, if 9/ is excluded from, say, the hourly sync a mirror does (since it only needs to be mirrored once), the os.newkey/ won't end up on the mirror, which is my primary concern. (I guess this has been answered, partly, in another reply in this thread already). Will the ISOs be respun to reflect the changes as well so that what is in os/ or in os.newkey/ meets what each of the ISO expects? I guess this is primarily relevant to respins, netinstalls and so forth, as the old RPM-GPG-KEYs will be in the root of those ISOs and I can only presume they are used, and people will want to use os.newkey/ as the tree to install from. At this time, the isos will not be respun. We will however re-sign the SHA1SUM file with the new gpg key. We are certain that the content on the ISOs (and the numerous hard copies floating about) are safe. The only content to be left in the repos these isos will be able to access out of the box will be the transition fedora-update release, and the fixed packagekit for gpg importing. We'll also have mirrormanager direct all requests for the old dir directly to mirrors which we have ultimate control over. I'm not sure how that solves the net install use case, especially if mirrormanager is going to redirect to os.newkey/, as signatures used on os.newkey/ packages will not meet what the installer expects the signature to be on these files. For the other part, where mirrormanager directs requests to mirrors we have ultimate control over... is this going to interfere with the local mirrors someone like myself may have set up at home and at multiple customer sites? E.g., will clients in these netblocks be redirected to mirrors the Fedora Project has ultimate control over, or am I misunderstanding what you are saying? Has creating/composing an entirely new 9.1/ release tree been considered? I guess recreating the entire release tree is a PITA (jigdo, iso, torrent, foo) even though updates would not be included other then maybe the updated fedora-release package (with the new rpm-gpg-keys and new repo configuration files)? It was considered briefly, but not very much. Calling something 9.1 would also have a bit of an assumption that we've fixed some bugs or otherwise made it a better release, which we aren't doing. We're merely re-signing content and placing it in a slightly different directory, but it's still 9, not 9+something. (ditto 8) This sounds to me like a not-really-technical argument. You're right in that the naming in releases/X.Y does imply a new and improved install tree. I think there's some other serious consequences to choosing to do it in the original X/ release tree though. I'm thinking, who gives a c* that there's not actually 'new and improved' content in the trees even though the naming suggests that there is, while it does carry an entirely new tree with ISOs and jigdo's and stuff that have the new signed content and make a full match between what you download and what you start using, like with a normal release. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Test servers
Mike McGrath wrote: So we're in kind of an awkward but probably beneficial spot right now for our test server infrastructure. Its _ALL_ down right now. And we need to build it back up. We've talked about another layer of test servers and I think its probably time for that so here's what I propose. Rebuild our test servers external to PHX. There is an open ticket for this already, we're just going to be doing it finally. Create a staging environment in the publictest and test areas in PHX. Staging will be identical to our production environment where possible with the exception of production data and where new features are being implemented and are not in production yet. Staging will be in puppet. All of it. Just like production is and they'll get rebuilt regularly. We can use puppet's environments to do this but I'm going to talk with kanarip about implementation and such. We actually have a very basic testing environment setup in puppet now but its not really tested or documented yet. Staging will be different. So, a few things on staging environments: Puppet can stage the following things: - the manifest to use (e.g. site.pp) for an environment, including all imported files (e.g. classes/*.pp etc) - the modulepath to use This means that you can split into environments what you use from the modules in those environments, but not what is in configs/ right now. For what is in configs/ to become staged, it needs to go into modules. Preferably, we would stage using git branches (development - testing - production, for example). A simple plan without too many details: - What we have right now becomes the production branch (configs/ can stay where it is) - We branch off to development (and testing if desirable), and start moving configs/ content into the modules for as far as these are related to the modules (e.g. templates, new files, but not simple files). - Changes go into the development branch first, then are pulled into / pushed to production. Any other thoughts? Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: DNS serial number
Mike McGrath wrote: Should the first serial number for a day be 00 or 01? EX: 2008081001 or 2008081000 Common practice is 01, along with (usually) appending your (account) name to the '; serial (mmcgrath)' in case you want other people with the same amount of control over the zone to be able to track down who made the last change. -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Puppet and modules
Bryan Kearney wrote: Just to make sure you have seen these resources: Existing Modules http://reductivelabs.com/trac/puppet/wiki/CompleteConfiguration http://reductivelabs.com/trac/puppet/wiki/Lab42Infrastructure Proposed Standards: http://reductivelabs.com/trac/puppet/wiki/ModuleStandards http://reductivelabs.com/trac/puppet/wiki/ModuleDocumentationStandards Also Genome and Thincrust are using alot of puppet, and may have some modules to use http://genome.et.redhat.com/ http://www.thincrust.net Additionally, there is some on http://git.puppetmanaged.org/ Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: fedorahosted git repo too large
Nigel Jones wrote: On Tue, 2008-08-05 at 23:44 -0400, Todd Zullinger wrote: Yuan Yijun wrote: I just tried to download revisor git with this command git pull http://git.fedorahosted.org/git/revisor master. I have to repeat 4-5 times since it breaks during downloading. The .git folder is about 58MB. After git gc --aggressive it becomes only 6MB. Anyone please run gc on server? Perhaps better would be repack. There was a recent thread on the git list and one of the developers pointed out an older mail from Linus where he described gc --aggressive as mostly dumb and recommended that using something like repack -a -d -f --depth=250 --window=250 instead. http://article.gmane.org/gmane.comp.gcc.devel/94613 That's actually a very useful article and the methods/reasons behind it sound quite sane and it could be a useful approach for us. I'll try this out on one of the smaller repos (a copy of course) and see what happens. We've ended up doing this live as well and I'm happy with the few stabs I took at seeing if everything still works. Feel free to make this a regular thing on the revisor repo and I'll report if anything breaks, so that if it doesn't, this could maybe become a regular thing to do on all repos? Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: bash $TMOUT
Mike McGrath wrote: Trying to prevent stuff like this: XXX pts/7XXX 06Jul08 10:11 0.06s 0.10s sshd: XXX [priv] ^^^ holy moly :) holy alright -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Fwd: Re: Announcing the Fedora EDU Spin Preview]
Jeffrey Ollie wrote: 2008/7/11 Paul W. Frields [EMAIL PROTECTED]: Anyone have insight into this? The issue is that something in postfix on collab1 (where the lists.fedoraproject.org mailing lists run) and/or bastion (which serves as a central mail gateway) is rewriting mailinglist@lists.fedoraproject.org addresses in the message headers to mailinglist@fedoraproject.org. When someone then tries to reply to a mailing list post the message is bounced as mailinglist@fedoraproject.org is an invalid address. I don't have enough postfix-fu to fix the problem and no one with enough postfix-fu has had the time, access, and/or interest in fixing the problem. Until this problem is fixed I've been hesitant to create any (more) lists.fedoraproject.org mailing lists. lists.fedorahosted.org has a similar problem, except that mailinglist@fedorahosted.org works due to some quirks of how postfix interprets email addresses (AFAIK without a some hackery postfix can't treat @lists.domain differently from @domain). Has anyone checked the masquerade domains and masquerade domains except settings or their postfix equivalents? Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: puppet and git
Mike McGrath wrote: So. We've been doing puppet wrong. Not really wrong but there's a better way now using modules. more info: http://reductivelabs.com/trac/puppet/wiki/PuppetModules Long story short, I (and probably kanarip if I can sucker him into it :) will start converting some stuff that we've got to the more module format. Some benefits: * Easier to share with others * Much better organization / easier to find stuff * The standard actually involves writing a README file per module. Thats a good thing and can help explain some things better. Before we go making a bunch of changes I'm going to make sure to keep everyone in the loop with whats going on. One thing I did want to discuss is that puppet does have some native support for git now and people are using it. I have to say I'm on the fence about it. Fedora as an organization is moving more to git, the websites team already uses it. What are the thoughts on this list? The GIT support isn't actually native (and neither is the support for any other of the SCM's), and I haven't been able to clone the git module for a couple of months now. Another GIT module (in the works) is at: http://git.puppetmanaged.org/?p=modules/git/.git;a=summary (and I hope you like it). There's other more Fedora specific modules as well (like a better puppet module then the one listed on puppet's wiki, or so I'd like to think) because it manages more of puppet, and allows $domain's to override what the module ships (in files and manifests). I'd like to work on the puppet configuration for Fedora Project as well (but you know that), as soon as I get back from my holiday. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [Fwd: Brief Comment: Delete user feature]
Ignacio Vazquez-Abrams wrote: For your consideration. FWIW, I have the same; while showing someone how easy it was to register, I created kanarip2, not realizing that there was no delete or expire account button anywhere. It would be nice to have some procedure to go about deleting these dummy user accounts which will most probably never turn active. -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Change Request: Setup Awstats for download.fp.o (and fix the torrent.fp.o one)
Mike McGrath wrote: On Sun, 4 May 2008, Ricky Zhou wrote: On 2008-05-04 04:13:01 PM, Matt Domsch wrote: I set up awstats a few weeks ago to handle mirrors.fp.o, and as the same proxies handle download.fp.o (and they really are the same content in the end), I made the awstats config just parse both then too (pre-change-freeze). http://fedoraproject.org/awstats/mirrors/awstats.mirrors.fedoraproject.org.html includes both mirrors.fp.o and download.fp.o. Oh, cool - that's perfect, then - thanks. We'll just want to fix the torrent one some time after the freeze, then. Side note about all this... I like awstats and all but I was wondering what other _OSS_ solutions people are using where they are? Just seems like awstats has... kind of been the same for years... I've been using webalizer for as long as I can remember... Impressive huh? ;-) Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: How much downtime do we afford for nagios?
Nigel Jones wrote: Looking through my email, from what I can recall there are no false positives. xen6 had to be power-cycled which caused all the other collateral notifications. Collateral notifications can be caught using service dependencies and parent hosts. Do we currently use any? Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: sub-optimal torrent for F9 Snapshot 1
John Poelstra wrote: I'm finding trying to get Friday's snapshot of Fedora 9 to be very sub-optimal... 62 hours estimated to go after already timing out once. I've got two peers and one seed :( I'll probably get it by time the next snapshot is ready :) Is this happening to others? Not happening here, I'm adding another seed to the swarm - I see it's already uploading more then it's downloading, while it is still downloading. Is this really a viable way to put out *weekly* snapshots? No. ;-) Is hosting jigdo templates a possibility? In my situation it would work well because I mirror the rawhide trees locally--yes I realize this begs the question of why I need the snapshot if I already mirror rawhide, but I'm curious if it fails to install for me just as rawhide has for the past three days. The snapshots (torrent ISO images) should have an updates.img which should make them installable. Jigdo is a possibility in distributing the snapshots, but the downside is that at least one party, and preferably more then one, will need to keep hosting the slices; while on day 0 all slices are (or should be) in rawhide, on day 1 some packages might have been updated again and are thus not available anymore -unless some party keeps hosting the entire tree such as Fedora Unity does with their Re-Spins; 4 mirrors keep hosting all slices that come from the updates/ repository for as long as the Re-Spin is offered for downloading. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Metalink support
Bram Neijt wrote: So would I, but for what I've seen the SHA1 information is not part of the mirrormanager database. For any good implementation of metalinks in the mirrormanager, I would at least want trustworthy SHA1 information in the database otherwise the only advantage of using metalinks would be load balancing on your mirrors (which is already mostly fixed with MM). So for the end user, there is not much to gain if metalinks is implemented in the mirrormanager. The only solution for the SHA1 information I could think of was to implement a script on the main mirror which hosts the SHA1 files, which would mean not running on the server with the MM database, which would mean not having direct access to that database. Parsing HTML is pretty stupid, I agree, but there is probably a much cleaner way of getting the mirror list (I havn't worked with turbo gears before, so I couldn't find a view of the list I would want). Something like fedora-test-data/mirror-hosts-core.txt would be much better. Rene is still working on the MM patch, but without the SHA1 information, I'm not really sure it would be _my_ ideal solution. Greets, Bram How about using: http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/releases/8/Fedora/i386/iso/Fedora-8-i386-DVD.iso instead of the HTML? Incorporating that in the .metalink, trusting Mirrormanager with managing whether that file is actually the file that is supposed to be there, and the metalink client doing a check-up on the chunks it has downloads and see if they match? Creating a metalink would then consist of: - getting the iso - verifying the sha1sum (so you don't start off on the wrong foot) - creating chunks and their sha1sum for use in a .metalink file - while/before the .metalink is being downloaded by a client, incorporate the mirrormanager results and trust mirrormanager to return the 1) right mirrors, 2) the right files, 3) the files with correct content. - optionally allow the .metalink to be created on-the-fly with all parameters mirrormanager has (country=NL,DE,BE, but not redirect=1) Does that sound like a good idea? Just my brain dump ;p Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: xen1 outage
Maybe because Fedora is also a moving target. Kind regards, Jeroen van Meeuwen -kanarip Itamar - IspBrasil wrote: why these machines can't run fedora 8 ? fedora 8 have new xen version, and new xen kernels. Mike McGrath wrote: On Wed, 9 Jan 2008, Mike McGrath wrote: FYI all we're working on xen1's issues. They seem to be iscsi related but its still not quite clear. Basically the last thing we see in the logs is an issue with iscsi, then the box reboots. We're seeing similar log issues around the same time on our other boxes... but they don't reboot. See: https://fedorahosted.org/fedora-infrastructure/ticket/334 xen2 has started doing this too, having recently upgraded to RHEL5 it is a likely suspect as both xen1 and 2 are now on RHEL5. I've updated the ticket for more info: https://fedorahosted.org/fedora-infrastructure/ticket/334#comment:5 Right now xen2 is basically downgraded to FC6 as far as kernel and xen libs are concerned. we'll see if that helps. I'll be testing the fixes suggested on xen1 in the coming week. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Jigdo - A Professional Letter to Mike McGrath
Jesse Keating wrote: On Tue, 11 Dec 2007 00:41:24 +0100 Jeroen van Meeuwen [EMAIL PROTECTED] wrote: We on the other hand have hundreds -if not thousands- of users download the CD version of Fedora 7 and Fedora 8 while supposedly they are in possession of the DVD images already. What makes you say that? When I poked at fedoraunity.org the only download option I saw was jigdo, so how are you determining that these people are using jigdo by choice rather than by necessity? I don't think I said anything about those users /choosing/ to use Jigdo, but if I was likely to be misunderstood in that aspect I apologize. Talking about necessity though, users interested in the Fedora 9 Everything Spin would need to use Jigdo as it is the only way anyone offers it (officially). Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Jigdo - A Professional Letter to Mike McGrath
Michael DeHaan wrote: Jeroen van Meeuwen wrote: Mike McGrath wrote: and we were going to judge jigdo a success if a certain % (compared to bittorrent) use jigdo. What % would that be? Jigdo would in this case be particularly useful to those with a local mirror as they have 99% of the content already (90% if you have F9T3?). Because it is particularly useful to some, and completely weird and strange for others, the number of users that will use it if BitTorrent is an alternative wouldn't be a very good indicator to see if it is actually a viable distribution method for the whole of Fedora, neither is it the goal for these proposals. I'm talking specifically about people going to the get-fedora page and clicking on the torrent link vs the jigdo link. Out of every 100 people, how many people will click on the jigdo link? Given the choice to download, say, the Fedora 9 i386 vanilla DVD, frankly, I expect only people that know Jigdo, or want to get to know Jigdo as it may have some benefits for them, and want to use it, are going to use it, so in all my optimism: roughly 10 out of a 100. I would venture less. As a former Debian user (and knowing other Debian users), our favorite install system was always the ~100 MB net install image, which we can do for Fedora already (though it's not 100 MB) Assuming you do have a network connection, like the example above; What would you want to do if there's no Jigdo, but you do have the Fedora 9 DVD, and you want/need the CD version too? Download another ~4GB of ISO images? How about off-line? It's fairly simple to create the Jigdo files and host them. Let's try it and get the real numbers, then decide if it's valuable enough for all of us to continue distributing installation media with. Spins are perhaps interesting for users that don't do minimal net-installs, and don't want to build their system with yum later, but jigdo is something that advanced users would use. They seem to be two different groups. Jigdo did not seem to be very popular among anyone I talked to once they figured out the minimal install images were available. We on the other hand have hundreds -if not thousands- of users download the CD version of Fedora 7 and Fedora 8 while supposedly they are in possession of the DVD images already. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Jigdo - A Professional Letter to Mike McGrath
Mike McGrath wrote: and we were going to judge jigdo a success if a certain % (compared to bittorrent) use jigdo. What % would that be? Jigdo would in this case be particularly useful to those with a local mirror as they have 99% of the content already (90% if you have F9T3?). Because it is particularly useful to some, and completely weird and strange for others, the number of users that will use it if BitTorrent is an alternative wouldn't be a very good indicator to see if it is actually a viable distribution method for the whole of Fedora, neither is it the goal for these proposals. I'm talking specifically about people going to the get-fedora page and clicking on the torrent link vs the jigdo link. Out of every 100 people, how many people will click on the jigdo link? Given the choice to download, say, the Fedora 9 i386 vanilla DVD, frankly, I expect only people that know Jigdo, or want to get to know Jigdo as it may have some benefits for them, and want to use it, are going to use it, so in all my optimism: roughly 10 out of a 100. For other spins without regular bittorrent seeds obviously the rate is 100%, and some of the people that get to know Jigdo that way will be using it again for our respins, and if possible, again for other spins (non-Everything?), and again, and again. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Jigdo - A Professional Letter to Mike McGrath
Till Maas wrote: On Do Dezember 6 2007, Jonathan Steffan wrote: The current updates system is getting better each release, but I think we should adjust our policies to also have an “updates-archive� repository. This repository will include all signed updates that had once lived in the updates repo, for the duration of the releases life-cycle. I don't expect all mirrors would want to carry this extra Once the repositories are presto enabled, an updates-archive with all the delta rpms would not take as much space as a full rpm repository but provide the same functionality. If in some way a mirror can regenerate a full, original RPM from all delta RPMs, so that Jigdo can use it as a slice, a combination of the two would be possible. Without that ability, all Jigdo recognizes is full RPMs on the ISO image (slices), against no (zero) matches in the updates-archive/ folder (all partial slices). -Jeroen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: UnicodeEncodeError is back
Jesse Keating wrote: On Sat, 10 Nov 2007 18:36:29 -0800 Thomas Chung [EMAIL PROTECTED] wrote: On 11/10/07, Thomas Chung [EMAIL PROTECTED] wrote: Hello, I'm getting UnicodeEncodeError message on following page: http://fedoraproject.org/wiki/Artwork/CDArt It's been 6 hours since I reported. FYI, here is the SOP for this issue. http://fedoraproject.org/wiki/Infrastructure/SOP/wiki#UnicodeEncodeError Regards, -- Sorry for the delay, I think I have it all cleaned up. Let me know if you run across more pages with errors. http://fedoraproject.org/wiki/PackageMaintainers/Policy had been reported by 'blarney' to have the same error. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: UnicodeEncodeError is back
Jesse Keating wrote: On Sun, 11 Nov 2007 15:12:24 +0100 Jeroen van Meeuwen [EMAIL PROTECTED] wrote: http://fedoraproject.org/wiki/PackageMaintainers/Policy had been reported by 'blarney' to have the same error. Which I fixed at the same time, as you would know if you actually checked it after I sent my message. I'm sorry to have troubled you; I'm now getting the UnicodeError on http://fedoraproject.org/wiki/Features/JigdoRelease Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: mirrormanager future features
Matt Domsch wrote: MirrorManager, for what I really wanted to see by the Fedora 7 release, has been a success. You're right, it is! I've set up this preferred netblock and any of the roaming clients in my home network can just use stock fedora-*repo configuration (as can my servers but they use static configuration anyway) ;-) Anything else people really need to see? Is there a way to 'query' the mirrorlist and telling it explicitly to not use any preferred netblock? Could we possible filter by protocol (http/ftp, rsync)? I'm not sure this one is still current, but formerly I had to move around directories because some mirror I was syncing from did not use the exact same full tree the master mirror was; if it is still current, could that be flagged and filtered on-request by mirror-manager? Thanks, Matt Thank you! -- Kind regards, Jeroen van Meeuwen -kanarip -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Puppet Training!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Toshio Kuratomi wrote: Mike McGrath wrote: Please let me know which of these times work best for you: Monday August 27th at 15:00 UTC Monday August 27th at 20:00 UTC Wednesday August 29th at 20:00 UTC Right now I'm scheduling it for the 27th at 20:00 UTC unless people can't make that time. Aug 27th at 20:00 UTC works well for me as well. +1 Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGzdyWKN6f2pNCvwgRAo2BAKC1aTXqUdQJkkFg0QabsHMvfZ67wgCgqqTC iNWGbsYnjIRS05zt1mWrl94= =q9Yp -END PGP SIGNATURE- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Fedora 8 Target
Mike McGrath wrote: Rahul Sundaram wrote: Mike McGrath wrote: Fedora 8 Test 1 is on its way out the door and I thought I'd take this time to list all of the outstanding issues we need to get implemented for F8: https://hosted.fedoraproject.org/projects/fedora-infrastructure/query?status=newstatus=assignedstatus=reopenedmilestone=Fedora+8 Most of these processes are owned. If you are the owner and can't work on it or don't want to for whatever reason, please switch it back to nobody. For those of you interested in helping one of these tasks, please add yourself to the cc and make a note. Is Jidgo integration a planned feature for Fedora 8? As you might be aware, Fedora News team has started a new column called Ask Fedora and someone was asking about CD sets (or lack of them) in Fedora 7 and I wanted to know whether suggesting they help out the infrastructure team in this aspect was the right way to go. AFAIK, no. Who's the Jidgo integration project lead? -Mike There's a bugzilla ticket assigned to Jesse: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245601 Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Python, VCSs, ssh keys and Transifex
Dimitris Glezos wrote: O/H Karsten Wade έγραψε: On Sat, 2007-07-14 at 00:55 +0200, Jeroen van Meeuwen wrote: Mike McGrath wrote: This is my worry too. It's almost enough to make me not want to do it for non Fedora projects but thats just bad. I'm hoping someone here has a good, clever way to solve this issue. The benefits of these new tools far outweigh the relatively slight risks. We really must step up and find a way to make it work. My vote is simple: we do the best we can, we spell out what the security is and the risks involved, and we put that in front of upstream projects. We ask them to agree (via email?) to the risk/reward balance we present. [...] Security risk assessment is never about, No matter the cost, I will secure this until it is unbreakable. That guarantee comes from a pair of wire cutters used on the CAT(5) between the server and the switch. Great for security, bad for business. [...] Along these thoughts and Dimitris', having a transifexd running under User A to collect to translations, and another User B to do the actual commits and pushes with, seems to be the best design. SELinux protection of course, is mandatory, although it doesn't prevent a compromised transifexd from putting 'malicious' file in User B's commit/push queue. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Python, VCSs, ssh keys and Transifex
Dimitris Glezos wrote: Hi all. There is a darkish cloud of security uncertainty in my sky (and Fedora's!), so it's better to discuss this as early as possible to avoid any late notices. I'm working on a web app that will help translation submission by allowing fedora translators (members of cvsl10n group) to commit translations to systems they don't have direct access to. Think: hosted.fpo (svn/hg/git). https://hosted.fedoraproject.org/projects/transifex The idea is that transifex will act as a proxy/mediator for translation commits. A translator will login to the transifex instance running on a host like `translate.fpo`, choose a module, a PO file to upload, and a destination file and click submit. The system will commit the file for him. Underneath this is achieved by having the VCS admin create a user (eg. fedora-transifex) with a dedicated SSH key, and give it write access to the specific modules accepting translations. The transifex admin will then hook the repo and module up with the system. Each commit will be done by the fedora-transifex user, and the actual user's details (name, surname, email, fedora username) will be written in the commit message and Changelog file. Transifex supports filaname filters, so even if a module maintainer can't add ACLs to the repo, he can define them on the transifex side; for example, .*/po/(LINGUAS|Changelog|.*po$). To put things in perspective, if we do this *right*, then *any* remote VCS could be hooked up. In the future, we could add a layer of approval before commits, so that the language maintainer (which we probably trust more than a john doe user with cvsl10n access) approves queued messages to be pushed. Or, we could give the option to a dev (for DVCS) to pull instead of the webapp to push. To the implementation details now, transifex will become the client to the remote VCSs. Once the user clicks submit PO, the webapp should commit (and push). The security question is how do we handle SSH keys? - Where do we store them? Best place would be ~/.ssh/, because not all VCS commands support SSH options to point to a different config file. - Right before running the checkout/pull and checkin/push commands, the environment should be right so that the commands run by the webapp will succeed over SSH. So an option the webapp (just like anyone) will have to type the passphrase to unlock the key. Or, use ssh-agent. And probably SELinux. What's the best approach with the minimum compromise risk? Well, storing keys, key-pairs or their passwords no matter crypted or salted, under the same user account that runs your webinterface generally is a bad idea. (In fact, storing passwords in general is a bad idea, no matter where they live). Then again, you could have passwordless SSH private and public key pairs, but you wouldn't want those usable by the account that has your web interface running either. A possible solution might be though, to have Transifex store the submitted PO's in /some/path/transifex, and then have another user account lift it's files and metadata, commit it to the pulled source repository (signed with GPG), and then push it upstream (with SSH priv/pub keys). Storing those passwords (plaintext or decryptable) would make just as much sense to me as allowing empty passwords to use these keys, but at least you prevent the webinterface from ever reaching those keys or files. I bet there's some thoughts on this ;-) Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Trac Instance
Jeff Sheltren wrote: On Jul 3, 2007, at 6:33 PM, Jeroen van Meeuwen wrote: If you start with having tickets assigned to certain milestones, and then add a milestone to move some tickets to, or remove a milestone (long story short: IMACD milestones), there's no easy way of moving tickets to or from that milestone, you need to modify them by hand. In our case, not having set too much different milestones but moving as fast as we do, we have to delete and add milestones every now and then and change the default milestone for new tickets, just because our roadmap changes. Changing existing tickets already linked to a milestone is a PITA. Just my 2 euro cents, Have you checked out the BatchModify plugin? It looks like it was made to do exactly this. Oooh, nice. Shame on me for not having consulted insert-your-favorite-search-engine-here Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
public mirror list 404
A heads up for anyone not online in the IRC channel, but able to maybe fix things or wake up someone: * [H]omer ([EMAIL PROTECTED]) has joined #fedora-admin [H]omer Hi [H]omer http://mirrors.fedoraproject.org/publiclist is showing a 404! [H]omer Did you guys know about this? kanarip nope i guess we didn't And indeed it does show up 404's from where I'm sitting, too. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Fedora Magazine RFR
Anand Capur wrote: Anand Wrote: eGroupware (which I will package for Fedora if needed). * Web Server: Apache 2.2.4 * PHP 5.2.2 * Database Server: MySQL 5.0.41 * Mail Server: Postfix * DNS Server: BIND9 (chrooted) * FTP Server: pureftpd * POP3/IMAP server: Dovecot * Webalizer for web site statistics I found egroupware packaged for fedora core 5/6 already. The link was on the egroupware site. http://software.opensuse.org/download/server:/eGroupWare/Fedora_Extras_6/noarch/ Ouch. If it's not in our repositories, it isn't properly packaged, or no-one ever took ownership and just dumped that package in. IMHO, that package is just like this one package I have: This-will-burn-your-machine-1.0.1-4.fc7.noarch.rpm Nonetheless, the package can save you a lot of work since you would only need to adjust the spec file and maybe build some patches to match the packaging guidelines and pass review, right? Kind regards, Jeroen van Meeuwen ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Fedora Magazine RFR
Anand Capur wrote: I understand, it will be for my egroupware installation, and maby joomla cms if needed. The good thing is both are quite secure when installed properly. Here is the reccomended config for egroupware. (It printed this on my home comp). And yes we need a completely separate domain. eGroupware and joomla have not been packaged for Fedora, have they? Just my € 0,02 Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Fedora Magazine RFR
Anand Capur wrote: So is our wiki packaged in fedora? Is our account system packaged in fedora? It's kinda difficult to see what you are replying to every time you delete the previous message from your reply... Both mediawiki (simple) and moinmoin (fedoraproject.org) are packaged for Fedora. What components make up our complete account system, I don't know. Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: smolt and bug reports
Jesse Keating wrote: On Friday 08 June 2007 17:53:55 Rahul Sundaram wrote: https://hosted.fedoraproject.org/projects/revisor/newticket https://hosted.fedoraproject.org/projects/LHCP/newticket https://hosted.fedoraproject.org/projects/mirrormanager/newticket https://hosted.fedoraproject.org/projects/mock/newticket https://hosted.fedoraproject.org/projects/presto/newticket https://hosted.fedoraproject.org/projects/readahead/newticket https://hosted.fedoraproject.org/projects/revisor/newticket https://hosted.fedoraproject.org/projects/setroubleshoot/newticket These should all be blocked now. So let me get this straight. We (kinda upstream) should have users log bugs in bugzilla, although we are using the hosted.fp.org ticketing system for the work we do? How do we get bugzilla tickets into Trac? Manually? Kind regards, Jeroen van Meeuwen -kanarip ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Set Reply-to Header for mailing list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keyword here is to use 'Reply All', and let the receiving party figure out whether he/she wants to receive duplicate messages. mailman allows the user to configure whether to check if the user is in both the members list as well as the TO_ headers, and prevent sending the message more then once. And yes, modifying the Reply-to: header is a mailman option, and applies to every message sent to the m-l. Kind regards, Jeroen van Meeuwen - -kanarip Ray Van Dolson wrote: On Tue, Apr 17, 2007 at 01:58:48PM -0400, Wilmer Jaramillo M. wrote: Hi, I have a suggestion, because don't is set the Reply-to header for fedora-infrastructure-list@redhat.com on mailing list?. When I answer a mail, only one _should_ receive the mail, but all of the internal list possibly does not, should use the header to redirect replies to messages into to mailing list. Likely a Mailman config option. Don't know if it's a side-wide default for all of RH's lists or not. If you use mutt, you can always use 'L' to do a list-only reply. :) Ray ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGJRS+KN6f2pNCvwgRAmUjAKDVMjDojPcOMM5oEB+DNymRSj2pkACdEz1c +wepvALf4gX9Aln2/nq3qpc= =UrF8 -END PGP SIGNATURE- ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
