Du Mot De Passe Sur Les Synos

[Tof]

>> oui, je viens d'essayer, changer le Gid ne sert pas (c'était mon premier essai infructueux). c'est bien le Uid, mais dans ce cas,

>> le pass est commun mais le HOME, le shell peuvent être différents.

> le mot de pase doit pouvoir être différent (les mots de passe sont dans /etc/shadow et sont définis par le nom de l'utilisateur

> et pas son uid.

> tu peux dont ajouter un utilisateur et définir sont mot de passe, puis changer dans /etc/passwd son uid (mettre 0).

> Tu auras alors deux utilisateurrs "root" avec tous les pouvoirs (uid 0) avec shells, home et mots de passe différents.

bah...non, il me semble avoir suivi cette procédure, enfin il me semble. je réessayerai, comme tu me dis que c'est normalement possible.

>> d'ailleurs concernant le pass root et les spécificités syno:

>> en telnet, le pass root c'est celui de admin, utilisateur par défaut, ligne admin de shadow

> ??? en telnet, le syno me demande l'utilisateur, puis le mot de passe. Je mets root et le mot

> de pase de root, c'est effectivement à l'origine le même que celui d'admin.

>> si on change le pass (passwd), ce n'est pas celui de admin qui est affecté, c'est celui de root....

> La commande passwd lancée seule change le mot de passe de l'utilisateur connecté (faire who pour voir qui). Pour le changer

> le pass d'admin, il faut préciser passwd admin

ok, logique

>> en SSH le pass est synopass initialement, j'imagine celui de root dans le fichier shadow.

>> il est affecté par le changement du pass root en telnet.

> Avec le ssh d'origine, le pass est celui défini dans le fichier /etc/rsync.secrets (voir la conf de ssh dans /etc/ssh/sshd_config)

>> en SSH, le comportement des autres user est standard (pass correspond à user).

> pas chez moi, et je cherche le pourquoi. j'ai créé un user ordinaire via l'interface web, je peux me loguer en telnet avec ce

> nom/mdp.

> En ssh ça ne marche pas (en raison de la conf de ssh, cf plus haut). J'ai mis le mot de passe de l'utilisateurs dans

> /etc/rsync.secrets et ça ne marche toujours pas... pas très propre tout ça !

j'ai installé et utilisé openssh. à cause de tes remarques, je me suis rendu compte après qu'il était installé d'origine (mais version plus ancienne). Actif seulement quant netbackup est utilisé (ce qui n'est pas mon cas).

>> mais attention, j'imagine que changer le pass root pourrait empêcher le bon fonctionnement de netbackup(sauvegarde

>> réseau)/rsync.

> rsync utilise exclusivement les mots de passe de /etc/rsync.secrets . le mot de passe rsync pour root est différent de celui de root.

ok, vu.

> Le mot de passe apparaissant dans le fichier rsync.secrets est le mot de passe en clair à utiliser

> (testé : ça marche, aussi bien avec root qu'avec un autre utilisateur). Attention, pour lezs services rsync, il faut mettre root comme

> uid (sinon pb de changements de droits).

j'ai aussi les fichiers rsync_client.pass et rsync_restore .pass (mdp identiques) avec un mdp différents de rsyncd.secrets.

c'est peut-être là où il faut chercher le "pas très propre"?

> Pour la sauvegarde avec rsync sur un réseau 100 Mb, la vitesse semble faible (de l'ordre de 1.5 Mo/seconde) soit près de 3 heures

> pour sauvegarder 15 Go (rsync avec compression activée) donc pas terrible. mais bon, c'est juste la première fois, après seules les

> différences sont transférées et là ça va vite).

chez moi aussi, c'est très faible, sans compression :

rsync Gigabit sur 1 fichier 530 Mo : 2.69Mo/s (serveur1 win2000 [giga]-> syno [giga])

rsync 100Mbits sur 1 fichier 530 Mo : 2.93Mo/s (serveur1 win2000 [giga]-> serveur2 win2000 [100])

rsync 100Mbits sur 1 fichier 530 Mo : 2.85Mo/s (station XpPro [100]-> syno [giga])

les quelques essais que j'ai fait en transferts sont aussi déplorables quant à l'augmentation de performances gigabits/100Mbits et j'en arrive à mettre les caractéristiques gigabits de mon ds-106j en doute. mais je dois encore faire d'autres essais avant d'affirmer.

[cricx]

[Tof]

>une petite modif à faire dans le script de lancement de ssh et ça roule sans activer netbackup

yes, mais je préfère garder ma version à côté (plus récente) installée de zéro, comme ça je sais ce que j'ai fait sans chercher l'existant (ce qui est un peu difficile quand on apprend de zéro).

>Chez moi je nai pas ces fichiers, je n'ai pas configuré de sauvegarde réseau.

ok. j'avais fait un essai (positif) pour voir si je pouvais sauvegarder sur un serveur rsync lambda.

>Je peux le faire maintenant que j'ai installé ma clé dsa sur le syno (login ssh sans mot de passe).

idem, pour éviter éventuel autre pass backdoor, j'ai aussi désactivé l'authentification par mdp, ligne PasswordAuthentication no dans sshd_config

>bon, c'est quand même 2 fois plus rapide que chez moi...

sur 1 seul gros fichier pour essai débit. sur des répertoires avec plusieurs petits fichiers, c'est bien plus faible, selon stats rsync, de l'ordre de 0.5 à 1.6 Mo/s. l'algo de rsync doit y être pour quelque chose.

>ou le disque dur ? faire un hdparm -tT /dev/hda pour voir)

DiskStation> ipkg update

DiskStation> ipkg install hdparm

Installing hdparm (6.1-1) to root...

DiskStation> hdparm -tT /dev/hda

Timing cached reads: 208 MB in 2.00 seconds = 104.00 MB/sec

Timing buffered disk reads: 72 MB in 3.03 seconds = 23.76 MB/sec

DiskStation> hdparm -c1 -d1 /dev/hda

setting 32-bit IO_support flag to 1

setting using_dma to 1 (on)

IO_support = 1 (32-bit)

using_dma = 1 (on)

DiskStation> hdparm -tT /dev/hda

Timing cached reads: 212 MB in 2.01 seconds = 105.47 MB/sec

Timing buffered disk reads: 76 MB in 3.02 seconds = 25.17 MB/sec

à priori pas grand chose à gagner

>il y a un utilitaire syno permettant de connaître le statut de la carte réseau et notamment la vitesse

DiskStation> /usr/syno/bin/synoethinfo eth0

Settings for eth0 :

Link Speed:1000

Duplex Mode:Full

MTU:1500

ça à-priori, c'est bon. j'ai pas encore essayé les 'jumboframes'.