> On Sun, Apr 06, 2008 at 07:28:51AM -0400, Haines Brown wrote:
>> I'be brought up my backup script for discussion before, and folks where
>> helpful in solving a problem, but the solution created another. Now all
>> files backed up have their ownerships changed to me, brownh:brownh.
> I did:
> cpio --help
>
> and the only thing that stuck out was this option:
> --no-preserve-owner Do not change the ownership of the files
>
> so maybe add this and use:
> cpio -pdmuv --no-preserve-owner
I'll give that a try. The logic of the option escaped me. It says,
"leave [files] owned by the user extracting them. This is the default of
non-root users".
In the past, if I ran my backup script as root (sudo), I didn't have
ownership change, and when cron ran it there was no change either,
although I did have other problems, which is why I messed with the
script. It had been running for years without any problem, until I
upgraded to etch.
I assume the "user" here is cron, but then does not this option say
leave the files owned by cron? Made no sense to me. Didn't sound like it
was something I wanted to do.
--
Haines Brown, KB1GRM
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
04-06-2008, 03:00 PM
Haines Brown
backup script changes permissions
Osamu Aoki <osamu@debian.org> writes:
> On Sun, Apr 06, 2008 at 07:28:51AM -0400, Haines Brown wrote:
>> I'be brought up my backup script for discussion before, and folks where
>> helpful in solving a problem, but the solution created another.
>
> I did not read it...
In brief, I was directing stdout and stderr to: > 2>&1, and this by
default creates a message, and when the message size limit was reached,
it stopped the process.
What I have is a script in ~/scripts that is known to my private cron
db: ~/cron-brownh, which in turn is known to /etc/cron.weekly.
>> find / -print | egrep -v "^/media|^/proc|^/sys|^/mnt" | cpio -pdmuv
>> /media/mirror/"$dirName" > 2>&1 | cat -vt
>
> I do not understand first ">"
"First" >? Just one that I can see. Or do you mean in the first script?
My answer: I forget. In any case, it worked fine when run directly by
root (sudo).
>> Here's the new script which only sends an error message:
>>
>> find / -print | egrep -v "^/media|^/proc|^/sys" | cpio -pdmuv
>> /media/mirror/"$dirName" 2>&1 | cat -vT >/home/brownh/.backup.log
>>
>> However, it seems to convert ownership of all files backed up to
>> brownh:brownh.
>>From what account did you run this/
> * root from real root
> * root from sudo
> * account brownh
>
> If last, files are owned by brownh. That is how it sould be.
Well, I really don't know ;-(. I merged my private cron-brownh database,
and so it would be run by cron, which is owned by root. In my
~/cron-brownh (owned by brownh:brownh) is the line:
0 4 * * 0 /home/brownh/scripts/backup
--
Haines Brown, KB1GRM
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
04-06-2008, 03:07 PM
Haines Brown
backup script changes permissions
Noah Slater <nslater@bytesexual.org> writes:
> Why don't you use a prebuilt package such as backup2l?
Noah, I might just do that. I've spent a lot of time struggling with the
backup script, which only offered the advantage of having unarchived files,
but in recent years I've not found it as necessary to recover single
files as I used to, and doing so does not seem at all difficult with
backup2l. I'm giving it a look.
--
Haines Brown, KB1GRM
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
04-06-2008, 03:37 PM
"Owen Townend"
backup script changes permissions
On 07/04/2008, Haines Brown <brownh@hartford-hwp.com> wrote:
Noah Slater <nslater@bytesexual.org> writes:
> Why don't you use a prebuilt package such as backup2l?
Noah, I might just do that. I've spent a lot of time struggling with the
backup script, which only offered the advantage of having unarchived files,
but in recent years I've not found it as necessary to recover single
files as I used to, and doing so does not seem at all difficult with
backup2l. I'm giving it a look.
--
****** Haines Brown, KB1GRM
Hey,
**There*are*other*options*around*too*such*as*local rsync. Something like this should work similarly:
**rsync -avh --exclude=/media*--exclude=/proc --exclude=/sys*/ */media/mirror/${dirName}/ 2>&1 | cat -vT > /home/brownh/.backup.log
cheers,
Owen.
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
04-07-2008, 04:17 PM
Osamu Aoki
backup script changes permissions
On Sun, Apr 06, 2008 at 11:00:53AM -0400, Haines Brown wrote:
> Osamu Aoki <osamu@debian.org> writes:
>
> > On Sun, Apr 06, 2008 at 07:28:51AM -0400, Haines Brown wrote:
> >> I'be brought up my backup script for discussion before, and folks where
> >> helpful in solving a problem, but the solution created another.
> >
> > I did not read it...
>
> In brief, I was directing stdout and stderr to: > 2>&1, and this by
> default creates a message, and when the message size limit was reached,
> it stopped the process.
>
> What I have is a script in ~/scripts that is known to my private cron
> db: ~/cron-brownh, which in turn is known to /etc/cron.weekly.
>
> >> find / -print | egrep -v "^/media|^/proc|^/sys|^/mnt" | cpio -pdmuv
> >> /media/mirror/"$dirName" > 2>&1 | cat -vt
> >
> > I do not understand first ">"
>
> "First" >? Just one that I can see. Or do you mean in the first script?
> My answer: I forget. In any case, it worked fine when run directly by
> root (sudo).
Interesting and strange to me.
> >> Here's the new script which only sends an error message:
> >>
> >> find / -print | egrep -v "^/media|^/proc|^/sys" | cpio -pdmuv
> >> /media/mirror/"$dirName" 2>&1 | cat -vT >/home/brownh/.backup.log
> >>
> >> However, it seems to convert ownership of all files backed up to
> >> brownh:brownh.
> >>From what account did you run this/
>
> > * root from real root
> > * root from sudo
> > * account brownh
> >
> > If last, files are owned by brownh. That is how it sould be.
>
> Well, I really don't know ;-(. I merged my private cron-brownh database,
> and so it would be run by cron, which is owned by root. In my
> ~/cron-brownh (owned by brownh:brownh) is the line:
>
> 0 4 * * 0 /home/brownh/scripts/backup
So it is normal usser process by brownh. So change of owner is
expected.
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
04-07-2008, 04:22 PM
Osamu Aoki
backup script changes permissions
On Sun, Apr 06, 2008 at 10:42:19AM -0400, Haines Brown wrote:
> Kevin Mark <kevin.mark@verizon.net> writes:
>
> > On Sun, Apr 06, 2008 at 07:28:51AM -0400, Haines Brown wrote:
> >> I'be brought up my backup script for discussion before, and folks where
> >> helpful in solving a problem, but the solution created another. Now all
> >> files backed up have their ownerships changed to me, brownh:brownh.
>
> > I did:
> > cpio --help
> >
> > and the only thing that stuck out was this option:
> > --no-preserve-owner Do not change the ownership of the files
> >
> > so maybe add this and use:
> > cpio -pdmuv --no-preserve-owner
>
> I'll give that a try. The logic of the option escaped me. It says,
> "leave [files] owned by the user extracting them. This is the default of
> non-root users".
>
> In the past, if I ran my backup script as root (sudo), I didn't have
> ownership change, and when cron ran it there was no change either,
> although I did have other problems, which is why I messed with the
> script. It had been running for years without any problem, until I
> upgraded to etch.
>
> I assume the "user" here is cron, but then does not this option say
> leave the files owned by cron? Made no sense to me. Didn't sound like it
> was something I wanted to do.
cron can be either user as you mentioned or from root (/etc/rc2.d/S89cron).
anyway, you should run it under root to access all the files.
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org