[Rear-users] SLES9: unpredictable behaviour is back

Schlomo Schapiro schlomo at schapiro.org
Fri Jan 30 07:33:03 CET 2009

Hi Werner,

indeed the question is, why does it not have a filename. Can you try to remove
the shopt line from the ssh script? This is basically already set globally. The
alternative is to actually search for the ssh config, copy it to /etc/ssh in the
rescue media and tell sshd which file to use. The hack was neccessary because
some Linux don't use the /etc/ssh subdir.

I'll answer your backup issues later...


Werner Flamme wrote:
> 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).
> ------------------------------------------------------------------------
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> ------------------------------------------------------------------------
> _______________________________________________
> Rear-users mailing list
> Rear-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rear-users

More information about the rear-users mailing list