1.1, schizoid (?), 10:28, 09/10/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
С некоторой версии ios появилась возможность...
Жесть...И с какой это некоторой?
| |
|
2.5, pablo (??), 12:27, 10/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
>А rancid чем не устраивает?
Никогда не использовал, честно говоря. Сейчас посмотрел.
Насколько я понимаю, алгоритм работы примерно такой:
1. Получили сообщение, о том что кто-то изменял конфигурацию
2. Сходили на железяку, забрали новый конфиг
3. ПОложили в svn и все остальные приятности. :)
Однако, что призойдет в случае если в один момент времени конфигурация менялась двумя администраторами?
| |
|
3.6, MOV_ah (?), 13:39, 10/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Однако, что призойдет в случае если в один момент времени конфигурация менялась
>двумя администраторами?
Насколько я помню его работу (полгода уже дело не имел), рансид запускается по крону и ходит на все железяки в его конфиге (так что желательно, в случае с кошками, пользовать tacacs+), собирает оттуда конфигу и diffает её с тем, что он сохранил в прошлый раз. Изменения скидываются на мыло.
В случае, если конфиг изменился двумя админами одновременно, то по схеме, приложенной выше, понятно, что будет, но автором изменений будет тот, кто последним набрал write ;) В этом плане, конечно, проигрыш.
Зато всегда есть последний конфиг с того момента, когда железяка была доступна в последний раз (без паролей, правда, но это дело вполне поправимое :))
| |
|
4.7, pablo (ok), 17:42, 10/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>по крону и ходит на все железяки в его конфиге (так
>что желательно, в случае с кошками, пользовать tacacs+), собирает оттуда конфигу
>и diffает её с тем, что он сохранил в прошлый раз.
>Изменения скидываются на мыло.
>В случае, если конфиг изменился двумя админами одновременно, то по схеме, приложенной
>выше, понятно, что будет, но автором изменений будет тот, кто последним
>набрал write ;) В этом плане, конечно, проигрыш.
>Зато всегда есть последний конфиг с того момента, когда железяка была доступна
>в последний раз (без паролей, правда, но это дело вполне поправимое
>:))
В принципе "с некоторой версии" (с) :)) добавились некоторые фичи которые могут серьезно облегчить жизнь в этом плане.
1. Configuration Replace and Configuration Rollback
http://cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09
Сохраняет конфигурацию в указанное место.
2. Contextual Configuration Diff Utility
http://cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09
Собственно из названия всё понятно. diff прямо в консольке железяки.
Надо бы об этом тоже заметку написать. :)
Но идея хранить все изменения в svn мне очень нравится.
Одно другому не мешает. :)
| |
|
|
|
1.8, cae (?), 09:17, 12/10/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Цискины индусы уже не зажигают, а просто поджигают ;-))
Зачем было плодить вывод изменений конфига в syslog, когда сто лет уже есть tacacs+?
Для того, чтобы хелпдеск видел изменения, которые ему нафиг не нужно видеть? Отлично! Безопасность на высоте, дальше некуда...
Правильное решение такое:
1. сбор конфигов rancid (каждый день принудительно, по команде из syslog - опционально
2. доступ и логи изменений конфига юзверями в tacacs+
3. хелпдеску enable не давать, для этого есть iptech.
3. syslog оставить хелпдеску для постоянного его курения на случай проблем.
dixi.
зы. Ну а то, что наконец появились diffы и коммиты конфига, которые в juniper были отродясь, не может не радовать ;-)))
| |
|
2.9, pablo (ok), 18:21, 12/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
Сомневаюсь, что индусы пишут то, что им в голову взбредет. Кто-то же им задачи ставит :)
Видимо добавления этого функционала, отражает различие подходов. Я сомневаюсь, что в циске "забыли" о существовании tacacs. :)
Может это разворот в сторону smb рынка...
Подскажите, что такое iptech? Гугл вразумительного ничего не отвечает.
| |
|
3.10, cae (?), 13:41, 16/10/2007 [^] [^^] [^^^] [ответить]
| +/– |
iptech - подразделение, отвечающее за ospf, bgp и прочее ip tech, чему обычный helpdesk, как правило, не обучен.
| |
|
|
|