Comments 32
Любопытная альтернатива Network Manager-у.
+1
нетфоркменеджер невыносимо отвратитетелен тем, что непонятно как его можно тонко настраивать и нет ни капли документации на его dbus api.
совершенно магическая программа — или она сама работает или она сама не работает.
совершенно магическая программа — или она сама работает или она сама не работает.
Лично мне пока много сетей не надо, проще настроить вручную и вручную же поднимать/опускать интерфейс. Но в будущем может пригодится — добавил в закладки
У вас нет ни Network Mnager, ни Wicd?
Мы же не про сервера говорим?
Мы же не про сервера говорим?
Нет, не использую ни Network Manager ни Wicd. Машина — ноутбук. Подключена по WiFi, конфигурация которого полностью вынесена в /etc/network/interfaces. Там же сконфигурен eth0 через провод, DHCP.
а почему это вас удивляет? Нетворк менеджеры нужны когда вы постоянно кочуете и сети меняются и прописывать конфиги каждый раз уже не логично, а если вы сидите на одном и том же месте в одной и той же сети…
Покажите мне хоть одну сеть без DHCP.
А вот пример с DNS может пригодитсься. Спасибо.
А вот пример с DNS может пригодитсься. Спасибо.
Дома и на работе — сеть без DHCP.
Хороша ложка к обеду, а тулить DHCP везде и всюду не считаю правильным
Лучше было написать «нормально сконфигурированую сеть без DHCP», тогда минусов было бы меньше, а плюсов больше :)
В сетях, где тусуются ноутбуки, рабочие станции и прочие мелкие сетевые устройства, DHCP — must have!
В сетях, где тусуются ноутбуки, рабочие станции и прочие мелкие сетевые устройства, DHCP — must have!
А я вот себе не могу дома позволить сеть с личным DHCP, т.к. либо у меня перестанет работать приставка IPTV (она получает IP от серверов провайдера по этому же самому DHCP), либо я лишусь возможности просмотра IPTV на компьютере. Да и вообще получается удобнее. Если настраиваешь адреса вручную, то пользуешься нормальным интернетом. А если у провайдера что-то упало, переключаешься на DHCP и пользуешься медленным порезанным служебным интернетом «от IPTV».
Правилом хорошего тона является указания полного пути при вызове внешней программы, а не прописывание путей в PATH.
Не соглашусь. Во-первых, пути могут меняться (/usr/sbin → /sbin или наоборот), а во-вторых, здесь важно, чтобы ifupdown смог вызвать внешние программы, а пути вызова в нём я менять не могу — они указываются на этапе компиляции в .defn-файле. Потому PATH нужен.
Я же не сказал — «каждый раз, когда в скрипте вместо прописывания абсолютных путей вы полагаетесь на PATH — где-то рвут оптический кабель» %)
Это именно правило хорошего тона, которое можно нарушать, если тому есть причины. Но лучше таки соблюдать, особенно если советовать публично. Или явно упоминать причины по которым сделано отступление от.
Это именно правило хорошего тона, которое можно нарушать, если тому есть причины. Но лучше таки соблюдать, особенно если советовать публично. Или явно упоминать причины по которым сделано отступление от.
Я категорически несогласен с этим правилом. Это правило очень плохого тона. В разных системах или даже в разных версиях одного пакета в рамках одного дистрибутива пути могут различаться. Или же по какой-либо причине системный администратор может сделать свой ifconfig с блекджеком и шахматистками, и этот скрипт не должен ломаться от этого. PATH для этого и нужен. И той строкой я возвращаю справедливость на место :)
Это печально.
Если скрипт предполагается к исполнению в разных системах — можно озаботиться выяснением точного расположения утилит с последующим сохранением полностью определенного имени и вызова через переменную.
В вышеприведенном скрипте, например, получив возможность создать файл с именем logger в каталоге /usr/local/[s]bin с правом на исполнение у кого-то может возникнуть желание поместить туда строку «rm -rf /» или что-то менее очевидное, но не менее неприятное. И гарантировать, что такое невозможно — никак нельзя, если уж мы ориентируемся на «разные системы или даже разные версии одного пакета в рамках одного дистрибутива».
Если скрипт предполагается к исполнению в разных системах — можно озаботиться выяснением точного расположения утилит с последующим сохранением полностью определенного имени и вызова через переменную.
В вышеприведенном скрипте, например, получив возможность создать файл с именем logger в каталоге /usr/local/[s]bin с правом на исполнение у кого-то может возникнуть желание поместить туда строку «rm -rf /» или что-то менее очевидное, но не менее неприятное. И гарантировать, что такое невозможно — никак нельзя, если уж мы ориентируемся на «разные системы или даже разные версии одного пакета в рамках одного дистрибутива».
>системный администратор может сделать свой ifconfig с блекджеком и шахматистками, и этот скрипт не должен ломаться от этого.
скрипты как раз любят ломаться, когда в ифкончиге видят шахматисток вместо того, что ожидали
скрипты как раз любят ломаться, когда в ифкончиге видят шахматисток вместо того, что ожидали
ifconfig — прошлый век, используйте ip.
>раз в полминуты перезаписывают мой /etc/resolv.conf
можно прописать 8.8.8.8 в резолв.конф и запретить его обновление через аттриут immutable
>Теоретически, ifplugd умеет работать и с отключаемыми адаптерами (параметр HOTPLUG_INTERFACES в конфигурационном файле), на практике же мне не удалось заставить его работать, потому это было сделано через udev
попробуйте github.com/realdesktop/ifplug-ng — интерфейсы подхватывает сам, евенты ловятся через 9p.
можно прописать 8.8.8.8 в резолв.конф и запретить его обновление через аттриут immutable
>Теоретически, ifplugd умеет работать и с отключаемыми адаптерами (параметр HOTPLUG_INTERFACES в конфигурационном файле), на практике же мне не удалось заставить его работать, потому это было сделано через udev
попробуйте github.com/realdesktop/ifplug-ng — интерфейсы подхватывает сам, евенты ловятся через 9p.
8.8.8.8 — далеко не единственный NS, с которым мне нужно работать, да и не барское это дело — immutable ставить. Сейчас, правда, я поставил себе resolvconf, а в нём приоритет «ручным» настройкам поставил выше, чем тем, что приходят от DHCP.
За ifplug-ng спасибо. И за 9p спасибо :) Кстати, librbus основана на libixp, так же? А давайте-ка я её опакечу, а? ;)
Только доки на английский пере-/допишите, пожалуйста.
у меня на днях пропала связь до 8.8.8.8, и вообще дальше местного IX.
вот я затрахался dnsы провайдера искать. (NSы prociderdomain.ru не рекурсировали изнутри)
вот я затрахался dnsы провайдера искать. (NSы prociderdomain.ru не рекурсировали изнутри)
Sign up to leave a comment.
Автоконфигурация сетевых интерфейсов в Debian GNU/Linux