[sisyphus] Корень монтируется в ro :(

[sisyphus] Корень монтируется в ro :(

[Шенцев Алексе владимирович]

Всем привет!

После сегодняшних "разборок" со своим компом у меня корень стал 
монтироваться в ro ... :(

Как исправить и как узнать что я такого сделал для этой пакости? :)

Re: [sisyphus] Корень монтируется в ro :(

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

On Fri, Jul 25, 2014 at 10:15:38PM +0400, Шенцев Алексе владимирович wrote:
> Всем привет!
> После сегодняшних "разборок" со своим компом у меня корень стал 
> монтироваться в ro ... :(
> Как исправить и как узнать что я такого сделал для этой пакости? :)

А что вообще делал?
Что в dmesg?
Что в логах при загрузке?

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] Корень монтируется в ro :(

[Michael Shigorin]

On Fri, Jul 25, 2014 at 10:15:38PM +0400, Шенцев Алексе владимирович wrote:
                                                      ^^^
> После сегодняшних "разборок" со своим компом у меня корень стал
> монтироваться в ro ... :( Как исправить и как узнать что я
> такого сделал для этой пакости? :)

Расскажи хоть, что делал.  Посмотри в dmesg | less -- нет ли
страшных записей при монтировании ФС.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [sisyphus] Корень монтируется в ro :(

[Шенцев Алексей Владимирович]

26.07.2014 15:15, Michael Shigorin пишет:
> On Fri, Jul 25, 2014 at 10:15:38PM +0400, Шенцев Алексе владимирович wrote:
>                                                       ^^^
>> После сегодняшних "разборок" со своим компом у меня корень стал
>> монтироваться в ro ... :( Как исправить и как узнать что я
>> такого сделал для этой пакости? :)
> Расскажи хоть, что делал.  
Что делал? Да выключал загрузку сервисов из sysv, перегружался и
смотрел, грузанулся dm или нет.
Вот история тех команд:

3507  mc
 3508  chkconfig --list
 3509  chkconfig consolesaver off
 3510  reboot
 3511  chkconfig gpm off
 3512  chkconfig --list
 3513  chkconfig gpm on
 3514  chkconfig virtualbox off
 3515  journalctl -ab|grep prefdm
 3516  mc
 3517  history
 3518  history|grep anal
 3519  systemd-analyze blame
 3520  mount -l
 3521  cat /etc/fstab|grep sda2
 3522  ping www.ru
 3523  clear
 3524  dmesg|grep sda2
 3525  dmesg|grep Mount
 3526  mount -o remount /
 3527  reboot

Вроде ни чего криминального.
Загрузку dm добился.
Причина не загружаемости dm - запуск virtualbox'а и возникновнеия из-за
этого циклов в systemd.
Такое как на домашней машине, так и на служебной, где вчера поставил
kdesktop 7 и обновил его до сизифа.
Но на служебной корень монтируется нормально.
А на домашней получил хорошую пакость самому себе ... :)
Корень прогнал через fsck - проблем нет.
Места на разделе ещё 15 гигов.
Что ещё смотреть?


> Посмотри в dmesg | less -- нет ли страшных записей при монтировании ФС.
dmesg.log|grep sda

[    2.094432] sd 1:0:0:0: [sda] 976773168 512-byte logical blocks: (500
GB/465 GiB)
[    2.094433] sd 1:0:0:0: [sda] 4096-byte physical blocks
[    2.094488] sd 1:0:0:0: [sda] Write Protect is off
[    2.094490] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    2.094514] sd 1:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[    2.113740]  sda: sda1 sda2 sda3 sda4
[    2.115731] sd 1:0:0:0: [sda] Attached SCSI disk
[    2.762207] EXT4-fs (sda2): mounted filesystem with ordered data
mode. Opts: (null)
[    5.740954] systemd[1]: Expecting device dev-sda1.device...
[    5.742958] systemd[1]: Expecting device dev-sda3.device...
[    5.744969] systemd[1]: Expecting device dev-sda4.device...
[   14.261253] Adding 8084476k swap on /dev/sda1.  Priority:-1 extents:1
across:8084476k FS
[   15.420279] EXT4-fs (sda3): mounted filesystem with ordered data
mode. Opts: (null)
[   79.213303] EXT4-fs (sda2): re-mounted. Opts: (null)

cat /etc/fstab
proc            /proc                   proc   
nosuid,noexec,gid=proc          0 0
devpts          /dev/pts                devpts 
nosuid,noexec,gid=tty,mode=620  0 0
tmpfs           /tmp                    tmpfs  
nosuid                          0 0
/dev/sda2       /               ext4    relatime        1       1
/dev/sda3       /var            ext4    nosuid,relatime 1       2
/dev/sda1       swap            swap    defaults        0       0
/dev/sr0        /media/cdrom    udf,iso9660     ro,noauto,user,utf8     0 0
/var/home       /home           auto    bind                    1       0
/var/srv        /srv            auto    bind                    1       0
/var/opt        /opt            auto    bind                    1       0
/dev/sda4       /mnt/winc       ntfs-3g
users,rw,noexec,nosuid,nodev,allow_other,default_permissions
/dev/sdb1       /mnt/wind       ntfs-3g
users,rw,noexec,nosuid,nodev,allow_other,default_permissions


-- 
С уважением, Шенцев Алексей Владимирович.

Re: [sisyphus] Корень монтируется в ro :(

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

On Sat, Jul 26, 2014 at 03:56:07PM +0400, Шенцев Алексей Владимирович wrote:

>>> После сегодняшних "разборок" со своим компом у меня корень стал
>>> монтироваться в ro ... :( Как исправить и как узнать что я
>>> такого сделал для этой пакости? :)

systemctl status systemd-remount-fs.service
journalctl -b -u systemd-remount-fs.service
grep -P '\s/\s' /etc/fstab
blkid
systemctl --state=failed
journalctl -b

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] Корень монтируется в ro :(

[Шенцев Алексей Владимирович]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

Всем привет!

Установил KDesktop 7.0.1.
Обновился до текущего p7.
Всё нормально.

Обновился до текущего сизифа и получил корень монтируемый в ro ...

В чём трабла? Куда смотреть?

[root@ashen ~]# systemctl status systemd-remount-fs.service
● systemd-remount-fs.service
    Loaded: masked (/dev/null)
    Active: inactive (dead)

Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended.
[root@ashen ~]# journalctl -b -u systemd-remount-fs.service
-- Logs begin at Вт 2014-08-05 19:15:12 MSK, end at Вт 2014-08-05 
19:50:16 MSK. --

[root@ashen ~]# grep -P '\s/\s' /etc/fstab
/dev/sda2       /               ext4    relatime        1       1
[root@ashen ~]# blkid
/dev/sdb1: LABEL="storage" UUID="42FC1F9602B5B6BA" TYPE="ntfs"
/dev/sda1: UUID="c50ec3d1-f9e3-42b7-a306-7e81b5130895" TYPE="swap"
/dev/sda2: UUID="6337ba9b-c20c-4c19-a73c-bc992b1b2c4a" TYPE="ext4"
/dev/sda3: UUID="9f42c16d-73ca-4fe1-8f35-b45f29649921" TYPE="ext4"
/dev/sda4: LABEL="Win7" UUID="48CC4631CC461998" TYPE="ntfs"

[root@ashen ~]# systemctl --state=failed
   UNIT            LOAD   ACTIVE SUB    DESCRIPTION
●krb5kdc.service loaded failed failed Kerberos 5 KDC

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.


P.S.: как сейчас посмотреть какие пакеты в системе ставились/удалялись?

-- 
С уважением, Шенцев Алексей Владимирович.



[-- Attachment #2: boot.log.bz2 --]
[-- Type: application/x-bzip, Size: 20547 bytes --]

Re: [sisyphus] Корень монтируется в ro :(

[Michael Shigorin]

On Tue, Aug 05, 2014 at 08:09:06PM +0400, Шенцев Алексей Владимирович wrote:
> Установил KDesktop 7.0.1.
> Обновился до текущего p7.
> Всё нормально.
> Обновился до текущего сизифа и получил 
> корень монтируемый в ro ...
> В чём трабла? Куда смотреть?

Не знаю, но на всякий напомню про http://altlinux.org/starterkits#main

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [sisyphus] Корень монтируется в ro :(

[Шенцев Алексей Владимирович]

05.08.2014 20:12, Michael Shigorin пишет:
> On Tue, Aug 05, 2014 at 08:09:06PM +0400, Шенцев Алексей Владимирович wrote:
>> Установил KDesktop 7.0.1.
>> Обновился до текущего p7.
>> Всё нормально.
>> Обновился до текущего сизифа и получил
>> корень монтируемый в ro ...
>> В чём трабла? Куда смотреть?
> Не знаю, но на всякий напомню про http://altlinux.org/starterkits#main

Предлагаешь не мучится с обновлениями с p7, а сразу ставиться с 
сизифного образа?

-- 
С уважением, Шенцев Алексей Владимирович.

Re: [sisyphus] Корень монтируется в ro :(

[Michael Shigorin]

On Tue, Aug 05, 2014 at 08:21:43PM +0400, Шенцев Алексей Владимирович wrote:
> >http://altlinux.org/starterkits#main
> Предлагаешь не мучится с обновлениями с 
> p7, а сразу ставиться с сизифного образа?

Типа того, если уж нужен именно сизиф.  Завтра будет свежий снапшот,
но можно взять и сегодняшний "rc" или прошлонедельную сборку,
в regular-kde4.iso немножко изменились ядро и Mesa (см. там же
ChangeLog).

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [sisyphus] Корень монтируется в ro :(

[Шенцев Алексей Владимирович]

05.08.2014 20:21, Шенцев Алексей Владимирович пишет:
> 05.08.2014 20:12, Michael Shigorin пишет:
>> On Tue, Aug 05, 2014 at 08:09:06PM +0400, Шенцев Алексей Владимирович 
>> wrote:
>>> Установил KDesktop 7.0.1.
>>> Обновился до текущего p7.
>>> Всё нормально.
>>> Обновился до текущего сизифа и получил
>>> корень монтируемый в ro ...
>>> В чём трабла? Куда смотреть?
>> Не знаю, но на всякий напомню про http://altlinux.org/starterkits#main
>
> Предлагаешь не мучится с обновлениями с p7, а сразу ставиться с 
> сизифного образа?
>

Моя не внимательность. Образы то на p7.

Да и всё равно, такое поведение встречаю только на одной машине.
Не так давно ставил на нескольких машинах KDesktop 7.0.1 и обсизифивал. 
Всё нормально.

-- 
С уважением, Шенцев Алексей Владимирович.

Re: [sisyphus] Корень монтируется в ro :(

[Michael Shigorin]

On Tue, Aug 05, 2014 at 08:26:49PM +0400, Шенцев Алексей Владимирович wrote:
> >>http://altlinux.org/starterkits#main
> >Предлагаешь не мучится с обновлениями с 
> >p7, а сразу ставиться с сизифного образа?
> Моя не внимательность. Образы то на p7.

Не твоя, а моя... http://altlinux.org/regular#main

> Да и всё равно, такое поведение встречаю только на одной машине.

Тогда хорошо бы поотлаживать, конечно, если удобно...
потому как обновление с p7 на p8 проверяться и чиниться будет,
но это ещё когда.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [sisyphus] Корень монтируется в ro :(

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]

On Tue, Aug 05, 2014 at 08:09:06PM +0400, Шенцев Алексей Владимирович wrote:

> [root@ashen ~]# systemctl status systemd-remount-fs.service
> ● systemd-remount-fs.service
>     Loaded: masked (/dev/null)
>     Active: inactive (dead)

# systemctl unmask systemd-remount-fs.service
# systemctl enable systemd-remount-fs.service

А вот как и зачем вы выключили этот сервер отдельный вопрос.

> [root@ashen ~]# grep -P '\s/\s' /etc/fstab
> /dev/sda2       /               ext4    relatime        1       1
> [root@ashen ~]# blkid
> /dev/sdb1: LABEL="storage" UUID="42FC1F9602B5B6BA" TYPE="ntfs"
> /dev/sda1: UUID="c50ec3d1-f9e3-42b7-a306-7e81b5130895" TYPE="swap"
> /dev/sda2: UUID="6337ba9b-c20c-4c19-a73c-bc992b1b2c4a" TYPE="ext4"
> /dev/sda3: UUID="9f42c16d-73ca-4fe1-8f35-b45f29649921" TYPE="ext4"
> /dev/sda4: LABEL="Win7" UUID="48CC4631CC461998" TYPE="ntfs"

Кстати в современных системах лучше монтировать по UUID а не по имени
девайса. 

> [root@ashen ~]# systemctl --state=failed
>    UNIT            LOAD   ACTIVE SUB    DESCRIPTION
> ●krb5kdc.service loaded failed failed Kerberos 5 KDC

Если он вам не нужен:

# systemctl mask krb5kdc.service

> P.S.: как сейчас посмотреть какие пакеты в системе ставились/удалялись?

Я для этой цели использую etckeeper (история /etc в git) и
syskeeper-rpm-git (он хранит список установленных пакетов в git, так что
можно легко и удобно смотреть историю всех изменений в системе).

А если лог, то:

# journalctl /usr/bin/apt-get /usr/bin/rpm

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] Корень монтируется в ro :(

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

On Tue, Aug 05, 2014 at 08:36:11PM +0400, Michael Shigorin wrote:

> Тогда хорошо бы поотлаживать, конечно, если удобно...
> потому как обновление с p7 на p8 проверяться и чиниться будет,
> но это ещё когда.

В смысле не будет? По каким причинам?

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] Корень монтируется в ro :(

[Шенцев Алексей Владимирович]

05.08.2014 22:37, Денис Смирнов пишет:
> On Tue, Aug 05, 2014 at 08:09:06PM +0400, Шенцев Алексей Владимирович wrote:
>
>> [root@ashen ~]# systemctl status systemd-remount-fs.service
>> ● systemd-remount-fs.service
>>      Loaded: masked (/dev/null)
>>      Active: inactive (dead)
> # systemctl unmask systemd-remount-fs.service
> # systemctl enable systemd-remount-fs.service

Денис, спасибо, оно!!!!

> А вот как и зачем вы выключили этот сервер отдельный вопрос.

Хороший вопрос мне самому: на фига я его отключил?
До оптимизировался с systemd ...

>
>> [root@ashen ~]# grep -P '\s/\s' /etc/fstab
>> /dev/sda2       /               ext4    relatime        1       1
>> [root@ashen ~]# blkid
>> /dev/sdb1: LABEL="storage" UUID="42FC1F9602B5B6BA" TYPE="ntfs"
>> /dev/sda1: UUID="c50ec3d1-f9e3-42b7-a306-7e81b5130895" TYPE="swap"
>> /dev/sda2: UUID="6337ba9b-c20c-4c19-a73c-bc992b1b2c4a" TYPE="ext4"
>> /dev/sda3: UUID="9f42c16d-73ca-4fe1-8f35-b45f29649921" TYPE="ext4"
>> /dev/sda4: LABEL="Win7" UUID="48CC4631CC461998" TYPE="ntfs"
> Кстати в современных системах лучше монтировать по UUID а не по имени
> девайса.

Мне так привычней.
Так как использование lilo, вместо grub.
Привычка - вторая натура ... :)


>
>> [root@ashen ~]# systemctl --state=failed
>>     UNIT            LOAD   ACTIVE SUB    DESCRIPTION
>> ●krb5kdc.service loaded failed failed Kerberos 5 KDC
> Если он вам не нужен:
>
> # systemctl mask krb5kdc.service

Да выключал я его, только в названии ошибся не много ... :)


>
>> P.S.: как сейчас посмотреть какие пакеты в системе ставились/удалялись?
> Я для этой цели использую etckeeper (история /etc в git) и
> syskeeper-rpm-git (он хранит список установленных пакетов в git, так что
> можно легко и удобно смотреть историю всех изменений в системе).

А etcgit ?

> А если лог, то:
>
> # journalctl /usr/bin/apt-get /usr/bin/rpm
>

Ага, спасибо.
Где то на нашей вики была страничка со всякими полезными советами.
Туда бы этот момент.
Только вот ни как не могу вспомнить эту страничку ... :(

-- 
С уважением, Шенцев Алексей Владимирович.

Re: [sisyphus] Корень монтируется в ro :(

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 3298 bytes --]

On Wed, Aug 06, 2014 at 01:04:09AM +0400, Шенцев Алексей Владимирович wrote:

>>> [root@ashen ~]# systemctl status systemd-remount-fs.service
>>> ● systemd-remount-fs.service
>>>      Loaded: masked (/dev/null)
>>>      Active: inactive (dead)
>> # systemctl unmask systemd-remount-fs.service
>> # systemctl enable systemd-remount-fs.service
> Денис, спасибо, оно!!!!
>> А вот как и зачем вы выключили этот сервер отдельный вопрос.
> Хороший вопрос мне самому: на фига я его отключил?
> До оптимизировался с systemd ...

С mask стоит быть очень осторожным. И маскировать systemd-* нужно особенно
осторожно.

>> Кстати в современных системах лучше монтировать по UUID а не по имени
>> девайса.
> Мне так привычней.
> Так как использование lilo, вместо grub.
> Привычка - вторая натура ... :)

Ok :)

>>> [root@ashen ~]# systemctl --state=failed
>>>     UNIT            LOAD   ACTIVE SUB    DESCRIPTION
>>> ●krb5kdc.service loaded failed failed Kerberos 5 KDC
>> Если он вам не нужен:
>> # systemctl mask krb5kdc.service
> Да выключал я его, только в названии ошибся не много ... :)

apt-get install bash-completion-systemd
или 
apt-get install zsh-completion-systemd

;)

>>> P.S.: как сейчас посмотреть какие пакеты в системе ставились/удалялись?
>> Я для этой цели использую etckeeper (история /etc в git) и
>> syskeeper-rpm-git (он хранит список установленных пакетов в git, так что
>> можно легко и удобно смотреть историю всех изменений в системе).
> А etcgit ?

Не пробовал его. Google не подсказал сходу сравнения между etcgit и
etckeeper.

А syskeeper я написал сам, ибо хранить у себя данные по дискам и
установленным пакетом оказалось очень удобно.

>> А если лог, то:
>> # journalctl /usr/bin/apt-get /usr/bin/rpm
> Ага, спасибо.

Фишка journalctl -- можно попросить его показать все что в логи отправили
конкретные бинарники. 

Я первое время очень нехорошими словами ругался на journalctl. Уж больно
непривычно. Зато по ходу его изучения оказывается многое очень удобно.

> Где то на нашей вики была страничка со всякими полезными советами.
> Туда бы этот момент.
> Только вот ни как не могу вспомнить эту страничку ... :(

Увы, не знаю.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] Корень монтируется в ro :(

[Шенцев Алексей Владимирович]

06.08.2014 01:12, Денис Смирнов пишет:
> On Wed, Aug 06, 2014 at 01:04:09AM +0400, Шенцев Алексей Владимирович wrote:
>
>>>> [root@ashen ~]# systemctl status systemd-remount-fs.service
>>>> ● systemd-remount-fs.service
>>>>       Loaded: masked (/dev/null)
>>>>       Active: inactive (dead)
>>> # systemctl unmask systemd-remount-fs.service
>>> # systemctl enable systemd-remount-fs.service
>> Денис, спасибо, оно!!!!
>>> А вот как и зачем вы выключили этот сервер отдельный вопрос.
>> Хороший вопрос мне самому: на фига я его отключил?
>> До оптимизировался с systemd ...
> С mask стоит быть очень осторожным. И маскировать systemd-* нужно особенно
> осторожно.

Эт точно.
>>>> [root@ashen ~]# systemctl --state=failed
>>>>      UNIT            LOAD   ACTIVE SUB    DESCRIPTION
>>>> ●krb5kdc.service loaded failed failed Kerberos 5 KDC
>>> Если он вам не нужен:
>>> # systemctl mask krb5kdc.service
>> Да выключал я его, только в названии ошибся не много ... :)
> apt-get install bash-completion-systemd
> или
> apt-get install zsh-completion-systemd
>
> ;)

Псиб за подсказку ... :)

>
>>>> P.S.: как сейчас посмотреть какие пакеты в системе ставились/удалялись?
>>> Я для этой цели использую etckeeper (история /etc в git) и
>>> syskeeper-rpm-git (он хранит список установленных пакетов в git, так что
>>> можно легко и удобно смотреть историю всех изменений в системе).
>> А etcgit ?
> Не пробовал его. Google не подсказал сходу сравнения между etcgit и
> etckeeper.

Надо будет поразбираться с ними.

> А syskeeper я написал сам, ибо хранить у себя данные по дискам и
> установленным пакетом оказалось очень удобно.

Эт я помню ... :)

>
>>> А если лог, то:
>>> # journalctl /usr/bin/apt-get /usr/bin/rpm
>> Ага, спасибо.
> Фишка journalctl -- можно попросить его показать все что в логи отправили
> конкретные бинарники.

Мне вот интересно понять, почему такое:

2min 225ms network.service

> Я первое время очень нехорошими словами ругался на journalctl. Уж больно
> непривычно. Зато по ходу его изучения оказывается многое очень удобно.

Это  с любым инструментом: пока не освоишь его нормально будет вечно не 
удобным.

-- 
С уважением, Шенцев Алексей Владимирович.

Re: [sisyphus] Корень монтируется в ro :(

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

On Wed, Aug 06, 2014 at 01:46:15AM +0400, Шенцев Алексей Владимирович wrote:

>> Фишка journalctl -- можно попросить его показать все что в логи отправили
>> конкретные бинарники.
> Мне вот интересно понять, почему такое:
> 2min 225ms network.service

А что на это говорит:

# journalctl -b 0 _SYSTEMD_UNIT=network

?

Я в итоге на домашней машине просто отказался от etcnet пока в пользу
systemd-network. А по ходу наличия времени пишу генератор systemd сервисов
из конфига etcnet.

>> Я первое время очень нехорошими словами ругался на journalctl. Уж больно
>> непривычно. Зато по ходу его изучения оказывается многое очень удобно.
> Это  с любым инструментом: пока не освоишь его нормально будет вечно не 
> удобным.

А осваивать нормально, когда пальцы и глаза уже за 15 лет привыкли к
syslog не так-то просто :)

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] Корень монтируется в ro :(

[Шенцев Алексей Владимирович]

06.08.2014 01:56, Денис Смирнов пишет:
> On Wed, Aug 06, 2014 at 01:46:15AM +0400, Шенцев Алексей Владимирович wrote:
>
>>> Фишка journalctl -- можно попросить его показать все что в логи отправили
>>> конкретные бинарники.
>> Мне вот интересно понять, почему такое:
>> 2min 225ms network.service
> А что на это говорит:
>
> # journalctl -b 0 _SYSTEMD_UNIT=network
>
> ?

На данный момент сказал:

journalctl -b 0 _SYSTEMD_UNIT=network
-- Logs begin at Вт 2014-08-05 19:15:12 MSK, end at Ср 2014-08-06 
01:51:57 MSK. --

Ну это я успел уже перегрузиться.
И получил:

Startup finished in 3.720s (kernel) + 16.810s (userspace) = 20.531s

systemd-analyze blame|grep blue
           1.392s bluetooth.service

systemctl status bluetooth.service
● bluetooth.service - Bluetooth service
    Loaded: loaded (/lib/systemd/system/bluetooth.service; masked)

Однако всё равно грузиться.
И хто его тянет то?


> Я в итоге на домашней машине просто отказался от etcnet пока в пользу
> systemd-network.

И как впечатление?
На моей домашней машинке кабелем до роутера.
А роутер выдаёт по dhpc адрес.

>   А по ходу наличия времени пишу генератор systemd сервисов
> из конфига etcnet.

Читал, читал. Ждём результат ... :)

P.S.: Тред по тихоньку съехал в сторону оптимизации загрузки при 
использовании systemd ... :)
Так что надо начинать новую тему, а не продолжать в теме про 
монтирование корня в ro.

-- 
С уважением, Шенцев Алексей Владимирович.

[sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]

On Wed, Aug 06, 2014 at 02:06:46AM +0400, Шенцев Алексей Владимирович wrote:

>> # journalctl -b 0 _SYSTEMD_UNIT=network
>> ?
> На данный момент сказал:
> journalctl -b 0 _SYSTEMD_UNIT=network
> -- Logs begin at Вт 2014-08-05 19:15:12 MSK, end at Ср 2014-08-06 
> 01:51:57 MSK. --
> Ну это я успел уже перегрузиться.
> И получил:
> Startup finished in 3.720s (kernel) + 16.810s (userspace) = 20.531s

20 секунд userspace? Кто-ж так тормозит?

> systemd-analyze blame|grep blue
>            1.392s bluetooth.service
> systemctl status bluetooth.service
> ● bluetooth.service - Bluetooth service
>     Loaded: loaded (/lib/systemd/system/bluetooth.service; masked)
> Однако всё равно грузиться.
> И хто его тянет то?

Я даже не представляю как это возможно успешно вытянуть masked сервис.

Кстати systemd-analyze blame не самое эффективное средство отладки
скорости загрузки, ибо systemd запускает сервисы параллельно.

Лучше смотреть systemd-analyze plot и critical-chain.

К примеру, некоторые сервисы могут запускаться по событиями от udev. Они
будут видны в blame, но вообще могут не влиять на время загрузки до
состояния "пользователь может войти в систему".

Соответственно оптимизация таких сервисов смысла не имеет.

>> Я в итоге на домашней машине просто отказался от etcnet пока в пользу
>> systemd-network.
> И как впечатление?
> На моей домашней машинке кабелем до роутера.
> А роутер выдаёт по dhpc адрес.

$ cat /etc/systemd/network/uplink.network
[Match]
Name=enp9s0

[Network]
DHCP=yes
DNS=8.8.8.8
DNS=8.8.4.4

Оно просто работает. Тупое как пробка, но работает. Сразу говорю -- об
openresolv оно, к сожалению, не в курсе.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[alexei]

----- Исходное сообщение -----
> От: "Денис Смирнов" <mithraen@freesource.info>
> Кому: sisyphus@lists.altlinux.org
> Отправленные: Среда, 6 Август 2014 г 13:51:32
> Тема: [sisyphus] systemd-network
> 
> On Wed, Aug 06, 2014 at 02:06:46AM +0400, Шенцев Алексей Владимирович wrote:
> 
> >> # journalctl -b 0 _SYSTEMD_UNIT=network
> >> ?
> > На данный момент сказал:
> > journalctl -b 0 _SYSTEMD_UNIT=network
> > -- Logs begin at Вт 2014-08-05 19:15:12 MSK, end at Ср 2014-08-06
> > 01:51:57 MSK. --
> > Ну это я успел уже перегрузиться.
> > И получил:
> > Startup finished in 3.720s (kernel) + 16.810s (userspace) = 20.531s
> 
> 20 секунд userspace? Кто-ж так тормозит?
> 
> > systemd-analyze blame|grep blue
> >            1.392s bluetooth.service
> > systemctl status bluetooth.service
> > ● bluetooth.service - Bluetooth service
> >     Loaded: loaded (/lib/systemd/system/bluetooth.service; masked)
> > Однако всё равно грузиться.
> > И хто его тянет то?
> 
> Я даже не представляю как это возможно успешно вытянуть masked сервис.
> 
> Кстати systemd-analyze blame не самое эффективное средство отладки
> скорости загрузки, ибо systemd запускает сервисы параллельно.
> 
> Лучше смотреть systemd-analyze plot и critical-chain.
> 
> К примеру, некоторые сервисы могут запускаться по событиями от udev. Они
> будут видны в blame, но вообще могут не влиять на время загрузки до
> состояния "пользователь может войти в систему".
> 
> Соответственно оптимизация таких сервисов смысла не имеет.
> 
> >> Я в итоге на домашней машине просто отказался от etcnet пока в пользу
> >> systemd-network.
> > И как впечатление?
> > На моей домашней машинке кабелем до роутера.
> > А роутер выдаёт по dhpc адрес.
> 
> $ cat /etc/systemd/network/uplink.network
> [Match]
> Name=enp9s0
> 
> [Network]
> DHCP=yes
> DNS=8.8.8.8
> DNS=8.8.4.4
> 
> Оно просто работает. Тупое как пробка, но работает. Сразу говорю -- об
> openresolv оно, к сожалению, не в курсе.

А какое нужно написать заклинание, чтобы в итоговый /etc/resolv.conf могда попасть строка
search bla-bla.com ?

Re: [sisyphus] Корень монтируется в ro :(

[Michael Shigorin]

On Tue, Aug 05, 2014 at 10:38:39PM +0400, Денис Смирнов wrote:
> > будет
> В смысле не будет?

Перечитай. :)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

On Wed, Aug 06, 2014 at 02:09:39PM +0900, alexei@taf.ru wrote:

>> Оно просто работает. Тупое как пробка, но работает. Сразу говорю -- об
>> openresolv оно, к сожалению, не в курсе.
> А какое нужно написать заклинание, чтобы в итоговый /etc/resolv.conf могда попасть строка
> search bla-bla.com ?

Оно не умеет resolv.conf. Так что заклинания надо писать прямо в
/etc/resolv.conf, увы.

Вообще я бы не рекомендовал переходить на него с etcnet, уж слишком
бедный функционал.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Alexey Shabalin]

7 августа 2014 г., 0:54 пользователь Денис Смирнов
<mithraen@freesource.info> написал:
> On Wed, Aug 06, 2014 at 02:09:39PM +0900, alexei@taf.ru wrote:
>
>>> Оно просто работает. Тупое как пробка, но работает. Сразу говорю -- об
>>> openresolv оно, к сожалению, не в курсе.
>> А какое нужно написать заклинание, чтобы в итоговый /etc/resolv.conf могда попасть строка
>> search bla-bla.com ?
>
> Оно не умеет resolv.conf. Так что заклинания надо писать прямо в
> /etc/resolv.conf, увы.

Ошибаешься. Оно умеет создавать resolv.conf, но пока в минимальном варианте.
search bla-bla.com - пока не умеет, но в апстриме пролетали патчи для
search bla-bla.com, которые раздает dhcp-сервер.

Для этого используется systemd-resolved.
resolv.conf создается в /run/systemd/resolve, что бы его задействовать
прямо сейчас, можно сделать симлинк /etc/resolv.conf ->
/run/systemd/resolve/resolv.conf
Если научить openresolv обрабатывать /run/systemd/resolve/resolv.conf,
то вообще все будет отлично. Кстати, можно написать сервис, который
будет мониторить изменения /run/systemd/resolve/resolv.conf и дергать
openresolv.

> Вообще я бы не рекомендовал переходить на него с etcnet, уж слишком
> бедный функционал.

-- 
Alexey Shabalin

Re: [sisyphus] systemd-network

[Вадим Илларионов]

В письме от 6 августа 2014 08:51:32 пользователь Денис Смирнов написал:
> $ cat /etc/systemd/network/uplink.network
> [Match]
> Name=enp9s0
> 
> [Network]
> DHCP=yes
> DNS=8.8.8.8
> DNS=8.8.4.4
> 
> Оно просто работает. Тупое как пробка, но работает. Сразу говорю -- об
> openresolv оно, к сожалению, не в курсе.

А содержимое секции [Service] из /lib/systemd/system/network.service можно 
глянуть?
-- 
Мимо проходил.

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

On Thu, Aug 07, 2014 at 03:47:04PM +0400, Alexey Shabalin wrote:

>> Оно не умеет resolv.conf. Так что заклинания надо писать прямо в
>> /etc/resolv.conf, увы.
> Ошибаешься. Оно умеет создавать resolv.conf, но пока в минимальном варианте.
> search bla-bla.com - пока не умеет, но в апстриме пролетали патчи для
> search bla-bla.com, которые раздает dhcp-сервер.
> Для этого используется systemd-resolved.
> resolv.conf создается в /run/systemd/resolve, что бы его задействовать
> прямо сейчас, можно сделать симлинк /etc/resolv.conf ->
> /run/systemd/resolve/resolv.conf
> Если научить openresolv обрабатывать /run/systemd/resolve/resolv.conf,
> то вообще все будет отлично. Кстати, можно написать сервис, который
> будет мониторить изменения /run/systemd/resolve/resolv.conf и дергать
> openresolv.

Дык systemd не указывает к какому интерфейсу относятся эти записи,
скрещивать openresolv будет поэтому непросто.

Лучше уж либо, если используется исключительно systemd-network
действительно создать симлинк. Либо, если используется хоть для чего-то
etcnet -- использовать его для всего.

systemd-network неплохая штука для "обычного десктопа", где никакой
конфигурации не предполагается. Большинству "обычных юзеров" вполне
достаточно его и встроенного DHCP-клиента. Чуть более сложные задачи уже
требуют тщательно думать и писать сервисы рядом (например чтобы сделать
себе сеть для qemu-kvm, мне пришлось уже чутка поплясать с бубном).

Всем остальным, которым нужна хоть какая-то гибкость -- стоит пользоваться
etcnet.

-- 
С уважением, Денис

http://mithraen.ru/


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

On Thu, Aug 07, 2014 at 08:48:06PM +0900, Вадим Илларионов wrote:

> А содержимое секции [Service] из /lib/systemd/system/network.service можно 
> глянуть?

No such file or directory.

Сервис -- systemd-networkd. etcnet на этой машине не установлен, потому и
network.service отсутствует.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Thu, 7 Aug 2014 16:30:42 +0400 Денис Смирнов wrote:
> On Thu, Aug 07, 2014 at 03:47:04PM +0400, Alexey Shabalin wrote:
> 
> >> Оно не умеет resolv.conf. Так что заклинания надо писать прямо в
> >> /etc/resolv.conf, увы.
> > Ошибаешься. Оно умеет создавать resolv.conf, но пока в минимальном варианте.
> > search bla-bla.com - пока не умеет, но в апстриме пролетали патчи для
> > search bla-bla.com, которые раздает dhcp-сервер.
> > Для этого используется systemd-resolved.
> > resolv.conf создается в /run/systemd/resolve, что бы его задействовать
> > прямо сейчас, можно сделать симлинк /etc/resolv.conf ->
> > /run/systemd/resolve/resolv.conf
> > Если научить openresolv обрабатывать /run/systemd/resolve/resolv.conf,
> > то вообще все будет отлично. Кстати, можно написать сервис, который
> > будет мониторить изменения /run/systemd/resolve/resolv.conf и дергать
> > openresolv.

Кстати да, можно нарисовать костыль с помощью inotify-tools или incron.
По уму сам systemd-resolved должен отдавать свой resolv.conf
resolvconf'у (так делает NM, например). Но у меня есть большие
сомнения, что апстрим примет такие патчи, там не любят shell-скрипты.
Есть надежда на Debian, возможно они пропихнут поддержку resolvconf, но
если это и случится, то нескоро.
Я пока не вижу особой необходимости что-то делать по этому поводу, не
настолько уж этот systemd-networkd необходим.

> Дык systemd не указывает к какому интерфейсу относятся эти записи,
> скрещивать openresolv будет поэтому непросто.

Openresolv'у абсолютно без разницы от какого имени ему добавляется
resolv.conf. Оно влияет только на приоритеты, которые легко
настраиваются. Это совсем не обязательно имя интерфейса. Добавлять
можно прямо от имени systemd-resolved, например.
NM, опять-таки, добавляет свой resolv.conf от имени NetworkManager.

> Лучше уж либо, если используется исключительно systemd-network
> действительно создать симлинк. Либо, если используется хоть для чего-то
> etcnet -- использовать его для всего.
> 
> systemd-network неплохая штука для "обычного десктопа", где никакой
> конфигурации не предполагается. Большинству "обычных юзеров" вполне
> достаточно его и встроенного DHCP-клиента.

Насколько я помню обсуждение в апстримной рассылке, там как раз
предполагалось, что systemd-networkd в первую очередь для серверов с
простой конфигурацией. А для десктопов предлагалось использовать NM или
connman.

-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]

On Thu, Aug 07, 2014 at 04:56:00PM +0400, Mikhail Efremov wrote:

> Кстати да, можно нарисовать костыль с помощью inotify-tools или incron.

См. altlinux-resolv.path в новом systemd -- никакой inotify-tools для
таких задач не нужен, в systemd есть встроенный механизм для таких простых
задач.

> По уму сам systemd-resolved должен отдавать свой resolv.conf
> resolvconf'у (так делает NM, например). Но у меня есть большие
> сомнения, что апстрим примет такие патчи, там не любят shell-скрипты.

Там не любят shell-скрипты, но адекватно относятся к hook'ам. Например
таким, как запуск некоего сервиса после поднятия интерфейса. Нам было бы
достаточно такого hook + складывания resolv.conf от разных интерфейсов не
в единый файл, а в несколько.

> Есть надежда на Debian, возможно они пропихнут поддержку resolvconf, но
> если это и случится, то нескоро.
> Я пока не вижу особой необходимости что-то делать по этому поводу, не
> настолько уж этот systemd-networkd необходим.

Да. Сейчас его использование достаточно для простейших случаев -- и то,
есть еще NM.

>> Дык systemd не указывает к какому интерфейсу относятся эти записи,
>> скрещивать openresolv будет поэтому непросто.
> Openresolv'у абсолютно без разницы от какого имени ему добавляется
> resolv.conf. Оно влияет только на приоритеты, которые легко
> настраиваются. Это совсем не обязательно имя интерфейса. Добавлять
> можно прямо от имени systemd-resolved, например.
> NM, опять-таки, добавляет свой resolv.conf от имени NetworkManager.

Ага, если этого нам достаточно -- тогда соответствующий сервис пишется на
коленке легко и непринужденно.

> Насколько я помню обсуждение в апстримной рассылке, там как раз
> предполагалось, что systemd-networkd в первую очередь для серверов с
> простой конфигурацией. А для десктопов предлагалось использовать NM или
> connman.

Для серверов с _очень_ простой конфигурацией он подходит. В принципе он
действительно может подходить для виртуалок. Для остального все же etcnet
несоизмеримо гибче.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Thu, 7 Aug 2014 18:08:35 +0400 Денис Смирнов wrote:
> On Thu, Aug 07, 2014 at 04:56:00PM +0400, Mikhail Efremov wrote:
> 
> > Кстати да, можно нарисовать костыль с помощью inotify-tools или incron.
> 
> См. altlinux-resolv.path в новом systemd -- никакой inotify-tools для
> таких задач не нужен, в systemd есть встроенный механизм для таких простых
> задач.

Да, действительно. Но это все равно костыль.
Кстати, при использовании resolvconf
update_chrooted будет дергаться дважды: хуком для resolvconf и из-за
PathChanged=/etc/resolv.conf в altlinux-libresolv.path.

-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

On Thu, Aug 07, 2014 at 08:09:36PM +0400, Mikhail Efremov wrote:

> Да, действительно. Но это все равно костыль.

Почему?

> Кстати, при использовании resolvconf
> update_chrooted будет дергаться дважды: хуком для resolvconf и из-за
> PathChanged=/etc/resolv.conf в altlinux-libresolv.path.

Да, я уже обратил внимание. Только дергается не целиком update_chrooted, а
исключительно /etc/chroot.d/resolv.conf. Кстати, я только что осознал что
это потенциально приведет к проблемам у других chrooted сервисов -- им-то
никто не обновляет resolv.conf.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Вадим Илларионов]

В письме от 7 августа 2014 16:32:03 пользователь Денис Смирнов написал:
> systemd-networkd
awk -F= '/VERSION=/ {print $2}' /etc/*release
"7.0.3 KDesktop  (Centaurea Montana)"

Из репов подключён только сизиф, но apt-cache search systemd-networkd отвечает 
молчанием.

Тогда как?!
-- 
Мимо проходил.

Re: [sisyphus] systemd-network

[Вадим Илларионов]

В письме от 7 августа 2014 16:32:03 пользователь Денис Смирнов написал:
> systemd-networkd

Вдогонку.

Невзирая на нетривиальную конфигурацию (а может, как раз благодаря ей), 
хотелось бы таки попробовать обойтись без etcnet'а.

Аплинк - 8-портовый киско-рутер, хоть и одомашненный, но умеющий вланы, лацп и 
прочие плюшки.
Шлюз на обычной офисной материнке, но с 2-портовой igb-шкой (тут LACP).
Вафельная точка доступа воткнута во встроенную сетевуху.
Снаружи 3 тегированных влана - корпоративный, абонентский и одного юрика, 
нашего клиента.
Вниз смотрит мост home, соединяющий вафлю с проводным бондом.
Под етснетом всё работает. 
Соорудив же вот такую конфигурацию, сносить етснет и ребутиться боюсь:

for f in /etc/systemd/network/*; do echo -e "\n`basename $f`\n--------"; grep 
-v ^# $f; done

00.enp2s0.network
--------
[Match]
Name=enp2s0

[Network]
Description=RealTek GigaBit Card
Bridge=home

00.enp5s0f.network
--------
[Match]
Bond=bond
Name=enp5s0f*

[Network]
Description=Intel Dual GigaBit Card

10.bond.netdev
--------
[NetDev]
Description=Dual IGB LACP Link
Kind=bond
Name=bond

[Bond]
Mode=802.3ad

10.bond.network
--------
[Match]
Name=bond

[Network]
Bridge=home

20.home.netdev
--------
[NetDev]
Description=Bridge between Dual IGB & RealTek GigaBit cards
Kind=bridge
Name=home

20.home.network
--------
[Match]
Name=home

[Network]
Address=192.168.6.254/24
Gateway=192.168.6.254
DNS=192.168.6.254

30.abon.netdev
--------
[NetDev]
Description=Abonent VLAN
Kind=vlan
Name=abon

[VLAN]
Id=51

30.abon.network
--------
[Match]
Name=abon

[Network]
DHCP=yes

40.corp.netdev
--------
[NetDev]
Description=Corporate VLAN
Kind=vlan
Name=corp

[VLAN]
Id=4094

40.corp.network
--------
[Match]
Name=corp

[Network]
DHCP=yes

50.nf.netdev
--------
[NetDev]
Description=Voronkin VLAN
Kind=vlan
Name=nf

[VLAN]
Id=701

50.nf.network
--------
[Match]
Name=nf

[Network]
DHCP=yes

Денис, глянь, пожалуйста, всё ль в порядке?
-- 
Мимо проходил.

Re: [sisyphus] systemd-network

[Вадим Илларионов]

В письме от 7 августа 2014 16:32:03 пользователь Денис Смирнов написал:

Вдогонку-2.
Адреса с упомянутого шлюза раздаёт dnsmasq, так что формировать 
/etc/resolv.conf исходя из настроек интерфейсов нет нужды.
-- 
Мимо проходил.

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

On Fri, Aug 08, 2014 at 08:55:54AM +0900, Вадим Илларионов wrote:
> В письме от 7 августа 2014 16:32:03 пользователь Денис Смирнов написал:
> > systemd-networkd
> awk -F= '/VERSION=/ {print $2}' /etc/*release
> "7.0.3 KDesktop  (Centaurea Montana)"
> Из репов подключён только сизиф, но apt-cache search systemd-networkd отвечает 
> молчанием.
> Тогда как?!

$ rpm -qf /lib/systemd/systemd-networkd 
systemd-214-alt11

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

On Fri, Aug 08, 2014 at 09:16:54AM +0900, Вадим Илларионов wrote:
>> systemd-networkd
> Вдогонку.
> Невзирая на нетривиальную конфигурацию (а может, как раз благодаря ей), 
> хотелось бы таки попробовать обойтись без etcnet'а.

Почему _благодаря_ ей?

> Аплинк - 8-портовый киско-рутер, хоть и одомашненный, но умеющий вланы, лацп и 
> прочие плюшки.
> Шлюз на обычной офисной материнке, но с 2-портовой igb-шкой (тут LACP).
> Вафельная точка доступа воткнута во встроенную сетевуху.
> Снаружи 3 тегированных влана - корпоративный, абонентский и одного юрика, 
> нашего клиента.
> Вниз смотрит мост home, соединяющий вафлю с проводным бондом.
> Под етснетом всё работает. 
> Соорудив же вот такую конфигурацию, сносить етснет и ребутиться боюсь:
> for f in /etc/systemd/network/*; do echo -e "\n`basename $f`\n--------"; grep 
> -v ^# $f; done
> Денис, глянь, пожалуйста, всё ль в порядке?

Ой-ой-ой. Я столь сложные конфиги писать даже и не пробовал.

А какая цель преследуется переносом всего этого счастья с etcnet на
systemd-networkd?

-- 
С уважением, Денис

http://mithraen.ru/


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On Fri, Aug 08, 2014 at 09:32:20AM +0900, Вадим Илларионов wrote:
> В письме от 7 августа 2014 16:32:03 пользователь Денис Смирнов написал:

> Вдогонку-2.
> Адреса с упомянутого шлюза раздаёт dnsmasq, так что формировать 
> /etc/resolv.conf исходя из настроек интерфейсов нет нужды.

Кстати, вот мой dnsmasq@.service:

[Unit]
Description=dnsmasq on specified interface
Requires=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
BindsTo=sys-subsystem-net-devices-%i.device
After=network-online.target
After=systemd-networkd.service

[Service]
Type=simple
Restart=always
StandardOutput=syslog
ExecStart=/usr/sbin/dnsmasq -k -i %i -I lo -D -C /etc/dnsmasq.%i.conf

[Install]
WantedBy=multi-user.target


-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1.1: Type: text/plain, Size: 876 bytes --]

On Thu, Aug 07, 2014 at 03:47:04PM +0400, Alexey Shabalin wrote:

> Ошибаешься. Оно умеет создавать resolv.conf, но пока в минимальном варианте.
> search bla-bla.com - пока не умеет, но в апстриме пролетали патчи для
> search bla-bla.com, которые раздает dhcp-сервер.
> Для этого используется systemd-resolved.
> resolv.conf создается в /run/systemd/resolve, что бы его задействовать
> прямо сейчас, можно сделать симлинк /etc/resolv.conf ->
> /run/systemd/resolve/resolv.conf

О, спасибо. Я не догадался, что для этого используется отдельный сервис.

> Если научить openresolv обрабатывать /run/systemd/resolve/resolv.conf,
> то вообще все будет отлично. Кстати, можно написать сервис, который
> будет мониторить изменения /run/systemd/resolve/resolv.conf и дергать
> openresolv.

Вроде такого (см. аттач)?

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #1.2: altlinux-openresolv.path --]
[-- Type: text/plain, Size: 219 bytes --]

[Unit]
Description=Update openresolv data from systemd-resolved
Before=paths.target shutdown.target
Wants=systemd-resolved.service

[Path]
PathChanged=/run/systemd/resolve/resolv.conf

[Install]
WantedBy=default.target

[-- Attachment #1.3: altlinux-openresolv.service --]
[-- Type: text/plain, Size: 245 bytes --]

[Unit]
Description=Update openresolv data from systemd-resolved
After=systemd-resolved.service

[Service]
Type=oneshot
ExecStart=/bin/sh -c '/sbin/resolvconf -a systemd-networkd < /run/systemd/resolve/resolv.conf'
#ExecStart=/sbin/resolvconf -u

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Вадим Илларионов]

В письме от 8 августа 2014 07:34:00 пользователь Денис Смирнов написал:
> On Fri, Aug 08, 2014 at 09:32:20AM +0900, Вадим Илларионов wrote:
> > В письме от 7 августа 2014 16:32:03 пользователь Денис Смирнов написал:
> > 
> > Вдогонку-2.
> > Адреса с упомянутого шлюза раздаёт dnsmasq, так что формировать
> > /etc/resolv.conf исходя из настроек интерфейсов нет нужды.
> 
> Кстати, вот мой dnsmasq@.service:
> 
> [Unit]
> Description=dnsmasq on specified interface
> Requires=sys-subsystem-net-devices-%i.device
> After=sys-subsystem-net-devices-%i.device
> BindsTo=sys-subsystem-net-devices-%i.device
> After=network-online.target
> After=systemd-networkd.service
> 
> [Service]
> Type=simple
> Restart=always
> StandardOutput=syslog
> ExecStart=/usr/sbin/dnsmasq -k -i %i -I lo -D -C /etc/dnsmasq.%i.conf
> 
> [Install]
> WantedBy=multi-user.target

У меня попроще:

/lib/systemd/system/dnsmasq.service                                                                                                                                                                                                        

[Unit]
Description=A lightweight DHCP and caching DNS server
After=bind.service

[Service]
ExecStartPre=/usr/sbin/dnsmasq-helper prestart
ExecStart=/usr/sbin/dnsmasq-helper start -k --pid-file
ExecStartPost=/usr/sbin/dnsmasq-helper poststart
ExecStopPost=/usr/sbin/dnsmasq-helper poststop
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

-- 
Мимо проходил.

Re: [sisyphus] systemd-network

[Вадим Илларионов]

В письме от 8 августа 2014 07:30:42 пользователь Денис Смирнов написал:
> On Fri, Aug 08, 2014 at 09:16:54AM +0900, Вадим Илларионов wrote:
> >> systemd-networkd
> > 
> > Вдогонку.
> > Невзирая на нетривиальную конфигурацию (а может, как раз благодаря ей),
> > хотелось бы таки попробовать обойтись без etcnet'а.
> 
> Почему _благодаря_ ей?
Дапатамушта руки чешутся отведать новенького. :)

> > Аплинк - 8-портовый киско-рутер, хоть и одомашненный, но умеющий вланы,
> > лацп и прочие плюшки.
> > Шлюз на обычной офисной материнке, но с 2-портовой igb-шкой (тут LACP).
> > Вафельная точка доступа воткнута во встроенную сетевуху.
> > Снаружи 3 тегированных влана - корпоративный, абонентский и одного юрика,
> > нашего клиента.
> > Вниз смотрит мост home, соединяющий вафлю с проводным бондом.
> > Под етснетом всё работает.
> > Соорудив же вот такую конфигурацию, сносить етснет и ребутиться боюсь:
> > for f in /etc/systemd/network/*; do echo -e "\n`basename $f`\n--------";
> > grep -v ^# $f; done
> > Денис, глянь, пожалуйста, всё ль в порядке?
> 
> Ой-ой-ой. Я столь сложные конфиги писать даже и не пробовал.
> 
> А какая цель преследуется переносом всего этого счастья с etcnet на
> systemd-networkd?
1 (но не главное). Отчего-то некоторые из интерфейсов не всегда поднимаются 
после ребута и/или не все правила iptables / ip route/rule отрабатывают. И 
подобное я ловил:
а) на разном железе,
б) на разных местах работы,
в) в разных системах виртуализации, но...
Но _только_ на етснете.
2. Изменения конфигурации на шлюзе производятся крайне редко. Динамические 
профили на нём не требуются. Отключить ненужный интерфейс не представляет 
трудности ни в одной из систем сетевой настройки. Завести новый несложно по 
аналогии с уже имеющимися. Пусть громоздко, зато надёжно и в соответствии с 
генеральной линией системд. :)

> rpm -qf /lib/systemd/systemd-networkd
> systemd-214-alt11
Да, у меня так же. То есть, достаточно напрочь снести курочке етснет или 
отключить его запуск?..
-- 
Мимо проходил.

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]

On Fri, Aug 08, 2014 at 01:18:46PM +0900, Вадим Илларионов wrote:

>> Почему _благодаря_ ей?
> Дапатамушта руки чешутся отведать новенького. :)

Понял :) Только главное, чтобы не в production ;)

> 1 (но не главное). Отчего-то некоторые из интерфейсов не всегда поднимаются 
> после ребута и/или не все правила iptables / ip route/rule отрабатывают. И 
> подобное я ловил:
> а) на разном железе,
> б) на разных местах работы,
> в) в разных системах виртуализации, но...
> Но _только_ на етснете.

Любопытно. А что общего у этих не поднимающихся интерфейсов?

> 2. Изменения конфигурации на шлюзе производятся крайне редко. Динамические 
> профили на нём не требуются. Отключить ненужный интерфейс не представляет 
> трудности ни в одной из систем сетевой настройки. Завести новый несложно по 
> аналогии с уже имеющимися. Пусть громоздко, зато надёжно и в соответствии с 
> генеральной линией системд. :)
>> rpm -qf /lib/systemd/systemd-networkd
>> systemd-214-alt11
> Да, у меня так же. То есть, достаточно напрочь снести курочке етснет или 
> отключить его запуск?..

И не забыть systemctl enable systemd-networkd.service

Только вот без etcnet у тебя даже ifup/ifdown не будет.

И многие фишки etcnet в принципе нереализуемы через systemd-networkd. Я
сходу даже элементарных аналогов per-interface if{up,down}-{pre,post} не нашел. 


-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Alexey Shabalin]

7 августа 2014 г., 20:09 пользователь Mikhail Efremov <sem@altlinux.ru> написал:
> On Thu, 7 Aug 2014 18:08:35 +0400 Денис Смирнов wrote:
>> On Thu, Aug 07, 2014 at 04:56:00PM +0400, Mikhail Efremov wrote:
>>
>> > Кстати да, можно нарисовать костыль с помощью inotify-tools или incron.
>>
>> См. altlinux-resolv.path в новом systemd -- никакой inotify-tools для
>> таких задач не нужен, в systemd есть встроенный механизм для таких простых
>> задач.
>
> Да, действительно. Но это все равно костыль.
> Кстати, при использовании resolvconf
> update_chrooted будет дергаться дважды: хуком для resolvconf и из-за
> PathChanged=/etc/resolv.conf в altlinux-libresolv.path.

А в этом есть проблема? что дважды дергается?
Для SysV тоже дважды дергается(из rc.sysinit и хуком для resolvconf),
и никто этой проблемы раньше не замечал.


-- 
Alexey Shabalin

Re: [sisyphus] systemd-network

[Alexey Shabalin]

8 августа 2014 г., 8:05 пользователь Денис Смирнов
<mithraen@freesource.info> написал:
> On Thu, Aug 07, 2014 at 03:47:04PM +0400, Alexey Shabalin wrote:
>
>> Ошибаешься. Оно умеет создавать resolv.conf, но пока в минимальном варианте.
>> search bla-bla.com - пока не умеет, но в апстриме пролетали патчи для
>> search bla-bla.com, которые раздает dhcp-сервер.
>> Для этого используется systemd-resolved.
>> resolv.conf создается в /run/systemd/resolve, что бы его задействовать
>> прямо сейчас, можно сделать симлинк /etc/resolv.conf ->
>> /run/systemd/resolve/resolv.conf
>
> О, спасибо. Я не догадался, что для этого используется отдельный сервис.
>
>> Если научить openresolv обрабатывать /run/systemd/resolve/resolv.conf,
>> то вообще все будет отлично. Кстати, можно написать сервис, который
>> будет мониторить изменения /run/systemd/resolve/resolv.conf и дергать
>> openresolv.
>
> Вроде такого (см. аттач)?

Только положить эти unit-файлы надо в пакет openresolv.


-- 
Alexey Shabalin

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

On Fri, Aug 08, 2014 at 01:38:24PM +0400, Alexey Shabalin wrote:

>>> Если научить openresolv обрабатывать /run/systemd/resolve/resolv.conf,
>>> то вообще все будет отлично. Кстати, можно написать сервис, который
>>> будет мониторить изменения /run/systemd/resolve/resolv.conf и дергать
>>> openresolv.
>> Вроде такого (см. аттач)?
> Только положить эти unit-файлы надо в пакет openresolv.

Кстати, у меня вопрос -- в каких случаях надо писать WantedBy
default.target, а в каких multi-user.target?

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 250 bytes --]

On Fri, Aug 08, 2014 at 01:14:49PM +0900, Вадим Илларионов wrote:

> У меня попроще:

Фишка моего варианта -- возможность запускать несколько dnsmasq с разными
конфигами для разных интерфейсов.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Вадим Илларионов]

В письме от 8 августа 2014 08:54:14 пользователь Денис Смирнов написал:
> >> Почему _благодаря_ ей?
> > Дапатамушта руки чешутся отведать новенького. :)
> Понял :) Только главное, чтобы не в production ;)
Разумеется! :)

> > 1 (но не главное). Отчего-то некоторые из интерфейсов не всегда
> > поднимаются
> > после ребута и/или не все правила iptables / ip route/rule отрабатывают. И
> > подобное я ловил:
> > а) на разном железе,
> > б) на разных местах работы,
> > в) в разных системах виртуализации, но...
> > Но _только_ на етснете.
> 
> Любопытно. А что общего у этих не поднимающихся интерфейсов?
Кабы удалось выявить, наверное, удалось бы и победить. А так - некий блудный 
глюк.

> > Да, у меня так же. То есть, достаточно напрочь снести курочке етснет или
> > отключить его запуск?..
> И не забыть systemctl enable systemd-networkd.service
Ага, спасибо.

> Только вот без etcnet у тебя даже ifup/ifdown не будет.
А вот это печалька...

> И многие фишки etcnet в принципе нереализуемы через systemd-networkd. Я
> сходу даже элементарных аналогов per-interface if{up,down}-{pre,post} не
> нашел.
Совсем горюшко. Хоть не раскрывай новые горизонты, блин...

-- 
Мимо проходил.

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

On Sat, Aug 09, 2014 at 11:43:33AM +0900, Вадим Илларионов wrote:

>> И многие фишки etcnet в принципе нереализуемы через systemd-networkd. Я
>> сходу даже элементарных аналогов per-interface if{up,down}-{pre,post} не
>> нашел.
> Совсем горюшко. Хоть не раскрывай новые горизонты, блин...

systemd-netword это не новые горизонты. Это только-только начавшийся
проект, к тому же ориентированный на совершенно другие задачи, нежели
"гибкая настройка сложной сети".

Как раз эту задачу лучше всего решает etcnet.

Хочется новых горизонтов -- тогда надо писать таки нормальные service's.
Или генератор этих самых service's из человеческого формата.

В общем -- хочешь действительно гибкой настройкой сети, то либо юзай
etcnet, либо пиши свой etcnet :)

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Вадим Илларионов]

В письме от 9 августа 2014 07:28:44 пользователь Денис Смирнов написал:
> systemd-netword это не новые горизонты. Это только-только начавшийся
> проект, к тому же ориентированный на совершенно другие задачи, нежели
> "гибкая настройка сложной сети".
> Как раз эту задачу лучше всего решает etcnet.
> 
> Хочется новых горизонтов -- тогда надо писать таки нормальные service's.
> Или генератор этих самых service's из человеческого формата.
> 
> В общем -- хочешь действительно гибкой настройкой сети, то либо юзай
> etcnet, либо пиши свой etcnet :)
Уже участвовал. Модуль опенвпн для неё делал.
Устало удручать, что один и тот же баг которую версию кряду приходится чинить 
после каждого обновления, вручную добавляя в config-fw подгрузку 
xtables_preload. Иначе ломается фаервол, прописанный человечьим языком.
Хватит с меня.
-- 
Мимо проходил.

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

On Sat, Aug 09, 2014 at 02:26:20PM +0900, Вадим Илларионов wrote:

>> В общем -- хочешь действительно гибкой настройкой сети, то либо юзай
>> etcnet, либо пиши свой etcnet :)
> Уже участвовал. Модуль опенвпн для неё делал.
> Устало удручать, что один и тот же баг которую версию кряду приходится чинить 
> после каждого обновления, вручную добавляя в config-fw подгрузку 
> xtables_preload. Иначе ломается фаервол, прописанный человечьим языком.
> Хватит с меня.

Номер бага на bugzilla и патч есть?

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Anton Gorlov]

09.08.2014 06:43, Вадим Илларионов пишет:
>> Только вот без etcnet у тебя даже ifup/ifdown не будет.
> А вот это печалька...
>
ip link set up/down dev ethN

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

On Sun, Aug 10, 2014 at 11:05:22AM +0400, Anton Gorlov wrote:

>>> Только вот без etcnet у тебя даже ifup/ifdown не будет.
>> А вот это печалька...
> ip link set up/down dev ethN

ifup это несколько больше чем ip link set.

Это еще и запуска if{up,down}-{pre,post} скриптов, обработка зависимостей
между интерфейсами (VPN надо поднимать после и опускать до основного
интерфейса), это и правила firewall'а, привяазанные к конкретному
интерфейсу, и изменения роутинга, и много чего еще.

См. код etcnet.

И для всего этого есть простые ручки -- ifup и ifdown.

-- 
С уважением, Денис

http://mithraen.ru/


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Michael Shigorin]

On Sat, Aug 09, 2014 at 02:26:20PM +0900, Вадим Илларионов wrote:
> Уже участвовал. Модуль опенвпн для неё делал.
> Устало удручать, что один и тот же баг которую версию кряду
> приходится чинить после каждого обновления, вручную добавляя в
> config-fw подгрузку xtables_preload. Иначе ломается фаервол,
> прописанный человечьим языком.  Хватит с меня.

Так давайте починим в пакете :)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [sisyphus] systemd-network

[Вадим Илларионов]

В письме от 10 августа 2014 19:49:50 пользователь Michael Shigorin написал:
> On Sat, Aug 09, 2014 at 02:26:20PM +0900, Вадим Илларионов wrote:
> > Уже участвовал. Модуль опенвпн для неё делал.
> > Устало удручать, что один и тот же баг которую версию кряду
> > приходится чинить после каждого обновления, вручную добавляя в
> > config-fw подгрузку xtables_preload. Иначе ломается фаервол,
> > прописанный человечьим языком.  Хватит с меня.
> 
> Так давайте починим в пакете :)

sed -i 's/xtables_${ACTION} \"$NAME\"/xtables_preload\n\t\t\txtables_${ACTION} 
\"$NAME\"/' /etc/net/scripts/config-fw
______________________________
Mobile: +7 (964) 103-65-67
Skype: gbIMoBou
JID = <mailto:>
Viber = Mobile
UIN: 7899517

Re: [sisyphus] systemd-network

[Вадим Илларионов]

В письме от 10 августа 2014 19:49:50 пользователь Michael Shigorin написал:
> Так давайте починим в пакете :)

Лучше так:

grep -q xtables_preload /etc/net/scripts/config-fw || sed -i 
's/xtables_${ACTION} 
"$NAME"/xtables_preload\n\t\t\txtables_${ACTION} "$NAME"/' 
/etc/net/scripts/config-fw

Одной строкою, вестимо.
-- 
Мимо проходил.

Re: [sisyphus] Корень монтируется в ro :(

[Sergey V Turchin]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

On Tuesday 05 August 2014 20:09:06 Шенцев Алексей wrote:
> Всем привет!
> 
> Установил KDesktop 7.0.1.
Лучше 7.0.3 устанавливать в любом случае.

[...]

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] Корень монтируется в ro :(

[Шенцев Алексей Владимирович]

11.08.2014 16:16, Sergey V Turchin пишет:
> On Tuesday 05 August 2014 20:09:06 Шенцев Алексей wrote:
>> Всем привет!
>>
>> Установил KDesktop 7.0.1.
> Лучше 7.0.3 устанавливать в любом случае.
>
1) Что было под рукой, то и установил ...
2) В чём был косяк, разобрались - сам виноват ...


-- 
С уважением, Шенцев Алексей Владимирович.

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Thu, 7 Aug 2014 21:00:06 +0400 Денис Смирнов wrote:
> On Thu, Aug 07, 2014 at 08:09:36PM +0400, Mikhail Efremov wrote:
> 
> > Да, действительно. Но это все равно костыль.
> 
> Почему?

Потому что вместо того, чтобы создавать файл и потом за ним следить
нужно сразу писать в pipe resolvconf'у.

-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Fri, 8 Aug 2014 13:33:30 +0400 Alexey Shabalin wrote:
> 7 августа 2014 г., 20:09 пользователь Mikhail Efremov <sem@altlinux.ru> написал:
> > Кстати, при использовании resolvconf
> > update_chrooted будет дергаться дважды: хуком для resolvconf и из-за
> > PathChanged=/etc/resolv.conf в altlinux-libresolv.path.
> 
> А в этом есть проблема? что дважды дергается?
> Для SysV тоже дважды дергается(из rc.sysinit и хуком для resolvconf),
> и никто этой проблемы раньше не замечал.

Нет, там, по сути инициализация чрутов, а хуком уже последующее
изменение при необходимости.
Здесь же всегда запуск из двух мест по одному условию
(изменение /etc/resolv.conf). Причем практически одновременный, что,
возможно, тоже может создавать проблемы из-за каких-нибудь race.

-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Fri, 8 Aug 2014 13:38:24 +0400 Alexey Shabalin wrote:
> 8 августа 2014 г., 8:05 пользователь Денис Смирнов
> <mithraen@freesource.info> написал:
> > On Thu, Aug 07, 2014 at 03:47:04PM +0400, Alexey Shabalin wrote:
> >
> >> Ошибаешься. Оно умеет создавать resolv.conf, но пока в минимальном варианте.
> >> search bla-bla.com - пока не умеет, но в апстриме пролетали патчи для
> >> search bla-bla.com, которые раздает dhcp-сервер.
> >> Для этого используется systemd-resolved.
> >> resolv.conf создается в /run/systemd/resolve, что бы его задействовать
> >> прямо сейчас, можно сделать симлинк /etc/resolv.conf ->
> >> /run/systemd/resolve/resolv.conf
> >
> > О, спасибо. Я не догадался, что для этого используется отдельный сервис.
> >
> >> Если научить openresolv обрабатывать /run/systemd/resolve/resolv.conf,
> >> то вообще все будет отлично. Кстати, можно написать сервис, который
> >> будет мониторить изменения /run/systemd/resolve/resolv.conf и дергать
> >> openresolv.
> >
> > Вроде такого (см. аттач)?
> 
> Только положить эти unit-файлы надо в пакет openresolv.

Я не уверен, что это правильное место. Openresolv - это просто
инструмент, который должен использоваться вместо прямой записи
в /etc/resolv.conf. И заботиться о том, чтобы его правильно
использовать, должен тот, кто использует. В данном случае -
systemd-resolvd.
Сам же инструмент не должен знать о том, кто и как его использует. 

-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

On Tue, Aug 12, 2014 at 05:25:10PM +0400, Mikhail Efremov wrote:

>>> Да, действительно. Но это все равно костыль.
>> Почему?
> Потому что вместо того, чтобы создавать файл и потом за ним следить
> нужно сразу писать в pipe resolvconf'у.

Тогда уж этим должен заниматься сам systemd-networkd. systemd-resolve это
очень странный грязный хак -- я на его код посмотрел. По сути он следит
через inotify за /run/systemd/netif, а дальше делает то же что openresolv,
только хуже.

И мы могли бы сделать легко полноценную поддержку openresolv аналогичным
способом, вот только файлики внутри /run/systemd/netif не содержат _имени_
интерфейса. Поэтому сделать можно только аналогичную systemd-resolve
кривульку.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

On Tue, Aug 12, 2014 at 05:32:45PM +0400, Mikhail Efremov wrote:

> Нет, там, по сути инициализация чрутов, а хуком уже последующее
> изменение при необходимости.
> Здесь же всегда запуск из двух мест по одному условию
> (изменение /etc/resolv.conf). Причем практически одновременный, что,
> возможно, тоже может создавать проблемы из-за каких-нибудь race.

В systemd inotify-based реакция происходит по закрытию файла.

race может быть только в одном случае -- если модифицируется с небольшим
интервалом, скажем, /etc/resolv.conf и /etc/hosts. Тогда, если второй файл
был изменен после запуска, но до завершения юнита с синхронизацией --
повторно он вызван не будет.

Я для личных целей пользуюсь incrond, и пробовал его заменить systemd, но
именно из-за этой особенности не срослось (там еще мне помешало то, что я
не нашел как при слежении за каталогом реагировать отдельно на каждый
файл -- указывая имя этого файла как параметра для скрипта).

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Tue, 12 Aug 2014 18:10:07 +0400 Денис Смирнов wrote:
> On Tue, Aug 12, 2014 at 05:32:45PM +0400, Mikhail Efremov wrote:
> 
> > Нет, там, по сути инициализация чрутов, а хуком уже последующее
> > изменение при необходимости.
> > Здесь же всегда запуск из двух мест по одному условию
> > (изменение /etc/resolv.conf). Причем практически одновременный, что,
> > возможно, тоже может создавать проблемы из-за каких-нибудь race.
> 
> В systemd inotify-based реакция происходит по закрытию файла.
> 
> race может быть только в одном случае -- если модифицируется с небольшим
> интервалом, скажем, /etc/resolv.conf и /etc/hosts. Тогда, если второй файл
> был изменен после запуска, но до завершения юнита с синхронизацией --
> повторно он вызван не будет.

Я про race при одновременном запуске из юнит-файла и из хука для
resolvconf'а. Это всегда будет происходить одновременно при
изменении /etc/resolv.conf resolvconf'ом.

-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Tue, 12 Aug 2014 18:06:46 +0400 Денис Смирнов wrote:
> On Tue, Aug 12, 2014 at 05:25:10PM +0400, Mikhail Efremov wrote:
> 
> >>> Да, действительно. Но это все равно костыль.
> >> Почему?
> > Потому что вместо того, чтобы создавать файл и потом за ним следить
> > нужно сразу писать в pipe resolvconf'у.
> 
> Тогда уж этим должен заниматься сам systemd-networkd. systemd-resolve это
> очень странный грязный хак -- я на его код посмотрел. По сути он следит
> через inotify за /run/systemd/netif, а дальше делает то же что openresolv,
> только хуже.

Так раньше этот код был в systemd-networkd, это в последних версиях
апстрим решил, что генерацией resolv.conf должен заниматься аж отдельный
демон.

> И мы могли бы сделать легко полноценную поддержку openresolv аналогичным
> способом, вот только файлики внутри /run/systemd/netif не содержат _имени_
> интерфейса. Поэтому сделать можно только аналогичную systemd-resolve
> кривульку.

Конечно лучше было бы генерить отдельные resolv.conf для каждого
интерфейса. Но большей беды в том, что там генерится общий resolv.conf
тоже нет: интерфейсы через которые доступны эти ДНС-сервера подняты.

Кстати, в systemd-resolved не предусмотрено явное удаление записей. Там
просто записывается пустой resolv.conf, насколько я помню. Для работы с
openresolv хорошо бы в этом случае использовать resolvconf -d вместо
записи пустого файла. Работать должно и так, конечно, но resolvconf
будет хранить этот пустой конфиг и пытаться его использовать.
То есть в altlinux-openresolv.service лучше бы все-таки использовать
скрипт-обертку с проверкой на размер /run/systemd/resolve/resolv.conf.
Да и ExecStop=/sbin/resolvconf -d systemd-networkd не помешает.

-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

On Tue, Aug 12, 2014 at 05:38:41PM +0400, Mikhail Efremov wrote:

> Я не уверен, что это правильное место. Openresolv - это просто
> инструмент, который должен использоваться вместо прямой записи
> в /etc/resolv.conf. И заботиться о том, чтобы его правильно
> использовать, должен тот, кто использует. В данном случае -
> systemd-resolvd.
> Сам же инструмент не должен знать о том, кто и как его использует. 

Тут такая штука -- есть системообразующие сервисы, и есть дополнительные
модули, реализующие некоторую функциональность.

systemd -- более "системообразующий" чем openresolv.

Однако, стоит заметить, systemd-networkd _у нас_ отнюдь не
системообразующий. И его стоило бы напару с systemd-resolve вынести в
отдельный пакет. В который и положить соответствующие unit'ы.

Ибо systemd-networkd у нас всего лишь одно из множества приложений,
которые умеют поднимать интерфейсы и получать адреса.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

On Tue, Aug 12, 2014 at 07:41:30PM +0400, Mikhail Efremov wrote:

>> race может быть только в одном случае -- если модифицируется с небольшим
>> интервалом, скажем, /etc/resolv.conf и /etc/hosts. Тогда, если второй файл
>> был изменен после запуска, но до завершения юнита с синхронизацией --
>> повторно он вызван не будет.
> Я про race при одновременном запуске из юнит-файла и из хука для
> resolvconf'а. Это всегда будет происходить одновременно при
> изменении /etc/resolv.conf resolvconf'ом.

Два приложения пишут в один и тот же файл одни и те же данные. Предполагаю
что это не приведет к повреждению данных.

Хотя, конечно, хорошо бы отучить openresolv от ручного вызова
update_chrooted при работе из под systemd.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

On Tue, Aug 12, 2014 at 08:06:44PM +0400, Mikhail Efremov wrote:

> Конечно лучше было бы генерить отдельные resolv.conf для каждого
> интерфейса. Но большей беды в том, что там генерится общий resolv.conf
> тоже нет: интерфейсы через которые доступны эти ДНС-сервера подняты.

Это делает невозможным использование interface_order в openresolv, к
примеру. Допустимо, но "неаккуратненько".

В любом случае, по крайней мере прямо сейчас это работающее решение.

> Кстати, в systemd-resolved не предусмотрено явное удаление записей. Там
> просто записывается пустой resolv.conf, насколько я помню. Для работы с
> openresolv хорошо бы в этом случае использовать resolvconf -d вместо
> записи пустого файла. Работать должно и так, конечно, но resolvconf
> будет хранить этот пустой конфиг и пытаться его использовать.
> То есть в altlinux-openresolv.service лучше бы все-таки использовать
> скрипт-обертку с проверкой на размер /run/systemd/resolve/resolv.conf.
> Да и ExecStop=/sbin/resolvconf -d systemd-networkd не помешает.

Вот тут уж я не знаю как правильно. Скрипт, кстати, необязателен -- можно
просто в ExecStart вызывать /bin/sh с соответствующей командой.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

On Tue, Aug 12, 2014 at 08:06:44PM +0400, Mikhail Efremov wrote:

> Конечно лучше было бы генерить отдельные resolv.conf для каждого
> интерфейса. Но большей беды в том, что там генерится общий resolv.conf
> тоже нет: интерфейсы через которые доступны эти ДНС-сервера подняты.

У systemd-resolve есть еще одна очень большая неприятная особенность при
использовании с openresolv -- у него внутрь прошиты дефолтные DNS'ы. И он
их _всегда_ анонсирует.

Так что с дефолтными конфигами он в принципе никогда не будет генерировать
пустой resolv.conf.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Wed, 13 Aug 2014 16:07:38 +0400 Денис Смирнов wrote:
> On Tue, Aug 12, 2014 at 08:06:44PM +0400, Mikhail Efremov wrote:
> 
> > Конечно лучше было бы генерить отдельные resolv.conf для каждого
> > интерфейса. Но большей беды в том, что там генерится общий resolv.conf
> > тоже нет: интерфейсы через которые доступны эти ДНС-сервера подняты.
> 
> У systemd-resolve есть еще одна очень большая неприятная особенность при
> использовании с openresolv -- у него внутрь прошиты дефолтные DNS'ы. И он
> их _всегда_ анонсирует.
> 
> Так что с дефолтными конфигами он в принципе никогда не будет генерировать
> пустой resolv.conf.

А, тогда нужно только ExecStop добавить, видимо.

-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Alexey Shabalin]

13 августа 2014 г., 16:07 пользователь Денис Смирнов написал:
> On Tue, Aug 12, 2014 at 08:06:44PM +0400, Mikhail Efremov wrote:
>
>> Конечно лучше было бы генерить отдельные resolv.conf для каждого
>> интерфейса. Но большей беды в том, что там генерится общий resolv.conf
>> тоже нет: интерфейсы через которые доступны эти ДНС-сервера подняты.
>
> У systemd-resolve есть еще одна очень большая неприятная особенность при
> использовании с openresolv -- у него внутрь прошиты дефолтные DNS'ы. И он
> их _всегда_ анонсирует.
>
> Так что с дефолтными конфигами он в принципе никогда не будет генерировать
> пустой resolv.conf.

Вроде в master(будущий v216) сильно-сильно переработали resolved.
А вообще, если мы хотим как-то влиять на ход разработки systemd, и
получить нужные нам фичи, то надо общаться с апстримом. Хотя бы
послать запрос.
Например, почему бы не реализовать функционал openresolv в самом
systemd-resolvd, и сделать совместимым способ управления с openresolv.

-- 
Alexey Shabalin

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

On Thu, Aug 14, 2014 at 07:09:07PM +0400, Alexey Shabalin wrote:

> Вроде в master(будущий v216) сильно-сильно переработали resolved.

Можно ссылки на то как именно?

> А вообще, если мы хотим как-то влиять на ход разработки systemd, и
> получить нужные нам фичи, то надо общаться с апстримом. Хотя бы
> послать запрос.
> Например, почему бы не реализовать функционал openresolv в самом
> systemd-resolvd, и сделать совместимым способ управления с openresolv.

Полностью совместимым не получится -- идеология конфигов разная.

А чтобы найти какое-то приемлимое решене у меня не хватит ни знаний
английского, ни времени :(

Там еще засада -- openresolv решает две задачи -- сборка resolv.conf из
данных с разных интерфейсов + еще и управление кэширующими DNS-серверами.

К тому же нынешний resolved вообще противоречит логике самого systemd. По
сути он просто реагирует на события inotify, но вместо того чтобы
использовать unit.path зачем-то сделан постоянно запущеный сервис.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Alexey Shabalin]

15 августа 2014 г., 12:43 пользователь Денис Смирнов
<mithraen@freesource.info> написал:
> On Thu, Aug 14, 2014 at 07:09:07PM +0400, Alexey Shabalin wrote:
>
>> Вроде в master(будущий v216) сильно-сильно переработали resolved.
> Можно ссылки на то как именно?

http://cgit.freedesktop.org/systemd/systemd/tree/src/resolve

>
>> А вообще, если мы хотим как-то влиять на ход разработки systemd, и
>> получить нужные нам фичи, то надо общаться с апстримом. Хотя бы
>> послать запрос.
>> Например, почему бы не реализовать функционал openresolv в самом
>> systemd-resolvd, и сделать совместимым способ управления с openresolv.
>
> Полностью совместимым не получится -- идеология конфигов разная.
>
> А чтобы найти какое-то приемлимое решене у меня не хватит ни знаний
> английского, ни времени :(
>
> Там еще засада -- openresolv решает две задачи -- сборка resolv.conf из
> данных с разных интерфейсов + еще и управление кэширующими DNS-серверами.

Я про что и говорю, почему бы в systemd-resolvd(или какой-нибудь
resolvctl) не добавить возможность запуска с указанием нужных данных,
что бы в хуках etcnet, pppd, NetworkManager и т.п. использовать
напрямую systemd-resolvd.

> К тому же нынешний resolved вообще противоречит логике самого systemd. По
> сути он просто реагирует на события inotify, но вместо того чтобы
> использовать unit.path зачем-то сделан постоянно запущеный сервис.



-- 
Alexey Shabalin

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

On Fri, Aug 15, 2014 at 02:04:04PM +0400, Alexey Shabalin wrote:

>>> Вроде в master(будущий v216) сильно-сильно переработали resolved.
>> Можно ссылки на то как именно?
> http://cgit.freedesktop.org/systemd/systemd/tree/src/resolve

Меня глючит, или они решили кэширующий DNS туда засунуть?

>> Там еще засада -- openresolv решает две задачи -- сборка resolv.conf из
>> данных с разных интерфейсов + еще и управление кэширующими DNS-серверами.
> Я про что и говорю, почему бы в systemd-resolvd(или какой-нибудь
> resolvctl) не добавить возможность запуска с указанием нужных данных,
> что бы в хуках etcnet, pppd, NetworkManager и т.п. использовать
> напрямую systemd-resolvd.

В принципе это и сейчас почти что можно сделать -- для этого нужно нужный
файлики в /run создать. resolved оттуда все читает.

Сейчас networkd и resolved очень тесно друг с другом связаны. Все что
нужно -- чтобы их интерфейс взаимодействия из внутреннего стал публичным,
и тогда туда будет легко вклиниться.

Только повторюсь -- openresolv это больше чем генерирование resolv.conf.
Поэтому надо либо реализовывать весь функционал openresolv в рамках
resolved, либо наоборот обеспечивать возможность работы _без_ resolved.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Wed, 13 Aug 2014 00:11:21 +0400 Денис Смирнов wrote:
> On Tue, Aug 12, 2014 at 07:41:30PM +0400, Mikhail Efremov wrote:
> 
> >> race может быть только в одном случае -- если модифицируется с небольшим
> >> интервалом, скажем, /etc/resolv.conf и /etc/hosts. Тогда, если второй файл
> >> был изменен после запуска, но до завершения юнита с синхронизацией --
> >> повторно он вызван не будет.
> > Я про race при одновременном запуске из юнит-файла и из хука для
> > resolvconf'а. Это всегда будет происходить одновременно при
> > изменении /etc/resolv.conf resolvconf'ом.
> 
> Два приложения пишут в один и тот же файл одни и те же данные. Предполагаю
> что это не приведет к повреждению данных.

При одновременном доступе к одному и тому же ресурсу проблемы могут
быть всегда.

> Хотя, конечно, хорошо бы отучить openresolv от ручного вызова
> update_chrooted при работе из под systemd.

Он просто запускает хуки из /etc/hooks/resolv.conf.d/ при
изменении /etc/resolv.conf. Положить туда хук может кто угодно (сейчас
там только хуки из пакетов avahi-daemon и chrooted, но могут появиться
и другие). И если хочется делать что-то подобное без resolvconf, то
запускать надо бы именно эти хуки (правда resolvconf может
экспортировать туда некоторые переменные, но существующие хуки никаких
resolvconf-специфичных переменных не используют), а не только прибитый
гвоздями в юнит-файле update_chrooted.
Вообще вариантов несколько:
1. Считать, что resolvconf используется всегда и тогда вообще не надо
следить за /etc/resolv.conf, resolvconf все сделает сам. Мне кажется,
что это предпочтительный вариант в данном случае.
2. При изменении /etc/resolv.conf проверять наличие /sbin/resolvconf и
ничего не делать если он присутствует.
3. В resolvconf не запускать хуки при наличие systemd. Мне сильно не
нравится этот вариант, resolvconf вообще не должны заботить такие вещи.
Делать так - только разводить бардак и странные неочевидные хаки.

-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Wed, 13 Aug 2014 00:09:33 +0400 Денис Смирнов wrote:
> On Tue, Aug 12, 2014 at 05:38:41PM +0400, Mikhail Efremov wrote:
> 
> > Я не уверен, что это правильное место. Openresolv - это просто
> > инструмент, который должен использоваться вместо прямой записи
> > в /etc/resolv.conf. И заботиться о том, чтобы его правильно
> > использовать, должен тот, кто использует. В данном случае -
> > systemd-resolvd.
> > Сам же инструмент не должен знать о том, кто и как его использует. 
> 
> Тут такая штука -- есть системообразующие сервисы, и есть дополнительные
> модули, реализующие некоторую функциональность.
> 
> systemd -- более "системообразующий" чем openresolv.
> 
> Однако, стоит заметить, systemd-networkd _у нас_ отнюдь не
> системообразующий. И его стоило бы напару с systemd-resolve вынести в
> отдельный пакет. В который и положить соответствующие unit'ы.

Пожалуй это лучший вариант.

> Ибо systemd-networkd у нас всего лишь одно из множества приложений,
> которые умеют поднимать интерфейсы и получать адреса.
> 



-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Alexey Shabalin]

15 августа 2014 г., 17:59 пользователь Mikhail Efremov
<sem@altlinux.ru> написал:
> On Wed, 13 Aug 2014 00:09:33 +0400 Денис Смирнов wrote:
>> On Tue, Aug 12, 2014 at 05:38:41PM +0400, Mikhail Efremov wrote:
>>
>> > Я не уверен, что это правильное место. Openresolv - это просто
>> > инструмент, который должен использоваться вместо прямой записи
>> > в /etc/resolv.conf. И заботиться о том, чтобы его правильно
>> > использовать, должен тот, кто использует. В данном случае -
>> > systemd-resolvd.
>> > Сам же инструмент не должен знать о том, кто и как его использует.
>>
>> Тут такая штука -- есть системообразующие сервисы, и есть дополнительные
>> модули, реализующие некоторую функциональность.
>>
>> systemd -- более "системообразующий" чем openresolv.
>>
>> Однако, стоит заметить, systemd-networkd _у нас_ отнюдь не
>> системообразующий. И его стоило бы напару с systemd-resolve вынести в
>> отдельный пакет. В который и положить соответствующие unit'ы.
>
> Пожалуй это лучший вариант.

вот таск с отдельным пакетом systemd-networkd
http://git.altlinux.org/tasks/127230/
дайте мне уже юниты, которые вы хотите добавить. а то я уже запутался
в обсуждениях.

>> Ибо systemd-networkd у нас всего лишь одно из множества приложений,
>> которые умеют поднимать интерфейсы и получать адреса.

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Thu, 14 Aug 2014 19:09:07 +0400 Alexey Shabalin wrote:
> 13 августа 2014 г., 16:07 пользователь Денис Смирнов написал:
> > On Tue, Aug 12, 2014 at 08:06:44PM +0400, Mikhail Efremov wrote:
> >
> >> Конечно лучше было бы генерить отдельные resolv.conf для каждого
> >> интерфейса. Но большей беды в том, что там генерится общий resolv.conf
> >> тоже нет: интерфейсы через которые доступны эти ДНС-сервера подняты.
> >
> > У systemd-resolve есть еще одна очень большая неприятная особенность при
> > использовании с openresolv -- у него внутрь прошиты дефолтные DNS'ы. И он
> > их _всегда_ анонсирует.
> >
> > Так что с дефолтными конфигами он в принципе никогда не будет генерировать
> > пустой resolv.conf.
> 
> Вроде в master(будущий v216) сильно-сильно переработали resolved.
> А вообще, если мы хотим как-то влиять на ход разработки systemd, и
> получить нужные нам фичи, то надо общаться с апстримом. Хотя бы
> послать запрос.
> Например, почему бы не реализовать функционал openresolv в самом
> systemd-resolvd, и сделать совместимым способ управления с openresolv.

Еще раз, resolvconf - это инструмент, который должен использоваться
вместо прямой записи в /etc/resolv.conf. Он уже есть, его не надо
заново писать, им просто должны пользоваться все, кто хочет писать
в /etc/resolv.conf. А добавлять им DNS-сервера можно хоть руками.

-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

On Fri, Aug 15, 2014 at 06:07:49PM +0400, Mikhail Efremov wrote:

> Еще раз, resolvconf - это инструмент, который должен использоваться
> вместо прямой записи в /etc/resolv.conf. Он уже есть, его не надо
> заново писать, им просто должны пользоваться все, кто хочет писать
> в /etc/resolv.conf. А добавлять им DNS-сервера можно хоть руками.

Повторюсь -- у нас разумнее всего юзать openresolv. Но в апстрим это
никогда не войдет, ибо openresolv это стопка скриптов на shell. А у
Поттеринг на шелл аллергия.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Mikhail Efremov]

[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]

On Fri, 15 Aug 2014 18:04:24 +0400 Alexey Shabalin wrote:
> 15 августа 2014 г., 17:59 пользователь Mikhail Efremov
> <sem@altlinux.ru> написал:
> > On Wed, 13 Aug 2014 00:09:33 +0400 Денис Смирнов wrote:
> >> On Tue, Aug 12, 2014 at 05:38:41PM +0400, Mikhail Efremov wrote:
> >>
> >> > Я не уверен, что это правильное место. Openresolv - это просто
> >> > инструмент, который должен использоваться вместо прямой записи
> >> > в /etc/resolv.conf. И заботиться о том, чтобы его правильно
> >> > использовать, должен тот, кто использует. В данном случае -
> >> > systemd-resolvd.
> >> > Сам же инструмент не должен знать о том, кто и как его использует.
> >>
> >> Тут такая штука -- есть системообразующие сервисы, и есть дополнительные
> >> модули, реализующие некоторую функциональность.
> >>
> >> systemd -- более "системообразующий" чем openresolv.
> >>
> >> Однако, стоит заметить, systemd-networkd _у нас_ отнюдь не
> >> системообразующий. И его стоило бы напару с systemd-resolve вынести в
> >> отдельный пакет. В который и положить соответствующие unit'ы.
> >
> > Пожалуй это лучший вариант.
> 
> вот таск с отдельным пакетом systemd-networkd
> http://git.altlinux.org/tasks/127230/
> дайте мне уже юниты, которые вы хотите добавить. а то я уже запутался
> в обсуждениях.

Вот слегка отредактированные юниты, которые тут ранее предлагал Денис.
Не проверял, но должно работать. Возможно еще стоит добавить Also чтобы
включался одновременно с systemd-resolved.service (или это в
systemd-resolved.service надо Also добавить?)

-- 
WBR, Mikhail Efremov

[-- Attachment #2: altlinux-openresolv.path --]
[-- Type: application/octet-stream, Size: 219 bytes --]

[-- Attachment #3: altlinux-openresolv.service --]
[-- Type: application/octet-stream, Size: 295 bytes --]

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Fri, 15 Aug 2014 18:15:18 +0400 Денис Смирнов wrote:
> On Fri, Aug 15, 2014 at 06:07:49PM +0400, Mikhail Efremov wrote:
> 
> > Еще раз, resolvconf - это инструмент, который должен использоваться
> > вместо прямой записи в /etc/resolv.conf. Он уже есть, его не надо
> > заново писать, им просто должны пользоваться все, кто хочет писать
> > в /etc/resolv.conf. А добавлять им DNS-сервера можно хоть руками.
> 
> Повторюсь -- у нас разумнее всего юзать openresolv. Но в апстрим это
> никогда не войдет, ибо openresolv это стопка скриптов на shell. А у
> Поттеринг на шелл аллергия.

Ну, я же говорю, что есть надежда на Debian. В конце концов resolvconf
- это их изобретение и они его используют давно и везде, AFAIK
(openresolv - это альтернативная реализация с некоторыми
дополнительными плюшками).

-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

On Fri, Aug 15, 2014 at 06:28:10PM +0400, Mikhail Efremov wrote:
> Вот слегка отредактированные юниты, которые тут ранее предлагал Денис.
> Не проверял, но должно работать. Возможно еще стоит добавить Also чтобы
> включался одновременно с systemd-resolved.service (или это в
> systemd-resolved.service надо Also добавить?)

Тут засада -- это-ж oneshot по изменению файла. Так что ExecStop
бесполезен.

А что самое печальное -- при остановке systemd-resolved сгенерированый им
файлик не удаляется. И как реагировать на удаление (если делать его в
ExecStopPost у самого resolved) я тоже не нашел.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Alexey Shabalin]

15 августа 2014 г., 18:33 пользователь Mikhail Efremov  написал:
> On Fri, 15 Aug 2014 18:15:18 +0400 Денис Смирнов wrote:
>> On Fri, Aug 15, 2014 at 06:07:49PM +0400, Mikhail Efremov wrote:
>>
>> > Еще раз, resolvconf - это инструмент, который должен использоваться
>> > вместо прямой записи в /etc/resolv.conf. Он уже есть, его не надо
>> > заново писать, им просто должны пользоваться все, кто хочет писать
>> > в /etc/resolv.conf. А добавлять им DNS-сервера можно хоть руками.
>>
>> Повторюсь -- у нас разумнее всего юзать openresolv. Но в апстрим это
>> никогда не войдет, ибо openresolv это стопка скриптов на shell. А у
>> Поттеринг на шелл аллергия.
>
> Ну, я же говорю, что есть надежда на Debian. В конце концов resolvconf
> - это их изобретение и они его используют давно и везде, AFAIK
> (openresolv - это альтернативная реализация с некоторыми
> дополнительными плюшками).

Ну вот я вижу у Debian
http://anonscm.debian.org/cgit/resolvconf/resolvconf.git/tree/debian/resolvconf.service
Но мне это не внушает доверия.

-- 
Alexey Shabalin

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Fri, 15 Aug 2014 19:28:09 +0400 Денис Смирнов wrote:
> On Fri, Aug 15, 2014 at 06:28:10PM +0400, Mikhail Efremov wrote:
> > Вот слегка отредактированные юниты, которые тут ранее предлагал Денис.
> > Не проверял, но должно работать. Возможно еще стоит добавить Also чтобы
> > включался одновременно с systemd-resolved.service (или это в
> > systemd-resolved.service надо Also добавить?)
> 
> Тут засада -- это-ж oneshot по изменению файла. Так что ExecStop
> бесполезен.

Разве? Мне казалось, что ExecStop должен выполняться в любом случае при
остановке сервиса. А с RemainAfterExit он должен считаться запущенным.
Хотя с RemainAfterExit может быть другая проблема, я не знаю какое
будет поведение при следующем изменении файла. Он, часом, не
проигнорирует запуск т.к. сервис уже running?
Проверять надо. Может на следующей неделе в kvm попробую если время
будет.

> А что самое печальное -- при остановке systemd-resolved сгенерированый им
> файлик не удаляется. И как реагировать на удаление (если делать его в
> ExecStopPost у самого resolved) я тоже не нашел.

Можно удалять файл в ExecStopPost в systemd-resolved.service и
запускать /sbin/resolvconf -fd systemd-networkd и там тоже. Или даже
только там.

-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Fri, 15 Aug 2014 19:47:56 +0400 Alexey Shabalin wrote:
> 15 августа 2014 г., 18:33 пользователь Mikhail Efremov  написал:
> > On Fri, 15 Aug 2014 18:15:18 +0400 Денис Смирнов wrote:
> >> On Fri, Aug 15, 2014 at 06:07:49PM +0400, Mikhail Efremov wrote:
> >>
> >> > Еще раз, resolvconf - это инструмент, который должен использоваться
> >> > вместо прямой записи в /etc/resolv.conf. Он уже есть, его не надо
> >> > заново писать, им просто должны пользоваться все, кто хочет писать
> >> > в /etc/resolv.conf. А добавлять им DNS-сервера можно хоть руками.
> >>
> >> Повторюсь -- у нас разумнее всего юзать openresolv. Но в апстрим это
> >> никогда не войдет, ибо openresolv это стопка скриптов на shell. А у
> >> Поттеринг на шелл аллергия.
> >
> > Ну, я же говорю, что есть надежда на Debian. В конце концов resolvconf
> > - это их изобретение и они его используют давно и везде, AFAIK
> > (openresolv - это альтернативная реализация с некоторыми
> > дополнительными плюшками).
> 
> Ну вот я вижу у Debian
> http://anonscm.debian.org/cgit/resolvconf/resolvconf.git/tree/debian/resolvconf.service
> Но мне это не внушает доверия.

Да, это что-то debian-specific. В openresolv у resolvconf нет таких
опций, надо будет почитать их resolvconf. Что-то у меня подозрение, что
они там что-то странное наворотили.

-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

On Fri, Aug 15, 2014 at 07:50:18PM +0400, Mikhail Efremov wrote:

>> Тут засада -- это-ж oneshot по изменению файла. Так что ExecStop
>> бесполезен.
> Разве? Мне казалось, что ExecStop должен выполняться в любом случае при
> остановке сервиса.

Именно! А кто у нас будет его _останавливать_? У нас есть событие для
запуска, которое его дергает, но нет события, которое бы делало stop.

> А с RemainAfterExit он должен считаться запущенным.
> Хотя с RemainAfterExit может быть другая проблема, я не знаю какое
> будет поведение при следующем изменении файла. Он, часом, не
> проигнорирует запуск т.к. сервис уже running?
> Проверять надо. Может на следующей неделе в kvm попробую если время
> будет.

>> А что самое печальное -- при остановке systemd-resolved сгенерированый им
>> файлик не удаляется. И как реагировать на удаление (если делать его в
>> ExecStopPost у самого resolved) я тоже не нашел.
> Можно удалять файл в ExecStopPost в systemd-resolved.service и
> запускать /sbin/resolvconf -fd systemd-networkd и там тоже. Или даже
> только там.

Ага, то есть проверять на наличие /sbin/resolvconf, и если есть --
выполнять. Логично.

-- 
С уважением, Денис

http://mithraen.ru/


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1.1: Type: text/plain, Size: 259 bytes --]

On Fri, Aug 15, 2014 at 06:04:24PM +0400, Alexey Shabalin wrote:

> дайте мне уже юниты, которые вы хотите добавить. а то я уже запутался
> в обсуждениях.

В аттаче то, что прямо сейчас у меня работает.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #1.2: altlinux-openresolv.path --]
[-- Type: text/plain, Size: 180 bytes --]

[Unit]
Description=Update openresolv data from systemd-resolved
Before=paths.target
ConditionFileIsExecutable=/sbin/resolvconf

[Path]
PathChanged=/run/systemd/resolve/resolv.conf

[-- Attachment #1.3: altlinux-openresolv.service --]
[-- Type: text/plain, Size: 226 bytes --]

[Unit]
Description=Update openresolv data from systemd-resolved
ConditionFileIsExecutable=/sbin/resolvconf

[Service]
Type=oneshot
ExecStart=/bin/sh -c '/sbin/resolvconf -a systemd-networkd < /run/systemd/resolve/resolv.conf'

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Fri, 15 Aug 2014 19:55:56 +0400 Mikhail Efremov wrote:
> On Fri, 15 Aug 2014 19:47:56 +0400 Alexey Shabalin wrote:
> > 15 августа 2014 г., 18:33 пользователь Mikhail Efremov  написал:
> > > On Fri, 15 Aug 2014 18:15:18 +0400 Денис Смирнов wrote:
> > >> On Fri, Aug 15, 2014 at 06:07:49PM +0400, Mikhail Efremov wrote:
> > >>
> > >> > Еще раз, resolvconf - это инструмент, который должен использоваться
> > >> > вместо прямой записи в /etc/resolv.conf. Он уже есть, его не надо
> > >> > заново писать, им просто должны пользоваться все, кто хочет писать
> > >> > в /etc/resolv.conf. А добавлять им DNS-сервера можно хоть руками.
> > >>
> > >> Повторюсь -- у нас разумнее всего юзать openresolv. Но в апстрим это
> > >> никогда не войдет, ибо openresolv это стопка скриптов на shell. А у
> > >> Поттеринг на шелл аллергия.
> > >
> > > Ну, я же говорю, что есть надежда на Debian. В конце концов resolvconf
> > > - это их изобретение и они его используют давно и везде, AFAIK
> > > (openresolv - это альтернативная реализация с некоторыми
> > > дополнительными плюшками).
> > 
> > Ну вот я вижу у Debian
> > http://anonscm.debian.org/cgit/resolvconf/resolvconf.git/tree/debian/resolvconf.service
> > Но мне это не внушает доверия.
> 
> Да, это что-то debian-specific. В openresolv у resolvconf нет таких
> опций, надо будет почитать их resolvconf. Что-то у меня подозрение, что
> они там что-то странное наворотили.

А, нет. Это просто выставление флага о том, что надо запускать
subscribers и их запуск. У нас я не вижу необходимости в чем-то
аналогичном.

-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Mikhail Efremov]

On Fri, 15 Aug 2014 20:45:48 +0400 Денис Смирнов wrote:
> On Fri, Aug 15, 2014 at 06:04:24PM +0400, Alexey Shabalin wrote:
> 
> > дайте мне уже юниты, которые вы хотите добавить. а то я уже запутался
> > в обсуждениях.
> 
> В аттаче то, что прямо сейчас у меня работает.

Тогда лучше эти юниты запаковать. Доработать всегда успеем.

-- 
WBR, Mikhail Efremov

Re: [sisyphus] systemd-network

[Alexey Shabalin]

15 августа 2014 г., 20:29 пользователь Денис Смирнов
<mithraen@freesource.info> написал:
> On Fri, Aug 15, 2014 at 07:50:18PM +0400, Mikhail Efremov wrote:
>
>>> Тут засада -- это-ж oneshot по изменению файла. Так что ExecStop
>>> бесполезен.
>> Разве? Мне казалось, что ExecStop должен выполняться в любом случае при
>> остановке сервиса.
>
> Именно! А кто у нас будет его _останавливать_? У нас есть событие для
> запуска, которое его дергает, но нет события, которое бы делало stop.
>
>> А с RemainAfterExit он должен считаться запущенным.
>> Хотя с RemainAfterExit может быть другая проблема, я не знаю какое
>> будет поведение при следующем изменении файла. Он, часом, не
>> проигнорирует запуск т.к. сервис уже running?
>> Проверять надо. Может на следующей неделе в kvm попробую если время
>> будет.
>
>>> А что самое печальное -- при остановке systemd-resolved сгенерированый им
>>> файлик не удаляется. И как реагировать на удаление (если делать его в
>>> ExecStopPost у самого resolved) я тоже не нашел.
>> Можно удалять файл в ExecStopPost в systemd-resolved.service и
>> запускать /sbin/resolvconf -fd systemd-networkd и там тоже. Или даже
>> только там.
>
> Ага, то есть проверять на наличие /sbin/resolvconf, и если есть --
> выполнять. Логично.

Отправляю в сизиф то, что выдали.

я бы вообще не делал нового юнита altlinux-openresolv.service, а
просто добавил бы:
ExecStartPost и ExecStopPost прямо в systemd-resolved.service.
если указать команды начиная с "-" (=-/bin/sh.....) то юнит не будет
ругаться на отсутствующий /sbin/resolvconf.

ExecStartPost=-/bin/sh -c '/sbin/resolvconf -a systemd-networkd <
/run/systemd/resolve/resolv.conf'
ExecStopPost=-/sbin/resolvconf -fd systemd-networkd

А с другой стороны, в altlinux-openresolv.service(или path) можно
проверять наличие симлинка /etc/resolv.conf и не запускаться, вдруг
уже кто-то использует без openresolv.
ConditionPathIsSymbolicLink=!/etc/resolv.conf
еще в altlinux-openresolv.service можно добавить
ReloadPropagatedFrom=systemd-resolved.service
или даже лучше
PartOf=systemd-resolved.service

-- 
Alexey Shabalin

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

On Fri, Aug 15, 2014 at 10:39:19PM +0400, Alexey Shabalin wrote:

> я бы вообще не делал нового юнита altlinux-openresolv.service, а
> просто добавил бы:
> ExecStartPost и ExecStopPost прямо в systemd-resolved.service.
> если указать команды начиная с "-" (=-/bin/sh.....) то юнит не будет
> ругаться на отсутствующий /sbin/resolvconf.

resolv.conf может меняться уже после запуска systemd-resolved.service, в
процессе его работы.

resolved это сервис, который через inotify следит за
/run/systemd/netif/links, и DNS'ы использует для перегенерирования
/run/systemd/resolve/resolv.conf.

Так что в качестве триггера на обновление годится исключительно
изменение /run/systemd/resolve/resolv.conf

> ExecStartPost=-/bin/sh -c '/sbin/resolvconf -a systemd-networkd <
> /run/systemd/resolve/resolv.conf'
> ExecStopPost=-/sbin/resolvconf -fd systemd-networkd

А вот реагировать на останов действительно стоит. 

> А с другой стороны, в altlinux-openresolv.service(или path) можно
> проверять наличие симлинка /etc/resolv.conf и не запускаться, вдруг
> уже кто-то использует без openresolv.
> ConditionPathIsSymbolicLink=!/etc/resolv.conf

С этим согласен полностью.

> еще в altlinux-openresolv.service можно добавить
> ReloadPropagatedFrom=systemd-resolved.service
> или даже лучше
> PartOf=systemd-resolved.service

А что это даст? Если systemd-resolved перезапустился нам это ничего не
дает. /run/systemd/resolve/resolv.conf может меняться сколько угодно без
всякого reload у systemd-resolved.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

On Fri, Aug 15, 2014 at 05:58:28PM +0400, Mikhail Efremov wrote:

> Он просто запускает хуки из /etc/hooks/resolv.conf.d/ при
> изменении /etc/resolv.conf. Положить туда хук может кто угодно (сейчас
> там только хуки из пакетов avahi-daemon и chrooted, но могут появиться
> и другие).

Тогда нужно просто исправить /etc/hook/resolv.conf.d:

[ /sbin/sd_booted ] || update_chrooted conf

> И если хочется делать что-то подобное без resolvconf, то
> запускать надо бы именно эти хуки (правда resolvconf может
> экспортировать туда некоторые переменные, но существующие хуки никаких
> resolvconf-специфичных переменных не используют), а не только прибитый
> гвоздями в юнит-файле update_chrooted.

Стоп, давай не путать два совершенно разных юнита для двух совершенно
разных задач.

Одна задача -- сотрудничество между systemd-resolved и openresolv.

Совершенно другая задача -- при изменении одного из целого списка файлов,
необходимых libresolv перенести их в chroot.

Это две совершенно разные задачи. Хотя после выполнения первой обязательно
выполнение второй, эта самая вторая нужна совершенно независимо.

> Вообще вариантов несколько:
> 1. Считать, что resolvconf используется всегда и тогда вообще не надо
> следить за /etc/resolv.conf, resolvconf все сделает сам. Мне кажется,
> что это предпочтительный вариант в данном случае.

Повторюсь -- следить надо не только за resolv.conf. Например еще есть
hosts. openresolv его не трогает, но при его изменении необходимо вызывать
update_chrooted.

> 2. При изменении /etc/resolv.conf проверять наличие /sbin/resolvconf и
> ничего не делать если он присутствует.
> 3. В resolvconf не запускать хуки при наличие systemd. Мне сильно не
> нравится этот вариант, resolvconf вообще не должны заботить такие вещи.
> Делать так - только разводить бардак и странные неочевидные хаки.

Не все "хуки", а один конкретный -- вызов update_chrooted.

-- 
С уважением, Денис

http://mithraen.ru/


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

On Thu, Aug 14, 2014 at 07:09:07PM +0400, Alexey Shabalin wrote:

>> У systemd-resolve есть еще одна очень большая неприятная особенность при
>> использовании с openresolv -- у него внутрь прошиты дефолтные DNS'ы. И он
>> их _всегда_ анонсирует.
>> Так что с дефолтными конфигами он в принципе никогда не будет генерировать
>> пустой resolv.conf.
> Вроде в master(будущий v216) сильно-сильно переработали resolved.

Боюсь конкретно написанное выше это не баг, это фича. Дефолтными туда в
код вшиты гуглевые DNS'ы, которые всегда анонсируются. И не анонсируются
они только если об этом прямо попросили в конфиге.

Это одно из решений в рамках работы с пустым /etc.

> А вообще, если мы хотим как-то влиять на ход разработки systemd, и
> получить нужные нам фичи, то надо общаться с апстримом. Хотя бы
> послать запрос.
> Например, почему бы не реализовать функционал openresolv в самом
> systemd-resolvd, и сделать совместимым способ управления с openresolv.

Я не представляю себе как это сделать, и мой английский не настолько
хорош, чтобы вести конструктивные беседы с апстримом.

-- 
С уважением, Денис

http://mithraen.ru/


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd-network

[Вадим Илларионов]

[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]

В письме от 10 августа 2014 06:57:20 пользователь Денис Смирнов написал:
> On Sat, Aug 09, 2014 at 02:26:20PM +0900, Вадим Илларионов wrote:
> > Уже участвовал. Модуль опенвпн для неё делал.
> > Устало удручать, что один и тот же баг которую версию кряду приходится
> > чинить после каждого обновления, вручную добавляя в config-fw подгрузку
> > xtables_preload. Иначе ломается фаервол, прописанный человечьим языком.
> > Хватит с меня.
> 
> Номер бага на bugzilla и патч есть?

Багзиллу доселе не юзал, посему патч пока сюда. Что он даёт:
1. Исправлена неработоспособность iptables, когда правила написаны в human 
syntax.
2. Исправлена неработоспособность ipset, так как его опции, применяемые в 
эцнете, давно не соответствуют реалиям.
3. Исправлена опция включения списков ipset в iptables (--set vs --match-set).
4. Добавлена возможность написания инверсных правил ipset (not-in-set: -mset ! 
--match-set).
5. Для совместимости с синтаксисом ipset исключены трансляции src: --src и 
dst: --dst.
6. Добавлен протокол OSPF (ospf: --protocol OSPF).
_______________________________
С уважением, *nix-администратор
Mobile: +7 (964) 103-65-67
Skype: gbIMoBou
JID = <mailto:>
Viber = Mobile
UIN: 7899517

[-- Attachment #2: etcnet.patch --]
[-- Type: text/x-patch, Size: 2843 bytes --]

--- etc/net/scripts/config-fw.old	2014-08-26 19:50:34.000000000 +0900
+++ etc/net/scripts/config-fw	2014-09-04 14:55:04.388200175 +0900
@@ -94,7 +94,8 @@
 				    unset IPTABLES_SYNTAX IPTABLES_SED_RULES
 				}
 			}
-		    xtables_${ACTION} "$NAME"
+			xtables_preload
+			xtables_${ACTION} "$NAME"
 		    ;;
         "ip6tables")
 		    # FIXME Does ip6tables support only IPv6?
@@ -115,7 +116,8 @@
 				    unset IP6TABLES_SYNTAX IP6TABLES_SED_RULES
 				}
 			}
-		    xtables_${ACTION} "$NAME"
+			xtables_preload
+			xtables_${ACTION} "$NAME"
 		    ;;
 	"ebtables")
 		    profiled_filename_dir cfwdir "$MYIFACEDIR/fw/$CFW_TYPE" ||
@@ -125,7 +127,8 @@
 			    print_error "$EBTABLES not found. Please, install ebtables package"
 			    continue
 			}
-		    xtables_${ACTION} "$NAME"
+			xtables_preload
+			xtables_${ACTION} "$NAME"
 		    ;;
 		
 	*)
--- etc/net/scripts/functions-fw-old	2014-08-26 19:50:34.000000000 +0900
+++ etc/net/scripts/functions-fw	2014-08-29 09:22:03.522038299 +0900
@@ -421,11 +421,11 @@
 
     [ -n "$HEADER" ] || return 0
     print_message -e "\tCreating the \"$SET\" set of the \"$TYPE\" type"
-    eval "$IPSET -N $SET $TYPE $HEADER" || print_error "$IPSET -N $SET $TYPE $HEADER"
+    eval "$IPSET create $SET $TYPE" || print_error "$IPSET create $SET $TYPE"
 
     [ -n "$MEMBERS" ] || return 0
     while read; do
-	eval "$IPSET -A $SET $REPLY" || print_error "$IPSET -A $SET $REPLY"
+	eval "$IPSET add $SET $REPLY" || print_error "$IPSET add $SET $REPLY"
     done <<<"$MEMBERS"
 }
 
@@ -439,7 +439,7 @@
 
     [ -n "$RULE" ] || return 0
     print_message -e "\tDestroying the \"$SET\" set of the \"$TYPE\" type"
-    eval "$IPSET -X $SET" || print_error "$IPSET -X $SET"
+    eval "$IPSET destroy $SET" || print_error "$IPSET destroy $SET"
 }
 
 ipset_start()
--- etc/net/ifaces/default/fw/iptables/syntax.old	2014-08-26 19:50:34.000000000 +0900
+++ etc/net/ifaces/default/fw/iptables/syntax	2014-09-04 15:08:22.064312826 +0900
@@ -175,9 +175,12 @@
 physdev-is-out: -mphysdev --physdev-is-out
 physdev-is-bridged: -mphysdev --physdev-is-bridged
 pkttype: -mpkttype --pkt-type
-random: -mrandom --average 
+random: -mrandom --average
 realm: -mrealm --realm
-set: -mset --set
+set: -mset --match-set
+in-set: -mset --match-set
+out-set: -mset ! --match-set
+not-in-set: -mset ! --match-set
 state: -mstate --state
 tcp-source-port: -mtcp --source-port
 tcp-src-port: -mtcp --source-port
@@ -212,10 +215,8 @@
 
 # Parameters
 from: --src
-src: --src
 source: --src
 to: --dst
-dst: --dst
 destination: --dst
 sport: --source-port
 src-port: --source-port
@@ -234,6 +235,7 @@
 udp: --protocol UDP
 icmp: --protocol ICMP
 gre: --protocol GRE
+ospf: --protocol OSPF
 jump: -j 
 jump-to: -j
 any: 0.0.0.0/0

Re: [sisyphus] systemd-network

[Alexey Shabalin]

8 августа 2014 г., 4:16 пользователь Вадим Илларионов
<gbimobou@gmail.com> написал:
> В письме от 7 августа 2014 16:32:03 пользователь Денис Смирнов написал:
>> systemd-networkd
>
> Вдогонку.
>
> Невзирая на нетривиальную конфигурацию (а может, как раз благодаря ей),
> хотелось бы таки попробовать обойтись без etcnet'а.
>
> Аплинк - 8-портовый киско-рутер, хоть и одомашненный, но умеющий вланы, лацп и
> прочие плюшки.
> Шлюз на обычной офисной материнке, но с 2-портовой igb-шкой (тут LACP).
> Вафельная точка доступа воткнута во встроенную сетевуху.
> Снаружи 3 тегированных влана - корпоративный, абонентский и одного юрика,
> нашего клиента.
> Вниз смотрит мост home, соединяющий вафлю с проводным бондом.
> Под етснетом всё работает.
> Соорудив же вот такую конфигурацию, сносить етснет и ребутиться боюсь:
>
> for f in /etc/systemd/network/*; do echo -e "\n`basename $f`\n--------"; grep
> -v ^# $f; done
>
> 00.enp2s0.network
> --------
> [Match]
> Name=enp2s0
>
> [Network]
> Description=RealTek GigaBit Card
> Bridge=home
>
> 00.enp5s0f.network
> --------
> [Match]
> Bond=bond
> Name=enp5s0f*
>
> [Network]
> Description=Intel Dual GigaBit Card
>
> 10.bond.netdev
> --------
> [NetDev]
> Description=Dual IGB LACP Link
> Kind=bond
> Name=bond
>
> [Bond]
> Mode=802.3ad
>
> 10.bond.network
> --------
> [Match]
> Name=bond
>
> [Network]
> Bridge=home
>
> 20.home.netdev
> --------
> [NetDev]
> Description=Bridge between Dual IGB & RealTek GigaBit cards
> Kind=bridge
> Name=home
>
> 20.home.network
> --------
> [Match]
> Name=home
>
> [Network]
> Address=192.168.6.254/24
> Gateway=192.168.6.254
> DNS=192.168.6.254
>
> 30.abon.netdev
> --------
> [NetDev]
> Description=Abonent VLAN
> Kind=vlan
> Name=abon
>
> [VLAN]
> Id=51
>
> 30.abon.network
> --------
> [Match]
> Name=abon
>
> [Network]
> DHCP=yes
>
> 40.corp.netdev
> --------
> [NetDev]
> Description=Corporate VLAN
> Kind=vlan
> Name=corp
>
> [VLAN]
> Id=4094
>
> 40.corp.network
> --------
> [Match]
> Name=corp
>
> [Network]
> DHCP=yes
>
> 50.nf.netdev
> --------
> [NetDev]
> Description=Voronkin VLAN
> Kind=vlan
> Name=nf
>
> [VLAN]
> Id=701
>
> 50.nf.network
> --------
> [Match]
> Name=nf
>
> [Network]
> DHCP=yes
>
> Денис, глянь, пожалуйста, всё ль в порядке?



Я приведу свой вариант успешной настройки не совсем тривиальной
конфигурации. Простые варианты, типа DHCP или статической настройки
одного интерфейса, рассмотрены в документации systemd-networkd.
Имеется несколько сетевых плат, их надо объединить в port-channel, со
стороны свича подаётся транк, из него надо взять vlan140 для
виртуалок, и на нём же назначить адрес хостовой машины для доступа:

все настройки в /etc/systemd/network/

1) создаём bond0 интерфейс на физических интерфейсах enp4s0 и  enp6s0:
10-create-bond0.network:
[Match]
Name=enp*

[Network]
Bond=bond0
----------------
20-setup-bond0.netdev:
[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=802.3ad
TransmitHashPolicy=encap3+4
LACPTransmitRate=slow
MIIMonitorSec=1s
UpDelaySec=2s
DownDelaySec=4s
----------------------
на всякий случай добавляю в
 /etc/modprobe.d/bonding.conf:
options bonding mode=4
options bonding lacp_rate=0
options bonding ad_select=1
options bonding xmit_hash_policy=1
options bonding miimon=1000
options bonding updelay=2000
options bonding downdelay=4000

2) создаем интерфейс vlan140 на bond0:

30-create-vlan141.network:
[Match]
Name=bond0

[Network]
VLAN=vlan140
----------------------
40-setup-vlan140.netdev:
[NetDev]
Name=vlan140
Kind=vlan

[VLAN]
Id=140

3) создаем бридж br140 в который включён vlan140
50-create-br140.network:
[Match]
Name=vlan140

[Network]
Bridge=br140
--------------
60-setup-br140.netdev:
[NetDev]
Name=br140
Kind=bridge

4) заключительным этапом создаём интерфейс для доступа к хосту:
90-management.network:
[Match]
Name=br140

[Network]
Address=1.1.1.100/24
Gateway=1.1.1.1
DNS=1.1.1.4
DNS=1.1.1.3
Domains=example.com
NTP=1.1.1.1

в зависимости от задачи, можно поменять схему, т.е. сначала делать
бридж на бондинг-интерфейсе, а потом уже выдергивать нужный vlan.
Может пригодиться если ваши виртуалки сами настраивают свой vlan.
Но надо следить за тем, что бы не создать петлю. Как включить STP в
этих конфигах, я не нашел.


-- 
Alexey Shabalin

Re: [sisyphus] systemd-network

[Вадим Илларионов]

В письме от 20 февраля 2015 21:16:43 пользователь Alexey Shabalin написал:
> Я приведу свой вариант успешной настройки не совсем тривиальной
> конфигурации. Простые варианты, типа DHCP или статической настройки
> одного интерфейса, рассмотрены в документации systemd-networkd.

Спасибо, буду пробовать.
-- 
Мимо крокодил.
WBR, rednex CIO.
Cell: +7(964)103-65-67
Viber = Cell
JID = <mailto:>
Skype = $local_part@<mailto:>