Re: yum-presto occasionally goes into eternal loop looking for deltas
On Thu, 7 Jan 2010, James Antill wrote:
On Thu, 2010-01-07 at 21:19 +0200, Jonathan Dieter wrote:
On Thu, 2010-01-07 at 20:44 +0200, Pekka Pietikainen wrote:
Presto is one of the best things ever, but occasionally it ends up not
finding the delta files from any of the mirrors in the mirror list and just
loops through them without making any progress. --disablepresto works
a-ok, I think yum clean all; yum update also did the trick once.
Still, this can probably be made a lot better. It shouldn't do that even if the
mirrors
are out-of-sync. Maybe add some logic that just disables
presto if the deltas are nowhere to be found after a few attempts? Anyone
else even see this happen?
Yeah, see https://bugzilla.redhat.com/show_bug.cgi?id=540140. To
summarize, the problem is that new updates have been pushed to the
server between the time you loaded primary.sqlite and prestodelta.xml.
When you run 'yum clean metadata' or 'yum clean all' it removes the
outdated cached primary.sqlite and downloads the newer version.
The bug has been closed as WONTFIX because there have only been a few
reports; I wouldn't mind revisiting that decision if someone has a
clever way of fixing it. (And I'm not convinced that checking n mirrors
and then giving up is the solution.)
The plugin could require yum = 3.2.25, and then do something like (in
config or prereposetup):
for repo in repos:
repo.mdpolicy.append('prestodelta')
...which would auto download presto MD when yum gets new repomd/primary.
People might complain though :) ... another kind of fix would be for the
plugin to call .cleanExpireCache() if the MD fails to download.
The nice server side fix is to keep around more than one complete set
of MD (possible now we have unique MD filenames), so there would have to
be two updates within the client side cache timeout. But I'm not sure
how easy that is.
But not all the drpms would be kept so if a largish number of them
changed
-sv
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: End of days?
On Thu, 7 Jan 2010, Tony Nelson wrote: On 10-01-06 17:54:10, Robert Relyea wrote: On 01/06/2010 01:43 PM, Orion Poplawski wrote: [or...@orca fedora/devel]$ ls */dead.package | wc -l 666 We're ok. The original number may have been 616: http://www.csad.ox.ac.uk/POxy/beast616.htm No, that's merely the most common correction by those with a little knowledge. 666 was the number for Neron Ceaser, while 616 was for Nero Ceaser (latinized form of name). Of course, the reference was actually to Domitian, who was Emperor when the Temple in Jerusalem was destroyed (again) after yet another revolt by the Jews. Mentioning the current Emperor in an unflattering way would get one killed, hence the code. If you want to continue this discussion please do so offlist. thanks, -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Increase my quota size
On Wed, 6 Jan 2010, Frederic Hornain wrote: Dear *, As I use http://fhornain.fedorapeople.org/ as repository for the packages I create, I would need a little bit more space. So is it possible to increase my quota ? your quota has been increased. -sv ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: ABRT considered painful
On Sat, 2 Jan 2010, Jan Kratochvil wrote: On Sat, 02 Jan 2010 13:34:47 +0100, drago01 wrote: On Sat, Jan 2, 2010 at 1:25 PM, Jan Kratochvil jan.kratoch...@redhat.com wrote: On Sat, 02 Jan 2010 11:53:28 +0100, Jiri Moskovcak wrote: the only problem I know about is when some of the enabled repositories is down - then the yum fails to download debuginfo even if it's in working directory and there is not much ABRT can do about this. ... Well this yum issue is by design .. reporting it does not have much sense because Seth do not want to change/fix it. Found this flameware at this open Bug: https://bugzilla.redhat.com/show_bug.cgi?id=528014 What flames? I said no and that - if abrt wants to do otherwise they can use the yum api to do so. How is that a flame? -sv -- 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 Tue, 22 Dec 2009, Jarod Wilson wrote: On 12/22/09 2:45 AM, Kevin Kofler wrote: Jesse Keating wrote: Nobody should be able to create any branches that do not start with private-. I really don't see the point of this, why can't we just allow any branch name that isn't a reserved name (master or F-[0-9]+)? We'll make sure that the buildsystem will not allow any official (non-scratch) builds to happen from a private-* branch. And as I wrote before, I don't like this at all, it's a regression from our current workflow Define our. In my personal opinion, Jesse is spot-on, we should NOT allow official builds from a private branch. That's just insane. Scratch builds are fine. Official builds need to be from the main branch, or a common non-private branch (such as the kernel has done for maintaining both e.g. 2.6.29 and 2.6.30 trees simultaneously for F10). If you get eaten by raptors, you can't expect another maintainer to come in after you and have to dig around for a private branch to update a build. FWIW - I agree with both jesse and jarod. Official builds are from main branch. Anything built anywhere else will never be official. -sv -- 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 Wed, 16 Dec 2009, Matthew Garrett wrote: On Wed, Dec 16, 2009 at 12:30:11AM +, Paul Jakma wrote: On Tue, 15 Dec 2009, Matthew Garrett wrote: And the remaining 0.1% of the work is probably the other 99.9% of the time. I think you massively underestimate the number of corner cases present in an utterly untested configuration. My data-point is that I ran an x86-64 kernel on i386 F10 for a few months until I got tired of yum not being able to update kernel packages. The kernel side apparently works fine AFAICT. The .1% is yum. It works for me is a poor standard of support. and if running an x86_64 kernel on an i386 install is something we want to do then we can make some changes to make that work. But complaining that yum doesn't work for something it was never designed to work for is a bit silly. -sv My this camel is not a very fast swimmer. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Wed, 16 Dec 2009, Nathanael D. Noblet wrote: So again today, I see some updates two of which require a full system reboot. nfs-utils and ibus-rawcode. My system seriously needs to be shut down for those to be properly updated? This is what I don't get. nfs-utils never got a system reboot before, it doesn't get one on RHEL/Centos boxes... What requires a reboot here? Again, I don't want the tone of this email to come off as anger, rude or whatever, mainly I'm wondering why so many packages require a reboot, why isn't nfs-utils just restarting any services it has or that depend on it if needed? Is that not reliable? you're an experienced user? You're comfortable knowing what does and what does not require a reboot? Then why are you using PK? Disable pk and do the updates directly via yum. Bam - no more requests to reboot. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Wed, 16 Dec 2009, Peter Jones wrote: On 12/16/2009 11:43 AM, Seth Vidal wrote: you're an experienced user? You're comfortable knowing what does and what does not require a reboot? Then why are you using PK? Disable pk and do the updates directly via yum. Bam - no more requests to reboot. I get what you're saying, and it's kindof a fair point, but there's also some utility to having the system automatically, proactively notify you of updates. And you can do that. Just don't have pk DO the update. There are lots of ways to get notifications of updates not using PK in the system. And again, we're not talking about for the default everyday user. we're talking about the experienced user who is comfortable knowing what does and does not need a reboot. All I'm saying is - we've not taken away any option, the experienced user can do what they want. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Wed, 16 Dec 2009, Chris Adams wrote: Once upon a time, Seth Vidal skvi...@fedoraproject.org said: we're talking about the experienced user who is comfortable knowing what does and does not need a reboot. It seems though that there is a problem with how the needs a reboot option is set (and if that is the case, it should be addressed). For example, in the nfs-utils case, what happened to having the %post scriptlet do service foo condrestart? Is it impossible to restart the daemons? well nfs restarts have never been likely to work if something is mounted iirc. but I'm not the nfs expert here - maybe steve dickson can better answer this. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Wed, 16 Dec 2009, Nathanael D. Noblet wrote: Maybe this is a feature that needs to be addressed in the rpm layer or something so that upgrades can have multiple effects with regards to needing a reboot. I'm not sure how PK gets the request to reboot from a package, but I'm wondering about it. It doesn't get it from the pkg. It uses the updateinfo.xml metadata that is generated by our update processing system that is called 'bodhi'. You can see this data using the yum-security plugin. seems like a package basically has complex upgrade issues, so we reboot. Are there other tags packages can have other than reboot? Should there be? etc etc.. No. I am an advanced user, and manage a handful of servers and workstations, so yes I don't have to reboot. I'm just wondering about the reboot 'feature' usage patterns I'm seeing. And again. PK is not designed for you. The 'reboot often' solution is not FOR you. I said this earlier on another subject but you shouldn't be shocked that camels are slow swimmers. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Wed, 16 Dec 2009, nodata wrote: we're talking about the experienced user who is comfortable knowing what does and does not need a reboot. All I'm saying is - we've not taken away any option, the experienced user can do what they want. -sv True, but the default should be sensible. And the default is sensible for the inexperienced user: Don't try to explain to the user how to restart the apps individually, tell them to bounce the box and it will be the right version when it comes back. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Wed, 16 Dec 2009, Nathanael D. Noblet wrote: seems like a package basically has complex upgrade issues, so we reboot. Are there other tags packages can have other than reboot? Should there be? etc etc.. No. The reason for this is that PKs target audience is not someone like me, and as such no need to provide different messages per package? No, the reason for this is there is not more to go on, yet. I would love to require more detailed info on the update including if it is an important/trivial/security/packaging/upstream-update or what not fix. Hands are needed to help advance this. Care to lend one? And again. PK is not designed for you. The 'reboot often' solution is not FOR you. I said this earlier on another subject but you shouldn't be shocked that camels are slow swimmers. So basically, PK is designed for the non-experienced users, as such everything it does is dumbed down, and experienced users should just ignore it, using other tools to keep their system up to date. If what the experienced user wants to do is not something that PK can do or can be configured to do then, yes, disable it and move along. Hell, same thing is true of yum. If you really know what you're doing and yum is in your way then stop using it. So one last question then, in the case of nfs-utils, (ignoring for now any nfs specific restart/condrestart issues). The packaging guidlines will continue to require that a post update script does what is sensible for an update, and not just depend on the admin rebooting their server? the post scripts do what is sensible, on many occasions restarting the daemon will not ensure that the new sw is in use and in other occasions there is no graceful way to restart. so your options are: 1. don't restart but ask the user to 2. restart and drop whatever connections are active. neither are great. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Wed, 16 Dec 2009, nodata wrote: Am 2009-12-16 18:21, schrieb Seth Vidal: On Wed, 16 Dec 2009, nodata wrote: we're talking about the experienced user who is comfortable knowing what does and does not need a reboot. All I'm saying is - we've not taken away any option, the experienced user can do what they want. -sv True, but the default should be sensible. And the default is sensible for the inexperienced user: Don't try to explain to the user how to restart the apps individually, tell them to bounce the box and it will be the right version when it comes back. -sv On the other hand I think requiring more reboots than Windows is a bad thing... Then I can think of a couple of solutions to this problem: 1. Have fewer update pushes per release - this is something I'm actively advocating and I think is possible 2. Match up more updates to a specific running app so we can see if the reboot is really necessary at all. - something else I've wrriten some code in support of. How would you like to help in these goals? -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Wed, 16 Dec 2009, Nathanael D. Noblet wrote: Hands are needed to help advance this. Care to lend one? Yes. I'm attempting to become more involved. I've submitted my first package, and am going through the review process. That doesn't help in this particular case, but I am not complaining for the sake of complaining. I want to help. I fully realize what I use daily for work is the result of many people like you who build this stuff. Thus my desire to become part of it. What can I do here? How much python do you know? We need some time spent on the updateinfo.xml and what information we provide there and tying this in with what info is required from packagers submitting updates to their pkgs. Another good angle to approach is to talk to the folks in fedora-qa and see where they can use a hand. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Tue, 15 Dec 2009, Nathanael D. Noblet wrote: Hello, I feel like there are an increasing number of packages requiring a system reboot. I'm wondering why. The following updates were installed today, and required a full system reboot. I can't seem to find any package in the list that I can conceivably see requiring a reboot, is it that PK doesn't have the concept of X logout vs reboot? Is it a bug in the packaging or PK or is there anything I can do/file to improve the situation? Dec 15 09:07:21 Updated: glib2-2.22.3-1.fc12.x86_64 Dec 15 09:07:23 Updated: mysql-libs-5.1.40-1.fc12.x86_64 Dec 15 09:07:23 Updated: gpm-libs-1.20.6-9.fc12.x86_64 Dec 15 09:07:25 Updated: mysql-5.1.40-1.fc12.x86_64 Dec 15 09:07:28 Updated: PyQt4-4.6.2-5.fc12.x86_64 Dec 15 09:07:32 Updated: mysql-server-5.1.40-1.fc12.x86_64 Dec 15 09:07:34 Updated: gpm-1.20.6-9.fc12.x86_64 Dec 15 09:07:37 Updated: 1:tk-8.5.7-3.fc12.x86_64 Dec 15 09:07:37 Updated: mpfr-2.4.1-5.fc12.x86_64 Dec 15 09:07:39 Updated: foomatic-4.0.3-5.fc12.x86_64 Dec 15 09:07:40 Updated: mysql-embedded-5.1.40-1.fc12.x86_64 Dec 15 09:07:41 Updated: glib2-2.22.3-1.fc12.i686 Dec 15 09:07:45 Updated: gtk2-2.18.4-3.fc12.x86_64 Dec 15 09:07:58 Updated: 1:gdm-2.28.1-25.fc12.x86_64 Dec 15 09:07:58 Updated: ibus-libs-1.2.0.20091204-2.fc12.x86_64 Dec 15 09:07:59 Updated: imsettings-libs-0.107.4-4.fc12.x86_64 Dec 15 09:08:02 Updated: glib2-devel-2.22.3-1.fc12.x86_64 Dec 15 09:08:07 Updated: yelp-2.28.1-1.fc12.x86_64 Dec 15 09:08:10 Updated: f-spot-0.6.1.5-1.fc12.x86_64 Dec 15 09:08:13 Updated: 1:xscreensaver-base-5.10-4.fc12.x86_64 Dec 15 09:08:13 Updated: 1:xscreensaver-gl-base-5.10-4.fc12.x86_64 Dec 15 09:08:16 Updated: gtk2-devel-2.18.4-3.fc12.x86_64 Dec 15 09:08:25 Updated: totem-2.28.4-1.fc12.x86_64 Dec 15 09:08:25 Updated: totem-nautilus-2.28.4-1.fc12.x86_64 Dec 15 09:08:27 Updated: 1:xscreensaver-gl-extras-5.10-4.fc12.x86_64 Dec 15 09:08:29 Updated: 1:xscreensaver-extras-5.10-4.fc12.x86_64 Dec 15 09:08:34 Updated: imsettings-0.107.4-4.fc12.x86_64 Dec 15 09:08:34 Updated: 1:gdm-user-switch-applet-2.28.1-25.fc12.x86_64 Dec 15 09:08:35 Updated: 1:gdm-plugin-fingerprint-2.28.1-25.fc12.x86_64 Dec 15 09:08:35 Updated: totem-mozplugin-2.28.4-1.fc12.x86_64 Dec 15 09:08:37 Updated: python-reportlab-2.3-1.fc12.x86_64 Dec 15 09:08:38 Updated: jna-3.2.4-1.fc12.x86_64 Dec 15 09:08:38 Updated: memcached-1.4.4-1.fc12.x86_64 Dec 15 09:08:38 Updated: less-436-3.fc12.x86_64 Dec 15 09:08:40 Updated: cscope-15.6-6.fc12.x86_64 Dec 15 09:08:40 Updated: xorg-x11-drv-mouse-1.5.0-1.fc12.x86_64 Dec 15 09:08:40 Updated: f-spot-screensaver-0.6.1.5-1.fc12.x86_64 Dec 15 09:08:46 Updated: gtk2-devel-docs-2.18.4-3.fc12.x86_64 Dec 15 09:08:46 Updated: gpm-devel-1.20.6-9.fc12.x86_64 Dec 15 09:08:46 Updated: liveusb-creator-3.9-1.fc12.noarch Dec 15 09:08:48 Updated: mysql-devel-5.1.40-1.fc12.x86_64 Dec 15 09:08:53 Updated: etoys-4.0.2339-1.fc12.noarch Dec 15 09:08:59 Updated: ibus-1.2.0.20091204-2.fc12.x86_64 Dec 15 09:08:59 Updated: ibus-gtk-1.2.0.20091204-2.fc12.x86_64 Wouldn't it be sufficient to logout? Is it a bug? Does gdm entirely restart when you logout? I don't believe so. I suspect you get the same result by killing X then going back to that runlevel but for many many many users a reboot is going to be less error-prone. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Tue, 15 Dec 2009, Nathanael D. Noblet wrote: On 12/15/2009 09:54 AM, Seth Vidal wrote: Does gdm entirely restart when you logout? I don't believe so. I suspect you get the same result by killing X then going back to that runlevel but for many many many users a reboot is going to be less error-prone. Isn't there gdm-restart for that purpose? I don't really know, but I'm just confused as to why a program that lets me login requires a reboot... I *really* don't want to sound whiny or anything like that, or be one of those that compare us to windows... but one of my favorite things from years ago was that I only had to reboot with a new kernel. Now I feel like I reboot every update. I mean, even the ibus stuff was stating I needed a reboot. As far as I know that is used for alternative language input, which I don't use, fair enough it doesn't know that. But what about it needs a reboot? I'm also curious why gdm is still running once I've logged in. I see the user-switch stuff but I'm just wondering. I mean rebooting isn't the end of the world but man it sure happens a lot now I don't have a good answer. You might want to ask on the fedora-desktop-list and/or in a bug for that component. I was just trying to explain the specific behavior you saw. Now, having said that - how would you feel if the updater stopped you before it ran and said you're running an app I'm trying to update, please close the app so I can update it. Would that be a pain or ok? -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
On Tue, 15 Dec 2009, Richard Hughes wrote: 2009/12/15 Seth Vidal skvi...@fedoraproject.org: Now, having said that - how would you feel if the updater stopped you before it ran and said you're running an app I'm trying to update, please close the app so I can update it. Would that be a pain or ok? That's exactly the PackageKit functionality I've added for packages like firefox, that explode internally when they get updated. The trick it to offer to close them down, and bring them back when done. this is what colin and I talked about at fudcon in toronto. I just added some code to yum so it returns to you a list of all pkgs on the system that own a file that is currently open/used in a running process. should make that part of your lookup easier. YumBase.rpmdb.return_running_packages() -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mea Culpa and Apology
On Tue, 15 Dec 2009, Stephen John Smoogen wrote: One of the big problems with the move from PHX1 to PHX2 has been the renaming of hosts. This was a big mistake on my part and made life very difficult for the Fedora people who worked over the weekend to get it working and running into constant headaches. I apologize and owe everyone a lot. Stephen, don't sweat it too much. It happens to everyone. In this case the lesson is: If you are making a big change, do not add any other big changes (or small changes) if you can avoid it. All change is bad. More change is MORE bad. Thanks, -sv ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Major dns issues
On Mon, 14 Dec 2009, Toshio Kuratomi wrote: On Mon, Dec 14, 2009 at 09:27:18AM -0600, Mike McGrath wrote: So I woke up today and we're still having dns issues on at least one of my hosts. Could everyone that has access please do a dig fedoraproject.org on all their hosts and tell me if any of them cannot resolve? Working from three US sites I have access to. -Toshio Not working from slicehost's nameservers. dig @67.207.128.4 fedoraproject.org ; DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5 @67.207.128.4 fedoraproject.org ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 9804 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;fedoraproject.org. IN A ;; Query time: 1 msec ;; SERVER: 67.207.128.4#53(67.207.128.4) ;; WHEN: Mon Dec 14 11:16:03 2009 ;; MSG SIZE rcvd: 35 -sv ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Voting app offline time?
On Mon, 14 Dec 2009, Mike McGrath wrote: On Mon, 14 Dec 2009, Paul W. Frields wrote: On Mon, Dec 14, 2009 at 09:51:09AM -0500, Paul W. Frields wrote: On Tue, Dec 15, 2009 at 12:14:46AM +1000, Nigel Jones wrote: We had some the original DB downtime ~1-2 hours, then downtime due to fas not been around ~1-2 hours, plus a DB downtime of ~2-3 hours and a VPN downtime of about an hour. All in all, I think it meets the 1 day extension criteria. Yup, top-side estimates add up to 8 hours, so we should extend the voting by one day as agreed. Make it so! ;-) And... after making the announcement, it's come to light that there are some DNS issues outstanding which could potentially have presented a problem to voters. This one's been difficult to confirm. We know there were some issues that have been resolved and so far slicehost is the only one having issues, which is almost certainly on us but so far no one has actually complained about any issues which is surprising to me but does point to a not widly spread issue. It could also mean they are trying to email about the problems but cannot b/c their mailer won't let them email to a domain they cannot find. :( This is how I noticed the problem this morning from slicehost . -sbv ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Help wanted with dist-cvs to git conversion
On Fri, 11 Dec 2009, Lubomir Rintel wrote: A big -1 for this. Your A lot is in fact a tiny fraction and for some of us an e-mail address is important mean for identifying an user (Oh, this is John Doe of Canonical, ...). I use mine exclusively and I think referring to the generic address makes life a lot easier. And let me put it this way: if fedora decides to post my non @fp.o address somewhere, like in git entries, I'm going to be extremely pissed off about it. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help wanted with dist-cvs to git conversion
On Fri, 11 Dec 2009, Mathieu Bridon (bochecha) wrote: On Fri, Dec 11, 2009 at 14:12, Seth Vidal skvi...@fedoraproject.org wrote: On Fri, 11 Dec 2009, Lubomir Rintel wrote: A big -1 for this. Your A lot is in fact a tiny fraction and for some of us an e-mail address is important mean for identifying an user (Oh, this is John Doe of Canonical, ...). I use mine exclusively and I think referring to the generic address makes life a lot easier. And let me put it this way: if fedora decides to post my non @fp.o address somewhere, like in git entries, I'm going to be extremely pissed off about it. Isn't it already posted in IRC when someone enters the .fasinfo skvidal command ? That's not in every google-retrievable gitweb interface, though. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide and tagging requests
On Thu, 10 Dec 2009, Jesse Keating wrote: On Thu, 2009-12-10 at 10:56 +0200, Panu Matilainen wrote: Hmm, looking at the traceback at the end of http://kojipkgs.fedoraproject.org/mash/rawhide-20091209/logs/mash.log it's not at all clear whether this is rpm-python bustage or yum... the last good compose (from 20091203) was before this went in: * Thu Dec 3 2009 Seth Vidal skvidal at fedoraproject.org - 3.2.25-2 - rebuild yum with latest HEAD patch - add rpmdb caching patch james wrote to see if it breaks everyone :) ...and the rpmdb caching patch does touch the area where it's crashing. Can you try a compose with yum tagged down to 3.2.25-1 just to cut down on the moving parts involved? Alternatively a reproducer that doesn't involve processing the entire rawhide would be helpful :) Yeah, it could totally be yum, I didn't do much investigation into it. Just didn't have it in me as I'm stranded at an airport over night. Looking at the rpmdb caching patch I'm not sure how it could be that. The parsing of local pkgs (what createrepo does) doesn't hit the rpmdb. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide and tagging requests
On Thu, 10 Dec 2009, Panu Matilainen wrote:
Yup, but this isn't createrepo crashing (the earlier one was):
2009-12-09 20:11:04 mash: createrepo: finished
/mnt/koji/mash/rawhide-20091209/development/x86_64/os/
2009-12-09 20:11:05 mash: Resolving multilib for arch x86_64 using method
devel
2009-12-09 20:11:05 mash: Waiting for depsolve and createrepo to finish...
2009-12-09 20:21:28 mash: Resolving depenencies for arch x86_64
Traceback (most recent call last):
File /usr/bin/mash, line 96, in module
main()
File /usr/bin/mash, line 84, in main
rc = themash.doMultilib()
File /usr/lib/python2.6/site-packages/mash/__init__.py, line 538, in
doMultilib
pid = self.doDepSolveAndMultilib(arch, repocache)
File /usr/lib/python2.6/site-packages/mash/__init__.py, line 511, in
doDepSolveAndMultilib
(rc, errors) = yumbase.resolveDeps()
File /usr/lib/python2.6/site-packages/yum/depsolve.py, line 718, in
resolveDeps
for po, dep in self._checkFileRequires():
File /usr/lib/python2.6/site-packages/yum/depsolve.py, line 1012, in
_checkFileRequires
po = self.getInstalledPackageObject(pkgtup)
File /usr/lib/python2.6/site-packages/yum/__init__.py, line 2421, in
getInstalledPackageObject
raise Errors.RpmDBError, _('Package tuple %s could not be found in
rpmdb') % str(pkgtup)
yum.Errors.RpmDBError: Package tuple ('clamav-scanner-upstart', 'noarch',
'0', '0.95.3', '1301.fc13') could not be found in rpmdb
My mistake - I thought we were talking about the earlier
traceback. Yes, the above looks like it could be caching.
I'll see what I can do.
-sv
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum doesn't like installonly_limit=1?
On Thu, 10 Dec 2009, Rajeesh K Nambiar wrote: On 12/10/09, James Antill ja...@fedoraproject.org wrote: On Thu, 2009-12-10 at 18:00 +0530, Rajeesh K Nambiar wrote: I changed the installonly_limit to 1 from the default value 3 in /etc/yum.conf, and yum blows up. # yum search boinc Loaded plugins: presto, refresh-packagekit Options Error: Error parsing '1': out of range integer value This is an error message, not what I'd usually term blows up. I mean - can't install anything, can't search a package. It took me a while to realize that the change made to the config file caused it as I tried to use yum again after couple of days. The message should include what option is not able to be parsed. I'll fix it up. thanks, -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Help wanted with dist-cvs to git conversion
On Thu, 10 Dec 2009, Jesse Keating wrote: I'm currently playing with a utility called parsecvs to convert our cvs stuff into git. This utility can also translate the raw usernames that CVS has into more useful names+email addresses that you'd typically get out of git. But to make this conversion it needs a translation file. It would be really helpful if somebody could generate a file for me that is in the format of: username=firstname lastname email eg: jkeating=Jesse Keating jkeat...@fedoraproject.org notting=Bill Nottingham nott...@fedoraproject.org For the initial testing, just giving every user a @feodraproject.org domain would be sufficient, however we should have a discussion about whether to use this email address or to use the user's real email address. I just did this on fedorapeople.org not against fas but I suspect that's the same set of users. #!/usr/bin/python -tt import pwd for pw in pwd.getpwall(): if pw.pw_uid 1: continue msg='%s=%s %...@fedoraproject.org' % (pw.pw_name, pw.pw_gecos, pw.pw_name) print msg the file with these contents is in my homedir on fedorapeople.org as: wacky-list-for-git if you want me to do it directly talking to fas I'll do it in the morning. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Outage Notification - date -d '2009-12-11 02:00:00 UTC'
On Thu, 10 Dec 2009, Darren VanBuren wrote: No, I mean it didn't get executed. It's not supposed to get executed. By cutting and pasting that command you get the output for YOUR local timezone. -sv ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Promoting i386 version over x86_64?
On Wed, 9 Dec 2009, Ralf Corsepius wrote: On 12/09/2009 04:14 PM, James Antill wrote: On Wed, 2009-12-09 at 15:26 +0100, Ralf Corsepius wrote: So, yeh, if _you_ want to support slower machines Well, I do not want to, I can't avoid to ... ... _you_ will have to do the work, you might get help from the community but just ranting on f-d-l Everyone should solve my problems is unlikely to actually help. IMO. There is an easier solution: Stop using/promoting/advertising Fedora and switch to a different distro ... okay, for you, that sounds like it may be the best option. You are obviously unhappy with fedora. We've appreciated your constructive contributions but if you are no longer interested in working on/with fedora, then we wish you well in your endeavors. It would be most polite to officially orphan your packages before you go. Thanks and good luck in the future. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum download estimates and stalls
On Wed, 9 Dec 2009, Richard W.M. Jones wrote: I don't want to make unfair comparisons to the famous bug in Windows Vista[1], but it seems as if when a yum download stalls, then the estimates can start to look a little large: rawhide/primar 20% [- ] 0.0 B/s | 2.5 MB 2046434610655583470384211558:24 ETA What ver of python-urlgrabber do you have installed? And there is a patch posted I've not merged yet, mainly b/c I was out of the world for the weekend. -sv -- 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 Wed, 9 Dec 2009, Ville Skyttä wrote: On Wednesday 09 December 2009, Ralf Corsepius wrote: On 12/08/2009 09:26 PM, Ville Skyttä wrote: These probably aren't things to be generally overly concerned about though, ... try a yum update over GSM or over a modem and you'll very soon experience what I am talking about. Been there, done that occasionally. Scenarios like that just don't happen to be part of what I meant by generally. But I'd have nothing against purifying x86_64 repos and instructing people who need something from ix86 repos to enable them as well. I suppose this is something PackageKit could even suggest on demand. Anyway I also suppose that if it was this simple, it would have been done already. if you want to purify x86_64 you can always add: exclude=*.i[3456]86 to your yum.conf under [main] -sv -- 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 Wed, 9 Dec 2009, Chris Adams wrote: Once upon a time, Ville Skyttä ville.sky...@iki.fi said: Yeah, I've done that in some setups but I was talking about purifying the _repos_ above; that setting doesn't affect them, e.g. it doesn't make the metadata to be downloaded any smaller. (As said, not that I think it's a big general issue at all, but just that I'd personally have nothing against if it would be fixed nevertheless.) One way to make this smaller (without any overlap) would be to split the current two (i386 and x86_64) repos into three: i386-common, i386, x86_64. For an i386 system, you use i386 and i386-common, for a multilib x86_64 system you use x86_64 and i386-common, and for a pure x86_64 system you use just x86_64. I don't know if it is worth the trouble though. and then you have to do that as well for updates. :( -sv -- 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 Wed, 9 Dec 2009, Gregory Maxwell wrote: On Wed, Dec 9, 2009 at 4:51 PM, Seth Vidal skvi...@fedoraproject.org wrote: and then you have to do that as well for updates. :( Not if you don't have a separate updates repo, no? still need an updates-testing. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Thu, 3 Dec 2009, Adam Williamson wrote: On Thu, 2009-12-03 at 00:32 -0500, Seth Vidal wrote: We wouldn't be talking about removing the original GA set - just adding updated pkgs into the path. So you'd still have the number of pkgs -just all in one repo, that you have to download all of the metadata for all of the more often, despite that 15K of them don't CHANGE. I don't think that was actually made clear in the initial proposal. I'd been assuming that the proposal was _exactly_ to remove the GA set. Usually, when a newer package shows up in any given repository, we don't keep the previous version of the package, do we? So I assumed the proposal was expecting that behaviour for the combined repository. From a QA standpoint I'd think you'd want at least one known-installable set of pkgs. Since everything after the original GA set is a giant questionmark. Not to mention that removing all the old pkgs would more or less make deltarpms very difficult. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Plan for tomorrow's (20091203) FESCo meeting
On Thu, 3 Dec 2009, Bill Nottingham wrote: Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 17:00UTC (noon EST) in #fedora-meeting on irc.freenode.net. This meeting may be cancelled if we cannot reach quorum. FESCo members who cannot make it are encouraged to vote or comment in the tickets. I won't be there - I'll be in the air, most likely. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2 Dec 2009, Paul W. Frields wrote: On Wed, Dec 02, 2009 at 11:09:41AM -0500, Bill Nottingham wrote: we ship. Any new solution would have to preserve this. Might there also be export compliance implications too? A larger isssue is constantly having the repodata for the everything repo be: 1. growing 2. changing So now instead of having a 15K pkg repo that never changes you have an ever-growing repo that never shrinks in size that changes what? 3 times a week? -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: F12 Yum/package kit bug??
On Wed, 2 Dec 2009, Nathanael D. Noblet wrote: Over the last few days I have been unable to install updates via the package kit applet that pops up. I get the following output after clicking 'install updates'. Error Type: class 'yum.Errors.RepoError' Error Value: Error getting repository data for installed, repository not found File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3125, in module main() File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3122, in main backend.dispatcher(sys.argv[1:]) File : /usr/lib/python2.6/site-packages/packagekit/backend.py, line 710, in dispatcher self.dispatch_command(args[0], args[1:]) File : /usr/lib/python2.6/site-packages/packagekit/backend.py, line 657, in dispatch_command self.update_packages(only_trusted, package_ids) File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 1948, in update_packages signed = self._is_package_repo_signed(pkg) File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 1437, in _is_package_repo_signed repo = self.yumbase.repos.getRepo(pkg.repoid) File : /usr/lib/python2.6/site-packages/yum/repos.py, line 121, in getRepo 'Error getting repository data for $s, repository not found' $ (repoid) However yum update functions properly. Is this a known bug? yes. It's in PK and I believe it's been fixed upstream. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2 Dec 2009, Nicolas Mailhot wrote: Since people are posting wishes, here is mine: 1. stop shuffling packages from directory to directory as they get promoted/demoted from release to release we sort of do this now with hardlinks - the problem is when we have to resign the pkgs. 2. have a single authoritative URL for each package packagedb... 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) I don't think that would work fine with a lot of our mirrors. 4. generate indexes of the kojipkgs.fedoraproject.org tree that represent Fedora X, Fedora X + updates, Fedora X + testing, etc. this is intriguing but expensive on kojipkgs. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2 Dec 2009, Peter Jones wrote: (on my on tangent...) On 12/02/2009 12:48 PM, Jesse Keating wrote: I hypothesize that we could place all rpms for a given release in a single directory (seth will hate this as he wants to split them up based on first letter of their name for better filesystem performance), Ugh, first letter isn't really a great plan anyway. First (few) letters of a hash of the filename is much better, but obviously hurts browsability. Next best is probably something like how a dead-tree dictionary index works; list everything, split the list up by starting letters evenly, so the directories (given a really unlikely hypothetical package set) are 0/ # contains packages named 0 through 3* 4/ # 4 through 9* a/ # a through ay* az/ # az through bw* bx/ # bx through cz* da/ # da through whatever's next ... so that every directory has about the same number of things. If you're looking for perfect division, sure - but the reality is this: 19K items in a single dir and ext3 and nfs and many many other things crap themselves returning that list. If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for producing the same list of files. I tested it on our backend to be sure. getting the complete pkglist goes from taking 5 minutes to take 30s. yes, I said 5 minutes. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2 Dec 2009, Peter Jones wrote: On 12/02/2009 03:53 PM, Seth Vidal wrote: On Wed, 2 Dec 2009, Nicolas Mailhot wrote: 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) I don't think that would work fine with a lot of our mirrors. I think it probably /could/ if we put some (relatively major) work in on the server side to make it look like the directories it isn't. Not that I'm endorsing such a plan. we'd have to make all our mirrors use that. not gonna fly. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2 Dec 2009, Peter Jones wrote: On 12/02/2009 05:58 PM, Seth Vidal wrote: On Wed, 2 Dec 2009, Peter Jones wrote: On 12/02/2009 03:53 PM, Seth Vidal wrote: On Wed, 2 Dec 2009, Nicolas Mailhot wrote: 3. replace static mirrors with proxy-ing of kojipkgs.fedoraproject.org (make sure it works with web infrastructure instead of fighting it) I don't think that would work fine with a lot of our mirrors. I think it probably /could/ if we put some (relatively major) work in on the server side to make it look like the directories it isn't. Not that I'm endorsing such a plan. we'd have to make all our mirrors use that. not gonna fly. Well, you just wouldn't get the benefits of this if you're using a mirror. Which, yes, is pretty lame. we won't get the benefits in fedora then. Our mirror infrastructure is a HUGE reason why we can do what we do. If we can't farm things out to our mirrors then we might as well go home b/c our users will NEVER be able to get our bits. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, 2 Dec 2009, Bruno Wolff III wrote: On Wed, Dec 02, 2009 at 17:58:24 -0500, Seth Vidal skvi...@fedoraproject.org wrote: I tested it on our backend to be sure. getting the complete pkglist goes from taking 5 minutes to take 30s. yes, I said 5 minutes. Have you tried any of the tunning knobs to have the directory cache be alotted more space or given higher priority? For example: vfs_cache_pressure -- Controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects. At the default value of vfs_cache_pressure=100 the kernel will attempt to reclaim dentries and inodes at a fair rate with respect to pagecache and swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer to retain dentry and inode caches. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes. Not tried that - worth giving it a shot - but it still won't help the 'holy crap there are 15K items on this webpage and it won't render' problem. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Thu, 3 Dec 2009, Kevin Kofler wrote: Seth Vidal wrote: If you're looking for perfect division, sure - but the reality is this: 19K items in a single dir and ext3 and nfs and many many other things crap themselves returning that list. If you make 36 subdirs (26+10) performance gets DRAMATICALLY better for producing the same list of files. The problem is, a few of those starting letters still correspond to A LOT of packages, e.g. p* matches perl-*, python-* and php-* and that's a lot of stuff (especially Perl and Python). And adding python3-* (and perl6-*, or are we going to use the rakudo-* namespace there?) won't make it any less. And yet, when tested, just making those 36 subdirs made a HUGE difference. What I've found is getting any one dir down below 3K entries makes things faster, by a lot. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Thu, 3 Dec 2009, Ralf Corsepius wrote: On 12/02/2009 07:09 PM, Seth Vidal wrote: the merger of repos is already happening at the yum layer. On the client's side - With a combined Everything+updates, this would happen on the server side. It's one of the aspects which made me said a combined Everything+updates shifts costs from client to server. except they wouldn't be merged on the server side -it would just be additive. We wouldn't be talking about removing the original GA set - just adding updated pkgs into the path. So you'd still have the number of pkgs -just all in one repo, that you have to download all of the metadata for all of the more often, despite that 15K of them don't CHANGE. this is why it is less good for our users. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Tue, 24 Nov 2009, James Antill wrote: On Mon, 2009-11-23 at 22:32 +, Colin Walters wrote: On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote: Possibly (it could simply be that an updated policy is weaker for some reason) -- but it doesn't matter, there should be no way to change MAC policy without MAC privilege. It'd be nice here if we had the ability to only grant the ability to install applications, not packages. applications is still way too broad, IMO. Even if you limit it to what I assume you meant, Desktop applications, it's not obvious that is good enough. A useful end goal seems more likely to be something like allow 'local' users to update/install signed/trusted versions of: fonts, codecs, themes, games, editors. For bonus points you could make it possible for them to remove packages they have installed. If done well this should even allow things like the webadmin role being allowed to update/install apache related packages. See, this is the problem, with all the exceptions you'd need to codify it would make much more sense to document how to set them up and make it relatively easy to do so that the local admin can do so. Think of it like documentation for sudo but with docs that don't make everyone cry. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and syslog
On Tue, 24 Nov 2009, Matthew Miller wrote: One of the important features of sudo is its ability to log elevated-access actions to syslog. Userhelper similarly logs actions, like so: userhelper[26491]: running '/usr/share/system-config-users/system-config-users ' with root privileges on behalf of 'mattdm'. PolicyKit serves a similar function, but doesn't seem to log anything. In fact, the only use of syslog appears to be in polkit-agent-helper-1, which logs in two possible situations -- when called with the wrong number of arguments and when stdin is a tty. (Most other things it fprintfs to stderr.) I'm not bringing this up to complain -- I just want to make sure that I'm not missing something (which happens more often than it should; *sigh*). If I'm not missing something, is this something anyone is working on already or has existing plans for? I see nothing noting any changes to the policy state whatsoever. I'd recommend filing this as a bug. thanks, -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and syslog
On Tue, 24 Nov 2009, Matthias Clasen wrote: On Tue, 2009-11-24 at 11:26 -0500, Matthew Miller wrote: One of the important features of sudo is its ability to log elevated-access actions to syslog. Userhelper similarly logs actions, like so: userhelper[26491]: running '/usr/share/system-config-users/system-config-users ' with root privileges on behalf of 'mattdm'. PolicyKit serves a similar function, but doesn't seem to log anything. In fact, the only use of syslog appears to be in polkit-agent-helper-1, which logs in two possible situations -- when called with the wrong number of arguments and when stdin is a tty. (Most other things it fprintfs to stderr.) I'm not bringing this up to complain -- I just want to make sure that I'm not missing something (which happens more often than it should; *sigh*). If I'm not missing something, is this something anyone is working on already or has existing plans for? PolicyKit itself is not running anything. It is just answering the question of a mechanism: 'is X allowed to do foo ?'. It would make more sense for the mechanisms that use PolicyKit to log privileged actions that they do or deny to do. when the policies are updated it is policy kit that has to be involved. polkitd is running, at least. It would make sense for polkitd to note a change to a policy. Maybe also to note any communications to polkitd of any kind. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and syslog
On Tue, 24 Nov 2009, Matthias Clasen wrote: On Tue, 2009-11-24 at 11:48 -0500, Seth Vidal wrote: when the policies are updated it is policy kit that has to be involved. polkitd is running, at least. That might be ok to log, indeed. polkitd need not be running, though. It is activated as needed. It would make sense for polkitd to note a change to a policy. Maybe also to note any communications to polkitd of any kind. That I would consider spamming. But maybe at absurd log levels... Policy changes should be warning level notices b/c it notes a change in state. any/all communication should be at debug level notices. debugging is a lot easier when you can follow the whole process along. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Tue, 24 Nov 2009, Bill Nottingham wrote: I don't want to ship a desktop that doesn't let the user do useful things. And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices. if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin. Given how .pkla works, this is likely to be done with packages, not with %post hackery. (Which should make it much easier to reliably test, as well.) provided those pkgs are not required anywhere or set in our default pkg groups, then sure. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: tangent: PolicyKit and PAM
On Tue, 24 Nov 2009, Matthew Miller wrote: On Tue, Nov 24, 2009 at 01:27:40PM -0500, Matthias Clasen wrote: Like I said, this is a tangent, and I'm certainly not expecting anyone to work on this. But it'd be cool if they did. Just as everybody else is struggling to get away from pam's awful apis...I don't think this would be a step forward; but sure, it might be doable. The awful API is actually an argument _for_ doing such a thing: it gets encapsulated away in only one place that needs to be maintained, and everyone can just write to PolicyKit. And in general having the logging of security-elevation events be in the lowest common denominator piece of code or interface keeps important information from getting lost due to insufficient logging in a calling app. -sv -- 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 Tue, 24 Nov 2009, 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? it'd be easy to have two sets of repodata in two different dirs pointing to the same set of pkgs. trivially, so. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Tue, 24 Nov 2009, Francis Earl wrote:
Would it be possible to do this similarly to Conary... only installing
the files (.so's and things in /etc and /usr/share/{icons,sounds,...}
etc) required by a given application (binary with .desktop file) ?
This would provide similar to package splitting, but because of version
control and something like google update, it can be effective to update
only those files and applications when its parts are updated upstream...
with something like presto only bringing in what changed, and something
like jigdo allowing you to download each file from a different mirror,
speeds can be quite quick and downloads quite small.
That would require massive changes to rpm.
it is not an undertaking that is likely to happen in my opinion.
-sv
--
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 Tue, 24 Nov 2009, Jeff Garzik 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. only some of the i686 pkgs are there. not all of them. that's what matt means. -sv -- 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 Wed, 25 Nov 2009, Jeff Garzik wrote: 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 mash is a specific program in this case. It inspects the pkgs to determine which i686 pkgs need to be included in the x86_64 tree. It's not arbitrary. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and syslog
On Tue, 24 Nov 2009, Matthias Clasen wrote: On Tue, 2009-11-24 at 11:48 -0500, Seth Vidal wrote: when the policies are updated it is policy kit that has to be involved. polkitd is running, at least. That might be ok to log, indeed. polkitd need not be running, though. It is activated as needed. It would make sense for polkitd to note a change to a policy. Maybe also to note any communications to polkitd of any kind. That I would consider spamming. But maybe at absurd log levels... Policy changes should be warning level notices b/c it notes a change in state. any/all communication should be at debug level notices. debugging is a lot easier when you can follow the whole process along. -sv -- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: Security testing: need for a security policy, and a security-critical package process
On Tue, 24 Nov 2009, Bill Nottingham wrote: I don't want to ship a desktop that doesn't let the user do useful things. And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices. if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin. Given how .pkla works, this is likely to be done with packages, not with %post hackery. (Which should make it much easier to reliably test, as well.) provided those pkgs are not required anywhere or set in our default pkg groups, then sure. -sv -- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: tangent: PolicyKit and PAM
On Tue, 24 Nov 2009, Matthew Miller wrote: On Tue, Nov 24, 2009 at 01:27:40PM -0500, Matthias Clasen wrote: Like I said, this is a tangent, and I'm certainly not expecting anyone to work on this. But it'd be cool if they did. Just as everybody else is struggling to get away from pam's awful apis...I don't think this would be a step forward; but sure, it might be doable. The awful API is actually an argument _for_ doing such a thing: it gets encapsulated away in only one place that needs to be maintained, and everyone can just write to PolicyKit. And in general having the logging of security-elevation events be in the lowest common denominator piece of code or interface keeps important information from getting lost due to insufficient logging in a calling app. -sv -- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: rawhide report screwing up changelogs (was: Re: rawhide report: 20091123 changes)
On Mon, 23 Nov 2009, Michael Schwendt wrote: On Mon, 23 Nov 2009 15:04:49 +0100, Christoph wrote: Am Montag, den 23.11.2009, 14:56 +0100 schrieb Michael Schwendt: On Mon, 23 Nov 2009 14:39:28 +0100, Christoph wrote: When two builds of the same version are done on the same day, the rawhide report screws up the order of the changelog entries: Can this be fixed please? See Yum (yum-utils) upstream tickets #6 and #7 for the background. One part of the fix will require a hack in the handling of repo metadata stored in SQLite tables. Thanks for the info, Michael. Obviously it's not so trivial. Well, somebody could still apply my patch attached to #7. It's a year old and still without a reply. It would print the missing changelog entries, which is what the ticket is about. | repodiff misses changelog entries (corner-case) | http://yum.baseurl.org/ticket/7 I've replied a bunch of times and I offered you access to commit it yourself. You never responded. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 23 Nov 2009, Matthias Clasen wrote: On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote: It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here. I don't think spots list is too useful, unfortunately; discussing an abstract 'unprivileged user' without defining some roles and use cases doesn't make much sense to me. There is probably a difference between a guest account and a regular (non-admin) user in what I want them to be able to do; 'unprivileged user' does not allow that distinction. And there is certainly a difference between what a regular user is expected to be allowed on a family computer vs a university computer lab. And this is why spot's list is useful. A family computer and a university computer lab have a lot in common but where they diverge we should start with err toward MORE restrictive and allow configuration by the local admin/owner to LESS restrictive. Otherwise we open ourselves up to a less-secure-by-default posture in an average install. We've been in that position in the past and it is not a favorable place to be. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Mon, 23 Nov 2009, Colin Walters wrote:
On Mon, Nov 23, 2009 at 10:02 PM, James Morris jmor...@namei.org wrote:
Possibly (it could simply be that an updated policy is weaker for some
reason) -- but it doesn't matter, there should be no way to change MAC
policy without MAC privilege.
It'd be nice here if we had the ability to only grant the ability to
install applications, not packages. We could possibly do this even
now inside PackageKit by always downloading the filelists data, and
looking for a .desktop file. It'd be even better if we could get at
the data inside the .desktop file, but that's not necessary for this.
That leaves aside the packagekit-command-not-found feature for unix
binaries, but that's more of a technical use case.
Or - you could more easily generate the 'which pkgs have .desktop files'
and propagate that into a package Provides.
since yum can install by provides - that takes care of that need.
example:
Provides: App('foo')
-sv
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 23 Nov 2009, Matthias Clasen wrote: On Mon, 2009-11-23 at 18:31 -0500, Seth Vidal wrote: Otherwise we open ourselves up to a less-secure-by-default posture in an average install. We've been in that position in the past and it is not a favorable place to be. We should just avoid to sink tons of QA resources in verifying that a theoretical 'unprivileged user' can do nothing, when that role is not something anybody would want to use anyway (because it can do nothing) and is not the role that most users will actually end up with in a typical desktop install. If someone installing/deploying fedora (or a fedora-derived spin) wants to configure a specific user or a set of users to have greater power, then they should be able to do that. The default as shipped in our packages should not empower users significantly. Default strict, configure relaxed. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 23 Nov 2009, Matthias Clasen wrote: I don't want to ship a desktop that doesn't let the user do useful things. And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices. if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin. We should not be forcing the choices for the desktop spin on everyone who installs a pkg in the distribution. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 23 Nov 2009, Matthias Clasen wrote: On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote: It's not QA's role to define exactly what the security policy should look like or what it should cover, but from the point of view of testing, what we really need are concrete requirements. The policy does not have to be immediately comprehensive - try and cover every possible security-related issue - to be valuable. Something as simple as spot's proposed list of things an unprivileged user must not be able to do - http://spot.livejournal.com/312216.html - would serve a valuable purpose here. I don't think spots list is too useful, unfortunately; discussing an abstract 'unprivileged user' without defining some roles and use cases doesn't make much sense to me. There is probably a difference between a guest account and a regular (non-admin) user in what I want them to be able to do; 'unprivileged user' does not allow that distinction. And there is certainly a difference between what a regular user is expected to be allowed on a family computer vs a university computer lab. And this is why spot's list is useful. A family computer and a university computer lab have a lot in common but where they diverge we should start with err toward MORE restrictive and allow configuration by the local admin/owner to LESS restrictive. Otherwise we open ourselves up to a less-secure-by-default posture in an average install. We've been in that position in the past and it is not a favorable place to be. -sv -- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 23 Nov 2009, Matthias Clasen wrote: On Mon, 2009-11-23 at 18:31 -0500, Seth Vidal wrote: Otherwise we open ourselves up to a less-secure-by-default posture in an average install. We've been in that position in the past and it is not a favorable place to be. We should just avoid to sink tons of QA resources in verifying that a theoretical 'unprivileged user' can do nothing, when that role is not something anybody would want to use anyway (because it can do nothing) and is not the role that most users will actually end up with in a typical desktop install. If someone installing/deploying fedora (or a fedora-derived spin) wants to configure a specific user or a set of users to have greater power, then they should be able to do that. The default as shipped in our packages should not empower users significantly. Default strict, configure relaxed. -sv -- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: Security testing: need for a security policy, and a security-critical package process
On Mon, 23 Nov 2009, Matthias Clasen wrote: I don't want to ship a desktop that doesn't let the user do useful things. And you can ship a desktop SPIN that way. But the base pkgs should not install with an insecure set of choices. if you want the spin to have a post-scriptlet which allows more things, then that's the choice of the desktop sig over the desktop spin. We should not be forcing the choices for the desktop spin on everyone who installs a pkg in the distribution. -sv -- Fedora-security-list mailing list Fedora-security-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
Re: PackageKit policy: background and plans
On Fri, 20 Nov 2009, Owen Taylor wrote: On Fri, 2009-11-20 at 11:50 -0430, Robert Marcano wrote: On 11/20/2009 10:04 AM, Matthew Garrett wrote: I know basically nobody who, on a generally single user system, explicitly switches to a console to log in as root and perform package installs there. If you're not doing that then the issue is basically moot - a user-level compromise will become a root-level compromise the next time you run anything as root. I do that on critical workstations because a long time ago an old (fixed) bug killed my X session when updating and messed my system, so I do not trust too much updating base X components using a GUI. on my personal systems, yes I use the GUI method This actually is one of the big advantages of PackageKit - because the installation is being done by a daemon rather than a process running in your session, if the X session dies during package installation, you won't be left with a half-completed transaction. Though that only helps from the command line if you use gpk-install-package-name rather than yum. Probably not too many people do that :-) if you install from the command line using yum and you're worried about the install obliterating your X session I would recommend using screen. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PackageKit policy: background and plans
On Fri, 20 Nov 2009, Frank Ch. Eigler wrote: otaylor wrote: This actually is one of the big advantages of PackageKit - because the installation is being done by a daemon rather than a process running in your session, if the X session dies during package installation, you won't be left with a half-completed transaction. To what extent are yum/rpm/packagekit transactions databasey enough so that they can actually be undone if the machine or process crashes midstream? not enough. We can sometimes recover - it really depends on where it died :( -sv -- 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 Wed, 18 Nov 2009, Jon Ciesla wrote: nodata wrote: Am 2009-11-18 18:08, schrieb nodata: 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! Just to elaborate: A local user is allowed to install software on the machine without being prompted for the root password. This is a recipe for disaster in my opinion. So much for granting shell access on my servers. . . You have PackageKit installed on servers? really? -sv -- 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 Wed, 18 Nov 2009, Jon Ciesla wrote: Seth Vidal wrote: On Wed, 18 Nov 2009, Jon Ciesla wrote: nodata wrote: Am 2009-11-18 18:08, schrieb nodata: 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! Just to elaborate: A local user is allowed to install software on the machine without being prompted for the root password. This is a recipe for disaster in my opinion. So much for granting shell access on my servers. . . You have PackageKit installed on servers? really? -sv 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. If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have. -sv -- 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 Wed, 18 Nov 2009, Dennis J. wrote: You have PackageKit installed on servers? really? Why shouldn't he? AFAIK there is nothing in the package warning users not to install this on a server. like I said in another email - I think of installing things on servers as 'barest minimal' and then adding things I require. Nothing else. Maybe I'm in the minority. -sv -- 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 Wed, 18 Nov 2009, nodata wrote: -sv 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. If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have. -sv Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what. right - which is why I wouldn't install PK on a server. yum doesn't allow users to install pkgs, only root. -sv -- 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 Wed, 18 Nov 2009, Jon Ciesla wrote: Seth Vidal wrote: On Wed, 18 Nov 2009, nodata wrote: -sv 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. If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have. -sv Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what. right - which is why I wouldn't install PK on a server. yum doesn't allow users to install pkgs, only root. -sv I just found PackageKit on a server that's never been anything but. It was installed fith FC-2, which IIRC is pre-PackageKit. Does this mean it was pulled in by something else that no longer requires it? Did you 'yum update' the box from fc-2 to whatever it is now? or how did you get there? -sv -- 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 Wed, 18 Nov 2009, Konstantin Ryabitsev wrote: 2009/11/18 Jon Ciesla l...@jcomserv.net: A local user is allowed to install software on the machine without being prompted for the root password. This is a recipe for disaster in my opinion. So much for granting shell access on my servers. . . I may be wrong, but I understand that this behaviour of PackageKit only applies to users with direct console access (i.e. not remote shells). So, only users that are logged in via GDM or TTY would be able to perform such tasks. 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. Not saying it's a good default policy -- but let's cool our heads. might be worth testing that feature with pkcon from an ssh terminal. I've not done that yet but I think it would be worth checking out. -sv -- 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 Wed, 18 Nov 2009, Bruno Wolff III wrote: On Wed, Nov 18, 2009 at 23:18:28 +0530, Rahul Sundaram sunda...@fedoraproject.org wrote: On 11/18/2009 11:19 PM, nodata wrote: Thanks. I have changed the title to: All users get to install software on a machine they do not have the root password to .. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail. Besides other issues listed, the packages being installed may be privileged programs that the admin doesn't want on the system, may start services or schedule runs at specified times by default which might considered a problem by the admin, the extra packages may use up too much disk space and cause problems. If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case. -sv -- 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 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. -sv -- 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 Wed, 18 Nov 2009, Simo Sorce wrote: On Wed, 2009-11-18 at 13:10 -0500, Seth Vidal wrote: Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what. right - which is why I wouldn't install PK on a server. yum doesn't allow users to install pkgs, only root. Seth, the fact you prefer to use yum doesn't make it right to have an insecure-by-default policy. I didn't say it did - I said it didn't make sense to have items like PK on servers. -sv -- 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 Wed, 18 Nov 2009, Dennis J. wrote: In fact I agree with you but this doesn't really address my point. How do you make sure the packages that are part of your minimal list don't introduce such a backdoor with the next update? You check them. That's the best you can do. It's just like anything else: How are you sure no one introduces a package into 'updates' which obsoletes glibc? We check them and hope we catch problems. -sv -- 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 Wed, 18 Nov 2009, Konstantin Ryabitsev wrote: 2009/11/18 Casey Dahlin cdah...@redhat.com: On 11/18/2009 01:22 PM, James Antill wrote: 3. Are there any attacks due to disk space used? Eg. If /var is low² I can probably install enough pkgs to make logging stop. I'm betting there's still enough systems out there without enough space in /usr for the entire package set. That's kind of a silly exercise in what-ifs. The default anaconda partition scheme is /boot, swap, and /. If someone wanted to fill up the disk, they can just write to /tmp on a default install. well - except for the 5% reserved for root :) -sv -- 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 Wed, 18 Nov 2009, Casey Dahlin wrote: On 11/18/2009 02:10 PM, Seth Vidal wrote: On Wed, 18 Nov 2009, Konstantin Ryabitsev wrote: 2009/11/18 Casey Dahlin cdah...@redhat.com: On 11/18/2009 01:22 PM, James Antill wrote: 3. Are there any attacks due to disk space used? Eg. If /var is low² I can probably install enough pkgs to make logging stop. I'm betting there's still enough systems out there without enough space in /usr for the entire package set. That's kind of a silly exercise in what-ifs. The default anaconda partition scheme is /boot, swap, and /. If someone wanted to fill up the disk, they can just write to /tmp on a default install. well - except for the 5% reserved for root :) -sv Which isn't safe from this since ultimately its root doing the install on the unprivileged user's behalf. which is why I said the user filling up /tmp couldn't fill up the whole disk.. -sv -- 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 Wed, 18 Nov 2009, Richard Hughes wrote: 2009/11/18 Andrew Haley a...@redhat.com: Is there some way to disable PackageKit but keep setroubleshoot? Just set all the policykit answers to no. You'll find more than just setroubleshoot breaks if you do this. How do you do this? Set the policykit answers to no? -sv -- 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?
2009/11/18 nodata l...@nodata.co.uk: Am 2009-11-18 20:20, schrieb Richard Hughes: 2009/11/18 Casey Dahlincdah...@redhat.com: By the admin's first opportunity to change the settings the box could already be rooted. I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine. You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo! If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it. So here is what I've just gotten from talking to Ray Strode and reading docs. if you want to disable this just run: pklalockdown --lockdown org.freedesktop.packagekit.package-install that will keep anyone from installing pkgs w/o authenticating as admin. That's the short version. the long version I'm working on writing up right now. -sv -- 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 Wed, 18 Nov 2009, nodata wrote: Am 2009-11-18 21:27, schrieb Seth Vidal: 2009/11/18 nodata l...@nodata.co.uk: Am 2009-11-18 20:20, schrieb Richard Hughes: 2009/11/18 Casey Dahlincdah...@redhat.com: By the admin's first opportunity to change the settings the box could already be rooted. I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine. You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo! If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it. So here is what I've just gotten from talking to Ray Strode and reading docs. if you want to disable this just run: pklalockdown --lockdown org.freedesktop.packagekit.package-install that will keep anyone from installing pkgs w/o authenticating as admin. That's the short version. the long version I'm working on writing up right now. -sv Thanks for this. Does this need to be run as root? :) yes :) -sv -- 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 Wed, 18 Nov 2009, Seth Vidal wrote: 2009/11/18 nodata l...@nodata.co.uk: Am 2009-11-18 20:20, schrieb Richard Hughes: 2009/11/18 Casey Dahlincdah...@redhat.com: By the admin's first opportunity to change the settings the box could already be rooted. I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine. You install software with a known buffer overflow before it is fixed and exploit it. More software = more chances to exploit. Bingo! If a user logged in from a physical local console wanted to exploit their machine, this would be the hard way to do it. So here is what I've just gotten from talking to Ray Strode and reading docs. if you want to disable this just run: pklalockdown --lockdown org.freedesktop.packagekit.package-install that will keep anyone from installing pkgs w/o authenticating as admin. That's the short version. the long version I'm working on writing up right now. longer version w/some more details: http://skvidal.wordpress.com/2009/11/18/polkit-and-package-kit-and-changing-settings/ -sv -- 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 Wed, 18 Nov 2009, Dan Williams wrote: On Wed, 2009-11-18 at 14:29 -0500, Seth Vidal wrote: On Wed, 18 Nov 2009, Richard Hughes wrote: 2009/11/18 Andrew Haley a...@redhat.com: Is there some way to disable PackageKit but keep setroubleshoot? Just set all the policykit answers to no. You'll find more than just setroubleshoot breaks if you do this. How do you do this? Set the policykit answers to no? The atom-bomb approach is to change everything in /usr/share/polkit-1/actions/ to allow_activeno/allow_active and allow_inactiveno/allow_inactive. But that's not right because those files aren't config files. Instead, you drop local authority files in /var/lib/polkit-1/localauthority/ that override those permissions on a site-by-site basis for your specific use-case, irregardless of what the defaults are. To be fair - it took 2 engineers about 30-40 minutes and looking through the code to figure out what was wanted in those files and then how to verify what was in there. it resulted in: http://skvidal.wordpress.com/2009/11/18/polkit-and-package-kit-and-changing-settings/ but the manpages do not make it obvious. nor is it obvious why those files are in /var/lib/ -sv -- 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 Wed, 18 Nov 2009, Jesse Keating wrote: On Wed, 2009-11-18 at 14:39 -0600, Chris Adams wrote: What would be nice would be a guide of how all this fits together and when to change what (not just documentation of individual options or syntax), but I do also understand that developers don't always like writing documentation (hey, who does, other than tech writers!). In this case we do have some documentation. man 8 polkit looks to be a great read for getting your head around this stuff. Unfortunately you need to be on an F12 box (or chroot) to run that, although the man page may be on the web somewhere. polkit man page tells you a lot - but it's not going to help a sysadmin configure something TODAY. FAQs and HOWTOs will do that. -sv -- 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 Wed, 18 Nov 2009, Jeff Garzik wrote: 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. @core doesn't contain anything like that: http://fpaste.org/Bk9t/ 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. -sv -- 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 Wed, 18 Nov 2009, Jeff Garzik wrote: 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? you're talking to the wrong guy. I don't maintain PK. I don't work on PK. I don't have anything to do with it, in fact. And you should listen to yourself. I'm saying: You want to run secure servers, then you have to know what's on the system. Not just what pkg, but what the pkg does. This is why I said: It doesn't make sense to have programs like packagekit which are targeted at end users on servers. -sv -- 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 Wed, 18 Nov 2009, Jeff Garzik wrote: 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? Not much. 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. -sv -- 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 Wed, 18 Nov 2009, Jeff Garzik wrote: 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. It is for purposes of me stating my opinion, which is all I've been saying this whole time. -sv -- 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 Wed, 18 Nov 2009, Richard Hughes wrote: 2009/11/18 Jeff Garzik jgar...@pobox.com: 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. F11 had retained authorisations, which arguably were more of a security weakness. If rawhide had been signed during the F12 cycle everybody would have seen this change much earlier. If you're deploying F12, then I really think you should know the basics about PolicyKit. 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? -sv -- 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 Wed, 18 Nov 2009, Richard Hughes wrote: 2009/11/18 Eric Christensen e...@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. I think this is less subjective than bikeshed colors. I think fesco is going to need to talk about this on friday. -sv -- 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 Wed, 18 Nov 2009, Matthew Miller wrote: On Wed, Nov 18, 2009 at 11:45:14AM -0800, Dan Williams wrote: But that's not right because those files aren't config files. Instead, you drop local authority files in /var/lib/polkit-1/localauthority/ that override those permissions on a site-by-site basis for your specific use-case, irregardless of what the defaults are. The config files live in /var? Really. https://bugzilla.redhat.com/show_bug.cgi?id=538615 bug is already opened. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Tue, 17 Nov 2009, James Antill wrote: On Tue, 2009-11-17 at 08:10 -0500, Josef Bacik wrote: On Tue, Nov 17, 2009 at 2:48 AM, Jeff Garzik jgar...@pobox.com wrote: As the URL notes under Detailed Description, that is not handled at all. It wraps all file I/O, yum or not, into the snapshot. Yeah but you can't roll back userland transactions. Not to mention you are talking about an interface that may change quite a bit over the next year. That seems like a significant limitation, I'm also not sure that the current transaction API would be usable by rpm. Anyway... We have snapshotting abilities now, and yes it's a big hammer, but just because its a bit of a blunt instrument doesn't mean we shouldn't take advantage of it. This implies that all you have is a hammer but you can already run yum history undo. which works up to a point. If the older pkgs you had prior to an update are not available anywhere history undo isn't going to be able to 'undo' but so much. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: scripts that need to be updated to f11? f12
On Fri, 13 Nov 2009, Mike McGrath wrote: On Fri, 13 Nov 2009, Stephen John Smoogen wrote: puppet/modules/scripts/files/maps/maps.sh was not updated to f11. Is it still being used? I have attached a proposed patch to cover those changes. Please let me know if I can commit them. is this the thing that generates the ambassador map stuff or these things? http://fedoraproject.org/maps/ If it's the latter, I'm down for getting those fixed. They're fairly neglected. Wasn't that intentionally disabled? -sv ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: scripts that need to be updated to f11? f12
On Fri, 13 Nov 2009, Mike McGrath wrote: On Fri, 13 Nov 2009, Seth Vidal wrote: Wasn't that intentionally disabled? It was but I think only because it didn't work after some upgrades and no one was willing to fix it. I thought it was for political reasons having to do with country-of-origin of some people... Ahem. ask paul. -sv ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: FESCO ticket#270 - preupgrade and F-12
On Thu, 12 Nov 2009, Neal Becker wrote: James Laska wrote: On Thu, 2009-11-12 at 13:00 -0700, Linuxguy123 wrote: On Thu, 2009-11-12 at 14:56 -0500, James Laska wrote: Greetings folks, After careful review by Will Woods around recently discovered problems related to preupgrading to Fedora 12, I've filed ticket#270 (https://fedorahosted.org/fesco/ticket/270) for discussion at the next FESCO meeting. Please take a moment to read the details in the ticket. The high-level summary from Will ... preupgrade to F12 is basically not going to work for anyone without significant manual workarounds, due to insufficient disk space on /boot. How much disk space will one require on /boot to perform the update without work arounds ? From the ticket (see URL above). Here's the details. The default /boot partition is 200MB, but there's some overhead: Ext3/Ext4 overhead: 7MB Reserved space: 10MB F11 kernel: 8MB (at least - usually 3 kernels = 24MB) GRUB/EFI files: 1MB Total overhead: 26MB So there's 174MB of usable space maximum, and usually 158MB available. preupgrade now requires at least 167MB free space on /boot: F12 installer images: 143MB (8mb larger than F11!) F12 kernel: 18MB (10mb larger than F11!) RPM/anaconda tmpfiles: =8MB (measured in stupid tests) Total: 167MB (Was 149MB in F11 - no problem!) Can gparted resize /boot ? There are definitely workarounds available, but none that meet the criteria for preupgrade as an effortless upgrade option. Thanks, James What if I have already a large /boot? then just run preupgrade. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
odd file requires
Hey folks, I put together this list for things I'd like to work on for f13. It's a list of packages with a file-requires that falls outside of *bin/* and /etc/* and then the provider(s) for those files. http://skvidal.fedorapeople.org/misc/non-primary-file-reqs-and-what-requires-them.txt I've gone through some of them and I'm looking for where we can clean up a few more. Take a look through, see if you see a package you're responsible for and, if you can, figure out a way to not need the file-requires. this helps our users b/c if we don't need to get the filelists to resolve the dependency then they don't use up the bandwidth. thanks, -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: odd file requires
On Mon, 9 Nov 2009, Julian Sikorski wrote: W dniu 09.11.2009 17:58, Seth Vidal pisze: Hey folks, I put together this list for things I'd like to work on for f13. It's a list of packages with a file-requires that falls outside of *bin/* and /etc/* and then the provider(s) for those files. http://skvidal.fedorapeople.org/misc/non-primary-file-reqs-and-what-requires-them.txt I've gone through some of them and I'm looking for where we can clean up a few more. Take a look through, see if you see a package you're responsible for and, if you can, figure out a way to not need the file-requires. this helps our users b/c if we don't need to get the filelists to resolve the dependency then they don't use up the bandwidth. thanks, -sv I fixed gnome-chemistry-utils-mozplugin to require mozilla-filesystem Thank you! -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum repolist puzzle
On Sat, 7 Nov 2009, Rahul Sundaram wrote: Hi, yum repolist on the latest rawhide shows fedora and updates repo as having the exact same number of packages which is rather confusing but I suppose it is because they get redirected by mirror manager to point to the same repo. Can we just show the candidate updates or something more meaningful? talk to releng and MM. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Ubuntu shows updates / security updates on shell logins
On Wed, 4 Nov 2009, Richard W.M. Jones wrote: Newly installed Ubuntu 9.10, when you log in over ssh you may see: 34 packages can be updated. 10 updates are security updates. I think this is a nice feature, because many administrators will log in to servers remotely over ssh and never see the graphical indications from packagekit et al. Administrators should not be relying on logging into a machine to know what is in need of updates. We have multiple mechanisms to notify admins about boxes needing updates. Adding it to the MOTD seems like an odd choice. Actually I was trying to work out how it's implemented. The text goes into /etc/motd, and as near as I can tell, the Ubuntu update-manager (roughly equivalent of PackageKit) rewrites it whenever packages become available or get installed. Is this something that PackageKit could also do? Look at yum-cron and how it is can send emails or other events when updates need to be applied. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Ubuntu shows updates / security updates on shell logins
On Wed, 4 Nov 2009, Kevin Kofler wrote: Richard June wrote: It's a good idea for one off jobs where the primary user is also the admin, but not so good for shared systems. Personally I think a better plan would be to display that information *only* if the user is flagged as an administrator, group root, wheel, etc. It's actually a security risk to display this to non-admin users. It's like putting a sticker on your door saying This door is not locked because my keyhole is not working. i don't think it is a security risk. Or rather - if it is then the rpmdb should not be readable by non-root users. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
