Mailing List Archive

On Thu, 7 Oct 2004 13:01:39 -0500, Jeff Smelser <tradergt@smelser.org> wrote:
>
> I don't disagree.. But your never gonna eliminate human error.. Because lets
> say etc-update saved old versions. Most people don't even realize the mistake
> until its too late.. They still have to put knoppix in and just restore the
> old version, over recreating it..
>
> So its not gonna save much.

Well, maybe, but I agree on the surface of it with Brant's 3-tiered
approach to looking at files. If etc-update did things differently
base don the 3 tiers then it could be better. I'll put my ideas in a
response to that note.

>
> > Please remember, I've done these stupid things on my boxes as I've
> > learned Gentoo, but the advantage was that I'm sitting there and can
> > struggle to get them fixed. This situation is one where the box is
> > remote and there is not super user at the other end with Linux admin
> > experience. He cannot even run vi!
>
> Nano is good for thos people.. :)

Good point. Couple this with the fact that he wears a hearing aid and
imagine having to say this over the phone:

paul-sam-space-alpha-ultra-xray-space-"funny character using shift
above the enter key"-gamma-relish-extra-paul-space-sam-sam-help-delta

Editing this way is no fun. With deep respect, every time I deal with
my dad this way I have a muc stronger connection to those among us
that have physical impairments. A user with hearing problems at the
other end of the phone line is like having your own typing problems.
It's tough!

- Mark

--
gentoo-user@gentoo.org mailing list

On Thu, 7 Oct 2004 12:55:18 -0700, Brant Katkansky
<brant.katkansky@gmail.com> wrote:
> > I'd (personally) prefer that fstab, modules.conf and all their varied
> > brothers and sisters, and probably a few other things, never be
> > changed and I get an ugly warning email once a day until I do make
> > those changes. There are just a few things, like disk partitions and
> > networking, that are so important to the operation of the box that
> > they should be cared for in a more managed way.
>
> (I'm going to piggyback on your post because I want to expand on what
> you're saying, not because I disagree.)

thanks!

>
> I would classify config files installed by portage in several categories -
>
> 1) Application and/or non-system critical config files. Updating
> these files may break will not prevent the system from booting, but
> may break individual applications and/or services.
>
> 2) System critical config files, which have "sane" defaults. While
> updating these files (if they have been modified by the
> installer/administrator) may break mission-critical services or make
> the system more vulnerable, doing so will not render the system
> unbootable (e.g. inittab, , etc).
>
> 3) System critical config files, which do *not* have sane defaults.
> Updating these files will always (or almost always) break the system
> and prevent it from being booted.
>
> I want to concentrate on the latter. Take for example /etc/fstab.
> The default fstab will prevent my system from booting, and in fact
> will prevent ANY system from booting. IMHO, portage should not
> install /etc/fstab, but should instead install it as /etc/fstab.sample
> - as the grub ebuild does with /boot/grub/grub.conf.sample.
>
> Another example /etc/{passwd},{shadow} - the installer is required to
> modify this file indirectly (by running passwd) in order to make the
> system usable. Allowing etc-update (or other tool) to update either
> the passwd or shadow file is a mistake in the overwhelming majority of
> cases. The same goes for /etc/modules.autoload.d/*.
>
> Were it up to me, I would install all of the files in category 3) as
> $filename.sample and let the ebuild copy them to $filename only if
> $filename does not already exist - especially in the case of
> /etc/fstab where the default file is completely useless and/or harmful
> to a configured system.

I very much like your idea. I'd be very satified to get a simple tweak
to etc-update that did the following:

1) Run etc-update the first time. It will only allow you to do the
edits on files in category 1. Categories 2 & 3 are 'grayed out' in
whatever means the developers think appropriate. There is a new
etc-update option that allows category 2 & 3 files to be 'not grayed
out' if the administrator wants it to work the way it does today. All
category 1 files must be updated first.

2) Run etc-update a second time. Category 2 files are addressed.
Category 3 is grayed out.

3) Run etc-update a third time and it does what it does today.

At least this way there would be no confusion about a system critical
file being in the middle of 50 other files and being missed. And for
those who want to work the way things work today that can run
"etc-update --I-dont-make-mistakes". ;-)
>
> Using dispatch-conf only helps if you realize your mistake before you reboot.
>
> Live CDs and/or Knoppix only help if you have qualified persons with
> physical access to the console, which in some cases is not the case.
>

It was difficult to get the machine and connexted to the net in a way
that was useful to me, but he did it and we got it fixed.

Thanks,
Mark

--
gentoo-user@gentoo.org mailing list

On Thursday 07 October 2004 03:04 pm, Mark Knecht wrote:
> Good point. Couple this with the fact that he wears a hearing aid and
> imagine having to say this over the phone:

At work, I use a kde editor from konsole.. use kwrite, looks just like notepad
but has more to it.. Wouldnt notice the difference..

Jeff

On Thu, 7 Oct 2004 13:04:14 -0700, Mark Knecht <markknecht@gmail.com> wrote:

> Well, maybe, but I agree on the surface of it with Brant's 3-tiered
> approach to looking at files.

You may have misunderstood - I was not necessarily suggesting that
etc-update do anything different, but that the ebuilds be done
differently when they contain system-critical files that aren't
approproate to update.

--
gentoo-user@gentoo.org mailing list

> I very much like your idea. I'd be very satified to get a simple tweak
> to etc-update that did the following:

Personally, I don't see this as being a problem with etc-update - it's
a problem with the ebuild that installs the configuration file to
begin with (e.g. /etc/fstab should get installed as /etc/fstab.sample
and copied if /etc/fstab doesn't exist already).

>
> 1) Run etc-update the first time. It will only allow you to do the
> edits on files in category 1. Categories 2 & 3 are 'grayed out' in
> whatever means the developers think appropriate. There is a new
> etc-update option that allows category 2 & 3 files to be 'not grayed
> out' if the administrator wants it to work the way it does today. All
> category 1 files must be updated first.

Problem with this approach is that etc-update needs to have some
notion of what files belong in what category, and that's not a
scalable way of doing things, unless the list of files that it
shouldn't touch is very small and static. Even if the list *is*
small, it's still probably better to let the process be controlled by
the ebuild.

--
gentoo-user@gentoo.org mailing list

On Thu, 7 Oct 2004 13:42:03 -0700, Brant Katkansky
<brant.katkansky@gmail.com> wrote:
> > I very much like your idea. I'd be very satified to get a simple tweak
> > to etc-update that did the following:
>
> Personally, I don't see this as being a problem with etc-update - it's
> a problem with the ebuild that installs the configuration file to
> begin with (e.g. /etc/fstab should get installed as /etc/fstab.sample
> and copied if /etc/fstab doesn't exist already).
>
> >
> > 1) Run etc-update the first time. It will only allow you to do the
> > edits on files in category 1. Categories 2 & 3 are 'grayed out' in
> > whatever means the developers think appropriate. There is a new
> > etc-update option that allows category 2 & 3 files to be 'not grayed
> > out' if the administrator wants it to work the way it does today. All
> > category 1 files must be updated first.
>
> Problem with this approach is that etc-update needs to have some
> notion of what files belong in what category, and that's not a
> scalable way of doing things, unless the list of files that it
> shouldn't touch is very small and static. Even if the list *is*
> small, it's still probably better to let the process be controlled by
> the ebuild.
>

I think both options are good. For system critical files which should
normally not be modified by new versions a .sample file would be
better. However, there *are* some instances where these files need to
be updated. Say a new option, critical security updates, etc. I
*suppose* that if the sample changes, you can still see the diff, but
aren't you more likely to just "-5" if you'r eonly updating sample
files?

Both of the options could be used. The ebuild would (somehow) specify
which conf files are in which category and portage could keep track of
which file syou have installed and their categories.....somewhere. Or
it could only keep track of tiers 2 and 3.

--
paperCrane --Justin Patrin--

--
gentoo-user@gentoo.org mailing list

On Thu, 7 Oct 2004 13:42:03 -0700, Brant Katkansky
<brant.katkansky@gmail.com> wrote:
> > I very much like your idea. I'd be very satified to get a simple tweak
> > to etc-update that did the following:
>
> Personally, I don't see this as being a problem with etc-update - it's
> a problem with the ebuild that installs the configuration file to
> begin with (e.g. /etc/fstab should get installed as /etc/fstab.sample
> and copied if /etc/fstab doesn't exist already).
>
> >
> > 1) Run etc-update the first time. It will only allow you to do the
> > edits on files in category 1. Categories 2 & 3 are 'grayed out' in
> > whatever means the developers think appropriate. There is a new
> > etc-update option that allows category 2 & 3 files to be 'not grayed
> > out' if the administrator wants it to work the way it does today. All
> > category 1 files must be updated first.
>
> Problem with this approach is that etc-update needs to have some
> notion of what files belong in what category, and that's not a
> scalable way of doing things, unless the list of files that it
> shouldn't touch is very small and static. Even if the list *is*
> small, it's still probably better to let the process be controlled by
> the ebuild.
>

OK, well, that's why I'm not a developer! ;-) None the less, any
solution that makes this more safe would make many folks happy. My
suspicion is that the people most likely to get really burned by this
problem are most likely the people most likely not to speak up.

In my mind the list of what is in what category was something like
/etc/portage/package.keywords. Some default file gets downloaded.
Experienced people can modify it as they wish.

You were correct that I misunderstood the idea of doing it in the
ebuild, but I think that the only time an ebuild might actually
install fstab, if it ever does, is when you fist build a system. My
problems with fstab have always been self generated through etc-update
misuse. I think that fixing ebuilds might not be well accepted by the
developer community, but I don't know. It also depends on how many of
these files there really are. You know more than I.

(Doesn't explain the talkative noob like me, but there's always on in
the crowd...)

--
gentoo-user@gentoo.org mailing list

On Thu, 7 Oct 2004 14:27:23 -0700, Brant Katkansky
<brant.katkansky@gmail.com> wrote:
> > You were correct that I misunderstood the idea of doing it in the
> > ebuild, but I think that the only time an ebuild might actually
> > install fstab, if it ever does, is when you fist build a system. My
> > problems with fstab have always been self generated through etc-update
> > misuse. I think that fixing ebuilds might not be well accepted by the
> > developer community, but I don't know. It also depends on how many of
> > these files there really are. You know more than I.
>
> That's just it - it was the ebuild attempting to install /etc/fstab,
> etc that created the problem. It shouldn't do that, it should install
> /etc/fstab.sample, since that's what it is.
>

Humm...OK, I don't remember that happening but I'll defer to you since
you seem pretty sure. Seems to me your idea is a good one. I hope
someone in power will consider acting on it. I put in a much simpler
portae enhancement request quite a while ago having to do with portage
showing you when you were using a ~ package. No response, and that one
was very simple, at least in my simple mind.

Cheers,
Mark

--
gentoo-user@gentoo.org mailing list