Все 100gb ?
alw добавил 20.11.2011 в 17:13
Да, разумеется.
alw добавил 20.11.2011 в 17:15
Ну суммарный объем разброс скачиваемых файлов явно больше размера ОЗУ.
Да я и не спорю, что она есть.
Я привел его как пример софтины, которой альтернативы нет.
Тут мы уже выходим за рамки администрирования в столь любимую философию.
Сорри, NDA. Факт тот что тестится оно порой на кластерах весьма нехилых аппаратных серверов.
А разрабатываться - да, вполне на виртуалках может.
Тем не менее у меня это первый вывод в grep -rl 'augeas' /etc/puppet/modules )
Прекрасно. Как обрабатываем ситуацию когда такая секция уже есть? прикручиваем еще и греп?
пишем целый скрипт и зовем его из паппета экзеком? И вы продолжаете утвержать что это удобнее и читаемее, чем приведенный пример?
Дописать патч к софтине, поддерживать его в актуальном состоянии, при выходе каждого апдейта не забывать пересобирать софт - проще и удобнее augeas ?
Ну попадется на глаза - приведу.
А про альтернативу dhcpd?
alw добавил 20.11.2011 в 09:40
Ну у нас тот же принцип, за исключением отсутствия стораджа.
Сейчас как раз неторопливо изучаем, какой сторадж использовать.
Вы что пользуете?
А управляете виртуалками как? просто virsh из консоли?
А вот не уверен. Что оно там делало при ребилде? Не готов поручиться, что оставшиеся три винта в том же состоянии, что и на момент евента.
это требование заказчика. которое не обсуждается.
В процессе разработки решения заказчик может - и регулярно этим пользуется - проверять что его требования соблюдены. И я считаю что это правильно.
На каком то этапе - так оно и есть. На этапе перфоманс-тестирования qemu/kvm не подходит.
С точки зрения паппета, развернута ли ОС на железной машине или в виртуалке - не важно.
С моими задачами он справляется. И я трачу меньше времени на реализацию их с помощью augeas, нежели с помощью sed/etc. Dixi.
Первое попавшееся:
augeas { "puppet_conf1": context => "/files/etc/puppet/puppet.conf/", changes =>[ "rm puppetd", "set agent/classfile \$vardir/classes.txt", "set agent/localconfig \$vardir/localconfig" ],
Жду аналог на sed.
Формулирую.
Хочется иметь пару dhcpd серверов в локации. Пару - для fault tolerance. Конфигурящихся из ldap. Ибо вся инфраструктура конфигурится из ldap, с помощью gosa. Вполне себе постановка задачи.
Таки зря вы не воспользовались советом, и начали делать активные действия без наличия бекапа.
Обратились бы к спецам - выдернули бы инфу. Не здесь, так повторюсь на форуме тринити.
Можно было хотя бы взять такие же три винта, сдампить их один-в-один, и на копии эксперементировать. А так - имеем что имеем.
И какой смысл изобретать свой велосипед, когда есть готовый debian и enterprise-level redhat ?
посвящу. Есть n заказчиков, у некоторых из них четкое требование - решение должно работать под такой то версией такой то ОС. И соответственно для построения лабы используется именно та ОС именно той версии, указанной в требовании заказчика. Но вместе с тем все лабы должны удовлетворять неким корпоративным стандартам в настройке. И с этой задачей puppet+augeas справляются отлично.
Я не о том совсем. Не нравится augeas - не пользуйте. Меня он более чем устраивает.
Речь была о другом. Есть набор требований - dhcp сервер, с поддержкой ldap и fault tolerance.
Решение - ровно одно, isc dhcpd. Соответственно независимо от его остальных качеств, альтернатив нет - приходится использовать его. Это я пытаюсь показать на примере, что далеко не всегда есть возможность выбирать.
И в чем же тут бардак?
Тут я привел пример dhcpd как софта, которому при некотором наборе требований замены нет.
А include он умеет, да.
В конкретно моем случае этого не нужно, но
ради бога, пусть в поле конфига, отвечающего за сервер, будет не единичное значение, а список.
стучись в аську 4831950, решим
