Re: MariaDB and Fedora
On 12/10/2009 09:01 PM, Pete Zaitcev wrote: On Thu, 10 Dec 2009 15:38:10 -0200 Henrique Juniorhenrique...@gmail.com wrote: I agree that postgresql is great, but MariaDB is expanding very fast. I'm not the best person to opine about databases, my experience is very limited, but it would be nice to keep an eye on MariaDB. Well, duh. Who's going to maintain it though? There must be a warm body. I for one care much more about Drizzle than about MariaDB. From what I can tell MariaDB is basically just a new storage engine inside the old crufty MySQL shell whereas Drizzle is a (much needed) overhaul of the whole thing. Much more interesting for future projects if you ask me. Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 06:49 PM, 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? Why shouldn't he? AFAIK there is nothing in the package warning users not to install this on a server. What is the appropriate way to audit this kind of stuff? Presuming that PackageKit uses PolicyKit to aquire the necessary privileges is there a way to query PolicyKit and ask show me all instances where a process can acquire root privileges without being asked for a password? I don't think it's a good idea to rely on admins knowing the magic handshake (or in this case the magic package list of dangerous apps) for security. Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 07:05 PM, Seth Vidal wrote: 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. 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? I think the existence of PolicyKit actually could allow us to query it in the way i mentioned in my previous mail and get a quick picture of the privileges applications have access to. Consider it the PK equivalent of scanning your filesystems for setuid files. Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 07:30 PM, Seth Vidal wrote: 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. Changing policy is not the same as introducing a problem. There should at least be a process for packages to go through if they want to make changes like PackageKit did so that this kind of thing shows up on peoples radars earlier can be peer-reviewed and if necessary be mentioned in the release-notes. Also these changes should probably not be introduced for updates between releases. My basic point is that changes that allow packages to elevate their privileges should set of some process based formal alarm when they are introduced rather than being discovered by accident after a release. Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: cpio to ext4 seems much slower than to ext2, ext3 or xfs
On 11/12/2009 04:03 PM, Eric Sandeen wrote: Richard W.M. Jones wrote: On Thu, Nov 12, 2009 at 09:54:12AM +, Daniel P. Berrange wrote: On Wed, Nov 11, 2009 at 09:05:20PM +, Richard W.M. Jones wrote: On Wed, Nov 11, 2009 at 01:24:20PM -0600, Eric Sandeen wrote: Anybody got actual numbers? I don't disagree that mkfs.ext4 is slow in the default config, but I don't think it should be slower than mkfs.ext3 for the same sized disks. Easy with guestfish: $ guestfish --version guestfish 1.0.78 $ for fs in ext2 ext3 ext4 xfs jfs ; do guestfish sparse /tmp/test.img 10G : run : echo $fs : sfdiskM /dev/sda , : time mkfs $fs /dev/sda1 ; done ext2 elapsed time: 5.21 seconds ext3 elapsed time: 7.87 seconds ext4 elapsed time: 6.10 seconds xfs elapsed time: 0.45 seconds jfs elapsed time: 0.78 seconds Note that because this is using a sparsely allocated disk each write to the virtual disk is very slow. Change 'sparse' to 'alloc' to test this with a non-sparse file-backed disk. You really want to avoid using sparse files at all when doing any kind of benchmark / performance tests in VMs. The combo of a sparse file store on a journalling filesystem in the host, w/ virt can cause very pathelogically bad I/O performance until the file has all its extents fully allocated on the host FS. So the use of a sparse file may well be exagarating the real difference in elapsed time between these different mkfs calls in the guest. Again, this time backed by a 10 GB logical volume in the host, so this should remove pretty much all host effects: $ for fs in ext2 ext3 ext4 xfs jfs reiserfs nilfs2 ntfs msdos btrfs hfs hfsplus gfs gfs2 ; do guestfish add /dev/mapper/vg_trick-Temp : run : zero /dev/sda : echo $fs : sfdiskM /dev/sda , : time mkfs $fs /dev/sda1 ; done ext2 elapsed time: 3.48 seconds ext3 elapsed time: 5.45 seconds ext4 elapsed time: 5.19 seconds so here we have ext4 slightly faster, which was the original question... ;) (dropping caches in between might be best, too...) xfs elapsed time: 0.35 seconds jfs elapsed time: 0.66 seconds reiserfs elapsed time: 0.73 seconds nilfs2 elapsed time: 0.19 seconds ntfs elapsed time: 2.33 seconds msdos elapsed time: 0.29 seconds btrfs elapsed time: 0.16 seconds hfs elapsed time: 0.44 seconds hfsplus elapsed time: 0.46 seconds gfs elapsed time: 1.60 seconds gfs2 elapsed time: 3.98 seconds I'd like to repeat my proviso: I think this test is meaningless for most users. Until users have 8TB raids at home, which is not really that far off ... Let's hope btrfs is production ready before then because extX doesn't look like a fitting filesystem for such big drives due their lack of online fsck. Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: cpio to ext4 seems much slower than to ext2, ext3 or xfs
On 11/12/2009 05:59 PM, Eric Sandeen wrote: Dennis J. wrote: On 11/12/2009 04:03 PM, Eric Sandeen wrote: Richard W.M. Jones wrote: ... I'd like to repeat my proviso: I think this test is meaningless for most users. Until users have 8TB raids at home, which is not really that far off ... Let's hope btrfs is production ready before then because extX doesn't look like a fitting filesystem for such big drives due their lack of online fsck. ext4's fsck is much faster than ext3's, and xfs's repair tool is also pretty speedy. Both are offline, but so far online fsck for btrfs is just a goal, no (released, anyway) code yet AFAIK. Isn't the speed improvement of ext4 achieved by not dealing with empty extends/blocks? If so that wouldn't help you much if those 8TB are really used. But even a speedy fsck is going to take longer and longer as filesystem size grows which is why I believe we will soon reach a point were offline-fsck simply isn't a viable option anymore. I have a 30TB storage system that I chopped into ten individual volumes because current filesystems don't really make creating a single 30TB fs a wise choice even though I'd like to be able to do that. Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dhclient and dhcp update require restart?
On 08/27/2009 07:49 PM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 26 Aug 2009, Dariusz J. Garbowski wrote: Hi, something that bothers me a bit... More and more system restart requests with each update (even if one doesn't use the package at the time). Is this necessary for dhclient and dhcp update packages to require restart? Wouldn't service network restart and service dhcpd restart in the install/upgrade scripts do the trick (after checking that the service is actually running)? Ssh used to do that since, well, as far as I remember. Yes, 'service dhcpd restart' will work fine for dhcpd. For dhclient, it's not necessarily as simple as restarting the network service. If you are using the network service, that will work fine. If you are using NetworkManager, you'll need to either restart NetworkManager or have it down the connection you're using dhclient on and bring it back up. Why is a restart of NetworkManager necessary in this case? If dhclient reinitializes the interface and gets the old dhcp data then nothing really changes and NetworkManager shouldn't have to care. If e.g. der IP changes then NetworkManager should detect that and reinitialize the connection info on its end (after all the new interface might not be connected to anything and thus have to be marked as down anyway). Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GRUB 2 in Ubuntu 9.10
On 06/10/2009 10:43 AM, Christopher Brown wrote: 2009/6/10 King InuYashangomp...@gmail.com: I would like to see GRUB Legacy replaced in Fedora 12 with GRUB 2, especially with a couple odd systems here that don't seem to like GRUB Legacy all that much Actually the reverse is true, in that you will find that GRUB 2 will support fewer machines than GRUB Legacy. This is why, as the ubuntu page quite correctly states, upgrading a bootloader is at best frightening and risky. So what is the deal with GRUB development? I find it strange that upstream already has declared the old GRUB Legacy even though GRUB 2 isn't ready for prime time yet. Has the patch for full ext4 support that has been mentioned before landed in upstream yet? What is the timetable to get GRUB 2 ready for primetime? Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gnaughty is a hot babe
On 05/29/2009 04:34 PM, Bill Nottingham wrote: Dennis J. (denni...@conversis.de) said: I wrote a proposal https://fedoraproject.org/wiki/PackagingDrafts/InappropriateContents I don't think you can just flag Packages as inappropriate because everyone has his own definition for that term. If you really want to make this work you'll have to create specific classifications like nudity or violence so people can make informed decisions. People might be ok with violent content but not nudity. When I see a Package marked only as inappropriate that doesn't help me to tell whether *I* would find that inappropriate or not. At which point, you need some sort of review board, where then every package gets something like: - TuxPaint is rated E for Everyone - quake3 is rated T for violent content - tcl is rated M for inappropriate language I'm going to go out on a limb and claim we don't have the resources to coherently do this. I don't see why we would need a review board. Just add a guideline asking packagers to tag their packages if they think the contents could be inappropriate out of courtesy toward their fellow community members. If some packagers don't give a damn then that's fine and not a lot can be done about that but why not give the community the tools to self regulate? Just because there is a general guideline does not mean there has to be enforcement through an iron-fisted review board. Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gnaughty is a hot babe
On 05/29/2009 05:02 PM, Seth Vidal wrote: On Fri, 29 May 2009, Toshio Kuratomi wrote: On 05/29/2009 02:10 AM, Muayyad AlSadi wrote: The problem with a comps group is that it will lead to having a group in graphical installers although in ojuba we use ourown comps files, but this is a catastrophe because they are merged! I guess there is an option for hidden groups Have these packages: Provides: policy(adult content) And have a package that's mandatory in your respin that has: Conflicts: policy(adult content) /me taking one of the good ideas from the flag debate. Except it is obvious that something contains a flag or not. Labeling certain content 'questionable' is going to end up being all over the distro and diluting the value of the tag. Let me put it this way - if we start randomly rating things in a provides tag and gnaughty or hot-babe or pr0n-comfort get labeled this way then I'll make sure I personally add the same tag to: - firefox - yum - sword - gnome-sword So the reason you acted in a benevolent way in this community is only because it didn't give you an opening and the moment that happens you promise to attack it? While I'm in general agreement that censorship in any form is bad that's a pretty sad statement to make. Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gnaughty is a hot babe
On 05/29/2009 06:48 PM, Bill Nottingham wrote: Dennis J. (denni...@conversis.de) said: At which point, you need some sort of review board, where then every package gets something like: - TuxPaint is rated E for Everyone - quake3 is rated T for violent content - tcl is rated M for inappropriate language I'm going to go out on a limb and claim we don't have the resources to coherently do this. I don't see why we would need a review board. Just add a guideline asking packagers to tag their packages if they think the contents could be inappropriate out of courtesy toward their fellow community members. If some packagers don't give a damn then that's fine and not a lot can be done about that but why not give the community the tools to self regulate? Just because there is a general guideline does not mean there has to be enforcement through an iron-fisted review board. Without some sort of standards, the tags would likely become meaningless to rely on in practice. (See also: the RPM Group tag.) Then let the people who are affected with this come up with a proposal and deal with it on it's technical merits. There is no enforcement involved. If that proposal is too difficult/complex to implement it can be rejected. If a packager is unwilling to put such a classification in his package then it's up to the people concerned to work it out. Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: gnaughty is a hot babe
On 05/28/2009 01:06 PM, Simon Wesp wrote: Michael Flemingmflem...@thatfleminggent.com wrotes: MF Hm. interesting case. MF I've got no problem with it. Unlike hot-babe there's nothing even MF remotely resembling depiction here. personally I am torn between 'go' and 'no-go' the guidelines says: Content must not be pornographic, or contain nudity, whether animated, simulated, or photographed. There are better places on the Internet to get porn. my pro: this package is free of pornographic content. hotbabe isn't free of this content. Why quote the guidline if it clearly doesn't apply in this case? my contra: it helps you to get this stuff. An instigator for a murder is guilty like the murderer himself! Murder is a crime, pornography isn't so this comparison doesn't make much sense. Also Firefox helps you to get this stuff too so if that's a reason for banning this package then you'd have to ban a lot of other software from Fedora too. I don't see much of a controversy here. The package doesn't try to deceive anyone about it's intentions and doesn't contain any objectionable material itself. Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
