А еще можно сделать гит рерозиторий, и править в проекте файл с данными на одной машине, а остальные допустим по крону раз в минуту делают git pull и всё. Имхо, менее геморойно.
Да, вариант вполне жизнеспособен, однако я работал в условиях, когда серверную часть желательно было оставить как есть (кое-кто придерживается старого правила «работает — не трогай»). Поэтому я и выбрал вариант, в котором инициализация работы происходит со сторонней машины.
Если изменять серверную часть, то, наверное, лучше было бы сразу посмотреть в сторону динамической маршрутизации (тот же bird).
Иногда динамика невозможна. Скажем, пакет Quagga не умеет работать с «виртуальным» ip-адресом carp-интерфейсов, упорно подсовывая в анонсах «реальный» ip-адрес, что во многих случаях неудобно. Авторы Quagga в рассылке заявили, что и не будут это исправлять, типа это фича.
В остальном соглашусь. И скрипты что-то очень уж… гм… монстроидальны. Центральный репозиторий svn/git был бы куда изящней.
Я вообще не фанат маршрутизации на Linux, все-таки, роутинг при помощи CPU — это уже не модно.
Для малого офиса, конечно, сойдет, пока поток через роутер не превышает 2-3 Мб/с, а количество сетей — 3-4 штук. Но дальше уже надо бы на специализированное оборудование переходить, желательно с Cisco Express Forwarding, чтобы маршрутизацией занимались исключительно ASIC, а процессор освободить для управления этой и другими функциями.
Гм, вы видимо в провайдерских сетях не работали ;) Маршрутизация на CPU это очень даже модно. Гигабит, причём с NAT'ом, маршрутизировать на серверах и под Linux — милое дело, стоит на порядок дешевле цисковских (и не только) NAT-железок. А уж чистый роутинг на этих скоростях вытянет любой современный офисный тазик с нормальной сетевушкой.
Работал :-) Я, кагбэ, исключительно с провайдерами и работаю. Правда, не нашими. К примеру, сейчас работаю с Sprint, одним из 12 Tier 1 операторов.
Чистый роутинг на 1 Гб/с между 10 разными сетями — не вытянет, готов поспорить :-) То есть, итоговая скорость не будет 1 Гб/с из-за задержек на обработку пакетов. А уж цепочка таких роутеров сделает задержку совсем неприличной.
Это бессмысленный спор и бессмысленный разговор, с учетом того, что я не могу показать Вам живую работу этого всего :-)
Поставьте эксперимет, если Вам интересно: подключите каскадом несколько компов на Linux с настроенным роутингом и рядом — несколько роутеров с поддержкой Cisco Express Forwarding, и просто попингуйте сеть на одном конце цепочки с другого ее конца. И посмотрите на delay.
Для того, чтобы ускорить маршрутизацию пакетов при помощи центрального процессора, когда-то придумали MPLS. Cisco Express Forwarding позволяет маршрутизировать обычные пакеты с той же скоростью, с которой это делают P роутеры в MPLS сети по меткам. Никогда процессором вы не добьетесь этой скорости.
Ну да, бессмысленный спор за отсутствием реального приложения. Но говорить, что нужна циска при потоках, превышающих 2-3 Мбайт/сек, является уж явным и абсолютным преувеличением.
This option specifies a list of static routes that the client should
install in its routing cache. If multiple routes to the same
destination are specified, they are listed in descending order of
priority.
Вариант с DHCP может не подойти, ибо изменения очень инертны получаются. а вот включить тупой RIP
командной router_enable="YES", действительно не сложно
Но если уж гоняют скрипты — то попросить dhcpcd проапдейтить руты (одна команда вместо тонны ненужных скриптов — дефакто нужно дать только SIGHUP сигнал демону) — все равно сильно лучше и проще предложенного решения.
Согласен, что «неправильная» (устаревшая) архитектура сети — ключ ко всему. Я работал с тем, что есть, о чём писал в комментарии выше. Топик — это описание реализации конкретного решения конкретной задачи, плюс небольшое описание некоторых особенностей shell-скриптов (работа с опциями скрипта, передача команды в качестве параметра функции), кому-то может пригодиться. И я не уверен, что запуск dhclient'a на серверах будет одобрен свыше. Но за наводку спасибо, об этом я, признаться, не подумал.
Извините, а зачем написана эта статья? Я восхищаюсь Вашим трудолюбием и понимаю, что в Вашем случае внедрение OSPF может быть и невозможно («я работал в условиях, когда серверную часть желательно было оставить как есть»), но зачем описывать это здесь? Вряд ли кто-нибудь пойдёт удалять свою кваггу или bird и адаптировать под себя выложенные скрипты.
Прошу прощения, что повторяюсь в комментариях, но отвечу и здесь. Топик — это описание реализации конкретного решения конкретной задачи, плюс небольшое описание некоторых особенностей shell-скриптов (работа с опциями скрипта, передача команды в качестве параметра функции), я посчитал, что кому-то может пригодиться (раз схема со статическими маршрутами работает у нас, то она вполне может встретиться и где-то ещё). Я ни в коем случае не призываю отказываться от динамической маршрутизации или от своих наработанных схем. =)
Титанический труд автора безусловно заслуживает уважение за исключением одной мелочи — постановка такой задачи полный идиотизм! Несколько десятков лет огромное количество людей разрабатывают протоколы маршртизации для того чтобы вот ЭТО НЕ ДЕЛАТЬ вручную.
автор зверь, перелопатил на С свою статическую маршрутизацию сети. есть еще умельцы!
долой динамические протоколы циски и прочую ересь! даешь С! шучу )
Автоматизация работы со статическими маршрутами на сети FreeBSD-серверов