Добрый день! Сегодня я хотел бы представить вашему вниманию Configuration Manager – plugin входящий в проект TacacsGUI.

Что же такое Configuration Manager? Это менеджер конфигураций (типа Oxidized или RANCID) с различными режимами просмотра изменений (diff) и записей в журнале AAA (Authentication Authorization Accounting). Таким образом, вы не только сможете контролировать разницу (diff) между конфигурациями, но и определять, кто сделал эти изменения. Протестировано на Cisco и Juniper. Ссылки на демо внутри.



Итак, план у нас такой: мы знакомимся с главным интерфейсом; оцениваем все преимущества и недостатки; следом изучаем, как настроить данную функцию; смотрим демо; делаем выводы и оставляем комментарии.

Главный Интерфейс. Preview


Начнем мы с самого интересного — с просмотра изменений конфигураций. Далее я буду сокращать Configuration Manager на CM.


Теперь разберем рисунок выше:

  1. В нашем распоряжении несколько режимов просмотра:
    • Brief (Краткий) – самый оптимальный режим просмотра diff. Здесь показаны только изменения и соседние строки конфигурации. Цифра 3 как раз и указывает количество строк текста вокруг изменения. При желании, вы можете увеличить это число, чтобы «картина» стала нагляднее.
    • Full View – тоже самое что и Brief, только на этот раз конфигурация показана целиком.
    • Preview – просто просмотр файла конфигурации. Выбираете версию файла и просматриваете.
    • Clear Diff – для тех «кто в танке» и любит «классику».
  2. Каждая версия файла определятся датой и hash commit (hash будет видно в будущем). Т.е. конфигурация с устройств будет собираться каждый день, но новая версия файла появится только когда произошли какие-либо изменения.
  3. Собственно, сам diff конфигураций. Здесь вы наглядно можете увидеть какие строки были добавлены, изменены или удалены, по сравнению с более старой версией файла.
  4. Мы приближаемся к самому интересному. Здесь содержится важная информация, которая указывает нам по каким критериям ведется выборка из ААА журналов, а именно – диапазон дат и адрес устройства.
  5. Список пользователей, которые получали доступ к устройству в указанный промежуток времени, а также краткая информация о записях в ААА журнале, связанная с ними. Слева направо кол-во Authentication, Authorization, Accounting.
  6. Здесь мы можем посмотреть, когда и какие команды вводил пользователь. В дальнейшем добавится фильтрация для удобного поиска.

Это и есть основной интерфейс, с которым вы будете работать, используя CM. Перейдем к описанию настройки.

Настройка CM


Краткая шпаргалка на рисунке ниже.


А теперь разберем более подробно каждый шаг, представленный на картинке:

Шаг 1. Добавление Устройства


Здесь все просто: вы указываете адрес, протокол (ssh, telnet) и порт. Опционально можно указать пользователя (Credential) и Prompt. Если пользователь на данном шаге не указан, то будет использован пользователь по умолчанию (определенный в Шаге 4). Если поле Prompt не заполнено, то его значение будет определятся на Шаге 3 (Создание модели).

Теперь поговорим о Prompt. Prompt – это приглашение устройства ввести команду, например, Switch> или Router>. У одного и того же устройства могут быть разные Prompt, в зависимости от уровня доступа, например, Switch>, Switch# или Switch(config)#. СМ использует Prompt запись, чтобы понять, когда вводить команду. Вы можете перечислить все возможные варианты Prompt разделяя их запятой. В дальнейшем я буду не однократно ссылаться на это описание.



Шаг 2. Создание пользователя


Имеется три поля, которые следует заполнить: название учетной записи (Credential Name), имя пользователя (Username) и его пароль (Password). Поле Credential Name будет отображаться в списках пользователей при его выборе и является обязательным для заполнения, а поле Username используется для авторизации на устройстве, и оно не обязательное, например, когда по telnet используется только пароль.



Шаг 3. Создание модели


Самый ответственный шаг. Здесь мы указываем порядок действий, который должен выполнить СМ. Заполнение поля Prompt аналогично описанному в Шаге 1 и его значение будет применено ко всем устройствам, определенным в Шаге 4. Если на данном этапе поле Prompt оставить пустым, то СМ будет использовать символы # и > по умолчанию. Далее лучше объяснять на примере.


В данном примере СМ, после успешного подключения, выполняет 5 команд:

  1. Ждет приглашения (Expect): router_15>
    Отправляет команду (Send): enable
  2. Ждет приглашения (Expect): assword: (строка вывода может быть указана частично)
    Отправляет команду (Send): ****** (если вы отправляете пароль, то его можно скрыть/hide)
  3. Ждет приглашения (Expect): (если вывод не указан, то вместо него будет использоваться строка из поля Prompt)
    Отправляет команду (Send): terminal length 0 (некоторые устройства используют функцию more, скрывающую часть информации для удобства, СМ не работает с more)
  4. Ждет приглашения (Expect):
    Отправляет команду (Send): show runn и сохраняет (Write) вывод в файл
  5. Ждет приглашения (Expect):
    Отправляет команду (Send): exit (отключаться желательно)

Надеюсь, я пролил свет на то, что же такое модель (model).

И да, это самый обычный expect. Данные настройки используются в сочетании с библиотекой Pexpect.

Шаг 4. Создание запроса


Если до этого мы создавали объекты, то здесь мы собираем их воедино. Выбираем куда будем сохранять файл(ы), модель (model), устройства (devices), пользователя по умолчанию, а также мы может подрезать выводимый файл и проверить как это будет выглядеть (Preview, второе изображение). Каждый файл будет имя составленное из шаблона — имя-устройства__id-устройства_id-запроса.



Подрезать файл можно как с начала, так и с конца. Например, мы подрезаем строки с 0 по 2, и -1 (последнюю) и -2 (предпоследнюю).

С помощью Preview вы сразу сможете определить будет ли работать ваша модель и как будет выглядеть файл.

В заключении мой вам совет – если у вас не получается получить конфигурацию, то попробуйте в начале подключиться сами к данному устройству и выполнить указанные команды. Лучше всего делать это прямо с сервера.

На этом настройка запроса закончена. Теперь остается удостовериться, что планировщик (cron) включен и ждать, когда СМ пройдется по запросам и соберет все конфигурации, либо запустить СМ не дожидаясь указанного времени (Force Start).

Demo


Так как это plugin, Configuration Manager находится не на самом видном месте. Чтобы исключить вопросы, «а где именно надо смотреть демо», я решил вынести это в отдельный раздел.

  1. Переходим на сайт demo.tacacsgui.com, авторизируемся.
  2. Далее смотрим внизу бокового меню Configuration Manager -> Configurations

  3. Выбираем файл и двойным кликом открываем меню просмотра (Preview)


    Ура! Мы на месте.


Планы на будущее


  1. Скачивать любую версию конфигурации (оно уже есть, не настроено в gui).
  2. Добавить больше информации для файлов в CM Explorer.
  3. Добавить шаблоны моделей.
  4. Обновить определенный файл, т.е. сделать быстрый запрос.
  5. Планировщик. Не просто раз в день или раз в неделю выполнять все запросы. А выполнять запросы по расписанию. С помощью СМ можно не только собирать конфигурацию, но собрать нечто вроде оптимизации, например, сохранять конфигурацию на устройствах.
  6. Добавить поддержку SFTP (SCP), FTP. Чтобы можно было скидывать файлы с устройств напрямую в СМ.
  7. Поддержка SNMP, чтобы устройство кидало сообщение о том, что конфигурация изменилась и СМ начал работать.

А у вас есть какие-нибудь идеи, что ещё можно добавить? Оставляйте ваши комментарии.

На этом все. Если вы хотите видеть больше статей о TacacsGUI по типу рецептов и советов по эксплуатации, то можете написать об этом в комментариях.

Всех Благ!