A Topic that needs to be discussed on next the QA meeting..

Andrew Farris lordmorgul at gmail.com
Tue Mar 18 02:53:12 UTC 2008


Johann B. Gudmundsson wrote:
> Thanks for making that one clear I have actually been waiting for some 
> one to give me a straight
> answer regarding that matter and this just proves that Fedora will never 
> be dominating the world :) .
> 
> That kinda also explains all this whole RTFM for the end users and he 
> has to be and is expected to be
> an "Linux Guru " attitude that still exists here ( Bug 436227 for 
> example )...

Ok so you think it should 'just work' for people who don't know how to set 
things up or adjust configurations.  So defaults need to be in place, and 
services need to be alive, and hardware needs to be supported.

> If we are targeting a whole bunch of "segments" then we should
> release specifically tuned to those "segments"
> 
> M$ has a server version Mac OS X has a server version
> there is a reason for it!
> 
> <whisper>Even Redhat has few *versions*....
> 
> So why cant Fedora release a server version?
> 
> This whole TRY TO PLEASE ALL concept is flawed..

I agree there is an issue with some default configuration decisions seemingly 
being guided by server/enterprise considerations; and one could make the 
assumption it is basically caused by the relationship of Fedora to RHEL.  Fedora 
doesn't need a server version.

I think you're right that ssh being open for users who never intend to use it is 
unnecessary.  I think if someone installs on a headless box and doesn't have a 
kickstart file that deals with their needed firewall setup they should be 
slapped.  But moving to separate base configurations (server/desktop/etc) is a 
step backwards.

>> Well, that's no longer a default installation then, is it?  Should we
>> disable CUPS too? (that at least has a recent history of issues).
>>
>>   
> YES ALONG WITH AVAHI BLUETOOTH AND MORE...
> until the system can proparly detect HW and enable services on demand...
> 
> Fedora cant be tuned to everybody's needs!
> 
> The end user should be making that chose not Fedora trying to make 
> "guesses" on how
> he's gonna setup his system.
> 
> We should be delivering a solid secure product then it's on the users 
> hands if he messes it up
> not us delivering it already unsecure.

Quite frankly... you want cake to eat and keep too.  Think this quoted text 
through again.  You want a system that does not require a user to be an expert, 
which does not anticipate his service needs, which is secured completely when it 
is installed, but which an unskilled and unexperienced user is able to configure 
immediately after they installed it.  You want all services including those that 
support his hardware to be off until requested, but I'm sure you want it all to 
'just work' when he gets done with firstboot.  If the user happens to cancel out 
of firstboot, or it (heaven forbid) crashes, he'll have a system he has no hope 
of getting operational because its completely dormant and locked down tight when 
he has no experience with the system.

I'd like world peace while you're at it.  Some sane defaults are necessary in a 
practical world.  The issue is whether open ssh ports are sane for desktop 
installs.  You and I disagree with most others it seems, but not as big an issue 
as you're making it out to be.

Had you even considered asking denyhosts to be a part of the base install and 
configured to start blocking hosts after 10 account failures, or when attempts 
at service account logins are made?  Problem solved.. ssh still open.

I would argue that blocking root from ssh logins by default would be smart.  I 
would think a livecd install (almost always a desktop user) it should be blocked 
by the firewall by default.  But seriously this rant is a bit over the top.

-- 
Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----




More information about the fedora-test-list mailing list