web-dev-qa-db-fra.com

Un moyen facile d'installer CrashPlan

Existe-t-il un fichier .deb, un référentiel, un PPA ou quoi que ce soit à installer CrashPlan autre que le fichier install.sh non standard fichier? J'ai poisson en tant que mon shell, et je devais perdre mon temps et enfin utiliser chsh avant que le script d'installation puisse fonctionner. Je ne veux pas avoir à sauter tous ces obstacles à chaque mise à niveau.

backuppparepositorydebfish
2
endolith

Selon CrashPlan:

mises à jour automatiques à la dernière version. Vous n'avez PAS besoin de le télécharger à nouveau une fois installé.

Si vous utilisez un noyau 2.6.13 Series ou supérieur, 1GHZ + processeur x86-64, 1 Go + mémoire, 250 Mo + espace disque disponible, Oracle (Sun) Java version 1.6+, Glibc 2.4+, GTK, Xorg travailler pour vous.

CrashPlan démarre automatiquement après l'installation et vous invite à créer un nouveau compte. Entrez les informations et cliquez sur Créer un compte. CrashPlan enverra des rapports de sauvegarde et des notifications à l'adresse e-mail que vous avez entrée.

Détail important: Vous devez démarrer le script d'installation avec cette commande afin d'éviter les messages d'erreur:

Sudo ./install.sh

C'est assez simple. Lisez les informations de lecture et d'installation pour les instructions d'installation.

3
Ringtail

Normalement, bash install.sh ou Sudo bash install.sh aurait dû fonctionner, mais avec le script de CrashPlan, certaines commandes internes finissent par s'exécuter sous fish et échouent à cause de différences de syntaxe.

La variable d'environnement $ Shell, qui pointe toujours vers/usr/bin/fish, est souvent à l'origine de cette situation. De nombreux programmes exécutent des sous-commandes à l'aide de $ Shell. J'ai donc essayé env Shell=/bin/bash Sudo bash install.sh => toujours la même erreur de poisson!

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
                                                                                                                            ^

Hmm. Essayons plus fort - travaillons à partir d'une vraie racine login Shell, qui effectue une réinitialisation plus complète (variables d'environnement, répertoire, etc.):

~/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

REMARQUE: quand il vous demande si vous voulez démarrer CrashPlanDesktop, dites NON. À la place, quittez le shell racine et exécutez-le vous-même, comme le montre l'exemple ci-dessus. (Si vous l'exécutez en tant que root, vous risquez par la suite de rencontrer des problèmes pour le démarrer vous-même, car les fichiers journaux sont uniquement accessibles en écriture par ce dernier. Vous devrez donc Sudo rm les utiliser puis le lancer. Par défaut, ne sauvegardez que/root /, assurez-vous donc de configurer le ou les répertoires appropriés.)

su - est suffisant pour obtenir un shell de connexion mais su demande le mot de passe de root et dans Ubuntu, nous sommes tellement habitués à Sudo ne demandant que notre mot de passe nous ne nous souvenons même pas du mot de passe root. Mais si vous êtes déjà root, su ne demande rien, donc Sudo su - fonctionne.

Je me sentais un peu ridicule en utilisant cette combinaison redondante de Sudo su simplement parce que su - est la syntaxe dont je me souviens, alors un aide rapide m'a indiqué que Sudo --login devrait suffire.
Étonnamment Sudo --login a échoué avec la même erreur de poisson!

Cela m'a rendu curieux. En lisant install.sh j'ai trouvé:

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

(utilisé plus tard pour créer /home/${SRC_USER}/Desktop/${APP_BASENAME}.desktop via un tas de commandes su ${SRC_USER} -c "...").

=> Aha! Donc le problème était que Sudo craque pour nous en exportant $ Sudo_USER, même à un shell de connexion. Sudo su - est arrivé au travail parce que su - ignore toutes les variables d'environnement, y compris Sudo_USER, dans une étape distincte.

0
anps