FWIW I downloaded the F14 Beta-rc3 i686 liveCD to run it through a few basic desktop tests, and there was one apparent hiccup.

When I turned on the printer, the system correctly identified my printer -- an HP Deskjet F4180 with an integrated flatbed scanner -- and automatically found and installed the necessary driver(s) and dependencies. However when I tried to use "simple scan" it still insisted that it couldn't find a connected scanner, or that maybe it wasn't turned on (ie. it was connected and turned on.) I have xSane installed on my F12 system, and as I recall all I did during the post-install process was install xSane, and the scanner (and printer) worked fine from the get-go.

Other mundane tests I did (I know that these aren't the tests asked for, but then why do outside clients contract Jamie and Adam from Mythbusters to test their "things" outside of the confines of the show? For the unconventional testing approach they'll use, or in my case here, the mundane approach. :) ) :

- on the login screen, I changed the language to English (Canada) -- successful - on the login screen, I changed the keyboard to Canada French (Legacy) -- successful, and the layout worked once logged in, the correct characters were where they were supposed to be - once I logged in with the liveuser account, I changed the screen resolution to 1280x1024 -- successful - Firefox booted and brought up the usual first time Firefox page, and in a second tab the Fedora search page -- successful - Vinagre was tested to VNC into my home server's desktop through the home network -- successful - Terminal: top command -- successful - Terminal: ifconfig -- successful - Terminal: su command -- successful, but I found it unnerving that there isn't a password for the root account; I suppose that assigning a root password and publicizing it may actually be worse than not assigning one at all, since some person will be lulled into thinking "oh well it's password protected" not realizing that in not changing it, any cracker who somehow manages to get into the system by whatever means would easily try the password announced in the same place that innocent liveCD users would find it: on a public web page!

Regards

On Tue, 2010-09-21 at 23:55 -0500, Iván Jiménez wrote:

I had the same problem in f13 and solved it by installing the package libsane-hpaio. I think it should be documented somewhere.

It should likely be reported as a bug :) Thanks!

Adam, on the presumption that your smiley was intended to convey a message of "well, now's the best time to report bugs, not after the release of the final product and hordes of people complain rather loudly" as opposed to "please don't bother, we *know* that *already*", I submitted the bug; here's the linky:

https://bugzilla.redhat.com/show_bug.cgi?id=636491

On Wed, 2010-09-22 at 09:03 +0100, Adam Williamson wrote:

On Tue, 2010-09-21 at 23:55 -0500, Iván Jiménez wrote:

...

I had the same problem in f13 and solved it by installing the package libsane-hpaio. I think it should be documented somewhere.

It should likely be reported as a bug :) Thanks!

Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net

-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop

On Wed, Sep 22, 2010 at 09:05:37 +0100, Adam Williamson awilliam@redhat.com wrote:

There's that, and logically speaking there's absolutely no reason to have a root password on a live image. You need to be able to boot the machine to run a live image, and any machine you can boot is a machine on which you have root access (it's trivial enough to find some kind of bootable media which gives you 'root' of some kind, or even to build your own).

The assumption that the person potentially getting root is able to boot the system is not be correct in all use cases.

On a live image with an encrypted, persistent /home, you could in theory let someone else use the image after it was booted. (Who wouldn't be able to get /home mounted on their own.) They might not even being physically present at the machine the image is running on.

If there is a compromise, not having a root password makes it trivial to escalate the compromise to root access.

I think in situations where firstboot is run on live images, it probably is reasonable to set a root password.

On Wed, 2010-09-22 at 08:56 -0500, Bruno Wolff III wrote:

The assumption that the person potentially getting root is able to boot the system is not be correct in all use cases.

On a live image with an encrypted, persistent /home, you could in theory let someone else use the image after it was booted. (Who wouldn't be able to get /home mounted on their own.) They might not even being physically present at the machine the image is running on.

I think we work on the basis that this is not at all the typical use case for a live image, and that if you were doing that, you'd probably know you should set a root password. Why would you do that, btw?

On Wed, Sep 22, 2010 at 15:11:02 +0100, Adam Williamson awilliam@redhat.com wrote:

I think we work on the basis that this is not at all the typical use case for a live image, and that if you were doing that, you'd probably know you should set a root password. Why would you do that, btw?

I agree it's not typical and we don't want it on the published live images.

With a persistent /home I care a bit more about the image getting hosed than otherwise. I think this will mitigate the affects of some compromises. (Though the hope is that those don't happen at all.)

There might also be a case where I'd want someone to be able to use the booted system breifly by switching users rather than taking the time for a reboot. But I haven't had that show up yet.

On Wed, Sep 22, 2010 at 11:02:23 -0400, Bill Nottingham notting@redhat.com wrote:

Bruno Wolff III (bruno@wolff.to) said:

...

...

firstboot never runs on live images. Only after installation.

It ran on one I made a couple of weeks ago. I assumed that was because livecd-iso-to-disk checked for a /home partition and changed things to run firstboot. But maybe that was a bug?

I suspect it was a bug with systemd integration, in that the livecd init script wasn't properly disabling the systemd firstboot unit.

OK. That's too bad, I kind of liked the idea after I got over the surprise.

case for a live image, and that if you were doing that, you'd probably know you should set a root password. Why would you do that, btw?

I'm trying to think outside of the box, and sometimes I'm having difficulty doing so because for most of the scenarios I'm thinking of, most people doing so would also know to set a root password. But along the lines of playing devil's advocate:

You're using the liveCD to do some system rescue work for a friend, and enable desktop control by an external source, say to work in tandem with someone else. Perhaps you even get an SSH server going. The system in question has valuable, at least to the owner, files on it. You have a direct internet connection and no router to "protect you behind a NAT", and your partner is at another location. A bot sniffs the IP and bang, gets in either by SSH root login, or VNC's into the desktop and starts up a terminal.

Of course it would be irresponsible of you to not have set up a root password in advance, given that you're supposed to be the expert in system recovery and at least some system security, but ...

And then there's the newbie who just "wants to try it out" without harming their Windows setup, and sees the settings for "let others control the desktop", thinking "ooooh, what does this do?" Click!