Препятствуйте тому, чтобы второй экземпляр моего программного обеспечения запустился

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

Но я бы предположил, что это далеко от совершенства, и его можно относительно легко обойти.

Это должно работать для сценария bash. Он прервет выполнение сценария, если будет найден другой экземпляр внешнего программного обеспечения. Ключевым моментом здесь является `pidof.

#!/bin/bash

# Abort startup if another instance was found    
pidof /path/to/software.executable > /dev/null && {
  echo Sorry. Only one instance allowed.
  exit
}

В качестве альтернативы вы можете использовать файлы блокировки, заменить запущенный экземпляр (т.е. сначала убить запущенный экземпляр, а затем разрешить запуск).

Однако опытный пользователь может обойти этот сценарий и напрямую вызвать внешнюю команду.

На самом деле, разумный способ - это запретить пользователю доступ, используя правильные разрешения, и разрешить только пользователям root(esque) запускать программу.

Существует очень мало файлов, которые должны быть абсолютно разными между двумя машинами и должны быть восстановлены при клонировании :

• Имя хоста /etc/hostname .
• Ключи хоста SSH: /etc/ssh _ host _ * _ key * или /etc/ssh/ssh _ host _ * _ key * или аналогичное местоположение.
• Случайное начальное число /var/lib/urandom/random-seed или /var/lib/random-seed или аналогичное местоположение. (/var/lib/systemd/random-seed в системах, использующих systemd)

Все остальное может быть идентичным, если у вас есть куча одинаковых машин.

Несколько файлов обычно различаются на машинах с различным оборудованием:

• /etc/fstab , /etc/crypttab , /etc/mdadm.conf и файлы конфигурации загрузчика (если они расположены в /etc - некоторые дистрибутивы помещают их в /boot ), если диски разделены по-разному.
• /etc/X11/xorg.conf , при наличии на компьютерах различных графических плат.
• Модули для загрузки или черный список в /etc/modules , /etc/modprobe.conf , /etc/modprobe.d/ и /etc/modutils/.

Кроме того, может потребоваться изменение конфигурации сети, в частности:

• Если у вас есть статические IP-адреса, их необходимо разнообразить для каждой машины. Расположение IP-конфигурации варьируется между дистрибутивами (например, /etc/network/interfaces на Debian, /etc/sysconfig/network на Red Hat).
• /etc/hosts часто содержит имя хоста.
• Конфигурация почты часто содержит имя хоста: проверьте /etc/mailname .

Нет общего ответа на вопрос «какие файлы в папке /etc уникальны для каждого компьютера», поскольку вся цель /etc заключается в хранении файлов, которые можно настроить на каждом компьютере. Например, если у вас есть разные учетные записи на разных машинах, то, очевидно, вы не можете совместно использовать базу данных учетных записей - и если вы хотите иметь возможность совместно использовать базу данных учетных записей, то в конечном итоге вы получите одни и те же учетные записи.

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

Если у вас есть компьютеры с различными конфигурациями, укажите в белом списке то, что вы синхронизируете. Рассматривайте файлы в /etc как отдельные на различных машинах, например, файлы в /var . Синхронизируйте только те, которые вы решили применять везде.

Одним из возможных способов управления синхронизацией является сохранение файлов, специфичных для машины, в другом каталоге, например, /local/etc , и создание символических ссылок, таких как /etc/fstab - > ../local/etc/fstab .Это по-прежнему требует в значительной степени однородного набора машин с точки зрения программного обеспечения, поскольку различные дистрибутивы размещают файлы в разных местоположениях. Или, наоборот, хранить только файлы, специфичные для машины, в /etc и все общие файлы в другом месте - но типичные дистрибутивы не подходят для этого.

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

С традиционными почтовыми клиентами unix /var/spool/mail/$ USER является почтовым ящиком пользователя. Электронные письма остаются там до тех пор, пока пользователь решает не архивировать почту. Некоторые почтовые клиенты настаивают на перемещении сообщений электронной почты в запатентованный файл или предлагают возможность перемещения сообщений электронной почты в другой файл после чтения. Пользователи могут выбирать, какой почтовый клиент они используют и как они его настраивают.

При запуске агента доставки почты (MDA), такого как procmail , его можно настроить для доставки некоторых сообщений электронной почты в почтовый ящик системы или для доставки всех сообщений электронной почты в файлы из домашнего каталога (при необходимости можно вызвать один из них в почтовый ящик). Это выбор пользователя.

Концептуально можно считать, что /var/spool/mail/$ USER является файлом в вашем домашнем каталоге. Это в значительной степени принадлежит тебе. Он находится в другом расположении, поскольку этот файл должен быть доступен во время доставки по электронной почте. Пользователям не разрешается создавать разорванную символическую ссылку или именованный канал, где система ожидает обычный файл, например, что позволяет избежать потенциально неприятных ошибок в системе доставки. Есть сайты, где домашние каталоги находятся на одном или нескольких файловых серверах, а почтовые очереди находятся на другом сервере.

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

Если необходимо убедиться, что запущен только один экземпляр программы, то вместо непосредственного запуска программы запустите сценарий-оболочку, проверяющий, запущено ли программное обеспечение. Ответ LatinSuD приводит пример такого сценария обертки.

Конечно, пользователь может обойти сценарий оболочки и запустить другой экземпляр вашего программного обеспечения. Но пользователь также может создать исполняемый файл, идентичный вашему, и запустить его. Таким образом, прохождение через сценарий обертки реализует желаемое ограничение способом, который имеет смысл.

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