У меня есть компьютер за NAT, который устанавливает обратное SSH-соединение с моим Digitalocean VPC. Я использую это обратное SSH-соединение из дома, чтобы войти в свой офисный компьютер (я уполномочен на это), копировать файлы и делать другие важные вещи.
Хотя и не часто, я заметил, что мой офисный компьютер перезагружается (из-за сбоя питания и т. Д.) И разрывает обратное соединение SSH, которое он установил с моим VPC. В подобных случаях я не могу подключиться с домашнего компьютера к офисному ПК.
Я запускаю следующий сценарий, чтобы сделать обратное соединение + динамический прокси-сервер для анонимизации моего трафика (поскольку я не обязан обмениваться данными для просмотра), сгенерированного на офисном ПК.
autossh -CD 8080 -i digitalOcean -R 8081:localhost:22 root@IPofDigitalOceanPC
Ни при каких обстоятельствах я не смогу снова запустить этот сценарий на моем офисном ПК после перезагрузки, поскольку меня там нет. Для решения этой проблемы я установил следующий crontab.
Примечание. Файл rev.sh
содержит вышеуказанную строку. Сертификат "digitalOcean" и rev.sh находится в Ubuntu home
. Поэтому, когда я выполняю ./rev.sh
в своем терминале Ubuntu, я получаю динамический прокси, а также доступ к своему серверу DigitalOcean. Этот метод работает на 100%.
Однако, когда я устанавливаю crontab следующим способом, мой компьютер с Ubuntu никогда не создает динамический прокси. Я вижу это, потому что когда я проверяю этот прокси из Google Chrome, он говорит, что прокси отказывается от соединения.
Вот cronjobs, которые я пробовал как cronjobs root. Я также пробовал их как обычный пользователь, но они не работали.
@reboot bash /home/user/rev.sh
@reboot /home/user/rev.sh
@reboot cd /home/user && ./rev.sh
Затем я установил crontab за несколько минут до текущего времени и дождался его запуска.
24 12 * * * bash /home/user/rev.sh
24 12 * * * /home/user/rev.sh
24 12 * * * reboot
Они тоже не выполнялись.
Я также пробовал 48 15 * * * bash /home/user/rev.sh >> test3
и */1 * * * * reboot -f >> test
, но test3 и test ничего не имеют. Однако файлы были созданы! crontab!
Пожалуйста, будьте любезны, чтобы помочь мне определить мою ошибку. На моем сайте много похожих вопросов по моей проблеме. Поэтому я привел много ответов, но ни один из них не помог.
Лучшее решение состояло бы в том, чтобы использовать сторожевой таймер. сторожевой таймер является демоном, который будет следить за рабочими процессами и если они выйдут, то автоматически перезапустит их.
sudo apt-get install watchdog
watchdog(8)
демон выполнит сценарии в /etc/watchdog.d
с аргументом test
или repair
. (см. TEST DIRECTORY
раздел watchdog(8)
страница справочника). Ваш сторожевой сценарий обрабатывает те два аргумента, когда он проверяет, чтобы видеть, выполняет ли процесс и принимает меры для восстановления его.
Можно настроить сторожевой таймер путем изменения /etc/watchdog.conf
(См. watchdog.conf(5)
).
watchdog.d
сценарийВозьмите, например, /etc/watchdog.d/autossh_script
(который имеет 755
полномочия и принадлежат root
).
Примечание: Вы, возможно, должны настроить
$targetuser
переменная среды в сценарии в качестве примера.sam
мое имя пользователя.
#!/bin/bash
targetuser=sam
runTest=false
runRepair=false
case $1 in
test)
runTest=true
;;
repair)
runRepair=true
repairExitCode=$2
;;
*)
echo 'Error: script needs to be run by watchdog' 1>&2
exit 1
;;
esac
if ${runTest}; then
#run a test here which will tell the status of your process
#the exit code of this script will be the repairExitCode if it is non-zero
if ! pgrep autossh &> /dev/null; then
#autossh not running; notify watchdog to repair
exit 1
else
#autossh running; no action necessary
exit 0
fi
fi
if ${runRepair}; then
#take an action to repair the affected item
#use a case statement on $repairExitCode to handle different failure cases
su - ${targetuser} -c 'nohup autossh -f -- -NCD 8080 -i digitalOcean -R 8081:localhost:22 root@IPofDigitalOceanPC'
exit 0
fi
-N
к Вашему ssh
команда в сценарии в качестве примера, таким образом, это только запускает туннель, но не пытается создать оболочку входа в систему.-f
кому: autossh
так, чтобы это работало в фоновом режиме.pgrep
шаблон. Однако можно далее сузить тест определенному пользователю или даже использовать шаблон для процесса. Посмотрите pgrep(1)
поскольку, как далее настроить Ваш тест с помощью pgrep./etc/watchdog.conf
и /etc/defaults/watchdog
места состоят в том, чтобы настроить сторожевой таймер. Посмотрите watchdog.conf(5)
.
Одной вещью отметить являются пользовательские сценарии, выполняются один раз во второй по умолчанию. Я рекомендую увеличить это по крайней мере до 30 секунд, если у Вас нет потребности в большем количестве проверки в реальном времени. Корректируйтесь interval
начинание watchdog.conf
.
Вы, возможно, должны создать /etc/watchdog.d
каталог перед Вашим сценарием.
/var/log/watchdog/*
содержит связанные со сторожевым таймером журналы и ошибки. Если Ваши выводы сценария к stdout или stderr затем это будет записано там. В моей системе я замечаю, что мой сценарий выполняется test
или repair
примерно один раз во второй. При использовании эха в сценарии, это должно только быть временным для отладки целей только. Иначе отбрасывание вывода рекомендуется кроме случая ошибок.
Если Ваш сценарий не работает вообще, затем проверяют полномочия: ls -l /etc/watchdog.d
.