sunnay

  • 30 avr. 2017
  • Inscrit 26 mars 2017
  • Salut,
    Oui je suis en DSM6, il me semble qu'il y avait une astuce pour éviter l'écrasement du crontab sur les DSM précédent mais je n'avais pas creusé et je ne peux plus tester (/etc.default/crontab si mes souvenirs sont bons).
    Pour le @reboot, je ne l'ai pas non plus en option quand je veux créé une tache depuis l'interface mais il fonctionne quand même.

  • clem73
    Oui j'utilise bien le package installé depuis le repo synocommunity. Pour le message que j'ai collé, il apparaît après la commande sudo mount -a
    Après m'être battu avec le fstab, j'ai déclaré forfait et je suis passé par un job cron.
    vi /etc/crontab
    Et j'ai rajouté la ligne :
    @reboot <user_nas> sshfs -o uid=1026 -o gid=100 <user_dedie>@<domain.tld>:<dossier_source> <dossier_cible>
    C'est pas idéal mais ça fonctionne et le répertoire est monté à chaque redémarrage.
    Attention, @reboot, <user_nas> et la commande de montage doivent être séparés par une tabulation et non par un espace.

  • Vu que je vais en avoir besoin, j'ai installé sshfs sur mon syno et je n'arrive pas non plus à monter le répertoire distant depuis fstab ni avec ma syntaxe, ni avec celle d'Aerya.

    mount: wrong fs type, bad option, bad superblock on sshfs#<user>@<domain.tlf>:<dossier_source>,
           missing codepage or helper program, or other error

    J'ai fait quelques recherches et apparemment le DSM ne gère pas normalement le fichier fstab, notamment pour la reconnaissance des fs ...
    Je vais voir si je trouve une solution.

  • Essaye de faire un sudo mount -a , tu devrais voir le message d'erreur retourné par le montage depuis fstab.

  • clem73
    Salut,
    Ta méthode pour les clés n'est pas la bonne. La clé publique doit être ajoutée dans le fichier
    .ssh/autorized-key du home de ton utilisateur ssh du dédié. Pour celà tu as deux méthodes.
    Méthode automatique (Sur le NAS):

    ssh-copy-id -i ~/.ssh/id_dsa.pub <user_dédié>@<adresse_dedidé>

    Une fois rentré ton mot de passe, la clé sera automatiquement ajoutée.

    Méthode manuelle :
    - Sur le NAS : copier le contenu du fichier ~/.ssh/id_rsa.pub
    - Sur le serveur : coller la ligne dans le fichier .ssh/authorized_keys du home l'utilisateur que tu utilises pour te connecter au serveur en SSH.

    Pour tester : ssh <user_dédié>@<adresse_dedidé>

  • Merci pour le retour, je suis reparti sur une base neuve du coup.

  • Salut,
    J'ai pas sshfs d'installé sur mon Syno donc je peux pas tester directement mais sur mon dédié voilà la syntaxe que j'utilise dans /etc/fstab

    <user_ssh>@<domain.tld>:<source_directory> <target_directory> fuse.sshfs rw,nosuid,nodev,uid=1000,gid=1000 0 0

    Les uid et gid sont à modifier selon ton utilisateur sur le Synology.
    Par contre pour que cela fonctionne, il te faudra une connexion par clé. Qu'est ce qui bloque dans tes tentatives d'utilisation des clés ?

  • Suite a cette discussion j'ai testé Medusa a la place de Sickrage et ça m'a l'air sympathique.
    J'ai écrasé la base d'origine Medusa (main.db) par celle de Sickrage (sickbeard.db) et tout l'air de se charger correctement, mais est-ce que quelqu'un a testé cette solution un certain temps ? Vaut-il mieux repartir d'une base vierge et tout recréér ?

    Edit : J'ai rien dit, la réponse est sur leur github.

    Before using this with your existing database (sickbeard.db) please make a backup copy of it and delete any other database files such as cache.db and failed.db if present
    We HIGHLY recommend starting out with no database files at all to make this a fresh start but the choice is at your own risk.

    • chlotus
      C'est un fichier classique, tu peux l’éditer avec nano ou simplement l'afficher avec cat ou less/more.

      • chlotus
        Le plus simple a mon avis est de rediriger la sortie de ton script vers un fichier de log au lieu de /dev/null

        55 23 * * * bash /root/scripts/rsync.sh > /ton/fichier/log 2>&1

        Il ne te restera plus qu'a vérifier le contenu de ton fichier de log.

        • Pour Youtube, il faut quand même faire attention au CGV selon ce qu'on y poste. A savoir :

          1. Les droits que vous concédez

          8.1 Lorsque vous soumettez du Contenu sur YouTube, vous concédez :

          à YouTube, le droit non exclusif, cessible (y compris le droit de sous-licencier), à titre gracieux, et pour le monde entier d'utiliser, de reproduire, de distribuer, de réaliser des œuvres dérivées, de représenter et d'exécuter le Contenu dans le cadre du Service ou en relation avec la mise à disposition de ce Service et l'activité de YouTube, notamment, sans limitation, pour la promotion et la redistribution de tout ou partie du Service (et des œuvres dérivées qui en résultent), en tout format, sur tout support et via tous les canaux média ;

          • Salut,
            Pour couchpotato, tu peux gérer les langues directement en créant des catégories.
            Il suffit d'en créé une pour la VF et une pour la VOST et de jouer sur le paramètre 'Required'
            VF / Required: french, truefrench,multi
            VOST / Required: vost,multi
            Tu peux ensuite choisir quelle catégorie tu veux utiliser quand tu ajoutes un film.

            Pour Sickrage, ça se gère au niveau de chaque série où tu as un réglage des Required également.

          • chlotus
            On sait jamais, autant demander, ça évite de passer des heures sur un faux problème 😉

          • chlotus
            Ah d'accord, du coup tu pourras essayer toutes les commandes possible depuis ton dédié, rien ne fonctionnera.
            Si ton NAS est derrière une box internet, est-ce que tu as bien redirigé ton port SSH vers le NAS dans la configuration de ta BOX ? Ce port est-il bien ouvert dans le firewall de la Box ?
            Et est-ce que tu utilises bien ton IP publique et non l'IP locale de ton nas (192.168.***.***) ?

            • Et en le faisant en deux fois ?
              Sur ton dédié, tu copies le contenu de ~/.ssh/id_rsa.pub
              Tu te logges sur ton nas et tu colles ?

              ssh admin@<ip_du_nas>
              echo '<tu_colles>' > ~admin/.ssh/authorized_keys
              • Salut Chlotus,
                Comme te l'as dis Aerya plus haut, il faut que tu copies la clé dans le home de l’utilisateur que tu utilises pour te connecter en SSH à ton NAS.
                Le bon chemin du fichier à modifier, sauf si tu te connectes en root, est donc:

                ~<ton_user_nas>/.ssh/autorized_keys
                Equivalent à 
                /var/services/homes/<ton_user_nas>/.ssh/autorized_keys

                Ensuite depuis le dédié, en étant connecté avec l'utilisateur qui a généré les clés SSH, tu dois pouvoir te connecter sans mot de passe avec:

                ssh <ton_user_nas>@<ton_user_nas>

                Voilà un exemple de configuration fonctionnelle chez moi, tu devrais arriver a quelquechose d'équivalent pour que ca marche.
                Sur le dédié, connecté avec mon <user_dedie>:

                <user_dedie>@Laptop-Mint ~ $ cat ~/.ssh/id_rsa.pub
                ssh-rsa AAAAB3NzaC1yc2EAAAA(...)AVm9PXE8olZeKv8QaYQLeNV <user_dedie>@Laptop-Mint

                Sur le NAS, connecté avec mon <user_nas>:

                <user_nas>@nas:~$ cat ~/.ssh/authorized_keys 
                ssh-rsa AAAAB3NzaC1yc2EAAAA(...)AVm9PXE8olZeKv8QaYQLeNV <user_dedie>@Laptop-Mint

                Si ça ne fonctionne toujours, il me semble que j'avais du activer la connection par clé qui est désactivée par défaut sur Synology.
                Pour cela, tu dois éditer le fichier de conf ssh

                sudo vi /etc/ssh/sshd_config

                Et décommenter les deux lignes suivantes :

                PubkeyAuthentication yes
                AuthorizedKeysFile	.ssh/authorized_keys

                Ensuite tu redémarres le service ssh:

                sudo synoservicectl --reload sshd
                • Aurioda
                  Oui en effet, j’étais parti sur autre chose et ca m'était sorti de la tête.
                  Voilà la nouvelle version basée sur la branche 'alpha' utilisé par le tuto:

                  https://github.com/Sunnay31/synhcro-seedbox

                  Le paramètre @user@ est a remplacer ligne 22 et 104 dans le fichier index.php si on ne fait de nouvelle installation.

                  Je l'ai testé en faisant une nouvelle install en suivant le tuto et en ne remplaçant que le fichier index.php sur une ancienne install, je n'ai pas eu de problème particulier. Tenez moi au courant si ça ne fonctionne pas.

                  • Aerya
                    La methode de fana m'a l'air d'être la meilleure après avoir relu le post de magicalex sur les directives nginx.
                    Son ^~ permet de limiter la résolution de l’adresse à cette location et donc ignore les autres locations avec lequel il pourrait y avoir un conflit. Ça m'a permit de régler un soucis plus ou moins similaire sur couchpotato qui n'affichait pas les icônes.

                  • superboki
                    Tu dois tout mettre dans le même fichier .conf à l’intérieur de ta déclaration server { } sauf si tu comptes utiliser plusieurs domaines ou ports pour le HTTP.
                    Par contre tu peux le renommer comme tu veux, ça n'a aucun impact.

                    • Salut Ernie95
                      Tu peux essayer ces paramètres en adaptant le port 5001 à ta config :

                      Host : scgi://localhost:5001
                      RPC URL, User Name et Password : vide