Re: Useless setroubleshoot alerts
On Wed, Dec 09, 2009 at 01:34:45PM +, Christopher Brown wrote: SELinux was quite good on F11 and F12. Now it would seem it is starting to regress again. Your expectations are too high if you think rawhide shouldn't have regressions. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Simplify non-responsive maintainers policy Part 2
On Thu, Oct 22, 2009 at 09:43:46AM -0700, Jesse Keating wrote: On Thu, 2009-10-22 at 11:16 +0200, Till Maas wrote: What kind of checks do you mean? If maintainers want to keep their packages, they can just change the owner of the package to their new private account before leaving Red Hat. That assumes the maintainer knows they're leaving Red Hat ahead of time. Perhaps no one should be using their @redhat.com address for Fedora work :-/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
dracut, or should booting a LiveCD touch the hard disk?
Dracut currently tries to find and activate all RAID, LVM, and LUKS partitions on the hard disks when booting the LiveCD. Several of my systems are made up of many RAID, LVM, and LUKS partitions in various combinations. Booting the LiveCD now goes and activates these and asks for passphrases that I have to skip over by entering blank/bogus values to get the system to boot up. I now know that you can pass various rd_* options such as rd_NO_LUKS to grub to have dracut skip these things, but I was hoping for something better, perhaps a skip button. The new behavior makes the LiveCD less independent of and more tied to the existing installations on the hard disk. This is surprising and unexpected. Many uses of LiveCD's expect that the live environment will be completely independent of, and unaffected by, what is on the hard disk. This is no longer true. It may be confusing for users of LiveCD's when an (unidentified) passphrase input text box pops up when booting the LiveCD. What do others think? Should the LiveCD by default access and activate storage volumes, including encrypted partitions, on the hard disks? Should the LUKS prompts better identify the volume so that users know what passphrase to enter? I would prefer a LiveCD that doesn't do anything to the hard disk at all, at least by default when booting up. It should be self-contained. Perhaps we should create another entry in syslinux.cfg that enables rd_NO_LUKS by default, and call it Boot without accessing hard disk. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dracut, or should booting a LiveCD touch the hard disk?
On Sun, Oct 04, 2009 at 06:44:47PM -0400, Ray Strode wrote: What do others think? Should the LiveCD by default access and activate storage volumes, including encrypted partitions, on the hard disks? Should the LUKS prompts better identify the volume so that users know what passphrase to enter? This seems like a misfeature in dracut for LiveCD or otherwise. The initrd should be about getting / mounted read-only and nothing else. There's a reason why plymouth doesn't identify the volume in the initrd. Plymouth is graphical and so would need to ship fonts, font renderering libraries, and translations in the initrd to display text. That's a non-starter. It's okay though, because in most cases the user should only ever get asked for one passphrase from the initrd, so we don't need to show anything but a lock icon and an entry box. If that's no longer the case in a dracut world, we probably need to fix dracut. I agree that this is the best solution. Fix dracut to only activate and mount /. I found these bugs closed as NOTABUG: https://bugzilla.redhat.com/show_bug.cgi?id=512620 https://bugzilla.redhat.com/show_bug.cgi?id=524366 and this is the one I had just opened: https://bugzilla.redhat.com/show_bug.cgi?id=525877 so if this is working as intended is there any chance of changing the default behavior to work as expected above? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto plugin by default
On Wed, Aug 19, 2009 at 11:03:44AM +0800, Steven James Drinnan wrote: I would hold off on the default thing. I have found that it has played havoc with intel video drivers and NetworkManager. I do not know how but for me it was a pain in the neck. All I know is that after I re-installed and upgraded I have had no problems -1 to installing it by default in F12. What the heck does yum-presto have to do with the quality of the xorg-x11-drv-intel and NetworkManager packages? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto plugin by default
On Wed, Aug 19, 2009 at 12:36:15AM -0400, Chuck Anderson wrote: On Wed, Aug 19, 2009 at 11:03:44AM +0800, Steven James Drinnan wrote: I would hold off on the default thing. I have found that it has played havoc with intel video drivers and NetworkManager. I do not know how but for me it was a pain in the neck. All I know is that after I re-installed and upgraded I have had no problems -1 to installing it by default in F12. What the heck does yum-presto have to do with the quality of the xorg-x11-drv-intel and NetworkManager packages? Responding to myself, are you perhaps confusing yum-presto with presto? Name : yum-presto Arch : noarch Version: 0.5.0 Release: 1.fc11 Size : 78 k Repo : installed Summary: Presto plugin for yum URL: http://www.lesbg.com/jdieter/presto/ License: GPLv2+ Description: Yum-presto is a plugin for yum that looks for deltarpms rather than : rpms whenever they are available. This has the potential of saving : a lot of bandwidth when downloading updates. : : A Deltarpm is the difference between two rpms. If you already have : foo-1.0 installed and foo-1.1 is available, yum-presto will : download the deltarpm for foo-1.0 = 1.1 rather than the full : foo-1.1 rpm, and then build the full foo-1.1 package from your : installed foo-1.0 and the downloaded deltarpm. Name : presto Arch : x86_64 Version: 0.1.3 Release: 6.fc11 Size : 35 k Repo : fedora Summary: A tilemap engine using the Allegro game programming library URL: http://www.hypersonicsoft.org/projects/showproject.php?id=29 License: GPLv3+ Description: Presto is a general-use tilemap engine coded in C that uses Allegro : for graphics rendering, and therefore is intended for use in games : using Allegro. It can handle rectangular tiles of any height and : width (and different height from width), loading tilemaps from : files, tile blending, and the capability to change most of these : elements on the fly. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto plugin by default
On Tue, Aug 18, 2009 at 01:35:37AM +0530, Rahul Sundaram wrote: On 07/26/2009 06:40 AM, Rahul Sundaram wrote: Hi, Can we make it a default in comps for Rawhide? Rahul No answer here after weeks. After some lengthy discussion with rel-eng team in irc, not much care either way. Talked to desktop team and based on their recommendation, I have added yum-presto to the GNOME Desktop group by default. If rel-eng wants to add it a base group for the DVD image, feel free to do so. Spin owners - likewise. Thanks. I've been using yum-presto since before F11 came out, and it is great. +1 to installing it by default in F12. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
On Sat, Jul 25, 2009 at 04:41:53PM +0100, Alan Cox wrote: md /boot is definitely broken, has been for ages and the bugs don't seem to have been touched. It's also obvious nobody bothered to actually test that case because the error paths in the install code don't actually work for that case either ! I always set up my md /boot manually and it works fine after that. Fortunately the usual updating fedora-release, yum upgrade approach worked on my boxes. I'd avoid preupgrade anyway it seems to like breaking systems and leaving them half upgraded so you have to rescue the mess by hand. I don't even upgrade anymore. I just keep two partitions (Logical Volumes actually)--one for Fedora N and one for Fedora N+1. I always do a fresh install, formatting the partition from the older install. This has the advantage of providing a backup in case the new Fedora doesn't work so well. Eventually, when updates to the new Fedora fix the most annoying bugs, I switch to using it full time. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 02:57:53PM +0100, Caolán McNamara wrote: So, https://bugzilla.redhat.com/show_bug.cgi?id=502226 was logged a while ago against OOo for the rpms improperly providing and requiring .sos that are not in the linker path, but instead in OOo's own subdirs. a) do we care ? Yes I care. I ran into somthing similar for perl modules. Packages shouldn't provide 'perl(foo)' unless those modules are in perl's default module path. It clearly breaks programs when a perl module in a private directory satisfies an rpm dependency for another package. b) if we care do we want to b.1) make every package that has some shared libraries in it that are not in the default linker path make manual filters to exclude the provides/requires ? (oh, the pain) That is what I had to do in the case of a perl program I'm packaging. There are even Fedora guidelines on how to do this for perl. b.2) extend the autorequires/autoprovides in some (handwaves) way to better indicate the desired match I like this idea better. AutoReq/Prov should only search system-wide deafult search paths for .so's, perl modules, and any other such objects that it supports. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 09:42:38AM -0500, Chris Adams wrote: Once upon a time, Chuck Anderson c...@wpi.edu said: b.2) extend the autorequires/autoprovides in some (handwaves) way to better indicate the desired match I like this idea better. AutoReq/Prov should only search system-wide deafult search paths for .so's, perl modules, and any other such objects that it supports. That breaks things, because a program in /usr/bin may require a module or library in a private directory. You have to search all directories for provides to satisfy internal requires. If a program in /usr/bin requires something in a private, non-system directory that is provided by a different package, then the provides/requires need to express that somehow, perhaps by using a full path in the provides. Until that becomes possible, I'm inclined to say that AutoReq/Prov shouldn't be searching private directories, and we should require all packages that have such requirements to use manual Requires: on either the file path or the package that provides the private library. Keeping things the way they are now is just plain broken. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 11:00:06AM -0500, Chris Adams wrote: Once upon a time, Chuck Anderson c...@wpi.edu said: On Wed, Jun 17, 2009 at 09:42:38AM -0500, Chris Adams wrote: That breaks things, because a program in /usr/bin may require a module or library in a private directory. You have to search all directories for provides to satisfy internal requires. If a program in /usr/bin requires something in a private, non-system directory that is provided by a different package, then the provides/requires need to express that somehow, perhaps by using a full path in the provides. I was talking about in the same package. For example, MRTG installs in /usr/bin/mrtg, and then needs private perl modules. If you simply remove the private directories, you'll end up with broken dependencies because /usr/bin/mrtg needs modules that are not provided anywhere. I don't see why. You would obviously filter out the Requires as well as the Provides. Those files are in the same package as the binary, so they'll always be there when the package is installed. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 10:50:43PM -0400, Bill Nottingham wrote: Chuck Anderson (c...@wpi.edu) said: system-wide includes paths mentioned in /etc/ld.so.conf.d/*, which are files provided by other packages. Suddenly your search scope is unbounded again. Not really unbounded. If a package puts a file in /etc/ld.so.conf.d/ then the library is now available system-wide, so it should be searched by autorequires/autoprovides. The package that puts the file in ld.so.conf.d and the package that puts libraries into the location specified in that file may not be the same package, and actually may have no dependencies between them at all... Do we have any examples of that? I'd be inclined to say if there are a very few cases where one package provides an ld.so.conf.d file that ends up being used by many other packages, we should just put that path into the system default /etc/ld.so.conf, so it is always present. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packaging web applications, SELinux
On Tue, Jun 16, 2009 at 04:46:00PM +0100, Paul Howarth wrote: On 16/06/09 16:34, Chuck Anderson wrote: Is there any pointer to best practices for packing a web application that provides static content, cgi scripts, integrates with Apache configuration, and works with SELinux? How should I package the SELinux policy needed to make this work? The Packaging Guidelines mention Web Applications, but not how to make them work with SELinux: https://fedoraproject.org/wiki/Packaging/Guidelines#Web_Applications Do you already have the policy for your webapp written? If so, you can proceed according to https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft but better still would be to post your policy on fedora-selinux-list for comment and get it merged into the main Fedora policy and upstream. No policy yet. I think I just need file_contexts to go along with the standard ones: /srv/([^/]*/)?www(/.*)? system_u:object_r:httpd_sys_content_t:s0 /var/www(/.*)? system_u:object_r:httpd_sys_content_t:s0 /var/www(/.*)?/logs(/.*)? system_u:object_r:httpd_log_t:s0 /var/www/[^/]*/cgi-bin(/.*)?system_u:object_r:httpd_sys_script_exec_t:s0 /var/www/perl(/.*)? system_u:object_r:httpd_sys_script_exec_t:s0 /var/www/icons(/.*)?system_u:object_r:httpd_sys_content_t:s0 /var/www/html/[^/]*/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t:s0 /var/www/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t:s0 I found that Debian has pretty well-defined (draft) guidelines for web applications: http://webapps-common.alioth.debian.org/draft/html/ that standardizes on /usr/share/PACKAGE/www for static content and /usr/lib/cgi-bin/PACKAGE for arch-dependent dynamically executed content. If we could come up with a similiar standard, then we could add standard SELinux file_contexts to deal with it, such as: /usr/share/[^/]*/www(/.*)? system_u:object_r:httpd_sys_content_t:s0 /usr/share/[^/]*/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t:s0 /usr//lib(64)?/[^/]*/cgi-bin(/.*)? system_u:object_r:httpd_sys_script_exec_t:s0 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: iptables/firewall brainstorming
On Sun, Jun 14, 2009 at 12:30:41PM -0600, Kevin Fenzi wrote: On Sun, 14 Jun 2009 18:34:52 +0100 Matthew Garrett m...@redhat.com wrote: On Sun, Jun 14, 2009 at 06:13:51PM +0200, Julian Aloofi wrote: So, solving this is pretty easy, even for newbies. But I agree that the error message will not help someone without advanced knowledge. Although I think people running Samba generally will know where to look for the problem. I think this is actually a problem that needs solving. We have several network services that are either installed by default or might be expected to be part of a standard setup, but which don't work because of the default firewall rules. The Anaconda people have (sensibly, IMHO) refused to simply add further exceptions to the firewall policy. So, what should happen here? Should we leave the firewall enabled in these cases* by default and require admins to open them? If so, is there any way that we can make this easier in some Packagekit-oriented manner? If not, how should we define that packages indicate that they need ports opened? Should this be handled at install time or run time? * The case that I keep hitting is mDNS resolution, which requires opening a hole in the firewall For the case of mDNS resolution, we should create a nf_conntrack module to track outbound requests and allow the related replies back in. This case is identical to the Samba browsing case where we created nf_conntrack_netbios_ns [1]. We need a nf_conntrack_mdns too. I keep wondering if we couldn't come up with something like a /etc/iptables.d/ type setup somehow that would work for these cases. That might be a good idea for services, but for clients (Samba NetBIOS browsing, mDNS, other client-initiated broadcast/multicast-based browsing or discovery protocols) we should just unconditionally install and enable iptables conntrack modules to handle them by default [1] [2]. Clients should just work out-of-the-box without requiring any user configuration. [1] https://bugzilla.redhat.com/show_bug.cgi?id=113918 [2] https://bugzilla.redhat.com/show_bug.cgi?id=469884 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
On Sun, Jun 14, 2009 at 10:45:09AM -0400, Simo Sorce wrote: * Samba (outbound) browsing requires firewall mods I don't know how Samba works, so forgive me if I say obvious stupidity, but shouldn't *client* work even behind closed firewall (like with any other services like ssh, ftp, ...)? Isn't this a samba bug then? Samba as a client needs to listen for Netbios packets replies (UDP) to do browsing, so since F-10 (yes this is not something new in F-11) the firewall has strict rules and there is a samba client specific rule. ...which is broken in that it is too permissive, and in that it isn't enabled by default. We need to fix it so it only uses the conntrack module but doesn't open inbound ports, and also enable it in the default install. https://bugzilla.redhat.com/show_bug.cgi?id=469884 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Announcing Fedora Activity Day - Fedora Development Cycle 2009
On Thu, Jun 04, 2009 at 10:56:34AM -0400, Seth Vidal wrote: On Thu, 4 Jun 2009, Tom \spot\ Callaway wrote: On 06/03/2009 07:48 PM, Chuck Anderson wrote: Not necessarily. I don't see why the Fedora Project couldn't qualify as a Sponsored Participant on Internet2 [1]. In fact, Red Hat is already connected in Raleigh. I think this is because they're technically on NC State University. and last time I checked it's a 100mbit connection to i2. Well, they are listed as Red Hat on the Internet2 map. Time to upgrade to Gig :-) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Announcing Fedora Activity Day - Fedora Development Cycle 2009
On Mon, Jun 01, 2009 at 06:45:07PM -0400, Tom spot Callaway wrote: On 06/01/2009 06:45 PM, Jesse Keating wrote: If we had I2 in PHX this would get a lot faster. We just need to hold some classes and get the PHX datacenter certified as a University. ;) Not necessarily. I don't see why the Fedora Project couldn't qualify as a Sponsored Participant on Internet2 [1]. In fact, Red Hat is already connected in Raleigh. I'd gladly help pursue this, but I may not be the right person seeing as I'm in Boston, not PHX. I2 also has a private lambda service where you can get your own dedicated 10Gig wavelength across the backbone [2]. It seems they are currently offering no-fee trials of this service to I2 connectors. Arizona State University is already on I2 via CENIC, and CENIC offers this Dynamic Circuit capability. MCNC in Durham where Red Hat is connected doesn't appear to have DCN though. [1] http://www.internet2.edu/network/participants/ Sponsored participants are individual educational institutions (including not-for-profit and for-profit K-20, technical, and trade schools), museums, art galleries, libraries, hospitals, as well as other non-educational, not-for-profit or for-profit organizations that require routine collaboration on instructional, clinical, and/or research projects, services, and content with Primary participants or with other Sponsored Participants. Such organizations typically are either not eligible or not able to become Internet2 members. [2] http://www.internet2.edu/network/dc/ To support the development, deployment, and use of innovative hybrid optical networking capabilities, Internet2 is initiating a no-fee trial of the Internet2 DCN. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
