shurshur

Если бы pv были в одном vg, можно было бы сделать pvmove для освобождения нужного pv.

Что касается ресайза, то многие файловые системы не умеют online resize в сторону уменьшения (а некоторые, как xfs, и offline не умеют уменьшать), так что файловую систему придётся размонтировать, "на живую" изменить размер не получится.

Возможный вариант, если нужно именно срочно освободить диск (к примеру, он подыхает): временно добавить ещё один диск, который добавить в тот же vg, затем сделать pvmove на него и после этого удалить первый. А дальше уже разбираться.

Самое простое решение:

docker run -p 9090:9090 --network=container:vpn-client-container 6d51b6be9afb awsemo-app

- оба контейнера будут использовать один и тот же сетевой стек и общий IP.

echo -e '\e[31;1mПривет!\e[0m'

За подробностями man console_codes.

Потому что после chroot корнем файловой системы для процесса будет указанный каталог, а где там /bin/bash? Его там нет. Его надо там создать. Далее потребуются некоторые библиотеки из /lib. Устройства из /dev. Утилиты, хотя бы coreutils. И т.д. и т.п. Проще всего сразу же сделать минимальную систему в нужном каталоге с помощью debootstrap.

PS: Я по формулировке темы вопроса думал, что вот сейчас надо будет рассказывать про chroot'ы, namespace'ы, openvz и виртуалки, но тут, оказывается, дело было не в этом...

Не очень понятна суть вопроса. Если просто не ставить и не обновлять ничего, то ничего не обновится. Или хочется, чтобы ничего не было обновлено по зависимостям, в том числе никакие библиотеки, но можно было ставить новые пакеты? Это почти без вариантов, если не сидеть на очень stable-ветке и своём собственном замороженном зеркале пакетов, ведь новая версия пакета в регулярно обновляемом репозитории может зависеть от новых версий библиотек, для которых и старой-то версии уже в репозитории нет.

В плане безопасности и стабильности всё решает квалификация админа, если у него руки кривые - никакой дистрибутив не спасёт. Плюс сложившаяся практика - чаще всего нет никакого смысла ставить один сервер на каком-то конкретном дистрибе, если уже успешно и системно обслуживаются 100 серверов на чём-то ещё.

Со многих точек зрения я бы предпочёл debian'ообразия, например, в нём изкаропки больше софта. Но есть доводы и в сторону centos, например, в нём есть есть готовые полиси для selinux (в debian с ними давно сложности), обычно проще с поддержкой интырпрайзного софта (всяких поделий от oracle, например).

netboot.xyz совсем не про это, ему как раз без kvm никуда...

Собрать систему из rescue можно, у всех распространённых дистрибов Linux есть для этого инструментарий (например, debootstrap). Но это квест точно не для неопытного пользователя. Лучше уж тогда запросить подключение kvm (если хостер предлагает, пусть даже и за деньги) либо установить нужную систему штатным инструментом хостера.

Собственно вот мой скрипт: sbin.ru/radio.zip
Он был даже двух версий, внутри обе с примером запуска (бесконечный while т.к. иногда под нагрузкой мой старый сервак не справлялся с процессом и коннект рвался).

Для запуска нужен icecast, perl-модуль Shout, а также вот это sbin.ru/mp3tools-27-11-05.tgz (на x86_64 могут прилично глючить, потому что писалось это в 2003-2005 годах, а первый amd64 у меня появился в 2006 году).

Рандом по списку был сделан так: выбирался случайный элемент, выкидывался из списка, а следующий выбирался на расстоянии между cur_list_length/2 и cur_list_length от текущего. Это понижало шансы на выбор двух песен одного исполнителя подряд, ведь предполагалось, что исполнители в файле сгруппированы (у меня они были разложены по каталогам, а список генерировался с помощью find). Реализовать какой-нибудь более умный алгоритм я так и не собрался.

icecast+ices?

В своё время решил эту задачу написанным на коленке perl-скриптом, использующим модуль Shout для доступа к icecast-серверу. Работало не один год, могу поискать.

За любой пункт из этого списка www.fsf.org/campaigns/priority-projects/ тебе скажут спасибо.

Причём тут OS/X и Ubuntu, если Punto switcher только для Windows?

dpkg -S /usr/lib/libnuzhnayaliba.so покажет в какой пакет она входит. Это можно использовать.

Однако я бы сделал пакет, при правильном написании системы сборки в debian/rules обязательно есть команда dh_shlibdeps (могу ошибаться с точным названием), которая включит нужные зависимости. Установка пакета в этом случае может выглядеть так:

dpkg -i proga_1.0_i386.deb
apt-get install -f

При первой программе ругнётся — это нормально. Вторая пофиксит зависимости и выполнит postinstall первой.