Простой способ установить CrashPlan

По данным CrashPlan:

автообновления до последней версии. Вам не нужно загружать его снова после его установки.

Если у вас ядро ​​серии 2.6.13 или выше, процессор 1 ГГц + x86-64, 1 ГБ + память, 250 МБ + свободное дисковое пространство, Oracle (Sun) Java версии 1.6+, Glibc 2.4+, GTK, Xorg, то это будет работать для вас.

CrashPlan автоматически запускается после установки и предлагает вам создать новую учетную запись. Введите информацию и нажмите "Создать учетную запись". CrashPlan будет отправлять резервные отчеты и уведомления на адрес электронной почты, который вы вводите.

Важная деталь: вам нужно запустить скрипт установки с этой командой, чтобы избежать сообщений об ошибках:

sudo ./install.sh

Это довольно просто. Прочтите "Прочтите меня и установите информацию" для инструкций по установке.

Обычно bash install.sh или же sudo bash install.sh должно было сработать, но со сценарием CrashPlan действительно некоторые внутренние команды заканчиваются выполнением под fish и не работают из-за различий в синтаксисе.

Распространенной причиной этого может быть переменная окружения $SHELL, которая по-прежнему указывает на / usr / bin / fish - многие программы выполняют подкоманды, используя $SHELL. Так я попробовал env SHELL=/bin/bash sudo bash install.sh => Все та же ошибка рыбы!

fish: Expected a command name, got token of type “Run job in background”. Did you mean “COMMAND; and COMMAND”? See the help section for the “and” builtin command by typing “help and”.
Standard input: sed -imod "s|Exec=.*|Exec=/usr/local/crashplan/bin/CrashPlanDesktop|" /home/anat/Desktop/CrashPlan.desktop && rm -rf /home/anat/Desktop/CrashPlan.desktopmod
                                                                                                                            ^

Хм. Давайте попробуем больше - давайте поработаем с реальной корневой оболочкой входа в систему, которая выполняет более тщательный сброс (переменные среды, каталог и т. Д.):

~/CrashPlan-install $ sudo su -
root@overgrad:~# echo $SHELL  # that wasn't the problem anyway
/bin/bash
root@overgrad:~# cd /home/anat/CrashPlan-install/
root@overgrad:/home/anat/CrashPlan-install# bash install.sh 

...
Would you like to start CrashPlanDesktop? (y/n) [n] 

To start the Desktop UI:
  /usr/local/bin/CrashPlanDesktop

Installation is complete. Thank you for installing CrashPlan for Linux.

root@overgrad:~# exit
logout
~/CrashPlan-install $ CrashPlanDesktop     

ПРИМЕЧАНИЕ: когда вас спросят, хотите ли вы запустить CrashPlanDesktop, скажите "НЕТ". Вместо этого выйдите из корневой оболочки и запустите ее как вы сами, как показано в примере выше. (Если вы запустите его от имени пользователя root, у вас могут возникнуть проблемы с его запуском из-за того, что файлы журналов доступны для записи только пользователю root - вам придется sudo rm их, а затем он запустится; также по умолчанию будет выполняться только резервное копирование / root /, поэтому убедитесь, что вы настроили правильные каталоги.)

su - достаточно, чтобы получить оболочку входа в систему, но su просит пароль root и в Ubuntu мы так привыкли sudo только спрашивая наш пароль, мы даже не помним пароль root. Но если вы уже root, su ничего не спрашиваетsudo su -работает.

Я чувствовал себя немного глупо, используя этот избыточный sudo su комбинация только потому, что su - это синтаксис, который я помню, так что быстрая подсказка сказала мне sudo --login должно быть достаточно.
Удивительно sudo --loginне удалось с той же ошибкой рыбы!

Это меня заинтересовало. Читая через install.sh я нашел:

SRC_USER=${SUDO_USER}
if [ "x${SRC_USER}" == "x" ] ; then
        SRC_USER=${USER}
fi

(позже использовал для создания /home/${SRC_USER}/Desktop/${APP_BASENAME}.desktop через кучу su ${SRC_USER} -c "..." команд).

=> Ага! Таким образом, проблема заключалась в том, что sudo набрасывается на нас, экспортируя $ SUDO_USER, даже в оболочку входа в систему. sudo su - случилось, потому что работа su - отбрасывает все переменные окружения - включая SUDO_USER - на отдельном шаге.