aegir_fr

Oui, enfin là on n'est pas dans de la bêta-version, on est dans de la mise à jour supposée stable...

Même problème avec mon téléviseur Panasonic, j'ai la liste des videos, mais pas de flux video. Mon routeur ne voit même pas l'UpnP du serveur média synology...

Bonjour, Je voulais faire un script PHP sur le synology qui attaque une base de données postgreSQL qui se trouve sur une autre machine. Mais lors du pg_connect j'avais obstinément le message "PostgreSQL is not a open service"... J'ai fini par trouver une solution de contournement sur un forum polonais, je mets ça ici, ça peut servir à d'autres, parce que perso je n'aurais jamais trouvé tout seul. Bon, d'abord il faut évidemment que le serveur postgresql accepte bien les connections distantes ( listen='...' dans postgres.conf et accès ouvert à la base pour le user depuis le NAS dans pg_hba.conf ). Vérifier avec un "psql -h host -p 5432 -U user dbname" en ligne de commande sur le syno que la connexion est bien OK. Ensuite, l'astuce est d'utiliser les objets PDO. Aucune idée du pourquoi de la chose. Je vous mets un petit exemple vite fait, ça peut éviter à d'autres de s'arracher les cheveux : try{ $db = new PDO('pgsql:host=192.168.1.100;dbname=aegir', 'user', 'password'); $db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); $db->exec("SET CLIENT_ENCODING TO 'UTF8'"); } catch (PDOException $e) { echo "<center><b><font color='red'>Serveur non disponible</font></center></b><br/>"; } if ( isset($db) ) { echo '<center><table>'; $sql = $db->query( "SELECT filename, ts_headline('french',content,q,'MaxWords=45, MinWords=25') hl, rank FROM (SELECT filename, content, q, ts_rank_cd(textsearchable_index_col,q ) AS rank FROM documents,to_tsquery('french','".$q."') q WHERE textsearchable_index_col @@ q ORDER BY rank DESC LIMIT 20) AS foo;" ); while( $row = $sql->fetch( PDO::FETCH_ASSOC ) ) { echo "<tr><td>"; echo "<a href='".$url."'>".$lib."</a></td><td>".$rang." %</td><td>"; echo $row['hl']; echo "</td></tr><br>n"; } echo "</table></center>"; }

Oui mais c'est bon, le find -links +1 ça marche avec le find de la busybox. De même que les "while read" etc. ça marche bien avec /bin/ash. Depuis le début de l'échange, le seul truc qui m'a manqué, c'est le flag ' du printf de awk pour avoir un séparateur de milliers.

Oui ben vaut mieux tester... Vu comme ça, je ne vois pas pourquoi ça ne marcherait pas, mais ça a un coté un peu "sauvage" et il y a souvent des cas de figure auxquels on avait pas pensé...

Attention hein ? Il faut supprimer les sauvegardes une par une ; et ré-exécuter la commande après chaque suppression. (puisque à chaque suppression, tous les compteurs de hardlinks seront décrémentés).

Bon, j'ai continué à fouiller, et manifestement voici un cas qui peut expliquer des problèmes : nas> ls -lsa "20140119-0000/homes/patricia/PATRICIA-2012/Backup Set 2013-03-03 190610/Backup Files 2013-03-17 190003/Catalogs/Backup files 4.wbcat" 4 -rwxrwxrwx 5 patricia parents 1588 Mar 17 2013 20140119-0000/homes/patricia/PATRICIA-2012/Backup Set 2013-03-03 190610/Backup Files 2013-03-17 190003/Catalogs/Backup files 4.wbcat nas> ls -lsa "20140126-0000/homes/patricia/PATRICIA-2012/Backup Set 2013-03-03 190610/Backup Files 2013-03-17 190003/Catalogs/Backup files 4.wbcat" 4 -rwxr-x--- 1 patricia parents 1588 Mar 17 2013 20140126-0000/homes/patricia/PATRICIA-2012/Backup Set 2013-03-03 190610/Backup Files 2013-03-17 190003/Catalogs/Backup files 4.wbcat nas> synoacltool -get "20140119-0000/homes/patricia/PATRICIA-2012/Backup Set 2013-03-03 190610/Backup Files 2013-03-17 190003/Catalogs/Backup files 4.wbcat" (synoacltool.c, 350)It's Linux mode nas> diff "20140126-0000/homes/patricia/PATRICIA-2012/Backup Set 2013-03-03 190610/Backup Files 2013-03-17 190003/Catalogs/Backup files 4.wbcat" "20140119-0000/homes/patricia/PATRICIA-2012/Backup Set 2013-03-03 190610/Backup Files 2013-03-17 190003/Catalogs/Backup files 4.wbcat" nas> J'ai donc bien 2 fichiers parfaitement identiques, dont la date n'a pas été modifiée entre mes 2 derniers backups, et pourtant comme on peut le voir, au backup précédent il y avait 5 hardlinks, alors qu'au dernier backup il a recréé le fichier avec un hardlink à 1. Et les ACL ne sont pas activés sur mon syno (et ne l'ont jamais été). En fait, la différence ce sont les droits d'accès de base (owner, group, other). Et effectivement, entre les 2 backups, j'ai fait des modifs sur les privilèges des utilisateurs. Donc toute modif sur les privilèges des utilisateurs peut entraîner un backup différentiel d'un très grand volume.

Non même pas ! La date de création figure dans l'inode ; quel que soit le hardlink pointant vers l'i-node ils auront tous la même date, le même propriétaire, les mêmes droits etc. puisque c'est le même fichier. Par contre, tu peux effectivement comparer la date de création par rapport à la date de la sauvegarde n-1

Mais oui, tu te trompes, je te dis que tu confonds avec les liens symboliques. Je ne sais pas comment l'expliquer autrement, mais dans un hardlink il n'y a pas de "fichier vers lequel tu pointes". C'est juste un non-sens. Par définition, tous les fichiers sont des hardlinks. Je vais essayer d'expliquer simplement : Un "fichier" c'est un i-node ( une sorte de bloc ) qui contient les caractéristiques du fichier : propriétaire, droits d'accès, taille, liste des blocs de données etc. et aussi le compteur de hardlinks. Mais l'i-node ne contient _PAS_ le nom du fichier. Tant que ce compteur de hardlinks est à zéro, le fichier n'existe pas sur le filesystem. Ensuite, on donne un nom au fichier, pour ça on ajoute dans le répertoire où on veut mettre le fichier une entrée, avec le nom et le numéro d'inode du fichier. En faisant cela on incrémente le compteur de hardlinks de l'inode. À ce moment, le fichier existe enfin. Il a une entrée dans un répertoire (donc un nom) et le compteur de hardlinks est supérieur à zéro. Si on ajoute d'autres entrées dans ce répertoire (ou d'autres répertoires) pointant vers ce même i-node, pour chaque entrée le compteur de hardlinks de l'inode est incrémenté. Ensuite, si on détruit une entrée dans un répertoire qui pointe sur cet inode, le compteur de hardlinks est décrémenté. Lorsque le compteur arrive à zéro, le filesystem efface l'inode et libère les blocs de données. Il n'y a donc pas de notion de "pointer vers un fichier". Chaque fichier est un hardlink vers un inode. Sous Un*x ; un fichier n'est pas désigné par son nom, mais par son numéro d'inode (c'est d'ailleurs le seul moyen de supprimer un fichier qui a dans son nom des caractères invalides). Ça fait plus de 30 ans que ça fonctionne comme ça.

Non, tu confonds les hardlinks et les liens symboliques. Les hardlinks sont des fichiers normaux. En fait, n'importe quel fichier est un hardlink ; sauf qu'à sa création le compteur de hardlinks est à 1. 2 hardlinks ont forcément le même noms, puisque c'est le même inode. Edit Non là je ne suis pas clair, 2 hardlinks peuvent avoir des noms différents, mais comme c'est le même inode de fichier il n'y en a pas un qui pointe sur l'autre. On peut supprimer le 1er le 2ème sera toujours là et vice-versa. Le fichier ne sera supprimé du disque que lorsque le compteur de hardlinks de l'inode arrivera à zéro. Sous DOS/Windows les hardlinks n'existent pas, il n'existe que l'équivalent des liens symboliques. Autrement on peut scripter un truc basé sur les inodes pour chercher les différences.

tu peux faire ça : nas> pwd /volume2/backup/TimeBackup/nas_001132193CB1/task_1 nas> ls 20131215-1810 20131229-0000 20140105-0000 20140112-0000 20140119-0000 20140126-0000 nas> for i in * ; do echo $i ; find $i -type f -links 1 -exec ls -lsa {} ; | awk '{SUM += $6} END {printf "%16.1f",SUM/1024; print " kilo-octets n" }' ; done 20131215-1810 14675.6 kilo-octets 20131229-0000 0.0 kilo-octets 20140105-0000 0.0 kilo-octets 20140112-0000 0.0 kilo-octets 20140119-0000 0.0 kilo-octets 20140126-0000 8972085.9 kilo-octets Mais c'est pas très intéressant, parce que comme seuls les fichiers avec le hardlink à 1 sont comptés, ça ne donne pas des résultats pertinents. Par exemple, pour la sauvegarde du 19 janvier, il est indiqué "0.0 kilo-octets" ; on pourrait croire qu'il n'y a pas eu de fichier modifié entre le 12 et le 19 janvier. Mais c'est pas vrai, si un fichier a été modifié mettons le 18 janvier, et n'a pas été modifié ensuite il figure dans les sauvegardes du 19 et 26 janvier, il a donc son hardlink à 2. Cette commande n'est donc utile qu'en l'appliquant sur la sauvegarde la plus récente pour voir le delta entre les 2 dernières sauvegardes.

Salut, Pour savoir précisément l'occupation de ta sauvegarde, en étant dans le répertoire de la sauvegarde tu peux utiliser la commande : find . -type f -links 1 -exec ls -lsa {} ; | awk '{SUM += $6} END {printf "%16.1f",SUM/1024; print " kilo-octets n" }' Ça va faire la somme de la taille de tous les fichiers réguliers dont le compteur de hardlinks est à 1. Ça ne va donc pas compter les fichiers qui n'ont pas été modifiés depuis la dernière sauvegarde, et qui sont donc juste linkés. Le résultat sera un peu différent de ce que t'indique le gestionnaire de stockage, car là on ne compte que la taille des données, on ne compte pas les éventuels extended-attributes (ACL). De plus on ne compte que les données "utiles" du fichier. Par exemple un fichier de 200 octets sera comptabilisé par cette commande comme 200 octets, alors que pour le gestionnaire de stockage, le fichier occupant 1 block de données, il va "manger" 4096 octets de place sur le disque (1 block). Exemple : nas> pwd /volume2/backup/TimeBackup/nas_001132193CB1/task_1/20140126-0000 nas> find . -type f -links 1 -exec ls -lsa {} ; | awk '{SUM += $6} END {printf "%16.1f",SUM/1024; print " kilo-octets n" }' 8972085.9 kilo-octets nas> du -sh . 86.8G . Voilà, j'ai 86,8 Go de données sauvegardées, et ma sauvegarde de dimanche dernier n'occupe que 8,9 Go (désolé pour la lisibilité, avec le awk busybox des synology, on ne peut pas utiliser le flag des séparateurs de milliers).

Après vérification, il n'y a pas getfacl / setfacl installés sur mon syno. Par contre, synology a apparemment fait son propre outil maison nommé "synoacltool". "synoacltool -h" donne les options disponibles. Il semblerait qu'on puisse supprimer les acl avec la commande "synoacltool -del /mon/fichier" À tester hein ? Comme je l'ai dit, j'ai pas les ACL activés sur mon syno, donc je peux pas tester. À noter, l'outil a des options spécifiques, permettant par exemple d'effacer l'archive-bit d'un fichier. Voir la doc obtenue avec "-h".

A priori, ça devrait être "getfacl fichier" pour voir les ACL d'un fichier ; et "setfacl -b fichier" pour enlever les ACL d'un fichier. Mais je n'ai pas pas mon syno sous la main pour tester, et de toute façons, j'ai pas les ACL d'activés dessus. T'es sûr qu'ils n'ont réellement pas changé ? (droits d'accès, date de modification etc.)

En ext4, par défaut un inode occupe 256 octets. Donc 10.000 fichiers occupent au minimum 2,5 Mo Cependant un inode ne peut contenir que 100 octets d'extended attributes (comme typiquement les ACL de windows), donc si ce n'est pas suffisant il les stocke dans un block de données (qui fait en général 4Ko). Dans ce cas là, chaque fichier occupe 256+4096=4352 octets. Pour 10.000 fichiers cela fait 43 520 000 octets ; soit 41,5 MiO Donc rien de surprenant dans ton cas.

Non, si tu fais clic-droit->propriété sous FileStation, tu as effectivement l'impression qu'ils font tous le même poids, parce qu'il calcule la taille des fichiers sur lesquels pointent les liens. Par exemple, si je demande là FileStation e calcul de la taille occupée par le dossier "TimeBackup" qui contient toutes les sauvegardes, il m'indique 379 GB parce qu'il compte la taille du fichier pour chaque sauvegarde. Mais si sous le gestionnaire de stockage je demande les infos sur le volume dédié que j'ai créé pour time backup, il m'indique 87 GB d'occupés. Par contre, Padawan s'est trompé, ce sont des liens physiques et non pas symboliques. Tu peux donc effacer manuellement une vieille sauvegarde, les sauvegardes plus récentes seront toujours valables. Ça se vérifie facilement en se connectant par ssh sur le NAS : nas> pwd /volume2/backup/TimeBackup/nas_001132193CB1/task_1/20140119-0000/photo nas> ls -lsa 4 drwxrwxrwx 5 root root 4096 Dec 21 12:03 . 4 drwxr-xr-x 4 root root 4096 Jan 19 00:01 .. 8 -rwxrwxrwx 5 admin users 6148 Feb 19 2013 .DS_Store 4 drwxrwxrwx 3 nobody nobody 4096 Feb 19 2013 @eaDir 4668 -rw-rw-r-- 5 1000 1000 4778936 Mar 24 2013 doublons.txt 432 -rw-rw-r-- 5 1000 1000 441975 Mar 10 2013 doublons2.txt 4372 -rw-rw-r-- 4 1000 1000 4473947 Dec 21 12:03 doublons3.txt 136 drwxrwxrwx 21 admin users 139264 Dec 19 22:02 herve 4 drwxrwsrwx 14 admin users 4096 Feb 19 2013 mac nas> Les chiffres en rouges indiquent combien de fois le fichier est lié. J'ai effectivement un historique de 5 sauvegardes ; et le fichier doublons3.txt est plus récent que la plus vieille sauvegarde, il est donc lié seulement 4 fois ( présent dans 4 sauvegardes).

Je n'ai jamais dit que le RAID ne servait à rien, que ce soit en 4 baies ou en 2 baies. J'ai dit qu'en général, à la maison, la problématique c'est de sécuriser ses données plutôt qu'avoir une continuité de service, et donc pour ça avec 2 disques, vaut mieux avoir des sauvegardes de l'un sur l'autre plutot que mettre les 2 disques en RAID. Et surtout, je n'ai jamais dit que du RAID sur du 2 baies ne servait à rien, J'ai simplement dit que si on ne fait pas de RAID, avec un 2 baies AMHA ça ne sert pas à grand chose de faire du disk-group. [MODE DECONNADE] Faudrait apprendre à lire correctement hein ? [/MODE DECONNADE]

L'avantage du RAID, c'est que si un disque claque, le NAS continue à fonctionner. C'est très utile pour les entreprises pour qui une heure où le personnel ne peut pas travailler c'est de l'argent perdu , mais à la maison, ce qu'on veut surtout, c'est une sauvegarde, pour ne pas perdre les photos de famille par exemple. Et le RAID n'est pas une sauvegarde, si tu te gourres et que tu supprimes le mauvais dossier tu dis "Ooops", et t'as tout perdu, même si t'es en RAID. Oui moi je laisserais les deux disques en BASIC. Perso, j'ai un 4 baies, avec 3 disques, donc j'ai créé 3 "group disk" de 1 disque, comme ça si j'ai des problèmes de taille de stockage, j'ajoute un 4ème disque et je pourrais étendre la taille du volume de mon choix. Mais avec un 2 baies, ça ne sert à rien, autant mettre chaque disque en basique. En ce qui me concerne, j'a 2 disques de 2To et 1 de 3To. Celui de 3To sert uniquement pour les sauvegardes, et une fois par semaine Time Backup me sauvegarde mes dossiers importants ( photo, home, homes ...) sur celui de 3To. Si j'ai un disque qui pète, ben j'ai une sauvegarde, mais comme je ne suis pas en RAID je ne pourrais pas utiliser le dossier partagé le temps que je remplace le disque. L'important c'est que je puisse récupérer mes données.

Pourquoi tu veux du RAID ? T'es bien sûr que ce soit utile ? AMHA une sauvegarde automatique du premier disque sur le second est bien plus appropriée. On rappelle que : 1) Le RAID n'est PAS une sauvegarde. 2) Le RAID sert à la continuité de service en cas de panne. Si ton idée est de mettre à l'abri tes données en cas de panne de disque, une sauvegarde est bien plus appropriée. Par contre, si ton problème c'est de pouvoir continuer à accéder à tes données normalement en cas de panne d'un disque dur, et que ça ne peut pas attendre le temps de changer le disque, le RAID est approprié.

Le SHR sert si tes disques n'ont pas la même capacité. Pour faire simple; le plus gros disque va être partitionné afin d'avoir une partition de taille identique à l'autre disque, et le reste de la place dans une autre partition. Comme ça si les deux disques sont mis en RAID, tu as le reliquat qui n'est pas perdu et qu tu peux utiliser pour un autre volume.

C'est bon j'ai trouvé, il faut aller dans le panneau de config, puis dans "portail des applications".

Bonjour, D'après la (mauvaise) doc DSM 4.1 page 126, il est indiqué qu'on peut accéder à video station par navigateur à l'adresse http://Synology_Server_IP_Address/video/ Si j'essaye http://nas/video/ ça me répond "la page que vous recherchez n'existe pas". Par contre http://nas/photo/ fonctionne bien pour photo station De même, via DSM ( http://nas:5000/ ) je peux lancer/consulter video station sans problème. J'avais le problème après avoir installé le video station "stable". Là je viens d'installer la version bêta pour tester l'indexation en français (qui fonctionne très bien) et c'est toujours pareil. Il y a une astuce, un truc à faire dans la config pour ouvrir http://nas/video/ ? Merci.

Il truc qu'il faudrait dire aussi, c'est que quand on fait un RAID5 sur 3 disques, ok, on a une tolérance de panne sur un disque. Mais comme il y a 3 disques, on a des pannes 3 fois plus souvent...

Il y a une raison technique parfaitement valable : Les disques utilisés dans des baies doivent garantir un temps de réponse maximal. Le risque c'est d'avoir un disque qui est brusquement déclaré invalide par la baie, juste parce qu'il a dépassé ce temps de réponse, alors qu'il n'a en fait aucun problème.

Bonjour, WD déconseille l'utilisation de WD GReen dans les NAS et/ou en RAID. http://www.wdc.com/fr/products/products.aspx?id=780 (voir la note de bas de page)