3:44 p.m.
Hi
Root login has been disabled in GDM for a while now in rawhide. Would
KDM and other display managers be modified to be consistent with this
behavior? I would prefer if it was.
Rahul
3:57 p.m.
On Wed, Sep 19, 2007 at 02:14:28AM +0530, Rahul Sundaram wrote:
Hi
Root login has been disabled in GDM for a while now in rawhide. Would KDM
and other display managers be modified to be consistent with this behavior?
I would prefer if it was.
wdm uses pam for those kind of things, is there a pam module that can
disable root login?
--
Pat
4:14 p.m.
On Tue, 2007-09-18 at 22:57 +0200, Patrice Dumas wrote:
On Wed, Sep 19, 2007 at 02:14:28AM +0530, Rahul Sundaram wrote:
> Hi
>
> Root login has been disabled in GDM for a while now in rawhide. Would KDM
> and other display managers be modified to be consistent with this behavior?
> I would prefer if it was.
wdm uses pam for those kind of things, is there a pam module that can
disable root login?
For example pam_succeed_if.
auth required pam_succeed_if.so user != root quiet
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
6:20 p.m.
Tomas Mraz wrote:
For example pam_succeed_if.
auth required pam_succeed_if.so user != root quiet
This would prevent root logins from ssh and the console too.
Such direct root logins make sense for server-only systems,
which don't normally have (or need) user accounts.
--
// Bernardo Innocenti - http://www.codewiz.org/
\X/ One Laptop Per Child - http://www.laptop.org/
6:50 p.m.
On Tue, 2007-09-18 at 19:20 -0400, Bernardo Innocenti wrote:
Tomas Mraz wrote:
> For example pam_succeed_if.
>
> auth required pam_succeed_if.so user != root quiet
This would prevent root logins from ssh and the console too.
Not if you put the directive in the xdm/kdm/*dm specific pam file, it
doesn't have to be in the common file
Simo.
7:04 a.m.
Rex Dieter wrote:
Rahul Sundaram wrote:
> Root login has been disabled in GDM for a while now in rawhide. Would
> KDM and other display managers be modified to be consistent with this
> behavior? I would prefer if it was.
What's the rationale (again?) for disabling root login?
See fedora-desktop list discussions. The goal IIUC was to discourage
root login via display managers since there isn't normally a reason to
do that and it presents a higher security risk. This has also been a
often requested feature in the past and with the introduction of Policy
Kit makes it even more sense to do so. Users who are inclined to ignore
this safeguard can always turn the option on.
Rahul
7:23 a.m.
Denis Leroy wrote:
Rahul Sundaram wrote:
> since there isn't normally a reason to do that
I beg to differ here, that are many scenarios where the security issues
are irrelevant. I see such systems on a daily basis here at work.
You snipped out the later part of my mail. If security concerns are
irrelevant, just turn on the option to enable root login just like you
are free to turn off the firewall or SELinux.
KDM root login was disabled until the last release anyway.
Rahul
7:36 a.m.
Rahul Sundaram wrote:
Denis Leroy wrote:
> Rahul Sundaram wrote:
>> since there isn't normally a reason to do that
>
> I beg to differ here, that are many scenarios where the security
> issues are irrelevant. I see such systems on a daily basis here at work.
You snipped out the later part of my mail. If security concerns are
irrelevant, just turn on the option to enable root login just like you
are free to turn off the firewall or SELinux.
Is that an anaconda option ? Obviously it's impossible to run gdmsetup
since one can't login as root :-)
7:39 a.m.
Denis Leroy wrote:
Rahul Sundaram wrote:
> Denis Leroy wrote:
>> Rahul Sundaram wrote:
>>> since there isn't normally a reason to do that
>>
>> I beg to differ here, that are many scenarios where the security
>> issues are irrelevant. I see such systems on a daily basis here at work.
>
> You snipped out the later part of my mail. If security concerns are
> irrelevant, just turn on the option to enable root login just like you
> are free to turn off the firewall or SELinux.
Is that an anaconda option ? Obviously it's impossible to run gdmsetup
since one can't login as root :-)
Why would it be impossible? Anaconda allows to set a root password and
first boot asks for setting up a normal user. Login via the normal user
and use su to run gdmsetup or switch to a virtual terminal and login as
root.
Rahul
7:49 a.m.
Rahul Sundaram wrote:
Denis Leroy wrote:
> Rahul Sundaram wrote:
>> Denis Leroy wrote:
>>> Rahul Sundaram wrote:
>>>> since there isn't normally a reason to do that
>>>
>>> I beg to differ here, that are many scenarios where the security
>>> issues are irrelevant. I see such systems on a daily basis here at
>>> work.
>>
>> You snipped out the later part of my mail. If security concerns are
>> irrelevant, just turn on the option to enable root login just like
>> you are free to turn off the firewall or SELinux.
>
> Is that an anaconda option ? Obviously it's impossible to run gdmsetup
> since one can't login as root :-)
Why would it be impossible? Anaconda allows to set a root password and
first boot asks for setting up a normal user. Login via the normal user
and use su to run gdmsetup or switch to a virtual terminal and login as
root.
Creating a normal user is not mandatory in anaconda (as it should be).
Maybe anaconda should only enable the option if no normal users were
creating during installation ? The idea here is to avoid a scenario
where after a successful X installation you just can't login into the
system!
7:53 a.m.
Denis Leroy wrote:
Creating a normal user is not mandatory in anaconda (as it should be).
Maybe anaconda should only enable the option if no normal users were
creating during installation ? The idea here is to avoid a scenario
where after a successful X installation you just can't login into the
system!
There was some discussions in fedora-desktop list into moving this
option away from first boot into Anaconda itself so that this would be
mandatory. This is indeed a good thing to do in this instance. Do file a
RFE in Anaconda. The idea was to entirely get rid of first boot if
possible in the desktop spin.
Rahul
8 a.m.
On Wed, Sep 19, 2007 at 06:23:28PM +0530, Rahul Sundaram wrote:
There was some discussions in fedora-desktop list into moving this
option away from first boot into Anaconda itself so that this would be
mandatory. This is indeed a good thing to do in this instance. Do file a
RFE in Anaconda. The idea was to entirely get rid of first boot if
If you file an RFE please post the number here so I can attach a violent
disagreement to the bug
8:51 a.m.
On Wed, 19 Sep 2007 09:00:58 -0400
Alan Cox <alan(a)redhat.com> wrote:
On Wed, Sep 19, 2007 at 06:23:28PM +0530, Rahul Sundaram wrote:
> There was some discussions in fedora-desktop list into moving this
> option away from first boot into Anaconda itself so that this would
> be mandatory. This is indeed a good thing to do in this instance.
> Do file a RFE in Anaconda. The idea was to entirely get rid of
> first boot if
If you file an RFE please post the number here so I can attach a
violent disagreement to the bug
My suggested method was that you were presented with a user add option
in anaconda, but the ability to opt out (for say network login
systems). If you opt-out then the no root login policy could be
lifted, but if you opt-in and create a local user then only that local
user would be allowed to graphical log in upon boot (unless you
manually change policy through a gui tool or a hand edit.)
--
Jesse Keating
Fedora -- All my bits are free, are yours?
9 a.m.
On Tue, Sep 18, 2007 at 09:51:49AM -0400, Jesse Keating wrote:
On Wed, 19 Sep 2007 09:00:58 -0400
My suggested method was that you were presented with a user add option
in anaconda, but the ability to opt out (for say network login
systems). If you opt-out then the no root login policy could be
lifted, but if you opt-in and create a local user then only that local
Will this be integrated with all the display managers (xdm, wdm, kdm
and the other one I don't remember its name but I reviewed it)?
--
Pat
3:24 p.m.
On Tue, Sep 18, 2007 at 09:51:49AM -0400, Jesse Keating wrote:
My suggested method was that you were presented with a user add
option
in anaconda, but the ability to opt out (for say network login
systems). If you opt-out then the no root login policy could be
lifted, but if you opt-in and create a local user then only that local
user would be allowed to graphical log in upon boot (unless you
manually change policy through a gui tool or a hand edit.)
But... how do you plan on fixing a system when networking is broken and
one cannot login as root anymore?
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <zyntrop(a)kvack.org>.
3:26 p.m.
Benjamin LaHaise wrote:
On Tue, Sep 18, 2007 at 09:51:49AM -0400, Jesse Keating wrote:
> My suggested method was that you were presented with a user add option
> in anaconda, but the ability to opt out (for say network login
> systems). If you opt-out then the no root login policy could be
> lifted, but if you opt-in and create a local user then only that local
> user would be allowed to graphical log in upon boot (unless you
> manually change policy through a gui tool or a hand edit.)
But... how do you plan on fixing a system when networking is broken and
one cannot login as root anymore?
Login as regular user and use su or switch to a VT. Ctl+Alt+F1
Rahul
8:42 a.m.
On 9/19/07, Alan Cox <alan(a)redhat.com> wrote:
On Wed, Sep 19, 2007 at 06:23:28PM +0530, Rahul Sundaram wrote:
> There was some discussions in fedora-desktop list into moving this
> option away from first boot into Anaconda itself so that this would be
> mandatory. This is indeed a good thing to do in this instance. Do file a
> RFE in Anaconda. The idea was to entirely get rid of first boot if
If you file an RFE please post the number here so I can attach a violent
disagreement to the bug
Alan, we are trying to improve the experience for the specific
audience of artists, developers and the like who download the Desktop
Live image from the web site and want to install it on a laptop or
home PC. No one is saying that all these changes are applicable to
every situation in which Linux is used.
No one is advocating taking away the old style Linux installation (the
Fedora "choose your own adventure" DVD).
8:58 a.m.
On Wed, Sep 19, 2007 at 09:42:35AM -0400, Colin Walters wrote:
Alan, we are trying to improve the experience for the specific
audience of artists, developers and the like who download the Desktop
Live image from the web site and want to install it on a laptop or
home PC. No one is saying that all these changes are applicable to
every situation in which Linux is used.
I appreciate that, but its often being done in a way that is so narrow
minded you could see stereo through a keyhole.
No one is advocating taking away the old style Linux installation
(the
Fedora "choose your own adventure" DVD).
And my violent objection would be to forcing the creation of a local user
account IFF the user has not selected any remote authentication scheme. If
I've not ticked any of ldap, nis, .. etc then its a very good idea to be
extremely clear to the user that they want a non root account.
Alan
9:04 a.m.
On 9/19/07, Alan Cox <alan(a)redhat.com> wrote:
And my violent objection would be to forcing the creation of a local user
account IFF the user has not selected any remote authentication scheme.
As the desktop spin is designed for home users on laptops, I don't
think it should offer remote authentication as an option during
installation at all, so there is no failure scenario here. For people
who want to set up labs of Fedora desktop machines - that's what the
DVD and kickstart files are for.
9:11 a.m.
On Wed, Sep 19, 2007 at 10:04:59AM -0400, Colin Walters wrote:
As the desktop spin is designed for home users on laptops, I
don't
think it should offer remote authentication as an option during
installation at all, so there is no failure scenario here. For people
who want to set up labs of Fedora desktop machines - that's what the
DVD and kickstart files are for.
Insert clue:
I have a laptop and desktop boxes. I have better things to do that download
two sets of media. (and no the laptop doesn't have a DVD drive, and yes its
less than 12 months old)
Alan
9:21 a.m.
On 9/19/07, Alan Cox <alan(a)redhat.com> wrote:
On Wed, Sep 19, 2007 at 10:04:59AM -0400, Colin Walters wrote:
> As the desktop spin is designed for home users on laptops, I don't
> think it should offer remote authentication as an option during
> installation at all, so there is no failure scenario here. For people
> who want to set up labs of Fedora desktop machines - that's what the
> DVD and kickstart files are for.
Insert clue:
I have a laptop and desktop boxes. I have better things to do that download
two sets of media. (and no the laptop doesn't have a DVD drive, and yes its
less than 12 months old)
You're running an enterprise network in your house, I understand.
Personally, I think that's a huge amount of pain (especially for
laptops) just so that your passwords are synchronized, but I'll accept
that you want to do it =)
Anyways, you don't actually need to download the full DVD. You can
also just download the boot.iso, and point it at a kickstart file that
has all your NIS information filled in, what packages you want, etc.
http://docs.fedoraproject.org/install-guide/f7/en_US/sn-automating-instal...
10:22 a.m.
Alan Cox wrote:
On Wed, Sep 19, 2007 at 10:04:59AM -0400, Colin Walters wrote:
> As the desktop spin is designed for home users on laptops, I don't
> think it should offer remote authentication as an option during
> installation at all, so there is no failure scenario here. For people
> who want to set up labs of Fedora desktop machines - that's what the
> DVD and kickstart files are for.
>
Insert clue:
I have a laptop and desktop boxes. I have better things to do that download
two sets of media. (and no the laptop doesn't have a DVD drive, and yes its
less than 12 months old)
Alan
+1
Plus too many option for users means too many things can go wrong....
So keeping simple set of installation-images ( we should not start to
release fedora-desktop, fedora-server,fedora-laptop,
fedora-blue,fedora-black etc etc.. )
and rather let the user choose what *type* of fedora he wants in Anaconda...
Best regards
Johann B.
--
Johann B. Gudmundsson. RHCE,CCSA
Unix System Engineer.
IT Management.
Reiknistofnun University of Iceland.
Taeknigardi, Dunhaga 5. Email: johannbg(a)hi.is
IS-107 Reykjavik. Phone: +354-525-4267
Iceland. Fax: +354-552-8801
2:10 a.m.
2007/9/19, "Jóhann B. Guðmundsson" <johannbg(a)hi.is>:
Alan Cox wrote:
> On Wed, Sep 19, 2007 at 10:04:59AM -0400, Colin Walters wrote:
>
>> As the desktop spin is designed for home users on laptops, I don't
>> think it should offer remote authentication as an option during
>> installation at all, so there is no failure scenario here. For people
>> who want to set up labs of Fedora desktop machines - that's what the
>> DVD and kickstart files are for.
>>
>
> Insert clue:
>
> I have a laptop and desktop boxes. I have better things to do that download
> two sets of media. (and no the laptop doesn't have a DVD drive, and yes its
> less than 12 months old)
>
> Alan
>
>
+1
Plus too many option for users means too many things can go wrong....
So keeping simple set of installation-images ( we should not start to
release fedora-desktop, fedora-server,fedora-laptop,
fedora-blue,fedora-black etc etc.. )
and rather let the user choose what *type* of fedora he wants in Anaconda...
+10
having 20 different official spins with completly different selectable
options and settings not only cofuses the users... it especially
confuses the people that try to support the newcomers e.g. on irc. if
one wanted to help one had to really try out all of those spins to be
able to help properly.... cant become more confusing in my eyes...
regards,
Rudolf Kastl
Best regards
Johann B.
--
Johann B. Gudmundsson. RHCE,CCSA
Unix System Engineer.
IT Management.
Reiknistofnun University of Iceland.
Taeknigardi, Dunhaga 5. Email: johannbg(a)hi.is
IS-107 Reykjavik. Phone: +354-525-4267
Iceland. Fax: +354-552-8801
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
9:41 a.m.
On Wed, 2007-09-19 at 10:04 -0400, Colin Walters wrote:
As the desktop spin is designed for home users on laptops, I
don't
think it should offer remote authentication as an option during
installation at all, so there is no failure scenario here. For people
who want to set up labs of Fedora desktop machines - that's what the
DVD and kickstart files are for.
Desktop != home users. If anything, home users are just a subset of
desktop users. Besides, with the trend in today's houses is towards
networking all equipment, it's not unheard of for mom to log in on the
kitchen computer to view her recipes.
At my place, all the Desktops (that's laptops as well as desktops) were
configured to authenticate from a central server.
Going back to the install option, it does make sense to make "local
account setup" and "network authentication" an OR proposal (at least one
has to be configured but the other would be optional).
--
Richi Plana
10:50 a.m.
On 9/19/07, Richi Plana <myfedora(a)richip.dhs.org> wrote:
At my place, all the Desktops (that's laptops as well as
desktops) were
configured to authenticate from a central server.
That's great. If you are running this sort of complex home
networking, know how to set up servers and NIS etc., then the choose
your own adventure DVD or boot.iso, combined with kickstart files are
appropriate for you.
3:17 p.m.
On Wed, 2007-09-19 at 11:50 -0400, Colin Walters wrote:
That's great. If you are running this sort of complex home
networking, know how to set up servers and NIS etc., then the choose
your own adventure DVD or boot.iso, combined with kickstart files are
appropriate for you.
There's nothing complex about it, and as I mentioned, it's becoming the
standard these days to have multiple computers and networked homes.
Say what you will, but I doubt configuring network authentication at
install-time will go away. First of all, it's already there and it's
non-intrusive. Even inexperienced installers aren't stymied by it
(though I would agree to a message stating "If you don't know what this
is, then don't ignore it"). Second, there are just too many people who
use Fedora now who need it. People who actually use Fedora are likely to
use that option or wish they did.
If anyone can show that having the option to configure network
authentication at install-time is a bigger detriment compared to having
the current number of people who DO use it suddenly create their own
ISOs or kickstart files OR be forced to create local users other than
root when it's unnecessary, then it may get a chance at being adopted.
--
Richi Plana
8:08 a.m.
Rahul Sundaram wrote:
Denis Leroy wrote:
>
> Creating a normal user is not mandatory in anaconda (as it should be).
>
> Maybe anaconda should only enable the option if no normal users were
> creating during installation ? The idea here is to avoid a scenario
> where after a successful X installation you just can't login into the
> system!
There was some discussions in fedora-desktop list into moving this
option away from first boot into Anaconda itself so that this would be
mandatory.
Wait, make creating a normal user mandatory ?!? I don't know who's on
fedora-desktop, but it must be people with absolutely no real-life
experience with linux systems and how they're used.
Just ask your RHEL customers.
8:07 a.m.
Denis Leroy wrote:
Wait, make creating a normal user mandatory ?!? I don't know
who's on
fedora-desktop, but it must be people with absolutely no real-life
experience with linux systems and how they're used.
Just ask your RHEL customers.
Again, this is for the desktop spin. RHEL customers don't come into the
picture at all.
Rahul
9:09 a.m.
Rahul Sundaram wrote:
Denis Leroy wrote:
> Wait, make creating a normal user mandatory ?!? I don't know who's on
> fedora-desktop, but it must be people with absolutely no real-life
> experience with linux systems and how they're used.
>
> Just ask your RHEL customers.
Again, this is for the desktop spin. RHEL customers don't come into
the picture at all.
You mean RHEL customers don't come into the picture at all -- so far....
Spider pig,spider pig does whatever a spider pig does... :)
Best regards
Johann B.
--
Johann B. Gudmundsson. RHCE,CCSA
Unix System Engineer.
IT Management.
Reiknistofnun University of Iceland.
Taeknigardi, Dunhaga 5. Email: johannbg(a)hi.is
IS-107 Reykjavik. Phone: +354-525-4267
Iceland. Fax: +354-552-8801
9:12 a.m.
Jóhann B. Guðmundsson wrote:
Rahul Sundaram wrote:
> Denis Leroy wrote:
>
>> Wait, make creating a normal user mandatory ?!? I don't know who's on
>> fedora-desktop, but it must be people with absolutely no real-life
>> experience with linux systems and how they're used.
>>
>> Just ask your RHEL customers.
>
> Again, this is for the desktop spin. RHEL customers don't come into
> the picture at all.
>
You mean RHEL customers don't come into the picture at all -- so far....
When they do, they can send their feedback about it. This isn't the
forum for that.
Rahul
9:10 a.m.
On Wed, Sep 19, 2007 at 06:37:18PM +0530, Rahul Sundaram wrote:
Again, this is for the desktop spin. RHEL customers don't come
into the
picture at all.
Ahhhh. So it's to be a selling point for RHEL? "Look! Fedora's desktop spin
isn't useable here. Buy RHEL, will ya?"
Grrr.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:17 a.m.
Matthew Miller wrote:
On Wed, Sep 19, 2007 at 06:37:18PM +0530, Rahul Sundaram wrote:
> Again, this is for the desktop spin. RHEL customers don't come into the
> picture at all.
Ahhhh. So it's to be a selling point for RHEL? "Look! Fedora's desktop spin
isn't useable here. Buy RHEL, will ya?"
Grrr.
Can you try and be more reasonable?
Rahul
9:24 a.m.
On Wed, Sep 19, 2007 at 07:47:39PM +0530, Rahul Sundaram wrote:
>>Again, this is for the desktop spin. RHEL customers don't
come into the
>>picture at all.
>Ahhhh. So it's to be a selling point for RHEL? "Look! Fedora's desktop
spin
>isn't useable here. Buy RHEL, will ya?"
>Grrr.
Can you try and be more reasonable?
Probably. :) No coffee yet this morning. But what I meant was: just because
RHEL customers are an *example* of a class where this is obviously a bad
idea doesn't mean that it's not also a bad idea for Fedora users.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:19 a.m.
On Wed, Sep 19, 2007 at 07:47:39PM +0530, Rahul Sundaram wrote:
> >>Again, this is for the desktop spin. RHEL customers don't come into
> the
> >>picture at all.
> >Ahhhh. So it's to be a selling point for RHEL? "Look! Fedora's
desktop
> spin
> >isn't useable here. Buy RHEL, will ya?"
> >Grrr.
> Can you try and be more reasonable?
Probably. :) No coffee yet this morning. But what I meant was: just
because
RHEL customers are an *example* of a class where this is obviously a bad
idea doesn't mean that it's not also a bad idea for Fedora users.
Maybe Matthew was simply celebrating Talk Like a Pirate Day.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
novus ordo absurdum
9:45 a.m.
On Wed, 2007-09-19 at 10:24 -0400, Matthew Miller wrote:
On Wed, Sep 19, 2007 at 07:47:39PM +0530, Rahul Sundaram wrote:
> >>Again, this is for the desktop spin. RHEL customers don't come into the
> >>picture at all.
> >Ahhhh. So it's to be a selling point for RHEL? "Look! Fedora's
desktop spin
> >isn't useable here. Buy RHEL, will ya?"
> >Grrr.
> Can you try and be more reasonable?
Probably. :) No coffee yet this morning. But what I meant was: just because
RHEL customers are an *example* of a class where this is obviously a bad
idea doesn't mean that it's not also a bad idea for Fedora users.
I think what Rahul is trying to impress upon us is that RHEL is to be
treated like any other distro spinner out there. Fedora chooses its
default but makes it easy for anyone else to customize their spin as
they see it. They're also welcome to provide feedback. Fedora isn't
trying to be the perfect default. It's just chosen its target and allows
others to spin off of it.
--
Richi Plana
9:51 a.m.
Matthew Miller wrote:
Probably. :) No coffee yet this morning. But what I meant was: just because
RHEL customers are an *example* of a class where this is obviously a bad
idea doesn't mean that it's not also a bad idea for Fedora users.
Correct but just be direct and explain why it would be a bad idea for a
desktop spin of Fedora. That's more useful than talking about RHEL. We
all know the audience is different between these distributions.
Rahul
10:46 a.m.
On Wed, 2007-09-19 at 20:21 +0530, Rahul Sundaram wrote:
Matthew Miller wrote:
>
> Probably. :) No coffee yet this morning. But what I meant was: just because
> RHEL customers are an *example* of a class where this is obviously a bad
> idea doesn't mean that it's not also a bad idea for Fedora users.
Correct but just be direct and explain why it would be a bad idea for a
desktop spin of Fedora.
The desktop spin is the bad idea - A desktop/Single
user/single seat
system is just a setup of a modular OS/set of packages, just as is a
"universal server" or a "dedicated server".
I am pretty certain many Fedora users use Fedora for both situations and
consider a "mere desktop spin" a waste of time.
That's more useful than talking about RHEL. We
all know the audience is different between these distributions.
It is not.
- Otherwise EPEL would not exist.
- Those using RHEL @situation X (eg. @work) not unlikely are the same
people running Fedora @situation Y (eg. @home)
...
Ralf
11:42 a.m.
Ralf Corsepius wrote:
I am pretty certain many Fedora users use Fedora for both situations
and
consider a "mere desktop spin" a waste of time.
That's ok. We will know soon enough how much interest there is when
there is a general release of Fedora 8 and we get downloads and feedback.
> That's more useful than talking about RHEL. We
> all know the audience is different between these distributions.
It is not.
- Otherwise EPEL would not exist.
- Those using RHEL @situation X (eg. @work) not unlikely are the same
people running Fedora @situation Y (eg. @home)
Your own example of running Fedora at home and RHEL at work is exactly
the different kind of roles and expectations that I was talking about.
Rahul
8:22 p.m.
On Wed, 2007-09-19 at 22:12 +0530, Rahul Sundaram wrote:
Ralf Corsepius wrote:
> I am pretty certain many Fedora users use Fedora for both situations and
> consider a "mere desktop spin" a waste of time.
That's ok. We will know soon enough how much interest there is when
there is a general release of Fedora 8 and we get downloads and feedback.
>> That's more useful than talking about RHEL. We
>> all know the audience is different between these distributions.
> It is not.
> - Otherwise EPEL would not exist.
> - Those using RHEL @situation X (eg. @work) not unlikely are the same
> people running Fedora @situation Y (eg. @home)
Your own example of running Fedora at home and RHEL at work is exactly
the different kind of roles and expectations that I was talking about.
You violently don't want to understand, don't you?
The main reason why you probably won't find many RHEL installations
@home is it's price and this product's characteristics (bundled with
service, promise of long term support, lack of suitable applications for
use @home, ...).
"desktop-use vs. server-use" isn't the real difference between RHEL and
Fedora - Of cause, you'll find more "desktop use-cases" for Fedora, but
this is just because you'll find more desktop-installation than
server-installations in general.
Ralf
8:18 a.m.
On Thu, 2007-09-20 at 18:22 +0530, Rahul Sundaram wrote:
Ralf Corsepius wrote:
talking about.
>
> You violently don't want to understand, don't you?
I understand but completely disagree with you. I think you would find
very few agreeing with you that Fedora and RHEL does not play any
different roles.
Apparently you don't want to understand, that there is _NO_
fundamental technical difference in
- Installing a desktop in an office/workplace or at home.
- Installing fedora on a server or RHEL.
The only real difference are
* sys-administrational (service contracts)
* money-flow wise (Fedora users invest in man-power, RHEL users into RH
and man-power)
* RHEL's longevity promise - This is an advantage and disadvantage at
the same time.
* RHEL being non-free.
Ralf
8:22 a.m.
Ralf Corsepius wrote:
On Thu, 2007-09-20 at 18:22 +0530, Rahul Sundaram wrote:
> Ralf Corsepius wrote:
> talking about.
>> You violently don't want to understand, don't you?
> I understand but completely disagree with you. I think you would find
> very few agreeing with you that Fedora and RHEL does not play any
> different roles.
Apparently you don't want to understand, that there is _NO_
fundamental technical difference in
- Installing a desktop in an office/workplace or at home.
- Installing fedora on a server or RHEL.
Sure there is. Update policies, lifecycle etc. What applies to RHEL does
not necessarily apply to Fedora and vice versa. There are many technical
solutions that are done on a routine basis in RHEL that are completely
infeasible in Fedora.
* RHEL being non-free.
It's not.
Rahul
8:46 a.m.
On Thu, Sep 20, 2007 at 06:52:02PM +0530, Rahul Sundaram wrote:
Sure there is. Update policies, lifecycle etc. What applies to RHEL does
not necessarily apply to Fedora and vice versa. There are many technical
I use fedora rawhide and centos 4/5, and I don't see many differences,
except of course for the 2 items you mentioned above.
solutions that are done on a routine basis in RHEL that are
completely
infeasible in Fedora.
An example?
> * RHEL being non-free.
It's not.
At least there is openmotif. But openmotif, even if it is not OSI
compatible is not that non free.
--
Pat
8:53 a.m.
Patrice Dumas wrote:
On Thu, Sep 20, 2007 at 06:52:02PM +0530, Rahul Sundaram wrote:
> Sure there is. Update policies, lifecycle etc. What applies to RHEL does
> not necessarily apply to Fedora and vice versa. There are many technical
I use fedora rawhide and centos 4/5, and I don't see many differences,
except of course for the 2 items you mentioned above.
These two are very significant technical differences.
> solutions that are done on a routine basis in RHEL that are
completely
> infeasible in Fedora.
An example?
Majority of updates are backported patches to maintain ABI compatibility.
At least there is openmotif. But openmotif, even if it is not OSI
compatible is not that non free.
This is just a side effect of Fedora having it when RHEL 5 was branched
and doesn't really make RHEL non-free.
Rahul
9:03 a.m.
On Thu, Sep 20, 2007 at 07:23:11PM +0530, Rahul Sundaram wrote:
Patrice Dumas wrote:
> On Thu, Sep 20, 2007 at 06:52:02PM +0530, Rahul Sundaram wrote:
>> Sure there is. Update policies, lifecycle etc. What applies to RHEL does
>> not necessarily apply to Fedora and vice versa. There are many technical
> I use fedora rawhide and centos 4/5, and I don't see many differences,
> except of course for the 2 items you mentioned above.
These two are very significant technical differences.
Indeed, but do they get into line with respect with non root/root login
in dm issue?
Majority of updates are backported patches to maintain ABI
compatibility.
Ok, still the lifetime difference.
This is just a side effect of Fedora having it when RHEL 5 was
branched and
doesn't really make RHEL non-free.
I don't know exactly because I had no contact with the RHEL people in
charge of openmotif, but it is not completly clear that RHEL 6 will use
lesstif. As always I would apreciate more info on that, but...
--
Pat
9:12 a.m.
Patrice Dumas wrote:
On Thu, Sep 20, 2007 at 07:23:11PM +0530, Rahul Sundaram wrote:
> These two are very significant technical differences.
Indeed, but do they get into line with respect with non root/root login
in dm issue?
Nope but Ralf claimed that there are no significant technical
differences at all which is something I disagreed with. Besides the kind
of customers you target a commercial product with is not merely a matter
of technical differences. For various reasons, these distributions play
different roles.
> Majority of updates are backported patches to maintain ABI
compatibility.
Ok, still the lifetime difference.
I am not sure what you mean here. A distribution life cycle is not tied
to ABI compatibility.
I don't know exactly because I had no contact with the RHEL
people in
charge of openmotif, but it is not completly clear that RHEL 6 will use
lesstif. As always I would apreciate more info on that, but...
I believe these sort of changes are discussed only closer to the release
but you can ask Daniel Reik, riek AT redhat.com if this is something
that you need to know urgently.
Rahul
9:28 a.m.
On Thu, Sep 20, 2007 at 07:42:20PM +0530, Rahul Sundaram wrote:
I believe these sort of changes are discussed only closer to the release
but you can ask Daniel Reik, riek AT redhat.com if this is something that
you need to know urgently.
Not urgently, but for packages in EPEL and fedora it would be nice to
have consistent provides for Motif implementations, be it openmotif or
lesstif.
--
Pat
9:41 a.m.
Patrice Dumas wrote:
On Thu, Sep 20, 2007 at 07:42:20PM +0530, Rahul Sundaram wrote:
> I believe these sort of changes are discussed only closer to the release
> but you can ask Daniel Reik, riek AT redhat.com if this is something that
> you need to know urgently.
Not urgently, but for packages in EPEL and fedora it would be nice to
have consistent provides for Motif implementations, be it openmotif or
lesstif.
It is very much unlikely that RHEL will switch to lesstif in an update
so this is not going to happen in the short term atleast. RHEL 6 will
likely just inherit the Fedora changes.
Rahul
9:50 a.m.
On Thu, Sep 20, 2007 at 08:11:49PM +0530, Rahul Sundaram wrote:
Patrice Dumas wrote:
> On Thu, Sep 20, 2007 at 07:42:20PM +0530, Rahul Sundaram wrote:
>> I believe these sort of changes are discussed only closer to the release
>> but you can ask Daniel Reik, riek AT redhat.com if this is something that
>> you need to know urgently.
> Not urgently, but for packages in EPEL and fedora it would be nice to
> have consistent provides for Motif implementations, be it openmotif or
> lesstif.
It is very much unlikely that RHEL will switch to lesstif in an update so
this is not going to happen in the short term atleast.
It is about providing consistent virtual provides, not real provides. In
my opinion switching to openmotif in the middle of a RHEL release
wouldn't be good (not to mention that openmotif and lesstif aren't ABI
compatible). And this is something I care about only if lesstif isn't
used in RHEL 6.
RHEL 6 will likely
just inherit the Fedora changes.
That's what I would like to know.
--
Pat
10:08 a.m.
Patrice Dumas wrote:
It is about providing consistent virtual provides, not real provides. In
my opinion switching to openmotif in the middle of a RHEL release
wouldn't be good (not to mention that openmotif and lesstif aren't ABI
compatible). And this is something I care about only if lesstif isn't
used in RHEL 6.
> RHEL 6 will likely
> just inherit the Fedora changes.
That's what I would like to know.
I will ask and get back to you.
Rahul
9:12 a.m.
Patrice Dumas wrote:
On Thu, Sep 20, 2007 at 07:23:11PM +0530, Rahul Sundaram wrote:
> These two are very significant technical differences.
Indeed, but do they get into line with respect with non root/root login
in dm issue?
Nope but Ralf claimed that there are no significant technical
differences at all which is something I disagreed with. Besides the kind
of customers you target a commercial product with is not merely a matter
of technical differences. For various reasons, these distributions play
different roles.
> Majority of updates are backported patches to maintain ABI
compatibility.
Ok, still the lifetime difference.
I am not sure what you mean here. A distribution life cycle is not tied
to ABI compatibility.
I don't know exactly because I had no contact with the RHEL
people in
charge of openmotif, but it is not completly clear that RHEL 6 will use
lesstif. As always I would apreciate more info on that, but...
I believe these sort of changes are discussed only closer to the release
but you can ask Daniel Riek, riek AT redhat.com if this is something
that you need to know urgently.
Rahul
10:14 a.m.
On Thu, 2007-09-20 at 19:42 +0530, Rahul Sundaram wrote:
Patrice Dumas wrote:
> On Thu, Sep 20, 2007 at 07:23:11PM +0530, Rahul Sundaram wrote:
>> These two are very significant technical differences.
>
> Indeed, but do they get into line with respect with non root/root login
> in dm issue?
Nope but Ralf claimed that there are no significant technical
differences at all which is something I disagreed with. Besides the kind
of customers you target a commercial product with is not merely a matter
of technical differences. For various reasons, these distributions play
different roles.
What is significantly different between the situation
a secretary in an office desktop writing texts/browsing the web etc. is
in and those of your Grandmother/ your 10 year old son doing the same
@home?
None. In both situations you will need a sysadmin.
What is the difference between somebody archiving his photographs in a
database-server @home and somebody archiving his photographs in a
database-server @work?
None. Both servers contain valuable data, both servers need a fairly
high reliability.
What is more valuable? Your digital wedding holiday's photographs @home
or your latest RH work @RH?
>> Majority of updates are backported patches to maintain ABI
compatibility.
Irrelevant from a desktop USER's POV.
To them, what matters is "their application simply works".
Ralf
10:26 a.m.
Ralf Corsepius wrote:
On Thu, 2007-09-20 at 19:42 +0530, Rahul Sundaram wrote:
What is significantly different between the situation
a secretary in an office desktop writing texts/browsing the web etc. is
in and those of your Grandmother/ your 10 year old son doing the same
@home?
None. In both situations you will need a sysadmin.
I don't see either situations needing a sysadmin. My grandmother does
her work on her computer without requiring any sysadmin interaction for
the kind of routine tasks you refer to.
>>> Majority of updates are backported patches to maintain
ABI compatibility.
Irrelevant from a desktop USER's POV.
To them, what matters is "their application simply works".
Correct but the technical difference and the impact on the differences
between the roles they provide still stand. One example of the impact of
ABI compatibility is with ISV applications. In this instance, you can't
expect them to simply work in any distribution without an additional
explicit effort. I will leave the discussion at that.
Rahul
10:40 a.m.
On Thu, 2007-09-20 at 20:56 +0530, Rahul Sundaram wrote:
Ralf Corsepius wrote:
> On Thu, 2007-09-20 at 19:42 +0530, Rahul Sundaram wrote:
> What is significantly different between the situation
> a secretary in an office desktop writing texts/browsing the web etc. is
> in and those of your Grandmother/ your 10 year old son doing the same
> @home?
>
> None. In both situations you will need a sysadmin.
I don't see either situations needing a sysadmin. My grandmother does
her work on her computer without requiring any sysadmin interaction for
the kind of routine tasks you refer to.
C'mon, you are really being
rediculous.
>>>> Majority of updates are backported patches to
maintain ABI compatibility.
> Irrelevant from a desktop USER's POV.
>
> To them, what matters is "their application simply works".
Correct but the technical difference and the impact on the differences
between the roles they provide still stand. One example of the impact of
ABI compatibility is with ISV applications.
ISV apps != RHEL desktop.
In this instance, you can't
expect them to simply work in any distribution without an additional
explicit effort.
1. We talked about desktops and freedom, not about ISVs.
2. They could do so easily, if they wanted to.
Ralf
10:51 a.m.
Ralf Corsepius wrote:
On Thu, 2007-09-20 at 20:56 +0530, Rahul Sundaram wrote:
> Ralf Corsepius wrote:
>> On Thu, 2007-09-20 at 19:42 +0530, Rahul Sundaram wrote:
>> What is significantly different between the situation
>> a secretary in an office desktop writing texts/browsing the web etc. is
>> in and those of your Grandmother/ your 10 year old son doing the same
>> @home?
>>
>> None. In both situations you will need a sysadmin.
> I don't see either situations needing a sysadmin. My grandmother does
> her work on her computer without requiring any sysadmin interaction for
> the kind of routine tasks you refer to.
C'mon, you are really being rediculous.
This is not a argument.
>>>>> Majority of updates are backported patches to
maintain ABI compatibility.
>> Irrelevant from a desktop USER's POV.
>>
>> To them, what matters is "their application simply works".
> Correct but the technical difference and the impact on the differences
> between the roles they provide still stand. One example of the impact of
> ABI compatibility is with ISV applications.
ISV apps != RHEL desktop.
RHEL desktop has ISV applications and an important technical feature
enabling that to happen is ABI compatibility. I wasn't talking about any
one product. This applies to Windows as well.
> In this instance, you can't
> expect them to simply work in any distribution without an additional
> explicit effort.
1. We talked about desktops and freedom, not about ISVs.
2. They could do so easily, if they wanted to.
Without ABI compatibility ISV application have to continuously play
catchup which is far from easy and there is no incentive for them to do
so. Even not considering ISV applications, ABI compatibility can still
result in breakage. This happens quite often for GPL kernel modules not
merged upstream for example.
We were talking about whether RHEL plays a different role from Fedora
and whether there are significant technical differences in between them.
I have given examples of the differences and the impact on the roles
they play.
Rahul
11:57 a.m.
Le jeudi 20 septembre 2007 à 21:21 +0530, Rahul Sundaram a écrit :
We were talking about whether RHEL plays a different role from Fedora
and whether there are significant technical differences in between them.
I have given examples of the differences and the impact on the roles
they play.
You have given differences on the support model; they do not have to
translate in user interaction differences. Fedora does not aim to be the
anti-RHEL, there is significant feature overlap or Red Hat would not be
funding Fedora, so can we please stop using the RHEL scarecrow argument?
If the enterprise and home space were so different, Microsoft would not
have succeeded as wildly as it did. There are far more similarities than
differences, home users like stability too, and enterprise users do not
disdain pretty gui apps when they're done properly. And server-like home
appliances are inundating the market now.
Enterprise and home do not have the same priority order, but the items
on their priority lists are the same, and good software will register on
both (and likewise, bad software may be tolerated a bit longer in one
context, but that it fails to pass on the other should raise alarms)
Having narrow focus only leads to debacles like NetworkManager, where
it's belately realised a feature needs to be deployed everywhere after
all, but can't be because one set of constrains was deliberately ignored
at project start.
--
Nicolas Mailhot
12:01 p.m.
Nicolas Mailhot wrote:
Le jeudi 20 septembre 2007 à 21:21 +0530, Rahul Sundaram a écrit :
> We were talking about whether RHEL plays a different role from Fedora
> and whether there are significant technical differences in between them.
> I have given examples of the differences and the impact on the roles
> they play.
You have given differences on the support model; they do not have to
translate in user interaction differences. Fedora does not aim to be the
anti-RHEL, there is significant feature overlap or Red Hat would not be
funding Fedora, so can we please stop using the RHEL scarecrow argument?
ABI compatibility is not merely differences in support and definitely
does affect user interaction depending on the applications. I agree with
you however that Fedora does have overlap with RHEL and it is not anti
anything. You seem to be reading things I haven't said.
Rahul
8:53 a.m.
Ralf Corsepius wrote:
On Thu, 2007-09-20 at 18:52 +0530, Rahul Sundaram wrote:
> Ralf Corsepius wrote:
>> * RHEL being non-free.
> It's not.
Send me the CD's or provide the URL where I can get the binary or better
be quiet - You are spreading foul propaganda.
The absence of free binaries does not make a software non-free. You
better look up the definition of Free software.
Rahul
9:02 a.m.
On Thu, 20 Sep 2007 15:49:20 +0200
Ralf Corsepius <rc040203(a)freenet.de> wrote:
> > * RHEL being non-free.
>
> It's not.
Send me the CD's or provide the URL where I can get the binary or
better be quiet - You are spreading foul propaganda.
Again language problem. Ralf is speaking of "free" as in money, where
Rahul is defending "free" as in software.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
9:06 a.m.
On Thu, 2007-09-20 at 15:49 +0200, Ralf Corsepius wrote:
Send me the CD's or provide the URL where I can get the binary
or
better
be quiet - You are spreading foul propaganda.
You better calm down Ralf.
This is not the tone of a civil discussion, and you should also read the
Free Software definition or the OSI guidelines, before accusing people.
Simo.
9:14 a.m.
On Thu, Sep 20, 2007 at 03:49:20PM +0200, Ralf Corsepius wrote:
On Thu, 2007-09-20 at 18:52 +0530, Rahul Sundaram wrote:
> Ralf Corsepius wrote:
> > * RHEL being non-free.
>
> It's not.
Send me the CD's or provide the URL where I can get the binary or better
be quiet - You are spreading foul propaganda.
Since it is free software, you can use respins like centos, although
RHEL is not really free.
--
Pat
9:20 a.m.
On Thu, 20 Sep 2007 16:14:54 +0200
Patrice Dumas <pertusus(a)free.fr> wrote:
Since it is free software, you can use respins like centos, although
RHEL is not really free.
There is additional software you have access to as a RHEL customer that
is in fact non-free software. However this software is not part of the
RHEL distribution, it is akin to an addon repository through RHN. The
RHEL distribution (as it currently sits, say RHEL4/5) is in fact free
software.
Unless you had some other thoughts as to what makes rhel non-free.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
8:14 a.m.
On Wed, 2007-09-19 at 15:08 +0200, Denis Leroy wrote:
> There was some discussions in fedora-desktop list into moving
this
> option away from first boot into Anaconda itself so that this would be
> mandatory.
Wait, make creating a normal user mandatory ?!? I don't know who's on
fedora-desktop, but it must be people with absolutely no real-life
experience with linux systems and how they're used.
Thanks for bringing the thread down to this level so quickly, that
allows us all to move on to more useful thing faster...
Anyway, why don't you come over to fedora-desktop and find out who
"those people" are ?
9:06 a.m.
Rahul Sundaram wrote:
Denis Leroy wrote:
>
> Creating a normal user is not mandatory in anaconda (as it should be).
>
> Maybe anaconda should only enable the option if no normal users were
> creating during installation ? The idea here is to avoid a scenario
> where after a successful X installation you just can't login into the
> system!
There was some discussions in fedora-desktop list into moving this
option away from first boot into Anaconda itself so that this would be
mandatory. This is indeed a good thing to do in this instance. Do file
a RFE in Anaconda. The idea was to entirely get rid of first boot if
possible in the desktop spin.
User should be able to turn on/off/enable/disable services ( the
service's that aren't the mandatory one's ) in Anaconda
If I like/dislike some service being started after installation I could
enable/disable those service's during the installation *faze* be it
firstboot, cups, bluetooth, hplip,ip6tables etc.
Best regards
Johann B.
--
Johann B. Gudmundsson. RHCE,CCSA
Unix System Engineer.
IT Management.
Reiknistofnun University of Iceland.
Taeknigardi, Dunhaga 5. Email: johannbg(a)hi.is
IS-107 Reykjavik. Phone: +354-525-4267
Iceland. Fax: +354-552-8801
9:52 a.m.
On Wed, 2007-09-19 at 14:06 +0000, "Jóhann B. Guðmundsson" wrote:
User should be able to turn on/off/enable/disable services ( the
service's that aren't the mandatory one's ) in Anaconda
Beg to disagree. Anaconda should just concentrate on getting the real
Fedora image installed so that it becomes the running system (its kernel
and filesystem is used). You can argue for it at firstboot, though. Or
just put it in kickstart (if possible).
I think firstboot is being thinned down to just retain the bare minimum
needed for a Desktop login.
What's the time differential anyway between doing it at Install time and
waiting to log in as a regular user? Or is it that you want a window to
pop up on first Log-on (we don't really take advantage of first login,
unfortunately) to ask you if you want to configure some additional
services?
--
Richi Plana
12:21 p.m.
Richi Plana wrote:
On Wed, 2007-09-19 at 14:06 +0000, "Jóhann B. Guðmundsson"
wrote:
> User should be able to turn on/off/enable/disable services ( the
> service's that aren't the mandatory one's ) in Anaconda
>
Beg to disagree. Anaconda should just concentrate on getting the real
Fedora image installed so that it becomes the running system (its kernel
and filesystem is used). You can argue for it at firstboot, though. Or
just put it in kickstart (if possible).
Then you must agree with me that Anaconda should enable just the
service's that are the mandatory one's and no other..
For a system functional installation...
And the user enables the rest of the services himself during first boot,
first login or when ever he chooses to do so...
If we are gonna go the way to let the system make the decision for the
user then where are we gonna draw the line on how *smart*
the system is....
Lets just go all the way!!!!...
Anaconda should then be able to install *default* installation for the
user in no more then 3 <mouse> clicks..
User inserts CD/DVD/USB/<other possible media formats> boots up AND
ends up in Anaconda <Advanced user can press and hold down or
do some glorious key combination to enter linux terminal installation
prompt where he can type *Advanced* kernel parameters.. ( askmethod text
etc.. )
First Menu...
presentation..
Legal stuff accept/decline <click1> --->
User is presented with installation
types
Desktop <click2>
System does educated guess on user preference --->
Server/Advanced
Finish screen...
User presented with reboot < click3 >
3 mouse clicks!!! no more no less..
Best regards
Johann B.
--
Johann B. Gudmundsson. RHCE,CCSA
Unix System Engineer.
IT Management.
Reiknistofnun University of Iceland.
Taeknigardi, Dunhaga 5. Email: johannbg(a)hi.is
IS-107 Reykjavik. Phone: +354-525-4267
Iceland. Fax: +354-552-8801
3:27 p.m.
On Wed, 2007-09-19 at 17:21 +0000, "Jóhann B. Guðmundsson" wrote:
Richi Plana wrote:
> On Wed, 2007-09-19 at 14:06 +0000, "Jóhann B. Guðmundsson" wrote:
>
>> User should be able to turn on/off/enable/disable services ( the
>> service's that aren't the mandatory one's ) in Anaconda
>>
>
> Beg to disagree. Anaconda should just concentrate on getting the real
> Fedora image installed so that it becomes the running system (its kernel
> and filesystem is used). You can argue for it at firstboot, though. Or
> just put it in kickstart (if possible).
>
>
Then you must agree with me that Anaconda should enable just the
service's that are the mandatory one's and no other..
How I wish! I want all my installations to be as lean and mean, as
possible. Unfortunately, you're relying on people to choose which
services should be enabled or not when it should be the user (via
his/her use of the computer) that should decide. Once the software is
installed on a person's machine, we won't be there to enable or disable
a service should it all of a sudden be needed. Ideally, the software
should be smart enough to enable what needs to be enabled when the user
says "I need to do this" (and one of it's requirements is an enabled
service), but we aren't there yet and there's no formal mention that
that's the direction we are actually going.
Really, the system should try to be smarter when it comes to guessing
what the user needs (as opposed to being static and set at spin-time).
Even Windows tries to be smart and keeps track of what apps have been
recently used and presents those first. It also knows which ones are
less likely to be used and offers to remove them. We're nowhere near
that with services and packages.
So as much as I want just the services that I actually use running on
my system (and packages that I only intend to use installed)
automatically done for me, I have to be satisfied with doing things
manually.
--
Richi Plana
4:17 p.m.
On Wed, 2007-09-19 at 17:21 +0000, "Jóhann B.
Guðmundsson" wrote:
> Richi Plana wrote:
> > On Wed, 2007-09-19 at 14:06 +0000, "Jóhann B. Guðmundsson" wrote:
> >
> >> User should be able to turn on/off/enable/disable services ( the
> >> service's that aren't the mandatory one's ) in Anaconda
> >>
> >
> > Beg to disagree. Anaconda should just concentrate on getting the real
> > Fedora image installed so that it becomes the running system (its
> kernel
> > and filesystem is used). You can argue for it at firstboot, though. Or
> > just put it in kickstart (if possible).
> >
> >
> Then you must agree with me that Anaconda should enable just the
> service's that are the mandatory one's and no other..
How I wish! I want all my installations to be as lean and mean, as
possible. Unfortunately, you're relying on people to choose which
services should be enabled or not when it should be the user (via
his/her use of the computer) that should decide.
I think you misunderstood me there, I am for all as much auto
install/configure as possible for the novice user But....
I want an option to disable and choose to do those things manually before
the system does those things for me, Instead of always have to back trace
what was configured for me and revert it to my choosing. :)
Once the software is
installed on a person's machine, we won't be there to enable or disable
a service should it all of a sudden be needed. Ideally, the software
should be smart enough to enable what needs to be enabled when the user
says "I need to do this" (and one of it's requirements is an enabled
service),
Agreed...
but we aren't there yet and there's no formal mention that
that's the direction we are actually going.
How about getting some formal answers from the those who make that ruling
Which by the way are ???
Really, the system should try to be smarter when it comes to guessing
what the user needs (as opposed to being static and set at spin-time).
Even Windows tries to be smart and keeps track of what apps have been
recently used and presents those first. It also knows which ones are
less likely to be used and offers to remove them. We're nowhere near
that with services and packages.
Agreed..
So as much as I want just the services that I actually use running on
my system (and packages that I only intend to use installed)
automatically done for me, I have to be satisfied with doing things
manually.
--
As do we all...
Best regards
Johann B.
9:08 a.m.
On Wed, Sep 19, 2007 at 06:23:28PM +0530, Rahul Sundaram wrote:
There was some discussions in fedora-desktop list into moving this
option away from first boot into Anaconda itself so that this would be
mandatory. This is indeed a good thing to do in this instance. Do file a
No way -- that would be a regression. Moving this to firstboot was a huge
step forward.
If you put it in anaconda and make it mandatory, what do you plan to do in
environments with network-based accounts?
RFE in Anaconda. The idea was to entirely get rid of first boot if
possible in the desktop spin.
Pushing stuff to Anaconda ain't the answer.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:13 a.m.
On Wed, Sep 19, 2007 at 10:11:20AM -0400, Colin Walters wrote:
> If you put it in anaconda and make it mandatory, what do you
plan to do in
> environments with network-based accounts?
What's wrong with using the DVD and kickstart files?
That'd be really annoying to have to resort to that for a one-off
installation.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:28 a.m.
On 9/19/07, Matthew Miller <mattdm(a)mattdm.org> wrote:
On Wed, Sep 19, 2007 at 10:11:20AM -0400, Colin Walters wrote:
> > If you put it in anaconda and make it mandatory, what do you plan to do in
> > environments with network-based accounts?
> What's wrong with using the DVD and kickstart files?
That'd be really annoying to have to resort to that for a one-off
installation.
I can't think of a situation in which NIS is used where using
kickstart files would be close to the biggest annoyance.
9:57 a.m.
On Wed, 2007-09-19 at 10:13 -0400, Matthew Miller wrote:
On Wed, Sep 19, 2007 at 10:11:20AM -0400, Colin Walters wrote:
> > If you put it in anaconda and make it mandatory, what do you plan to do in
> > environments with network-based accounts?
> What's wrong with using the DVD and kickstart files?
That'd be really annoying to have to resort to that for a one-off
installation.
A one-off? I might be misunderstanding you, but I thought you were
arguing for network-based account installs and multiple machines? If
it's just one machine, then does it really matter whether you do it at
firstboot or Anaconda?
--
Richi Plana
11:05 a.m.
On Wed, Sep 19, 2007 at 08:57:36AM -0600, Richi Plana wrote:
> That'd be really annoying to have to resort to that for a
one-off
> installation.
A one-off? I might be misunderstanding you, but I thought you were
arguing for network-based account installs and multiple machines? If
it's just one machine, then does it really matter whether you do it at
firstboot or Anaconda?
Consider an environment where network authentication is desired but OS
choice is not enforced. People are likely to download and want to use the
Fedora Desktop spin on their desktop computers.
But this is all really a moot point because I think it's highly unlikely
that anaconda will go back to its old behavior -- that stuff was moved out
for reasons other than policy.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
11:21 a.m.
On 9/19/07, Matthew Miller <mattdm(a)mattdm.org> wrote:
Consider an environment where network authentication is desired but OS
choice is not enforced. People are likely to download and want to use the
Fedora Desktop spin on their desktop computers.
Can you be more specific? I don't understand what these scenarios would be.
8 a.m.
On Wed, Sep 19, 2007 at 02:49:19PM +0200, Denis Leroy wrote:
Creating a normal user is not mandatory in anaconda (as it should
be).
It should not be. In an environment using single sign on systems, ldap, NIS
or yellow pages it makes no sense.
Secondly the security argument here is simply peeing in the wind as you can
hit ctrl-alt-f1 and log in as root on a text console.
Alan
7:37 a.m.
On Wed, Sep 19, 2007 at 02:49:19PM +0200, Denis Leroy wrote:
> Creating a normal user is not mandatory in anaconda (as it should be).
It should not be. In an environment using single sign on systems, ldap,
NIS
or yellow pages it makes no sense.
Secondly the security argument here is simply peeing in the wind as you
can
hit ctrl-alt-f1 and log in as root on a text console.
Can this information be included on the login screen, somewhere small and
discreet, like in faded text on the bottom left or something? I was
unaware of it and would have found it useful one evening some time ago.
Alan
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
novus ordo absurdum
8:50 a.m.
Jon Ciesla wrote:
Can this information be included on the login screen, somewhere small
and
discreet, like in faded text on the bottom left or something? I was
unaware of it and would have found it useful one evening some time ago.
Sounds useful if the method to return back is also mentioned. I am not
sure there is a way to describe this without making the interface
cluttered. You can file a request in http://bugzilla.gnome.org
Rahul
9:14 a.m.
On Wed, 2007-09-19 at 07:37 -0500, Jon Ciesla wrote:
Can this information be included on the login screen, somewhere small
and
discreet, like in faded text on the bottom left or something? I was
unaware of it and would have found it useful one evening some time ago.
How about suggest a change in GDM so that when a user tries to log-in
with the "root" account, it displays a message box informing them that
root login is disabled and what their options are?
--
Richi Plana
9:22 a.m.
Richi Plana wrote:
On Wed, 2007-09-19 at 07:37 -0500, Jon Ciesla wrote:
> Can this information be included on the login screen, somewhere small and
> discreet, like in faded text on the bottom left or something? I was
> unaware of it and would have found it useful one evening some time ago.
>
How about suggest a change in GDM so that when a user tries to log-in
with the "root" account, it displays a message box informing them that
root login is disabled and what their options are?
--
Your currently trying to log in as root ( oh did I type root I was gonna
write smurkydoo )
The root account is currently disable please press <ctrl><alt> F1 type
root as your Login name and the root password enable the root account
exit then try again..
lol....
Best regards
Johann B.
--
Johann B. Gudmundsson. RHCE,CCSA
Unix System Engineer.
IT Management.
Reiknistofnun University of Iceland.
Taeknigardi, Dunhaga 5. Email: johannbg(a)hi.is
IS-107 Reykjavik. Phone: +354-525-4267
Iceland. Fax: +354-552-8801
9:40 a.m.
Jóhann B. Guðmundsson wrote:
Richi Plana wrote:
> On Wed, 2007-09-19 at 07:37 -0500, Jon Ciesla wrote:
>
>> Can this information be included on the login screen, somewhere
>> small and
>> discreet, like in faded text on the bottom left or something? I was
>> unaware of it and would have found it useful one evening some time ago.
>>
>
> How about suggest a change in GDM so that when a user tries to log-in
> with the "root" account, it displays a message box informing them that
> root login is disabled and what their options are?
> --
>
Your currently trying to log in as root ( oh did I type root I was
gonna write smurkydoo )
The root account is currently disable please press <ctrl><alt> F1 type
root as your Login name and the root password enable the root account
exit then try again..
lol....
If this is gonna be *good* user experience users need to be able to enable
the root account in gdm/kdm/xdm etc..
First user tries to log in as root gets an *hint* that he need to go to
option --> enable root login, types the root password, root account enabled
logs in as root receives an stripped down administrative/rescue desktop
Best regards
Johann B.
--
Johann B. Gudmundsson. RHCE,CCSA
Unix System Engineer.
IT Management.
Reiknistofnun University of Iceland.
Taeknigardi, Dunhaga 5. Email: johannbg(a)hi.is
IS-107 Reykjavik. Phone: +354-525-4267
Iceland. Fax: +354-552-8801
11:08 a.m.
On Wed, 2007-09-19 at 14:40 +0000, "Jóhann B. Guðmundsson" wrote:
Jóhann B. Guðmundsson wrote:
> Richi Plana wrote:
>> On Wed, 2007-09-19 at 07:37 -0500, Jon Ciesla wrote:
>>
>>> Can this information be included on the login screen, somewhere
>>> small and
>>> discreet, like in faded text on the bottom left or something? I was
>>> unaware of it and would have found it useful one evening some time ago.
>>>
>>
>> How about suggest a change in GDM so that when a user tries to log-in
>> with the "root" account, it displays a message box informing them
that
>> root login is disabled and what their options are?
>> --
>>
> Your currently trying to log in as root ( oh did I type root I was
> gonna write smurkydoo )
> The root account is currently disable please press <ctrl><alt> F1 type
> root as your Login name and the root password enable the root account
> exit then try again..
>
> lol....
>
>
If this is gonna be *good* user experience users need to be able to enable
the root account in gdm/kdm/xdm etc..
First user tries to log in as root gets an *hint* that he need to go to
option --> enable root login, types the root password, root account enabled
logs in as root receives an stripped down administrative/rescue desktop
This is a very reasonable proposal, I think it is a very sensible way to
help users do the right thing (or the wrong one ... details :-).
Simo.
8:06 a.m.
On Wed, 2007-09-19 at 09:00 -0400, Alan Cox wrote:
On Wed, Sep 19, 2007 at 02:49:19PM +0200, Denis Leroy wrote:
> Creating a normal user is not mandatory in anaconda (as it should be).
It should not be. In an environment using single sign on systems, ldap, NIS
or yellow pages it makes no sense.
Secondly the security argument here is simply peeing in the wind as you can
hit ctrl-alt-f1 and log in as root on a text console.
Yeah, but then you don't walk away from your root session expecting the
screensaver to kick in - which it doesn't for root. Face it, running a
desktop session as root is just broken.
8:13 a.m.
Matthias Clasen wrote:
On Wed, 2007-09-19 at 09:00 -0400, Alan Cox wrote:
> On Wed, Sep 19, 2007 at 02:49:19PM +0200, Denis Leroy wrote:
>> Creating a normal user is not mandatory in anaconda (as it should be).
> It should not be. In an environment using single sign on systems, ldap, NIS
> or yellow pages it makes no sense.
>
> Secondly the security argument here is simply peeing in the wind as you can
> hit ctrl-alt-f1 and log in as root on a text console.
Yeah, but then you don't walk away from your root session expecting the
screensaver to kick in - which it doesn't for root.
Yes but who cares about a screensaver when you
1) use a kvm switch
2) have no monitor connected, but use vlc-server (you do need gnome
installed for that)
3) have no monitor connected, but use a virtual remote console (as in
our sun systems).
As mentioned earlier, the best solution may be to turn the root desktop
into a special rescue environment...
3:18 p.m.
Matthias Clasen <mclasen <at> redhat.com> writes:
Yeah, but then you don't walk away from your root session
expecting the
screensaver to kick in - which it doesn't for root.
Then fix that GNOME bug instead of hiding it. Screensavers and desktop locking
for root work just fine in KDE.
Kevin Kofler
3:29 p.m.
On Wed, 2007-09-19 at 20:18 +0000, Kevin Kofler wrote:
Matthias Clasen <mclasen <at> redhat.com> writes:
> Yeah, but then you don't walk away from your root session expecting the
> screensaver to kick in - which it doesn't for root.
Then fix that GNOME bug instead of hiding it. Screensavers and desktop locking
for root work just fine in KDE.
And I assume that KDE users are just happy to run tons of unaudited
toolkit code as root...
Anyway, its a moot point, we'll re-enable root login for test3.
4:06 p.m.
on 9/19/2007 4:29 PM, Matthias Clasen wrote:
On Wed, 2007-09-19 at 20:18 +0000, Kevin Kofler wrote:
> Matthias Clasen <mclasen <at> redhat.com> writes:
>> Yeah, but then you don't walk away from your root session expecting the
>> screensaver to kick in - which it doesn't for root.
> Then fix that GNOME bug instead of hiding it. Screensavers and desktop locking
> for root work just fine in KDE.
And I assume that KDE users are just happy to run tons of unaudited
toolkit code as root...
Anyway, its a moot point, we'll re-enable root login for test3.
I have watched this thread since the beginning and I can no longer keep my
peace.
A knowledgeable Linux user would know how to change this default. Or
figure out how to change. I know how and I am certainly not on the level
of many here.
A 'not so knowledgeable Linux user' would use the 'enter Roots password'
windows to preform these tasks.
Any user that can not do either of these things *does not* have any
business logging in as root in a GUI. Period.
Or do you want Fedora 8 to be like Windows? Where 'run as root' is the
default for the 'not so knowledgeable Windows user'? You want them to be
able to shoot themselves in the foot?
I hope not.
Want to use Linux, be a Linux Geek, so to speak? Learn a little more about
it first. More than downloading an ISO and burning it it Windows. I did
that years ago. How about you?
--
David
4:12 p.m.
On 9/19/07, David Boles <dgboles(a)gmail.com> wrote:
Or do you want Fedora 8 to be like Windows? Where 'run as root' is the
default for the 'not so knowledgeable Windows user'?
It is not the default. You have to actively work to arrive at the
situation, ignoring a warning dialog.
It is not worth developer time at this stage to improve the warnings,
create a special X session, etc.
It will be fixed correctly for F9.
4:33 p.m.
on 9/19/2007 5:12 PM, Colin Walters wrote:
On 9/19/07, David Boles <dgboles(a)gmail.com> wrote:
> Or do you want Fedora 8 to be like Windows? Where 'run as root' is the
> default for the 'not so knowledgeable Windows user'?
It is not the default. You have to actively work to arrive at the
situation, ignoring a warning dialog.
It is not worth developer time at this stage to improve the warnings,
create a special X session, etc.
It will be fixed correctly for F9.
I do not think that you understood me. I do *not* think that what many are
arguing for here, GUI root logins as a default 'on' feature, is a good
idea for the average new user. Those that have enough experience can
change it, if they want to do that.
You developers are much too busy to see what those of us that follow the
fedora-user list see every day. Many are trying very hard to make a
working system and to learn Linux but most are true Newbies that need to
be somewhat protected from themselves until they learn a little about
Linux. If not they will be as open to 'attack' as most Windows users.
--
David
4:43 p.m.
On Wed, 2007-09-19 at 17:06 -0400, David Boles wrote:
Want to use Linux, be a Linux Geek, so to speak? Learn a little more
about
it first. More than downloading an ISO and burning it it Windows. I did
that years ago. How about you?
Now that's not a nice mentality.
I'm a self-professed computer geek, but it's my opinion that a person
should be good at what they aim to accomplish. If they mean to write a
great essay on a wordprocessor on Linux, then they don't need to be
proficient with Linux. Just writing. OTOH, if you want to be a Linux
machines system administrator, then that person should damn well know
what the heck is going on under the hood of their machine (as opposed to
just button-clicking). Even with grammar-correction, writers should know
well the rules of grammar.
The beauty in Linux is that as the software matures, people find
themselves being more productive in whatever goal they set themselves
out to use a computer for. Hopefully, it might even allow them to be
creative about it in ways that weren't open to them before using Linux.
(That's how I got hooked on code reusability and the Unix philosophy.)
--
Richi Plana
10:42 p.m.
on 9/19/2007 5:43 PM, Richi Plana wrote:
On Wed, 2007-09-19 at 17:06 -0400, David Boles wrote:
> Want to use Linux, be a Linux Geek, so to speak? Learn a little more about
> it first. More than downloading an ISO and burning it it Windows. I did
> that years ago. How about you?
Now that's not a nice mentality.
I'm a self-professed computer geek, but it's my opinion that a person
should be good at what they aim to accomplish. If they mean to write a
great essay on a wordprocessor on Linux, then they don't need to be
proficient with Linux. Just writing. OTOH, if you want to be a Linux
machines system administrator, then that person should damn well know
what the heck is going on under the hood of their machine (as opposed to
just button-clicking). Even with grammar-correction, writers should know
well the rules of grammar.
The beauty in Linux is that as the software matures, people find
themselves being more productive in whatever goal they set themselves
out to use a computer for. Hopefully, it might even allow them to be
creative about it in ways that weren't open to them before using Linux.
(That's how I got hooked on code reusability and the Unix philosophy.)
I did *not* say that you needed to be a 'geek' to use Linux for common
everyday tasks. What I said was that if you, the (any)user, wants to do
really, really strange things that the user should know more about Linux
than how to tie his shoes strings.
When I started with Linux 'docs' was a joke. Man pages was just about the
same. GUI configuration applications? What are those? Files, most of
which, are done 'for you' now had to be done by hand during the
installation or in text editors later. Firewalls. Port sentries. Lan
connections. Almost everything had to be done by hand.
Which took - OH MY $deity - reading and more than 'click here dummy or
accept the default'.
The *MAIN* fault with Windows is the 'user is root' situation. You want
that for Linux? Do you really want someone who thinks that a harddrive is
that 'big box on my desk that all of this stuff is connected to' to have
kill it in one shot abilities?
Really? Then Linux is doomed to follow the same path. When 'you' make
Linux just like that - that is when the masses will/might convert to
Linux. That will be when the guy in Russia starts writing the really kool
screen saver that the dummy you enticed to try Linux downloads. The on
that contacts the first major Linux Trojan/virus/ crap.
I hope not.
--
David
3:47 a.m.
David Boles wrote:
on 9/19/2007 5:43 PM, Richi Plana wrote:
> On Wed, 2007-09-19 at 17:06 -0400, David Boles wrote:
>
>> Want to use Linux, be a Linux Geek, so to speak? Learn a little more about
>> it first. More than downloading an ISO and burning it it Windows. I did
>> that years ago. How about you?
>>
> Now that's not a nice mentality.
>
> I'm a self-professed computer geek, but it's my opinion that a person
> should be good at what they aim to accomplish. If they mean to write a
> great essay on a wordprocessor on Linux, then they don't need to be
> proficient with Linux. Just writing. OTOH, if you want to be a Linux
> machines system administrator, then that person should damn well know
> what the heck is going on under the hood of their machine (as opposed to
> just button-clicking). Even with grammar-correction, writers should know
> well the rules of grammar.
>
> The beauty in Linux is that as the software matures, people find
> themselves being more productive in whatever goal they set themselves
> out to use a computer for. Hopefully, it might even allow them to be
> creative about it in ways that weren't open to them before using Linux.
> (That's how I got hooked on code reusability and the Unix philosophy.)
>
I did *not* say that you needed to be a 'geek' to use Linux for common
everyday tasks. What I said was that if you, the (any)user, wants to do
really, really strange things that the user should know more about Linux
than how to tie his shoes strings.
No just to start to buy a loot of books about linux and read the wealth
of information
about linux before you start using it...
When I started with Linux 'docs' was a joke. Man pages was
just about the
same. GUI configuration applications? What are those? Files, most of
which, are done 'for you' now had to be done by hand during the
installation or in text editors later. Firewalls. Port sentries. Lan
connections. Almost everything had to be done by hand.
Which took - OH MY $deity - reading and more than 'click here dummy or
accept the default'.
Oh the good old days :) We have come a long way since then..
The *MAIN* fault with Windows is the 'user is root'
situation. You want
that for Linux? Do you really want someone who thinks that a harddrive is
that 'big box on my desk that all of this stuff is connected to' to have
kill it in one shot abilities?
If the user is *chrooted* to his home directory and what he does cant
affect the system or
other users, then hell yeah.. he should have the power to shoot himself
in the "foot"
or commit otherwize user suicide...
Really? Then Linux is doomed to follow the same path. When
'you' make
Linux just like that - that is when the masses will/might convert to
Linux.
Where have you been fella, the masses have already started to use
GNU/Linux
The number are increasing by the day...
Welcome to the OpenSource Revolution....
( We have to start creating T-Shirts and come up with some really cool
songs and slogans. )
( Any one open/up for the task to write an OpenSource musical :) .. )
That will be when the guy in Russia starts writing the really kool
screen saver that the dummy you enticed to try Linux downloads. The on
that contacts the first major Linux Trojan/virus/ crap.
I hope not.
As long as it affect the user and only the user then it does not matter...
Best regards
Johann B.
--
Johann B. Gudmundsson. RHCE,CCSA
Unix System Engineer.
IT Management.
Reiknistofnun University of Iceland.
Taeknigardi, Dunhaga 5. Email: johannbg(a)hi.is
IS-107 Reykjavik. Phone: +354-525-4267
Iceland. Fax: +354-552-8801
7:40 a.m.
On Thu, 2007-09-20 at 08:47 +0000, "Jóhann B. Guðmundsson" wrote:
> The *MAIN* fault with Windows is the 'user is root'
situation. You want
> that for Linux? Do you really want someone who thinks that a harddrive is
> that 'big box on my desk that all of this stuff is connected to' to have
> kill it in one shot abilities?
>
If the user is *chrooted* to his home directory and what he does cant
affect the system or
other users, then hell yeah.. he should have the power to shoot himself
in the "foot"
or commit otherwize user suicide...
I'm afraid I'm going to have to disagree on this one. Yes, I do agree
that users should be given the freedom to shoot themselves in the foot
IF shooting themselves in the foot is what they want. In this case,
intent matters.
I keep mentioning that the Fedora system should be made to be smart to
aid the user in achieving what he/she wants to do (and is allowed to do,
assuming there are restrictions in the institution he's in). It's not
even about being root or user privileges. Some users will want to
actually DO something (like start/stop system services, configure
printers, etc.) while some users just WANT to be root because he knows
he has a myriad of things to do requiring root privileges.
Unfortunately, the latter situation is really a remnant of the Unix way
of thinking. In truth, Administrators don't have to have root access for
everything but have gotten so used to not having to authenticate
themselves to the system as having the privilege to do what they want
whenever they try something.
So no, I don't believe in the Windows' "the user is root" philosophy,
but until out system has gotten to the point where extended privileges
can be given to the user WITHOUT HAVING TO TYPE THE ROOT PASSWORD EACH
TIME, then "the user is root" makes sense for a lot of cases (not that
I'm advocating it).
Think about it this way: let's say Fedora is installed on a computer
where only one person will use it (the owner). It's really cumbersome
having to type the root password each time certain actions have to be
performed.
I've never been a big fan of the single-tiered "root is god" idea,
anyway. It's certainly convenient for Unix users (including myself) who
know exactly what they're doing, though. At the very least, there should
be two user IDs: root and admin. admin gets power over some low to
mid-level subsystems and could even be the first local account created,
while root is root. I seem to recall that Novell (the network system)
had a more complex privilege or access list system. Not too sure about
Windows.
--
Richi Plana
5:09 p.m.
on 9/19/2007 4:29 PM, Matthias Clasen wrote:
> On Wed, 2007-09-19 at 20:18 +0000, Kevin Kofler wrote:
>> Matthias Clasen <mclasen <at> redhat.com> writes:
>>> Yeah, but then you don't walk away from your root session expecting
>>> the
>>> screensaver to kick in - which it doesn't for root.
>> Then fix that GNOME bug instead of hiding it. Screensavers and desktop
>> locking
>> for root work just fine in KDE.
>
> And I assume that KDE users are just happy to run tons of unaudited
> toolkit code as root...
>
> Anyway, its a moot point, we'll re-enable root login for test3.
I have watched this thread since the beginning and I can no longer keep my
peace.
A knowledgeable Linux user would know how to change this default. Or
figure out how to change. I know how and I am certainly not on the level
of many here.
True so he know he can simply <ctrl><alt>F1 and take it from there...
A 'not so knowledgeable Linux user' would use the 'enter
Roots password'
windows to preform these tasks.
And if the user manage to shoot himself in the foot so he cant login
using his username and password how is he gonna manage to get to his
"enter the root password dialog"....
Any user that can not do either of these things *does not* have any
business logging in as root in a GUI. Period.
Wrong he has a fighting chance to save himself log into familiar
surroundings fix the situation with S-C-* tools, learn from his mistake
instead of have to do clean install or bother advanced users given that they
are some where around him.
The alternitive "dropping him to terminal window" were he would be dead in
the water...
Or do you want Fedora 8 to be like Windows?
No...
Where 'run as root' is the
default for the 'not so knowledgeable Windows user'?
Last time I used M$ windows it made dam sure that the user could harm
the system ( windows it self ) and question every other move he did..
Maybe Windows is actually trusting user today but I doubt it...
You want them to be
able to shoot themselves in the foot?
Yes. the users will learn from there mistakes, adopt,evolve and move on..
Let's place the trust on the user always.
I hope not.
Want to use Linux, be a Linux Geek, so to speak? Learn a little more about
it first. More than downloading an ISO and burning it it Windows.
Nope get the user first into linux as hazle free and comfortable as
possible...
From there he will start using, playing, fiddle around *expanding his
knowledge about linux. etc..
Best regards
Johann B.
8:36 p.m.
on 9/19/2007 6:09 PM, � wrote:
> on 9/19/2007 4:29 PM, Matthias Clasen wrote:
>> On Wed, 2007-09-19 at 20:18 +0000, Kevin Kofler wrote:
>>> Matthias Clasen <mclasen <at> redhat.com> writes:
>>>> Yeah, but then you don't walk away from your root session expecting
>>>> the
>>>> screensaver to kick in - which it doesn't for root.
>>> Then fix that GNOME bug instead of hiding it. Screensavers and desktop
>>> locking
>>> for root work just fine in KDE.
>> And I assume that KDE users are just happy to run tons of unaudited
>> toolkit code as root...
>>
>> Anyway, its a moot point, we'll re-enable root login for test3.
>
> I have watched this thread since the beginning and I can no longer keep my
> peace.
>
> A knowledgeable Linux user would know how to change this default. Or
> figure out how to change. I know how and I am certainly not on the level
> of many here.
>
True so he know he can simply <ctrl><alt>F1 and take it from there...
> A 'not so knowledgeable Linux user' would use the 'enter Roots
password'
> windows to preform these tasks.
>
And if the user manage to shoot himself in the foot so he cant login
using his username and password how is he gonna manage to get to his
"enter the root password dialog"....
> Any user that can not do either of these things *does not* have any
> business logging in as root in a GUI. Period.
Wrong he has a fighting chance to save himself log into familiar
surroundings fix the situation with S-C-* tools, learn from his mistake
instead of have to do clean install or bother advanced users given that they
are some where around him.
The alternitive "dropping him to terminal window" were he would be dead in
the water...
> Or do you want Fedora 8 to be like Windows?
No...
> Where 'run as root' is the
> default for the 'not so knowledgeable Windows user'?
Last time I used M$ windows it made dam sure that the user could harm
the system ( windows it self ) and question every other move he did..
Maybe Windows is actually trusting user today but I doubt it...
> You want them to be
> able to shoot themselves in the foot?
Yes. the users will learn from there mistakes, adopt,evolve and move on..
Let's place the trust on the user always.
> I hope not.
>
> Want to use Linux, be a Linux Geek, so to speak? Learn a little more about
> it first. More than downloading an ISO and burning it it Windows.
Nope get the user first into linux as hazle free and comfortable as
possible...
>From there he will start using, playing, fiddle around *expanding his
knowledge about linux. etc..
Well as soon as Linux can play Oblivion, Solder of Fortune, Half-Life, and
the so many other Windows games you will get a *lot* of 'new Linux users'
from Windows. Just as ignorant as you are looking for here.
I give up. Logical thinking does not work when dealing with zealots. But I
still think that you are wrong. No default GUI root logins.
--
David
2:11 a.m.
2007/9/20, David Boles <dgboles(a)gmail.com>:
on 9/19/2007 6:09 PM, � wrote:
>> on 9/19/2007 4:29 PM, Matthias Clasen wrote:
>>> On Wed, 2007-09-19 at 20:18 +0000, Kevin Kofler wrote:
>>>> Matthias Clasen <mclasen <at> redhat.com> writes:
>>>>> Yeah, but then you don't walk away from your root session
expecting
>>>>> the
>>>>> screensaver to kick in - which it doesn't for root.
>>>> Then fix that GNOME bug instead of hiding it. Screensavers and desktop
>>>> locking
>>>> for root work just fine in KDE.
>>> And I assume that KDE users are just happy to run tons of unaudited
>>> toolkit code as root...
>>>
>>> Anyway, its a moot point, we'll re-enable root login for test3.
>>
>> I have watched this thread since the beginning and I can no longer keep my
>> peace.
>>
>> A knowledgeable Linux user would know how to change this default. Or
>> figure out how to change. I know how and I am certainly not on the level
>> of many here.
>>
>
> True so he know he can simply <ctrl><alt>F1 and take it from there...
>
>> A 'not so knowledgeable Linux user' would use the 'enter Roots
password'
>> windows to preform these tasks.
>>
>
> And if the user manage to shoot himself in the foot so he cant login
> using his username and password how is he gonna manage to get to his
> "enter the root password dialog"....
>
>> Any user that can not do either of these things *does not* have any
>> business logging in as root in a GUI. Period.
>
> Wrong he has a fighting chance to save himself log into familiar
> surroundings fix the situation with S-C-* tools, learn from his mistake
> instead of have to do clean install or bother advanced users given that they
> are some where around him.
>
> The alternitive "dropping him to terminal window" were he would be dead
in
> the water...
>
>> Or do you want Fedora 8 to be like Windows?
>
> No...
>
>> Where 'run as root' is the
>> default for the 'not so knowledgeable Windows user'?
>
> Last time I used M$ windows it made dam sure that the user could harm
> the system ( windows it self ) and question every other move he did..
>
> Maybe Windows is actually trusting user today but I doubt it...
>
>> You want them to be
>> able to shoot themselves in the foot?
>
> Yes. the users will learn from there mistakes, adopt,evolve and move on..
>
> Let's place the trust on the user always.
>
>> I hope not.
>>
>> Want to use Linux, be a Linux Geek, so to speak? Learn a little more about
>> it first. More than downloading an ISO and burning it it Windows.
>
> Nope get the user first into linux as hazle free and comfortable as
> possible...
>
>>From there he will start using, playing, fiddle around *expanding his
> knowledge about linux. etc..
Well as soon as Linux can play Oblivion, Solder of Fortune, Half-Life, and
the so many other Windows games you will get a *lot* of 'new Linux users'
from Windows. Just as ignorant as you are looking for here.
well please do your homework:
http://appdb.winehq.com
sof even has a native linux port.
regards,
Rudolf Kastl
I give up. Logical thinking does not work when dealing with zealots. But I
still think that you are wrong. No default GUI root logins.
--
David
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
8:53 a.m.
on 9/20/2007 3:11 AM, Rudolf Kastl wrote:
2007/9/20, David Boles <dgboles(a)gmail.com>:
> on 9/19/2007 6:09 PM, � wrote:
>
> Well as soon as Linux can play Oblivion, Solder of Fortune, Half-Life, and
> the so many other Windows games you will get a *lot* of 'new Linux users'
> from Windows. Just as ignorant as you are looking for here.
well please do your homework:
http://appdb.winehq.com
sof even has a native linux port.
regards,
Rudolf Kastl
You should have looked a little harder before you jumped to defend Windows
games for Linux. ;-)
I mentioned those games only because they came to mind late at night.
Those are all old, by gaming standards very old, games. SOF is from 2000
for example and basically abandoned. It will run because it is OpenGL and
could be ported. Oblivion and Half-Life are written 'in' DirectX. Those
would not, and many others I would think, run in Wine. Ever. Nor will they
run in VMware.
--
David
9:23 a.m.
David Boles wrote:
on 9/20/2007 3:11 AM, Rudolf Kastl wrote:
> 2007/9/20, David Boles <dgboles(a)gmail.com>:
>> on 9/19/2007 6:09 PM, � wrote:
>>
>> Well as soon as Linux can play Oblivion, Solder of Fortune, Half-Life, and
>> the so many other Windows games you will get a *lot* of 'new Linux
users'
>> from Windows. Just as ignorant as you are looking for here.
> well please do your homework:
>
> http://appdb.winehq.com
>
> sof even has a native linux port.
>
> regards,
> Rudolf Kastl
You should have looked a little harder before you jumped to defend Windows
games for Linux. ;-)
I mentioned those games only because they came to mind late at night.
Those are all old, by gaming standards very old, games. SOF is from 2000
for example and basically abandoned. It will run because it is OpenGL and
could be ported. Oblivion and Half-Life are written 'in' DirectX. Those
would not, and many others I would think, run in Wine. Ever. Nor will they
run in VMware.
Half-Life (and friends) has an OpenGL renderer and has worked for ages
in Linux using wine. Half-Life 2 and Oblivion are DirectX only but do
work somewhat in wine (have some rendering glitches, water reflections
can be odd, performance is decreased).
Both run very well in Cedega, including copy protection. As do a slew of
other modern games. It still isn't at the point where you can grab any
game off the shelf and have it work but I've got a large stack of games
that say you're wrong that DirectX games will never, ever be playable on
Linux.
rob
10:33 a.m.
on 9/21/2007 10:23 AM, Rob Crittenden wrote:
David Boles wrote:
> on 9/20/2007 3:11 AM, Rudolf Kastl wrote:
> You should have looked a little harder before you jumped to defend Windows
> games for Linux. ;-)
>
> I mentioned those games only because they came to mind late at night.
> Those are all old, by gaming standards very old, games. SOF is from 2000
> for example and basically abandoned. It will run because it is OpenGL and
> could be ported. Oblivion and Half-Life are written 'in' DirectX. Those
> would not, and many others I would think, run in Wine. Ever. Nor will they
> run in VMware.
>
Half-Life (and friends) has an OpenGL renderer and has worked for ages
in Linux using wine. Half-Life 2 and Oblivion are DirectX only but do
work somewhat in wine (have some rendering glitches, water reflections
can be odd, performance is decreased).
Both run very well in Cedega, including copy protection. As do a slew of
other modern games. It still isn't at the point where you can grab any
game off the shelf and have it work but I've got a large stack of games
that say you're wrong that DirectX games will never, ever be playable on
Linux.
I don't play games myself but there is someone on this list that I know
and will not name (if he wishes he can say) who is a Fedora user that has
two siblings that are Windows only because of the games. Games are closed
source and the executables that you can use to run some of them in Linux
are closed source and supplied by the game developers. They are not
developed by Linux developers.
I was thinking of Half-Life II actually. My point is that real Windows
like game performance will be a long time coming to Linux. If ever. And
since some (estimated) 90% of the computers use Windows in some form or
another I don't see game producers doing much with Linux. No money in it.
This thread has really drifted OT from the Subject:
To say it once more.
I think it is a good thing to *not* allow, by default, root GUI logins.
Those that want to do that can enable it. Those that can not figure out
how to enable it probably should not be doing it anyway.
--
David
1:18 p.m.
On Fri, Sep 21, 2007 at 11:33:53AM -0400, David Boles wrote:
To say it once more.
I think it is a good thing to *not* allow, by default, root GUI logins.
Those that want to do that can enable it. Those that can not figure out
how to enable it probably should not be doing it anyway.
--
David
I agree. +1.
--
http://zoidtechnologies.com/ -- software that sucks less
1:26 p.m.
On Fri, 2007-09-21 at 14:18 -0400, jam(a)zoidtechnologies.com wrote:
On Fri, Sep 21, 2007 at 11:33:53AM -0400, David Boles wrote:
> To say it once more.
>
> I think it is a good thing to *not* allow, by default, root GUI logins.
> Those that want to do that can enable it. Those that can not figure out
> how to enable it probably should not be doing it anyway.
> --
>
> David
>
I agree. +1.
I agree, as well. The important thing is for users to have access to GUI
applications that would allow them to do their admin work. A lot of that
is accomplished by accessing the same apps from System->Administration
and authenticating themselves, or "su -"'ing from a terminal and
executing X applications from there. They don't need a whole X session
to achieve their goal of administering the machine.
If they really want an X session as root for other reasons, then they
can log on a console VT and "startx :1".
But again, if root must be allowed to start an X session from gdm as
policy, then let it be a stripped down session.
--
Richi Plana
2:08 p.m.
on 9/21/2007 2:26 PM, Richi Plana wrote:
On Fri, 2007-09-21 at 14:18 -0400, jam(a)zoidtechnologies.com wrote:
> On Fri, Sep 21, 2007 at 11:33:53AM -0400, David Boles wrote:
>> To say it once more.
>>
>> I think it is a good thing to *not* allow, by default, root GUI logins.
>> Those that want to do that can enable it. Those that can not figure out
>> how to enable it probably should not be doing it anyway.
>> --
>>
>> David
>>
> I agree. +1.
I agree, as well. The important thing is for users to have access to GUI
applications that would allow them to do their admin work. A lot of that
is accomplished by accessing the same apps from System->Administration
and authenticating themselves, or "su -"'ing from a terminal and
executing X applications from there. They don't need a whole X session
to achieve their goal of administering the machine.
If they really want an X session as root for other reasons, then they
can log on a console VT and "startx :1".
But again, if root must be allowed to start an X session from gdm as
policy, then let it be a stripped down session.
The stripped down session that you propose would be ok. But then you will
start a 'flame' about just what this session should contain. ;-)
--
David
3:11 p.m.
On Fri, 2007-09-21 at 15:08 -0400, David Boles wrote:
The stripped down session that you propose would be ok. But then you
will
start a 'flame' about just what this session should contain. ;-)
Well, we can always start with X and twm then slowly change or add
things, ;). There's already a proposal to give them at least metacity
and lxpanel. I dunno ... that seems a lot, ;).
In effect, it would be like kids asking for a little bit more at a time
proving along the way that it's needed. :)
--
Richi
3:38 p.m.
on 9/21/2007 4:11 PM, Richi Plana wrote:
On Fri, 2007-09-21 at 15:08 -0400, David Boles wrote:
> The stripped down session that you propose would be ok. But then you will
> start a 'flame' about just what this session should contain. ;-)
Well, we can always start with X and twm then slowly change or add
things, ;). There's already a proposal to give them at least metacity
and lxpanel. I dunno ... that seems a lot, ;).
In effect, it would be like kids asking for a little bit more at a time
proving along the way that it's needed. :)
Which is pretty much what I said. ;-)
I don't know why it is but most Linux users, not *ALL* of us, have this
mindset that Linux, and the developers, owe us this great debt of
gratitude because we use the software that they so generously work on for
next to nothing and give to us for free. 8-)
--
David
6:53 a.m.
2007/9/21, David Boles <dgboles(a)gmail.com>:
on 9/20/2007 3:11 AM, Rudolf Kastl wrote:
> 2007/9/20, David Boles <dgboles(a)gmail.com>:
>> on 9/19/2007 6:09 PM, � wrote:
>>
>> Well as soon as Linux can play Oblivion, Solder of Fortune, Half-Life, and
>> the so many other Windows games you will get a *lot* of 'new Linux
users'
>> from Windows. Just as ignorant as you are looking for here.
>
> well please do your homework:
>
> http://appdb.winehq.com
>
> sof even has a native linux port.
>
> regards,
> Rudolf Kastl
You should have looked a little harder before you jumped to defend Windows
games for Linux. ;-)
i didnt defend anything here, just stated the facts.
I mentioned those games only because they came to mind late at night.
Those are all old, by gaming standards very old, games. SOF is from 2000
for example and basically abandoned. It will run because it is OpenGL and
could be ported. Oblivion and Half-Life are written 'in' DirectX. Those
would not, and many others I would think, run in Wine. Ever. Nor will they
run in VMware.
wine does run directx based games. just to get the facts straight
again. wine is not an emulator in the traditional sense but actually
for the large part an abstraction layer for the windows api.
again: www.winehq.org and appdb.winehq.org will show you.
regards,
Rudolf Kastl
--
David
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
3:06 a.m.
David Boles wrote:
on 9/19/2007 6:09 PM, � wrote:
>> on 9/19/2007 4:29 PM, Matthias Clasen wrote:
>>
>>> On Wed, 2007-09-19 at 20:18 +0000, Kevin Kofler wrote:
>>>
>>>> Matthias Clasen <mclasen <at> redhat.com> writes:
>>>>
>>>>> Yeah, but then you don't walk away from your root session
expecting
>>>>> the
>>>>> screensaver to kick in - which it doesn't for root.
>>>>>
>>>> Then fix that GNOME bug instead of hiding it. Screensavers and desktop
>>>> locking
>>>> for root work just fine in KDE.
>>>>
>>> And I assume that KDE users are just happy to run tons of unaudited
>>> toolkit code as root...
>>>
>>> Anyway, its a moot point, we'll re-enable root login for test3.
>>>
>> I have watched this thread since the beginning and I can no longer keep my
>> peace.
>>
>> A knowledgeable Linux user would know how to change this default. Or
>> figure out how to change. I know how and I am certainly not on the level
>> of many here.
>>
>>
> True so he know he can simply <ctrl><alt>F1 and take it from there...
>
>
>> A 'not so knowledgeable Linux user' would use the 'enter Roots
password'
>> windows to preform these tasks.
>>
>>
> And if the user manage to shoot himself in the foot so he cant login
> using his username and password how is he gonna manage to get to his
> "enter the root password dialog"....
>
>
>> Any user that can not do either of these things *does not* have any
>> business logging in as root in a GUI. Period.
>>
> Wrong he has a fighting chance to save himself log into familiar
> surroundings fix the situation with S-C-* tools, learn from his mistake
> instead of have to do clean install or bother advanced users given that they
> are some where around him.
>
> The alternitive "dropping him to terminal window" were he would be dead in
> the water...
>
>
>> Or do you want Fedora 8 to be like Windows?
>>
> No...
>
>
>> Where 'run as root' is the
>> default for the 'not so knowledgeable Windows user'?
>>
> Last time I used M$ windows it made dam sure that the user could harm
> the system ( windows it self ) and question every other move he did..
>
>
s/could/could\ not/
> Maybe Windows is actually trusting user today but I doubt it...
>
>
>> You want them to be
>> able to shoot themselves in the foot?
>>
> Yes. the users will learn from there mistakes, adopt,evolve and move on..
>
> Let's place the trust on the user always.
>
>
>> I hope not.
>>
>> Want to use Linux, be a Linux Geek, so to speak? Learn a little more about
>> it first. More than downloading an ISO and burning it it Windows.
>>
> Nope get the user first into linux as hazle free and comfortable as
> possible...
>
> >From there he will start using, playing, fiddle around *expanding his
> knowledge about linux. etc..
>
Well as soon as Linux can play Oblivion, Solder of Fortune, Half-Life, and
the so many other Windows games you will get a *lot* of 'new Linux users'
from Windows. Just as ignorant as you are looking for here.
There is nothing preventing games ( except maybe graphics driver, but
that in fast process of changing due to AMD/ATI open up
their drivers pouring some work in with help of others and fix the ATI
driver...
It *seems* NVIDIA is putting more efforts their drivers to answer ATI so
my predection on that are we will ( have actually been with AMD/ATI ) be
seeing
some fast improvements on graphics driver in not so distant future..) in
to be played on linux...
and has not been for quite some time...
Those who want to play games on Linux
http://www.transgaming.com/
Wine
Games have even been develope for Linux
Rememberg Lokigames!!!
I give up. Logical thinking does not work when dealing with zealots.
But I
still think that you are wrong. No default GUI root logins.
The ideal solution has already been mention.
Default gui root login turned off, user gets an option in
GDM/KDM/XDM/rest-of-DM to enable
root login ( user tries to login as root get hinted to go to option
where he can enable root login, types the root password,
root gui login is now enabled, logs in as root to an stripped down
administrative version of the gui AKA safe mode...
Best regards
Johann B.
--
Johann B. Gudmundsson. RHCE,CCSA
Unix System Engineer.
IT Management.
Reiknistofnun University of Iceland.
Taeknigardi, Dunhaga 5. Email: johannbg(a)hi.is
IS-107 Reykjavik. Phone: +354-525-4267
Iceland. Fax: +354-552-8801
8:05 a.m.
On Thu, 2007-09-20 at 14:34 +0200, Ralf Ertzinger wrote:
Hi.
On Wed, 19 Sep 2007 16:29:42 -0400, Matthias Clasen wrote:
>
> And I assume that KDE users are just happy to run tons of unaudited
> toolkit code as root...
They are running Gnome/KDE as root to begin with. Where exactly is the
problem?
The problem lies in privileged code doing something unintentional either
due to 1) a bug in the code, 2) malicious exploit or 3) user ignorance.
Why would anyone want an application to run, anyway, that has the
potential of bringing down the system or accessing other users' files?
--
Richi Plana
8:19 a.m.
Richi Plana <myfedora <at> richip.dhs.org> writes:
Why would anyone want an application to run, anyway, that has the
potential of bringing down the system or accessing other users' files?
Unfortunately, when you're the only user on the system, running your
applications as your regular user won't help much, they can still eat all your
files. You'd have to run applications like browsers as a different user to take
advantage of the user-based security model, and I don't see many people doing
that.
Kevin Kofler
8:40 a.m.
On Thu, 2007-09-20 at 13:19 +0000, Kevin Kofler wrote:
Richi Plana <myfedora <at> richip.dhs.org> writes:
> Why would anyone want an application to run, anyway, that has the
> potential of bringing down the system or accessing other users' files?
Unfortunately, when you're the only user on the system, running your
applications as your regular user won't help much, they can still eat all your
files. You'd have to run applications like browsers as a different user to take
advantage of the user-based security model, and I don't see many people doing
that.
Yeah. And a user-based, micro-level SELinux policy would probably be
overkill. I suppose there's no point in restricting access of media
players to only multimedia files or write access to files not marked for
editing. There comes a point when the only solution is to fix the
application.
--
Richi Plana
1:46 p.m.
Kevin Kofler wrote:
Richi Plana <myfedora <at> richip.dhs.org> writes:
> Why would anyone want an application to run, anyway, that has the
> potential of bringing down the system or accessing other users' files?
Unfortunately, when you're the only user on the system, running your
applications as your regular user won't help much, they can still eat all your
files. You'd have to run applications like browsers as a different user to take
advantage of the user-based security model, and I don't see many people doing
that.
Note that we have SELinux policies by default for Firefox from Fedora 7
onwards which can be further tuned to limit damage. There is also a
guest user functionality in rawhide which can quite useful
http://danwalsh.livejournal.com/11913.html
Rahul
8:09 a.m.
On Thu, 2007-09-20 at 14:34 +0200, Ralf Ertzinger wrote:
Hi.
On Wed, 19 Sep 2007 16:29:42 -0400, Matthias Clasen wrote:
>
> And I assume that KDE users are just happy to run tons of unaudited
> toolkit code as root...
They are running Gnome/KDE as root to begin with. Where exactly is the
problem?
If that's no problem with you, then I have this "Love Letter" program
you might want to see! Just click on the executable and watch the fancy
graphics, ;).
Sorry ... couldn't resist.
--
Richi Plana
3:20 p.m.
Hi.
On Thu, 20 Sep 2007 07:09:31 -0600, Richi Plana wrote
If that's no problem with you, then I have this "Love
Letter" program
you might want to see! Just click on the executable and watch the
fancy graphics, ;).
Maybe I misunderstood Matthias' original comment, but I was under the
impression that he did not want to run screensavers as root because of
unaudited code. Which I found quite odd, given that we were talking about
running KDE/Gnome as root in the first place, so having a screensaver on
top could not make things much worse.
3:34 p.m.
On Thu, 2007-09-20 at 22:20 +0200, Ralf Ertzinger wrote:
Hi.
On Thu, 20 Sep 2007 07:09:31 -0600, Richi Plana wrote
> If that's no problem with you, then I have this "Love Letter" program
> you might want to see! Just click on the executable and watch the
> fancy graphics, ;).
Maybe I misunderstood Matthias' original comment, but I was under the
impression that he did not want to run screensavers as root because of
unaudited code. Which I found quite odd, given that we were talking about
running KDE/Gnome as root in the first place, so having a screensaver on
top could not make things much worse.
No, I was commenting on the fact that making screensavers work for root
is not really helping at all; considering that the entire desktop
session runs as root.
8:06 a.m.
Alan Cox wrote:
On Wed, Sep 19, 2007 at 02:49:19PM +0200, Denis Leroy wrote:
> Creating a normal user is not mandatory in anaconda (as it should be).
It should not be. In an environment using single sign on systems, ldap, NIS
or yellow pages it makes no sense.
Yes I agree with you here, my statement above was confusing. Having to
create a normal user should absolutely not be mandatory.
9:04 a.m.
On Wed, Sep 19, 2007 at 09:00:08AM -0400, Alan Cox wrote:
Secondly the security argument here is simply peeing in the wind as
you can
hit ctrl-alt-f1 and log in as root on a text console.
That's not the security argument.
The security argument is that GUI's mean a huge ammount of extra code running
as root. Tipically extremely buggy code...
Rui
--
Keep the Lasagna flying!
Today is Pungenday, the 44th day of Bureaucracy in the YOLD 3173
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
10:11 a.m.
On Wed, Sep 19, 2007 at 09:00:08AM -0400, Alan Cox wrote:
It should not be. In an environment using single sign on systems,
ldap, NIS
or yellow pages it makes no sense.
Secondly the security argument here is simply peeing in the wind as you can
hit ctrl-alt-f1 and log in as root on a text console.
Got an interesting situation recently: I just had installed a
reasonably updated fc5 with a us keyboard with no (nis) users enabled
yet, then moved the box to its final destination where the user has a
french (azerty) keyboard. C-A-F1 didn't work, but the rest of the
keyboard did, so I logged in as graphically as root.
Then opened an xterm, did a chvt 1, login and loadkeys fr, but that's
just me.
So, amusingly, there are cases where C-A-F1 does not work.
OG.
7:41 a.m.
On 19/09/2007, Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
Denis Leroy wrote:
> Rahul Sundaram wrote:
>> since there isn't normally a reason to do that
>
> I beg to differ here, that are many scenarios where the security issues
> are irrelevant. I see such systems on a daily basis here at work.
You snipped out the later part of my mail. If security concerns are
irrelevant, just turn on the option to enable root login just like you
are free to turn off the firewall or SELinux.
Unless I'm very much mistaken, the ability to turn on/off root login is not
an option during install. This differs a little from firewall and SEL
therefore.
Cheers
Chris
--
http://www.chruz.com
7:41 a.m.
Christopher Brown wrote:
Unless I'm very much mistaken, the ability to turn on/off root login is
not an option during install. This differs a little from firewall and
SEL therefore.
Not really. You can turn either of them, on or off post installation.
You can do a root login as explained in my other mail. Again KDM root
login was disabled until the last release and I am merely asking for the
user experience to be consistent across display manager.
Rahul
7:48 a.m.
On Wed, Sep 19, 2007 at 05:34:09PM +0530, Rahul Sundaram wrote:
Rex Dieter wrote:
>Rahul Sundaram wrote:
>
>>Root login has been disabled in GDM for a while now in rawhide. Would
>>KDM and other display managers be modified to be consistent with this
>>behavior? I would prefer if it was.
>
>What's the rationale (again?) for disabling root login?
See fedora-desktop list discussions. The goal IIUC was to discourage
root login via display managers since there isn't normally a reason to
do that and it presents a higher security risk.
Aren't those users the ones that most likely will need to login as root
(with a GUI) at some point in the future because for example they
managed to disable their user account? Do you really expect them to be
able use the command line from the console?
Kostas Georgiou
7:49 a.m.
Kostas Georgiou wrote:
Aren't those users the ones that most likely will need to login
as root
(with a GUI) at some point in the future because for example they
managed to disable their user account? Do you really expect them to be
able use the command line from the console?
I don't see how normal users would somehow manage to disable their user
account. Can you explain such a scenario that you have experienced? I
guess they do need to use a console in such circumstances.
Rahul
9:08 a.m.
On Wed, 2007-09-19 at 13:48 +0100, Kostas Georgiou wrote:
Aren't those users the ones that most likely will need to login
as root
(with a GUI) at some point in the future because for example they
managed to disable their user account? Do you really expect them to be
able use the command line from the console?
I'm guessing their assumption is anyone who administers a Fedora Linux
box should know how to use the console and commandline-apps.
Which is kinda contrary to us developing more GUI administration apps,
come to think of it.
--
Richi Plana
9:09 a.m.
On Wed, 19 Sep 2007 08:08:54 -0600
Richi Plana <myfedora(a)richip.dhs.org> wrote:
I'm guessing their assumption is anyone who administers a Fedora
Linux
box should know how to use the console and commandline-apps.
Which is kinda contrary to us developing more GUI administration apps,
come to think of it.
No, it's just getting rid of the assumption that you have to log in as
root to administrate something.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
11:06 a.m.
On Mon, 2007-09-24 at 15:43 +0100, Bill Crawford wrote:
On 18/09/2007, Jesse Keating <jkeating(a)redhat.com> wrote:
...
> No, it's just getting rid of the assumption that you have to log in as
> root to administrate something.
Even when one of the things you want to do is:
umount /home
system-config-lvm
...
mount -a
Well ... in fairness, the original argument was between giving root an X
Windows session to do administration vs. administering from a regular
user X Window session.
If administrative tasks like the one you mentioned happens often, then I
suggest those systems create at least one user whose $HOME isn't
in /home. :-p
--
Richi Plana
12:53 p.m.
on 9/24/2007 12:06 PM, Richi Plana wrote:
On Mon, 2007-09-24 at 15:43 +0100, Bill Crawford wrote:
> On 18/09/2007, Jesse Keating <jkeating(a)redhat.com> wrote:
> ...
>> No, it's just getting rid of the assumption that you have to log in as
>> root to administrate something.
> Even when one of the things you want to do is:
>
> umount /home
> system-config-lvm
> ...
> mount -a
Well ... in fairness, the original argument was between giving root an X
Windows session to do administration vs. administering from a regular
user X Window session.
If administrative tasks like the one you mentioned happens often, then I
suggest those systems create at least one user whose $HOME isn't
in /home. :-p
What I said the other, and I still feel this way, was that *if* you are
the qualified admin of this system you should know how to change the 'no
root GUI' default setting to allow root to login with a WM desktop. You
should not but you should know how to do this.
Or how to get to a root login without X when already logged as 'you' in a
WM, login as root an start an X session for your WM. And later how to
logout as root get back to logged in as 'you' in an X session DM.
Or how to do admin duties from a terminal in a 'you' DM by logging and
doing them from the CLI. Or, will in the terminal windows how to start, as
root, the GUI frontends that you would like to use.
Remember I said "qualified admin"? If you really are one of those you
should know how to do some, actually you should know how to do all, of
these. If you don't know how to do these. IMO you are not a "qualified
admin". And you have no business even being root.
Me? I am *not* qualified to admin a system but I know how to do all of
these examples.
--
David
8:35 a.m.
On 24/09/2007, David Boles <dgboles(a)gmail.com> wrote:
What I said the other, and I still feel this way, was that *if* you
are
the qualified admin of this system you should know how to change the 'no
root GUI' default setting to allow root to login with a WM desktop. You
should not but you should know how to do this.
OK, how about making it an install-time option, checked by default?
And if one can switch to a VT, login and run "startx" anyway, what's
the benefit, really, of disallowing root login except to make it
cosmetically more secure?
9:24 a.m.
Bill Crawford wrote:
On 24/09/2007, David Boles <dgboles(a)gmail.com> wrote:
> What I said the other, and I still feel this way, was that *if* you are
> the qualified admin of this system you should know how to change the 'no
> root GUI' default setting to allow root to login with a WM desktop. You
> should not but you should know how to do this.
OK, how about making it an install-time option, checked by default?
Piling more options everywhere isn't really a good answer.
And if one can switch to a VT, login and run "startx"
anyway, what's
the benefit, really, of disallowing root login except to make it
cosmetically more secure?
The amount of code running as root is significantly less in a VT
compared to running a entire desktop environment as root user.
Rahul
6:09 a.m.
See fedora-desktop list discussions. The goal IIUC was to discourage
root login via display managers since there isn't normally a reason to
do that and it presents a higher security risk. This has also been a
Hello Rahul,
default should be to allow root login for convenience and keep
it up to sysadmins to lock down a machine completely if this is
desired as local security policy.
regards,
Florian La Roche
6:14 a.m.
Florian La Roche wrote:
> See fedora-desktop list discussions. The goal IIUC was to
discourage
> root login via display managers since there isn't normally a reason to
> do that and it presents a higher security risk. This has also been a
Hello Rahul,
default should be to allow root login for convenience and keep
it up to sysadmins to lock down a machine completely if this is
desired as local security policy.
Security by default works better but this argument is irrelevant now
since it has enabled again in GDM as per the last Desktop SIG meeting.
The plan is to tackle this in a more comprehensive way in Fedora 9.
Rahul
7:05 a.m.
On Wed, Sep 19, 2007 at 06:49:22AM -0500, Rex Dieter wrote:
> Root login has been disabled in GDM for a while now in rawhide.
Would
> KDM and other display managers be modified to be consistent with this
> behavior? I would prefer if it was.
What's the rationale (again?) for disabling root login?
I assume its to make sure that if your LDAP or NIS services fail you
are totally screwed and cannot rescue the machine.
Alan
7:25 a.m.
On Wed, Sep 19, 2007 at 08:05:25AM -0400, Alan Cox wrote:
> What's the rationale (again?) for disabling root login?
I assume its to make sure that if your LDAP or NIS services fail you
are totally screwed and cannot rescue the machine.
Proposed alternative: enable root logins, but customize the default root
GUI environment so it is a clear and simple rescue/configuration workspace,
not just another user's desktop.
At BU, we've been doing this for a long time -- you get system-config-users
and a terminal window and that's it.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
7:39 a.m.
On 19/09/2007, Matthew Miller <mattdm(a)mattdm.org> wrote:
On Wed, Sep 19, 2007 at 08:05:25AM -0400, Alan Cox wrote:
> > What's the rationale (again?) for disabling root login?
> I assume its to make sure that if your LDAP or NIS services fail you
> are totally screwed and cannot rescue the machine.
Proposed alternative: enable root logins, but customize the default root
GUI environment so it is a clear and simple rescue/configuration
workspace,
not just another user's desktop.
At BU, we've been doing this for a long time -- you get
system-config-users
and a terminal window and that's it.
Or we could actually leave the user in control of the system and allow them
to nuke it if they want to. Give them enough rope and all that. I recall
that one system used to place a black bomb image in each corner of the
desktop and use a big red desktop background.
Cheers
Chris
--
http://www.chruz.com
7:52 a.m.
On Wed, Sep 19, 2007 at 08:25:54AM -0400, Matthew Miller wrote:
Proposed alternative: enable root logins, but customize the default
root
GUI environment so it is a clear and simple rescue/configuration workspace,
not just another user's desktop.
Thats an extremely good idea and one I like a great deal
7:34 a.m.
On Wed, Sep 19, 2007 at 08:25:54AM -0400, Matthew Miller wrote:
> Proposed alternative: enable root logins, but customize the default root
> GUI environment so it is a clear and simple rescue/configuration
> workspace,
> not just another user's desktop.
Thats an extremely good idea and one I like a great deal
+1 </meetoo>
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
novus ordo absurdum
9:24 a.m.
On Wed, 2007-09-19 at 07:34 -0500, Jon Ciesla wrote:
> On Wed, Sep 19, 2007 at 08:25:54AM -0400, Matthew Miller wrote:
>> Proposed alternative: enable root logins, but customize the default root
>> GUI environment so it is a clear and simple rescue/configuration
>> workspace,
>> not just another user's desktop.
>
> Thats an extremely good idea and one I like a great deal
+1 </meetoo>
Well, if it is ever decided to re-allow root login, then +1 to that
idea. Regular gnome sessions and KDE sessions just require so many user
processes to run and some to even daemonize themselves that it's scary
to think they've root privileges. I mean, who knows how well they're
written and what kind of havoc they could cause.
As for the X environment, give them TWM, ;).
--
Richi Plana
4:08 p.m.
On Wed, Sep 19, 2007 at 08:24:27AM -0600, Richi Plana wrote:
As for the X environment, give them TWM, ;).
There's no need to make things *painful*. How about metacity + lxpanel?
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
4:54 p.m.
On Wed, 2007-09-19 at 17:08 -0400, Matthew Miller wrote:
On Wed, Sep 19, 2007 at 08:24:27AM -0600, Richi Plana wrote:
> As for the X environment, give them TWM, ;).
There's no need to make things *painful*. How about metacity + lxpanel?
I was being facetious, :).
Seriously, though, a window manager and an application launcher should
be maximum. No gnome session managers, no nautilus, no dbus, no applets.
Does lxpanel make use of the menu options
inside /usr/share/applications/ or does it require it's own menu
configuration? Even a stripped-down menu selection (no games, no office
apps) might be a good idea. Wouldn't want a bug in gsudoku to bring the
machine down, ;).
--
Richi Plana
8:57 a.m.
Matthew Miller wrote:
On Wed, Sep 19, 2007 at 08:05:25AM -0400, Alan Cox wrote:
>> What's the rationale (again?) for disabling root login?
>>
> I assume its to make sure that if your LDAP or NIS services fail you
> are totally screwed and cannot rescue the machine.
>
Proposed alternative: enable root logins, but customize the default root
GUI environment so it is a clear and simple rescue/configuration workspace,
not just another user's desktop.
+1 Great idea!!!
Default root desktop with only System --> administration, Terminal and
some text editors
Identical in both Gnome and KDE..
Best regards
Jóhann B.
--
Johann B. Gudmundsson. RHCE,CCSA
Unix System Engineer.
IT Management.
Reiknistofnun University of Iceland.
Taeknigardi, Dunhaga 5. Email: johannbg(a)hi.is
IS-107 Reykjavik. Phone: +354-525-4267
Iceland. Fax: +354-552-8801
9:38 a.m.
On Wed, 2007-09-19 at 13:57 +0000, "Jóhann B. Guðmundsson" wrote:
Matthew Miller wrote:
> On Wed, Sep 19, 2007 at 08:05:25AM -0400, Alan Cox wrote:
>
>>> What's the rationale (again?) for disabling root login?
>>>
>> I assume its to make sure that if your LDAP or NIS services fail you
>> are totally screwed and cannot rescue the machine.
>>
>
> Proposed alternative: enable root logins, but customize the default root
> GUI environment so it is a clear and simple rescue/configuration workspace,
> not just another user's desktop.
>
+1 Great idea!!!
Default root desktop with only System --> administration, Terminal and
some text editors
Identical in both Gnome and KDE..
Even better force root to login only with twm (or something worst if it
exists) and only a xterm ... now that would be a great punishment for
not doing as told <g>
Simo.
9:55 a.m.
Simo Sorce wrote:
On Wed, 2007-09-19 at 13:57 +0000, "Jóhann B. Guðmundsson"
wrote:
> Matthew Miller wrote:
>
>> On Wed, Sep 19, 2007 at 08:05:25AM -0400, Alan Cox wrote:
>>
>>
>>>> What's the rationale (again?) for disabling root login?
>>>>
>>>>
>>> I assume its to make sure that if your LDAP or NIS services fail you
>>> are totally screwed and cannot rescue the machine.
>>>
>>>
>> Proposed alternative: enable root logins, but customize the default root
>> GUI environment so it is a clear and simple rescue/configuration workspace,
>> not just another user's desktop.
>>
>>
> +1 Great idea!!!
> Default root desktop with only System --> administration, Terminal and
> some text editors
> Identical in both Gnome and KDE..
>
Even better force root to login only with twm (or something worst if it
exists) and only a xterm ... now that would be a great punishment for
not doing as told <g>
Simo.
Hum let's see uh...
Application -->
1. Archive manager -- Might be used in rescue
situations
2. Calculator -- Not gonna be used in rescue
stituations ( could be removed )
3. Character map -- Not gonna be used in rescue
situations ( could be removed )
4. Dictionary -- Not gonna be used in rescue
situations ( could be removed )
5. Take a screenshot -- Not gonna be used in rescue
situations ( could be removed )
6. Terminal -- Might be used in rescue situations
7. Text Editor -- Might be used in rescue situations
8. VNC -- Not gonna be used in rescue situations
for his machine ( could be removed )
Edutainment --> Not gonna be used in rescue stituations ( could be
removed )
Games --> Not gonna be used in rescue stituations ( could be removed )
Graphics --> Not gonna be used in rescue stituations ( could be removed )
Internet, an browser an email client, pidgin, xchat -- > Rest could be
removed
Office --> Not gonna be used in rescue stituations ( could be removed )
Programming --> Not gonna be used in rescue stituations ( could be
removed )
Sound and Video --> Not gonna be used in rescue stituations ( could be
removed )
System tools --> Not gonna be used in rescue stituations ( could be
removed ) ( questionable File browser/Software updater )
Wine --> Not gonna be used in rescue stituations ( could be removed )
Places could stay ( from my point of view or be removed neutral )
System left as is..
Best regards
Johann B.
--
Johann B. Gudmundsson. RHCE,CCSA
Unix System Engineer.
IT Management.
Reiknistofnun University of Iceland.
Taeknigardi, Dunhaga 5. Email: johannbg(a)hi.is
IS-107 Reykjavik. Phone: +354-525-4267
Iceland. Fax: +354-552-8801
9:30 a.m.
On Wed, 2007-09-19 at 08:05 -0400, Alan Cox wrote:
On Wed, Sep 19, 2007 at 06:49:22AM -0500, Rex Dieter wrote:
> > Root login has been disabled in GDM for a while now in rawhide. Would
> > KDM and other display managers be modified to be consistent with this
> > behavior? I would prefer if it was.
>
> What's the rationale (again?) for disabling root login?
I assume its to make sure that if your LDAP or NIS services fail you
are totally screwed and cannot rescue the machine.
It's just disabled in GDM not via console/ssh if I understood correctly.
Simo.
7:04 a.m.
Hi
Root login has been disabled in GDM for a while now in rawhide. Would
KDM and other display managers be modified to be consistent with this
behavior? I would prefer if it was.
I assume exceptions are made for LiveCDs?
Rahul
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
novus ordo absurdum
7:51 a.m.
Jon Ciesla wrote:
> Hi
>
> Root login has been disabled in GDM for a while now in rawhide. Would
> KDM and other display managers be modified to be consistent with this
> behavior? I would prefer if it was.
I assume exceptions are made for LiveCDs?
Live images enable timed auto login as normal user with no password for
any user. First boot is only set to run when you install it to a hard disk.
Rahul
6064
days inactive
6071
days old
147 comments
30 participants
participants (30)
-
"Jóhann B. Guðmundsson" -
Alan Cox -
Benjamin LaHaise -
Bernie Innocenti -
Bill Crawford -
Christopher Brown -
Colin Walters -
David -
Denis Leroy -
Florian La Roche -
Jeff MacDonald -
Jesse Keating -
Jon Ciesla -
Kevin Kofler -
Kostas Georgiou -
Matthew Miller -
Matthias Clasen -
Nicolas Mailhot -
Olivier Galibert -
Patrice Dumas -
Rahul Sundaram -
Ralf Corsepius -
Ralf Ertzinger -
Rex Dieter -
Richi Plana -
Rob Crittenden -
Rudolf Kastl -
Rui Miguel Silva Seabra -
Simo Sorce -
Tomas Mraz