Один компьютер администратора для систем с только обычной учетной записью в сети

Как у меня могут быть системы только с обычной учетной записью с административными задачами, управляемыми одним компьютером?

Я просто хочу иметь возможность добавлять / удалять программы на всех компьютерах из одной системы. Оптовая продажа - не индивидуальный вход в каждый компьютер и выполнение того, что нужно сделать. Я могу сделать это физически или по SSH, но с сотней или около того компьютеров это не совсем вариант, который я бы хотел рассмотреть.

7
задан 5 June 2015 в 23:24

5 ответов

Чтобы управлять несколькими машинами с центрального компьютера, вы можете попробовать изучить платформу управления системой, такую ​​как Puppet . Это позволяет вам управлять несколькими машинами (куклами) с одной главной машины (puppetmaster). В зависимости от вашего сценария это может быть немного излишним, но это отличный инструмент для управления многими машинами из центральной точки управления. Это также позволяет очень легко устанавливать новые машины (или переустанавливать старые), так как вы можете получить всю конфигурацию, списки пакетов и т. Д. С сервера.

Вот ссылка на руководство по установке для Ubuntu , чтобы установить & amp; тест кукловод.

0
ответ дан 5 June 2015 в 23:24

Скрыть администраторов

В каждой системе необходим по крайней мере один административный пользователь, поскольку в Ubuntu отключена отдельная корневая учетная запись * . Тем не менее, можно было бы скрыть этого пользователя «администратор» от входа в систему gdm, добавив следующую строку в /etc/gdm/custom.conf:

[greeter]
Exclude=nobody,administrator

Мы можем дополнительно ограничить доступ для чтения неадминистративных пользователей к /home/administrator/.

Для административных задач мы регистрируемся локально как пользователь администратор (например, в командной строке или выбрав others в GUI), или удаленно через ssh.

Определить ssh_config

Для выдачи команды нескольким удаленным машинам нам необходимо определить локальный файл конфигурации в ~/.ssh/ssh_config, где мы перечисляем детали, необходимые для входа на наши удаленные машины. и где мы можем определить удобные имена для клиентов:

# ssh configuration
Host remote1
    HostName 192.168.0.1
    Port 22
    User USERNAME

Host remote2
    HostName 192.168.0.2
    Port 22
    User USERNAME

Могут потребоваться дополнительные опции для дальнейшего контроля деталей сеанса (например, отключение аутентификации по паролю).

Выполнить команду на нескольких клиентах

Теперь мы напишем сценарий, который подключается к одному клиенту за другим для выполнения данной команды:

#!/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

Если этот сценарий был назван remote_command.sh мы можем выполнить любую команду на наших удаленных машинах 1-X, вызвав:

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

В зависимости от индивидуальных потребностей мы можем прочитать список для $ REMOTES из файла или использовать обычный шаблон для имен пультов для удобного использования скрипта. Если удаленные клиенты не меняются, мы также можем закодировать все имена в этом скрипте, чтобы вызывать его только с помощью команды.

* Повторное включение учетной записи root (путем определения действительного пароля для root с passwd root <password> в корневой оболочке) не рекомендуется , так как недостатки перевешивают.

0
ответ дан 5 June 2015 в 23:24

Если вы используете свой собственный локальный репозиторий (как я полагаю, если вы работаете в школе, чтобы сократить требования к пропускной способности), вы можете просто сделать дебат с зависимостями нужного программного обеспечения. Затем, всякий раз, когда вы обновляете deb, если есть задание cron для установки обновлений, которое запускается от имени пользователя root или что бы то ни было волшебным образом происходит. Вам не нужно большое количество прямого контроля на каждом ПК. Я бы сделал это с помощью манипуляций с пакетами. Вы можете даже запустить сценарии одноразового запуска таким образом, если в deb встроена «задача после установки».

0
ответ дан 5 June 2015 в 23:24

Я не знаю программного обеспечения интернет-кафе, которое сделало бы это, и я думаю, что что-то как Марионетка или Шеф-повар было бы излишеством. Можно создать очень простую установку на основе SSH, который работал бы.

Позволяет говорят, что у Вас есть 20 клиентов (10.0.0.101 к 10.0.0.120) и 1 станция управления (10.0.0.1).

Все следующие шаги могут быть проверены первоначально на 1 клиенте только для проверения вещей. Начальная настройка должна будет быть выполнена вручную на всех клиентах.

Шаг 1: Сделайте это более безопасным (Дополнительный?)

Заставьте брандмауэр управлять на всех клиентах, чтобы только принять новые соединения от 10.0.0.1

Возможно, можно открыть вопрос о пыльнике об этом. Я могу также предоставить некоторой справке iptables но у меня нет опыта с новыми правилами брандмауэра Ubuntu.

Шаг 2: Установите соединение

У Вас должен был бы быть сервис SSH, работающий на всех клиентах.

  1. Создайте отдельную некорневую учетную запись на станции станции управления.
  2. Выполненный ssh-keygen получить пару ключей SSH. Не обеспечивайте пароль.
  3. Создайте отдельную учетную запись на клиентах. Takkat упомянул, как исключить его из окна Gnome Login.
  4. Добавьте учетную запись к sudoers (например, с sudo visudo). Добавьте эту строку:

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

    NOPASSWD важен, потому что Вам будут нужны установки для выполнения, не прося у Вас пароль для каждого клиента.

Теперь можно протестировать. От Вашей выполненной станции управления:

ssh 10.0.0.101 sudo apt-get update

Шаг 3: Соединитесь со всеми параллельно

Теперь вот то, где мой вклад входит. Я использовал этот сценарий в течение приблизительно 3 лет и действительно доволен им. Это выполняет команду ssh параллельно ко многим узлам, печатающим вывод и/или ошибки приятно.

Необходимо было бы установить рубин на станции управления apt-get install ruby и помещенный все Ваши клиенты размещает в списке в/etc/managed-clients как это:

n01
n02
n03
n04

И также на станции управления добавляют к /etc/hosts:

10.0.0.101 n01
10.0.0.102 n02
10.0.0.103 n03
10.0.0.103 n04

Затем сохраните этот сценарий в /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

Код был рассмотрен для хорошего стиля кодирования и здесь существуют некоторые снимки экрана: https://codereview.stackexchange.com/questions/1180/ruby-script-on-all-nodes-run-for-teaching, но я никогда не заставлял время представлять эти предложения. Код работает хорошо, как.

Тест как это:

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

Шаг 4: программное обеспечение Установки параллельно

Теперь необходимо смочь установить и обновить программное обеспечение как это (извините, я только имею show пример со способностью, но должно быть возможно сделать то же с 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

Заключительное примечание

Если у Вас есть больше чем 10-20 клиентов затем в дополнение к сценарию выше Вас, должен найти способ повторно настроить жесткие диски с чем-то как Perceus. Тем путем можно сэкономить себе некоторое время (добавляющий новый клиент, и т.д....) и удостовериться, что все - то же через все клиенты. На практике я использую on-all-nodes-run 100 с времен в год. Я повторно отображаю с Perceus все клиенты несколько раз год.

3
ответ дан 5 June 2015 в 23:24

Это не совсем дешево и не с открытым исходным кодом, но, возможно, Canonical Landscape может помочь.

0
ответ дан 5 June 2015 в 23:24

Другие вопросы по тегам:

Похожие вопросы: