[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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).

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 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
----                                                                       ----

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]