Very much agreed that package managers really ought to support (by default IMO!) the ability to install to a user's homedir, whether or not that user has the ability to perform a system-wide install. I'm fed up of having to install stuff from source (without dependency management) just because I only want something in ~/.
High-level package managers generally don't expose that functionality because many packages aren't really built to expect it. In theory packages should be perfectly relocatable, but in practice most maintainers never test installing them anywhere but / , and they tend to do things based on the assumption they'll be installed to / and by a process with root privileges (for instance, updating certain databases in %post scripts wouldn't make much sense for a package being installed as a user).
If you want to dice with death, though:), you can do it via rpm. 'rpm --root ~/some_directory -Uvh (packages)' should do the trick. You can also do it with yum - 'yum --installroot=~/somedirectory'. I haven't tried this, so I'm not sure what gotchas are involved, but the concept is there.
i'd be happy if they fixed the checksum file which incorrectly states the sha256 hashes are sha1.
It doesn't. It states that the signature on the CHECKSUM file is SHA-1, which it is. The file is signed with an SHA-1 signature, the checksums themselves are SHA-256. This is admittedly somewhat confusing, and will be changed to be less so in Fedora 13. But it's not incorrect.
How many security fixes do Red Hat and Novell backport to their enterprise distributions, which frequently run "old" software (relative to Ubuntu/Fedora)?
All fixes for known vulnerabilities in supported packages in supported releases. That's kind of a big part of the definition of 'support', really.
So redhat still plans on making this change. They are just waiting till they implement the GUI to easily change a user's role.
Well, um, then it's not going to be the *same* change, is it? The point is that you'll be able to choose what kind of role a new user account has, and hence what actions it'll be able to do. A regular, non-admin user account won't be able to install software this way.
In which case I've lost my mind and apologise. I took the first RPM from rawhide 0xFFFF-0.3.9-4.fc12.x86_64.rpm and tested to see if it was signed. It was, but this doesn't seem to be universal, so you're right, and I'm entirely wrong.
Most packages in the current 'Rawhide' are still packages from the final F12 release, and hence signed. If you check a package with an fc13 tag - i.e. one built since F12 went out - you'll see it's not signed.
There was a full package set rebuild during the F12 cycle, before the beta release, so by the time F12 Beta came out, just about every package in Rawhide had been rebuilt since F11's release, and hence was unsigned.
I submitted the initial story, but they edited it a bit a before publication. I'm _sure_ it didn't have three 'controvers*' in it, but I can't prove it to you, I didn't keep a copy of my submission. It _was_ pretty late last night. Usually I'd shoot myself in the head before writing something that inelegant.:)
"The compromise should of been allowing admin's to white-list a subset of the signed packages that they want to allow all users unrestricted access to."
if the admin's going to go to all the trouble of whitelisting a subset of signed packages, why not just...install them? It's not like disk space is expensive. Also, I don't know a lot of admins who would welcome the prospect of trying to evaluate a list of around 10,000 packages as a great way to spend their weekend...
The initial change was discussed in public - on the PackageKit mailing list - and implemented over a year ago. PackageKit is an upstream project, used by multiple distributions, and this change was implemented in PackageKit (although, of course, the upstream author who proposed and coded the change works for Red Hat); it's come to light in Fedora 12 because it's the first distribution to actually use a version of PackageKit ported to PolicyKit 1.
I'm curious as to how you expect an idea to be "squashed 5 minutes after it was proposed" as a result of Fedora "open[ing] up their decision making process" - how does a more open process lead to faster decisions? In all the experience I've ever had, the result is true. Having an open review process - which Fedora does - results in slightly slower decisions but, hopefully, more ultimately correct ones. I know which I'd choose.
There are potential process improvements here - there's a proposal to have a consistent policy for privileges granted via PolicyKit, for instance - but it's really not as simple as 'open up their decision making process'. It's pretty darn open already.
Though fedora emphasizes 'su' style privilege escalation which has no granularity, 'sudo' style gives the granularity required.
Um. You didn't research this very thoroughly, did you?
The whole basis for the introduction of this issue is the use of PolicyKit, which is massively more flexible and fine-grained than su *or* sudo. Both su or sudo can only run entire processes as a different UID, and have fairly limited authentication method choices. PolicyKit allows far more fine-grained granting of escalated privileges; that's the whole point of using it in PackageKit, the main PackageKit GUI process runs as an unprivileged user and PolicyKit is used to grant escalated privileges only to a subsidiary process which actually does the package installation. PolicyKit also allows far more flexibility in terms of the exact type of authentication required for any given action.
Basically, PolicyKit has all the flexibility sudo has, and far far more. Seriously, go do some reading.
Non of the beta testers noticed it and thought it might be an issue?
Nope, because packages in the development repositories are not signed until very shortly before release. No-one testing the beta would have seen this bug, because they'd never have installed a signed package.
Um. The comment on the bug report which kicked all this off - "Seems to work: but why am I not getting a root password prompt?" - is dated 2009-11-18 07:47:19 EDT. The email announcing that the policy will be tightened is dated Thu, 19 Nov 2009 21:29:19 (again ET). That's a response time of 37 hours, 42 minutes, by my count. I think you'd find that's...really quite fast.:)
Important note: the policy in question will be changed, likely with an update to be issued tomorrow. The new policy will be more restrictive than that in Fedora 11 (it will require root authentication for each package installation operation). Please see the official announcement and the more extensive fedora-devel-list post for more details.
Thanks.
marciot: regular users have always been able to execute arbitrary code with their own privileges, in any distribution. they just install it to their home directory.
It's a fairly large jump from 'grub2 isn't in Fedora 12' to 'Red Hat doesn't care about booting from 4TiB disks in the year 2014', isn't it? You might want to wait a bit and see what happens before you leap too many tall buildings in search of your conclusion.:)
All true, but that's not what Paul was initially talking about; he was talking about things like copyrighted driver firmware, which some people want Fedora to distribute. I already mentioned in another reply that there's _different_ reasons why we don't distribute various different components.
Re:it didn't detect my usb mouse so i can't instal
on
Fedora 12 Released
·
· Score: 1
I think that's a general problem with unetbootin. We'd recommend using livecd-iso-to-disk or liveusb-creator to create the image. You can actually just dd the image onto a USB stick and it should work, but that's a new feature for F12 and not heavily tested yet.
Re:1GHz Pentium 3 with 512MB of RAM
on
Fedora 12 Released
·
· Score: 2, Insightful
'lightness' is a function of the software you have installed, not the distribution you're running. A 'light' distribution might make it easier to achieve a 'light' package load out and, yes, there are a few dependency choices a 'light' distribution might make differently, but it's nothing really deal breaking. You could run Fedora - or another 'big' distribution, like Mandriva or Ubuntu - perfectly well on such a system, if you make sensible application choices. You might want to look at LXDE as a desktop, Midori as a browser, claws or something of its ilk as a mail client...look for lighter applications than the typically omnivorous Firefox, Thunderbird / Evolution and so on.
(having said that, I ran Mandriva with GNOME and Evo / Firefox all the way up to GNOME 2.12 on a system with 192MB of RAM. It did require a bit of patience at times.:>)
Fedora is not RHEL. The original poster was correct. Fedora is its own product, and it is not intended to be a server distribution. It is expressly mainly a desktop distribution. Nothing to do with servers is anywhere on the list of important things that need to work in a Fedora release, for instance. I haven't spent the last few weeks up till three AM trying to get fixes for bugs in apache.:)
Re:Ubuntu influence on marketing materials
on
Fedora 12 Released
·
· Score: 1
Not really sure, then. I'm not going to go around making any absolute declarations as I haven't used Ubuntu for several releases. I just found the five minutes number unusual, and not something I see around here. Not going to say yum is faster than apt-get, it may well not be, but it's certainly fast enough not to cause me any particular pain.
it's a fairly fine distinction at that point. frankly, what _any_ distro ships for a kernel (except, perhaps, Slackware) bears rather small resemblance to the upstream kernel tarball with the same version number (don't believe me, grab any Ubuntu, SUSE or Mandriva kernel and count the patches). Given that, it's not something I lie awake at nights worrying about. I tend to care more about whether it works.
Re:Ubuntu influence on marketing materials
on
Fedora 12 Released
·
· Score: 1
you _are_ using a network-based package manager while the servers are being heavily spammed by people downloading the release. Aside from that...was that your first yum operation on a new install? I've never seen it go anywhere near that long except when it's first building the metainformation for newly configured repositories (i.e. just after install). It doesn't take that long on my 1.33GHz Atom with 4200RPM hard disk.
Oh, yes? Are you a lawyer? Have you heard of the doctrine of contributory copyright infringement? Fedora's legal team has, which is why they're decidedly dicey about that sort of thing.
That said, there are several proprietary drivers which are perfectly legally redistributable - NVIDIA, AMD, Broadcom's own driver, for instance. Fedora does not distribute or implement a button for these not because it would be legally problematic but because it would be at odds with the Fedora project's philosophy and goals, as I mentioned in an earlier comment.
Re:Huh, they're using the Nouveau driver...
on
Fedora 12 Released
·
· Score: 1
Do you have a bug filed?
I use nouveau all day every day and never have had it crash on me (had a few other bugs in the past, which I filed and Ben resolved.) If this were happening to all nouveau users I'd expect to have got a few more reports of it by now (I triage the nouveau bugs myself), so I think it's specific to your hardware.
"How about rolling the bugs forward if they still exist in the newest version."
That's exactly what happens, if they are known to exist in the newest version. When a release is going EOL a warning is added to the bug that it will be closed in a month if we don't get information that it's still valid with a supported release. If no-one confirms the bug is still valid in the new release, how are we to know? The Bugzappers team is a dozen or so volunteers, not dozens of paid full-time staff; we can hardly go through several hundred bugs manually trying to reproduce each one to determine what to do with it. And a lot of them are hardware or configuration specific and there's not enough information in the bug report to reliably reproduce them in any case.
When bugs are eventually closed, the closure message specifically states that they can be re-opened if they are found to affect a currently-supported release.
Slashdot Mirror
Very much agreed that package managers really ought to support (by default IMO!) the ability to install to a user's homedir, whether or not that user has the ability to perform a system-wide install. I'm fed up of having to install stuff from source (without dependency management) just because I only want something in ~/.
High-level package managers generally don't expose that functionality because many packages aren't really built to expect it. In theory packages should be perfectly relocatable, but in practice most maintainers never test installing them anywhere but / , and they tend to do things based on the assumption they'll be installed to / and by a process with root privileges (for instance, updating certain databases in %post scripts wouldn't make much sense for a package being installed as a user). If you want to dice with death, though :), you can do it via rpm. 'rpm --root ~/some_directory -Uvh (packages)' should do the trick. You can also do it with yum - 'yum --installroot=~/somedirectory'. I haven't tried this, so I'm not sure what gotchas are involved, but the concept is there.
i'd be happy if they fixed the checksum file which incorrectly states the sha256 hashes are sha1.
It doesn't. It states that the signature on the CHECKSUM file is SHA-1, which it is. The file is signed with an SHA-1 signature, the checksums themselves are SHA-256. This is admittedly somewhat confusing, and will be changed to be less so in Fedora 13. But it's not incorrect.
How many security fixes do Red Hat and Novell backport to their enterprise distributions, which frequently run "old" software (relative to Ubuntu/Fedora)?
All fixes for known vulnerabilities in supported packages in supported releases. That's kind of a big part of the definition of 'support', really.
So redhat still plans on making this change. They are just waiting till they implement the GUI to easily change a user's role.
Well, um, then it's not going to be the *same* change, is it? The point is that you'll be able to choose what kind of role a new user account has, and hence what actions it'll be able to do. A regular, non-admin user account won't be able to install software this way.
In which case I've lost my mind and apologise. I took the first RPM from rawhide 0xFFFF-0.3.9-4.fc12.x86_64.rpm and tested to see if it was signed. It was, but this doesn't seem to be universal, so you're right, and I'm entirely wrong.
Most packages in the current 'Rawhide' are still packages from the final F12 release, and hence signed. If you check a package with an fc13 tag - i.e. one built since F12 went out - you'll see it's not signed. There was a full package set rebuild during the F12 cycle, before the beta release, so by the time F12 Beta came out, just about every package in Rawhide had been rebuilt since F11's release, and hence was unsigned.
Do /. writers get paid by "controversy"?
I submitted the initial story, but they edited it a bit a before publication. I'm _sure_ it didn't have three 'controvers*' in it, but I can't prove it to you, I didn't keep a copy of my submission. It _was_ pretty late last night. Usually I'd shoot myself in the head before writing something that inelegant. :)
"The compromise should of been allowing admin's to white-list a subset of the signed packages that they want to allow all users unrestricted access to."
if the admin's going to go to all the trouble of whitelisting a subset of signed packages, why not just...install them? It's not like disk space is expensive. Also, I don't know a lot of admins who would welcome the prospect of trying to evaluate a list of around 10,000 packages as a great way to spend their weekend...
The initial change was discussed in public - on the PackageKit mailing list - and implemented over a year ago. PackageKit is an upstream project, used by multiple distributions, and this change was implemented in PackageKit (although, of course, the upstream author who proposed and coded the change works for Red Hat); it's come to light in Fedora 12 because it's the first distribution to actually use a version of PackageKit ported to PolicyKit 1.
I'm curious as to how you expect an idea to be "squashed 5 minutes after it was proposed" as a result of Fedora "open[ing] up their decision making process" - how does a more open process lead to faster decisions? In all the experience I've ever had, the result is true. Having an open review process - which Fedora does - results in slightly slower decisions but, hopefully, more ultimately correct ones. I know which I'd choose.
There are potential process improvements here - there's a proposal to have a consistent policy for privileges granted via PolicyKit, for instance - but it's really not as simple as 'open up their decision making process'. It's pretty darn open already.
Though fedora emphasizes 'su' style privilege escalation which has no granularity, 'sudo' style gives the granularity required.
Um. You didn't research this very thoroughly, did you?
The whole basis for the introduction of this issue is the use of PolicyKit, which is massively more flexible and fine-grained than su *or* sudo. Both su or sudo can only run entire processes as a different UID, and have fairly limited authentication method choices. PolicyKit allows far more fine-grained granting of escalated privileges; that's the whole point of using it in PackageKit, the main PackageKit GUI process runs as an unprivileged user and PolicyKit is used to grant escalated privileges only to a subsidiary process which actually does the package installation. PolicyKit also allows far more flexibility in terms of the exact type of authentication required for any given action.
Basically, PolicyKit has all the flexibility sudo has, and far far more. Seriously, go do some reading.
Non of the beta testers noticed it and thought it might be an issue?
Nope, because packages in the development repositories are not signed until very shortly before release. No-one testing the beta would have seen this bug, because they'd never have installed a signed package.
"(even though it took a while)"
Um. The comment on the bug report which kicked all this off - "Seems to work: but why am I not getting a root password prompt?" - is dated 2009-11-18 07:47:19 EDT. The email announcing that the policy will be tightened is dated Thu, 19 Nov 2009 21:29:19 (again ET). That's a response time of 37 hours, 42 minutes, by my count. I think you'd find that's...really quite fast. :)
Important note: the policy in question will be changed, likely with an update to be issued tomorrow. The new policy will be more restrictive than that in Fedora 11 (it will require root authentication for each package installation operation). Please see the official announcement and the more extensive fedora-devel-list post for more details. Thanks.
I'm not a Fedora user. Does Fedora not package daemons such that they are added to the appropriate runlevel automatically when installed?
No. By policy, daemons which would be open to external access should not be enabled by default upon installation in Fedora.
marciot: regular users have always been able to execute arbitrary code with their own privileges, in any distribution. they just install it to their home directory.
It's a fairly large jump from 'grub2 isn't in Fedora 12' to 'Red Hat doesn't care about booting from 4TiB disks in the year 2014', isn't it? You might want to wait a bit and see what happens before you leap too many tall buildings in search of your conclusion. :)
All true, but that's not what Paul was initially talking about; he was talking about things like copyrighted driver firmware, which some people want Fedora to distribute. I already mentioned in another reply that there's _different_ reasons why we don't distribute various different components.
I think that's a general problem with unetbootin. We'd recommend using livecd-iso-to-disk or liveusb-creator to create the image. You can actually just dd the image onto a USB stick and it should work, but that's a new feature for F12 and not heavily tested yet.
'lightness' is a function of the software you have installed, not the distribution you're running. A 'light' distribution might make it easier to achieve a 'light' package load out and, yes, there are a few dependency choices a 'light' distribution might make differently, but it's nothing really deal breaking. You could run Fedora - or another 'big' distribution, like Mandriva or Ubuntu - perfectly well on such a system, if you make sensible application choices. You might want to look at LXDE as a desktop, Midori as a browser, claws or something of its ilk as a mail client...look for lighter applications than the typically omnivorous Firefox, Thunderbird / Evolution and so on.
(having said that, I ran Mandriva with GNOME and Evo / Firefox all the way up to GNOME 2.12 on a system with 192MB of RAM. It did require a bit of patience at times. :>)
Fedora is not RHEL. The original poster was correct. Fedora is its own product, and it is not intended to be a server distribution. It is expressly mainly a desktop distribution. Nothing to do with servers is anywhere on the list of important things that need to work in a Fedora release, for instance. I haven't spent the last few weeks up till three AM trying to get fixes for bugs in apache. :)
Not really sure, then. I'm not going to go around making any absolute declarations as I haven't used Ubuntu for several releases. I just found the five minutes number unusual, and not something I see around here. Not going to say yum is faster than apt-get, it may well not be, but it's certainly fast enough not to cause me any particular pain.
it's a fairly fine distinction at that point. frankly, what _any_ distro ships for a kernel (except, perhaps, Slackware) bears rather small resemblance to the upstream kernel tarball with the same version number (don't believe me, grab any Ubuntu, SUSE or Mandriva kernel and count the patches). Given that, it's not something I lie awake at nights worrying about. I tend to care more about whether it works.
you _are_ using a network-based package manager while the servers are being heavily spammed by people downloading the release. Aside from that...was that your first yum operation on a new install? I've never seen it go anywhere near that long except when it's first building the metainformation for newly configured repositories (i.e. just after install). It doesn't take that long on my 1.33GHz Atom with 4200RPM hard disk.
Oh, yes? Are you a lawyer? Have you heard of the doctrine of contributory copyright infringement? Fedora's legal team has, which is why they're decidedly dicey about that sort of thing. That said, there are several proprietary drivers which are perfectly legally redistributable - NVIDIA, AMD, Broadcom's own driver, for instance. Fedora does not distribute or implement a button for these not because it would be legally problematic but because it would be at odds with the Fedora project's philosophy and goals, as I mentioned in an earlier comment.
Do you have a bug filed?
I use nouveau all day every day and never have had it crash on me (had a few other bugs in the past, which I filed and Ben resolved.) If this were happening to all nouveau users I'd expect to have got a few more reports of it by now (I triage the nouveau bugs myself), so I think it's specific to your hardware.
"How about rolling the bugs forward if they still exist in the newest version."
That's exactly what happens, if they are known to exist in the newest version. When a release is going EOL a warning is added to the bug that it will be closed in a month if we don't get information that it's still valid with a supported release. If no-one confirms the bug is still valid in the new release, how are we to know? The Bugzappers team is a dozen or so volunteers, not dozens of paid full-time staff; we can hardly go through several hundred bugs manually trying to reproduce each one to determine what to do with it. And a lot of them are hardware or configuration specific and there's not enough information in the bug report to reliably reproduce them in any case.
When bugs are eventually closed, the closure message specifically states that they can be re-opened if they are found to affect a currently-supported release.