• Category Archives AIX
  • IBM’s unix flavor AIX.

  • Unix » AIX
  • Finally, the time has come… CFEngine

    The amount of work that has not been automated bores me to death.

    Imagine changing your own user password every month (!) on x-hundredth hosts manually for different reasons.

    Of course, you can script it with an expect script and ssh-keys, but its still not ideal. What if your account is locked on one of them or the password changed manually at one time for a reason. then the expect script fails and the host in question is not completed.

    First up, to determine policies and to add Gentoo’s portage so Cfengine recognises it in package management. Nothing too elaborate, just a simple setup that works.

    package_changes               => "individual";
    package_list_command          => "/usr/bin/python -c 'import os; os.system(\"/bin/ls -d /var/db/pkg/*/* | cut -c 13-\")'";
    package_list_name_regex       => ".*/([^\s]+)-\d.*";
    package_list_version_regex    => ".*/[^\s]+-(\d.*)";
    package_installed_regex       => ".*";                  # all reported are installed
    package_name_convention       => "$(name)";
    #package_list_update_command    => "/bin/echo --sync";           
    package_list_update_command    => "/usr/bin/eix-sync";           
    package_list_update_ifelapsed     => "14400";                 
    
    
    package_add_command        => "/usr/bin/emerge -q --quiet-build";
    #package_add_command         => "/bin/echo Installing";
    package_delete_command      => "/usr/bin/emerge --depclean";
    package_update_command      =>  "/usr/bin/emerge --update";
    package_verify_command      => "/usr/bin/emerge -s";
    package_noverify_regex      => ".*(Not Installed|Applications found : 0).*";

    This causes portage to synchronise every 10 days and we use eix to speedup certain things.

    Next up, we will save this file but not yet activate it. First I used the default update_script that came with cfengine as a failsafe mechanism. Editted to suit my needs, I don’t need a

    /home/mark(etc)

    with access to localhost ;-). Although these are mark’s unix pages of course. still, as a humourous sidenote maybe. Nope, editted out this one. Next up, I changed the place where cfengine keeps its masterfiles, for security-through-obscurity reasons. Although not real security, if it throws off even 10% of scriptkiddies it means it was successful.

    When the client’s intranet is ready, I will move the cfengine off the public interface despite the fact the traffic never sees the full unprotected internet. Hackers can be even within one’s own ISP after all 🙂

    Finally, I will configure cfengine to run shell-scripts on every host when present in a directory on its master and move the shell-script to an archive-directory along with the output logfiles.

    My basic setup is now finished and onward to a more difficult setup.

     


  • SSH Ignore (un)known host keys

    Sometimes, you wish that SSH would just connect without asking questions. For instance if you are on a trusted net where you do not need to worry about man-in-the-middle attacks.

    You can realise that wish with the following settings.

    Onetime setting as commandline argument:

    $ ssh -o UserKnownHostsFile=/dev/null \
     -o StrictHostKeyChecking=no user@192.168.0.100
    Warning: Permanently added '192.168.0.100' (RSA) to the list of known hosts.
    user@192.168.0.100's password:

    Permanent in ssh users config ~/.ssh/config

    StrictHostKeyChecking=no
    UserKnownHostsFile=/dev/null

    Explanation:

    UserKnownHostsFile sets the location of known hosts. In this case, we use /dev/null to make sure there aren’t any existing hosts with offending host keys already present.

    StrictHostKeyChecking=no means that ssh will automaticly add the key to the database (/dev/null) without asking for user confirmation.

    These 2 steps together mean that ssh will totally ignore any known or unknown host key and just login without silly questions.