7

How can I have systems with only a regular account with administrative tasks managed by a single computer?

I simply want be able to add/remove software on all computers from a single system. Wholesale - not individually logging into each computer and doing what needs to be done. I can do that physically or by SSH, but with a hundred or so computers, that's not really an option I would like to consider.

6
  • 1
    It's a bit unclear. Are you trying to run administrative tasks remotely? What is an example of your network? May 10, 2011 at 18:34
  • @Aleksandr, Local network. Other than the administrator computer, the rest should only have a regular user account (no sudo/root privileges).
    – Oxwivi
    May 11, 2011 at 9:55
  • Like others have said, please update your question with a more specific description of what you need. Your question is unclear and it is difficult for us to answer it. May 13, 2011 at 19:15
  • I am currently evaluating Mkahawa Cyber Manager, for Ubuntu 11.10. mkahawa.sourceforge.net It looks quite good, although I am also looking for additional features not yet present.
    – david6
    Nov 23, 2011 at 6:03
  • I am also working on a product proposal for remote-access management. I would be very interested in your (more detailed) requirements ..
    – david6
    Nov 23, 2011 at 6:05

5 Answers 5

11
+100

To manage multiple machines from a central computer, you could try learning a system management platform such as Puppet. It allows you to manage multiple machines (puppets) from one main machine (puppetmaster). Depending on your scenario it might be a bit overkill, but it is an excellent tool to manage many machines from a central point of control. It also makes it very easy to set up new machines (or re-install the old ones), as you can pull all configuration, package lists etc from the server.

Here is a link to a ubuntu how-to guide to install & test puppetmaster.

6
  • Can you share desktops with it? I need to use this for very specific tasks, may I ask you how to achieve them?
    – Oxwivi
    May 13, 2011 at 10:30
  • 1
    What do you mean by sharing desktops? You should probably update the question with a more thorough explanation of what you seek.
    – Egil
    May 13, 2011 at 10:36
  • Sharing desktops as in seeing and controlling another computer's desktop, and I've asked another question about it. Anyway, the specific tasks I mentioned takes precedence.
    – Oxwivi
    May 13, 2011 at 10:57
  • You could enable desktop sharing similar to what was done at askubuntu.com/questions/41537/… ,but I would suggest requiring a password. Just remember to block it from outside access if you are not behind nat.
    – Egil
    May 13, 2011 at 16:43
  • Never mind desktop sharing, how do I set up Puppet server? How exactly do I define server and client addresses?
    – Oxwivi
    May 13, 2011 at 16:49
5

Hide administrators

At least one administrative user is needed on each system because in Ubuntu a distinct root account is disabled*. Nevertheless it would be possible to hide this user "administrator" from gdm login by adding the following line in /etc/gdm/custom.conf:

[greeter]
Exclude=nobody,administrator

We may further restrict read access of non-administrative users to /home/administrator/.

For administrative tasks we login locally as user administrator (e.g. on the command line or by choosing others in the GUI), or remotely via ssh.

Define ssh_config

For issuing a command to a multiple remote machines we need to define a local config file in ~/.ssh/ssh_config where we list details needed to log in to our remote machines and where we can define convenient names for the clients:

# ssh configuration
Host remote1
    HostName 192.168.0.1
    Port 22
    User USERNAME

Host remote2
    HostName 192.168.0.2
    Port 22
    User USERNAME

Additional options may be needed to further control session details (such as disabling password authentication).

Run command on multiple clients

We now write a script that connects to one client after the other to run a given command:

#!/bin/bash

# run a command on multiple remotes   

REMOTES=$1;shift
COMMAND=$1;shift

for remote in $REMOTES
do
    echo $remote
    ssh -oConnectTimeout=10 $remote $COMMAND
done

If this script was named remote_command.sh we are able to run any command on our remote machines 1-X by invoking:

remote_command "remote1 remote2 ... remote<X>" "<COMMAND>" > remote_command.log

Depending on individual needs we could read a list for $REMOTES from a file or we could use a regular pattern for names of the remotes for convenient script usage. If remote clients do not change we could also code all names in this script to invoke it with the command only.

*Re-enabling the root account (by defining a valid password for root with passwd root <password> in a root shell) is discouraged as disadvantages overweigh.

2
  • Don't you mean /home/users/? For SSH is there anything to set up in the user computers I've described? And how can I send commands to multiple computers in bulk?
    – Oxwivi
    May 11, 2011 at 3:48
  • You will have e.g. /home/jack/, and /home/oxwivi/ on your boxes. Jack may (or may not!) need further restritions for acccess to /home/oxvivi. Other than running a startup script or cronjob to access an administrative task script that would be hosted on your admin server I have no idea how to send ssh commands to multiple boxes (for ssh you need to log in remotely). I'm not much of a networker, there may well be a more elegant solution. New Q if this has not been asked before?
    – Takkat
    May 11, 2011 at 6:30
3

It's not exactly cheap, nor open source, but maybe Canonical's Landscape can help.

1
  • I know about it, but I can't really recommend it to a school who's been using pirated Windows... (LoCo activity)
    – Oxwivi
    May 13, 2011 at 10:01
3

If you're using your own local repo (like I think you should if your working at a school to cut bandwidth requirements), you could just make a deb with dependencies of the software you want. Then whenever you update the deb, if there's an install updates cron job that runs as root or whatever it magically happens. You don't need a large amount of direct control at each PC. I would do it with package manipulation. You can even push one-time run scripts this way if the have a "post-install task" built into the deb.

3

I don't know any internet-cafe software that would do this and I think something like Puppet or Chef would be an overkill. You can build a very simple setup based on SSH that would work.

Lets say you have 20 clients (10.0.0.101 to 10.0.0.120) and 1 management station (10.0.0.1).

All of the following steps can be tested out initially on 1 client only to test things out. The initial setup will need to be performed manually on all the clients.

Step 1: Make it more secure (Optional?)

Make a firewall rule on all of the clients to only accept new connections from 10.0.0.1

Maybe you can open anther question about this. I can also provide some help with the iptables but I don't have experience with the new Ubuntu firewall rules.

Step 2: Establish a connection

You would need to have SSH service running on all the clients.

  1. Create a separate non-root account on the management station station.
  2. Run ssh-keygen to get an SSH key-pair. Don't provide any password.
  3. Create a separate account on the clients. Takkat mentioned how to exclude it from the Gnome Login window.
  4. Add the account to sudoers (e.g. with sudo visudo). Add this line:

    aptaccount1 ALL=(silktree) NOPASSWD: /usr/bin/apt-get

    NOPASSWD is important because you will need the installations to run without asking you for a password for every client.

Now you can test. From your management workstation run:

ssh 10.0.0.101 sudo apt-get update

Step 3: Connect to all in parallel

Now here is where my contribution comes in. I used this script for about 3 years and am really happy with it. It runs an ssh command in parallel to many nodes printing the output and/or errors nicely.

You would need to install ruby on the management station apt-get install ruby and put all your clients hosts in a list into /etc/managed-clients like this:

n01
n02
n03
n04

And also on the management station add to /etc/hosts:

10.0.0.101 n01
10.0.0.102 n02
10.0.0.103 n03
10.0.0.103 n04

Then save this script into /usr/local/bin/on-all-nodes-run

#!/usr/bin/ruby

CLIENTS_FILE =  "/etc/managed-clients"

require "open3"

# Non-interactive, no password asking, and seasonable timeouts
SSH_OPTIONS = ["-o PreferredAuthentications=publickey,hostbased,gssapi,gssapi-with-mic",
               "-o ForwardX11=no",
               "-o BatchMode=yes",
               "-o SetupTimeOut=5",
               "-o ServerAliveInterval=5",
               "-o ServerAliveCountMax=2"
              ].join(" ")

SSH    = "/usr/bin/ssh #{SSH_OPTIONS}"
MKDIR  = "/bin/mkdir"

raise "Pleae give this command at least one argument" if ARGV.size < 1
COMMAND = ARGV[0..-1].join(' ')

output_o = {}
output_e = {}


IO_CONNECTIONS_TO_REMOTE_PROCESSES = {}

def on_all_nodes(&block)
  nodes = []
  File.open(CLIENTS_FILE) do |f|
    while line = f.gets
      i = line.split(' ').first
      nodes.push(i)
    end
  end
  nodes.sort.each {|n| block.call(n)}
end


# Create processes
on_all_nodes do |node|
  stdin, stdout, stderr = Open3.popen3("#{SSH} #{node} \"#{COMMAND}\"")
  IO_CONNECTIONS_TO_REMOTE_PROCESSES[node] = [stdin, stdout, stderr]
end


has_remote_errors = false

# Collect results
on_all_nodes do |node|
  stdin, stdout, stderr = IO_CONNECTIONS_TO_REMOTE_PROCESSES[node]

  stdin.close

  e_thread = Thread.new do
    while line = stderr.gets
      line.chomp!
      STDERR.puts "#{node} ERROR: #{line}"
      has_remote_errors = true
    end
  end

  o_thread = Thread.new do
    while line = stdout.gets
      line.chomp!
      puts "#{node}      : #{line}"
    end
  end

  # Let the threads finish
  t1 = nil
  t2 = nil
  while [t1, t2].include? nil
    if t1.nil?
      t1 = e_thread.join(0.1) # Gives 1/10 of a second to STDERR
    end
    if t2.nil?
      t2 = o_thread.join(0.1) # Give 1/10 of a second to STDOUT
    end
  end

end


exit(1) if has_remote_errors

The code has been reviewed for good coding style and there are some screenshots here: https://codereview.stackexchange.com/questions/1180/ruby-script-on-all-nodes-run-for-teaching but I never got time to introduce these suggestions. The code works well as is.

Test like this:

on-all-nodes-run echo hi
n01      : hi
n02      : hi
n03 ERROR: Timeout, server not responding.
n04      : hi

Step 4: Install software in parallel

Now you should be able to install and upgrade software like this (sorry, I only have the show example with aptitude but it should be possible to do the same with apt-get):

on-all-nodes-run sudo aptitude show pbzip2 \| grep State
n01      : State: not installed
n02      : State: not installed
n03 ERROR: Timeout, server not responding.
n04      : State: not installed

on-all-nodes-run echo "Yes" \| sudo apt-get install pbzip2
...

on-all-nodes-run sudo aptitude show pbzip2 \| grep State
n01      : State: installed
n02      : State: installed
n03 ERROR: Timeout, server not responding.
n04      : State: installed

Final note

If you have more than 10-20 clients then in addition to the script above you should find a way to re-provision the hard-drives with something like Perceus. That way you can save yourself some time (adding new client, etc...) and ensure that everything is the same across all the clients. In practice I use on-all-nodes-run 100s of times per year. I re-image with Perceus all the clients a few times a year.

3
  • 1
    Instead of echo "Yes" \| sudo apt-get install pbzip2, use sudo apt-get -y install pbzip2. Otherwise, you could be answering "Yes" to a question like "do you want me to break your system?" ;)
    – Lekensteyn
    May 18, 2011 at 18:56
  • @Lekensteyn +1 good point. I also recommend ssh'ing into one of the clients and going through one install manually so you know what answers you want. And only then run the whole thing on all the clients. In practice it's not a very big deal though. May 18, 2011 at 19:02
  • Why would puppet, chef etc be overkill? They might involve a learning curve to set up, but they provide much more than just running a command across multiple machines. How would your script handle the task of configuring a fresh install etc?
    – Egil
    May 19, 2011 at 9:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .