* [make-initrd] master updated @ 2019-04-26 12:35 Alexey Gladkov 2019-04-29 11:02 ` Michael A. Kangin 0 siblings, 1 reply; 13+ messages in thread From: Alexey Gladkov @ 2019-04-26 12:35 UTC (permalink / raw) To: make-initrd Привет! Я обновил master. * Вернул из make-initrd-1x возможность запустить скрипты до и после сервисов. * Вернул потерянную возможность вызвать скрипт перед предзагружаемыми модулями. * DHCPv6-клиент учитывает ipv6.disable и ipv6.disable_ipv6 и не пытается запуститься. * Линк и маршруты настраиваются. * В resolv.conf только уникальные значения. * В route= имя интерфейса обязательно. * Добавлен ifname= параметр для переименования интерфейсов. -- Rgrds, legion ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated 2019-04-26 12:35 [make-initrd] master updated Alexey Gladkov @ 2019-04-29 11:02 ` Michael A. Kangin 2019-04-29 12:18 ` Alexey Gladkov 0 siblings, 1 reply; 13+ messages in thread From: Michael A. Kangin @ 2019-04-29 11:02 UTC (permalink / raw) To: make-initrd On 04/26/2019 02:35 PM, Alexey Gladkov wrote: > Я обновил master. Замечательно! Всё прям работает, даже почти не придраться :) > > * Вернул из make-initrd-1x возможность запустить скрипты до и после > сервисов. Хотел уточнить: > Скрипты из директории /lib/initrd/all вызываются перед и после каждого > сервиса. > Все скрипты вызываются с аргументами {start|stop} <servicename> [retcode] Из этой директории, насколько я понял, они вызываются перед стартом каждого сервиса, и непосредственно после старта сервиса, и во втором случае им еще передаётся третьим параметром retcode. Я правильно понял? Вызываются ли они (из /all/ ) еще при остановке сервисов? (я не знаю как протестировать сценарий остановки сервисов, если просто сказать /etc/init.d/service stop, этого недостаточно). > * В route= имя интерфейса обязательно. Насколько я понял, сейчас все три параметра обязательно? сеть, шлюз, интерфейс. Когда я пытаюсь нарисовать link-маршрут route=172.16.0.0/12::eth2, он не применяется. > Изменил обработку macaddr в ip. Теперь MAC меняется у интерфейса, а не > переименовывает интерфейс. Это совпадает с поведением в fedora; Но запрос на DHCP приходит со старого мака. И адрес выдаётся соответственно для старого. Интересно будет посмотреть событие обновление лизы, как бы посреди работы новый IP не схватила. > > Если считать, что утилита nfsroot работает, то используя фичу nfsroot ты > получишь просто корень по NFS. Вот интересно, с этими последними релизами из master она хоть запускаться пытается (при указании заклинания root=/dev/nfs, кстати зачем, nfsroot не хватило бы?) Но таки не работает, ошибки из логов: /var/log/ueventd.log:[2019-04-29 10:54:53] uevent-handler: Running nfsroot handler ... /var/log/ueventd.log:/lib/uevent/handlers/040-nfsroot: line 7: /tmp/net-eth1.conf: No such file or directory /var/log/ueventd.log:[2019-04-29 10:54:53] uevent-handler: Event handler failed: nfsroot И напоминаю, фича dropbear тоже сломана, сислога хочет. -- Michael A. Kangin ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated 2019-04-29 11:02 ` Michael A. Kangin @ 2019-04-29 12:18 ` Alexey Gladkov 2019-04-29 14:37 ` Michael A. Kangin 0 siblings, 1 reply; 13+ messages in thread From: Alexey Gladkov @ 2019-04-29 12:18 UTC (permalink / raw) To: make-initrd On Mon, Apr 29, 2019 at 01:02:36PM +0200, Michael A. Kangin wrote: > On 04/26/2019 02:35 PM, Alexey Gladkov wrote: > > > Я обновил master. > > Замечательно! Всё прям работает, даже почти не придраться :) За это нужно вас всех в этой рассылке благодарить )) > > * Вернул из make-initrd-1x возможность запустить скрипты до и после > > сервисов. > > Хотел уточнить: > > Скрипты из директории /lib/initrd/all вызываются перед и после каждого > > сервиса. > > Все скрипты вызываются с аргументами {start|stop} <servicename> [retcode] > > Из этой директории, насколько я понял, они вызываются перед стартом > каждого сервиса, и непосредственно после старта сервиса, и во втором > случае им еще передаётся третьим параметром retcode. Я правильно понял? Именно. > Вызываются ли они (из /all/ ) еще при остановке сервисов? (я не знаю как > протестировать сценарий остановки сервисов, если просто сказать > /etc/init.d/service stop, этого недостаточно). Для остановки сервисов тоже вызываются. Для этого там первый параметр {start|stop} передаётся. Чтобы это проверить дайте начать загрузиться реальной системе. Когда корень найден, то система переходит на runlevel 2 и сервисы останавливаются. > > * В route= имя интерфейса обязательно. > > Насколько я понял, сейчас все три параметра обязательно? сеть, шлюз, > интерфейс. > Когда я пытаюсь нарисовать link-маршрут route=172.16.0.0/12::eth2, он не > применяется. В логах что-нибудь есть ? ip-route выполняется ? Я посмотрю. > > Изменил обработку macaddr в ip. Теперь MAC меняется у интерфейса, а не > > переименовывает интерфейс. Это совпадает с поведением в fedora; > > Но запрос на DHCP приходит со старого мака. И адрес выдаётся > соответственно для старого. Интересно будет посмотреть событие > обновление лизы, как бы посреди работы новый IP не схватила. Хм. Это правда. В случае, когда меняется и mac и используется dhcp, то mac будет изменён после работы dhcp. Это же касается mtu. Собственно все параметры будут применяться после dhcp. Нужно подумать. > > Если считать, что утилита nfsroot работает, то используя фичу nfsroot ты > > получишь просто корень по NFS. > > Вот интересно, с этими последними релизами из master она хоть > запускаться пытается (при указании заклинания root=/dev/nfs, кстати > зачем, nfsroot не хватило бы?) root=/dev/nfs это не моё изобретение: https://github.com/torvalds/linux/blob/master/Documentation/filesystems/nfs/nfsroot.txt#L46 > Но таки не работает, ошибки из логов: > /var/log/ueventd.log:[2019-04-29 10:54:53] uevent-handler: Running > nfsroot handler ... > /var/log/ueventd.log:/lib/uevent/handlers/040-nfsroot: line 7: > /tmp/net-eth1.conf: No such file or directory > /var/log/ueventd.log:[2019-04-29 10:54:53] uevent-handler: Event handler > failed: nfsroot Да, я помню. Эту нужно чинить и писать новую nfs. > И напоминаю, фича dropbear тоже сломана, сислога хочет. Угу. Видимо добавлю из busybox, хотя не очень хочется. -- Rgrds, legion ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated 2019-04-29 12:18 ` Alexey Gladkov @ 2019-04-29 14:37 ` Michael A. Kangin 2019-04-29 14:49 ` Alexey Gladkov 0 siblings, 1 reply; 13+ messages in thread From: Michael A. Kangin @ 2019-04-29 14:37 UTC (permalink / raw) To: make-initrd On 04/29/2019 02:18 PM, Alexey Gladkov wrote: > В логах что-нибудь есть ? ip-route выполняется ? [2019-04-29 13:47:36] 040-network: eth1: process event: network.route.update [2019-04-29 13:47:36] route: eth1: run: ip -4 route append default via 192.168.222.1 [2019-04-29 13:47:36] route: eth1: run: ip -4 route append 172.16.0.0/12 ip: RTNETLINK answers: No such device [2019-04-29 13:47:36] route: eth1: create event: network.route.update -> network.route.updated /.initrd/initenv:export CMDLINE="ip=192.168.222.25::192.168.222.1:25:myhost:eth1:none route=172.16.0.0/12::eth1 nameserver=98.158.111.2 nameserver=[fd00:eeee:2::1] debug rd-depmod=y rdshell rootdelay=5" /.initrd/initenv:export ROUTE0="172.16.0.0/12::eth1" /.initrd/initenv:export route="172.16.0.0/12::eth1" /.initrd/kernenv:route="172.16.0.0/12::eth1" кстати: еще в логах постоянно мелькает такая запись: [2019-04-29 14:22:27] addr: lo: run: ip -4 address add dev lo 127.0.0.1/8 ip: RTNETLINK answers: File exists вроде вреда особого нету... еще кстати: If you are here that something went wrong. If so, it's important to remember: ... - /var/log/uevent.log -- contains log of the execution of handlers. Он /var/log/uevent*d*.log - /var/log/udhcp{4|6}.<iface>.log -- contains DHCP logs. Оне /var/log/udhcp*с*... > root=/dev/nfs это не моё изобретение: > https://github.com/torvalds/linux/blob/master/Documentation/filesystems/nfs/nfsroot.txt#L46 Я просто задумался, если NFS (и другие фичи) рассматривать и как транспорт, то чей root= в итоге будет. Ну да ладно, у вас там свои идеи наверное есть :) >> И напоминаю, фича dropbear тоже сломана, сислога хочет. > Угу. Видимо добавлю из busybox, хотя не очень хочется. В принципе, сам dropbear прекрасно сейчас и без него работает (из дополнительного debug.cpio) Если закомментить упоминания syslog: features/dropbear/data/etc/rc.d/init.d/dropbear: -# Required-Start: $syslog localnet +# Required-Start: udev features/dropbear/rules.mk: -$(call require,syslog) то initrd собирается, dropbear упаковывается нормально, в рантайме запускается, host-ключи генерит. Впрочем, для того, чтобы действительно приконнектиться, нужно еще решить вопрос с ключом или паролем для root, а так же монтировать в рантайме /dev/pts Вот тогда действительно коннектится :) мне кажется, при сборке стоит подумать о вопросах: - добавления паблик-ключа в /home/root/.ssh/authorized_keys - возможность класть свои host-ключи (сейчас они генерятся каждый раз заново при старте системы, не вижу в этом большого профита, только с known_hosts лишняя возня) - как класть дропбировский scp ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated 2019-04-29 14:37 ` Michael A. Kangin @ 2019-04-29 14:49 ` Alexey Gladkov 2019-04-29 15:39 ` Michael A. Kangin 0 siblings, 1 reply; 13+ messages in thread From: Alexey Gladkov @ 2019-04-29 14:49 UTC (permalink / raw) To: make-initrd On Mon, Apr 29, 2019 at 04:37:58PM +0200, Michael A. Kangin wrote: > On 04/29/2019 02:18 PM, Alexey Gladkov wrote: > > > В логах что-нибудь есть ? ip-route выполняется ? > > [2019-04-29 13:47:36] 040-network: eth1: process event: network.route.update > [2019-04-29 13:47:36] route: eth1: run: ip -4 route append default via > 192.168.222.1 > [2019-04-29 13:47:36] route: eth1: run: ip -4 route append 172.16.0.0/12 > ip: RTNETLINK answers: No such device Спасибо. Так яснее. > [2019-04-29 13:47:36] route: eth1: create event: network.route.update -> > network.route.updated > > /.initrd/initenv:export > CMDLINE="ip=192.168.222.25::192.168.222.1:25:myhost:eth1:none > route=172.16.0.0/12::eth1 nameserver=98.158.111.2 > nameserver=[fd00:eeee:2::1] debug rd-depmod=y rdshell rootdelay=5" > /.initrd/initenv:export ROUTE0="172.16.0.0/12::eth1" > /.initrd/initenv:export route="172.16.0.0/12::eth1" > /.initrd/kernenv:route="172.16.0.0/12::eth1" Спасибо. Проверю. > кстати: еще в логах постоянно мелькает такая запись: > [2019-04-29 14:22:27] addr: lo: run: ip -4 address add dev lo 127.0.0.1/8 > ip: RTNETLINK answers: File exists Я видел. Да, это не страшно. > еще кстати: > If you are here that something went wrong. If so, it's important to > remember: > ... > - /var/log/uevent.log -- contains log of the execution of handlers. > > Он /var/log/uevent*d*.log > Исправлю. > - /var/log/udhcp{4|6}.<iface>.log -- contains DHCP logs. > > Оне /var/log/udhcp*с*... А это вообще нужно придумать как вынести в фичу. > > root=/dev/nfs это не моё изобретение: > > https://github.com/torvalds/linux/blob/master/Documentation/filesystems/nfs/nfsroot.txt#L46 > > Я просто задумался, если NFS (и другие фичи) рассматривать и как > транспорт, то чей root= в итоге будет. Ну да ладно, у вас там свои идеи > наверное есть :) В каком смысле чей будет ? > >> И напоминаю, фича dropbear тоже сломана, сислога хочет. > > Угу. Видимо добавлю из busybox, хотя не очень хочется. > > В принципе, сам dropbear прекрасно сейчас и без него работает (из > дополнительного debug.cpio) > > Если закомментить упоминания syslog: А куда у тебя логи идут в этом случае ? > Впрочем, для того, чтобы действительно приконнектиться, нужно еще решить > вопрос с ключом или паролем для root, а так же монтировать в рантайме > /dev/pts В сервисе dropbear нужно проверять и монтировать его. > мне кажется, при сборке стоит подумать о вопросах: > - добавления паблик-ключа в /home/root/.ssh/authorized_keys Хорошая мысль. > - возможность класть свои host-ключи (сейчас они генерятся каждый раз > заново при старте системы, не вижу в этом большого профита, только с > known_hosts лишняя возня) Угу > - как класть дропбировский scp Можно. -- Rgrds, legion ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated 2019-04-29 14:49 ` Alexey Gladkov @ 2019-04-29 15:39 ` Michael A. Kangin 2019-04-29 15:53 ` Leonid Krivoshein 2019-04-29 16:26 ` Alexey Gladkov 0 siblings, 2 replies; 13+ messages in thread From: Michael A. Kangin @ 2019-04-29 15:39 UTC (permalink / raw) To: make-initrd On 04/29/2019 04:49 PM, Alexey Gladkov wrote: >>> root=/dev/nfs это не моё изобретение: >>> https://github.com/torvalds/linux/blob/master/Documentation/filesystems/nfs/nfsroot.txt#L46 >> >> Я просто задумался, если NFS (и другие фичи) рассматривать и как >> транспорт, то чей root= в итоге будет. Ну да ладно, у вас там свои идеи >> наверное есть :) > > В каком смысле чей будет ? Мм, мне трудновато с непривычки выразиться корректно и понятно :) Я имею ввиду, когда несколько фич могут быть самодостаточными, а могут и использовать друг-друга в качестве промежуточного транспорта - как они договорятся, которая из них будет обрабатывать параметр root=? Ну вот допустим есть некая фича "squash-boot", которая использует nfsroot как транспорт. Мы говорим root=/dev/nfs, чтобы у нас nfs вообще заработало. Тогда этой squash-boot мы должны дать какой-то другой параметр вместо root= ? Хорошо, допустим мы ей будем давать squash-root= А в ситуации, когда "squash-boot" будет пользоваться как транспортом http или iSCSI - мы вообще без root= останемся? Или разделить нынешнюю nfsroot на транспортную фичу, которая будет хотеть nfsroot= и непосредственно монтировочную (как бы назвать такую финальную фичу - которая предоставляет подготовленный /root), которая будет активироваться root=/dev/nfs? т.е. например если мы скажем nfsroot=192.168.0.1:/nfsshare/mysystem root=/dev/nfs то, как сейчас, 192.168.0.1:/nfsshare/mysystem смонтируется на /root а если nfsroot=192.168.0.1:/nfsshare/images root=nfs:/image1.squash тогда 192.168.0.1:/nfsshare/images должно быть смонтировано куда-то не в /root, а дальше пусть разбирается "squash-boot" со своим параметром root=, который она поймёт как процессить Кстати, в каком объёме нужна будет поддержка NFS? tcp/udp? v. 3 / 4? kerberos? >> Если закомментить упоминания syslog: > А куда у тебя логи идут в этом случае ? Чьи, самого дропбира? Пока вникуда. Да они вроде и не нужны особенно.. Cейчас с сетью, мне кажется нужно думать за ремотные сислоги. Вот, говорят, busybox'ный syslog вроде как умеет отсылать: https://developer.ridgerun.com/wiki/index.php/How_to_Configure_Remote_Syslog_Logging И у меня есть смутная идея - возможно удалось бы экспортировать по сети /dev/log какой-нибудь хитрой магией netcat/socat ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated 2019-04-29 15:39 ` Michael A. Kangin @ 2019-04-29 15:53 ` Leonid Krivoshein 2019-04-29 21:08 ` Alexey Gladkov 2019-04-29 16:26 ` Alexey Gladkov 1 sibling, 1 reply; 13+ messages in thread From: Leonid Krivoshein @ 2019-04-29 15:53 UTC (permalink / raw) To: make-initrd 29.04.2019 18:39, Michael A. Kangin пишет: > On 04/29/2019 04:49 PM, Alexey Gladkov wrote: > >>>> root=/dev/nfs это не моё изобретение: >>>> https://github.com/torvalds/linux/blob/master/Documentation/filesystems/nfs/nfsroot.txt#L46 >>>> >>> >>> Я просто задумался, если NFS (и другие фичи) рассматривать и как >>> транспорт, то чей root= в итоге будет. Ну да ладно, у вас там свои идеи >>> наверное есть :) >> >> В каком смысле чей будет ? > > Мм, мне трудновато с непривычки выразиться корректно и понятно :) > > Я имею ввиду, когда несколько фич могут быть самодостаточными, а могут > и использовать друг-друга в качестве промежуточного транспорта - как > они договорятся, которая из них будет обрабатывать параметр root=? > По цепочке все фичи парсят /proc/cmdline, в результате что-то оказывается в глобальной $INITRD_ROOT. Видимо, кто первый, тот и транспорт, и так каждый следующий. А кто последний, тот и root. > > Ну вот допустим есть некая фича "squash-boot", которая использует > nfsroot как транспорт. Мы говорим root=/dev/nfs, чтобы у нас nfs > вообще заработало. Тогда этой squash-boot мы должны дать какой-то > другой параметр вместо root= ? > > Хорошо, допустим мы ей будем давать squash-root= > А в ситуации, когда "squash-boot" будет пользоваться как транспортом > http или iSCSI - мы вообще без root= останемся? > > > Или разделить нынешнюю nfsroot на транспортную фичу, которая будет > хотеть nfsroot= и непосредственно монтировочную (как бы назвать такую > финальную фичу - которая предоставляет подготовленный /root), которая > будет активироваться root=/dev/nfs? > > т.е. например если мы скажем > nfsroot=192.168.0.1:/nfsshare/mysystem root=/dev/nfs > то, как сейчас, 192.168.0.1:/nfsshare/mysystem смонтируется на /root > Кажется излишним такой синтаксис. > а если > nfsroot=192.168.0.1:/nfsshare/images root=nfs:/image1.squash > тогда 192.168.0.1:/nfsshare/images должно быть смонтировано куда-то не > в /root, а дальше пусть разбирается "squash-boot" со своим параметром > root=, который она поймёт как процессить > И такой тоже. Что-то вроде этого напрашивается: root=nfs:server:/nfsshare/images;squash:livecd > > Кстати, в каком объёме нужна будет поддержка NFS? > tcp/udp? v. 3 / 4? kerberos? > > > >>> Если закомментить упоминания syslog: >> А куда у тебя логи идут в этом случае ? > > Чьи, самого дропбира? Пока вникуда. Да они вроде и не нужны особенно.. > Cейчас с сетью, мне кажется нужно думать за ремотные сислоги. > > Вот, говорят, busybox'ный syslog вроде как умеет отсылать: > https://developer.ridgerun.com/wiki/index.php/How_to_Configure_Remote_Syslog_Logging > > > И у меня есть смутная идея - возможно удалось бы экспортировать по > сети /dev/log какой-нибудь хитрой магией netcat/socat > -- Best regards, Leonid Krivoshein. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated 2019-04-29 15:53 ` Leonid Krivoshein @ 2019-04-29 21:08 ` Alexey Gladkov 0 siblings, 0 replies; 13+ messages in thread From: Alexey Gladkov @ 2019-04-29 21:08 UTC (permalink / raw) To: make-initrd On Mon, Apr 29, 2019 at 06:53:50PM +0300, Leonid Krivoshein wrote: > > > 29.04.2019 18:39, Michael A. Kangin пишет: > > On 04/29/2019 04:49 PM, Alexey Gladkov wrote: > > > >>>> root=/dev/nfs это не моё изобретение: > >>>> https://github.com/torvalds/linux/blob/master/Documentation/filesystems/nfs/nfsroot.txt#L46 > >>>> > >>> > >>> Я просто задумался, если NFS (и другие фичи) рассматривать и как > >>> транспорт, то чей root= в итоге будет. Ну да ладно, у вас там свои идеи > >>> наверное есть :) > >> > >> В каком смысле чей будет ? > > > > Мм, мне трудновато с непривычки выразиться корректно и понятно :) > > > > Я имею ввиду, когда несколько фич могут быть самодостаточными, а могут > > и использовать друг-друга в качестве промежуточного транспорта - как > > они договорятся, которая из них будет обрабатывать параметр root=? > > > > По цепочке все фичи парсят /proc/cmdline, в результате что-то > оказывается в глобальной $INITRD_ROOT. Видимо, кто первый, тот и > транспорт, и так каждый следующий. А кто последний, тот и root. > > > > > > Ну вот допустим есть некая фича "squash-boot", которая использует > > nfsroot как транспорт. Мы говорим root=/dev/nfs, чтобы у нас nfs > > вообще заработало. Тогда этой squash-boot мы должны дать какой-то > > другой параметр вместо root= ? > > > > Хорошо, допустим мы ей будем давать squash-root= > > А в ситуации, когда "squash-boot" будет пользоваться как транспортом > > http или iSCSI - мы вообще без root= останемся? > > > > > > Или разделить нынешнюю nfsroot на транспортную фичу, которая будет > > хотеть nfsroot= и непосредственно монтировочную (как бы назвать такую > > финальную фичу - которая предоставляет подготовленный /root), которая > > будет активироваться root=/dev/nfs? > > > > т.е. например если мы скажем > > nfsroot=192.168.0.1:/nfsshare/mysystem root=/dev/nfs > > то, как сейчас, 192.168.0.1:/nfsshare/mysystem смонтируется на /root > > > > Кажется излишним такой синтаксис. > > > > а если > > nfsroot=192.168.0.1:/nfsshare/images root=nfs:/image1.squash > > тогда 192.168.0.1:/nfsshare/images должно быть смонтировано куда-то не > > в /root, а дальше пусть разбирается "squash-boot" со своим параметром > > root=, который она поймёт как процессить > > > > И такой тоже. Что-то вроде этого напрашивается: > > root=nfs:server:/nfsshare/images;squash:livecd Да, что-то в этом роде. Хотя мне не очень нравится один параметр с кучей опций вперемешку. Мне бы хотелось разделить их, но не уверен, что это будет удобно задавать. -- Rgrds, legion ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated 2019-04-29 15:39 ` Michael A. Kangin 2019-04-29 15:53 ` Leonid Krivoshein @ 2019-04-29 16:26 ` Alexey Gladkov 2019-04-29 16:42 ` Michael A. Kangin 1 sibling, 1 reply; 13+ messages in thread From: Alexey Gladkov @ 2019-04-29 16:26 UTC (permalink / raw) To: make-initrd On Mon, Apr 29, 2019 at 05:39:20PM +0200, Michael A. Kangin wrote: > > В каком смысле чей будет ? > > Мм, мне трудновато с непривычки выразиться корректно и понятно :) > > Я имею ввиду, когда несколько фич могут быть самодостаточными, а могут и > использовать друг-друга в качестве промежуточного транспорта - как они > договорятся, которая из них будет обрабатывать параметр root=? Такой ситуации не бывает. Каждый транспорт ждёт необходимых параметров и если они предоставлены, то согласно им монтирует нечто в указанный каталог. Так продолжается пока не будет выполнено условие, после которого система считается готовой. Сейчас для монтирования корня входными параметрами являются эвенты udev. В новой вселенной этого не достаточно и будет ещё что-то. > Кстати, в каком объёме нужна будет поддержка NFS? > tcp/udp? v. 3 / 4? kerberos? Я пока не знаю. > >> Если закомментить упоминания syslog: > > А куда у тебя логи идут в этом случае ? > > Чьи, самого дропбира? Пока вникуда. Да они вроде и не нужны особенно.. Вот это меня очень смущает. Поэтому там syslog. > Cейчас с сетью, мне кажется нужно думать за ремотные сислоги. > > Вот, говорят, busybox'ный syslog вроде как умеет отсылать: > https://developer.ridgerun.com/wiki/index.php/How_to_Configure_Remote_Syslog_Logging Я это и имел в виду, когда говорил, что можно починить фичу syslog, включив sysklog в busybox. Правда в этом случае эти утилиты нельзя будет не класть в образ и фича будет приносить лишь service-файлы, то не очень мне нравится. -- Rgrds, legion ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated 2019-04-29 16:26 ` Alexey Gladkov @ 2019-04-29 16:42 ` Michael A. Kangin 2019-04-29 17:25 ` Alexey Gladkov 0 siblings, 1 reply; 13+ messages in thread From: Michael A. Kangin @ 2019-04-29 16:42 UTC (permalink / raw) To: make-initrd On 04/29/2019 06:26 PM, Alexey Gladkov wrote: >>> А куда у тебя логи идут в этом случае ? >> Чьи, самого дропбира? Пока вникуда. Да они вроде и не нужны особенно.. > Вот это меня очень смущает. Поэтому там syslog. А зачем они вообще могут быть настолько необходимы? Возможно, еще стоит подумать в сторону: -E Log to stderr rather than syslog ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated 2019-04-29 16:42 ` Michael A. Kangin @ 2019-04-29 17:25 ` Alexey Gladkov 2019-04-29 17:46 ` Michael A. Kangin 0 siblings, 1 reply; 13+ messages in thread From: Alexey Gladkov @ 2019-04-29 17:25 UTC (permalink / raw) To: make-initrd On Mon, Apr 29, 2019 at 06:42:38PM +0200, Michael A. Kangin wrote: > On 04/29/2019 06:26 PM, Alexey Gladkov wrote: > > >>> А куда у тебя логи идут в этом случае ? > >> Чьи, самого дропбира? Пока вникуда. Да они вроде и не нужны особенно.. > > Вот это меня очень смущает. Поэтому там syslog. > > А зачем они вообще могут быть настолько необходимы? Эм. Ну как бы мне иногда хочется знать почему меня не пускает )) > Возможно, еще стоит подумать в сторону: > -E Log to stderr rather than syslog Я уже думал про это. -- Rgrds, legion ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated 2019-04-29 17:25 ` Alexey Gladkov @ 2019-04-29 17:46 ` Michael A. Kangin 2019-04-29 21:05 ` Alexey Gladkov 0 siblings, 1 reply; 13+ messages in thread From: Michael A. Kangin @ 2019-04-29 17:46 UTC (permalink / raw) To: make-initrd On 04/29/2019 07:25 PM, Alexey Gladkov wrote: >> А зачем они вообще могут быть настолько необходимы? > Эм. Ну как бы мне иногда хочется знать почему меня не пускает )) Мне для этого хватило запустить с -EF, сразу всё понятно стало :) Мож так и гонять в systemd стиле, с nohup, не демонизируя... ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [make-initrd] master updated 2019-04-29 17:46 ` Michael A. Kangin @ 2019-04-29 21:05 ` Alexey Gladkov 0 siblings, 0 replies; 13+ messages in thread From: Alexey Gladkov @ 2019-04-29 21:05 UTC (permalink / raw) To: make-initrd On Mon, Apr 29, 2019 at 07:46:33PM +0200, Michael A. Kangin wrote: > On 04/29/2019 07:25 PM, Alexey Gladkov wrote: > > >> А зачем они вообще могут быть настолько необходимы? > > Эм. Ну как бы мне иногда хочется знать почему меня не пускает )) > > Мне для этого хватило запустить с -EF, сразу всё понятно стало :) Это ты, когда уже имеешь доступ ты можешь запустить его так и посмотреть :) > Мож так и гонять в systemd стиле, с nohup, не демонизируя... Это один из вариантов. -- Rgrds, legion ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-04-29 21:08 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-26 12:35 [make-initrd] master updated Alexey Gladkov 2019-04-29 11:02 ` Michael A. Kangin 2019-04-29 12:18 ` Alexey Gladkov 2019-04-29 14:37 ` Michael A. Kangin 2019-04-29 14:49 ` Alexey Gladkov 2019-04-29 15:39 ` Michael A. Kangin 2019-04-29 15:53 ` Leonid Krivoshein 2019-04-29 21:08 ` Alexey Gladkov 2019-04-29 16:26 ` Alexey Gladkov 2019-04-29 16:42 ` Michael A. Kangin 2019-04-29 17:25 ` Alexey Gladkov 2019-04-29 17:46 ` Michael A. Kangin 2019-04-29 21:05 ` Alexey Gladkov
Make-initrd development discussion This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/make-initrd/0 make-initrd/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 make-initrd make-initrd/ http://lore.altlinux.org/make-initrd \ make-initrd@lists.altlinux.org make-initrd@lists.altlinux.ru make-initrd@lists.altlinux.com public-inbox-index make-initrd Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.make-initrd AGPL code for this site: git clone https://public-inbox.org/public-inbox.git