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=1.2 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 Date: Wed, 24 Apr 2019 23:24:48 +0200 From: Alexey Gladkov To: make-initrd@lists.altlinux.org Message-ID: <20190424212448.GI9023@dhcp129-178.brq.redhat.com> References: <20190423142655.GB9023@dhcp129-178.brq.redhat.com> <126da50b-d948-b9b9-43c8-35707703ee58@complife.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <126da50b-d948-b9b9-43c8-35707703ee58@complife.ru> Subject: Re: [make-initrd] master updated 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, 24 Apr 2019 21:24:55 -0000 Archived-At: List-Archive: On Wed, Apr 24, 2019 at 06:43:00PM +0200, Michael A. Kangin wrote: > On 04/23/2019 04:26 PM, Alexey Gladkov wrote: > > > * Добавил возможность вызвать скрипт до и после старта сервиса; > yes > > > * Увеличил приоритет nameserver= и теперь они будет попадать в resolv.conf > > первыми; > yes > > > * Я добавил параметр ifname=: (как в dracut) для > > переименования интерфейсов; > yes > > > * Изменил обработку macaddr в ip. Теперь MAC меняется у интерфейса, а не > > переименовывает интерфейс. Это совпадает с поведением в fedora; > > В конфиги попадает, к интерфейсу не применяется. Наверное, та же фигня > что и с MTU > ~:# cat /etc/network/ifaces/eth1/iplink > set address 01:02:01:02:01:ff > set mtu 9000 > ~:# ip li sh dev eth1 > 3: eth1: mtu 1500 qdisc pfifo_fast > qlen 1000 > link/ether 52:54:00:a7:29:23 brd ff:ff:ff:ff:ff:ff Работаю над этим. > И еще пару мыслей о DHCP > В формате ip=dhcp действительно ли ему стоит пытаться поднимать все > интерфейсы, или было бы лучше пробовать по одному? > И если уж все, то лучше одновременно. Так dhcp-клиент вызывается хоть и последовательно, но работают параллельно. Потом опять синхронизируются. > Сейчас, когда дело дойдёт до тестирования в железе, какой-нибудь сервер > о шести 10G сетевушках будет делать ip link up для каждой из них секунд > по 20. > не хотелось бы получить необоснованных задержек при загрузке системы :) В таком случае нельзя говорить ip=dhcp. В этом случае нужно указывать какой интерфейс нужно настраивать. > Кроме того, если скажем сетевушки подключены к одной сети и получают > один и тот же NS, то /etc/resolv.conf может получиться такой вот > кучерявый с дублирующимися серверами: > ~:# cat /etc/resolv.conf > > nameserver 98.158.110.2 > nameserver 98.158.111.2 > # eth0: DHCP4 start > nameserver 192.168.222.1 > # eth0: DHCP4 end > > # eth1: DHCP6 start > nameserver fd00:eeee:0012:0000:0000:0000:0000:0001 > # eth1: DHCP6 end > > # eth2: DHCP4 start > nameserver 192.168.222.1 > # eth2: DHCP4 end > > ~:# cat /proc/cmdline > ip=dhcp nameserver="98.158.110.2 98.158.111.2" debug rdshell > > > И что именно в него попадает при dualstack для каждого интерфейса, v4 > или v6 адрес - дело случая, и разнится от загрузки к загрузке, бывает и > по три 192.168.222.1. Но попадает что-нибудь одно. Как раз сейчас нарвался на такое с resolv.conf. Я это попробую исправить. -- Rgrds, legion