Разработчики Ubuntu сообщили (https://lists.ubuntu.com/archives/ubuntu-devel-announce/2017...) о переводе находящегося в разработке осеннего выпуска дистрибутива (17.10) на использование netplan (https://git.launchpad.net/netplan/tree/doc/netplan.md) для хранения настроек сетевых интерфейсов, вместо ранее применяемого инструментария ifupdown, хранящего настройки в файле /etc/network/interfaces. Netplan обеспечивает хранение параметров в формате YAML и предоставляет бэкенды, абстрагирующие доступ к конфигурации для NetworkManager и systemd-networkd.Переход на Netplan обеспечивает (https://wiki.ubuntu.com/MigratingToNetplan) бесшовно, но пользователям также предоставлена возможность при желании продолжить использование ifupdown ("sudo apt install ifupdown"). В ежедневных сборках Ubuntu Server новая система уже задействована для записи сетевой конфигурации в каталог /etc/netplan. В Ubuntu Desktop простейшая конфигурация netplan уже применяется в NetworkManager, начиная с выпуска 16.10.
Применение netplan унифицирует определение базовых конфигурационных файлов, используемых в NetworkManager и systemd-networkd, избавляя от необходимости изучения деталей форматов конфигурации каждой из этих систем. Суть работы netplan сводится к тому, что в процессе начальной загрузки он читает базовые сетевые настройки из файлов "/{lib,etc,run}/netplan/*.yaml" и записывает конфигурацию в каталог /run в формате, подходящем для дальнейшей обработки сетевыми демонами (по умолчанию конфигурация передаётся systemd-networkd, но опционально поддерживается NetworkManager).
Из особенностей netplan также отмечается: игнорирование устройств, не отмеченных в конфигурации; вся конфигурация хранится только в исходном YAML-файле (без использования /etc/network/interfaces); поддерживается разбиение конфигурации на несколько файлов (например, для выноса настроек libvirt и lxd); гибкие возможности выбора и смены бэкенда. Из поддерживаемых команд отмечаются: "netplan generate" для генерации конфигурации для обработчиков (NetworkManager или systemd-networkd) на основе базовых YAML-настроек; "netplan apply" для применения всех настроек и перезапуска обработчиков;
"netplan ifupdown-migrate" для преобразования старых настроек /etc/network/interfaces в формат netplan.Описание параметров сетевых интерфейсов в netplan осуществляется при помощи декларативного синтаксиса, позволяющего достаточно просто описать структуру сложной сети. Из достоинств netplan по сравнению с ifupdown отмечается декларативный синтаксис; возможность применения масок для имён сетевых интерфейсов, MAC-адресов, драйверов и других компонентов; netplan учитывает контекст при разборе иерархии параметров сетевых интерфейсов, что позволяет корректно и в правильном порядке передать настройки обработчикам (в ifupdown при разборе сложных кофигураций не исключено возникновение проблем, вызванных состоянием гонки).
В случае применения DHCP простейшиая конфигурация netplan будет выглядеть следующим образом:
network:
version: 2
ethernets:
enp3s0:
dhcp4: yesБолее сложный пример:
network:
version: 2ethernets:
id0:
match:
macaddress: 00:11:22:33:44:55
wakeonlan: true
dhcp4: true
addresses:
- 192.168.14.2/24
- 2001:1::1/64
gateway4: 192.168.14.1
gateway6: 2001:1::2
nameservers:
search: [foo.local, bar.local]
addresses: [8.8.8.8]
lom:
match:
driver: ixgbe
set-name: lom1
dhcp6: true
switchports:
match:
name: enp2*
mtu: 1280
wifis:
all-wlans:
match: {}
access-points:
"Joe's home":
password: "s3kr1t"
wlp1s0:
access-points:
"guest":
mode: ap
channel: 11
bridges:
br0:
interfaces: [wlp1s0, switchports]
dhcp4: true
routes:
- to: 0.0.0.0/0
via: 11.0.0.1
metric: 3
URL: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2017...
Новость: http://www.opennet.dev/opennews/art.shtml?num=46751
Ну теперь-то заживём!
> network:
> version: 2
> ethernets:
> enp3s0:
>
> dhcp4: yesЭто офигительно проще и декларативнее чем "iface enp3s0 inet dhcp"
Просто попробуй поадминить что-то, отличное от твоего десктопа.
тут мало админить что-то просто отличное от локалхоста, надо админить множество
Множество локалхостов? Генераторов и распространителей файлов конфигурации полно еще со времен больших машин и людей в белых халатах.Чем конкретно этот формат лучше других для применения в них?
Не пофигу что будет дёргать Ansible?
> В случае применения DHCP простейшиая конфигурация netplan будет выглядеть следующим образом:
> network:
> version: 2
> ethernets:
> enp3s0:
>
> dhcp4: yesАга, это без сомнения проще и многократно декларативней, чем старый сложный императивный(ха-ха три раза) вариант:
iface enp3s0 inet dhcp
На этом преимущества ifupdown всё. закончились.
> На этом преимущества ifupdown всё. закончились.На простоте? Так этого более чем достаточно, родной.
>> На этом преимущества ifupdown всё. закончились.
> На простоте? Так этого более чем достаточно, родной.На простоте в одном конкретном случае.
применяемом в 90% случаев
Если ты вдруг не понял, то данный пример демонстрирует липовость преимуществ этого плана. По крайней мере тех, что указаны в новости. Можешь сам посчитать сколько раз была подчеркнута декларативность при том, что она и в ifupdown является основой. Аналогично с масками, которые в ifupdown тоже пристутсвуют, например:
bridge-ports eth0 regex veth.*
Да мне глубоко на новость плевать. Кто там что написал - это совершенно неважно.
Преимущество заключается в унификации и дополнительном уровне абстракции.
Не уверен, правда, что вы поймёте, о чём речь. Если вы бы понимали, зачем это нужно, вашего комментария бы не существовало.
> Преимущество заключается в унификации и дополнительном уровне абстракции.Все проблемы можно решить через добавление дополнительного слоя абстракции. Все, кроме одной: проблемы чрезмерно большого количества слоёв абстракции.
В данном конкретном случае вы сможете доказать избыточность этой абстрации?
Зачем доказывать? :)
Абстракция с более сложным синтаксисом и потерей функцинала избыточна.
У вас отсутствует фундаментальное понимание принципов абстрагирования.
Мне даже кажется, что вам надо работать сапожником.
Всецело поддерживаю! Нужно как можно больше абстракции! Я художник-абстракционист, я так вижу!
> Зачем доказывать? :)
> Абстракция с более сложным синтаксисом и потерей функцинала избыточна.Большую сложность синтаксиса вы не доказали, а "потеря функционала" - вообще бред. Какой функционал у вас потеряли? L2-норму?
Совершенно случайно забежал сюда по случаю релиза убунты. Что я могу сказать:
1) большая сложность синтаксиса -- это сообщение #2
2) потеря функционала -- это сообщение #40
это не абстракция. это по другому навязывается - overengineering
> это не абстракция. это по другому навязывается - overengineeringВесь так называемый "научно-технический прогресс" - это история непрерывного overengineering-а. Потому что вполне неплохо можно жить и в пещерах, пользуясь только дубинами и палками-копалками (кому такая жизнь не нравится - тот слабак, хипстор и фанбой системды).
>В данном конкретном случае вы сможете доказать избыточность этой абстрации?Я могу. Нужен ли YAML, когда уже все есть? Нет. Значит его можно выкинуть. Отослали ли ребята из netplan патчи в systemd, NM? Нет. Зато они написали конвертор. Нужен ли этот конвертор, равно как и systemd, NM? Нет. Значит их можно выкинуть.
Все что можно выкинуть есть избыточность.
Если уже делать на совесть, то надо переписывать вообще все с нуля. От и до. Честно, с упорством, долго и тщательно все продумавая и вылизывая. Как Кнут, который пилил 20+ лет TeX.
Переписывать что? Ядро? Так не в нем проблема.
Мимо. В данном случае речь не о добавлении слоя, а о ЗАМЕНЕ.PS. YAML лучше хотя бы тем, что это стандартный ML с готовыми парсерами/линтерами для всех ЯП. Короче если не понимаете, то просто смиритесь с тем, что ML со временем существенно потеснят классические лисапеды из /etc.
> PS. YAML лучше хотя бы тем, что это стандартный ML с готовыми
> парсерами/линтерами для всех ЯП. Короче если не понимаете, то просто смиритесь
> с тем, что ML со временем существенно потеснят классические лисапеды из
> /etc.Учитывая, что сейчас большинство etc-ов на продакшенах рулится через ansible, который настраивается на YAML - процесс уже идет, и очень неплохо.
> Да мне глубоко на новость плевать. Кто там что написал - это совершенно неважно.что вы тогда делаете в ее обсуждении?
> Преимущество заключается в унификации и дополнительном уровне абстракции.
По поводу унификации путем добавления еще одного стандарта уже давным давно всё сказано в https://xkcd.com/927/
> По поводу унификации путем добавления еще одного стандарта уже давным давно всё сказано в https://xkcd.com/927/Вам нужно понять разницу между "ещё один инструмент" и "ещё один уровень абстракции". У вас такая же проблема, как и у товарища freechk.
Попробуйте таки внимательно прочитать этот короткий, но поучительный комикс. Там тоже речь не об еще одном инструменте.
Ну, однако, новые удобные программы пишутся, а вы бурлите и негодуете, что ваши старпёрские уродливые поделки, в которых вы сами разбирались 10 лет, вымирают. Просто потому, что у современного человека есть масса более интересных дел, чем разбираться в 100 форматах конфигов для одного и того же.
Но вы всё равно не поймёте: вы либо слишком молоды и своего мнения просто не имеете, либо слишком стары, и ваши мозги похожи на мрамор.
> Но вы всё равно не поймёте: вы либо слишком молоды и своего
> мнения просто не имеете, либо слишком стары, и ваши мозги похожи
> на мрамор.И вообще, мы усе фрём, ага!
Да и правда, куда уж нам до очередных анонимов в белых одеждах, с умным видом и надутыми щеками уже третий комментарий яростно доказывающих что-то свое, анонимное.
Главное правило ведь какое -- dещать обобщенно, без конкретики, чтобы очередному диванному аналитегу не пришлось срочно изображать запланированный прием целебно-грязевой ванны.
> Ну, однако, новые удобные программы пишутся, а вы бурлите и
> негодуете, что ваши старпёрские уродливые поделки, в которых вы сами
> разбирались 10 лет, вымирают.
> ...
> вы либо слишком молоды и своего мнения просто не имеете, либо
> слишком стары, и ваши мозги похожи на мрамор.Вагнер недавно интересную мысль высказал на этот счёт.
"Вот в этом-то и корень принципиального несогласия между защитниками
systemd и его противниками.Противники systemd это люди, которные умеют пользоваться традиционными
coreutils, и ежедневно это делают, решая какие-то свои прикладные
задачи. А вот в логи глядят редко, ну раз в полгода, если раз в месяц,
значит что-то в системе не так и надо менять.Поэтому для них логичным кажется использовать для решения редкой, но,
как правило, срочной задачи тот же инструмент, который они используют
каждый день и хорошо знают.Сторонники systemd это "новое поколение". Которые для решения своих
задач пользуются всякими ide, офисным софтом и прочей неудобоваримой
гуи-хренью. Для них естественно, когда встает новая задача, не пытаться
ее сформулировать на языке привычных инструментов, а искать отдельное
приложение которое умеет ее решать. Пределом этой тендеции служат,
конечно смартфоны, где даже для просмотра большинства крупных сайтов
используется не браузер, а отдельные приложения."PS: ссылку на сообщение, боюсь, не приведу: gmane веб-архив больше не держит, а home.gmane.org так и не взлетел
PPS: сообщение от 2017-06-14 debian-russian@
Который Вагнер?
> Который Вагнер?Витус Вагнер
>> Который Вагнер?
> Витус ВагнерНа редкость вменяемый человек
https://lists.debian.org/debian-russian/2017/06/msg00329.html
Ну и зачем ты притащил сюда его бред? С чего ты и он взяли, что "сторонники systemd ... для решения своих задач пользуются всякими ide, офисным софтом и прочей неудобоваримой гуи-хренью."? С чего вы взяли, что сторонники systemd не умеют пользоваться coreutils?Я вот сторонник systemd. И journald, хоть он и тормозит, собака. И умею пользоваться coreutils, и постоянно ими пользуюсь. И сервера у меня без гуёв. Впрочем как и у большинства компетентных линукс-админов. В не зависимости от их отношения к systemd. Но мне нахрен не впёрлось велосипедить там, где можно взять готовое и работающее. И чтение man-страницы по какому-то новому решению не вызывает у меня острой боли. Вот в наличии этой боли от чтения и есть основное различие между systemd-хэйтерами и systemd-сторонниками.
> Вот в этом-то и корень принципиального несогласия между защитниками systemd и его противниками.Он себе льстит.
На самом деле все проще. Противники systemd в далекой молодости заучили несколько простых команд, и любая прочая информация в их черепушках уже не поместится. Читать маны и пользоваться поиском для них бессмысленно - там много каких-то непонятных букв. "Зачем учиться, ведь я и так мега-супер-админ?"
У сторонников systemd, наоборот, ресурс усвоения новой информации пока не исчерпан, и они могут сравнить доступные инструменты и выбрать наиболее удобный (ни для кого не секрет, что их оппоненты ругают systemd по принципу "не читал, но осуждаю").
> Противники systemd в далекой молодости заучили несколько простых"простых" и тьюринг-полных. ;)
> Читать маны и пользоваться поиском для них бессмысленно - там много каких-то непонятных букв.
Сказали люди, не осилившие shell-скрипты. :)
> У сторонников systemd, наоборот, ресурс усвоения новой информации пока не исчерпанИ это хорошо. Потому что скоро каникулы у них закончатся и надо будет много нового усваивать.
Витус, конечно, слабый авторитет в "IDE не нужен". Вы его программы видели? Как человек, привыкший к тому, что Perl, CGI и Tk -- любимый стек, может быть авторитетом в современной разработке?
> Витус, конечно, слабый авторитет в "IDE не нужен".Особенно если учесть, что он этого не утверждает. :)
> Вы его программы видели?
Вы программы Леннарта видели? :)
> Perl, CGI и Tk
Вы так говорите, как будто это что-то плохое. :)
>> Perl, CGI и Tk
> Вы так говорите, как будто это что-то плохое. :)хотите всю жизнь пользоваться программами на perl-tk и веб-серверами на perl/cgi? (демонический хохот, гроза)
> хотите всю жизнь пользоваться программами на perl-tk и веб-серверами на perl/cgi?Ничего не имею против. Tk хорош, Perl тоже, да и FastCGI под него уже давно завезли.
Всегда смешит, когда сторонники "модного молодежного" демонстрируют устаревшие на 5 и более лет знания в смежных, но все-таки чуть других нишах. А мы "старперы, неспособные к изучению чего-то нового" почему-то о них в курсе.
Проекты на perl cgi массово переписывали на fastcgi и catalyst более 10 лет назад. Где-то 5-7 лет назад основным выбором для вебстека на perl стали plack(аналог rack и wscgi) и dancer/mojolicious. Три года назад CGI.pm выкинули из perl core.
вы витусу это расскажите, я-то в курсе.
>А мы "старперы, неспособные к изучению чего-то нового" почему-то о них в курсе.Именно так. Потому что ты за 10-20 лет так и не понял, что форма изменилась, а камень остался прежним. Mojo все так же как и CGI отдает 500 реквестов в секунду. И Catalyst все так же популярен как и 10 лет назад, глянь вакансии reg.ru и удавись в своем невежестве.
> Mojo все так же как и CGI отдает 500 реквестов в секунду.Может ты его готовить не умеешь? А вот у тех, кто разбирается в вопросе, он более десяти тысяч реквестов в секунду делает, то есть более чем достаточно для его ниши.
>то есть более чем достаточно для его нишиДля какой ниши? Что ты пытаешься втереть? Что надо жить на старых огрызках? Именно так старперы и говорят.
И более того, что ты готовил? Для какой задачи? Или твоя задача это задача, которую решают абсолютно все? Ну-ну.
И вообще, все это сказки псевдо-хайлоадщиков, или как вы себя зовете? Раздавать статику с обновлением раз в минуту это хайлоад. Мда.
>> Mojo все так же как и CGI отдает 500 реквестов в секунду.
> Может ты его готовить не умеешь? А вот у тех, кто разбирается
> в вопросе, он более десяти тысяч реквестов в секунду делает, то
> есть более чем достаточно для его ниши.На, утрись: https://www.techempower.com/benchmarks/
Современная ниша это nodejs или твой шеф не знает за что он платит тебе?
Ну и сколько запросов в секунду делает mojolicious по твоей же ссылке? Или деградация зашла настолько далеко, что числа уже понять не можешь, только на график смотришь?Значение слова "ниша" посмотри в словаре, ты явно его не понимаешь.
>Ну и сколько запросов в секунду делает mojolicious по твоей же ссылке?Столько сколько нужно для _теста_. Еще раз есть задачи, а есть тесты. Так вот, на _моих_ задачах mojo делает 500 реквестов в секунду, а все остальные начинают от 5к. И мои задачи покрывают 80% нужд всех веб-серверов.
Ты сам протестируй, потом балаболь. На мой ответ ты так и не ответил.
s/На мой ответ/На мой вопрос/
а что до смешит -- я лет на 15 младше витуса (т.е. старше половины местных ораторов, кто считает себя по его классификации старпёрами). но также знаком с девелоперами, которые старше витуса и спокойно используют ide с 90-х. не в возрасте дело, а в узколобости и гордости.
>Три года назад CGI.pm выкинули из perl core.И знаешь почему? Потому, что такие модули не должны быть в поставке Perl-core, т.к. за ними нужно следить и мейнтенить. А раз мейнтейнера вменяемого нет -- модуль идет в свалку.
А CGI до сих пор активно используется: https://github.com/bestpractical/rt/blob/stable/lib/RT/Inter...Ну, что ты скажешь старпер? Может тебе пора на пенсию, т.к. ты _действительно_ НИЧЕГО нового не познаешь.
> # Activate the following if running httpd as root (the normal case).да уж, пример современного грамотного cgi-скрипта вы привели знатный.
Бред. Настоящие "папки" знают, что все фигня, а поэтому разбираются во всем. Им что systemd, что sysv по зубам. А спорят какая фигня лучше только нубы.
> Бред. Настоящие "папки" знают, что все фигня, а поэтому разбираются во всем.А ещё я слышал, что у нас маразм, так что не папки, а директории.
> Бред. Настоящие "папки" знают, что все фигня, а поэтому разбираются во всем.
> Им что systemd, что sysv по зубам. А спорят какая фигня
> лучше только нубы.Ваша классификация неполна и требует доработки. Вы не посчитали нубов, написавших новую фигню и "бесспорно" уверенных, что она "лучше".
>> разбирались 10 лет, вымирают.
>> ...
>> вы либо слишком молоды и своего мнения просто не имеете, либо
> Вагнер недавно интересную мысль высказал на этот счёт.
> "Вот в этом-то и корень принципиального несогласия между защитниками
> systemd и его противниками.
> PS: ссылку на сообщение, боюсь, не приведу: gmane веб-архив больше не держит,
> а home.gmane.org так и не взлетел
> PPS: сообщение от 2017-06-14 debian-russian@Какноничекое https://lists.debian.org/debian-russian/2017/06/msg00329.html
таки такие любители "прогресса" и понапридумывали эти 100 форматов
> По поводу унификации путем добавления еще одного стандарта уже давным давно всё сказано в https://xkcd.com/927/Вас послушать - так вообще стандарты отменить надо, вот тогда заживем!
> Преимущество заключается в унификации и дополнительном уровне абстракцииА раньшие уровни абстракции на чём сфейлили, что пришлось ещё один городить?
Вы сможете сами ответить на этот вопрос, если поразмыслите на тему отличий одного инструмента с несколькими бэкендами от нескольких инструментов.
Поразмыслив, могу сказать, что отвёртка со сменными битами выглядит современней, чем несколько отвёрток с разными жалами, но отвёртки с разными жалами можно одну положить, а другую взять, всё делается одной рукой, вторая рука в это время может держать деталь. Для отвёртки со сменными битами приходится задействовать обе руки, чтобы вынуть одну биту и вставить другую.
Ну вообще-то у мебельщиков таки используются и крестовые, и шестигранные головки. Но таки да, никогда нет необходимости закручивать их поочерёдно. Обычно сначала все саморезы закручивают, а потом уже конфирматы.
> Деталей, которые крепятся с одного бока крестовыми шурупами, а с другой "плоскими"Как минимум, размеры шурупов таки могут сильно разниться.
> винтами, например, я лично никогда не видел.Это говорит скорее о том, что у вас очень интересная и альтернативная вселенная. Ну или что вы ничего сложнее авторучки не разбирали.
>> Деталей, которые крепятся с одного бока крестовыми шурупами, а с другой "плоскими"
> Как минимум, размеры шурупов таки могут сильно разниться.В абсолютном большинстве саморезов стараются делать голову PH2/PZ2. Кроме редких случаев, когда саморез очень-очень большой (тогда PZ3) или очень-очень маленький (тогда PH0). PH1 - очень редкий зверь, прочие - еще реже. Если у вас был шуруповерт и вы покупали для него биты, вы это знаете не хуже меня.
Млять крестовой!! КРЕСТОВОЙ, КАРЛ!!!
Филипс он млять, ФИЛИПС!!!!
А еще есть ПОЗИДРАЙВ.А плоская называется ШЛИЦ.
И то что Вы в одном устройстве есть и шлиц и филипс не встречали, не значит что такого нет.
Вот это уровень знания.
> Млять крестовой!! КРЕСТОВОЙ, КАРЛ!!!
> Филипс он млять, ФИЛИПС!!!!
> А еще есть ПОЗИДРАЙВ.
> А плоская называется ШЛИЦ.
> И то что Вы в одном устройстве есть и шлиц и филипс
> не встречали, не значит что такого нет.
> Вот это уровень знания.ПОЗИДРАЙВ -> Позидрив
Еще фриасон есть.
А еще можно сказать "Крестовой шлиц" - Шах и мат, неуч.
> А еще можно сказать "Крестовой шлиц" - Шах и мат, неуч.Тем не менее, работяги шлицом называют именно плоскую отвёртку.
В этимологию русского рабочего языка по-моему лучше вообще не вникать. Мне до сих пор шаблон разрывает, когда я вспоминаю, что настенные светильники они называют плафонами (т.к. plafond -- это вообще-то по-французски "потолок").
> Не знаю, для чего бы тебе потребовалось, заворачивая крестовой шуруп, вдруг поменять
> крестовой бит на плоский или типа того.Да, именно! И вообще, ваш спор бепредметен. Учёные же уже давно доказали, что шуруп, забитый молотком держится гораздо... Гораздо!!111... лучше, чем гвоздь, ввёрнутый отвёрткой.
Раньше видимо сразу ioctl делали :-P
> Преимущество заключается в унификацииУжа с ежом?
> и дополнительном уровне абстракциибольше уровней абстракции богу абстракции! В идеале их должно быть 512. А управление вестись через кнопку "сделать 3.14здато".
> Преимущество заключается в унификации1) /etc/net был уже давно;
2) xkcd про стандарты.
> На этом преимущества ifupdown всё. закончились.А как на счёт зависимостей между интерфейсами? Параметров pre/post-up/down? ;)
Если этого сейчас нет, то будет сделано позже. Или вы всерьёз считаете, что разработчики откажутся от востребованной многими функциональности?
> Если этого сейчас нет, то будет сделано позже. Или вы всерьёз считаете,
> что разработчики откажутся от востребованной многими функциональности?Прежде всего, ими самими. Многие пакеты типа openssh-server и samba активно юзают хуки в /etc/network/if-*.d
> Если этого сейчас нет, то будет сделано позже. Или вы всерьёз считаете,
> что разработчики откажутся от востребованной многими функциональности?Да запросто. Сто раз уже нарывались. :)
К тому же, судить-то надо не по намерениям, а по делам. Вот когда эта функциональность будет, тогда и поговорим.
> К тому же, судить-то надо не по намерениям, а по делам. Вот
> когда эта функциональность будет, тогда и поговорим.Сколько раз за предыдущий год я слышал "Вот когда Маск успешно посадит свою ступень, тогда и поговорим"... :)
Да-да, по этому Коперфильду судебный дознаватель плачет. Конкретно по статье "мошенничество в особо крупном размере". Как посадка на баржу - так трансляция прерывается. Очень удобно.
Ну да, недавно одна из трансляций прервалась в самый ответственный момент. Прервалась аж на несколько секунд. Но есть же трансляции, где всё видно от и до.
https://youtu.be/7TE1o2lFpoU
> Сколько раз за предыдущий год я слышал "Вот когда Маск успешно посадит
> свою ступень, тогда и поговорим"... :)Маск Шаттлворт? ;-)
> Если этого сейчас нет, то будет сделано позже.С помощью еще одного слоя абстракции, непременно. Иначе - не считается.
Главное его преимущество, что конфигурация 10 лет не сбивалась при обновлении.
Ну так для простой конфигурации оно и не особо-то нужно, кто ж говорит...
> Ага, это без сомнения проще и многократно декларативней, чем старый сложный императивный(ха-ха три раза) вариант:Нет, императивщина - это pre-up/up/down/post-down. Правда, как жить без этих костылей - лично я себе не очень представляю.
Да просто в пуризм впадать не надо. Компьютер - штука последовательная, как ни крути, и последовательность операций имеет значение. Когда можно что-то объявить просто и декларативно - хорошо. Когда что-то можно сделать просто и императивно - тоже хорошо. Когда эти два варианта дружат, как в ifupdown - вообще отлично. А вот когда начинаются попытки под верования подогнуть реальность и выходит бессмысленное усложнение или ограничение - тогда всё печально.
Я правильно понимаю, что блоки выделяются табами/пробелами?
http://docs.ansible.com/ansible/YAMLSyntax.html
Изучи, должно снять вопросы.
Пробелами. Количество пробелов на вкус, главное - соблюдать вложенность. Табы в yaml запрещены, парсер yaml, реализованный в соответствии со спецификацией, должен на табы ругаться и прекращать парсинг.Вообще yaml странная штука. Вроде как задуман быть удобным для человека, но по факту как-то не очень. Хотя, несомненно, удобнее для ручной правки, чем json, надмножеством которого yaml является.
> Хотя, несомненно, удобнее для ручной правки, чем jsonА вот это спорно.
Особенно, если ручную правку осуществлять не в "блокноте", а в редакторе, умеющем находить парные скобки, а также пропускать чужой json через форматировщик типа jq. В этом случае из преимуществ остаются разве что комментарии.
Кавычки расставлять лениво очень. Особенно когда копипастишь кусок JS-кода, инициализирующий объект, в какой-нибудь Postman в тело запроса. :)А по большому счету - да, комментарии. Были бы комментарии в json, я бы много где с yaml-ом и не связывался.
> Кавычки расставлять лениво очень.Есть такое дело. Особенно с учетом того, что в js они не обязательны.
> Особенно когда копипастишь кусок JS-кода, инициализирующий объект, в какой-нибудь Postman в тело запроса. :)
Можно открыть консоль в браузере, скопипастить инициализацию js объекта туда, а потом применить к объекту JSON.stringify и получить корректный JSON. Пример:
JSON.stringify({a:5,b:7,c:'12'})
"{"a":5,"b":7,"c":"12"}"
Я все хочу подобное в postman pre-request script засунуть, но все ленюсь.
> Особенно, если ручную правку осуществлять не в "блокноте", а в редакторе, умеющем
> находить парные скобки, а также пропускать чужой json через форматировщик типа
> jq. В этом случае из преимуществ остаются разве что комментарии.Интересно, если бы сабж был не на ямле, а на джейсоне, вы бы его одобрили?
Да. Поклонник си придумал json, поклонник питона ему отомстил. 😄
Крокфорд вроде не был болшим фанатом си
JSON появился из хэш-массивов JavaScript, за основу которых был взят синтаксис словарей из Python. Шах и мат!
Ну выглядит конечно не особо лаконично, но думаю жить можно и с таким. ну и NM перестанет конфликтовать с системным конфигом, может кому это и нужно.
> в ifupdown при разборе сложных конфигураций не исключено возникновение проблем, вызванных состоянием гонкиЭто конечно важная вещь, сталкивался не раз, но нельзя ли было ifupdown допилить??
> нельзя ли было ifupdown допилить?Это не молодежно. Ломать, так ломать.
> Это конечно важная вещь, сталкивался не раз, но нельзя ли было ifupdown допилить??А как? Парсить конфигурации всех интерфейсов в один проход, построить дерево зависимостей между ними и пускать воркеров с учетом этих зависимостей?
Так это парсер переписывать надо. Ну вот они и переписали.
Сетевой стек убунту и ранее вызывал много нареканий. С введением новой системы они, похоже, в конец решили идти microsoft way.
> Сетевой стек убунту и ранее вызывал много нареканий.А чем он отличается от сетевого стека Debian? Или CentOS?
Если не секрет, конечно.
Проиграет конкуренцию systemd-abstract-network-configd от Лёни
Леня ушел пилить casync, больше никаких systemd-everything, похоже, не будет.
> Проиграет конкуренцию systemd-abstract-network-configd от ЛёниПосмотрел, кто основной разработчик. Martin Pitt, бывший сотрудник каноникла и мейнтейнер udev в убунте, ныне - сотрудник редхата, активный разработчик systemd и лучший друг Лени.
Так что, похоже, играют они за одну команду.
> бывший сотрудник канониклаА, это все объясняет. Спустя некоторое время поделка отправится вслед за миром, упссратом, унити и усплешем. Расходимся.
Удобная иерархия - синтаксис джуниперов, всё очень приятно читать глазами. А данный питон-синтаксис очень провоцирует на ошибки.
>> синтаксис джуниперов
> джуниперовtop kek
там из синтаксиса джуников только пробелы
> там из синтаксиса джуников только пробелыПохоже, вы не прочитали комментарий, на который отвечаете.
вообще да, приятно - сходу видно в примере что происходит, вообще без взгляда в документацию. С другой стороны - чтобы писать что-то осмысленное всё равно её освоить придётся, а дальше побоку.Но будь у него pre-up и подобное + бэкэнд для ifupdown - был бы идеал, пожалуй.
Ну-да, давайте в 10 местах хранить настройки сети, чтобы вообще не понимать, где их править. Удобно! И закончится все ifconfig-ом в rc.local
в юните systemd-etcrclocald
Учите матчасть. Оно называется systemd-rc-local-generator.
А нафига абстрагировать доступ к конфигурации для NetworkManager и systemd-networkd?
Примерно затем же, зачем нужен libvirt вместо ковыряния виртуалок напрямую.Чтобы юзер, залезший руками в настройки, а также скрипты-конфигураторы, гуёвые тулзы, тулзы, создающие отчёты о системе и валидаторы могли не парить каждую новую муть отдельно. Правда непонятно зачем они, написав это для ifupdown, зачем-то влепили промежуточную сущность.
Снизу постучали
Это просто еще один слой абстракции.
> Это просто еще один слой абстракции.Нужно много админов, чтобы очищать слои от абстракции.
Ничего проще netctl еще ничего не придумали.
> Ничего проще netctl еще ничего не придумали.Конкурирующий слой абстракции над зюстем-дэ? Нужно. Нужно БООООооольше!!11
народ, расслабьте булки, поиграется и бросит, впервой что ли ?что будет у красношляпных в приоритете на том большинство дистров и будет сидеть, впервой что ль ? =)
а то устроили кипиш с новостью, панимаш =D
> народ, расслабьте булки, поиграется и бросит, впервой что ли ?
> что будет у красношляпных в приоритете на том большинство дистров и будет
> сидеть, впервой что ль ? =)
> а то устроили кипиш с новостью, панимаш =Dглавное чтоб devuan не трогали.
а так-то, да, пофиг, пусть миллионы мух кушают что хотят :)
А можно в 2017-ом УТИЛИТКУ чтобы раз - и присвоил/сохранил статический ip адрес...
nmcli
#>>чтобы раз - и
> ipconfig.exeч0рд, опередил.
> А можно в 2017-ом УТИЛИТКУ чтобы раз - и присвоил/сохранил статический ip адрес...ifconfig :)
ничего проще еще iproute не придумали
Еще один велосипед, почему не назвали netpland?
systemd-netpland же :)
Тогда прошу прощения, пару лет назад на FreeBSD першел, отстал немного от Linux'овых велосипедов.
> на FreeBSD першел, отстал немного от Linux'овых велосипедов.Да, ржавые трёхколёсние велосипеды - на них не разгонишся, неудивительно, что отстал.
Работает на десктопе несколько лет. Установилась без проблем. Один раз под себя настроил и пользуешся. Все работает как швейцарские часы.
Я хотел поставить-посмотреть 11.0 - не поставил. Там инсталлятор как и раньше требует перезапуска, если выбранное для установки зеркало неактивно. Это при том, что явным образом, в сопроводительном тексте предлагается выбрать территориально ближайшее зеркало. При этом, работоспособность зеркала инсталлятором не проверяется. А после перезапуска инсталлятора становится недоступной сеть (тупейший проводной dhcp). Во время работы инсталлятора на экране грязь непонятных сообщений об ошибке сети 0хчто-то-там, которое может перекрывает кнопки и сообщения самого инсталлятора. Всё как было на 9. Очевидно, что качество этой ОС недалеко ушло от её инсталлятора. Я не стал упорствовать в её установке.
> Во время работы инсталлятора на экране грязь непонятных сообщенийТам работать-то толком нечему - разбить диск, распаковать tar, добавить пользователя и пару строчек в fstab и rc.conf. Никакой мистики, все делается штатными утилитами и склеено простыми скриптами. Но отлично характеризует понимание современных лапчатых сути установки )
> Очевидно, что качество этой ОС недалеко ушло от её инсталлятора.
Фееричные выводы очередных анонимных аналитеков.
Хотя упорный поиск тех же самых граблей
> Там инсталлятор как и раньше требует перезапуска, если выбранное для установки зеркало неактивно.
> Всё как было на 9и такое же упорное нежелание использовать офлайнустановщик как бы, намекают.
И правда ведь, зачем использовать набор простых и дубовых, немолодежных установочных sh-скриптов, если есть отличный, модный установщик, в лучших современных традициях комбайнерства на питоне, Qt5, qml, частью кед и размером нетинстала на пару гигзов?
Вся суть FreeBSD - искать на свою задницу трудности, героически их преодолевать, и презрительно отзываться о тех, кто идет более простыми путями.
> Вся суть FreeBSD - искать на свою задницу трудности, героически их преодолевать,
> и презрительно отзываться о тех, кто идет более простыми путями.Вся суть современного лапчатого ньюфага - считать все непохожее на вантуз неудобным и служащим лишь для поднятия ЧСВ.
У тебя бздя вместо мозгов. От слова "бздить".
> У тебя бздя вместо мозгов. От слова "бздить".Быстро ты слился. Хотя о чем это я - нормально потроллить ведь хоть какая-то квалификация и знания матчасти нужны, а не виндусня и копипаста.
Вывод с твоего коммента выше. Есть bcdinstall, который предлагается использовать по-умолчанию в руководстве и на самом установочном диске, но использовать его не нужно/не рекомендуется/не стоит. Есть официальный образ для сетевой установки, но(!) использовать его не нужно/не рекомендуется/не стоит. Это какая-то особая извращенная бздя-философия? А то, типа, не дай бог в нашей маргиналочке случится +1 юзер, который добавит -1 к нашей маргинальной уютности.
> Вся сутьДа вы, ньюфаги, друг друга стоите.
Ты проБЗДел свой мозг.
>почему не назвали netpland?есть-план-же!
А чё не JSON?
жсон слишком простой, вот странно, что не хмль, раз у них регедит и дбас на хмле.
> жсон слишком простой, вот странно, что не хмль, раз у них регедит и дбас на хмле.Как человек, реализовывавший поддержку в своей программе и JSON, и XML, ответственно заявляю - JSON сложнее.
>ответственно заявляю - JSON сложнееЧто, не нашел json-парсер/врайтер? А уж сколько много libxml2 форков-то! Ух. Действительно сложно.
И это с учетом того, что xml предназначен для построения _своих_ конфигов, а json всего-навсего сериализатор с рядом кастраций.
> А чё не JSON?Уже есть - см. /var/lib/openvswitch/conf.db@openvswitch - там тебе и JSON, и БД... :)
>> А чё не JSON?
> Уже есть -
> - там тебе и JSON, и БД... :)...наверное, даже даже Postscript где-то "там" есть?... А PDF? И завершаюшщие штрихи -- .ooxml с .xps.
Видимо, JSON им показался слишком "обыденным" - зачем делать сенсацию на общепринятом? Надо достать из закромов такое, чтобы все сточили лоб в фэйспалмах! Рефал какой-нибудь, brainf*ck, клинопись, древнекитайское письмо... больше безумия, больше экстаза!!
:)
Раз вкорячили везде systemd, то надо systemd-networkd использовать а не городить ещё чтото.
> Раз вкорячили везде systemd, то надо systemd-networkd использовать а не городить ещё чтото.Кому надо - те давно используют. Лично я на простых задачах давно на него перешел.
На ifupdown остались только фееричные костыли, которые лучше не трогать без серьезной причины, типа
iface eth1 inet manual
up /sbin/dhclient -pf /var/run/dhclient.eth1.pid -lf /var/lib/dhcp/dhclient.eth1.leases -cf /etc/dhcp/dhclient.eth1.conf eth1
down /sbin/dhclient -r -pf /var/run/dhclient.eth1.pid -lf /var/lib/dhcp/dhclient.eth1.leases -cf /etc/dhcp/dhclient.eth1.conf eth1(dhclient не умеет в единый конфиг с per-interface sections, хотя в мане это описано).
Но и это рано или поздно перепишу на юниты dhclient@ethX.service
Чего только не сделаешь, лишь бы не писать баг-репорт, да?
Я боюсь, не прилетит ли сия сущность в Debian 10...
Надо добавить ещё условные операторы и функции.
нет, надо перейти на хранение в БД, причем желательно какой-нибудь редкой и неожиданной к применению, Apache Cassandra например мотивируя это тем, что конфиги будут отлично храниться в сети и подставляться на новые машины при замене.
Вместо того чтобы научить нормально читать уже сложившийся формат Поттерингово пoделие создают еще один слой абстракции, из которого странные глюки будут вылавливать еще N лет. И создают кучу работы мантейнерам простых сетевых демонов.
> нет, надо перейти на хранение в БД, причем желательно какой-нибудь редкой
> и неожиданной к применению, Apache Cassandra например мотивируя это
> тем, что конфиги будут отлично храниться в сети
> и подставляться на новые машины при замене.
> Вместо того чтобы научить нормально читать уже сложившийся формат
> Поттерингово пoделие создают еще один слой абстракции, из которого странные
> глюки будут вылавливать еще N лет. И создают
> кучу работы мантейнерам простых сетевых демонов.Для этого надо сделать 2х факторную реализацию -
Сначала поднимается lo интерфейс из /etc/network/interfaces потом стартует распределённая БД, которая ищет свои конфиги по всем распределённым дискам во всех распределённых каталогах, а уже затем, на основе этой информации и разворачивается netplan
план ... такой план...
> Для этого надо сделать 2х факторную реализацию - Сначала поднимается lo интерфейс из /etc/network/interfacesВ дебианах/убунтах - не нужно, там systemd, в котором конфигурирование lo жестко зашито в init и работает даже при отсутствии /etc.
Прикол в том, что сложившийся формат оно читать умеет - "Для миграции на Netplan предусмотрена команда "netplan ifupdown-migrate", которая осуществляет преобразование старых настроек /etc/network/interfaces в формат netplan".выходит, что ifupdown сейчас - идеальный вариант, который можно оставить как есть, а можно из него генерировать конфиги для нежити.
Хотя лично я предпочёл бы именно netplan как базу - на редкость понятная штука вышла, но это если б изначально. а так - преимущества не настолько круты, чтобы стоило перебираться.
> выходит, что ifupdown сейчас - идеальный вариант, который можно оставить как есть,
> а можно из него генерировать конфиги для нежити.Выходит, что разрабы systemd и NM просто послали всех в лес. Почему кто-то должен прогибаться под них? Это Поттеринг должен был запилить нормальный парсер, т.к. это его п0делие, которое ДОЛЖНО поддерживать СУЩЕСТВУЮЩИЙ софт.
Но, нет. Есть идиоты, которые любят подтирать чужие попки.
Оставьте конфиги в покое! Пусть гонками системд занимается, он у нас гонщик.
> Суть работы netplan сводится к
> тому, что в процессе начальной загрузки он читает базовые сетевые настройки
> из файлов "/{lib,etc,run}/netplan/*.yaml"Прекрасная суть. Программа просто что-то читает и пишет конфиг. Но читать она хочет именно в своем формате. Похоже, кто-то просто не осилил парсинг /etc/network/interfaces.
И потом.
Нахуа вообще искать конфиги в /lib/?
И нахуа искать хоть что-то в пустом /run/ в процессе начальной загрузки?
> И потом.
> Нахуа вообще искать конфиги в /lib/?
> И нахуа искать хоть что-то в пустом /run/ в процессе начальной загрузки?Видимо, в дальнейшем конфиги планируют сделать библиотеками. И ставить их из репов.
Суть нормальная, избавляет весь остальной софт от выяснения, какая там хрень за сеть отвечает.Насчёт локейшнов тоже очевидно - довольно часто совсем дефолтную и на рассчитанную на правки юзером часть конфига держать вне /etc (правда обычно всё же в /usr/share), а что /run пуст - совсем не факт, никто ж не говорит, что это первое, что при загрузке запускается. Нормальный вариант для вычитывания части, сгенерированной на лету какими-то другими стартап-скриптами.
Но да, хороший формат конфига не оправдывает возню с миграцией с ненамного худшего.
> Суть нормальная, избавляет весь остальной софт от выяснения, какая там хрень за
> сеть отвечает.Теперь софт будет дополнительно выяснять, отвечает ли за сеть нетплан...
Ну вот убунтовский - не будет. Подозреваю, что редхатовский - тоже. А там - подтянутся.
> Похоже, кто-то просто не осилил парсинг /etc/network/interfaces.Там есть импорт из ifupdown, так что наоборот, демонстративно осилили.
> И потом.
> Нахуа вообще искать конфиги в /lib/?Дистрибутивные предустановки. Например, когда собирается дистрибутив для внутреннего использования в организации, дефолтные сетевые конфиги можно сразу включить в базовую систему.
Или какой-нибудь miredo или vpn, которому хочется добавить конфиг для своих интерфейсов, но неудобно дописывать в interfaces.> И нахуа искать хоть что-то в пустом /run/ в процессе начальной загрузки?
В systemd, например, /run/systemd уж на начальной загрузке содержит динамически сгенерированные юниты (например, точки монтирования из fstab, пускалку rc.local, если он есть, и т.д.).
Здесь может быть аналогично - софт, который имеет свои конфиги, может на их основе динамически конфигурировать netplan. Благо, зависимости при загрузке теперь прописать не проблема.
>> Похоже, кто-то просто не осилил парсинг /etc/network/interfaces.
> Там есть импорт из ifupdown, так что наоборот, демонстративно осилили.Тогда остается непонятным демонстративное создание своего формата.
Такое ощущение, что люди просто не понимают объема работ других людей по переходу на другой формат.
бидонисты будут очень . рады табам и пробелам
> бидонисты будут очень . рады табам и пробеламяМлисты будут ещё больше рады -- табам питонистов!
> хранящего настройки в файле /etc/network/interfacesДанное месторасположениие было слишком очевидным?
> записи сетевой конфигурации в каталог /etc/netplanНу да, так же гораздо лучше!
и + ВНЕЗАПНО из /lib/netplan/.
И заверте...
Программерам понравится, сисадминам нет.
девопсам понравилось ... sed не нужен...
А как соотносится язык отступов с седом? Сед становится неудобен?
Скрипты, которые генерят ямл конфиги.Явно лучше sed/awk
да какбе в yaml не обязательно использовать отступы. смотри:
network: { version: 2, ethernets: { enp3s0: { dhcp4: yes }}}
Им ничего не нравится чему меньше 20 лет, не впервой
Нет, это новичкам не хватает еще опыта, чтобы отличить стоящие вещи из нового от писков моды, о которых забудут через 10 лет. При этом мы можем пользоваться относительно новыми инструментами, о которых живущие хайпом даже не слышали.
Нет, просто некоторые чуют, что их время (точнее, время работы привычными им методами) проходит. Системы растут, и человек там может всё меньше. Можно сказать (очень грубо и не совсем корректно), что "программисты побеждают сисадминов" - чем дальше, чем понятнее, что лезть в продакшн-систему руками не надо вообще. При аварии - надо вывести узел из эксплуатации, добавить чистый и позволить системе смасштабироваться/восстановиться какими-то штатными средствами. При проблемах в конфигурации - нужные правки вносятся в дерево исходников проекта (где скрипты развёртывания и миграции живут наравне с прочим) и деплоятся как обычное обновление. Любые ковыряния - на выведенных из эксплуатации нодах либо на копиях. Сами (микро)сервисы - в докере и подобных, гарантирующих правильное развёртывание, умеют друг друга обнаруживать, обрабатывать отказы и т.д. В этом плане ясно, что перспектива - это не Ansible, а Kubernetes и подобные. В общем, продолжение всё той же тенденции - по максимуму выкинуть из бизнес-процессов человека и воспользоваться этим чтобы делать то, что для человека слишком сложно. Это идеал, конечно, но явно именно в эту сторону процесс идёт.И вот это всё для того, кто привык знать каждый болтик рабочей системы (а не её конфигурации, заданной разработчиком), разумеется, выглядит стрёмно, но для мейнстрима ( а мейнстримом уже явно стали облака и конфигурации из кучи нодов) - это, по факту, единственный логичный путь - выкинуть как можно больше "тайнго знания" из головы сисадмина в формализованный вид в репозитории.
Здесь, в общем, то же самое - вендор пытается всё дать "из коробки" так, чтобы это подходило большинству и минимизировать возню с поддержкой. Учитывая, что ноуты, чёрт бы из взял, победили и всякая динамика в сетях - от вайфая до частого использования виртуалок, контейнеров с бриджами и прочим стала нормой - ifupdown на мейнстрим ну никак не тянет. Нужен какой-то автомат для конфигурации. Раз их есть два и у убунтоидов не хватает ресурсов продавить какой-то один - значит, надо сделать надстройку чтобы не распылять силы на поддержку каждого по отдельности. Собственно, получилось-то у них вполне годное решение этой задачи, и читабельно на редкость и в кои-то веки даже миграцию сделали. Учитывая, что pre-up и подобное один хрен на NM не мапится (или я гоню?) логично, что они это дело не включили - их интересуют только распространённые и хорошо поддерживаемые случаи.
Поклоняюся тебе! Не остави в беде и юнИтах!
> ifupdown на мейнстрим ну никак не тянет. Нужен какой-то автомат для конфигурации.Кстати говоря. ifupdown прекрасно может существовать в качестве бэкенда к какому-нибудь событийно-ориентированному демону. Можно наваять замену NM-у в этом плане: демон следит, скажем, за доступными wifi-сетями, и в случае нахождения запускает поднятие интерфейса через ifupdown. К сервису разумеется приложим небольшую обвязку на Tk, добавим в трей. Надо же как-то противостоять хреновым тенденциям.
Получим инструмент, который не нарушает логику работы ifupdown, как это делает NM (из-за чего он не работает с интерфейсами, перечисленными в network/interfaces).
ifupdown ведь чем хорош: к нему легко добавлять новые бэкенды. Вот был случай, потребовалось мне через vpnc подрубиться к vpn-у. Так я за пару часиков разобрался, как эти самые бэкенды устроены и написал свой собственный, специально для vpnc. Сделать такое для NM в разумные сроки -- вообще невозможно.
Дети, вы такие смешные. Если для вас старые дяди наконец сделали инструменты управления нодами с интерфейсом "для домохозяйки", то это вовсе не значит, что сами дяди не рулили кластерами и тем, что теперь зовут облаками, за много лет до вашего прихода в профессию. Большая часть того, о чем ты сейчас с таким пафосом вещал, я видел более 10 лет назад. Попробуй на досуге прочитать басню "Свинья под дубом", глядишь наведет на кое какие умные, хоть и обидные для самооценки мысли.
По-моему суть тут в том, что они хотят событийно-ориентированный демон, который реагирует на изменения, произошедшие во внешнем мире, модификацией конфигурации сети на машине. Много раз видел эту претензию в самых разных рассылках. Они к тому же, правда, считают ущербным всё, что работает не так, ну да это не так уж и важно, пожалуй. Я к тому, что это некоторое упущение, что пресловутому NM-у нет аналогов.
Кто знает если ли инструмент с абстракцией на их абстракцию, а то не гоже, современному человеку с YAML баловаться.
А меня и так всё устраивало
Лунатик старательно сливает своё единственное прибыльное направление.
вот то-то теперь-то эхом будетъ удобно конфиги править!флагманские дистры скатываются в татальный оверинжиниринг:
конфиги в yaml и json - удобно!!! Забыл двоеточие - падаем, АХ ЗАБЫЛ ЗАПЯТУЮ -смерь!!!
системда с удевами, поверх этого нетпланы с пульсаудио и резолвконфы, и сверху всё это обмазано гномом и флатпаками, осталось это в докер засунуть, чтобы уж точно - если не загрузилось - пепец котёнку, качай новый образ докера у вендора - этот своё отъездил, окошки оно нарисует, а внутрь лучше вообще не заглядывать.
Правильной дорогой идёте, товарищи! Протореной!
з.ы. второй час пытаюсь понять почему у меня убунта 16.10 после обновления только в режиме апстарта грузится, black screen и тишина... так что - да, припекает.
Братья, которые правят конфиги на хосте эхом и не умеют настроить в любимом эдиторе линтер для YAML/json, в ближайшие годы отправятся на биржу труда. Потому что они тупиковая ветвь эволюции.
> Братья, которые правят конфиги на хосте эхомА как еще, если вим только бибикает и все портит?
Дорогой Кеша, в наш век рулит автоматизация соответственно есть 2 случая: Первый - когда сервак упал - туда лезут руками, возможно даже из инитрамфса и настраивать в этот момент "линтер в Едиторе" не самая приоритетная задача, тем более что из программ для работы с текстом там тожет оказаться только cat, sed и echo.Второй случай - самый распространённый - это "автоматизированная установка", где конфиги правят скриптом, чаще всего - написаным слабоумными людьми за миску риса. Как например тут:
https://github.com/Juniper/contrail-provisioning/blob/master...И в этом случае - чем конфиг проще, тем проще мне найти в чём проблема.
И да в моём любимом эдиторе скорее всего не настроить линтеров, т.к. он слишком прост, придётся писать отдельные скрипты для валидации, тянуть зависимости и т.д. и т.п., но опять же - мне это деать придётся после того как всё уже УПАЛО!
> системда с удевами, поверх этого нетпланы с пульсаудио и резолвконфы, и сверху
> всё это обмазано гномом и флатпакамиДа ладно вам. Иногда все же доставляют скриншотики с ноутов молодежных модников, где то пульса, то системда отжрирают по 10% цпу. Зато да - "альса нинужна и устарела, у нас усе работаит на пульсавдио!" )
А OVSBridge можно поднять через этот netplan?
Ну, неплохо. В общем-целом, не вижу изменений в глобальном плане, разве что минус один свой, непохожий ни на что, формат конфигурации чего-то.
Сначала схема предсказуемого именования сетевых интерфейсов - enx78e7d1ea46da
Теперь хранение конфигураций сетевых интерфейсов в YAML.С такими темпами, мы скоро простой конфиг будем на ассемблере и/или js писать :D
> С такими темпами, мы скоро простой конфиг будем на ассемблере и/или js писать :DПисать простые конфиги на тьюринг-полных языках - это юникс-вей, от которого сейчас, наоборот, уходят.
> С такими темпами, мы скоро простой конфиг будем на ассемблере и/или js
> писать :DВы, вероятно, весьма молоды и не в курсе про sendmail.cf на сноболе. Считалось Юникс-веем в 80х, в 90х по просьбам неосиляторов сделали генератор снобола из m4
тьюринг-полный конфиг exim'а себя прекрасно чувствует и поныне. с шлимылом проблема гораздо глубже - его писал пидapас во всех смыслах. И его конфиг это только подтверждает.
>мы скоро простой конфиг будем на
>и/или js писать :DNGinx Inc. предвосхитила ваши желания!
> Братья, которые правят конфиги на хосте эхом и не умеют настроить в любимом эдиторе линтер для YAML/jsonречь скорее идет о всяких автоматизациях, которые используют sed/awk и т.п.
>речь скорее идет о всяких автоматизациях, которые используют sed/awk и т.п.Вообще без разницы чем генерировать конфиги. Задо YAML/JSON жутко неудобно править руками. Даже ini и тот в 100500 раз удобней.
> Вы, вероятно, весьма молоды и не в курсе про sendmail.cf на сноболе.знаком и поэтому я выбрал в свое время удобный конфиг postfix ;) о чем не пожалел ни разу
да чего вы переживаете, будет ещё пара форков из-за очередного велосипеда, например, с netplan и без systemd, без netplan и без systemd и так далее. ведь никому не интересно предоставить выбор компонента в момент установки для хомячков, а кому будет критично - соберут сами как им надо.
убунте лишь бы куда нибудь перейти
лишь бы как ябблу сделать ни как у других, во имя большей несовместимости
опять очередной мозгое этот нетплан. больше делать нечего как учить
новую рень.