I need help writing a bash script

[pauhn]

I have to add to specific users - john28 and joe54 to the group wheel. I then have to go into /etc/sudoers and make sure that requiretty is commented out (#). I have to do this to about 40 Red Hat servers, and a script would make the entire process a lot easier.

[Irithori]

Have a look at Puppet
It is worth the learning
Documentation | Puppet Labs - Type Reference

[drl]

Hi.

For a less capable utility (but also less complex than puppet from the looks of it), I use pdsh for some simple tasks that require remote access. It can use ssh.

Description: Efficient rsh-like utility, for using hosts in parallel
Pdsh is a high-performance, parallel remote shell utility, similar to dsh.
It has built-in, thread-safe clients for rsh. Pdsh uses a "sliding window"
parallel algorithm to conserve socket resources on the initiating node and
to allow progress to continue while timeouts occur on some connections.
.
It makes all parallel connections from one client machine, and attempts to
keep 32 (default, can be changed on command line) connections to remote
machines at any given time. It can run single commands or as an interactive
shell.
( from Debian apt-cache show pdsh)

It was in the repository for Debian (lenny, at least). More information at: https://computing.llnl.gov/linux/pdsh.html

At one company I worked at, the IT staff used cfengine to help maintain a few hundred Linux workstations, Precision in IT Infrastructure Engineering - CFEngine I thought it was very complicated, but perhaps that was because every now and then the display would roll and roll and roll when cfengine was working.

Good luck ... cheers, drl

[Irithori]

We used cfengine v2 before and the choice was either a complete rewrite of our .cf scripts to version 3 (as we were using some deprecated and say.. odd constructs)
or a complete rewrite to puppet.

The experience we made with the migration to puppet was, that the definitions are much shorter and easier to read now.
Also, it is no longer neccessary to copy the whole cfengine directory structure to each host. Which is a great gain, as some of the files do contain accounts, that are exclusive to a environment.

So it was impossible to share the same scripts with the developers and qa guys.
We can now with a combination of puppet, hiera, augeas, git and quite a lot of thought on how to define modules and classes.

But to be fair, we didnt give cfengine 3 the same effort.
It is for sure more than worth a look also.


There are also other system/config management tools, all require reading documentation, testing, reading again, etc.
But once one understands such a tool, it becomes easy to maintain hundreds/thousands of machines.

40 is already a number, that I wouldnt want to do maintencance without one.
In fact my few machines at home are puppet controlled, but ymmv.

[drl]

Hi.

Good comments. the OP should be able to find something among the suggestions ... cheers, drl

[pauhn]

I just need help writing a script... I'm confused what all of this talk about AIX is about.

[drl]

Hi.

I just need help writing a script... I'm confused what all of this talk about AIX is about.

I apparently missed that -- where was AIX mentioned here? Or did you mean at the LINL page? I think I mentioned that it was running on my Linux (Debian 5, "lenny").

Did you check your distribution repository? ... cheers, drl

[pauhn]

This puppet stuff: manages_aix_lam: The provider can manage AIX Loadable Authentication Module (LAM) system.

[Irithori]

That is a "provider", that deals with a AIX speciality.

For your usecase, a manifest like this would deal with the user creation part:


Arbitrary chosen filename: pauhn_users.pp

# pauhn_users.pp

user { 'john28':
  ensure  => 'present',
  comment => 'John 28',
  gid     => 'users',
  home    => '/home/john28',
  shell   => '/bin/bash',
  uid     => '1000',
  groups  => 'wheel',
  password => 'JOHN28_HASH',
  managehome => 'true',
}

user { 'joe54':
  ensure  => 'present',
  comment => 'Joe 54',
  gid     => 'users',
  home    => '/home/joe54',
  shell   => '/bin/bash',
  uid     => '1000',
  groups  => 'wheel',
  password => 'JOE54_HASH',
  managehome => 'true',
}

Note: tested with puppet 2.7.3.

You would apply that with

puppet apply -v pauhn_users.pp

Now, for actual deployment, you would need a
- puppet server
- a certain directory structure plus filenames (pauhn_users.pp would be init.pp in a "module" of your choice)
- puppet clients on your 40 machines
- some sort of revision control (svn, git)

Of course, the example manifest above can be (much) improved and abstracted.
I would recommend to try the tutorial. http://docs.puppetlabs.com/learning/
Maybe you like it and find it usefull for your scenario.


A simple approach for the sudoers task is to have the modified file available via a puppet URL, and to distribute it from there to all machines.
A slightly more interesting way is to modify the existing /etc/sudoers via the augeas tool, which can be used via puppet as well.