Re: dist-git proof of concept phase 2 ready for testing
Sorry, if I missed this in previous messages... Are the cvs tags going to become git tags, or git branches? When I checked out ~48 hours ago, it seemed like everything was a git branch, which is not what I expected for the build tags. kernel.org admins recommend either 'git tag -a' or 'git tag -s' tags, and not plain 'git tag'. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On 12/19/2009 08:04 PM, Jesse Keating wrote: On Dec 19, 2009, at 15:02, Jeff Garzik jgar...@pobox.com wrote: Sorry, if I missed this in previous messages... Are the cvs tags going to become git tags, or git branches? When I checked out ~48 hours ago, it seemed like everything was a git branch, which is not what I expected for the build tags. kernel.org admins recommend either 'git tag -a' or 'git tag -s' tags, and not plain 'git tag'. The cvs tags should become gi tags. If they aren't I'll have to look into it. Yep, current pull looks fine that way. Everything is git tags, with zero git branches. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Datacenter, git, and cvs
On 12/14/2009 04:57 PM, Todd Zullinger wrote: Mike Chambers wrote: If I understand what is happening now (and over the past weekend), the datacenter machines are moving to a new location, AND the package building is moving from cvs to git (will be, or already in process)? Only the former is taking place now. A move from cvs to git is being tested but is not imminent. I'm sure that it will be hard to miss once that change is ready and implemented. If done right, the move to git can still service CVS requests in some capacity... that may make the transition a little less abrupt and painful. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On 11/24/2009 08:31 PM, Matthew Miller wrote: On Tue, Nov 24, 2009 at 06:17:08PM -0600, Dennis Gilmore wrote: the goal for F-13 is to have unified media, for F-14 and beyond we could look at other options like having a 64 bit kernel and 32 bit userland. i should have stated that a bit more clearly So would this mean one disk with two repositories on it, or is everything mashed together all in one repository? The current x86-64 has both 32-bit and 64-bit mashed together, so that sort of configuration would be more of the same. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On 11/24/2009 09:58 PM, Matthew Miller wrote: On Tue, Nov 24, 2009 at 09:19:22PM -0500, Jeff Garzik wrote: So would this mean one disk with two repositories on it, or is everything mashed together all in one repository? The current x86-64 has both 32-bit and 64-bit mashed together, so that sort of configuration would be more of the same. Well, it's currently only half-mashed. In Fedora 12, the i686 and x86-64 rpms are in the same directory, on the x86-64 DVD ISO. That's sufficiently mashed for my purposes, but whatever... :) Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [RFC] unified i386/x86_64 install media.
On 11/25/2009 01:32 AM, Jesse Keating wrote: On Nov 24, 2009, at 19:30, Jeff Garzik jgar...@pobox.com wrote: On 11/24/2009 09:58 PM, Matthew Miller wrote: On Tue, Nov 24, 2009 at 09:19:22PM -0500, Jeff Garzik wrote: So would this mean one disk with two repositories on it, or is everything mashed together all in one repository? The current x86-64 has both 32-bit and 64-bit mashed together, so that sort of configuration would be more of the same. Well, it's currently only half-mashed. In Fedora 12, the i686 and x86-64 rpms are in the same directory, on the x86-64 DVD ISO. That's sufficiently mashed for my purposes, but whatever... :) Look closer. It is only a small subset of the i686 content in the x86_64 repo for multilib purposes. That's merely a space issue, not any failure to or absence of mash Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On 11/20/2009 02:21 AM, Rudolf Kastl wrote: there are also inconsistencies between gui clickery and shell usage... simple example: click shutdown in gnome just does it in f12 Yeah, you can do that in F11 as well :( I agree, this needs protecting with a root password too. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On 11/19/2009 09:03 AM, Chris Adams wrote: Again, you are also making the assumption that desktop distro == single-user system, when the Fedora desktop work is going in the other direction (making the desktop more multi-user friendly). Many home systems are now multi-user, and not everybody should be installing software. +1 agreed A huge number of comments here, in the bugzilla, and elsewhere point to desktop spin == no root password logic being quite unpopular. It needs to be an /option/ in the desktop spin, an option defaulted to OFF (== prompt for root pw). Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/19/2009 12:16 PM, Simon Andrews wrote: Bill Nottingham wrote: Jeff Garzik (jgar...@pobox.com) said: This sounds like a tacit admission that the default install for servers is bloody stupid (== same as desktop), unless the admin REMOVES packages we helpfully installed on the server system. PackageKit has only ever been included in destkop package groups. While these groups are enabled by default, they are with the caveat of: The default installation of Fedora includes a set of software applicable for general internet usage. I've just been and checked on our servers, which were installed with minimal packages and never used for desktop activities and found two of them with PackageKit installed. Looking at the dependencies there is nothing on those machines which currently requires PackageKit so it could be cleanly removed, but something has pulled this in as a dependency in the past. Both of these machines have been through sequential upgrades from around FC3. Changing the behaviour of PackageKit would certainly affect me and I've never explicity installed it. Indeed. This issue is giving Fedora a major black eye in security. And this major security issue -- where admins upgrade into insecurity -- is just hand-waved away even though it applies to a lot of situations. As Kevin K noted, it is completely illogical that the presence or absence of a package (PackageKit) dictates security, or lack thereof. Desktop spin or not, you need to prompt for a root password by default, unless the user has opted INTO a lowered security policy. Ironically, even Microsoft Windows Vista is smart enough to ASK if you want a loose or tight security policy. Fedora 12 just assumes you want a loose policy. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/19/2009 03:59 PM, Peter Jones wrote: On 11/19/2009 03:37 PM, Jeff Garzik wrote: On 11/19/2009 12:16 PM, Simon Andrews wrote: Bill Nottingham wrote: Jeff Garzik (jgar...@pobox.com) said: This sounds like a tacit admission that the default install for servers is bloody stupid (== same as desktop), unless the admin REMOVES packages we helpfully installed on the server system. PackageKit has only ever been included in destkop package groups. While these groups are enabled by default, they are with the caveat of: The default installation of Fedora includes a set of software applicable for general internet usage. I've just been and checked on our servers, which were installed with minimal packages and never used for desktop activities and found two of them with PackageKit installed. Looking at the dependencies there is nothing on those machines which currently requires PackageKit so it could be cleanly removed, but something has pulled this in as a dependency in the past. Both of these machines have been through sequential upgrades from around FC3. Changing the behaviour of PackageKit would certainly affect me and I've never explicity installed it. Indeed. This issue is giving Fedora a major black eye in security. And this major security issue -- where admins upgrade into insecurity -- is just hand-waved away even though it applies to a lot of situations. Seriously, quit spreading this it's hand-waved away FUD. Elsewhere in the thread, notably without your participation, people have started I'm in the thread; I guess that's another thing you are hand-waving away. discussing both guidelines for how polkit policy should work and also mentioned that they're going to bring this specific case up at the next FESCo meeting and try to deal with it. So seriously, quit pontificating about how your opinion is the truth, the way, and the light, and start reading what others are saying. It's not as you seem to think is is. These are facts, not opinion: * F11 with PK would prompt for a password * F12 with PK does not * Everyone upgrading to F12, with PK on their system, receives this wonderful gift of lessened security. * The user is not warned of this change, either via upgrade tool or [gold] release notes. * Judging by the reaction here and elsewhere, this change was NOT expected by the Fedora userbase. Every second that ticks by, more people upgrade into insecurity, with no warning besides a slashdot thread. This is a secalert issue. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Vote for the bug (was Re: Local users get to play root?)
Note to all... Please add your vote to https://bugzilla.redhat.com/show_bug.cgi?id=534047 (Active local console users get to install signed software on a machine they do not have the root password to) I agree with Rahul that it is less productive to +1 on this email thread. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Vote for the bug (was Re: Local users get to play root?)
On 11/19/2009 07:48 PM, Jesse Keating wrote: On Nov 19, 2009, at 13:51, Jeff Garzik jgar...@pobox.com wrote: Note to all... Please add your vote to https://bugzilla.redhat.com/show_bug.cgi?id=534047 (Active local console users get to install signed software on a machine they do not have the root password to) I agree with Rahul that it is less productive to +1 on this email thread. Yes because what we really need here is more noise... Please do /not/ pile on to the bug. It will not help no matter what your opinion is. huh? Are you not familiar with the concept of bugzilla votes? Try clicking on the '(vote)' link sometime. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Vote for the bug (was Re: Local users get to play root?)
On 11/19/2009 08:25 PM, Jeff Spaleta wrote: On Thu, Nov 19, 2009 at 4:15 PM, Jeff Garzikjgar...@pobox.com wrote: Are you not familiar with the concept of bugzilla votes? Try clicking on the '(vote)' link sometime. I'm not aware of a workflow or policy which takes into account bugzilla votes in Fedora. Individual maintainers may or may not consider votes when prioritizing how they use bugzilla, but there's certainly nothing that I am aware that suggests that highly voted on bugs are subject to high level review or discussion as a part of project management. I fear that you are encouraging people to vote with the expectation that the vote will matter in some way when it may not. Valid points. However, I reject the implied notion that ALL feedback from Fedora users must be stifled -- which is the only conclusion one may draw from Fedora leaders asking people to (a) not comment on the list, and (b) not comment on the bug. I'm curious what Fedora leaders think is the proper forum for __Fedora users__ to register complaints against this policy. Voting seems to be the most efficient, and least spam-y method of doing so, but I am open to suggestions! Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Vote for the bug (was Re: Local users get to play root?)
On 11/19/2009 09:20 PM, Jeff Spaleta wrote: On Thu, Nov 19, 2009 at 4:34 PM, Jeff Garzikjgar...@pobox.com wrote: I'm curious what Fedora leaders think is the proper forum for __Fedora users__ to register complaints against this policy. Voting seems to be the most efficient, and least spam-y method of doing so, but I am open to suggestions! Voting doesn't mean much if there's no agreement to process the votes. No, you misunderstand the purpose of Bugzilla voting. But I think you've failed to state something important. I think what you really want to know is how Fedora users can register complaints meant to illicit an immediate response... faster than the turn around one can obtain via a fesco meeting. You want a 911 number to call, instead of a town meeting to speak at. No, that's not it at all. I meant precisely what I said, no more, no less: it makes ZERO sense to squelch Fedora users' feedback. Fedora leaders are saying no feedback on fedora-devel and no feedback on the bugzilla, and now, no Bugzilla voting. Bugzilla voting was created precisely so that users could raise the profile of a bug and register their voice, without adding actual noise to the discussion. Similar to like links on Facebook. Fedora users -- keep on voting, that is why the feature exists. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Sorry, but this default (desktop users can install pkgs without root) is just stupid. It is antithetical to all standard security models that have come before in Fedora and other Linux distributions. Instead of shielding yourselves with silly arguments about the lack of lock-and-key on a desktop machine, ask yourself how many decades-old assumptions you are wiping in one fell swoop. It's no excuse to give viruses, pranksters and other vectors easy access to Fedora. Even Microsoft Windows asks for elevated privileges for this sort of thing! This is just shameful. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 12:45 PM, Bastien Nocera wrote: On Wed, 2009-11-18 at 18:08 +0100, nodata wrote: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! Seems fair as the default for a desktop installation. Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin. No, the sane security answer is to least privileges as-is (require root) until your new user management stuff is ready. Re-read your own post, and realize you proposed: FC1+: secure F12: insecure F13+ secure again This is a hugely inconsistent security policy, a special case that administrators must un-learn and re-learn as they go through Fedora versions. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 01:04 PM, Seth Vidal wrote: On Wed, 18 Nov 2009, Jon Ciesla wrote: Seth Vidal wrote: You have PackageKit installed on servers? really? I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it. Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server. This sounds like a tacit admission that the default install for servers is bloody stupid (== same as desktop), unless the admin REMOVES packages we helpfully installed on the server system. Does that sound like good engineering to you? Sorry, this new policy is wildly inconsistent, a special case that will change in F13, we are told. It is wholly different from the entire history of Linux distributions. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 01:28 PM, Seth Vidal wrote: I didn't say it did - I said it didn't make sense to have items like PK on servers. Listen to yourself. The above is a blatant admission that it is REALLY EASY for existing users to upgrade themselves into a security nightmare. * F11 w/ PK: requires root * F12 w/ PK: does not require root And you don't see any problem with this? Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 01:23 PM, Seth Vidal wrote: On Wed, 18 Nov 2009, nodata wrote: Am 2009-11-18 19:18, schrieb Colin Walters: This is a major change. I vote for secure by default. If the admin wishes this surprise-root feature to be enabled he can enable it. I'm not sure how this is 'surprise root'. IT will only allow installs of pkgs signed with a key you trust from a repo you've setup. which pretty much means: if the admin trusts the repo, then it is okay. if the admin doesn't trust the repo it should NOT be on the box and enabled b/c an untrusted repo can nuke your entire world. By your own adminssion, we are talking about DESKTOP USERS. How little social engineering + virus automation does it take to get such an install to include a malicious 3rd party repo? Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 01:41 PM, Konstantin Ryabitsev wrote: 2009/11/18 Simo Sorcesso...@redhat.com: On Wed, 2009-11-18 at 13:19 -0500, Konstantin Ryabitsev wrote: This significantly limits the number of users with powers to install signed software -- almost to the point of where it sounds like a fair trade-off. If someone has physical access to the machine, then heck -- it's not like they don't already effectively own it. Most of my users wouldn't be able to own it even if I let a root shell open, but they would definitely be able to install or remove packages using the GUI. The difference is huge. If I have physical access to your machine, I'll own it. I may have to use tools to get to the HDD, but it's only a question of time and dedication. Now, there can be situations where someone has access to the TTY console or GDM (usually when it's a VM guest or a machine behind a network KVM), but most often, if someone can log in on the console, they are sitting in front of the physical box, to which they have full access. Console access is no excuse for a completely lax security policy. Didn't Microsoft Windows teach us all that? In the real world(tm), hacking via console access still means there are a lot of hurdles you must dodge, like making noise while opening the case. This new policy completely screws multi-user setups where (for example) kids are given a login to play games -- but I sure don't want them to be installing packages. Now, pkgs installs for them are trivial. The physical argument by policy proponents is the real straw man: F12+PK lowers the security barrier from difficult to a simple mouse click. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 02:26 PM, Bob Arendt wrote: On 11/18/09 12:03, Konstantin Ryabitsev wrote: 2009/11/18 Simo Sorcesso...@redhat.com: If I have physical access to your machine, I'll own it. I may have to use tools to get to the HDD, but it's only a question of time and dedication. *you* are not one of my users, and this has nothing to do with *you* hacking in my machine. If I have physical access to a machine I do not even care about what's installed on it. In 99% of the cases I will just be able to boot from a live cd. That's a completely different issue. Well, then we're violently agreeing about the same thing. Anyway. It doesn't look like this is a change in Fedora policy, because it clearly caught everyone off-guard. Looks like PK developer made an executive decision and it's up to us to either issue an update to revert to the previous behaviour, or to continue debating whether allowing local console users to install trusted software from trusted repositories is a sane security trade-off. I haven't tried .. but does this this also include the capability for my grade-school child to *remove* software using their account? Like gcc? glibc? gdm? All fun activities ... They sure can install all the naughty software you've forbidden on that machine. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 02:53 PM, Casey Dahlin wrote: The answer is: because being associated with a login on the local console doesn't verify that it is a /user/ in control. Bingo. I guess everyone else missed that day in Security 101 class. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 03:25 PM, Colin Walters wrote: On Wed, Nov 18, 2009 at 3:20 PM, Jeff Spaletajspal...@gmail.com wrote: I'm not sure enough sysadmins understand PolicyKit enough to confidently generate local policy edits. I think learning how to implement site specific PolicyKit best practises by modifying unwanted PackageKit's behavior is going to be a trial by fire introduction to PolicyKit policy editting for a lot of admins. We saw the same sort of learning curve frustration when hal policy was introduced that changed how hardware was handled. Having Yet Another access control system in HAL was precisely the reason PolicyKit was created, so administrators can have one place to find this stuff across the OS. Rather irrelevant to our current problem, unfortunately. Admins will upgrade to F12 not knowning that PK policy defaults have changed. They will upgrade into insecurity. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 04:34 PM, Seth Vidal wrote: I said I do remove items from @core that I don't need. It was my way of saying servers should have as little as possible on them. You keep repeating this, as if your personal actions and situation are relevant. How many existing installs out there have PK, and will get upgraded into insecurity? How many admins will even known about this new F12 policy when they install? At a minimum there should have been a big flashing warning in F12 release notes, employing the blink tag, at the very top about this security change. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 04:46 PM, Seth Vidal wrote: Jeff, I think you're misunderstanding, a lot, here. I'm not in favor of user-can-install-pkgs. I'm just explaining why I don't think pk should be on servers. PK will be on F12 servers, because of upgrades and very poor communication of this new policy. That is the reality of the situation. /should/ is not relevant at all here. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 05:14 PM, Richard Hughes wrote: 2009/11/18 Jeff Garzikjgar...@pobox.com: How little social engineering + virus automation does it take to get such an install to include a malicious 3rd party repo? You need the root password to install from repos not signed by a key previously imported, or if the package signature is wrong. You forget we have botnets doing distributed cracking now. Fedora just opened up a huge attack vector, for the users who are least equipped to understand the consequences. And this enormous security hole of a policy change was done with next to /zero/ communication, making it likely that many admins will not even know they are vulnerable until their kids install a bunch of unwanted packages. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 05:36 PM, Colin Walters wrote: On Wed, Nov 18, 2009 at 5:18 PM, Jeff Garzikjgar...@pobox.com wrote: You forget we have botnets doing distributed cracking now. But...if you've cracked the root password, there are rather easier (and less audited) routes to trojaning the system than adding a third party yum repository and downloading your malicious RPM. I am talking about cracking signing keys, not root passwords. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 05:38 PM, Richard Hughes wrote: If you're deploying F12, then I really think you should know the basics about PolicyKit. should? The F12 security policy is dumbed down to make life easier for users, making it easier for them to get by with -less- knowledge. And yet you claim that education bar should be HIGHER than F10/F11? That is unrealistic. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 05:51 PM, Rahul Sundaram wrote: On 11/19/2009 04:19 AM, Richard Hughes wrote: 2009/11/18 Seth Vidalskvi...@fedoraproject.org: Richard, to be fair, when I asked you how to edit a .pkla file you couldn't tell me. So, if our engineers don't know the basics, how should our users? Fair comment. Release notes additions might be good in this regard. It should have been announced and documented with the rationale for the change *before* the release. Just pretending that everyone should know about how PolicyKit works when documentation is just lacking doesn't cut it. You didn't even respond to by bugzilla comment and just closed the Agreed 100.1%. bug. We will still do a post-release update for the release notes now but that's scrambling to minimize damage. The only thing that will fix the damage is to update PK, reverting the default-insecure policy. May I remind folks that it is easy to UPGRADE INTO INSECURITY here. Admins with servers, coming from F10/F11, can very easily fall into this trap simply by updating their current systems. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 06:12 PM, Richard Hughes wrote: 2009/11/18 Eric Christensene...@christensenplace.us: Has anyone drafted a notice to go out on the Announce List explaining this vulnerability? If admins don't know to fix/remove PK then they are putting their systems at risk. I'm really bored of this conversation. The bikeshed is blue. There are much bigger problems in UNIX security than installing signed packages. We don't set a grub password by default. Signed does not mean bug-free. Further, observe the broken logic: Because local users might be able to break into the system with effort, it is pointless to have any safeguards at all. [firefox|pidgin] exploit + PackageKit == trivial remote exploit. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 07:23 PM, Bill Nottingham wrote: Jeff Garzik (jgar...@pobox.com) said: Sorry, but this default (desktop users can install pkgs without root) is just stupid. It is antithetical to all standard security models that have come before in Fedora and other Linux distributions. Out of the box, a desktop user has the ability to shut down the machine. This gives them the ability, out of the box, to: - DoS everyone on it - get a root shell -- install whatever they want -- put viruses on - hell, slap in a livecd or USB key and reinstall the box How is any of that justification for lowering the security bar to zero? All of those you list are more technically complex than the current F12 behavior -- letting the kids or guests click a button. IFF this feature was listed as a question in firstboot, and IFF this feature was explained in detail in release notes, then there would have been no problem at all... You also omitted the case where admins of servers upgrade into a less secure policy. PackageKit presence does not imply desktop user. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 07:34 PM, Jeff Garzik wrote: On 11/18/2009 07:23 PM, Bill Nottingham wrote: Jeff Garzik (jgar...@pobox.com) said: Sorry, but this default (desktop users can install pkgs without root) is just stupid. It is antithetical to all standard security models that have come before in Fedora and other Linux distributions. Out of the box, a desktop user has the ability to shut down the machine. This gives them the ability, out of the box, to: - DoS everyone on it - get a root shell -- install whatever they want -- put viruses on - hell, slap in a livecd or USB key and reinstall the box How is any of that justification for lowering the security bar to zero? All of those you list are more technically complex than the current F12 behavior -- letting the kids or guests click a button. And it ignores that remote exploits are now much easier, because remote non-root exploit + package install == remote root exploit. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 07:37 PM, Colin Walters wrote: On Wed, Nov 18, 2009 at 7:36 PM, Jeff Garzikjgar...@pobox.com wrote: And it ignores that remote exploits are now much easier, because remote non-root exploit + package install == remote root exploit. No, the uid needs to have logged in through a physical console. See references in multiple mails to firefox, pidgin, and any number of other example applications run by a uid logged in through a physical console. Web browsers -- especially with bin-only flash -- are the most likely vector for remote exploits these days. Far more so than any system daemon. There are Real Good(tm) reasons why Firefox complains, if your Flash plug-in is out of date, even on Linux... Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security policy oversight needed?
On 11/18/2009 07:37 PM, Mike McGrath wrote: I think that's too subjective though. I'd be more in favor of a simple, broad view of what the user should be able to do without root. It's possible install packages would be on that list, it's possible not. That way packages could ask themselves does this break the policy? If it doesn't, great. If it does, time for a bug report. Better then a review process because then everyone would generally know what to expect. Agreed, that makes more sense and is more scalable. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 07:52 PM, Eric Christensen wrote: I guess the big thing, to me, is that this vulnerability wasn't presented, documented, or talked about and it is the opposite policy to what most (all?) SYSADMINS would expect. If you don't know to fix it then you are pwned. Bingo. That is the crux of the dilemma. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 07:45 PM, Mike McGrath wrote: Stick with the facts, be clear about what you're trying to accomplish (changing it back in F13? Changing it back in F12? Setting a policy so stuff like this doesn't happen again?) 1) We should recognize this new policy departs from decades of Unix and Linux sysadmin experience. 2) F12 policy should be reverted to F11, ASAP. Possibly with a CVE. 3) Due to #1, F13+ should not deviate from the decades-old default. 4) Release notes should explain new [and after step #2, optional] policy in detail, including how to turn it off again. Seth's laudable write-up efforts should not have been necessary -- that info should be prepared. 5) The people who want this new security policy should add an opt-in checkbox in Anaconda or firstboot. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
Another data point for this thread: Running a 64-bit kernel with a 32-bit userland is a common practice on non-x86 platforms, and non-Linux OS's. For a lot of tasks, you simply do not need 64-bit pointers and a 64-bit process address space. Both executable code and in-memory data structures tend to be smaller on 32-bit. cp(1), for example, can be 32-bit as long as it supports O_LARGEFILE and off64_t. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86-64 on i386 (was Re: Promoting i386 version over x86_64?)
On 11/18/2009 09:56 PM, Roland McGrath wrote: Another data point for this thread: x86 is unlike other architectures because 64-bit also has twice as many registers as 32-bit. So you get to trade off the benefits of register allocation across more registers against the memory/cache footprint of 64-bit pointers. Absolutely. x86-64 is definitely one of my favorite ISAs. Worlds improvement from i386. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On 11/18/2009 01:32 AM, Gregory Maxwell wrote: I noticed that http://fedoraproject.org/get-fedora appears to be strongly promoting i386 Fedora over x86_64. Is this intentional or an oversight? I agree, that was my first impression as well. However, if you just want a single download now button, 32-bit would get you the widest hardware coverage. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: buildsys Broken dependencies - libc
On 11/16/2009 12:37 AM, Arthur G wrote: Hi anyonewhocanhelp, Just curious, is libc now an explicit dependency or should I buy a sense of humour? broken dependencies in the development tree: On ppc: xmlfy-1.5.0-1.fc12.ppc requires libc.so.6(GLIBC_2.4) xmlfy-1.5.0-1.fc12.ppc requires libc.so.6 etc Everyone is getting these emails, therefore I assumed it would be fixed by someone other than the package maintainers :) Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
How to update F12 packages?
Project Hail[1] has three packages in F12, cld, chunkd and tabled, which need updating. I successfully built cld: make build placed it into dist-f12-updates-candidate apparently. But koji wait-repo is timing out after a two-hour wait, preventing me from building chunkd and tabled. What do I need to do, to build updated chunkd and tabled packages on top of the new cld? Does each dependency need its own bodhi update, or something? I am hoping to avoid - build cld - submit bodhi update - wait for update to be processed into repo - build chunkd - submit bodhi update - wait for update to be processed into repo - build tabled - submit bodhi update - wait for update to be processed into repo Surely there is a faster way, for _clusters_ of dependent packages, such as Project Hail's? Thanks, Jeff [1] http://hail.wiki.kernel.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: How to update F12 packages?
On 11/16/2009 09:42 PM, Orcan Ogetbil wrote: On Mon, Nov 16, 2009 at 8:43 PM, Jeff Garzik wrote: What do I need to do, to build updated chunkd and tabled packages on top of the new cld? You need to file a ticket to releng [1] and ask for buildroot overrides as outlined in the guidelines somewhere I can't remember. You need to provide them the name, version, release of the package you want to have in the buildroot so you can build other packages on top of that. Also let them know on what Fedora version(s) you want to have your package tagged. See example [2]. Ticket filed, thanks for the advice. It is a bit messy to file two tickets each time I build my packages, though :( Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Looking into LLVM
On 10/28/2009 06:24 AM, Kevin Kofler wrote: Jud Craft wrote: On Mon, Oct 26, 2009 at 12:31 PM, Kevin Kofler wrote: But this is about C++. I don't mean to misunderstand, but if I recall from your very first post in this thread... Actually, the ABI issue is only if you use the C code generator, not the native ones. Hence I thought you were talking about ABI issues with C. You misunderstood me. The C code generator is an LLVM *back*end, not a frontend. The frontend is what recognizes the input language, the backend is what defines the output LLVM generates. I'm not up on how LLVM frontend integration works, so I actually don't understand the distinction between the LLVM C Backend and the native LLVM backends. LLVM can either directly output machine code (native backend) for some architectures or it can output preoptimized C code (especially for those architectures which don't have a native backend). The latter is what the C code generator or C backend does. clang and all other LLVM language front-ends produce bitcode, which is virtualized machine code a la JVM. LLVM backend generates processor-dependent machine code from processor-independent machine code. The LLVM C __backend__ converts bitcode back into C... something no idiot in their right mind would use for C++ or anything else. The LLVM C backend is not commonly used. The vast, vast majority of people trying to compile C++ programs with LLVM would either use clang - llvm - asm code or llvm-gcc - llvm - asm code Certainly not Clang (C++) → LLVM → LLVM C backend → gcc [- asm code] Regards, Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Looking into LLVM
On 10/26/2009 10:45 AM, Adam Jackson wrote: On Mon, 2009-10-26 at 19:07 +0530, Rahul Sundaram wrote: On 10/26/2009 07:03 PM, Adam Jackson wrote: On Sun, 2009-10-25 at 21:05 +0530, Rahul Sundaram wrote: Has anyone been looking into building Fedora with it to see how the performance impact is? I'm going to go out on a limb here and say that the dominating factor in our performance is the code itself. I meant performance, primarily in terms of speed of compilation. Not the code itself. Suppose it's faster. Say even by a factor of 100. So what? What problem would that solve? Personally I don't that compile speed is as interesting as new bugs the compiler is able to highlight, either through the compilation process or through the use of LLVM as a static analyzer. But LLVM/clang is quite far away from building Fedora, so I do not think there's a need for people to get anxious. I worked for a couple weeks on fixing LLVM, clang and Linux kernel bugs so that the kernel would build under clang. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On 10/14/2009 08:21 AM, Steve Dickson wrote: On 10/13/2009 09:56 AM, Christopher Aillon wrote: Not everyone had issues with the indexing so that seemed to slip past testing. It was a change, but didn't seem to disrupt things, so we let it slide. Not to pile on, believe me I know painful change is... 8-) but... This new indexing is the biggest pain of all the changes IMHO... My laptop CPU start to and continues to be pegged when I start up and shut down TB3b... I could not read mail for 24hrs due to TPB3 trying to indexing all my mail... Granted I have a ton of mail, in large number of folders... but my CPU became pegged, TPB3 start to eat all the memory, causing everything to be swapped out, which caused the system to finally hang!! This was happen continuously. So I figured the only way to get by this was to delete mail... Which became a race between me deleting mail and TB3b try to index that folder... I have a feeling that scenario was not tested too well... ;-) So for you to say indexing didn't seem to disrupt things is simply inaccurate... It was a major disruption and a complete waste of time... Agreed. Or put more simply, this bug fix update dropped an unexpected, 2+ gigabyte turd into my NFS-mounted home directory [jgar...@bd ~]$ ls -l ~/.thunderbird/tc8ktlwu.default/global-messages-db.sqlite -rw-r--r-- 1 jgarzik jgarzik 2731515904 2009-10-14 08:42 /g/g/.thunderbird/tc8ktlwu.default/global-messages-db.sqlite as well as slowing down all my NFS accesses for ~24 hours. I hope a thunderbird update is being prepared, to make 2 config tweaks for F11? And a warning / release note for F12 users, noting that a __lot__ of additional disk space is required in ~/.thunderbird. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
thunderbird rel-eng
On 10/14/2009 10:31 AM, Jesse Keating wrote: On Wed, 2009-10-14 at 09:27 -0500, Mike McGrath wrote: The problem isn't GLODA and smart folders, it's that we have no process in place to identify and deal with problems like this before it's too late. Aside from updates-testing you mean, where people can test potential updates and give feedback as to how they work on their systems? Do you honestly believe this was a testing problem? Long after F11 release, we had an update billed as a bug fix that included 1) a major UI change. 2) additional home directory disk space requirement, several GIGABYTES in size. A non-trivial, on-going CPU usage requirement, as well. 3) global indexing which lumps together, in a single file, distinctly separate email accounts. This potentially creates a LEGAL PROBLEM for end users. These changes in the middle of a stable Fedora release are outside the bounds of normal, expected bug fixes. That is simply not up to Fedora standards by any stretch of the imagination. The above are major problems that should be caught by a release engineering process... the maintainer if nobody else. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On 10/13/2009 09:56 AM, Christopher Aillon wrote: Not everyone had issues with the indexing so that seemed to slip past testing. It was a change, but didn't seem to disrupt things, so we let it slide. We are looking at reverting both in F11. Global indexing introduces legal issues, disk space requirements and CPU requirements that extend beyond F11... Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On 10/14/2009 11:35 AM, Michael Cronenworth wrote: Jeff Garzik wrote: Global indexing introduces legal issues, disk space requirements and CPU requirements that extend beyond F11... Maybe I'm a bit stupid, but what is the significance of how many files your emails are stored in? Separating them out provides some sort of security advantage? Legally speaking, it is important, if I am ever called into court, to be able to show a distinct separation between my personal email and my NDA-heavy Red Hat email. And, bboth of which must be separate from my micro-micro-corporation. If one does not demonstrate intent at creating walls separating legal entities, it becomes a whole lot easier for a GarzikMicroCorp-related lawsuit to subpoena my personal and Red Hat email. Separation of data is basic legal CYA. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On 10/14/2009 12:03 PM, Michael Cronenworth wrote: I fully understand the separation of email accounts, but what I'm getting at is the storage of your binary data on the hard disk. If you keep any personal email on your hard disk, and the whole disk is subpoenaed, your personal+RH email will be on it. The only safe way to prevent that is to not use TB at all. It keeps caches of everything whether you like it or not. In fact, it might be a cool feature to add to TB - a corporate mode so to speak - that prevents any and all local storage of email data. That is why my cache points to a tmpfs location... goes away after each reboot. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On 10/13/2009 01:58 AM, Christopher Aillon wrote: On 10/11/2009 09:46 AM, Rahul Sundaram wrote: On 10/11/2009 10:03 PM, Michael Cronenworth wrote: I do use TB (read my email headers). I fully understood that TB 3.0 was in beta and could drastically change at any moment. I keep track of their development as well so I was prepared for the changes that have happened. If you expect beta software to act like stable software then you need to update your dictionary. Oh please. Expecting all Fedora thunderbird users to keep track of upstream development of software included in Fedora is totally ridiculous. The package maintainer made the judgement to include a beta release of thunderbird. If major UI or other behaviour changes were expected to follow in later revisions, it would have been wise to not include the beta release in the first place. Otherwise, it would have been easy enough to disable those couple of features we are talking about in the update and avoid the hassle for users. The changes were not expected. Actually, the fact that TB3 is still in beta was not expected, since it was supposed to be released as a final within a week of FF35. Clearly, things haven't been going as planned for upstream and that's had an effect on Fedora, too. While the changes are unfortunate, they have gone through testing, and I'll note that er, huh? What does that mean? If testing had been done, then why were these two _blindingly obvious_ behavior changes pushed to F11? Where did the process break down, then? Did the package maintainer think that UI and indexing changes in the middle of a stable Fedora release are acceptable, general practice? The indexing change has created a new wrinkle, too: I separate my work and non-work email for LEGAL reasons. Now the index has smushed those two together. Lovely, fscking lovely... Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: thunderbird upgrade - wtf?
On 10/11/2009 04:54 AM, Rahul Sundaram wrote: It was ok to ship a beta release of thunderbird but updates shouldn't cause such issues. If the fixes were necessary to push as updates then it would have prudent to disable smart folders and indexing by default and leave it enabled in Fedora 12. Precisely. F11 is supposed to be a stable release. The sudden appearance of both smart folders and indexing was unexpected, disruptive and IMO did not achieve the desired quality level for a Fedora stable release upgrade. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
thunderbird upgrade - wtf?
Just upgraded my F11 workstation, which included an upgrade to thunderbird-3.0-2.7.b4.fc11.x86_64 Without any prompting or warning, my email layout -- a key interface into my open source development workflow -- was changed to use something called smart folders. Also annoying, though of less impact to me personally, was the decision (again, without prompting or warning) to index all of my email -- of which there is a considerable amount. Now, I'm sure smart folders are a nifty new feature, but where was the warning about this upgrade? Why was this done late in F11, rather than F12? IMO, major MUA upgrades should be handled better than this. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PPC/PPC64 disabled in Koji for dist-f13
On 09/28/2009 12:21 PM, Josh Boyer wrote: Hi All, As of today, ppc and ppc64 are no longer primary architectures in koji starting with the dist-f13 tag. This is in accordance with the FESCo approved demotion of PowerPC starting with Fedora 13 development. The dist-f12 and older tags continue to have them as primary. Both ppc and ppc64 have been excellent at catching software bugs in my projects that long went unnoticed on i386/x86-64. The lack of big endian builds by default is a notable loss, and will lead to a decline in software quality. I think this is a net-negative for Fedora. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fp.o content via IPv6
On 09/09/2009 09:48 AM, Seth Vidal wrote: On Wed, 9 Sep 2009, Matt Domsch wrote: We could instead advertise www.ipv6.fp.o and make people choose to use v6 or not. Google does this today for exactly these reasons (failures elsewhere in the network we can't control). Kind of defeats the purpose though. Why not do this and continue working on ipv6 on the rest of the systems? rest of the systems == rest of the world. could take a while :) This is precisely IPv6's catch-22: if providers don't implement IPv6, then end user networks won't get fixed. If end user networks don't get fixed, providers won't implement IPv6. The hosts that require an explicit hostname (ipv6.google.com) tend to get used very rarely, and are poorly integrated into the existing site. There tend to be three main policy choices: 1) Work through the problems. The ideal, and also the most difficult. The most irritating to end users. 2) Wikimedia approach: deploy IPv6 as first class citizen for all engineer/admin services, where presumably the end user has some knowledge when delays or strange errors appear. wait a bit to deploy IPv6 on main, public-facing, Windows-user-using sites. 3) Google DNS approach: Whitelist networks that are IPv6-safe: Using a feature such as BIND views, return records, or not, depending on whether the querying system is in the whitelist. A nice approach and OK for google, but IMO probably too much trouble and manual labor for fp.o. An alternate approach, possibly viable for fp.o, could be to blacklist (== no records returned in DNS) networks that are terminally broken. If people wanted to pursue alt#3, I'm pretty sure BIND views will do the trick... they worked for me in the past, delivering two different versions of a zone depending on whether the querying party was external or internal to the network on which I deployed that config. http://www.oreillynet.com/pub/a/oreilly/networking/news/views_0501.html Jeff ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] add apache IPv6 config options
On 08/28/2009 05:11 PM, Matt Domsch wrote: index 5c40c80..bd4480f 100644 --- a/modules/httpd/files/httpd.conf-rhel5p +++ b/modules/httpd/files/httpd.conf-rhel5p @@ -148,6 +148,7 @@ MaxRequestsPerChild1 # Listen 0.0.0.0:80 Listen 0.0.0.0:443 +Listen [::]:80 Two comments: - wouldn't *:80 accomplish the same thing as two listen directives? Perhaps *:80 means that Apache binds, on Linux, to the slightly-more-efficient ipv6 socket, where ipv4 connections are ipv6-mapped (::10.20.30.40)? - do you need a listen [::]:443 also? ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] add IPv6 addresses for apache VirtualHost stanzas
On 08/28/2009 05:11 PM, Matt Domsch wrote:
From: Matt Domschmdom...@puppet1.fedora.phx.redhat.com
---
manifests/servergroups/proxy.pp | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/manifests/servergroups/proxy.pp b/manifests/servergroups/proxy.pp
index bfa0481..eeb9e19 100644
--- a/manifests/servergroups/proxy.pp
+++ b/manifests/servergroups/proxy.pp
@@ -22,6 +22,7 @@ class proxy {
66.35.62.162,
80.239.156.214,
152.46.7.221,
+[2610:28:200:1::fed0:1],
],
server_aliases = [ stg.fedoraproject.org ],
ssl= true,
No objection/comment on the IPv6 portion of this patch.
I'm surprised these highly repetitive address lists are not
auto-generated from a flat file (or other database), though.
Jeff
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] change proxy4 IPv6 addresses to static scheme
On 08/28/2009 05:11 PM, Matt Domsch wrote: From: Matt Domschmdom...@puppet1.fedora.phx.redhat.com --- modules/bind/files/master/fedoraproject.org |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/modules/bind/files/master/fedoraproject.org b/modules/bind/files/master/fedoraproject.org index 2327080..14eb8c3 100644 --- a/modules/bind/files/master/fedoraproject.org +++ b/modules/bind/files/master/fedoraproject.org @@ -168,8 +168,9 @@ posse8 INA 209.132.178.18 posse9 INA 209.132.178.20 proxy3 INA 66.35.62.162 proxy4 INA 152.46.7.221 -proxy4 IN 2610:28:200:1:216:3eff:fe62:9fdd +proxy4 IN 2610:28:200:1::fed0:1 proxy4-2INA 152.46.7.222 +proxy4-2IN 2610:28:200:1::fed0:2 proxy5 INA 80.239.156.214 publictest1 INA 152.46.7.227 publictest2 INA 152.46.7.228 Tangential issue... How are IPv6 addresses assigned to proxy4[-2] ? If they are statically set on the machine, all good. If they are assigned via radvd or DHCPv6, you might want to consider some setup where the machine's IPv6 address is proactively pushed to the DNS servers. One method is nsupdate + TSIG, which is pretty easy to set up on a fine-grained basis (ie. give a DNS key DNS update perms for _only_ the proxy4 addresses). Otherwise, the dynamically-assigned IPv6 address on the host may not match the IPv6 address in DNS. Jeff ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] add apache IPv6 config options
On 08/28/2009 05:11 PM, Matt Domsch wrote: From: Matt Domschmdom...@puppet1.fedora.phx.redhat.com --- modules/httpd/files/00-namevirtualhost.conf |4 modules/httpd/files/httpd.conf-rhel5p |1 + 2 files changed, 5 insertions(+), 0 deletions(-) another apache question... will ipv6 addresses in log files choke any existing log analysis tools? Jeff ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: [PATCH] add IPv6 addresses for apache VirtualHost stanzas
On 08/28/2009 07:36 PM, Mike McGrath wrote:
On Fri, 28 Aug 2009, Jeff Garzik wrote:
On 08/28/2009 05:11 PM, Matt Domsch wrote:
From: Matt Domschmdom...@puppet1.fedora.phx.redhat.com
---
manifests/servergroups/proxy.pp | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/manifests/servergroups/proxy.pp
b/manifests/servergroups/proxy.pp
index bfa0481..eeb9e19 100644
--- a/manifests/servergroups/proxy.pp
+++ b/manifests/servergroups/proxy.pp
@@ -22,6 +22,7 @@ class proxy {
66.35.62.162,
80.239.156.214,
152.46.7.221,
+[2610:28:200:1::fed0:1],
],
server_aliases = [ stg.fedoraproject.org ],
ssl= true,
No objection/comment on the IPv6 portion of this patch.
I'm surprised these highly repetitive address lists are not auto-generated
from a flat file (or other database), though.
I'm not quite sure what you mean but I am interested in a better way to do
this. basically we've got 4 sites + staging. As such, fedoraproject.org
could listen on 5 different addresses. We have to enter them somewhere,
any ideas?
I was thinking in the m4-macro sense; looking at Matt's patch, it
appears that a large number of virtual hosts have the same address list.
If so, it seems like some sort of macro substitution could be employed
to match a list of virtual hosts with a set of addresses.
Not a big deal... just noting an above-average amount of copy/paste.
Jeff
___
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Policy on removing %changelog entries?
What is the policy regarding deletion of individual entries in the middle of %changelog? A developer added a %changelog entry to each of my cloud daemons' packages, on the main fedora-cvs devel branch of each. Then, a day or so later, after other %changelog entries had been added by me... the same developer removed one %changelog entry from the middle of %changelog, and added another entry at the top. I thought the policy was to never delete %changelog entries, ever? Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: IPv6 for Fedora services?
On 08/27/2009 01:01 AM, Matt Domsch wrote: I've done some more digging, and posted my findings on [1] specifically that our torrent tracker doesn't support IPv6, though the VM is on a machine that has a global IPv6 address. I've started looking at building opentracker, which is under a beerware license (so acceptable). [...] Regarding bittorrent, http://www.sixxs.net/tools/tracker/ And they link to http://ipv6.niif.hu/index.php?mn=3sm=5lg=en which is dead, but http://ipv6.niif.hu/index.php?mn=3sm=5lg=en which is alive, and contains some discussion of IPv6 and BT. With what we have at iBiblio, we could enable ns2, proxy4, and torrent1 pretty easily. Nice! Jeff ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: IPv6 for Fedora services?
On 08/27/2009 01:06 AM, Tristan Santore wrote: Matt, I think the key issue is to get anything going. Anything is better than nothing. When other providers roll IPv6 PAs out, then those locations can be enabled, when available. Of course there would also be the 6to4 option. Might also be smart, to check if those providers offer a 6to4 gateway, then 6to4 tunneling, could be used in the interim. 6to4 is definitely worth investigating, but there are a few downsides, - gateway is often far away (you hint at this) - it complicates firewalling; a site may need additional rules relating to wrapping, unwrapping and passing protocol IPPROTO_IPV6 (41) on the iptables (ie. IPv4 tables) side of things It's definitely an option to consider, though... Jeff ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Koji build failure with coreutils-7.5
On 08/24/2009 03:11 AM, Jim Meyering wrote: Jim Meyering wrote: Todd Zullinger wrote: I tried to build a git update into dist-f12-openssl earlier and had it die in %doc with an error from cp¹: cp: preserving times for `/builddir/build/BUILDROOT/git-1.6.4.1-1.fc12.i386/usr/share/doc/git-1.6.4.1/contrib/hooks': Function not implemented Hi Todd, This is because that latest version of coreutils tries to preserve permissions on symlinks when it thinks that is possible. It determines whether to try by testing at configure time for the existence of the utimensat function. If it can compile and link against that function, then the resulting executable will call it and report any failure. The trouble is when you configure on a system with recent libraries and headers, yet *run* with a kernel that is old enough as to lack the syscall. By the way, to those who maintain koji, It is subtly dangerous to configure a package against headers and libraries that are not well-matched with the kernel. In this case, new headers/libraries suggest a function is available, as detected by a standard autoconf function-existence check. Yet only at run time do we detect (via surprising failure with ENOSYS) that the kernel is too old to support the function that we were led to believe would be available. Here, it wasn't that big a deal, but I can easily imagine this sort of mismatch leading to a more serious problem. It is fine to have a kernel *newer* than would be suggested by headers/libraries. Now you've seen why is risky to use one that is older. Unfortunately this is quite common for build machines... as it is easy to build any number of buildroots for any number of OS's. But since one cannot chroot into a new kernel, to build with new libraries/headers, the kernel remains inevitably older than that which the machine builds. The only other alternative I can think of is booting a virtual machine for each package build, which I imagine is probably too costly/painful to consider for koji... Outside of koji, speaking as a kernel developer, people DO boot older kernels on newer userlands -- particularly if they are having a problem with their hardware. So it is entirely possible that a run-time check for a newly-added syscall is the only way to make things work. :( That's what people had to do with sendfile(2) for a long time. I imagine most other newly-added Linux syscalls don't find their way into core daemons and utilities, so most people don't notice. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: IPv6 for Fedora services?
On 08/23/2009 06:59 PM, David JM Emmett wrote: A rather large ballache would also be ip6tables - I saw no mention in your post - thought I'd throw it out there also. Are you saying that IPv4 rules would need IPv6 counterparts, or something more? Jeff ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: IPv6 for Fedora services?
On 08/23/2009 04:50 PM, Matt Domsch wrote: The automatic Internet2 detection will need some help too, as right now the BGP tables I'm pulling from http://syslog.abilene.ucaid.edu/bgp/WASH/RIBS/ is only listing IPv4 addresses. neat :) didn't know about this. As for serving other content, if it's fronted by the proxy servers (e.g. web content), then it should naturally start working via the IPv6-enabled proxys. Testing will prove that out. Yep. Though I would prioritize A+ web setups below other tasks, since web content has the greatest possibility of meeting a misconfigured user, who cannot figure out what went wrong. For non-web content (git, cvs, ssh?), I believe this is mostly hosted in PHX, which at this point we don't believe has native IPv6. How can we go about requesting such in the colo? I presume this is something that Red Hat IS would have to ask for on our behalf. I'd much rather try to get native going, instead of dealing with 6to4 (the nearest 6to4 server is 10 hops and 60+ms away) or tunnels. Agreed... unless native IPv6 is estimated to be years away. Internal pushing at RH has yielded very little result... fedorapeople is at BU, which has some native IPv6 capability, but it's not clear they use it: http://www.mrp.net/IPv6_Survey.html As for DNS servers (serving DNS over IPv6), we have: ns1 is at serverbeach. Best googled estimates are probably by the end of 2009 ns2 is at ibiblio. That's the good news. ibiblio has been experimenting with IPv6 for years: http://theclassicalstation.org/press/2004_ipv6.shtml Also, another DNS issue: getting glue records served by the .org registrar. We'll need to know their native IPv6 capability before proceeding there. This is less critical, as most users are still doing their DNS lookups to an IPv4 DNS server at their ISP. But it would be nice. Technically this is true... but it is also true that most users are still doing IPv4 ;) I tend to look at DNS as a sooner rather than later hurdle, because that is the first link necessary to construct an all-IPv6 path to the destination servers. Jeff ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: IPv6 for Fedora services?
On 08/24/2009 01:17 AM, David JM Emmett wrote: On 24 Aug 2009, at 02:47, Jeff Garzik jgar...@pobox.com wrote: On 08/23/2009 06:59 PM, David JM Emmett wrote: A rather large ballache would also be ip6tables - I saw no mention in your post - thought I'd throw it out there also. Are you saying that IPv4 rules would need IPv6 counterparts, or something more? That is why ip6tables exists ;) Yes; I would hope that a Linux kernel developer who has worked extensively in network (me) and the entire infrastructure team knows this. Was trying to determine if your point is simply remember ipv6 rules, or something more detailed and explicit... Regards, Jeff P.S. Please don't top-post. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: IPv6 for fedora services?
On 08/16/2009 01:37 PM, Dennis Gilmore wrote: While this is the completely wrong list to ask something like this on. fedora- infrastructre list is the correct place. there is currently no plans to roll My apologies. I have just subscribed to this list, and will re-send my query there. It seemed to me that there was some relevance to fedora-devel, as we would need to get the IPv6-enabled technology in place, before the Fedora sysadmins can deploy it. out IPv6 our upstream providers do no provide IPv6 connectivity. we could look at using SIXXS or someone like it for ipv6 tunnels. but as of right now its not being actively worked on. We do need to look into it at some point however. some mirrors are available via ipv6 . it would be nice to have mirror lists available via it. some services i know dont support ipv6. Thanks, Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
IPv6 for Fedora services?
Is there any IPv6 plan for *.fedoraproject.org ? One plan chosen by projects (including wikimedia) is a staged rollout, like this: 1) enable IPv6 reachability and records for DNS servers 2) enable IPv6 for small-audience or developer-only services, such as cvs/svn/git services 3) enable IPv6 for primary services, such as public web Such staged rollouts attempt to balance the potential for service disruption due to end-user misconfiguration, with pushing technological progress foward. As of today, for months, the DNS root servers are reachable via IPv6 and have records. Any chance we could look at step #1 or #2 for Fedora? I am hoping that Fedora can be a leader rather than a follower in deploying this new technology. Jeff ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: IPv6 for Fedora services?
On 08/17/2009 10:01 AM, Mike McGrath wrote: On Mon, 17 Aug 2009, Jeff Garzik wrote: Is there any IPv6 plan for *.fedoraproject.org ? There is currently no plan. What needs to be done to create a plan, and move forward? Jeff ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
IPv6 for fedora services?
Is there any IPv6 plan for *.fedoraproject.org ? One plan that projects (including wikimedia) have chosen is a staged rollout, 1) enable IPv6 reachability and records for DNS servers 2) enable IPv6 for small-audience or developer-only services, such as cvs/svn/git services 3) enable IPv6 for primary services, such as public web Such staged rollouts attempt to balance the potential for service disruption due to end-user misconfiguration, with pushing technological progress foward. As of today, for months, the DNS root servers are reachable via IPv6 and have records. Any chance we could look at step #1 or #2 for Fedora? Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updates lacking descriptions
Richard W.M. Jones wrote: Now I agree that extending RPM to add metadata to mark the upstream changelog file or URL would be an excellent idea. It's a one-off change to specfiles and means that we don't need to write the same thing in every update - a win all round. Suggestions: %doc(changelog): ChangeLog.txt Changelog-URL: http://example.com/changes.html How would that work for changelogs stored in a git repository? Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
Lennart Poettering wrote: Doing digital grabbing of is very reliable these days. The analog path is just completely obsolete. I guess it's an open question why HDA touts multi-analog and hw mixing as modern features, then :) Modern hardware isn't all PCM either... Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
Lennart Poettering wrote: On Thu, 30.07.09 19:06, Jeff Garzik (jgar...@pobox.com) wrote: Lennart Poettering wrote: Doing digital grabbing of is very reliable these days. The analog path is just completely obsolete. I guess it's an open question why HDA touts multi-analog and hw mixing as modern features, then :) Oh does it? How about adding some references to this claim? Might be actually convincing then. http://www.intel.com/design/chipsets/hdaudio.htm Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
Lennart Poettering wrote: On Thu, 30.07.09 19:37, Jeff Garzik (jgar...@pobox.com) wrote: Lennart Poettering wrote: On Thu, 30.07.09 19:06, Jeff Garzik (jgar...@pobox.com) wrote: Lennart Poettering wrote: Doing digital grabbing of is very reliable these days. The analog path is just completely obsolete. I guess it's an open question why HDA touts multi-analog and hw mixing as modern features, then :) Oh does it? How about adding some references to this claim? Might be actually convincing then. http://www.intel.com/design/chipsets/hdaudio.htm Where do you see hardware mixing mentioned there? Or multi-analog? I certainly cannot see that mentioned directly or indirectly in any way on that page. Try the programmer's guide, for one. If you are going to whine about googling, don't expect to be spoonfed knowledge you should already know. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
Lennart Poettering wrote: On Wed, 29.07.09 09:47, Jeff Garzik (jgar...@pobox.com) wrote: mixing is certainly the smallest part of it. Plese don't forget that mixing is not exactly the most complex operation on earth. Please don't forget that hardware mixing... is more than just mixing. Modern audio hardware can offload sample rate conversion, attenuation, 3D processing, and other goodies. Interesting in which parallel universe you must be living. Modern audio hardware is usually locked to a specific sample rate, got rid of all mixer controls by going to 24bit and letting the CPU attenuate using the 8bit extra headroom. And 3d processing, and other goodies aren't avilable in newer hw designs anymore either. In fact haven't been available since quite some time in any design anymore. (With the excption of those creative cards) bzzt, sorry, thanks for playing. The world has more to offer than 2005-era motherboard audio locked at 48K. If you keeping bringing up Microsoft as a shining example, it might behoove you examine how DirectSound has evolved for modern audio. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
Adam Williamson wrote: On Wed, 2009-07-29 at 08:51 -0500, Dr. Diesel wrote: This is supported by the zillions of forum messages asking how to fix or remove pulseaudio. Not to mention the billion post thread here on devel. In my experience, this is a more common pattern: $POOR_NEWBIE: I have a problem with audio. $RANDOM_'HELPFUL'_PERSON: Oh, you need to remove PulseAudio! Removing PA is far too often jumped on as the 'obvious' fix for resolving any kind of audio problem whatsoever. Even if it had nothing to do with PA in the first place. And? Random helpful person quickly becomes ignored person, if the advice fails to work. Problem is... removing or disabling PA often -does- solve a problem. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 mass rebuild status
Jesse Keating wrote: http://jkeating.fedorapeople.org/failed-f12-rebuilds.html chunkd should be fixed as soon as wait-repo permits :) Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
Adam Williamson wrote: On Sun, 2009-07-26 at 13:50 +0200, Ralf Corsepius wrote: The worst about it: Unless rel-eng finally releases updated Fedroa 11 isos, the shameful situation about F11 installs will not see much improvements, because anaconda being FIXED UPSTREAM/RAWHIDE doesn't help FC11 users. That would be why we've been rolling updates.img files for the most serious anaconda issues, and documenting them on the Common Issues page. IMO kernel issues should influence installer image updates, too... Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
Rahul Sundaram wrote: On 07/28/2009 01:11 AM, David Cantrell wrote: The problem here is when do you stop generating new media to fix bugs in F-11's installer and start working on F-12? Never? A week after F-11 GA? What determines if an installer bug gets a fix in F-11 vs. not? It's a gigantic waste of time for the installer team to release updates to F-11's installer. We can address those bugs in rawhide and have them fixed in the next stable release. Can you push the fixes as updates for Anaconda in Fedora 11? Fedora Unity isn't the only one doing updated images. It is increasingly becoming useful to have updated Anaconda packages available within the official repository as updates. If the Anaconda team doesn't want to do it, hand over that work to Jeroen van Meeuwen. He has already volunteered to take care of it and since he is doing it anyway for the unity images, his work could benefit more people. The only thing you got to do is give him commit access. Honestly, I always thought Fedora install images should be regenerated far more frequently. I think back to my days as a Solaris sysadmin in the late 90's, where ordering the latest media kit (CD-ROM) from Sun meant I got a fresh installer, fresh kernel, and all recommended patches. Even in the face of known Linux kernel bugs, people always seemed reluctant to regenerate the Fedora install images. I think Fedora would better serve its users by being much more willing to update install images after initial release. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 Alpha Blocker Bug Meeting: Friday 2009-07-24
Adam Williamson wrote: What: F12Alpha Blocker bug meeting (https://bugzilla.redhat.com/show_bug.cgi?id=f12alpha) When: Friday, 2009-07-24 @ 15:00 UTC (11 AM EDT) Where: #fedora-bugzappers Yes, ladies and gentlemen, tomorrow marks the second blocker bug review meeting for Fedora 12 Alpha. Please do come along to provide your insight and wisdom as we go through the list of bugs blocking the Alpha release (and probably do a quick sweep of those blocking the final release, too). If you are aware of any bugs you think should block the Alpha, please do set them to block 'F12Alpha' - and come to the meeting, if you can, to chime in when we discuss them. I can't come to the meeting, but I just added this one: https://bugzilla.redhat.com/show_bug.cgi?id=512377 Upgrading nfs-utils disrupts ALL active NFS clients, and further, prevents them from re-connecting after the upgrade. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 Alpha Blocker Bug Meeting: Friday 2009-07-24
Adam Williamson wrote: On Thu, 2009-07-23 at 17:53 -0400, Jeff Garzik wrote: Adam Williamson wrote: What: F12Alpha Blocker bug meeting (https://bugzilla.redhat.com/show_bug.cgi?id=f12alpha) When: Friday, 2009-07-24 @ 15:00 UTC (11 AM EDT) Where: #fedora-bugzappers Yes, ladies and gentlemen, tomorrow marks the second blocker bug review meeting for Fedora 12 Alpha. Please do come along to provide your insight and wisdom as we go through the list of bugs blocking the Alpha release (and probably do a quick sweep of those blocking the final release, too). If you are aware of any bugs you think should block the Alpha, please do set them to block 'F12Alpha' - and come to the meeting, if you can, to chime in when we discuss them. I can't come to the meeting, but I just added this one: https://bugzilla.redhat.com/show_bug.cgi?id=512377 Upgrading nfs-utils disrupts ALL active NFS clients, and further, prevents them from re-connecting after the upgrade. Going on strict criteria, this probably isn't an Alpha blocker (as it doesn't stop the critical functions of the system working). It certainly looks like a final release blocker, though. Anyway, I'll leave it on the list and we'll discuss it at the meeting tomorrow and take appropriate action. Thanks for contributing to the process! [tone note: not a sarcastic question...] What are critical functions of the system? I'd say access to one's filesystem is quite critical. :) Either way things go... thanks! Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 Alpha Blocker Bug Meeting: Friday 2009-07-24
Jesse Keating wrote: On Thu, 2009-07-23 at 18:12 -0400, Jeff Garzik wrote: [tone note: not a sarcastic question...] What are critical functions of the system? I'd say access to one's filesystem is quite critical. :) Either way things go... thanks! Outside the less popular cases of nfs mounted / or /home, you do not need access to NFS mounted filesystems in order to login and update your system. Agreed -- though the consequences are quite severe in those cases. https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal speaks to some of what we consider the critical path. Thanks! Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
koji buildroot inconsistencies? chain-build does not fix...
Fighting against in-buildroot-or-not? dependencies ;-) I have three packages, cld depends: none chunkd depends: cld tabled depends: cld chunkd 1) I updated all three packages in cvs devel (rawhide), and tagged them. 2) 'make build' on cld succeeded http://koji.fedoraproject.org/koji/taskinfo?taskID=1490075 3) Waited 45 minutes. 4) 'make build' on chunkd failed, because it was building against an outdated cld package. http://koji.fedoraproject.org/koji/taskinfo?taskID=1490259 5) So, I try chain-build, which is supposed to get dependencies right: $ cd /spare/repo/fedora/tabled/devel# Fedora CVS for tabled $ make chain-build CHAIN='cld : chunkd :' this fails, because cld is already built (step #2). http://koji.fedoraproject.org/koji/taskinfo?taskID=1490341 6) So, ok, I try chain-build without cld, since koji tells me it is already built: $ make chain-build CHAIN='chunkd :' this fails, for the same reason as step #4 -- outdated cld. http://koji.fedoraproject.org/koji/taskinfo?taskID=1490371 If I build assuming up-to-date cld is in rawhide, it fails. If I build NOT assuming up-to-date cld in rawhide, it fails. How to fix this paradox? I guess this is punishment for not using chain-build from the beginning... Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
review req: remaining 2 cloud computing daemons (simple, I promise)
My little cloud computing project has three small server daemons, plus client libs, ready for Fedora. Thanks to Mike Bonnet, the first package of three, cld, is now in rawhide (BZ# 511934). The remaining two packages, chunkd (BZ# 511941) and tabled (BZ# 511944), are practically the same as cld in package structure, build system, etc. They are all small packages, around 10k LOC each IIRC. I hope all that means it would be a quick and easy review for... some helpful volunteer like you, gentle reader! :) Can anyone help me out? Also, as mentioned in another thread, tabled requires both chunkd and cld in rawhide simply to build in koji. Clearing that build dependency would be most helpful. project homepage: http://hail.wiki.kernel.org/ cld (done): https://bugzilla.redhat.com/show_bug.cgi?id=511938 chunkd: https://bugzilla.redhat.com/show_bug.cgi?id=511941 tabled: https://bugzilla.redhat.com/show_bug.cgi?id=511944 Thanks, Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: koji build dependencies in cloud computing project?
Pete Zaitcev wrote: On Thu, 16 Jul 2009 16:12:30 -0500, Dennis Gilmore den...@ausil.us wrote: On Thursday 16 July 2009 03:58:37 pm Jeff Garzik wrote: cld and chunkd built just fine in koji, but tabled does not: it BuildRequires both cld and chunkd. Its not possible you can only build against what is released in fedora Do I understand it right that CLD has to get into Rawhide first, then? And once it's established there, chunk and tabled can move in? Until you submit your next batch of chunkd work upstream, both cld and chunkd are independent of any other dependencies... :) tabled can move in after those two, it appears. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
