Система допускает одновременный доступ нескольких пользователей через одну или разные командные оболочки и Web-интерфейс, в том числе — под одним именем. Однако такая игра на одном рояле в 4 руки всегда чревата конфликтами, если разные пользователи или инструменты пытаются выполнить противоречащие друг другу действия. Эта проблема принципиально неразрешима одними лишь программными средствами, поэтому в конечном счёте, если администратор(-ы) устройства допускают для себя возможность такого управления, то они тем самым берут на себя всю ответственность за возможные последствия. Программная среда может лишь отчасти ограничить негативные последствия творчества коллективного разума.

Схема взаимодействия различных инструментов управления в NSG Linux 2.1 показана на рисунке. Как можно видеть, они распадаются на две основные группы: фирменная система управления NSG (nsgsh/Web + nsgconfd) и стандартные средства управления ОC Linux: командная оболочка bash (включая все возможные способы обращения к ней) и агент SNMP. Возможные сценарии конфликтов и способы их разрешения:

1. Внутри системы управления NSG Linux. Командные оболочки NSG (nsgsh и Web) допускают одновременный вход нескольких пользователей, в т.ч. — имеющих права чтения и записи. Однако при этом следует различать административные права пользователя и административный статус его текущей сессии, который может быть равным или ниже административных прав. В каждый момент времени на устройстве может быть не более одного администратора, которому разрешено изменять, применять и сохранять конфигурацию. Присвоение и передача прав текущего администратора в случае, когда на них претендуют одновременно несколько пользователей, регламентируются правилами и параметрами, описанными подробно в справке по узлу .system.sessions.

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

2. Между стандартными средствами управления ОС Linux. Команды bash и запись в SNMP OID-ы — это разовые акты управления. Они не предусматривают дальнейшего контроля за судьбой сделанных изменений. Таким образом, эти изменения настроек могут быть отменены или вновь изменены другим пользователем, в другом сеансе, или другим инструментом управления. Проследить за этим принципиально невозможно, остаётся только рассчитывать на наличие здравого смысла у пользователей — сколь бы маловероятно это ни было.
   Это относится также ко всем возможным способам выполнения команд bash, включая:
   • Ручной запуск команд в интерактивной сессии
   • Выполнение пользовательских стартовых скриптов
   • Выполнение пользовательских скриптов, заданных в системе управления NSG
   • Выполнение макрокоманд и произвольных скриптов в системе SMS-управления
   • Выполнение произвольных команд и скриптов агентом Zabbix

3. Между системой управления NSG Linux и стандартными средствами управления. Система управления NSG, в лице демона nsgconfd, постоянно контролирует текущее состояние системы и его соответствие заданному дереву конфигурации. Если изменить это состояние внешними средствами, например, взять маршрут, созданный в узле .ip.route, и удалить его средствами bash или SNMP, то через короткое время оно будет восстановлено снова.
   Если какие-то объекты (например, маршруты) изначально созданы и управляются стандартными средствами ОС Linux и не отражены в конфигурационном дереве NSG, то система управления NSG в их работу не вмешивается.
4. Пользователь может из-под nsgsh запускать вложенный сеанс интерактивной работы в bash. Система управления NSG также может, в соответствии со своим деревом конфигурации, запускать из-под nsgconfd скрипты, исполняемые в комадной среде bash. Такие скрипты могут быть заданы, в частности, в netping или в обработчике событий. Относительно взаимодействия таких скриптов с другими инструментами управления см. п.2.
5. Из-под bash можно запускать nsgsh в интерактивном или пакетном режиме. При этом вложенная сессия nsgsh конкурирует с другими сессиями nsgsh/Web за статус текущего администратора на общих основаниях. В частности, заданный скрипт не выполнится, если он требует изменения дерева конфигурации, а в это время в системе уже открыта сессия со статусом администратора.
6. Внутренние скрипты nsgconfd не конфликтуют ни с какими другими оболочками. Однако область их применения весьма узка и специфична. В данной версии NSG Linux 2.1 это только выполнение действий в обработчике событий.

Чтобы избежать подобных конфликтов, настоятельно рекомендуется настраивать каждый объект конфигурации всегда либо только посредством инструментов NSG, либо только при помощи стандартных средств ОС Linux, не смешивая их. Например, если требуется манипулировать некоторым маршрутом при помощи скриптов, вызываемых из netping, то и создавать его следует средствами таких же скриптов. Если некоторый объект конфигурации управляется по SNMP, то и первоначальную настройку этого объекта следует выполнять по SNMP или при помощи стартового скрипта bash.

Также рекомендуется, по возможности, избегать вызова nsgsh в пакетном режиме из среды bash, а выполнять те же операции напрямую — с помощью стандартных команд Linux. Например:

вместо .port.show.ПОРТ —

ifconfig ИНТЕРФЕЙС или ifconfig $(nsgsh -q .system.get-iface-name=ПОРТ)

вместо .tunnels.ipsec.restart — ipsec setup restart

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