Не обязательно любой shell скрипт должен начинать с #!(sha-bang). Например — подключение shell скриптов с помощью. — тот скрипт который мы подключаем не обязан иметь sha-bang в начале.
Почему пост исключительно направлен на тех, кто использует linux? bash практически де-факто стандарт для всех пользовательских shell'ов. Где-то встречал рекомендацию, чтобы оформлять sha-bang так # !/bin/sh. Именно пробел после #. Только не понял для чего это используется:)
Если планируется писать скрипты, которые должны работать на всех видах nix, то лучше писать исключительно на sh, не употребляя дополнительные возможности bash или какого-нибудь специфичного интепретатора.
Вообще можно посоветовать как можно больше читать чужого кода. Тогда со временем помими прочих полезных вещей, приходит понимание того как нужно и не нужно именовать функции и называть переменные.
Я прекрасно понимаю как можно ускорить обновление зон для BIND. Но в ввиду определенных условий, сделав так как Вы предлагаете, у меня возрастет нагрузка на базу. Скажем так, в виду архитектурной особенности сделать nsupdate для каждой меняющейся зоны нельзя.
Я прекрасно понимаю как можно ускорить обновление зон для BIND. Но в ввиду определенных условий, сделав так как Вы предлагаете, у меня возрастет нагрузка на базу. Скажем так, в виду архитектурной особенности сделать nsupdate для каждой меняющейся зоны нельзя.
Каждый час происходит перегенарация. Поверьте, 25 % часа на чтение зон — много. Слишком.
Да, говорим мы про djbdns, и если и Вы потрудитесь внимательно все перечитать, то я нигде не говорил об исключительном использовании оного как авторитетного dns сервера. Я говорю о всех его возможностях. Если Вы не знаете, то djdbns это грубо говоря набор различных программ. И еще, если Вы уж используете ipv6, то наверное должны знать что CIDR не применяется в ipv6 и указывать ipv6 сеть через cidr нотацию, по крайней мере странно.
Вы подменяете понятия. «в последнее время наибольшую популярность набирает разработка уважаемого господина D. J. Bernstein — djbdns» отнюдь не значит, что djbdns — «наиболее популярным». Перечитайте внимательно исходный пост и поймите наконец, что я считаю djbdns новым стандартом dns серверов. Если Вы до сих пор не поняли, то я хотел донести до широкой общественности, что существует хорошая альтернатива BIND, использование которой в некоторых случаях лучше чем использование BIND. Перечитайте мои комментарии, я нигде не говорил, что следует немедленно прекратить использовать BIND. Вы же, занимаете позицию, что djbdns ни в коем случае не стоит использовать даже для локального кеширующего сервера, то есть позицию «BIND и только BIND». Я понял Вашу точку зрения. На сим предлагаю Вам прекратить наш спор, ибо каждый останется при своем мнении, а дальнейшие споры, выяснение отношений мне никак не хочется здесь лицезреть. Спасибо.
Откуда у Вас столько уверенности, что софт этот не пригоден для продакшна? Еще раз спрашиваю про qmail — Вы статистику используемых MTA видели? Если есть там qmail — значит он _работает_. Более того, если его используют более менее крупные ISP/хостеры это говорит о том, что qmail работает хорошо. Вам показать список уязвимостей в BIND? Пожалуйста, попробуйте перестать занимать позицию «BIND и только BIND», попробуйте занять позицию «BIND и с некоторыми оговорками другие сервера». Право, это умнее!
Я не говорю о производительности в плане способности обратотать n запросов в секунду. Для меня более приоритетным является время обновления нескольких десятков тысяч зон.
И по поводу количества обрабатываемых запросов. Чтобы не быть голословными — посмотрите на www.faqts.com/knowledge_base/view.phtml/aid/11438/fid/699. Из-за этой же идиотской позиции автора его софт работает быстро и надежно, ничего более.
Хорошо, пускай нашли один баг на 64 битной архитектуре. Но мне кажется что это не сравниться с количеством багов в sendmail? Или я не прав?
1. Вам жалко еще одного ip адреса?
2. Не при наличии одного сетевого интерфейса, а при наличии одного ip на интерфейсе. Согласен что возможно это не правильно, но 13 метров памяти для кеширующего сервера ничем не лучше.
3. djbdns и bind не могут использовать notify из-за бажной реализации notify в bind.
Я имел ввиду, что для _действительно_ больших проектов, в которых стоит думать о load balancing'е на уровне geo position, в качесте DNS серверов вряд ли будет использоваться BIND ;) Собственно скорее всего как и djbdns.
И ровным счетом ничего больше.
Почему пост исключительно направлен на тех, кто использует linux? bash практически де-факто стандарт для всех пользовательских shell'ов. Где-то встречал рекомендацию, чтобы оформлять sha-bang так # !/bin/sh. Именно пробел после #. Только не понял для чего это используется:)
Если планируется писать скрипты, которые должны работать на всех видах nix, то лучше писать исключительно на sh, не употребляя дополнительные возможности bash или какого-нибудь специфичного интепретатора.
Да, говорим мы про djbdns, и если и Вы потрудитесь внимательно все перечитать, то я нигде не говорил об исключительном использовании оного как авторитетного dns сервера. Я говорю о всех его возможностях. Если Вы не знаете, то djdbns это грубо говоря набор различных программ. И еще, если Вы уж используете ipv6, то наверное должны знать что CIDR не применяется в ipv6 и указывать ipv6 сеть через cidr нотацию, по крайней мере странно.
+поймите наконец, что я _не_ считаю djbdns новым стандартом dns серверов.
Вы код пробовали смотреть? qmail спроектирован с учетом безопасности. Что называется security by design.
И по поводу количества обрабатываемых запросов. Чтобы не быть голословными — посмотрите на www.faqts.com/knowledge_base/view.phtml/aid/11438/fid/699. Из-за этой же идиотской позиции автора его софт работает быстро и надежно, ничего более.
Да, с axfr перепутал.
Вам сейчас нужны AAAA записи?
1. Вам жалко еще одного ip адреса?
2. Не при наличии одного сетевого интерфейса, а при наличии одного ip на интерфейсе. Согласен что возможно это не правильно, но 13 метров памяти для кеширующего сервера ничем не лучше.
3. djbdns и bind не могут использовать notify из-за бажной реализации notify в bind.
И ровным счетом ничего больше.