Baby steps towards surviving overly helpful helper scripts - Mandriva

This is a discussion on Baby steps towards surviving overly helpful helper scripts - Mandriva ; There have been an increasing number of overly helpful helper scripts in Mandriva of late. You know, the kind that erase the configurations you want and replace them with something else that doesn't work, because it "knows better". This has ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Baby steps towards surviving overly helpful helper scripts

  1. Baby steps towards surviving overly helpful helper scripts

    There have been an increasing number of overly helpful helper scripts in
    Mandriva of late. You know, the kind that erase the configurations
    you want and replace them with something else that doesn't work, because
    it "knows better". This has bitten me so many times lately that on my
    systems I've now set up under /root a "my_config" directory. It
    contains the following:

    etc a mostly complete copy of /etc. After copying, these
    subdirectories were deleted (for size reasons)
    etc/gconf
    etc/pki
    etc/alterantives
    Also removed are any relative links which were originally
    to files outside of the /etc directory tree.
    Also removed were these three files which change at least
    at every reboot (or more often):
    etc/adjtime
    etc/ntp/drift
    etc/sysconfig/harddrake2/previous_hw
    What's left comes to a bit over 10 Mb.
    usr the 4 or 5 files I've modified in /usr, such as
    /usr/bin/rxvt.sh. This directory has negligible size.
    root A few files from /root such as .bashrc. This directory has
    negligible size.
    findchanges.sh
    a script for finding changes between these backup copies
    and the active ones. Use it initially to find and remove the
    troublesome links described in "etc" above. See below for
    the script. It runs in a second or two on my system.
    find_owner_prot_change.sh
    Looks for ownership and file protection changes, but only in etc.
    rpm_order.txt
    The output of: rpm -qa --last
    setupnode.sh
    Commands used in setting up a machine after cloning. This
    is very site specfic so I won't provide mine, but
    it MUST contain:
    rm -f /etc/iftab
    rm -f /etc/udev/rules.d/61-net_config.rules
    to get rid of the places where Mandriva now associates a MAC with
    eth0 and/or eth1. Also if static addresses and/or names are
    used /etc/sysconfig/network-scripts/ifcfg-eth0 and
    /etc/sysconfig/network need to be rewritten, as well as
    their copies in /root/my_config/etc. Finally the network,
    iptables, and shorewall need to be restarted to pick up the
    changes.


    Here are findchanges.sh and find_owner_prot_changes.sh:

    cat >findchanges.sh < #!/bin/sh
    cd /root/my_config
    echo "looking for changes in etc"
    diff -r etc /etc | grep -v 'Only in /etc'
    echo "looking for changes in usr"
    diff -r usr /usr | grep -v 'Only in /usr'
    echo "looking for changes in root"
    diff -r root /root | grep -v 'Only in /root'
    echo "DONE"
    EOD
    cat >find_owner_prot_changes.sh < #!/bin/sh
    echo "looking for ownership and protection changes in etc"
    (cd /etc ; tar cf - .) | (cd /root/my_config/etc; tar -df - . ) 2>&1 \
    | grep -v 'Cannot readlink' \
    | grep -v 'Cannot stat' \
    | grep -v 'Mod time'
    echo "DONE"
    EOD
    chmod 755 findchanges.sh find_owner_prot_changes.sh

    Now when something hits the fan I can do:

    ./findchanges.sh

    and it will spot all of the changed config files. If for some reason I
    want to check ownership or protection changes (could be a problem, but
    I've not seen this yet) also do this:

    ./find_owner_prot_changes.sh

    To see which rpm packages might be involved there is also this:

    rpm -qa --last > new_rpm_order.txt
    diff new_rpm_order.txt rpm_order.txt

    I'm pretty sure that as time goes on I'm going to see files being
    modified in /etc for no reason whatsoever, and these may have to
    be removed from /root/my_config/etc to avoid false negatives in the
    findchanges.sh runs.

    As advertised, these are just baby steps. Even so, it should
    make finding changed config files much easier.
    Plus it can be used preemptively - look for changes and see if
    they matter, rather than finding something broken and (trying)
    to work backwards to the affected config file.

    Regards,

    David Mathog





  2. Re: Baby steps towards surviving overly helpful helper scripts

    David Mathog wrote:

    > Also removed were these three files which change at least
    > at every reboot (or more often):
    > etc/adjtime
    > etc/ntp/drift
    > etc/sysconfig/harddrake2/previous_hw


    Here's another one I just found, also take out

    etc/asound.state

    It is different on the two systems even though one is a clone of the
    other and the hardware is identical. On a system where the sound was
    used it would presumably change frequently.

    Regards,

    David Mathog

  3. Re: Baby steps towards surviving overly helpful helper scripts

    On Mon, 25 Jun 2007 12:53:16 -0700, David Mathog wrote:
    > There have been an increasing number of overly helpful helper scripts in
    > Mandriva of late.


    Yes, and I have thinking about something like
    http://sourceforge.net/projects/aide
    or http://la-samhna.de/samhain/s_documentation.html

    The jre plugin package slipped in a /etc/init.d/jexec service/deamon.
    Tried using MCC and chkconfig to disable it. Did not stop it, so I put an
    exit 0
    below the header.

    Looking at
    http://computerworld.co.nz/news.nsf/...257302000B0EE8
    suggest I'll need the IDS package anyway when the US banks decide the
    "code" is a good thing for their customers.

  4. Re: Baby steps towards surviving overly helpful helper scripts

    Bit Twister wrote:
    > On Mon, 25 Jun 2007 12:53:16 -0700, David Mathog wrote:
    >> There have been an increasing number of overly helpful helper scripts in
    >> Mandriva of late.

    >
    > Yes, and I have thinking about something like
    > http://sourceforge.net/projects/aide


    That's like tripwire, right? I thought about using tripwire but the
    problem was it was designed to detect changes but not to repair them -
    the database contained only checksums. Here I not only want to find
    out when a file has changed but be able to restore it easily.

    > The jre plugin package slipped in a /etc/init.d/jexec service/deamon.
    > Tried using MCC and chkconfig to disable it. Did not stop it, so I put an
    > exit 0
    > below the header.


    Which rpm was that, specifically? The java pieces here have names like
    java-1.6.0-sun*1.6.0.0-6mdv2007.1. They didn't put anything in
    /etc/rc.d/init.d.

    Regards,

    David Mathog


  5. Re: Baby steps towards surviving overly helpful helper scripts

    On Mon, 25 Jun 2007 13:23:56 -0700, David Mathog wrote:
    > Bit Twister wrote:
    >
    >> The jre plugin package slipped in a /etc/init.d/jexec service/deamon.
    >> Tried using MCC and chkconfig to disable it. Did not stop it, so I put an
    >> exit 0
    >> below the header.

    >
    > Which rpm was that, specifically?


    #************** Start jre-6u1-linux-i586_install.txt **************
    #*
    #* Download jre from http://java.sun.com/javase/downloads/index.jsp
    #*
    #*
    #* The following assums you have setup global environment for Firefox
    #* If not, you place the link in the Firefox plugins directory.
    #*
    #* Example snippet from my /local/bin/xx_local.sh. Permissions:
    #* -rwxr-xr-x 1 root root 2964 Feb 25 17:23 /local/bin/xx_local.sh
    #*
    #* xx_local.sh has a link to from /etc/profile.d
    #*
    #* #********************************************
    #* # set global firefox/mozilla plugin directory
    #* #********************************************
    #*
    #* export MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
    #* if [ "$HOME" ]; then
    #* export MOZ_PLUGIN_PATH=$MOZ_PLUGIN_PATH:$HOME/.mozilla/plugins
    #* fi
    #*
    #*
    #* Note: /accounts/downloads is my browser download directory and
    #* assumes MOZ_PLUGIN_PATH contains /usr/lib/mozilla/plugins
    #*
    #************************************************* ***************

    cd /accounts/downloads

    chmod +x jre-6u1-linux-i586-rpm.bin
    ../jre-6u1-linux-i586-rpm.bin
    yes

    or if already executed the bin

    urpmi /accounts/downloads/jre-6u1-linux-i586.rpm
    cd /usr/lib/mozilla/plugins
    /bin/rm -f libjavaplugin_oji.so

    ln -s /usr/java/jre1.6.0_01/plugin/i386/ns7/libjavaplugin_oji.so
    ls -al

    #******************************************
    #* disable the new java system service/deamon
    #*******************************************

    service jexec stop
    chkconfig --del jexec
    chkconfig jexec off

    edt /etc/init.d/jexec
    and add
    exit 0
    under the header comment block.
    Click Save/quit

    #******************************************
    #* jre/java test links
    #******************************************

    firefox http://java.com/en/download/installed.jsp
    and verify version number displayed on screen

    firefox http://www.bodo.com/javame.htm

    #************** End jre-6u1-linux-i586_install.txt *********************


    > The java pieces here have names like
    > java-1.6.0-sun*1.6.0.0-6mdv2007.1. They didn't put anything in
    > /etc/rc.d/init.d.


    Heheheh, I think that java-1.6.0-sun*1.6.0.0-6mdv2007.1 was the one
    which changed my latest/greasted jre plugin link to use
    /etc/alternatives and when I went to
    http://java.com/en/download/installed.jsp it indicated an old release.


  6. Re: Baby steps towards surviving overly helpful helper scripts

    Bit Twister wrote:
    >> The java pieces here have names like
    >> java-1.6.0-sun*1.6.0.0-6mdv2007.1. They didn't put anything in
    >> /etc/rc.d/init.d.

    >
    > Heheheh, I think that java-1.6.0-sun*1.6.0.0-6mdv2007.1 was the one
    > which changed my latest/greasted jre plugin link to use
    > /etc/alternatives and when I went to
    > http://java.com/en/download/installed.jsp it indicated an old release.


    I don't know about that, but it (or something like it) did leave a lot
    of java related links in /etc/alternatives: like

    lrwxrwxrwx 1 root root 36 Jun 15 04:21 /etc/alternatives/orbd ->
    /usr/lib/jvm/java-1.6.0-sun/bin/orbd*

    where, unfortunately, the actual path is:

    /usr/lib/jvm/java-1.6.0-sun-1.6.0.0/jre/bin/orbd*

    I worked around that by

    cd /usr/lib/jvm
    ln -s java-1.6.0-sun-1.6.0.0/jre java-1.6.0-sun

    Regards,

    David Mathog

+ Reply to Thread