cricx

Personnellement je trouve un peu inutile d'avoir deux serveurs ssh qui tournent, sachant qu'un seul permet aussi bien d'utiliser scp et sftp et ssh, bien s

l'extension d'un fichier est une notion typiquement "windowsienne", elle n'est pas nécessairement utilisée sous linux. Le type d'un fichier est reconnu grâce à un "magic number" correspondant à son contenu (par exemple, un exécutable windows est reconnu par les lettres MZ au début du fichier, ou une image jpeg par JFIF). Essaie avec la commande file (file nom_de_ton_fichier). Un fichier exécutable doit avoir l'attribut exécutable positionné. Un fichier texte (script) exécutable via un interpréteur de commande (bash, sh, perl, python...) est capable d'invoquer directement sont interpréteur s'il commence par un shebang (par exemple #!/usr/bin/perl va invoquer perl et lui faire exécuter le script), mais un script sans shebang peut être exécuté en invoquant l'interpréteur et en lui fournissant le nom du script (par exemple sh monscript). Dans ce cas, monscript ne nécessite pas d'être exécutable. Quand on rajoute une extension, c'est plus pour savoir visuellement quel est le type du fichier (on se dit logiquement qu'un .sh est un script shell, .pl un script perl). Donc pour qu'un script ne se lance pas : - s'il est exécutable par lui même (il commence par un shebang et a l'attribut exécutable) : on peut lui enlever l'attribut exécutable, ou enlever le shebang, ou les 2 - s'il est exécuté via l'interpréteur lui même : la seule solution consiste à mettre en première ligne l'instruction exit. mais il faut savoir que les init scripts sont lancés automatiquement en faisant le listage alphabétique des script situés dans un répertoire donné (cest pour ça qu'on mets S99 pour un script à lancer en dernier), ce listage pouvant être partiel (on ne liste que les Sxxzzzzzzz, ou que les Sxxzzzzz.sh). Dans ce cas, changer le nom ou l'extension peut suffire. Je n'ai pas de syno sous la main pour vérifier comment les init scripts sont lancés, mais je suis sûr que quelqu'un pourra te répondre à ce sujet. De mémoire, ce mot de passe était utilisé dans les premières versions du firmware. Ce n'est plus le cas maintenant. Je suppose que tu n'as pas du mettre à jour le firmware, peux-tu confirmer quelle est ta version ? Oui, il peut très bien y avoir plusieurs instances de ssh qui tournent (mais elle ne doivent pas écouter le même port). Qu'est-ce qui te fait dire qu'il y a plusieurs instances qui tournent ? si tu es connecté au syno via ssh, tu as deux tâches ssh : le démon qui reste en écoute, et ta connexion en cours. Si tu faisait en même temps un rsync sur ssh ou un scp ou un sftp, tu aurais encore d'autres tâches ssh. Mais il n'y a pour autant qu'une instance qui tourne, elle fait un fork pour chaque nouvelle connexion.

oui

cette notion apparemment simple mérite d'être précisée : - le client est, celui qui se connecte sur l'autre, qui est à l'initiative de la connexion. Le transfert de données pouvant alors s'effectuer dans un sens ou l'autre - le serveur peut être ssh (port 22) ou rsync (port 873) - l'implémentation ssh/rsync d'origine sur syno est incomplète et n'utilise pas les mécanismes standard catimini a l'ai de maitriser son sujet (malgré ou grâce à son âge avancé ;-) Il faudrait qu'il expose la solution qu'il a mise en place entre ses synos. pas clair... Rappel : rsync est un outil de transfert de fichiers intelligent. Il peut s'utiliser en local ou à distance. Pour la sécurité, il vaut mieux l'utiliser sur un tunnel ssh, ce qui est ebn général le comportement par défaut quand ls démon rsyncd (le service rsync) n'est pas utilisé. Sur un linux "normal", l'utilisation de rsync sur ssh utilise les comptes du système (logique puisqu'on utilise ssh), ce qui permet d'effectuer des transferts d'un compte local vers un compte distant, même différent, pourvu que l'on ait les identifiants du compte (nom + mot de passe) ou que l'on ait installé une paire de clés. Par exemple, dans le cadre professionnel, je fais souvent des transferts sécurisés avec la commande suivante : [user1@localhost ~]$rsync -avz mondossierlocal user2@serveurdistant:/lechemindistant Le transport est par défaut ssh, mais on pourrait le préciser avec l'option -e pas compris ce que tu veux dire non, pas besoin de laisser un pc allumé pour lancer un transfert ftp entre 2 synos... il suffit d'installer sur le syno client le paquet ncftp (il contient : ncftp ncftpbatch ncftpbookmarks ncftpget ncftpls ncftpput ncftpspooler) Le mieux est d'installer un vrai ssh et un vrai rsync. Mais on doit pouvoir configurer sur les dernières version du firmware rsync pour qu'il utilise ssh... En fait, je vais prochainement remettre en place ce que j'avais installé auparavant (mon syno me sert de serveur de sauvegarde de mes pcs, je fais un rsync à partir des comptes utilisateur vers le compte du même utilisateur du syno, sans qu'il soit besoin d'avoir les mêmes uid, et sans mot de passe, en utilisant une paire de clés. J'avais installé à l'origine les paquets optware car les premières versions du firmware étaient incomplètes. On devrait maintenant y arriver avec moins de bricolage. PS : il est tout-à-fait anormal de devoir utiliser le compte root pour faire des sauvegardes !

linux sur 2 fixes et 2 portables à la maison, également sur mon routeur (dd-wrt), mon syno , mon dd multimedia (tvix) linux sur mon poste principal au boulot, multiboot xp/linux sur mon poste secondaire, et une bonne vingtaine de serveurs linux palmos sur mon palm Sous linux exclusivement depuis plus de 10 ans... mais je n'arrive pas à tout faire : mon gps garmin (etrex) et ses cartes protégées ne sont exploitables que sous win et je vais être obligé, pour ce seul motif, à installer un win (en virtuel bien sûr)

si ce n'est que pour les alias, le postfix reload est inutile. Et il n'y a pas la commande d'édition du fichier aliases. Donc pas bon. de plus : un alias déclaré depuis le .profile d'un utilisateur ne fonctionne qu'avec cet utilisateur. La solution d'un script est meilleure que celle d'un alias. Mais bon, tu fais comme tu veux. Mais quand tu auras des années d'expérience d'admin linux, tu reviendra au script. Sinon, pour le côté fainéant, je suis bien d'accord, c'est fou l'énergie et le temps que je passe a écrire des scripts pour en faire le moins possible

si si, mais c'est l'