Re: rawhide, /mnt/koji and /pub/fedora
On Fri, 2008-08-29 at 02:25 -0400, Jon Masters wrote: > Now I'm no Fedora sysadmin (and the infrastructure doesn't appear to be > publicly documented anywhere - beyond the basics) so it's likely that > the mounts in question simply don't do ACLs right or you'd have already > discussed it...but for the sake of mentioning it, you could just add an > additional ACL onto the /pub/fedora directory writeable by master. s/master/masher/ (too used to typing "Masters" when I start typing those letters) Jon. ___ 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
On Wed, 2008-08-27 at 21:44 -0700, Jesse Keating wrote: > We have another user, 'ftpsync' that has write access > to /pub/fedora/. Previously the rawhide script was ran as root, and > thus it was no problem to su ftpsync for the rsync calls. The masher > user does not possess the capability of doing this. Now I'm no Fedora sysadmin (and the infrastructure doesn't appear to be publicly documented anywhere - beyond the basics) so it's likely that the mounts in question simply don't do ACLs right or you'd have already discussed it...but for the sake of mentioning it, you could just add an additional ACL onto the /pub/fedora directory writeable by master. Jon. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New Key Repo Locations
Jeroen van Meeuwen wrote: 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. You misunderstand the New Key plan. Mirrormanager for the existing repos fedora, updates and updates-testing will not redirect to the new location. Please read the plan again carefully. Warren Togami [EMAIL PROTECTED] ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New Key Repo Locations
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. > 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. 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. > > >> 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. 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. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ 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: New Key Repo Locations
On Thu, 2008-08-28 at 20:12 -0400, Jon Stanley wrote: > Sorry for the top post, I'm on my crackberry. We need to male sure to > CLEARLY communicate this to mirror admins. I'm sure that more than 1 > excludes releases/9/ since it is considered to be static content after > release in order to reduce the number of files for rsync to consider. Yes, of course, this wouldn't be a silent change. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New Key Repo Locations
Sorry for the top post, I'm on my crackberry. We need to male sure to CLEARLY communicate this to mirror admins. I'm sure that more than 1 excludes releases/9/ since it is considered to be static content after release in order to reduce the number of files for rsync to consider. On 8/28/08, Jesse Keating <[EMAIL PROTECTED]> 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. > >> >> 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. > >> >> 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) > > -- > Jesse Keating > Fedora -- Freedom² is a feature! > identi.ca: http://identi.ca/jkeating > -- Sent from Gmail for mobile | mobile.google.com Jon Stanley Fedora Bug Wrangler [EMAIL PROTECTED] ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New Key Repo Locations
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. > > 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. > > 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) -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ 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: rawhide, /mnt/koji and /pub/fedora
On Thu, 2008-08-28 at 18:38 +0200, Till Maas wrote: > /bin/mail -s SUBJECT [EMAIL PROTECTED] -- -f [EMAIL PROTECTED] -F > "freeform from > part" Ah, that was the missing part. Thanks. I've tossed in git, will tag it once the current run is done. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
publictest15
Publictest15 is up and ready. If you were using publictest10, start getting your stuff set back up on publictest15. If you need things restored create a ticket and let us know what and why. Remember, the pt servers don't get backed up, you should never be storing info there where it is the only place that info exists. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: New Key Repo Locations
> On Thu, 2008-08-28 at 16:31 -0400, 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. Also, "newkey" is literal. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
New Key Repo Locations
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. Release Before (no yum repo file) http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Fedora/$basearch/os/ Release After (no yum repo file) http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Fedora/$basearch/os.newkey/ fedora http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/ fedora-newkey http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/os.newkey/ fedora-debuginfo http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug/ fedora-debuginfo-newkey http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug.newkey/ fedora-source http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/source/SRPMS/ fedora-source-newkey http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/source/SRPMS.newkey/ updates http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch/ updates-newkey http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch.newkey/ updates-debuginfo http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch/debug/ updates-debuginfo-newkey http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch.newkey/debug/ updates-source http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/SRPMS/ updates-source-newkey http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/SRPMS.newkey/ updates-testing http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch/ updates-testing-newkey http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch.newkey/ updates-testing-debuginfo http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch/debug/ updates-testing-debuginfo-newkey http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/$basearch.newkey/debug/ updates-testing-source http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/SRPMS/ updates-testing-source-newkey http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$releasever/SRPMS.newkey/ ___ 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
On Thu, 2008-08-28 at 14:58 -0500, Mike McGrath wrote: > > Is changing the user that owns the files going to cause unnecessary rsync > > churn for mirrors? > > > > Only if we change the uid of ftpsync. If we change the uid of masher > we're good on the mirrors. I went the sudo route. I was able to narrow the command down considerably for safety. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Introductions
2008/8/28 Mike <[EMAIL PROTECTED]>: > Toshio, > > I am most definitely interested, I will jump on IRC as soon as I can find a > hole in the firewall at work, Otherwise I will be on when I get back home. > I am in US Central Time. if I can find a hole before the meeting I will > attend. > > if possible can you shoot me an email with a cli project so I can get a jump > on it. > > Mike, You might take a look at http://www.mibbit.com. It's a web interface to IRC. Frank ___ 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
On Thu, 28 Aug 2008, Bill Nottingham wrote: > Jesse Keating ([EMAIL PROTECTED]) said: > > So I realized something last night. We created a user "masher" to have > > the ability to write to /mnt/koji/mash/ but not any of the other koji > > space. This is useful to prevent too much damage from a horribly wrong > > rawhide compose. To make things easier in the rawhide compose configs, > > we decided to run the cron/scripts as the masher user. This is also > > good because it means things run unprivileged. However I ran into a > > snag. We have another user, 'ftpsync' that has write access > > to /pub/fedora/. Previously the rawhide script was ran as root, and > > thus it was no problem to su ftpsync for the rsync calls. The masher > > user does not possess the capability of doing this. > > > > Since the ftpsync user is only really used to sync data onto the Fedora > > netapp, I propose that we collapse ftpsync and masher into one user > > (masher). It'll require minimal puppet changes, mostly just moving some > > cron jobs from ftpsync over to masher. It will require UID changes, > > either changing masher to the ftpsync UID (which breaks our new range we > > just setup), or chmodding some stuff on the Fedora netapp and changing > > what UID has write access there. > > > > For now, I'm syncing rawhide by hand. > > > > Comments? > > Is changing the user that owns the files going to cause unnecessary rsync > churn for mirrors? > Only if we change the uid of ftpsync. If we change the uid of masher we're good on the mirrors. -Mike ___ 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
Jesse Keating ([EMAIL PROTECTED]) said: > So I realized something last night. We created a user "masher" to have > the ability to write to /mnt/koji/mash/ but not any of the other koji > space. This is useful to prevent too much damage from a horribly wrong > rawhide compose. To make things easier in the rawhide compose configs, > we decided to run the cron/scripts as the masher user. This is also > good because it means things run unprivileged. However I ran into a > snag. We have another user, 'ftpsync' that has write access > to /pub/fedora/. Previously the rawhide script was ran as root, and > thus it was no problem to su ftpsync for the rsync calls. The masher > user does not possess the capability of doing this. > > Since the ftpsync user is only really used to sync data onto the Fedora > netapp, I propose that we collapse ftpsync and masher into one user > (masher). It'll require minimal puppet changes, mostly just moving some > cron jobs from ftpsync over to masher. It will require UID changes, > either changing masher to the ftpsync UID (which breaks our new range we > just setup), or chmodding some stuff on the Fedora netapp and changing > what UID has write access there. > > For now, I'm syncing rawhide by hand. > > Comments? Is changing the user that owns the files going to cause unnecessary rsync churn for mirrors? Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Introductions
Toshio, I am most definitely interested, I will jump on IRC as soon as I can find a hole in the firewall at work, Otherwise I will be on when I get back home. I am in US Central Time. if I can find a hole before the meeting I will attend. if possible can you shoot me an email with a cli project so I can get a jump on it. 2008/8/28 Toshio Kuratomi <[EMAIL PROTECTED]> > Mike Watters wrote: > >> Hello, >> I have applied to the sysadmin group and would like to give you an >> overview my experience. >> >> I have been a systems admin or security analyst for 12 years at 3 major >> worldwide (US based) companies. the majority of the time I was a systems >> admin for Solaris, AIX >> I did about 2years of admin work for SGI and HPUX boxes. I did 2 years of >> security analyst for Solaris, AIX and RHEL. I have been using Fedora from >> Fedora 7 release. I am proficient in Perl, bash, ksh scripting. I am >> competent with C, C++ and Java ( I prefer C ) I am looking to learn Python. >> >> My programming/scripting is almost all CLI apps. I did some TCL/TK stuff >> long ago. >> I am learning GTK and Glade in my free time. using libglade and C. >> >> I am looking for a sponsor for the Sysadmin group >> >> Please let me know if you would like any further info. >> >> personal info. I have been married for 9 years and have 3 children, 2 >> boys 7 and 5 and 1 girl 18mo. I shoot pool on an APA league one night a >> week, I took the summer off to get some projects done around the house. I >> look to start again in a couple of weeks for the Fall session. I am a SL 5 >> in the APA. the ratings are from 2 ( extreme novice ) to 7 ( break and >> run 3 or more of 10 racks ) >> >> > Hi Mike, are you interested in continuing to learn python? If so, I have > a bunch of projects that you can help out with from command line apps to > TurboGears web applications. > > If you're on IRC, you can ping me on irc.freenode.net #fedora-admin > abadger1999 and let me know what you might be interested in. > > -Toshio > > > ___ > 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: Strange popen behavior on xen builders?
Orion Poplawski wrote: Orion Poplawski wrote: Filed bug #459442 as I have a simple test case. Once everything is back up we can test again. It appears that the pipe2 syscall on the x86_64 xen kernels is broken and that rawhide glibc has moved to using pipe2 from pipe in rawhide. This seems like a blocker to me. Okay, looks like a known issue with the xen kernels. New test kernels are available, see the bug for more info. We should get a fixed version onto the Fedora xen builders very soon, and maybe disable them until they can be fixed? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane [EMAIL PROTECTED] Boulder, CO 80301 http://www.cora.nwra.com ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Introductions
Mike Watters wrote: Hello, I have applied to the sysadmin group and would like to give you an overview my experience. I have been a systems admin or security analyst for 12 years at 3 major worldwide (US based) companies. the majority of the time I was a systems admin for Solaris, AIX I did about 2years of admin work for SGI and HPUX boxes. I did 2 years of security analyst for Solaris, AIX and RHEL. I have been using Fedora from Fedora 7 release. I am proficient in Perl, bash, ksh scripting. I am competent with C, C++ and Java ( I prefer C ) I am looking to learn Python. My programming/scripting is almost all CLI apps. I did some TCL/TK stuff long ago. I am learning GTK and Glade in my free time. using libglade and C. I am looking for a sponsor for the Sysadmin group Please let me know if you would like any further info. personal info. I have been married for 9 years and have 3 children, 2 boys 7 and 5 and 1 girl 18mo. I shoot pool on an APA league one night a week, I took the summer off to get some projects done around the house. I look to start again in a couple of weeks for the Fall session. I am a SL 5 in the APA. the ratings are from 2 ( extreme novice ) to 7 ( break and run 3 or more of 10 racks ) Hi Mike, are you interested in continuing to learn python? If so, I have a bunch of projects that you can help out with from command line apps to TurboGears web applications. If you're on IRC, you can ping me on irc.freenode.net #fedora-admin abadger1999 and let me know what you might be interested in. -Toshio signature.asc Description: OpenPGP digital signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: rawhide, /mnt/koji and /pub/fedora
2008/8/28 Jesse Keating <[EMAIL PROTECTED]> > On Thu, 2008-08-28 at 08:52 +0200, Xavier Lamien wrote: > > yeah, you can easily do that by invoking : /bin/mail -r From_adress > > hope that mailx is up to date ;) > > Looks like that's not working in EL5. Pitty. > hm... is installed rhel-5.2 working with mailx-8.1.1 on the box ? if so, that will imply to update it. This feature has been integrated from release 9.25 another way could be to add ~r From-adress in the header of the file content (should work for version =< 10.2 ). -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB ___ 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
On Thu August 28 2008, Jesse Keating wrote: > On Thu, 2008-08-28 at 08:52 +0200, Xavier Lamien wrote: > > yeah, you can easily do that by invoking : /bin/mail -r From_adress > > hope that mailx is up to date ;) > > Looks like that's not working in EL5. Pitty. This works for me on CentOS 5, after the "--" sendmail options can be used: /bin/mail -s SUBJECT [EMAIL PROTECTED] -- -f [EMAIL PROTECTED] -F "freeform from part" Regards, Till signature.asc Description: This is a digitally signed message part. ___ 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
On Thu, Aug 28, 2008 at 11:27 AM, Seth Vidal <[EMAIL PROTECTED]> wrote: > On Thu, 2008-08-28 at 09:22 -0700, Jesse Keating wrote: >> On Thu, 2008-08-28 at 08:52 +0200, Xavier Lamien wrote: >> > yeah, you can easily do that by invoking : /bin/mail -r From_adress >> > hope that mailx is up to date ;) >> >> Looks like that's not working in EL5. Pitty. > > a simple python script to do that is easy enough. Looks like configs/system/sendmail-unicode.py is already out there... -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" ___ 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
On Thu, 2008-08-28 at 09:22 -0700, Jesse Keating wrote: > On Thu, 2008-08-28 at 08:52 +0200, Xavier Lamien wrote: > > yeah, you can easily do that by invoking : /bin/mail -r From_adress > > hope that mailx is up to date ;) > > Looks like that's not working in EL5. Pitty. > a simple python script to do that is easy enough. -sv ___ 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
On Thu, 2008-08-28 at 08:52 +0200, Xavier Lamien wrote: > yeah, you can easily do that by invoking : /bin/mail -r From_adress > hope that mailx is up to date ;) Looks like that's not working in EL5. Pitty. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part ___ 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
On Thu, 2008-08-28 at 11:57 +0200, Jeroen van Meeuwen wrote: > > 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. bar > > Does that narrow it down sufficiently? I think so. I'll play with this some today. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) signature.asc Description: This is a digitally signed message part ___ 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
On Thu, 28 Aug 2008, Seth Vidal wrote: > On Thu, 2008-08-28 at 08:42 -0500, Mike McGrath wrote: > > On Wed, 27 Aug 2008, Jesse Keating wrote: > > > > > So I realized something last night. We created a user "masher" to have > > > the ability to write to /mnt/koji/mash/ but not any of the other koji > > > space. This is useful to prevent too much damage from a horribly wrong > > > rawhide compose. To make things easier in the rawhide compose configs, > > > we decided to run the cron/scripts as the masher user. This is also > > > good because it means things run unprivileged. However I ran into a > > > snag. We have another user, 'ftpsync' that has write access > > > to /pub/fedora/. Previously the rawhide script was ran as root, and > > > thus it was no problem to su ftpsync for the rsync calls. The masher > > > user does not possess the capability of doing this. > > > > > > Since the ftpsync user is only really used to sync data onto the Fedora > > > netapp, I propose that we collapse ftpsync and masher into one user > > > (masher). It'll require minimal puppet changes, mostly just moving some > > > cron jobs from ftpsync over to masher. It will require UID changes, > > > either changing masher to the ftpsync UID (which breaks our new range we > > > just setup), or chmodding some stuff on the Fedora netapp and changing > > > what UID has write access there. > > > > > > For now, I'm syncing rawhide by hand. > > > > > > Comments? > > > > Fine by me. ftpsync isn't really one of ours anyway :) > > > > it and masher are, however, names that need to get added to the banlist > in fas, I think. > Anyone care to think of a less manual way of doing this? -Mike ___ 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
On Thu, 2008-08-28 at 08:42 -0500, Mike McGrath wrote: > On Wed, 27 Aug 2008, Jesse Keating wrote: > > > So I realized something last night. We created a user "masher" to have > > the ability to write to /mnt/koji/mash/ but not any of the other koji > > space. This is useful to prevent too much damage from a horribly wrong > > rawhide compose. To make things easier in the rawhide compose configs, > > we decided to run the cron/scripts as the masher user. This is also > > good because it means things run unprivileged. However I ran into a > > snag. We have another user, 'ftpsync' that has write access > > to /pub/fedora/. Previously the rawhide script was ran as root, and > > thus it was no problem to su ftpsync for the rsync calls. The masher > > user does not possess the capability of doing this. > > > > Since the ftpsync user is only really used to sync data onto the Fedora > > netapp, I propose that we collapse ftpsync and masher into one user > > (masher). It'll require minimal puppet changes, mostly just moving some > > cron jobs from ftpsync over to masher. It will require UID changes, > > either changing masher to the ftpsync UID (which breaks our new range we > > just setup), or chmodding some stuff on the Fedora netapp and changing > > what UID has write access there. > > > > For now, I'm syncing rawhide by hand. > > > > Comments? > > Fine by me. ftpsync isn't really one of ours anyway :) > it and masher are, however, names that need to get added to the banlist in fas, I think. -sv ___ 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
On Wed, 27 Aug 2008, Jesse Keating wrote: > So I realized something last night. We created a user "masher" to have > the ability to write to /mnt/koji/mash/ but not any of the other koji > space. This is useful to prevent too much damage from a horribly wrong > rawhide compose. To make things easier in the rawhide compose configs, > we decided to run the cron/scripts as the masher user. This is also > good because it means things run unprivileged. However I ran into a > snag. We have another user, 'ftpsync' that has write access > to /pub/fedora/. Previously the rawhide script was ran as root, and > thus it was no problem to su ftpsync for the rsync calls. The masher > user does not possess the capability of doing this. > > Since the ftpsync user is only really used to sync data onto the Fedora > netapp, I propose that we collapse ftpsync and masher into one user > (masher). It'll require minimal puppet changes, mostly just moving some > cron jobs from ftpsync over to masher. It will require UID changes, > either changing masher to the ftpsync UID (which breaks our new range we > just setup), or chmodding some stuff on the Fedora netapp and changing > what UID has write access there. > > For now, I'm syncing rawhide by hand. > > Comments? Fine by me. ftpsync isn't really one of ours anyway :) -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Introductions
On Wed, 27 Aug 2008, Mike Watters wrote: > Hello, > I have applied to the sysadmin group and would like to give you an overview my > experience. > > I have been a systems admin or security analyst for 12 years at 3 major > worldwide (US based) companies. the majority of the time I was a systems > admin for Solaris, AIX > I did about 2years of admin work for SGI and HPUX boxes. I did 2 years of > security analyst for Solaris, AIX and RHEL. I have been using Fedora from > Fedora 7 release. I am proficient in Perl, bash, ksh scripting. I am > competent with C, C++ and Java ( I prefer C ) I am looking to learn Python. > > My programming/scripting is almost all CLI apps. I did some TCL/TK stuff long > ago. > I am learning GTK and Glade in my free time. using libglade and C. > > I am looking for a sponsor for the Sysadmin group > > Please let me know if you would like any further info. > > personal info. I have been married for 9 years and have 3 children, 2 boys 7 > and 5 and 1 girl 18mo. I shoot pool on an APA league one night a week, I > took the summer off to get some projects done around the house. I look to > start again in a couple of weeks for the Fall session. I am a SL 5 in the APA. > the ratings are from 2 ( extreme novice ) to 7 ( break and run 3 or more of > 10 racks ) > Welcome Mike! Keep on people until you find a sponsor. Make sure to come to our meetings if you can make them: http://fedoraproject.org/wiki/Infrastructure/Meetings -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: hello
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Amitakhya Phukan wrote: > Mike McGrath wrote: >> On Wed, 2 Jul 2008, Amitakhya Phukan wrote: >> >> >>> hi people! >>> >>> i was away for a long time and now i am back. i am looking >>> forward to contributing to fedora infrastructure now and am >>> looking for some work :) >>> >>> can anyone please help me out here ? >>> >>> >> Sounds like you need a sponsor! Which FIG are you interested in? >> >> >> -Mike > hi, > > sysadmin-test and sysadmin-hosted interest me as of now. > > regards, amit. hi, anyone out there to sponsor me ? :) regards, amit. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki2nQ0ACgkQisV6fTFpwA05NwCeNDi4M+DhhKCydwEs8X3G08W5 hDAAn1KvNl1o658WB92fnMDZSpvhIN/s =AzUe -END PGP SIGNATURE- ___ 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: 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 that runs: rsync ... 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. 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
