А будет ли поддрержка UDEV ? а то при активации udev в /dev/ отсутсвует почти все...
Уважаемый OpenVZ team слишком за виртуализировался и забыл что sysfs надо включать не только для дистрибутивов suse, а для любого который расчитан на 2.6 ядра. (проще уж добавить опцию в конфиг - чем шаманить с именем шаблона/дистрибутива в vzctl). Кроме того неплохо бы иметь в sysfs не только class/network с данными по интерфейсам, но еще и class/tty/ptmx. Без этого не создается /dev/ptmx и не работает console multeplexer. Патч исправляющий это досадное недоразумение приатачен. PS. недавно получилось воспроизвести забавную атаку на OpenVZ. vzctl enter перевел процес в контекст VPS но при этом консоль открылась на хосте. Деталей толком нету - все что известно, это происходит при выходе за какой-то из лимитов скорее всего file limit или proc limit.
внутри VE? пока не планируется, т.к. без нее живется прекрасно %) на самом деле причины в другом. виртуализация sysfs/hotplug-events не столь простая вещь. sysfs/net-devices у нас виртуализованы, но... этого мало. Делать почестному - проблематично, а делать хаки не хочется. Плюс, помимо технических проблем есть проблемы совместимости. К сожалению, авторы sysfs/udev совершенно не озабочены совместимостью... Недавно Andrew Morton даже завернул патч от Greg KH... :/ Как Вы понимаете нам это критично...
Quote: Уважаемый OpenVZ team слишком за виртуализировался и забыл что sysfs надо включать не только для дистрибутивов suse, а для любого который расчитан на 2.6 ядра. (проще уж добавить опцию в конфиг - чем шаманить с именем шаблона/дистрибутива в vzctl). 1. Все нормальные дистрибутивы прекрасно работают и без sysfs/udev. Во многих из них, можно даже настраивать как работать. 2. sysfs был сделан опцией, т.к. на ядрах 2.6.x до какого-то момента файловая система sysfs работала так, что dentries/inodes были unreclaimable. Из-за этого sysfs даже в том виде какой он есть у нас занимал >0.5-1Mb/VE. Полный sysfs занимал бы еще в разы больше. В 2.6.16+ (по идее) его теперь можно просто всегда включать. 3. насчет конфига - правильное замечание, это просто где-то потерялось по пути в OpenVZ. http://bugzilla.openvz.org/show_bug.cgi?id=242 Quote: Кроме того неплохо бы иметь в sysfs не только class/network с данными по интерфейсам, но еще и class/tty/ptmx. Без этого не создается /dev/ptmx и не работает console multeplexer. Патч исправляющий это досадное недоразумение приатачен. Огромное спасибо за патч и за то, что помогаете не только словом, но и делом http://bugzilla.openvz.org/show_bug.cgi?id=243 Quote: PS. недавно получилось воспроизвести забавную атаку на OpenVZ. vzctl enter перевел процес в контекст VPS но при этом консоль открылась на хосте. Деталей толком нету - все что известно, это происходит при выходе за какой-то из лимитов скорее всего file limit или proc limit. будем исследовать. Как Вы определили что консоль открылась на хосте? /proc/user_beancounters Вы не смотрели? http://bugzilla.openvz.org/show_bug.cgi?id=244
Quote: 1. Все нормальные дистрибутивы прекрасно работают и без sysfs/udev. Во многих из них, можно даже настраивать как работать. Объясните это RHEL4 & клоны - которые в дефолтой конфигурации ставят udev, и не расчитаны на другое. Обмануть можно - но зачем ручные телодвижения? Quote: 2. sysfs был сделан опцией, т.к. на ядрах 2.6.x до какого-то момента файловая система sysfs работала так, что dentries/inodes были unreclaimable. Из-за этого sysfs даже в том виде какой он есть у нас занимал >0.5-1Mb/VE. Полный sysfs занимал бы еще в разы больше. В 2.6.16+ (по идее) его теперь можно просто всегда включать. это было в районе 2.6.3 или где-то типа того. патч под 2.6.8 (stable) и там насколько помню этого нету. Даже если бы и было - минимальное дерево не сожрет много места в памяти. И будет убито при unmount. Quote: 3. насчет конфига - правильное замечание, это просто где-то потерялось по пути в OpenVZ. http://bugzilla.openvz.org/show_bug.cgi?id=242 Тогда можете еще дописать 1) vzctl не возвращает коректный код возврата при enter failed. Quote: # vzctl enter 4 ; echo $? enter failed 0 2) При привышении количества процессов и попытке сделать enter - возвращается Quote: # vzctl enter 4 Unable to fork: Cannot allocate memory вместо Too many processes. 3) в какой-то момент получилась ситуация 2 раза смотрироваными директориями none /vz/root/4/dev tmpfs rw 0 0 none /vz/root/4/dev/pts devpts rw 0 0 none /vz/root/4/dev tmpfs rw 0 0 none /vz/root/4/dev/pts devpts rw 0 0 Похоже в отличии от FreeVPS вы не делается force umount для всего VPS mount tree. Собственно OpenVZ не знает что такое disknamespace поэтому возможны такие приколы. Quote: Кроме того неплохо бы иметь в sysfs не только class/network с данными по интерфейсам, но еще и class/tty/ptmx. Без этого не создается /dev/ptmx и не работает console multeplexer. Патч исправляющий это досадное недоразумение приатачен. Огромное спасибо за патч и за то, что помогаете не только словом, но и делом http://bugzilla.openvz.org/show_bug.cgi?id=243 Quote: Quote: PS. недавно получилось воспроизвести забавную атаку на OpenVZ. vzctl enter перевел процес в контекст VPS но при этом консоль открылась на хосте. Деталей толком нету - все что известно, это происходит при выходе за какой-то из лимитов скорее всего file limit или proc limit. будем исследовать. Как Вы определили что консоль открылась на хосте? /proc/user_beancounters Вы не смотрели? http://bugzilla.openvz.org/show_bug.cgi?id=244 по тому что promt не поменялся. и я как был в /etc/sysconfig на host - так и остался. при этом ps ax показывал процессы VPS. к сожалению я поздно спохватился и логов не сохранил. Но это была попытка запустить с Virtozzo unlimited.conf - VPS внутри которого RHEL4 с java. явно не хватало и процессов и файлов - но что именно позволило такому событию быть - не скажу.
Quote: это было в районе 2.6.3 или где-то типа того. патч под 2.6.8 (stable) и там насколько помню этого нету. Даже если бы и было - минимальное дерево не сожрет много места в памяти. И будет убито при unmount. нет, как раз в 2.6.8 каждая sysfs отнимает по пол метра. я понимаю, что Вам скорее всего это не критично, а для клиентов которые запускают по 100+ VE, это уже >50-100Mb, т.е. порядка 10% normal zone на i386. Quote: Тогда можете еще дописать 1) vzctl не возвращает коректный код возврата при enter failed. http://bugzilla.openvz.org/show_bug.cgi?id=245 Quote: 2) При привышении количества процессов и попытке сделать enter - возвращается: # vzctl enter 4 Unable to fork: Cannot allocate memory вместо Too many processes. Такой ошибки не бывает. Есть ENOMEM и ядро еще возвращает EAGAIN (Try again) в случае rlimit'ов. P.S. такая ошибка есть на SPARC'е... #define EPROCLIM 67 /* SUNOS: Too many processes */ Quote: 3) в какой-то момент получилась ситуация с 2 раза смотрироваными директориями none /vz/root/4/dev tmpfs rw 0 0 none /vz/root/4/dev/pts devpts rw 0 0 none /vz/root/4/dev tmpfs rw 0 0 none /vz/root/4/dev/pts devpts rw 0 0 Похоже в отличии от FreeVPS вы не делается force umount для всего VPS mount tree. Собственно OpenVZ не знает что такое disknamespace поэтому возможны такие приколы. disk namespace не используется, т.к. иначе проблематично осуществить доступ к файлам VE из VE0. На VE stop все должно отмонтироваться... vzctl делает это в цикле пока есть маунты...
[quote] dev wrote on Fri, 01 September 2006 05:27 Quote: это было в районе 2.6.3 или где-то типа того. патч под 2.6.8 (stable) и там насколько помню этого нету. Даже если бы и было - минимальное дерево не сожрет много места в памяти. И будет убито при unmount. нет, как раз в 2.6.8 каждая sysfs отнимает по пол метра. я понимаю, что Вам скорее всего это не критично, а для клиентов которые запускают по 100+ VE, это уже >50-100Mb, т.е. порядка 10% normal zone на i386. по моим наблюдениям тем кому надо 100+ VE ставят миниум 2xPIV 4G, а то и x86_64/4G. Кроме того можно просто бэкпорт нужной фичи в stable. вы многое другое бэкпортите - так почему бы не это? Quote: Quote: 2) При привышении количества процессов и попытке сделать enter - возвращается: # vzctl enter 4 Unable to fork: Cannot allocate memory вместо Too many processes. Такой ошибки не бывает. Есть ENOMEM и ядро еще возвращает EAGAIN (Try again) в случае rlimit'ов. P.S. такая ошибка есть на SPARC'е... #define EPROCLIM 67 /* SUNOS: Too many processes */ Есть еще и в FreeBSD - с которой я вобщем-то и спутал. Quote: Quote: 3) в какой-то момент получилась ситуация с 2 раза смотрироваными директориями none /vz/root/4/dev tmpfs rw 0 0 none /vz/root/4/dev/pts devpts rw 0 0 none /vz/root/4/dev tmpfs rw 0 0 none /vz/root/4/dev/pts devpts rw 0 0 Похоже в отличии от FreeVPS вы не делается force umount для всего VPS mount tree. Собственно OpenVZ не знает что такое disknamespace поэтому возможны такие приколы. disk namespace не используется, т.к. иначе проблематично осуществить доступ к файлам VE из VE0. На VE stop все должно отмонтироваться... vzctl делает это в цикле пока есть маунты... вот воспроизведение - box 2xPIIIs ядро stable с моим патчем. # ssh rhel4 Last login: Fri Sep 1 07:56:17 2006 from berloga.shadowland [root@rhel4 ~]# vzctl mount 4 VPS is mounted [root@rhel4 ~]# vzctl start 4 Warning: distribution not specified default used /etc/vz/dists/default Starting VPS ... VPS is unmounted VPS is mounted Setting CPU limit: 0 Setting CPU units: 1000 Set hostname: vps134 VPS start in progress... [root@rhel4 ~]# cat /proc/mounts /dev/root / ext3 rw 0 0 none /dev tmpfs rw 0 0 /proc /proc proc rw,nodiratime 0 0 /sys /sys sysfs rw 0 0 none /dev/pts devpts rw 0 0 none /dev/shm tmpfs rw 0 0 /dev/hda3 /vservers ext3 rw 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0 /vservers/vps134 /vz/root/4 simfs ro 0 0 /proc /vz/root/4/proc proc rw,nodiratime 0 0 /sys /vz/root/4/sys sysfs rw 0 0 none /vz/root/4/dev tmpfs rw 0 0 none /vz/root/4/dev/pts devpts rw 0 0 [root@rhel4 ~]# vzctl restart 4 Restarting VPS Stopping VPS ... VPS was stopped VPS is unmounted Warning: distribution not specified default used /etc/vz/dists/default Starting VPS ... VPS is mounted Setting CPU limit: 0 Setting CPU units: 1000 Set hostname: vps134 VPS start in progress... [root@rhel4 ~]# cat /proc/mounts /dev/root / ext3 rw 0 0 none /dev tmpfs rw 0 0 /proc /proc proc rw,nodiratime 0 0 /sys /sys sysfs rw 0 0 none /dev/pts devpts rw 0 0 none /dev/shm tmpfs rw 0 0 /dev/hda3 /vservers ext3 rw 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0 /vservers/vps134 /vz/root/4 simfs rw 0 0 /proc /vz/root/4/proc proc rw,nodiratime 0 0 /sys /vz/root/4/sys sysfs rw 0 0 none /vz/root/4/dev tmpfs rw 0 0 none /vz/root/4/dev/pts devpts rw 0 0 [root@rhel4 ~]# cat /proc/mounts /dev/root / ext3 rw 0 0 none /dev tmpfs rw 0 0 /proc /proc proc rw,nodiratime 0 0 /sys /sys sysfs rw 0 0 none /dev/pts devpts rw 0 0 none /dev/shm tmpfs rw 0 0 /dev/hda3 /vservers ext3 rw 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0 /vservers/vps134 /vz/root/4 simfs ro 0 0 /proc /vz/root/4/proc proc rw,nodiratime 0 0 /sys /vz/root/4/sys sysfs rw 0 0 none /vz/root/4/dev tmpfs rw 0 0 none /vz/root/4/dev/pts devpts rw 0 0 [root@rhel4 ~]# vzctl restart 4 Restarting VPS Stopping VPS ... VPS was stopped VPS is unmounted Warning: distribution not specified default used /etc/vz/dists/default Starting VPS ... VPS is mounted Setting CPU limit: 0 Setting CPU units: 1000 Set hostname: vps134 VPS start in progress... [root@rhel4 ~]# cat /proc/mounts /dev/root / ext3 rw 0 0 none /dev tmpfs rw 0 0 /proc /proc proc rw,nodiratime 0 0 /sys /sys sysfs rw 0 0 none /dev/pts devpts rw 0 0 none /dev/shm tmpfs rw 0 0 /dev/hda3 /vservers ext3 rw 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0 /vservers/vps134 /vz/root/4 simfs rw 0 0 /proc /vz/root/4/proc proc rw,nodiratime 0 0 /sys /vz/root/4/sys sysfs rw 0 0 none /vz/root/4/dev tmpfs rw 0 0 none /vz/root/4/dev/pts devpts rw 0 0 none /vz/root/4/dev tmpfs rw 0 0 none /vz/root/4/dev/pts devpts rw 0 0 [root@rhel4 ~]#
Quote: disk namespace не используется, т.к. иначе проблематично осуществить доступ к файлам VE из VE0. Админ host не должен быть хозяином всего - иначе OpenVZ не позволяет хранить конфиденциальные данные. Пользователь должен иметь возможность хранить свои конфиденциальные данные которые не видны с host - иначе мы получаем ситуацию когда при взломе host - взломщику доступны данные всех VE на хосте. Как клево черт подери человек замоунтил криптованый диск, а юзер на хосте может гулять по его данным и читать.
если говорить о security, то: 1. disk namespace не улучшает security. host'овый root ВСЕГДА видит всю память, разделы, имеет прямой доступ к железу и может например читать disk partition. Надеюсь не надо объяснять, что человек, которому _НАДО_ владея всеми этими правами все равно получит доступ к файлам. И, в конце концов, наличие vzctl enter также позволяет УВИДЕТЬ ВСЕ что надо с еще меньшими усилиями. Quote: иначе OpenVZ не позволяет хранить конфиденциальные данные Ни одна софтварная технология виртуализации не позволяет хранить конфидециальные данные, которые тем или иным образом не мог бы считать админ машины. Разница только в требуемых усилиях. Каковы Ваши предложения? Сделать просто чтобы по умолчанию доступа не было? 2. Обычно когда думают о безопасности не дают VE0 глобальные IP адреса и настраивают как положено доступ, также не запускают в VE0 apache c php, telnet и т.д. Опять же, OpenVZ в данном плане не исключение. Об этом нужно помнить и думать при использовании любой технологии виртуализации. Могу я поинтересоваться чем Вам так насолила OpenVZ и откуда такая неприязнь? По крайней мере, у меня возникло такое ощущение...
dev wrote on Fri, 01 September 2006 06:33 если говорить о security, то: Каковы Ваши предложения? Сделать просто чтобы по умолчанию доступа не было? 2. Обычно когда думают о безопасности не дают VE0 глобальные IP адреса и настраивают как положено доступ, также не запускают в VE0 apache c php, telnet и т.д. Опять же, OpenVZ в данном плане не исключение. Об этом нужно помнить и думать при использовании любой технологии виртуализации. Могу я поинтересоваться чем Вам так насолила OpenVZ и откуда такая неприязнь? По крайней мере, у меня возникло такое ощущение... Сделать как сделано в том же Linux-VServer. if inode->ctx_id != process->ctx_id => deny access. Это как миниум защитит от 90% атак из под обычного пользователя. И заставит очень сильно подумать человека который имеет даже root на host. PS. неужели список багов это признак неприязни? хотя отсутсвие правильного кода возврата у vzctl - сильно мешает мне в работе. Quote: # vzctl status 4; echo $? VPSID 4 exist unmounted down 0 [root@rhel4 ~]# vzctl start 4 Warning: distribution not specified default used /etc/vz/dists/default Starting VPS ... VPS is mounted Setting CPU limit: 0 Setting CPU units: 1000 Set hostname: vps134 VPS start in progress... [root@rhel4 ~]# vzctl status 4; echo $? VPSID 4 exist mounted running 0
Quote: Сделать как сделано в том же Linux-VServer. if inode->ctx_id != process->ctx_id => deny access. Это как миниум защитит от 90% атак из под обычного пользователя. И заставит очень сильно подумать человека который имеет даже root на host. #define VE_AREA_ACC_CHECK 0x0001 #define VE_AREA_ACC_DENY 0x0002 #define VE_AREA_EXEC_CHECK 0x0010 #define VE_AREA_EXEC_DENY 0x0020 #define VE0_AREA_ACC_CHECK 0x0100 #define VE0_AREA_ACC_DENY 0x0200 #define VE0_AREA_EXEC_CHECK 0x1000 #define VE0_AREA_EXEC_DENY 0x2000 int ve_area_access_check = 0; # echo 65535 > /proc/sys/fs/ve-area-access-check и ядро будет ругаться и запрещать доступ к данным из VE0 в VE и наоборот (последнее просто дополнительная security защита). Quote: PS. неужели список багов это признак неприязни? хотя отсутсвие правильного кода возврата у vzctl - сильно мешает мне в работе. Нет конечно, за баги я Вам бесконечно благодарен. Мне просто показалось что у Вас какой-то раздраженный тон )) Quote: # vzctl status 4; echo $? VPSID 4 exist unmounted down 0 [root@rhel4 ~]# vzctl start 4 Warning: distribution not specified default used /etc/vz/dists/default Starting VPS ... VPS is mounted Setting CPU limit: 0 Setting CPU units: 1000 Set hostname: vps134 VPS start in progress... [root@rhel4 ~]# vzctl status 4; echo $? VPSID 4 exist mounted running 0 Это by design. 1. ошибок никаких нет. поэтому ноль. 2. при добавлении новых состояний, множество кодов будет расти, а соответственно нужно переделывать скрипты и т.д. Это не желательно.
dev wrote on Fri, 01 September 2006 07:09 Quote: Сделать как сделано в том же Linux-VServer. if inode->ctx_id != process->ctx_id => deny access. Это как миниум защитит от 90% атак из под обычного пользователя. И заставит очень сильно подумать человека который имеет даже root на host. #define VE_AREA_ACC_CHECK 0x0001 #define VE_AREA_ACC_DENY 0x0002 #define VE_AREA_EXEC_CHECK 0x0010 #define VE_AREA_EXEC_DENY 0x0020 #define VE0_AREA_ACC_CHECK 0x0100 #define VE0_AREA_ACC_DENY 0x0200 #define VE0_AREA_EXEC_CHECK 0x1000 #define VE0_AREA_EXEC_DENY 0x2000 int ve_area_access_check = 0; # echo 65535 > /proc/sys/fs/ve-area-access-check и ядро будет ругаться и запрещать доступ к данным из VE0 в VE и наоборот (последнее просто дополнительная security защита). Thanks. жалко что это нигде не документировано - или я плохо искал? Quote: Quote: PS. неужели список багов это признак неприязни? хотя отсутсвие правильного кода возврата у vzctl - сильно мешает мне в работе. Нет конечно, за баги я Вам бесконечно благодарен. Мне просто показалось что у Вас какой-то раздраженный тон )) Quote: # vzctl status 4; echo $? VPSID 4 exist unmounted down 0 [root@rhel4 ~]# vzctl start 4 Warning: distribution not specified default used /etc/vz/dists/default Starting VPS ... VPS is mounted Setting CPU limit: 0 Setting CPU units: 1000 Set hostname: vps134 VPS start in progress... [root@rhel4 ~]# vzctl status 4; echo $? VPSID 4 exist mounted running 0 Это by design. 1. ошибок никаких нет. поэтому ноль. 2. при добавлении новых состояний, множество кодов будет расти, а соответственно нужно переделывать скрипты и т.д. Это не желательно. [/quote] Эато нет возможности опреть состояние без парсинга строки ответа. гораздо логичнее - для такой команды как status вовзращать с кодом возврата текущее состояние VPS, и обработать в скрипте проще и не надо привязываться к текстовым строкам. Я не прав?
Quote: Thanks. жалко что это нигде не документировано - или я плохо искал? это действительно не документировано. Я думал написать на wiki страничку про security, про соображения насчет VE0 и т.д. но пока руки не доходят :/ Quote: Эато нет возможности опреть состояние без парсинга строки ответа. гораздо логичнее - для такой команды как status вовзращать с кодом возврата текущее состояние VPS, и обработать в скрипте проще и не надо привязываться к текстовым строкам. Я не прав? И правы, и нет. парсить в скриптах возможно и проще. Хотя, не сказать что существенно. А вот проблема возникает. Например, сейчас множество состояний и соответственно кодов это {exist,destroyed}x{mounted,unmounted}x{running,stopped}. Итого, 8 комбинаций. И вот скоро например мы хотим расширить состояния: {running,stopped,suspended} и {exist,destroyed,migrating}. Соответственно количество состояний, во-первых, увеличивается в 4 раза, во-вторых, нужно ходить править скрипты и разбираться что имел ввиду автор. С другой стороны, наверное, все комбинации не бывают и достаточно репортить состояния: NOT_EXIST STOPPED MOUNTED RUNNING плюс 1 бит на ошибки.
Quote: 3. насчет конфига - правильное замечание, это просто где-то потерялось по пути в OpenVZ. http://bugzilla.openvz.org/show_bug.cgi?id=242 вот реализация SYSFS=[yes|no] как опции конфига. man править не стал - я mdoc не на столько хорошо знаю. Мою задачу решает - с остальным еще думать будем.
Quote: И правы, и нет. парсить в скриптах возможно и проще. Хотя, не сказать что существенно. А вот проблема возникает. Например, сейчас множество состояний и соответственно кодов это {exist,destroyed}x{mounted,unmounted}x{running,stopped}. Итого, 8 комбинаций. И вот скоро например мы хотим расширить состояния: {running,stopped,suspended} и {exist,destroyed,migrating}. Соответственно количество состояний, во-первых, увеличивается в 4 раза, во-вторых, нужно ходить править скрипты и разбираться что имел ввиду автор. С другой стороны, наверное, все комбинации не бывают и достаточно репортить состояния: NOT_EXIST STOPPED MOUNTED RUNNING плюс 1 бит на ошибки. exit(2) возвращает в userland помоему 8 бит. C учетом планируемых состояний я бы сказал что нужны группы EXIST/NO_EXIST mounted/unmounted {running,stopped,suspended,migrating} и того 4 бита в ответе (3 бита резерв) крайний бит - флаг ошибки. младшие биты в этом случае код ошибки. определение ошибки будет элементарным if( $rc > 127 ) $error = 256 - $rc. попробую сделать патчик :-\
мы планировали сделать FEATURES="sysfs и др.". Но возможно сделаем именно так... добавил очередной баг %)
Какая версия vzctl использовалась? Какой темплит использовался для впски? Можно ли запостить сюда конфиг файл для этой впски?
dev wrote on Fri, 01 September 2006 10:17 мы планировали сделать FEATURES="sysfs и др.". Но возможно сделаем именно так... добавил очередной баг %) Я читал багзилу - но тогда уж FLAGS. что бы хоть как-то стандартизировать имя переменной среди VPS софта.
Andrey Mirkin wrote on Fri, 01 September 2006 11:02 Какая версия vzctl использовалась? Какой темплит использовался для впски? Можно ли запостить сюда конфиг файл для этой впски? vzctl - 3.0.10 темлейт не стандартный - в некотором каталоге был развернут архив с содержиым FS от устанвленого RHEL4. конфиг собственно тривиальный == SYSFS=no AVNUMPROC=40:40 CAPABILITY="MKNOD:on CHOWN:on" CPULIMIT=0 CPUUNITS=1000 DCACHESIZE=1048576:1097728 DGRAMRCVBUF=132096:132096 DISKINODES=200000:220000 DISKSPACE="5120000:5120000" HOSTNAME=vps134 KMEMSIZE="2147483647:2147483647" LOCKEDPAGES=32:32 NUMFILE="2147483647:2147483647" NUMFLOCK=100:110 NUMIPTENT=128:128 NUMOTHERSOCK=80:80 NUMPROC="400:400" NUMPTY=16:16 NUMSIGINFO=256:256 NUMTCPSOCK="40:40" ONBOOT=no OOMGUARPAGES="2147483647:2147483647" OTHERSOCKBUF=132096:336896 PHYSPAGES=0:2147483647 PRIVVMPAGES="2147483647:2147483647" QUOTATIME=0 SHMPAGES=8192:8192 TCPRCVBUF=319488:524288 TCPSNDBUF=319488:524288 VE_PRIVATE=/vservers/vps134 VMGUARPAGES="2147483647:2147483647" === практически все в unlim. Базовым для игр служил == 1070 Авг 23 12:37 ve-unlimited.conf-sample == взятый из демки виртуозы.
А на vzctl - 3.0.11 баг с дублированием моунтов после рестарта воспроизводится? Не могли бы Вы попробовать?
Quote: UMKA: PS. недавно получилось воспроизвести забавную атаку на OpenVZ. vzctl enter перевел процес в контекст VPS но при этом консоль открылась на хосте. Деталей толком нету - все что известно, это происходит при выходе за какой-то из лимитов скорее всего file limit или proc limit. DEV: будем исследовать. Как Вы определили что консоль открылась на хосте? /proc/user_beancounters Вы не смотрели? http://bugzilla.openvz.org/show_bug.cgi?id=244 UMKA: по тому что promt не поменялся. и я как был в /etc/sysconfig на host - так и остался. при этом ps ax показывал процессы VPS. к сожалению я поздно спохватился и логов не сохранил. Но это была попытка запустить с Virtozzo unlimited.conf - VPS внутри которого RHEL4 с java. явно не хватало и процессов и файлов - но что именно позволило такому событию быть - не скажу. Добрый день, К сожалению, мнем не удалось воспроизвести ситуацию, о которой вы говорите. Во-первых, пробовал входить в VE так, чтобы в процессе его выполнения превышались лимиты количества процессов и количества открытых файлов. Далее анализировал код vzctl. Судя по описанию, т.к. вы находитесь в той же директории - значит не сработал chroot, но при этом сменился environment. По коду: if ((ret = vz_chroot(root))) goto err; ret = vz_env_create_ioctl(h, veid, VE_ENTER); if (ret < 0) { if (errno == ESRCH) ret = VZ_VE_NOT_RUNNING; else ret = VZ_ENVCREATE_ERROR; goto err; } Значит смена environment могла произойти только (!) если удачно прошёл chroot... Может быть chroot проходил не туда (что-то вроде /)? Проверено такие ситуации обрабатываются и enter проваливается. Закрываю баг как инвалид, но если вам удастся его воспроизвести переоткройте его, пожалуйста. С полным описанием как воспроизвести. Спасибо!
vass wrote on Sat, 02 September 2006 05:18 Значит смена environment могла произойти только (!) если удачно прошёл chroot... Может быть chroot проходил не туда (что-то вроде /)? Проверено такие ситуации обрабатываются и enter проваливается. Закрываю баг как инвалид, но если вам удастся его воспроизвести переоткройте его, пожалуйста. С полным описанием как воспроизвести. Спасибо! Попробую.