From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=HtQJftXe9L/qkDMRlI02RH1fbM8M5Jlw3ylUH7nqJPY=; b=qhYpa4umS60S7IzGdrN7FJzORj1zFRNSUP5/hpmEsfuRQRfXXWeuSNcdhM8MNcThSR Sf1lSlpotvy2WzOKp71QKhBnbf1QcLq5KHDLW9umQ3wdmorSGt0TQ6mXiWTmjH1dQAyA US6zwEZQpHrP3jHOd4b+tpQ0NsI/xmN3lctsC8bk9K/+pgdDg1RqgGfD3sd75YVGr/hj EJpYfgW1K8IxqrXJAtRkiRBaGkzy3pedXdpbvddXLeLyluh6/jwBqu/ZLlH9zDI44Jyp GBVoE6lWlZikNHKd0gavHU1J8wPFzRSN3ez+MFlNDA/eSnz3KwIcKi6Ok31VDdKvKOTh hd3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=HtQJftXe9L/qkDMRlI02RH1fbM8M5Jlw3ylUH7nqJPY=; b=04uM+4j6js5wmWST2t/GRzztdK8fsFE45JdnA4FuHjZhRtGO+at7hj3crvCJ6Q/rDw FgGxMJpRSXsZl7tfUNBiy4CFrzwq+nepK9OWrvEY+hS750y2LqLVMoM++3KqmU6lj25o itylpzwISeMhy/ZYF9NXWZWJZszcOFiY4qqV7DyIMrL6IxWvxIYdNisihkoMb6RTOtX8 +4CcwS1BdGMpY2WxAHcq/rOHgIaYTCy3BCnL79zH1z3KN4nO8ciHgHMjR9chRabFz1Ki wO5AyJ/hHsljwcHdSB4eZA62ydGa5utC+hMI7SxpyMwwRyWuJjLTWgz5KqPd+xw7hbOS mA1g== X-Gm-Message-State: AOAM530BhyjjzL9igNdzm0gMBscfUSF9nCQM3D1bCRvqDlSOJIrbEUmV CXxLhcSOinFSo6Bw9CQHgPQwCZ12gE0= X-Google-Smtp-Source: ABdhPJxOF20PhWlgxmhmzvUXLXoiyePbZT5wztAHoBes+c/E5AFC3hUbRpv8EGYqtEUjJMXMXYkrgQ== X-Received: by 2002:a05:6512:3a83:: with SMTP id q3mr374696lfu.215.1632327127266; Wed, 22 Sep 2021 09:12:07 -0700 (PDT) To: make-initrd@lists.altlinux.org References: <20210917220845.s4dgl2hqla7yt4pe@example.org> <5815442b-e5a1-7469-b705-24090749e245@gmail.com> <20210922100901.e5dsw554g6elb3lx@example.org> <52f4526d-7fa7-e0ed-6d2d-12e06f20408c@gmail.com> <20210922114132.yaobsgcz7vrkjgbq@example.org> <8d262440-d8fc-c174-3293-1964e3440617@gmail.com> <20210922130839.b4iwv2arqyggczb3@example.org> <20210922144619.3h4va7j4u6m36mka@example.org> From: Leonid Krivoshein Message-ID: Date: Wed, 22 Sep 2021 19:12:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20210922144619.3h4va7j4u6m36mka@example.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru Subject: Re: [make-initrd] =?utf-8?b?dWRoY3BjIHNjcmlwdCDQsiDRhNC40YfQtSBuZXR3?= =?utf-8?q?ork?= X-BeenThere: make-initrd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: make-initrd@lists.altlinux.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2021 16:13:41 -0000 Archived-At: List-Archive: 22.09.2021 17:46, Alexey Gladkov пишет: > On Wed, Sep 22, 2021 at 04:50:57PM +0300, Leonid Krivoshein wrote: >> 22.09.2021 16:08, Alexey Gladkov пишет: >>> [...] >>> Это довольно смелое предположение что когда тебя не просят конфигурировать >>> сеть, то на самом деле пользователь хотел dhcp ... да ещё и ipv4. >> [...] Главная подоплёка в том, >> что если сетевых настроек нет, хорошо бы их спрашивать. Ну, потому что без >> сети с выбранным методом иначе не загрузиться. Сейчас код более простой. >> Возможно, тут стоит выводить диалоги. Но вопрос в последующем применении >> новых настроек. > Весь вот этот автоугадав и домысливание должно происходить после сервиса > cmdline. Или же даже проще - до сервиса udev. В этом случае вся > конфигурация будет готова и не будет никаких гонок. > > Вообще почти все диалоги с уточнением конфигурации должны быть тут т.е. до > udevd и pipelined. Сначала ужаснулся от мысли о необходимости разделения bootchain на две части -- диалоговую для выяснения конфигурации и ту, что работает сейчас после udev. Конечно, нет ничего невозможного, так работают многие инсталляторы, сначала задавая вопросы, а потом выполняют действия по уже подготовленным ответам. Но... не получится! Так как есть диалоги, которые предлагают выбор определённого оборудования, а для его определения нужен udev. И ещё мы можем всегда вернутся в самое начало. Плюс те диалоги, когда в процессе выполнения что-то пошло не так, тут тоже могут быть варианты. Немыслимо организовать связку между этими двумя частями, когда посредине будет запуск udev. Поэтому я бы предпочёл не менять нынешнюю конструкцию, конфигурировать в диалогах после запуска udev то, что не было сконфигурировано в командой строке, на худой конец, прибегать к технике повторного сканирования, реализованной в пропагаторе. И пусть параллельно с этим отрабатывают эвенты udev. >> Для altboot пока что не имеет значения, что make-initrd умеет работать с >> IPv6. В нём просто нет пока его поддержки, как и в пропагаторе. Если >> указывать ip=dhcp, сеть поднимается дольше. Поддержку IPv6 можно будет >> добавить позже... > Я считаю, что в 2021 уже не нужно говорить о поддержке IPv6 в новом коде. > Нужно просто считать, что он есть. > > Для того чтобы в пустую не ждать есть функции ipv4_enabled/ipv6_enabled. > Кстати, IPv4 в современном мире может быть выключен и это стоит учитывать. Это очень правильное замечание, я даже и не сомневался, что это так. Мало того, я уверен, что добавить поддержку IPv6 в altboot до безобразия просто. Но лично я мало что понимаю в IPv6, так что если кто-то поможет заменить вызовы resolve на resolve6 и ss в паре мест, буду признателен. Так, конечно, основная поддержка сети IPv6 уже есть в самом make-initrd и грех её не использовать. И основное тут даже не код, а тестирование -- я это не смогу проверить как следует. > [...] >>> /lib/initrd/cmdline.d/network должен выполняться лишь один раз до всего >>> это этого subshell. Он генерирует конфигурацию для всех интерфейсов. >> Но он уже один раз выполнился до входа в bootchain-waitnet, при этом был >> сконфигурирован только "lo". > lo всегда есть. Он даже не конфигурируется: > > features/network/data/etc/network/ifaces/lo/ipv4address > > Зоркий глаз может заметить, что формат конфигов очень похож на etcnet ;) Да, я заметил, как и разницу. Мне показалось странным, зачем при авто-конфигурировании сохранять не полученные значения, а некие строки типа "nameserver " или "defult via ", ведь их же потом неудобно будет парсить. Но видимо так задумано, чтобы читать потом всю конфигурацию в едином формате. Если сравнивать фичу network с etcnet из stage2, то у меня возникает два недоумения... )) 1. Зачем такой навороченный network в stage1? Ведь для сетевой загрузки нужен только один интерфейс. 2. С другой стороны, etcnet умеет vlan'ы, bond'ы и много чего, а network сейчас непригоден для загрузки через такое, а значит придётся менять конфигурацию на свичах или использовать отдельную сеть только для сетевой загрузки. >>> Перед этим стоит остановить udev А как это правильнее сделать? И не лучше ли тогда, не останавливая udev, заставить его перечитать правила? >>> поскольку cmdline.d/network дописывает >>> /etc/udev/rules.d/60-persistent-net.rules и я вообще сомневаюсь, что там >>> всё правильно. Скорее всего нужно переделывать работу с >>> 60-persistent-net.rules, чтобы можно было запускать cmdline.d/network >>> несколько раз. Насчёт этого я думаю, что можно вообще не беспокоиться, т.к. если IFNAME был синтаксически правильно определён в /proc/cmdline и udev-правило уже отработало один раз, то интерфейс с нужным именем уже появился и повторная обработка IFNAME не требуется, диалогов для этого не предполагается. >> [...] >> 2) IFNAME -- должен отрабатывать один раз, конечно, поэтому мне жалко >> удалять всю конфигурацию. :-) ...а значит и удаление всей конфигурации не должно отрицательно сказаться на повторном конфигурировании, которое не предусматривает диалогового аналога IFNAME=..., либо я чего-то не учитываю? >>> Также перед запуском cmdline.d/network нужно удалить старую конфигурацию! >> А как это правильно сделать? rm -rf -- "$net_autoconfdir" "$net_statedir" ? > cmdline.d/network кладёт всё сюда: > > "$net_confdir/ifaces/$interface" > "$net_confdir/default" > > net_autoconfdir -- это место, куда кладут конфигурацию dhcp. Они отделены > от системной конфигурации, чтобы они не смешивались. В некоторых случаях > это нужно. > > Для каждого интерфейса параметры могут приехать из: > > net_autoconfdir/ifaces/$NET_IF/* > net_confdir/ifaces/$NET_IF/* > net_confdir/default/* > > net_statedir -- это результат объединения всех. Это стейт. > > Наверно, стоит написать отдельную функцию, чтобы "забыть" конфигурацию > интерфейса. Тогда уж лучше научить cmdline.d/network повторно конфигурировать все интерфейсы, чтобы он сам удалял то, что было раньше. :-) > [...] >> но я не рискнул писать развесистую логику, а решил использовать >> готовую фичу. При этом возникает риск гонок: самое начало загрузки, модуль >> сетевой карты мог ещё не подгрузиться, сеть заранее никто не >> сконфигурировал, а тут я пытаюсь что-то перезапускать... > Гонки с загрузкой модулей неприятные, да. Тут может быть такая эвристика: > мы догадались, что нужна сеть, ни одного интерфейса нет (кроме lo)? значит > ждём появления сетевого интерфейса. > > Будет другая проблема если интерфейсы будут появляться сильно не сразу, но > это уже следующая проблема. Потому я и пытаюсь пристроиться к имеющейся фиче network очень аккуратно. Следом за приведённым фрагментом идёт код, который просто ждёт появления хоть какого-то реального интерфейса. В финальном же варианте идеал мне видится таким: конфигурирование сети через диалоги, если определённая конфигурация не даёт полного представления о единственном сетевом интерфейсе. В ранних исталляторах (не альтовых) я видел, что до диалогов настройки сети предпринимаются попытки сконфигурировать сеть по DHCP. Не уверен, что это плохая идея, потому что лишние диалоги на этапе загрузки -- зло, а когда ещё не работает мышь/клавиатура -- даже вредительство. :-) >> Если удастся найти рабочий вариант с диалогами настройки сети "вдогонку", у >> нас снимется много вопросов о том, как интегрировать bootchain/interactive с >> уже имеющимися фичами make-initrd. Будет хороший пример, как это можно >> сделать. > То есть ты предлагаешь мне сделать диалоги для конфигурирования сети ? (я > не против). Нет, наоборот, диалоги же как раз по моей части: https://lists.altlinux.org/pipermail/devel/2018-April/204192.html :-) -- Best regards, Leonid Krivoshein.