Что-то мне это напоминает российское правительство в миниатюре.
— Нее, мы не получаем откаты за принятые законопроекты от правообладателей, мы просто защищаем авторские права. И не имеет значения, что мы разрешили правообладателям беспредельничать от нашего имени.
— Нее, мы не получаем откаты за сертификацию от создателей малвари, мы просто защищаем ваши компьютеры. И не имеет значения, что мы подписали сертификатом малварь, опять-таки разрешив ей беспредельничать от нашего имени.
Сколько можно уже?
Кто-нибудь может просветить насчёт возможности пожаловаться на держателя сертификата тому, кто его выдал?
Вау. Учитывая количество новостей оттуда хотя бы об этом законопроекте за последний месяц, я боюсь вообще приближаться к границе — а вдруг услышу музыку на таможенном посту? Если принимать во внимание эти законопроекты, с меня возьмут штраф за это, едва я въеду в Россию. Только таможенникам не подсказывайте, пожалуйста.
1) Задача поставлена правильно. Нужно, чтобы DNS сервера хранились в resolv.conf (их каноничное место) и чтобы использовался статический DNS-сервер (не имеет значения, какой). Цель достигнута.
2) Аргументов до сих пор нет — всего хорошего. У меня тоже, знаете ли, есть цели и свободное время. Сейчас моя позиция уже разъяснена и больше объяснять я не вижу смысла.
Удачного Вам дня! Надеюсь, что нам обоим этот спор как-либо пойдёт на пользу.
Если вы не имеете желания доказывать — почему утверждаете в стиле «Статья того не стоит, вот это ошибочно, но я не докажу, почему»?
Так. Краткое описание моего способа:
dnsmasq берёт DNS-сервера из resolv.conf
Сервера прописаны статичные, т.е. всегда используются одни и те же, признанные надёжными. Никто не запрещает, плюс — во всех сетях гарантирована работа DNS, а то он имеет свойство падать на дешёвых роутерах, к которым я иногда подключаюсь ;-)
Проблема — при получении информации от DHCP-сервера dhclient также перезаписывает resolv.conf. Нам это не надо — у нас DNS прописан навечно один и тот же.
Есть 3 варианта избежать перезаписи файла, не отключая dhclient:
1) Отредактировать конфиг dhclient. В нём для отключения перезаписи файла нужно прописать те же статические адреса, что и в resolv.conf. Плюсы — проблема решена. Минусы — если потребуется изменить статический DNS на OpenDNS, к примеру, придётся вспоминать, что я раньше конфигурировал и как именно. resolv.conf немножечко так теряет своё значение — место хранения адресов DNS-серверов. Всё потому, что адреса DNS по факту хранятся в каком-то другом файле, а это уже затрудняет дальнейшую конфигурацию.
2) Отключить у dhclient функцию перезаписи resolv.conf. Да, такая функция имеется. Плюсы — такие же, как у третьего способа, который я и использовал (блокировка файла). Минусов на два больше. Первый — это то, что файл всё равно может быть перезаписан кем-то ещё, хоть это и нежелательно.
Почему не описал в статье? Вот и второй минус этого способа. Есть одно правило, которое необходимо соблюдать, когда пишешь статью. Она должна быть удобочитаемой, у статьи есть конечная цель. Эта цель — фраза «Всё настроено». Отходить от пути к этой цели нужно очень осторожно и маленькими шагами — иначе рискуешь четверть статьи посвятить тонкой настройке dhclient. Это, может, и хорошо, но в статье нарушается баланс подробность-удобочитаемость. И редактирование файлов с функциями dhclient — это та вещь, которую я, как автор статьи, посчитал неважной для читателя. Ведь читателю от этой статьи нужна инструкция по настройке точки доступа, а не dhclient, иначе у статьи был бы другой заголовок, не думаете?
3) Блокировка файла. Плюсы — 1) цель достигнута 2) список серверов вообще никто не перезапишет 3) тем более dhclient 4) всего одна консольная команда. Минусы — dhclient поругается в консоль, если его вызвать ручками. Свои основные функции он по-прежнему выполняет, не выполняет только не нужную нам.
Всё, пожалуй. Если не будет достойного комментария — я лучше перестану отвечать, у меня на очереди ещё не одна статья. Почему сейчас отвечаю? Всё просто. Именно по комментариям читатели определяют, какие рекомендации верны, а какие — нет. Это моя статья, и я написал её не просто так, а чтобы создать полноценный материал, способный помочь в настройке. И именно я, как автор, ответственный за написанное, буду доказывать, что статья моя — не результат переработки пищи экземпляром Canis Lupus, а то, что действительно может помочь в настройке. И именно я поблагодарил Вас за поправку к статье (ifup/ifconfig) — опять же, мне самому выгодно, чтобы статья была хорошей. И именно я буду объяснять что «так на самом деле можно» — это моя статья, и моё мнение, а я стараюсь всегда обосновывать своё мнение — а необоснованная критика ничего хорошего статье априори не несёт.
Извините, но уверенность в стиле «Вы настолько неправы, я даже объяснить не смогу» как-то не является аргументом. Серьёзно — Вы производите впечатление человека, который заучил один путь и следует ему, всячески порицая другой, при этом не приводя ни одного аргумента кроме дважды повторённого сравнения, которое, на мой взгляд, притянуто за уши. Раз уж нельзя что-то делать, объясните, прошу.
— Почему блокировать файл от записи плохо?
— Почему системный администратор не может заблокировать от записи файл, который не должен быть перезаписан? dhclient поперхнётся? Уверяю Вас, работает нормально в разных сетях, просто везде используется один и тот же DNS — Гугловский.
— В чём минусы такого подхода?
Понимаете, можно решить всё не перезаписью, полностью согласен. Но зачем? В чём плюс? Минусы реально никто не перечислил — они все справа от моих комментариев, но объяснений нет. Печально. Да, я упрямый, но признавать недоказанные ошибки не вижу смысла.
Видимо, это AD-HOC. Скажу сразу — я даже не рассматривал эту опцию, поскольку, как по мне, это подходит лишь для быстрого поднятия беспроводной связи между парой-тройкой ноутов на коленке, стабильность тоже так себе (использовал в своё время AD-HOC, встроенный в Windows XP и W7). Именно отсутствие поддержки на многих устройствах и не радует. Так что — лучше повозиться, но потом не жалеть о том, что не во всех случаях подходит, к hostapd подключается всё, что ловит сигнал.
К слову, я сам сейчас думаю о том, чтобы освоить Sputnik или что-то подобное. А если буду осваивать — обязательно напишу статью. К тому же — есть идея, где это можно применить с пользой в ближайшее время. А ноут — лишь одна из альтернатив, те же дешёвые AP элементарно не выдержат многих вещей и тоже не имеют многих аппаратных плюшек нетбука. К тому же я буквально сейчас работаю над тем, чтобы встроить гнездо RP-SMA для антенны в корпус ноута, сегодня буду паять переходник IPX-RP SMA и сверлить корпус ноута, ну и карточку беспроводную думаю другую поставить =)
Это-то конечно =) Но логика тут простая — все и так либо на крайних каналах. либо на центральном — распределение такое, чтобы уменьшить негативное взаимодействие сигнала AP на разных каналах. И если поставить точку где-то между 1 и 6, то на сигнал нашей точки будут влиять как станции из канала 1, так и станции из канала 6, так же и с 6 и 11. Поправьте меня, если что.
А что, если статья допускает ошибку в двух похожих командах, даже из прочтения мануалов по которым не всегда можно уловить разницу между ними, то это уже «статья»?
Заблокировать файл — один из путей достигнуть цели, и никто не запрещает его использовать. Да, никто также не запрещает указать это в настройках dhclient — но разницы-то по настоящему нет. Или, по-вашему, есть?
Да, спасибо, эту опцию в дефолтном конфиге я уже видел. Если её не указывать, довольно умный в плане опций dnsmasq, насколько я помню, берёт сервера из resolv.conf. А resolv.conf — файл, который предназначен для того, чтобы хранить названия DNS-серверов, используемых системой… Что он, внезапно, и делает, храня там 8.8.8.8, которые мы бы могли указать в конфиге dnsmasq… Но зачем, если есть resolv.conf? В который можно закинуть эти сервера и просто-напросто удостовериться, что не нужно будет обрубать лапы каждой программе, которая захочет изменить resolv.conf. Там просто нет смысла его менять, честно-честно.
Да, а ещё в resolv.conf можно указать localhost, где у нас dnsmasq, а ему же приказать брать серверы из ещё одного файла. Так тоже можно, да. Путей в Linux очень и очень много, честно говоря, сама идеология Linux об этом прямым текстом говорит.
Ну так вот, пожалуйста, приведите примеры, почему же блокировать файл волей администратора, который знает, что содержимое этого файла менять просто ну не надо — бред. И почему DNS-сервера, захардкоженные в /etc/dnsmasq.conf, лучше, чем те же сервера в /etc/resolv.conf, хотя, по идее — им нужно быть в последнем.
— Нее, мы не получаем откаты за принятые законопроекты от правообладателей, мы просто защищаем авторские права. И не имеет значения, что мы разрешили правообладателям беспредельничать от нашего имени.
— Нее, мы не получаем откаты за сертификацию от создателей малвари, мы просто защищаем ваши компьютеры. И не имеет значения, что мы подписали сертификатом малварь, опять-таки разрешив ей беспредельничать от нашего имени.
Сколько можно уже?
Кто-нибудь может просветить насчёт возможности пожаловаться на держателя сертификата тому, кто его выдал?
Только таможенникам не подсказывайте, пожалуйста.
2) Аргументов до сих пор нет — всего хорошего. У меня тоже, знаете ли, есть цели и свободное время. Сейчас моя позиция уже разъяснена и больше объяснять я не вижу смысла.
Удачного Вам дня! Надеюсь, что нам обоим этот спор как-либо пойдёт на пользу.
Так. Краткое описание моего способа:
dnsmasq берёт DNS-сервера из resolv.conf
Сервера прописаны статичные, т.е. всегда используются одни и те же, признанные надёжными. Никто не запрещает, плюс — во всех сетях гарантирована работа DNS, а то он имеет свойство падать на дешёвых роутерах, к которым я иногда подключаюсь ;-)
Проблема — при получении информации от DHCP-сервера dhclient также перезаписывает resolv.conf. Нам это не надо — у нас DNS прописан навечно один и тот же.
Есть 3 варианта избежать перезаписи файла, не отключая dhclient:
1) Отредактировать конфиг dhclient. В нём для отключения перезаписи файла нужно прописать те же статические адреса, что и в resolv.conf. Плюсы — проблема решена. Минусы — если потребуется изменить статический DNS на OpenDNS, к примеру, придётся вспоминать, что я раньше конфигурировал и как именно. resolv.conf немножечко так теряет своё значение — место хранения адресов DNS-серверов. Всё потому, что адреса DNS по факту хранятся в каком-то другом файле, а это уже затрудняет дальнейшую конфигурацию.
2) Отключить у dhclient функцию перезаписи resolv.conf. Да, такая функция имеется. Плюсы — такие же, как у третьего способа, который я и использовал (блокировка файла). Минусов на два больше. Первый — это то, что файл всё равно может быть перезаписан кем-то ещё, хоть это и нежелательно.
Почему не описал в статье? Вот и второй минус этого способа. Есть одно правило, которое необходимо соблюдать, когда пишешь статью. Она должна быть удобочитаемой, у статьи есть конечная цель. Эта цель — фраза «Всё настроено». Отходить от пути к этой цели нужно очень осторожно и маленькими шагами — иначе рискуешь четверть статьи посвятить тонкой настройке dhclient. Это, может, и хорошо, но в статье нарушается баланс подробность-удобочитаемость. И редактирование файлов с функциями dhclient — это та вещь, которую я, как автор статьи, посчитал неважной для читателя. Ведь читателю от этой статьи нужна инструкция по настройке точки доступа, а не dhclient, иначе у статьи был бы другой заголовок, не думаете?
3) Блокировка файла. Плюсы — 1) цель достигнута 2) список серверов вообще никто не перезапишет 3) тем более dhclient 4) всего одна консольная команда. Минусы — dhclient поругается в консоль, если его вызвать ручками. Свои основные функции он по-прежнему выполняет, не выполняет только не нужную нам.
Всё, пожалуй. Если не будет достойного комментария — я лучше перестану отвечать, у меня на очереди ещё не одна статья. Почему сейчас отвечаю? Всё просто. Именно по комментариям читатели определяют, какие рекомендации верны, а какие — нет. Это моя статья, и я написал её не просто так, а чтобы создать полноценный материал, способный помочь в настройке. И именно я, как автор, ответственный за написанное, буду доказывать, что статья моя — не результат переработки пищи экземпляром Canis Lupus, а то, что действительно может помочь в настройке. И именно я поблагодарил Вас за поправку к статье (ifup/ifconfig) — опять же, мне самому выгодно, чтобы статья была хорошей. И именно я буду объяснять что «так на самом деле можно» — это моя статья, и моё мнение, а я стараюсь всегда обосновывать своё мнение — а необоснованная критика ничего хорошего статье априори не несёт.
— Почему блокировать файл от записи плохо?
— Почему системный администратор не может заблокировать от записи файл, который не должен быть перезаписан? dhclient поперхнётся? Уверяю Вас, работает нормально в разных сетях, просто везде используется один и тот же DNS — Гугловский.
— В чём минусы такого подхода?
Понимаете, можно решить всё не перезаписью, полностью согласен. Но зачем? В чём плюс? Минусы реально никто не перечислил — они все справа от моих комментариев, но объяснений нет. Печально. Да, я упрямый, но признавать недоказанные ошибки не вижу смысла.
There is no «one true way» to do anything. Вы уж простите, но это действительно так.
Да, спасибо, эту опцию в дефолтном конфиге я уже видел. Если её не указывать, довольно умный в плане опций dnsmasq, насколько я помню, берёт сервера из resolv.conf. А resolv.conf — файл, который предназначен для того, чтобы хранить названия DNS-серверов, используемых системой… Что он, внезапно, и делает, храня там 8.8.8.8, которые мы бы могли указать в конфиге dnsmasq… Но зачем, если есть resolv.conf? В который можно закинуть эти сервера и просто-напросто удостовериться, что не нужно будет обрубать лапы каждой программе, которая захочет изменить resolv.conf. Там просто нет смысла его менять, честно-честно.
Да, а ещё в resolv.conf можно указать localhost, где у нас dnsmasq, а ему же приказать брать серверы из ещё одного файла. Так тоже можно, да. Путей в Linux очень и очень много, честно говоря, сама идеология Linux об этом прямым текстом говорит.
Ну так вот, пожалуйста, приведите примеры, почему же блокировать файл волей администратора, который знает, что содержимое этого файла менять просто ну не надо — бред. И почему DNS-сервера, захардкоженные в /etc/dnsmasq.conf, лучше, чем те же сервера в /etc/resolv.conf, хотя, по идее — им нужно быть в последнем.