Hi all;
I've got a new dell laptop I'm trying to setup. Most everything is working
well but I cannot get dual monitor support working. There's a local Linux
install-fest this weekend near me and I plan to attend seeking some help.
However, I use this laptop as my main work computer and I cannot afford for it
to be down, so just in case something we do at install-fest breaks my system
(in fact I had early issue with the nvidia drivers causing me to only see a
blank screen) I want to be able to restore properly.
Here's what I've done so far:
I have a filesystem "/stage" where I'm staging an rsync backup.
I have a script that reads a list of directories and does an rsync. I've
listed all root level (/) directories in this list except for stage, dev and
sys since dev and sys are generated at boot time and stage is where I'm
pushing the backups to. So, my backup scripts look like this:
dirlist:
==========
bin
boot
docs
download
etc
home
lib
lib64
lost+found
media
mnt
opt
root
sbin
selinux
srv
tmp
usr
var
rsync_backup.sh:
==================
#!/bin/bash
for I in `cat dirlist`
do
echo "[$I]"
echo "=========="
rsync -avXA --delete /${I} /stage/backup/rsync
done
rsync_restore.sh:
==================
#!/bin/bash
for I in `cat dirlist`
do
echo "[$I]"
echo "=========="
rsync -avXA --delete /stage/backup/rsync/${I} /
done
Here's my questions. Is this going to be reliable , i.e. if I have to
restore will it accurately restore the entire system ?
When I run the backup script I see IO errors like this:
home/kkempter/.xsession-errors
IO error encountered -- skipping file deletion
rsync error: some files/attrs were not transferred (see previous errors) (code
23) at main.c(1040) [sender=3.0.4]
rsync error: some files/attrs were not transferred (see previous errors) (code
23) at main.c(1040) [sender=3.0.4]
I also see SE Linux warnings like this:
Summary
SELinux is preventing rsync from creating a file with a context of security_t
on a filesystem.
Detailed Description
SELinux is preventing rsync from creating a file with a context of security_t
on a filesystem.
Usually this happens when you ask the cp command to maintain the context of a
file when copying between
file systems, "cp -a" for example. Not all file contexts should be maintained
between the file systems.
For example, a read-only file type like iso9660_t should not be placed on a r/w
system. "cp -P" might be a better solution,
as this will adopt the default file context for the destination.
Allowing Access
Use a command like "cp -P" to preserve all permissions except SELinux context.
Additional Information
Source Context: system_u:object_r:security_t:s0
Target Context: system_u:object_r:fs_t:s0
Target Objects: .index.6k5mIl [ filesystem ]
Source: rsync
Source Path: /usr/bin/rsync
Port: <Unknown>
Host: Issac.consistentstate.com
Source RPM Packages: rsync-3.0.4-0.fc10
Target RPM Packages: Policy RPM: selinux-policy-3.5.13-38.fc10
Selinux Enabled: True
Policy Type: targeted
MLS Enabled: True
Enforcing Mode: Enforcing
Plugin Name: filesystem_associate
Host Name: Issac.consistentstate.com
Platform: Linux Issac.consistentstate.com 2.6.27.7-134.fc10.x86_64 #1 SMP Mon
Dec 1 22:21:35 EST 2008 x86_64 x86_64
Alert Count: 1
First Seen: Fri 23 Jan 2009 09:12:23 AM MST
Last Seen: Fri 23 Jan 2009 09:12:23 AM MST
Local ID: 77df5603-8c05-4884-ac35-19a5cab2070a
Line Numbers:
Raw Audit Messages :
node=Issac.consistentstate.com type=AVC msg=audit(1232727143.337:1347): avc:
denied { associate } for pid=8099 comm="rsync" name=".index.6k5mIl" dev=sdb1
ino=4825112 scontext=system_u:object_r:security_t:s0
tcontext=system_u:object_r:fs_t:s0 tclass=filesystem
node=Issac.consistentstate.com type=SYSCALL msg=audit(1232727143.337:1347):
arch=c000003e syscall=189 success=no exit=-13 a0=7fff5f0c8610 a1=17055e0
a2=17055c0 a3=20 items=0 ppid=8098 pid=8099 auid=500 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="rsync" exe="/usr/bin/rsync"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
Thoughts ?
Thanks in advance
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
