[Rear-users] SLES9: unpredictable behaviour is back

Werner Flamme werner.flamme at ufz.de
Thu Jan 29 16:34:46 CET 2009


Schlomo Schapiro [29.01.2009 15:36]:
> Hi Werner,
> 
> the co[n]fig hack should work well with the shopt -s nullglob option. I
> can imagine that sed will hang if both file locations don't work. Can
> you please do an rear -D mkrescue and post the log file?

Hi Schlomo,

OK, the 50_* file is reset to its original content and rear -D did as
best as it could ;-). The output is attached (tar bz2).

The last line of output shows "sed -i ...", but no filename. So sed
hangs because of the missing file. But why...

It were easier to understand if it hangs on all 3 boxes, but so? Every
box has sshd running, and it sure has an /etc/ssh/sshd_config file.

> BTW, we are busy working on new releases, you can expect a new "Schlomo"
> release today with lots of cool new things. If you quickly send the the
> log I might be able to put a fix for your problem in as well.
> 
> What is the problem with ReaR/rbme ? You simply setup both to work with
> their respective defaults and use a manual rsync to push the backup data
> back to the ReaR rescue system. Or do you mean writing a script that
> will assist in the restore from RBME?

If it were that simple :-(

I have to back up to a remote host. This host runs a rsync daemon, but
not with root rights. When I rsync directly to this host (that is not
managed by me) and rsync it back, all files have the same owner, and
this id is unknown to my boxes (the rsync user's id on the backup
host)... So I use rbme to do its work, tar the result, and rsync this
fat file (about 15 GB per box and day, bzip2'ed) to the backup host. The
files containe a date stamp (like 20090128) in the file name. Besides, I
have a maximum of 10 files per host on the remote box, so I have to
delete an old file to get place for the new. This works so far...

Next, I have to test a script that does an automated restore out of the
archive. To have that, I first have to look for the most up to date file
on the backup host, rsync it back, and untar it (if this fails, take the
next archive on the backup host...). And hope that everything is at the
proper place ;-) - which may be influenced by using rbmes directory as
base of the tar...

Regards,
Werner

> 
> Werner Flamme wrote:
>> Hi,
>>
>> today I applied the last updates to my SLES9 boxes, the current rear
>> (1.7.6 / 2008-08-14) and was happy. I did a "rear mkrescue" on all three
>> boxes and was successful on two of them, the third was hanging. As usual
>> :-(, it was sed. And again, as I had reported one year ago, at
>> /usr/share/rear/build/default/50_patch_sshd_config.sh (I used rear -d
>> mkrescue then).
>>
>> On this one box, I had to change the simple code in a bulk on lines:
>>
>> ---snip---
>> shopt -s nullglob
>> if [ -f $ROOTFS_DIR/etc/sshd_config ]; then
>>     SSHDCONFIGFILE=$ROOTFS_DIR/etc/sshd_config
>> elif [ -f $ROOTFS_DIR/etc/ssh/sshd_config ]; then
>>     SSHDCONFIGFILE=$ROOTFS_DIR/etc/ssh/sshd_config
>> fi
>> if [ -n "$SSHDCONFIGFILE" ]; then
>>   sed -i  -e 's/PasswordAuthentication.*/PasswordAuthentication no/ig' \
>>  -e 's/ChallengeResponseAuthentication.*/ChallengeResponseAuthentication
>> no/ig' \
>>         -e 's/UsePAM.*/UsePam no/ig' \
>>         -e '1i PrintMotd no' \
>>             $SSHDCONFIGFILE
>> fi
>> ---pins---
>>
>> Sorry about the alignment, it's the mail client...
>>
>> So the sed command itself is untouched, except that I used a variable
>> for the name of the config file. The sed on all boxes tells me "GNU sed
>> version 4.0.9", so I don't see a reason for this behaviour. I worked
>> around the error, but I do not understand why...
>>
>> BTW, I still have not worked out a useable backup integration for my
>> ReaR images :-( I will do, and share my scripts then (will be rsync/rbme
>> and tar).
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rearlog.tb2
Type: application/octet-stream
Size: 24875 bytes
Desc: not available
Url : http://pikachu.3ti.be/pipermail/rear-users/attachments/20090129/a25e6280/attachment.obj 


More information about the rear-users mailing list