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

Re: Bug#72738: Unnecessary changes to /etc/passwd



Thus spake Christian Kurz on Sat, Sep 30, 2000 at 04:54:57AM CDT
> 
> > follow this format for non-specific problem reporting then it should be
> > explained on <http://www.debian.org/Bugs/Reporting>.  It's not.
> 
> And where's there written that you should use the package unknown if you
> had problems with the upgrade in general?

It was appropriate to put something in here.  "unknown" was logical, and I
believe you and every one else who read it got the picture.  If someone
wants me to use particular wording in a report, I should be instructed to
do so, but IMHO this is silly nitpicking.  What does it matter whether I
used "general" or "unknown".  I expect this kind of pettiness from bored
government bureaucarats, not from developers of a major Linux distribution.

> How often should I write you again, that the script update-passwd get's
> _ONLY_ executed, when _YOU_ as the admin, decide to do so. While
> upgrading passwd you will get the following message:
> 
> |Checking if your system passwd, shadow and group files are correct...
> |
> |It looks like I need to make some changes to your system. Without those
> |changes some packages might not work correctly. The list of changes are
> |listed above. For more documentation on the Debian account policies
> |please read /usr/share/doc/base-passwd/README.

An appropriate addition to this should read:

                            * * * * * * * * *

WARNING:  If you have manually modified entries in /etc/passwd with UIDs in
the range of 0 - 99, running this scirpt may render components related to
these entries inoperable.  DO NOT make these changes unless you understand
the full implication of doing so.

                            * * * * * * * * *

Two sentences - no big deal, right?   Probably would have saved me a lot of
hassle, and probalby others as well.  Such a warning would be completely
consistent with other package updates in Debian which kindly provide
appropriate warnings of this nature.  I've rather come to expect it.

> Then submit a bug for the package so that the master-file for it gets
> changed but don't blame debian for this, because _you_ told the script
> to update/change your passwd. 

Let's get past blame here, and talk about what works best, what's safest,
and what will make Debian more user friendly without compromising function.  

> > I make the decision to drive my car, too, but I don't expect it to drive me
> > into a utility pole unless I very explicitly steer it in that direction. 
> > What the update script did was broken, whatever my answer may have been to
> > the install question.
> 
> It was not broken! Read above what I wrote about it.

The behavior of the script is BROKEN!  Period!!  It failed to give adequte
warning, to make a proper backup, and it mucked with a passwd entry which it
had no business changing.  How many times do you _have_ to tell me that it's
my fault and the script isn't broken?  Well you'd damn sure better allocate
a lot of time for it on an ongoing basis becuase I'm not about to change my
mind on this, and I will continue to disagree with you as long as you chose
to disagree with ME on this issue!  If you're tired of repeating your false
assertions over and over to me, consider that I'm damn sure tired of hearing
them.  Study standard Unix system administration!  Whether or not I pushed
the button on this, the script violates a number of very basic principles of
proper system administation.  When I was working for an ISP in Austin some
years ago I would have gotten >fired< for putting in place a script which is
this out of compliance with standard Unix administrative standards.

> > This is all the more reason to remove the majordomo entry from
> > passwd.master.
> 
> Then submit a matching bug report.

I will do so.

> > The mail server was NOT broken, nor was my qmail list server (ezmlm). The
> > majordomo list server >was< broken (mail server != list server).  I said
> 
> And this can't be noticed after an upgrade? 

It was, but not until it was called to my attention by someone else.  I had
no expectation that any portion of the upgrade would do something as stupid
and broken as to modify the list server home directory in /etc/passwd.  I
expected more of Debian.  Functionality of the list server rests solely on
the functionality of perl and of the mail server, both of which I determined
to be OK.

> When do you understand, that there's no blackbox and there's a standard
> passwd for debian-systems that normally doesn'get changed by the admin,
> only with some new users added or removed. And the update-passwd script
> only makes it changes to the passwd to make it identically with the
> debian-standard, if you as the admin request that.

The standard MUST take a back seat to functionalty!  If enforcing a standard
in this fashion is going to break things, then the answer to question of
"when do you understand" is "never!" and you can either stop telling me
this, or keep repeating it as long as you like, but you're not going to
change my mind.  'Nuff said!

-- 
Lindsay Haisley       | "Everything works    |     PGP public key
FMP Computer Services |       if you let it" |      available at
fmouse@fmp.com        |    (The Roadie)      | <http://www.fmp.com/pubkeys>
http://www.fmp.com    |                      |



Reply to: