Прежде чем предпринимать какие-либо значительные усилия по восстановлению, следует проверить состояние работоспособности дискового устройства с помощью SMART и создать резервную копию всех важных данных. Ваш диск уже оказался не совсем надежным, поэтому сначала убедитесь, что ваши данные в безопасности. Если данные SMART показывают, что диск неисправен, было бы лучше получить новый, чем пытаться продлить страдания старого.
Хорошая команда smartctl
для проверки работоспособности, например. диск /dev/sda
будет:
smartctl -HA -f brief -l xerror,error /dev/sda
libseccomp.so.2
должен находиться в/usr/lib/x86_64-linux-gnu/
(или эквивалентном для различных аппаратных архитектур ). Если этот каталог был потерян, исправить это будет довольно сложно, так как в нем много библиотечных файлов. К счастью, это может быть так же просто, как сказать инструментам управления пакетами проверить все lib*
пакеты, а затем переустановить те, в которых отсутствуют файлы -, по крайней мере теоретически.
Поскольку у вас установлен Debian, dpkg -V | grep -v ' c '
следует проверить все файлы в системе, которые были установлены из .dpkg
пакетов, и сообщить обо всех измененных или отсутствующих файлах. Часть grep
исключает любые файлы конфигурации из списка. Это самый минимальный полезный инструмент для этой ситуации, который я могу придумать; если у вас установлен debsums
или вы можете его установить, debsums | grep -v 'OK$'
можно использовать для той же цели.
Если у вас по-прежнему достаточно неповрежденных библиотек, чтобы эта команда работала,
apt-get install --reinstall $(dpkg -S $(debsums -c) | cut -d : -f 1 | sort -u)
автоматически переустановит все пакеты с измененными файлами конфигурации, отличными от -.Использование apt-get install --reinstall
для повторной -установки любых пакетов, некоторые из файлов которых повреждены, было бы гораздо лучшим вариантом, чем пытаться разобрать их из lost+found
.
Ладно, оказывается, это не так уж и тривиально.
Пользовательский ввод, когда
$ wgsh
wgsh@vultr /$
и конвейерные команды:
$ wgsh <<EOD
echo 1
echo 2
echo 3
EOD
Нелегко, но выполнимо.
Решение состоит в том, чтобы локальная socat
открывала удаленную оболочку (обратную оболочку ). Затем переходите в фоновый режим всякий раз, когда обнаруживается ввод команды по каналу. Наконец, отправьте каждую переданную команду в /dev/ptsN
, связанный с фоном socat
.
Первая проблема заключается в том, что socat
всегда думает, что у него есть два дополнительных аргумента всякий раз, когда он пытается установить фон внутри сценария оболочки . Жалоба:
socat[3124] E exactly 2 addresses required (there are 4)
Вторая проблема заключается в том, что выполнение команд на другом /dev/ptsN
не является тривиальным.
Следовательно, решение состоит из двух частей:
tmux
для фонового подключения socat
. ttyecho
для отправки каждой конвейерной команды в фоновый socat
. ttyecho
— это пользовательская утилита от Pratik Sinha , которая также содержит ящик Rust .
Инструмент командной строки ttyecho
функционально похож на writevt
, который был частью console-tools
, но, насколько я могу судить, его разработка остановлена, а последний пакет Ubuntu был для 12.04.
Это означает, что вам, скорее всего, придется скомпилировать и установить собственный ttyecho
.
Есть какие-то дополнительные морщины -разве они не всегда есть?
Для открытия нового tty с помощью tmux
требуются привилегии суперпользователя. Чтобы иметь возможность бегать:
sudo --validate
tmux...
без блокировки запущенного процесса по паролю, нужно добавить в свой/etc/sudoers.d/<user>
:
Defaults: <user> !tty_tickets
Со всем этим это должно работать (с ttyecho
на вашем пути)
if [ -t 0 -a $# -eq 0 ]
then
## No piped commands.
## 1. Start interactive shell.
sudo /usr/bin/nsenter --setuid 1000 \
--setgid 1000 \
--net=/var/run/netns/nns-a \
-- \
socat file:$(tty),raw,echo=0 \
tcp:10.10.10.1:2222
else
## Piped commands.
## 1. Setup sudo --validate for new tty sessions:
# Add
# Defaults: <user> !tty_tickets
# to the file (chmod 440): /etc/sudoers.d/<user>
#
sudo --validate
## 2. Start a detached connection to remote shell.
#
tmux new-session \
-d \
-s a_session \
'sudo /usr/bin/nsenter --setuid 1000 --setgid 1000 --net=/var/run/netns/nns-a -- socat file:$(tty),raw,echo=0 tcp:10.10.10.1:2222'
## 3. Capture the socat process ID
#
SOCAT_PID=$(pgrep -u "root" socat)
## 4. Get the /dev/pts of the socat connection
#
DEV_PTS=$(tmux list-panes -t a_session -F '#{pane_tty}')
## 5. Consume all the piped commands
#
while read cmd
do
sudo /usr/bin/nsenter --setuid 1000 \
--setgid 1000 \
--net=/var/run/netns/nns-a \
-- \
ttyexec -n ${DEV_PTS} "${cmd}"
done
## 6. Exit, if not already done.
#
if pgrep -u "root" socat
then
sudo /usr/bin/nsenter --setuid 1000 \
--setgid 1000 \
--net=/var/run/netns/nns-a \
-- \
ttyexec -n ${DEV_PTS} "exit"
fi
fi
Надеюсь, это кому-нибудь поможет?
Для обратной оболочки:
sudo /usr/bin/nsenter --setuid 1000 --setgid 1000 --net=/var/run/netns/ns-a -- socat TCP4:10.10.10.1:2222 EXEC:/bin/bash
Затем выполните скрипт в фоновом режиме:
./my-script &
С другой стороны:
socat -d TCP4-LISTEN:2222 STDOUT
<commands to execute>