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

Re: Bug#224509: [PROPOSAL] Correct spurious promise regarding TTY availability



* Chris Waters

 > I've never heard anyone suggest any reason for disallowing TTYs
 > *except* for running apt-get under cron/at.  And running update under
 > cron is a BAD IDEA(tm)!  If something goes wrong, it leaves your
 > system potentially unusable and inaccessible!  If you must do
 > something under cron's control, use 'apt-get -d', to download the
 > packages, then do the actual install manually, under human control.

  I believe you are blowing the risk factor out of proportions.  Sure,
 severe breakage from upgrades happens occasionally, but I don't think
 situations where an upgrade is unproblematic in interactive mode,
 but damages the system badly in non-interactive mode, to be anything
 but extremely rare.

  For example, the last major breakage that bit me as I recall was when
 ifconfig stopped working.  Which would have happened irregardless of
 the broken package being installed from cron-apt or by hand.

  It's anyway risk vs. convenience.  I like to decide on my own
 which one is the most important to me on the various systems.  On
 my laptop (which is already running unstable, and are thus more
 prone to breakage anyway), I opt for the convenience of being able
 to wake up every morning to a day-fresh sid installation.  On a
 mission-critical server, on the other hand, the issue is vastly
 different and I wouldn't dream of using cron-apt there.  I'd like
 the choice to be mine to make, that's all.

* Tore Anderson

 > Doing "ssh somehost apt-get install foo" (or similar).

* Chris Waters

 > This is generally a bad idea too.  If something goes wrong, you may be
 > stuck, and unable to reconnect to the machine to fix the problem.  If
 > you ssh in first, and then run apt-get, your chances of fixing any
 > problems that may arise is far greater, since you'll have an existing
 > connection and a running shell to work with.  Even with "-t", I
 > recommend against this.

  My above points is valid for this too.  Anyway, if the perceived
 breakage here was in, say, PAM or login, it is likely to assume that
 I would have logged out, being blissfully ignorant of the breakage
 until I tried in vain to log in again at a later date.  So I can't
 really be one hundred percent safe in any case -- I have to make
 a conscious decision as to how extensive security measures I'll have
 to implement on a case-by-case basis.

-- 
Tore Anderson



Reply to: