Re: Disable ZeroConf: how to ?
-----BEGIN PGP SIGNED MESSAGE-----
Am Fr den 4. Mär 2011 um 10:31 schrieb Wouter Verhelst:
[Corporate users with preference for security]
[Home users with preference for convenience]
I somewhat agree. But not in all consequence.
For that users that you call "Corporate users" I think I can fully
agree. But not with "Home users".
The reason is not that obvious but might be clear when looking to the
image, systems have in the world:
Windows: Insecure, full control, many software, games, official support
Mac: Easy, colorful, all is moving and wabbering
Debian: Secure, clear dependencies, no hidden control (that would
overwrite administrator settings), absolute control
Ubuntu: Colorful, Easy, more or less secure
SuSI^HE: Much of hidden control, insecure (somewhat, but who cares),
Redhat: Official supported, not that many packages
I left out many other systems but that should be enough to show, what I
want to show.
A user that installs Debian on his system will do that due to the
reputation in security. If he want to have a simpler system he would
install, for example, Ubuntu, Mac or Windows.
So I do not think that we should sell the reputation of a secure system
just for the convenience. But I think that, for that people who do not
care about the part of security, such services should be easily to
enable (Maybe with a debconf question that explains the consequences).
I do not think that Debian should be good for every DAU (German
abbreviation, English would be luser or so). I think Debian should be a
distribution for experts and professionals (but not exclusive).
> > Well, they might be for a mac or windows user that is not care about
> > security at all. But it is horror for a debian user who care at least a
> > bit about security.
> Let's just say 'end users who are not very aware of computing
> technology' rather than 'mac or windows user', shall we?
Well, I played intentional with the clichés as the most people (here)
would understand that it stands for them. (However, I might fail with
the idea. But see above)
And it has an other reason too I used that clichés, I do not think that
debian should reuse the errors and mistakes that systems above did do in
the past (Just think about the easy sharing stuff on early windows
(netbios and contortions, that was the target for many attacks in the
past, the designers of that services even did not think about the
problems they created). I think zeroconf with all the stuff around is on
the way to go the same way than that.
If the user want to have it, well then he should be able to do. But
debian (and in my eyes all systems) should not give them the pistol, arm
it and show them how to shoot himself in the head. We can sell them the
pistol but should prepare them about the danger it can have.
> There are several Debian users who fall in that category, too. And while
> I agree that disabling zeroconf should be easily possible, I think a
> default of 'convenience for a home user' is not a bad thing for a
> distribution that is used for both corporate and home environments. Such
> a default would include 'enabling zeroconf'.
As I told, I think that the default should be disabled (as that would
correct for most of the debian users). But I agree that the
enabling/disabling should be easy; and not only per system, zeroconf
insists on several systems like avahi, link local, mdns, ...
> > And even worse, debian is often used on server platforms where you never
> > ever want to have any such magically configured services.
> Since avahi isn't a dependency of anything you'd want to install on a
> server -- I personally have never installed gnome on a server, for
> instance -- it usually isn't.
True. But sometimes you need a software component on the server that you
usually only use on laptops or desktops. One example is the
wpa-supplicant, that is common to test radius servers. It should not be
that this accidentally leads to zeroconf components with the
dependencies. (I did not check if that is the case in my example above.)
Klaus Ethgen http://www.ethgen.ch/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus@Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
-----END PGP SIGNATURE-----