Re: [BackupPC-users] Testing full restore of backuppc... MULTIPLE BUGS???

2020-05-23 Thread backuppc
Thanks Craig.
The --specials now works (and I agree with both you and Michael that
it is not useful... but it validates that the restore is 'perfect' as
far as rsync is concerned)

Regarding selinux, you can turn it on in 'permissive' (non-enforcing)
mode in which case it shouldn't do anything other than create messages
of selinux policy violations... but it shouldn't block (or otherwise
affect any parts of your running system)

Check out the following for some details:
https://docs.fedoraproject.org/en-US/quick-docs/changing-selinux-states-and-modes/

Craig Barratt wrote at about 18:26:34 -0700 on Saturday, May 23, 2020:
 > While I agree with Michael that restoring sockets isn't that useful (since
 > they are only created by a process that is receiving connections on a
 > unix-domain socket), I did fix the bug
 > 
 > that causes them to be incorrectly restored by rsync_bpc.
 > 
 > I'm quite unfamiliar with selinux attributes.  Is it possible to add
 > selinux attributes to a file (with setfilecon) when selinux is disabled?
 > Unfortunately my attempt to turn selinux on didn't go well - my machine
 > didn't boot into a usable state, so I'm not willing to turn on selinux.
 > 
 > Craig
 > 
 > On Fri, May 22, 2020 at 8:26 PM Michael Stowe <
 > michael.st...@member.mensa.org> wrote:
 > 
 > > On 2020-05-22 16:49, backu...@kosowsky.org wrote:
 > > > Michael Stowe wrote at about 22:18:50 + on Friday, May 22, 2020:
 > > >  > On 2020-05-22 11:42, backu...@kosowsky.org wrote:
 > > >  > > 1. Sockets are restored as regular files not special files -->
 > > > BUG?
 > > >  >
 > > >  > Why would one back up a socket?
 > > > I am testing the fidelity of the backup/restore cycle..
 > > >>
 > > >  > If you really think this is sensible, you should be able to
 > > > accomplish
 > > >  > it with "--devices --specials" as part of your rsync command lines.
 > > >  >  From the symptoms, you have this in backup but not restore.
 > > >
 > > > Actually, in the original text (which you snipped), I shared my
 > > > rsync_bpc commands for both 'dump' and 'restore', which include the
 > > > '-D' flag (actually it's the default in the config.pl for both rsync
 > > > dump and restore)... and '-D' is *equivalent* to '--devices
 > > > --specials'
 > > >
 > > > And since I suspected some readers might miss that, I even noted in
 > > > the text that:
 > > >"Also, special files (--specials) should be included under the -D
 > > >flag that I use for both rsync dump and restore commands (see
 > > >below)"
 > > >
 > > > Hence, why I suggested this is a *BUG* vs. user error or lack of
 > > > knowledge :)
 > >
 > > You've mistaken my point -- sure, the -D flag is there, but it's
 > > behaving like it isn't.  Let's review:
 > >
 > > --devices
 > > This option causes rsync to transfer character and block  device
 > > files  to  the  remote  system  to recreate these devices.  This
 > > option has no effect if the receiving rsync is not  run  as  the
 > > super-user (see also the --super and --fake-super options).
 > >
 > > Naturally this begs the question as to whether you're running it as the
 > > super-user, and if you've seen the options as referred to in the man
 > > page, which I've quoted above.
 > >


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/


Re: [BackupPC-users] backuppc-fuse hard links

2020-05-23 Thread Craig Barratt via BackupPC-users
Jeff,

I remember looking into this long ago, and I recall that fuse makes up its
own fake inode numbers, which creates exactly the problem you noticed -
hardlinked files don't show the same inode number.  The Git issue you
mentioned reports that problem.

Craig

On Sat, May 23, 2020 at 8:52 PM  wrote:

> It seems like backuppc-fuse correctly lists the number of hard links
> for each file *but* the corresponding inodes are not numbered the
> same.
>
> For example:
>
> #Native file system
> ls -il /usr/bin/pigz /usr/bin/unpigz
> 564544 -rwxr-xr-x 2 root root 116944 Dec 27  2017 /usr/bin/pigz*
> 564544 -rwxr-xr-x 2 root root 116944 Dec 27  2017 /usr/bin/unpigz*
>
> #Backuppc-fuse version
> ls -il /mnt/backuppc/consult/root/{/usr/bin/pigz,/usr/bin/unpigz}
> 386328 -rwxr-xr-x 2 root root 116944 Dec 27  2017
> /mnt/backuppc/myhost/root/usr/bin/pigz*
> 827077 -rwxr-xr-x 2 root root 116944 Dec 27  2017
> /mnt/backuppc/myhost/root/usr/bin/unpigz*
>
> Is there any way to fix this???
>
> I couldn't find much on Google, but it seems like there is a low and a
> high level inode notion in fuse filesystems and that the low-level one
> has the right inode number. See:
> https://github.com/libfuse/libfuse/issues/79
>
>
> ___
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/


[BackupPC-users] backuppc-fuse hard links

2020-05-23 Thread backuppc
It seems like backuppc-fuse correctly lists the number of hard links
for each file *but* the corresponding inodes are not numbered the
same.

For example:

#Native file system
ls -il /usr/bin/pigz /usr/bin/unpigz
564544 -rwxr-xr-x 2 root root 116944 Dec 27  2017 /usr/bin/pigz*
564544 -rwxr-xr-x 2 root root 116944 Dec 27  2017 /usr/bin/unpigz*

#Backuppc-fuse version
ls -il /mnt/backuppc/consult/root/{/usr/bin/pigz,/usr/bin/unpigz}
386328 -rwxr-xr-x 2 root root 116944 Dec 27  2017 
/mnt/backuppc/myhost/root/usr/bin/pigz*
827077 -rwxr-xr-x 2 root root 116944 Dec 27  2017 
/mnt/backuppc/myhost/root/usr/bin/unpigz*

Is there any way to fix this???

I couldn't find much on Google, but it seems like there is a low and a
high level inode notion in fuse filesystems and that the low-level one
has the right inode number. See:
https://github.com/libfuse/libfuse/issues/79


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/


Re: [BackupPC-users] BUG? Using --omit-dir-times in rsync backup sets all dir dates to beginning of Epoch

2020-05-23 Thread Craig Barratt via BackupPC-users
I wasn't previously familiar with the --omit-dir-times option.  As you
discovered, the low-level parts of rsync_bpc don't 100% faithfully mimic
the native linux system calls.  In particular, the mkdir() in rsync_bpc
doesn't set the mtime, since rsync updates it later (assuming
--omit-dir-times is not specified).

It would be a one-line change to set the mtime to the current time in
bpc_mkdir() in bpc_sysCalls.c.  However, I don't think it makes sense to
"fix" it, since a backup shouldn't add metadata that changes each time you
backup some data that hasn't changed.

Craig

On Fri, May 22, 2020 at 8:17 PM Michael Stowe <
michael.st...@member.mensa.org> wrote:

> On 2020-05-22 16:52, backu...@kosowsky.org wrote:
> > Michael Stowe wrote at about 23:46:54 + on Friday, May 22, 2020:
> >  > On 2020-05-22 16:19, backu...@kosowsky.org wrote:
> >  > > Michael Stowe wrote at about 22:24:13 + on Friday, May 22,
> > 2020:
> >  > >  > On 2020-05-22 09:15, backu...@kosowsky.org wrote:
> >  > >  > What it does is omit directories from the modification times
> > that it
> >  > >  > sets.  In other words, you're telling it not to set the times
> > on
> >  > >  > directories it copies.  The beginning of the epoch is pretty
> >  > > reasonable
> >  > >  > for directories which have no specific time set.
> >  > >  >
> >  > >
> >  > > Actually, at least the manpage is unclear.
> >  > > And *differs* from the default behavior of native rsync (at lesat
> > on
> >  > > Ubuntu) that sets the dir time to the current time -- which is
> > more
> >  > > reasonable than some arbitrary epoch = 0 time.
> >  > >
> >  > > That is what I would have expected and I believe should be the
> > default
> >  > > behavior...
> >  > >
> >  > >  > This option has no implications for which directories are
> > selected
> >  > > to be
> >  > >  > copied.
> >  >
> >  > Unset is unset, it's not the option to use if you want the directory
> >  > modification time set.
> >
> > Regardless, behavior should be consistent with normal rsync...
> >
> > If you can show me a standard *nix version of rsync that uses Epoch as
> > the default then I would retract my point... but otherwise Epoch is
> > totally arbitrary and illogical... while at least the current time has
> > a good rationale... Choosing 1/1/1970 not so much...
>
> It's not that "epoch is the default" it's that that's what a timestamp
> of 0 is.  When you tell rsync not to set the timestamps, it doesn't.
>
> If you want to touch the directories and update their timestamps to the
> current time, you can do that, but it's an odd thing to expect rsync to
> take care of for you when you explicitly tell it not to.
>
>
> ___
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/


Re: [BackupPC-users] Testing full restore of backuppc... MULTIPLE BUGS???

2020-05-23 Thread backuppc
Michael Stowe wrote at about 03:25:45 + on Saturday, May 23, 2020:
 > On 2020-05-22 16:49, backu...@kosowsky.org wrote:
 > > Michael Stowe wrote at about 22:18:50 + on Friday, May 22, 2020:
 > >  > On 2020-05-22 11:42, backu...@kosowsky.org wrote:
 > >  > > 1. Sockets are restored as regular files not special files --> 
 > > BUG?
 > >  >
 > >  > Why would one back up a socket?
 > > I am testing the fidelity of the backup/restore cycle..
 > >> 
 > >  > If you really think this is sensible, you should be able to 
 > > accomplish
 > >  > it with "--devices --specials" as part of your rsync command lines.
 > >  >  From the symptoms, you have this in backup but not restore.
 > > 
 > > Actually, in the original text (which you snipped), I shared my
 > > rsync_bpc commands for both 'dump' and 'restore', which include the
 > > '-D' flag (actually it's the default in the config.pl for both rsync
 > > dump and restore)... and '-D' is *equivalent* to '--devices
 > > --specials'
 > > 
 > > And since I suspected some readers might miss that, I even noted in
 > > the text that:
 > >"Also, special files (--specials) should be included under the -D
 > >flag that I use for both rsync dump and restore commands (see
 > >below)"
 > > 
 > > Hence, why I suggested this is a *BUG* vs. user error or lack of
 > > knowledge :)
 > 
 > You've mistaken my point -- sure, the -D flag is there, but it's 
 > behaving like it isn't.  Let's review:
 > 

So we both agree it's a BUG... :)

I also tried just using --specials which also didn't work..
And '-D' *does* backup & restore devices... so seems like the issue is
that 'specials' are not being restored (but they are dumped
properly)... which is the BUG that I originally reported at the start
of the thread...

 > --devices
 > This option causes rsync to transfer character and block  device
 > files  to  the  remote  system  to recreate these devices.  This
 > option has no effect if the receiving rsync is not  run  as  the
 > super-user (see also the --super and --fake-super options).
 > 
 > Naturally this begs the question as to whether you're running it as the 
 > super-user, and if you've seen the options as referred to in the man 
 > page, which I've quoted above.

Again, referencing the  rsync_bpc command I shared (which you
clipped from the thread), you would see that I ran it as 'sudo' (plus
the default includes the options '--super' anyway)


___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/


Re: [BackupPC-users] Testing full restore of backuppc... MULTIPLE BUGS???

2020-05-23 Thread Craig Barratt via BackupPC-users
While I agree with Michael that restoring sockets isn't that useful (since
they are only created by a process that is receiving connections on a
unix-domain socket), I did fix the bug

that causes them to be incorrectly restored by rsync_bpc.

I'm quite unfamiliar with selinux attributes.  Is it possible to add
selinux attributes to a file (with setfilecon) when selinux is disabled?
Unfortunately my attempt to turn selinux on didn't go well - my machine
didn't boot into a usable state, so I'm not willing to turn on selinux.

Craig

On Fri, May 22, 2020 at 8:26 PM Michael Stowe <
michael.st...@member.mensa.org> wrote:

> On 2020-05-22 16:49, backu...@kosowsky.org wrote:
> > Michael Stowe wrote at about 22:18:50 + on Friday, May 22, 2020:
> >  > On 2020-05-22 11:42, backu...@kosowsky.org wrote:
> >  > > 1. Sockets are restored as regular files not special files -->
> > BUG?
> >  >
> >  > Why would one back up a socket?
> > I am testing the fidelity of the backup/restore cycle..
> >>
> >  > If you really think this is sensible, you should be able to
> > accomplish
> >  > it with "--devices --specials" as part of your rsync command lines.
> >  >  From the symptoms, you have this in backup but not restore.
> >
> > Actually, in the original text (which you snipped), I shared my
> > rsync_bpc commands for both 'dump' and 'restore', which include the
> > '-D' flag (actually it's the default in the config.pl for both rsync
> > dump and restore)... and '-D' is *equivalent* to '--devices
> > --specials'
> >
> > And since I suspected some readers might miss that, I even noted in
> > the text that:
> >"Also, special files (--specials) should be included under the -D
> >flag that I use for both rsync dump and restore commands (see
> >below)"
> >
> > Hence, why I suggested this is a *BUG* vs. user error or lack of
> > knowledge :)
>
> You've mistaken my point -- sure, the -D flag is there, but it's
> behaving like it isn't.  Let's review:
>
> --devices
> This option causes rsync to transfer character and block  device
> files  to  the  remote  system  to recreate these devices.  This
> option has no effect if the receiving rsync is not  run  as  the
> super-user (see also the --super and --fake-super options).
>
> Naturally this begs the question as to whether you're running it as the
> super-user, and if you've seen the options as referred to in the man
> page, which I've quoted above.
>
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/


Re: [BackupPC-users] how to install SCGI , exactly??

2020-05-23 Thread Craig Barratt via BackupPC-users
There are two different components that have to be installed, one for perl
(the client end) and another for apache (the server end).

The perl module SCGI needs to be installed, which can be done via cpan.  If
cpan doesn't work you can install it manually from the tarball, which can
be found in many places (eg, here

).

Second, apache needs the scgi module (typically called mod-scgi) installed
and enabled.  As Doug mentions that can be done using your favorite package
manager.

Craig

On Fri, May 22, 2020 at 10:39 AM Doug Lytle  wrote:

> >>> I am currently running BackupPC  version 4.3.2 on Ubuntu 18.04.4 LTS .
> >>> Everything seems to be working perfectly, except this pesky
> "2020-05-22 10:02:30 scgi : BackupPC_Admin_SCGI: can't load perl SCGI
> module - install via CPAN; exiting in 60 seconds" error
>
> Mike,
>
> The only thing I have on my backuppc server is the same as yours
>
> dpkg -l|grep -i scgi
>
> ii  libapache2-mod-scgi   1.13-1.1amd64
> Apache module implementing the SCGI protocol
>
>
> How are you trying to access the admin page?
>
> I don'g use sgi in my URL.  I use
>
> http://192.168.145.99/backuppc
>
> The description of the SGI admin is
>
> # BackupPC_Admin_SCGI: An SCGI implementation of the BackupPC
> #  admin interface.
>
> Which is something I don't use, just the CGI version.
>
> Doug
>
>
> ___
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/