#2125 PR `merged`: Fix #2120: avoid unwanted "Welcome to" messages in log file¶

Labels: enhancement, cleanup, fixed / solved / done, minor bug

OliverO2 opened issue at 2019-04-28 16:22:¶

Pull Request Details:¶

Type: Bug Fix
Impact: Low
Reference to related issue (URL): #2120
How was this pull request tested? Ran rear mkrescue on Ubuntu 18.04.2 LTS server before and after patching. Verifying log output changes as intended. Also tested a full restore successfully.
Brief description of the changes in this pull request:

This PR intends to fix #2120, avoiding unwanted "Welcome to" messages in the log file from rear mkrescue.

These invocations of bash --login in usr/share/rear/build/default/990_verify_rootfs.sh were affected as follows:

Motd message does not appear in log file, as output is filtered by grep. But if someone would change the welcome message text to something containing the phrase "not found", the grep expression would always match and subsequent code would behave erroneously. The fix prevents this.
Motd does appear in log file. Fix has been verified to suppress it.
Motd does appear in log file. Fix has been verified to suppress it.

Other invocations of bash --login across rear scripts are not affected in the same way: They do not chroot into the rescue system (chroot $ROOTFS_DIR), but into the recovered target system instead (chroot $TARGET_FS_ROOT). The target system has its own set of bash profile files, so it does not emit the ReaR welcome message. Examples tested:

usr/share/rear/finalize/Debian/i386/550_rebuild_initramfs.sh
usr/share/rear/finalize/Linux-i386/660_install_grub2.sh
usr/share/rear/restore/default/900_create_missing_directories.sh

schlomo commented at 2019-04-28 16:25:¶

Good catch, redirecting STDIN makes sure that the shell is non-interactive.

OliverO2 commented at 2019-04-28 16:48:¶

At least the redirection covers what usr/share/rear/skel/default/etc/bash.bashrc thinks about interactivity. Bash seems to have its own notion of it and the presence of the -c option already makes it consider itself non-interactive (i missing from $-).

gdha commented at 2019-04-29 08:04:¶

@jsmeix looks worth taking with the release 2.5, no?
@OliverO2 thanks for the cleanup of the code

jsmeix commented at 2019-04-29 08:22:¶

@OliverO2
as always many thanks for your thorough analysis of the issue
and for your fix!

Because you wrote (excerpts)

Motd message does not appear in log file,
as output is filtered by 'grep'
...
(chroot $TARGET_FS_ROOT). The target system
has its own set of bash profile files

I got a bit scared because this means there could be also any kind
of unexpected bash output in the target system chroot environment
(e.g. because of any etc/motd in the target system environment)
so that I checked right now our chroot ... /bin/bash --login calls as in
https://github.com/rear/rear/issues/2120#issuecomment-484159562
if there are some where stdout is used like

chroot ... /bin/bash --login ... | ...

Fortunately it seems there are none (except the single one that is
fixed by this pull request - the first one in the output below)

# find usr/share/rear/ -name '*.sh' | xargs grep -h -o 'chroot .* /bin/bash --login .*' | sort -u

chroot $ROOTFS_DIR /bin/bash --login -c "cd $( dirname $binary ) && ldd $binary" | grep -q 'not found' && broken_binaries="$broken_binaries $binary"

chroot $ROOTFS_DIR /bin/bash --login -c "type $program" || missing_programs="$missing_programs $program"

chroot $ROOTFS_DIR /bin/bash --login -c "type $required_program" || missing_required_programs="$missing_required_programs $required_program"

chroot $TARGET_FS_ROOT /bin/bash --login -c "chown $v $owner:$group $directory" 1>&2 ; then

chroot $TARGET_FS_ROOT /bin/bash --login -c "echo -e '$root_password\n$root_password' | passwd root"

chroot $TARGET_FS_ROOT /bin/bash --login -c "$grub_name-install $bootdisk" ; then

chroot $TARGET_FS_ROOT /bin/bash --login -c "$grub_name-install $grub2_install_device" ; then

chroot $TARGET_FS_ROOT /bin/bash --login -c "$grub_name-install $grub2_install_option $grub2_install_device" ; then

chroot $TARGET_FS_ROOT /bin/bash --login -c "$grub_name-install $grub2_install_option $part" ; then

chroot $TARGET_FS_ROOT /bin/bash --login -c "$grub_name-mkconfig -o /boot/$grub_name/grub.cfg" ; then

chroot $TARGET_FS_ROOT /bin/bash --login -c "$networking_preparation_command" || LogPrint "Command failed: $networking_preparation_command"

chroot $TARGET_FS_ROOT /bin/bash --login -c "$network_setup_command" || LogPrint "Command failed: $network_setup_command"

chroot $TARGET_FS_ROOT /bin/bash --login -c 'type -P mkinitrd'

chroot $TARGET_FS_ROOT /bin/bash --login -c 'type -P update-initramfs'

chroot $TARGET_FS_ROOT /bin/bash --login -c '/usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg'

chroot $TARGET_FS_ROOT /bin/bash --login -c "/usr/share/mdadm/mkconf >/etc/mdadm/mdadm.conf" ; then

chroot $TARGET_FS_ROOT /bin/bash --login -c "yes '' | TERM=dumb yast2 --ncurses lan add name=eth0 ethdevice=eth0 bootproto=dhcp" || true

jsmeix commented at 2019-04-29 08:37:¶

@schlomo @gdha
what do you think about redirecting the input to /dev/null for chroot calls
(provided input is not needed in each particular case)
to avoid such unwanted messages in any case for ReaR 2.6?
Cf.
https://github.com/rear/rear/issues/2120#issuecomment-485695688

OliverO2 commented at 2019-04-29 12:01:¶

I know I haven't been asked but let me drop some points to consider:

usr/share/rear/skel/default/etc/bash.bashrc checks via tty -s.
The 'canonical' way to check for an interactive shell is something like [[ $- == *i* ]] (Bash Reference Manual).
$- contains an i whenever there are commands to execute (either via -c or via at least one non-option argument), or if a -i option is present. -c is present in all bash --login invocations within ReaR, -i is not.
There are no guarantees regarding the actions being performed by the target system's profile files in general.
There are no guarantees regarding the actions being performed by the target system's profile files in case of an incomplete setup (e.g PATH not set up as expected).
Unless you are in control of each and every profile file involved, there might be unwanted side effects when invoking bash --login in the (partially set up) target environment. Maybe it is worth to look for a safer way to achieve things.

jsmeix commented at 2019-04-29 12:32:¶

@OliverO2
of course you are always welcome to contribute your thoughts!

I asked @schlomo and @gdha because I hope they may better
know about the history why certain things are as they are in ReaR
like why there is in usr/share/rear/skel/default/etc/bash.bashrc

# print motd for interactive shells
tty -s && test -s /etc/motd && cat /etc/motd

Regarding using $- to determine if we run interactively:
This should work at least down to SLES10-SP4
with GNU bash 3.1.17 where "man bash" reads

An interactive shell is one started without non-option arguments
and without the -c option whose standard input and error are both
connected to terminals (as determined by isatty(3)), or one started
with the -i option. PS1 is set and $- includes i if bash is interactive,
allowing a shell script or a startup file to test this state.

In general regarding chroot ... /bin/bash --login -c "command ..."
versus chroot ... /path/to/command ... see
https://github.com/rear/rear/issues/862
and therein in particular
https://github.com/rear/rear/issues/862#issuecomment-274068914
and subsequent comments therein and subsequent issues like
https://github.com/rear/rear/pull/1345#issuecomment-299798204

OliverO2 commented at 2019-04-29 12:39:¶

Regarding using $- to determine if we run interactively:
This should work at least down to SLES10-SP4
with GNU bash 3.1.17

I suppose you'd even find $- and the i option in the ancient bourne shell. If I remember correctly it's been there ever since. The only difference in detection is the pattern matching available in bash.

[Export of Github issue for rear/rear.]

#2125 PR merged: Fix #2120: avoid unwanted "Welcome to" messages in log file¶