system autodeath

Jeff Spaleta jspaleta at
Thu Aug 21 18:25:32 UTC 2008

On Thu, Aug 21, 2008 at 8:02 AM, Matthew Miller <mattdm at> wrote:
> And it's part of our responsibility: we're putting powerful software into
> their hands and then not providing security updates for it for very long at
> all. Turning off network access before they all become part of a gigantic
> botnet is the right thing to do.

I think there is an argument to be made to encourage our users to
choose responsible use of technology. A part of that is adequate
education as to what responsibility actually means in context of
making a personal choice. I'm not sure all efforts to disseminate best
practises are always best achieved by silently active enforcement
policies which do not have a timely educational component meant to
educate the system admin or user when the enforcement engages.

Now I'm not saying we shouldn't consider doing something by default. I
would think that something designed as autoannoy instead of autodeath
would be more appropriate.

For desktop machines..hooking the concept behind autodeath into
packagekit to give users a choice to use preupgrade or turn off the
network..seems pretty reasonable...and it seems people are already
thinking hard about that particular usage case.

For machines which aren't meant to be used like a desktop... remotely
hosted machines with ssh remote logins or whatnot...would it be
reasonable to have autoannoy change the motd or message at login to
indicate to remotely logged in users that the machine is no longer
able to receive updates and communicate the associated risks of that
situation? Thus informing users of such remotely located Fedora
systems that they need to take action, or their hosting company needs
to take action...but without locking them out of the system entirely
by bringing the network down?  How many hosting companies out there
sell access to Fedora systems to people without adequately informing
them as to the EOL policies and are willing to continue to take money
to host EOL'd Fedora systems with no due diligence on their part as a
hosting company to help their clients handle Fedora release EOL? Can
we give users of systems like that enough information to take steps to
rectify the EOL related problems their hosting company didn't prepare
them for.. without arbitrarily shutting them out of their own systems?


More information about the fedora-devel-list mailing list