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.