Re: [gentoo-user] Is it possible to protect *INDIVIDUAL FILES* against etc-update?

2006-10-17 Thread Walter Dnes

Thank you, thank you, thank you verrry verrry much


  That's *EXACTLY what I'm looking for.

-- 
Walter Dnes <[EMAIL PROTECTED]> In linux /sbin/init is Job #1
My musings on technology and security at http://techsec.blog.ca
-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] Is it possible to protect *INDIVIDUAL FILES* against etc-update?

2006-10-17 Thread Neil Bothwick
On Tue, 17 Oct 2006 15:16:01 +0200, Bo Ørsted Andresen wrote:

> > As I've mentioned several times before, there was a patch to
> > dispatch-conf to do just this. You added the files you didn't want
> > touching, ever, to a line in the config file. Unfortunately, the patch
> > hasn't been updated for a couple of years and stopped working a while
> > ago. Why not re-open the bug at
> > http://bugs.gentoo.org/show_bug.cgi?id=68618  
> 
> https://bugs.gentoo.org/show_bug.cgi?id=151685

I've already posted an updated patch to the original bug.


-- 
Neil Bothwick

What's the difference between ignorance and apathy?
I don't know and I don't care


signature.asc
Description: PGP signature


Re: [gentoo-user] Is it possible to protect *INDIVIDUAL FILES* against etc-update?

2006-10-17 Thread Bo Ørsted Andresen
On Sunday 15 October 2006 14:27, Neil Bothwick wrote:
> As I've mentioned several times before, there was a patch to
> dispatch-conf to do just this. You added the files you didn't want
> touching, ever, to a line in the config file. Unfortunately, the patch
> hasn't been updated for a couple of years and stopped working a while
> ago. Why not re-open the bug at
> http://bugs.gentoo.org/show_bug.cgi?id=68618

https://bugs.gentoo.org/show_bug.cgi?id=151685

-- 
Bo Andresen


pgprOQ2Sq7Ok3.pgp
Description: PGP signature


Re: [gentoo-user] Is it possible to protect *INDIVIDUAL FILES* against etc-update?

2006-10-17 Thread Neil Bothwick
On Mon, 16 Oct 2006 17:57:57 -0400, Walter Dnes wrote:

>   Maybe I didn't make myself clear enough.  It works as designed.  I did
> not overwrite the files, but I'm getting annoyed at having to tell
> etc-update "NO" every few weeks when I run etc-update.  There are
> anywhere from 10 to 40 files to plow through.  And I have a 7-year-old
> PIII Dell as my emergency backup machine, so I repeat the process all
> over again.

I've fixed the dispatch-conf patch in Bug #68618 to work with the latest
dispatch-conf. Add a line to /etc/dispatch-conf to specify files to be
ignored by dispatch-conf like

frozen="/etc/rc.conf /etc/conf.d/clock"

 http://bugs.gentoo.org/show_bug.cgi?id=68618


-- 
Neil Bothwick

Don't forget that MS-Windows is just a temporary workaround until you can
switch to a GNU system.


signature.asc
Description: PGP signature


Re: [gentoo-user] Is it possible to protect *INDIVIDUAL FILES* against etc-update?

2006-10-16 Thread Richard Fish

On 10/16/06, Walter Dnes <[EMAIL PROTECTED]> wrote:

long will it take me to realize what's happened?  What I'm asking for is
a way to pre-emptively tell etc-update not to bother me about certain
files.  Zap the new version and keep the old.


cat > my_etcupdate.sh <

Re: [gentoo-user] Is it possible to protect *INDIVIDUAL FILES* against etc-update?

2006-10-16 Thread Walter Dnes
On Sun, Oct 15, 2006 at 09:06:40AM +0200, Bo ?rsted Andresen wrote

> I suspect you don't really understand what CONFIG_PROTECT{,_MASK} is. Please 
> read the output of `emerge --help --config`. All the files you've mentioned 
> are covered by CONFIG_PROTECT in a default configuration so if they aren't it 
> means you've screwed up your CONFIG_PROTECT and/or CONFIG_PROTECT_MASK 
> variables. Otherwise it is you who overwrote those files with 
> etc-update/dispatch-conf or whatever you use for that.

  Maybe I didn't make myself clear enough.  It works as designed.  I did
not overwrite the files, but I'm getting annoyed at having to tell
etc-update "NO" every few weeks when I run etc-update.  There are
anywhere from 10 to 40 files to plow through.  And I have a 7-year-old
PIII Dell as my emergency backup machine, so I repeat the process all
over again.

  What worries me is that one of these days I'll hit the wrong key (Y
instead of N) and zap a config file.  Yes, I do have backups, but how
long will it take me to realize what's happened?  What I'm asking for is
a way to pre-emptively tell etc-update not to bother me about certain
files.  Zap the new version and keep the old.

-- 
Walter Dnes <[EMAIL PROTECTED]> In linux /sbin/init is Job #1
My musings on technology and security at http://techsec.blog.ca
-- 
gentoo-user@gentoo.org mailing list



Re: [gentoo-user] Is it possible to protect *INDIVIDUAL FILES* against etc-update?

2006-10-15 Thread Neil Bothwick
On Sun, 15 Oct 2006 00:40:52 -0400, Walter Dnes wrote:

> > Yes, etc-update shows it to your before asking what to do. Check the
> > contents of each file before allowing it to be overwritten, and never,
> > ever let etc-update overwrite etc/fstab, /etc/passwd or /etc/group.  
> 
>   CONFIG_PROTECT and CONFIG_PROTECT_MASK work at the *DIRECTORY* level.

That will change soon IIRC.

> What I really want/need is a feature that allows additional protection
> *FOR INDIVIDUAL FILES*.  E.g...

You don't understand what CONFIG_PROTECT means, it prevents files being
automatically overwritten during installation, leaving them to you to
update.

>   - my customized /etc/conf.d/local.start or /etc/conf.d/local.stop
> should *NEVER* be replaced with an empty version

Agreed.
 
>   - /etc/rc.conf should be left alone too.  ***FOR THE UMPTEENTH TIME,
> NO I DO NOT WANT NANO REPLACING VIM AS MY "EDITOR"***

How would you know about changes to rc.conf? Either new features or changes in 
the way things are done would pass you by.

>   And the list goes on and on.  Howsabout an environmental variable
> CONFIG_PROTECT_FILES, containing a list of protected files?  I'm ready
> to submit a feature request if necessary.  Does anybody have additional
> comments?

As I've mentioned several times before, there was a patch to
dispatch-conf to do just this. You added the files you didn't want
touching, ever, to a line in the config file. Unfortunately, the patch
hasn't been updated for a couple of years and stopped working a while
ago. Why not re-open the bug at
http://bugs.gentoo.org/show_bug.cgi?id=68618


-- 
Neil Bothwick

If you think that you can truncate my sig to 75 chars, then you can just
fu


signature.asc
Description: PGP signature


Re: [gentoo-user] Is it possible to protect *INDIVIDUAL FILES* against etc-update?

2006-10-15 Thread Bo Ørsted Andresen
On Sunday 15 October 2006 06:40, Walter Dnes wrote:
[SNIP]
>   CONFIG_PROTECT and CONFIG_PROTECT_MASK work at the *DIRECTORY* level.
> What I really want/need is a feature that allows additional protection
> *FOR INDIVIDUAL FILES*.  E.g...
>
>   - my customized /etc/conf.d/local.start or /etc/conf.d/local.stop
> should *NEVER* be replaced with an empty version
>
>   - /etc/rc.conf should be left alone too.  ***FOR THE UMPTEENTH TIME,
> NO I DO NOT WANT NANO REPLACING VIM AS MY "EDITOR"***
>
>   - /etc/conf.d/clock too.  ***FOR THE UMPTEENTH TIME, NO I DO NOT WANT
> MY SYSTEM CLOCK SET TO GMT***
>
>   - /etc/ssmtp/ssmtp.conf too.  ***FOR THE UMPTEENTH TIME, NO I DO NOT
> WANT MY CUSTOMIZED FILE REPLACED WITH AN EXAMPLE FILE***
>
>   And the list goes on and on.  Howsabout an environmental variable
> CONFIG_PROTECT_FILES, containing a list of protected files?  I'm ready
> to submit a feature request if necessary.  Does anybody have additional
> comments?

I suspect you don't really understand what CONFIG_PROTECT{,_MASK} is. Please 
read the output of `emerge --help --config`. All the files you've mentioned 
are covered by CONFIG_PROTECT in a default configuration so if they aren't it 
means you've screwed up your CONFIG_PROTECT and/or CONFIG_PROTECT_MASK 
variables. Otherwise it is you who overwrote those files with 
etc-update/dispatch-conf or whatever you use for that.

I suppose you could work around your own clumsiness ;) by removing the 
mentioned files in post_pkg_postinst of sys-apps/baselayout and 
mail-mta/ssmtp. Something like e.g.:

# mkdir -p /etc/portage/env/sys-apps && \
echo 'post_pkg_postinst() {
echo "Removing new rc.conf, local.{start,stop} and clock"
rm -fv ${ROOT}/etc/._cfg_rc.conf \
   ${ROOT}/etc/conf.d/._cfg_{local.start,local.stop,clock}
}' >> /etc/portage/env/sys-apps/baselayout

PS: Please don't capitalize your sentences like that. It's really annoying..

-- 
Bo Andresen


pgpO5dKEewcPa.pgp
Description: PGP signature


[gentoo-user] Is it possible to protect *INDIVIDUAL FILES* against etc-update?

2006-10-14 Thread Walter Dnes
  Changing thread name here, because I'm going off on a tangent...

On Fri, Oct 13, 2006 at 04:33:19PM +0100, Neil Bothwick wrote
> On Fri, 13 Oct 2006 08:22:04 -0700 (PDT), maxim wexler wrote:
> 
> > IIRC the last time I updated baselayout it overwrote
> > some important files and my system was un-usable. In
> > all the excitement I failed to note what they were.
> 
> That wasn't baselayout, it was you when running etc-update.
> 
> > Is there a list somewhere?
> 
> Yes, etc-update shows it to your before asking what to do. Check the
> contents of each file before allowing it to be overwritten, and never,
> ever let etc-update overwrite etc/fstab, /etc/passwd or /etc/group.

  CONFIG_PROTECT and CONFIG_PROTECT_MASK work at the *DIRECTORY* level.
What I really want/need is a feature that allows additional protection
*FOR INDIVIDUAL FILES*.  E.g...

  - my customized /etc/conf.d/local.start or /etc/conf.d/local.stop
should *NEVER* be replaced with an empty version

  - /etc/rc.conf should be left alone too.  ***FOR THE UMPTEENTH TIME,
NO I DO NOT WANT NANO REPLACING VIM AS MY "EDITOR"***

  - /etc/conf.d/clock too.  ***FOR THE UMPTEENTH TIME, NO I DO NOT WANT
MY SYSTEM CLOCK SET TO GMT***

  - /etc/ssmtp/ssmtp.conf too.  ***FOR THE UMPTEENTH TIME, NO I DO NOT
WANT MY CUSTOMIZED FILE REPLACED WITH AN EXAMPLE FILE***

  And the list goes on and on.  Howsabout an environmental variable
CONFIG_PROTECT_FILES, containing a list of protected files?  I'm ready
to submit a feature request if necessary.  Does anybody have additional
comments?

-- 
Walter Dnes <[EMAIL PROTECTED]> In linux /sbin/init is Job #1
My musings on technology and security at http://techsec.blog.ca
-- 
gentoo-user@gentoo.org mailing list