Если в /etc/net/ifaces/eth0/ipv4address маска подсети указана в виде 192.168.1.1/255.255.255.192, то в веб-интерфейсе PVE CIDR имеет значение 32. В случае, если происходит изменение настроек сети через веб-интерфейс PVE, то при сохранении настроек CIDR 32 применяется к настройкам сетевой карты и файл /etc/net/ifaces/eth0/ipv4address принимает вид: 192.168.1.1/255.255.255.255 При этом, если изначально файл /etc/net/ifaces/eth0/ipv4address имеет вид: 192.168.1.1/26, то в веб-интерфейсе PVE маска подсети отображается правильно, но после сохранения настроек из веб-интерфейса файл /etc/net/ifaces/eth0/ipv4address приводится к виду: 192.168.1.1/255.255.255.192 В результате при повторном сохранении маска выставляется неверно.
В функции __read_ipv4address_into() netmask через вызов __unwrap_netmask4() превращается из "/26" в "255.255.255.192" и перезаписывается в таком виде, при повторном вызове __unwrap_netmask4("255.255.255.192") превращает маску в "255.255.255.255", т.к. считает, что получила на входе 255, а проверок на допустимые значения там никаких нет: sub __unwrap_netmask4 { my $in=shift; my @out; while (@out<4) { if ($in>8) { push @out, '255'; $in -= 8; print "DEBUG: in=$in\n"; } else { push @out, $nm4prefix{$in}; $in = 0; } } return join('.',@out); } а после коммита 4507a5e5268f924be6627a5df8a161f7921d9243 функция __interface_to_etcnet() использует netmask без изменений (до этого netmask конвертировалась из "255.255.255.192" в "/26"). Т.е. имеет место быть интерференция старой ошибки (или неопределённого поведения) и новой фичи. Наверное, можно исправить функцию __unwrap_netmask4() так, чтобы она возвращала строку netmask без изменения, если там /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/. Тогда маска будет всегда в длинном формате. Вопрос: это именно то поведение, которое задумывалось для указанного коммита?
Created attachment 8885 [details] __unwrap_netmask4(): не конвертировать маску в формате A.B.C.D
(Ответ для Kot_Uchoniy на комментарий #0) > Если в /etc/net/ifaces/eth0/ipv4address маска подсети указана в виде > 192.168.1.1/255.255.255.192 В etcnet нельзя так указывать маску. В web интерфейсе у pve тоже маска указывается как CIDR (/24) Откуда берется такой вид маски?
(In reply to Alexey Shabalin from comment #3) > (Ответ для Kot_Uchoniy на комментарий #0) > > Если в /etc/net/ifaces/eth0/ipv4address маска подсети указана в виде > > 192.168.1.1/255.255.255.192 > > В etcnet нельзя так указывать маску. В web интерфейсе у pve тоже маска > указывается как CIDR (/24) > Откуда берется такой вид маски? Берется при перезапуске pve-cluster. Во время перезапуска этого сервиса судя по всему обновляется настройка сети для PVE и правятся настройки etcnet. И вот как раз в этот момент маска в /etc/net/ifaces/eth0/ipv4address сохраняется в таком виде. И даже больше скажу, etcnet с маской такого вида у меня работал.
читайте документацию к etcnet и проблем не будет
(Ответ для Valery Inozemtsev на комментарий #5) > читайте документацию к etcnet и проблем не будет Валера, а что мешает применить выше указанный патч для исправления? Хотелось бы исправить ошибку и иметь возможность настраивать сеть из web-интерфейса PVE, а не закрывать глаза и отправлять читать доку по etcnet.
это проявляется только в том случае если неправильно указать маску в etcnet
(Ответ для Valery Inozemtsev на комментарий #7) > это проявляется только в том случае если неправильно указать маску в etcnet При чем тут документация от etcnet, если веб-интерфейс неправильно сохраняет маску? Могу тогда порекомендовать читать доки тем, кто прорабатывал сохранение настроек PVE в etcnet. С Вашим решением не согласен, прочитайте первый коммендарий, там все описано
Created attachment 8907 [details] etcnet-to-network: принимать маску сети в длинном формате Различать формат маски сети в /etc/net/ifaces/XX/ipv4address, в PVE /etc/network/interfaces пишется в длинном формате, как и раньше. В интерфейсе PVE можно ввести только CIDR формат.
Created attachment 8908 [details] pve-common: принимать маску сети из etcnet в любом формате (компактная версия) Более короткая версия. Чтобы не потерялось.
Ошибка больше не наблюдается после выхода релиза 9.1
