Yokav

Pour info, j'ai trouvé ma réponse ici http://forum.synology.com/enu/viewtopic.php?f=20&t=95078 Ce que j'explique dans mon précédent poste n'est plus disponible avec la dernière version de DSM. Il n'est donc plus possible de choisir quelle bdd on sauvegarde et d'avoir ainsi un fichier de sauvegarde par bdd. Désormais, c'est l'ensemble du paquet et des bases de données qui est sauvegardé au sein d'un seul et même fichier. On est donc obligé de restaurer toutes les bases de données en même temps. Si on veut se retrouver avec le même système de sauvegarde qu'avant, ils recommandent de passer par tâche exécutant un script qui fera la sauvegarde désirée. On peut trouver ici http://forum.synology.com/enu/viewtopic.php?f=160&t=95955quelques lignes de codes qui une fois adaptées pourront faire l'affaire.

Ouaip, je regardais sur un nas sans MariaDB, de fait j'aurais pas pu voir cette option. Par contre, après vérification, sous DSM 5.0 mes sauvegardes de bdd finissaient dans "DossierDuBackup -> @app -> @msql -> nom_de_la_bdd.sql.gz". Ici c'était parfaitement exploitable, un fichier sql par bdd qui est tout simplement compressé. Maintenant sous DSM 5.1, ça doit ce passer par ici "DossierDuBackup -> @app -> @Application -> MariaDB -> @data -> data.compress". Ce fichier ne me semble pas très exploitable... Pas moyen de le décompresser.

Merci CoolRaoul, c'est bien ça que je cherchais, j'aurais du ouvrir un peu plus les yeux. Je trouve du coup un peu bizarre d'obliger la sauvegarde de la config lors de toute tâche de sauvegarde, m'enfin tant que l'option est toujours bien là... Il ma manque juste une chose du coup, la précédente version proposait le backup des bases de données... ici cela semble ne plus être possible.

Merci pour l'info. Ça corrige ainsi une partie du problème mais on est toujours pas avec ce que l'on avait avant. J'aurais du préciser dans mon message d'origine que je cherchais à savoir si cette fonctionnalité n'aurait pas été déplacée ailleurs et si elle n'existait plus, savoir si il existait une alternative. Si cette fonctionnalité à réellement disparu, je trouve ça vraiment bizarre... à quoi bon faire régresser cet outil pourtant bien pratique.

Bonjour, Il s'agit d'une option qui existait avant et qui ne semble plus disponible. Je m'en suis rendu compte car je désirais déplacer le dossier de backup d'une tâche de sauvegarde automatique. Ça ce passe donc dans la partie "Sauvegarde et réplication" où il était possible de créer une tâche permettant de sauvegarder la config du nas vers un répertoire local. Je me sers de ça depuis toujours, ce dossier local de sauvegarde est lui-même sauvegardé sur un support externe. Ainsi en cas de crash, je suis certain de pouvoir récupérer ma config. Hors malheureusement cela semble impossible à reproduire désormais, excepté en générant un sauvegarde de la config au format dss via "Panneau de Config -> Mise à jour et... -> Sauvegarde..." qui est bien moins complet que ce qui existait avant.

Merci pour le lien CoolRaoul, je vais déjà commencer par retirer ces clés du registre et voir ce que ça donne. Il est vrai que l'antivirus pourrait être responsable, j'utilise pour ma part kaspersky et je pense que par défaut, il n'analyse pas systématiquement ce qui se trouve sur un lecteur réseau. ---- edit: Voilà, j'ai appliqué le correctif et je suis presque certain que le problème est résolu. Encore un tout grand merci. Pour info, les clés du registre à supprimer sont : HKEY_CLASSES_ROOTCABFolderCLSID HKEY_CLASSES_ROOTCompressedFolderCLSID HKEY_CLASSES_ROOTSystemFileAssociations.cabCLSID HKEY_CLASSES_ROOTSystemFileAssociations.zipCLSID

Bonjour, J'ai remarqué quelque chose d'étrange dont je n'arrive pas à trouver la cause, j'ai une augmentation de "charge" importante lorsqu'un utilisateur (sous windows) parcours un dossier partagé contenant des fichiers zip et ce même si il n'en n'ouvre aucun. Cette augmentation de "charge" se traduit par une augmentation du trafic réseau ainsi que de l'activité du cpu qui sature presque. Je pense que ça doit être un problème de configuration de Windows et non du syno mais comme je ne sais pas trop par où chercher, peut-être que quelqu'un d'autre a déjà eu le cas... Les ordis sont sous Win 7 et le programme utilisé pour gérer les fichiers zip est 7-zip.

De retour, désolé pour le retard de ma réponse. Pour ma part, j'ai fait tous mes tests sous windows mais j'en ai profité pour faire de même sous windows et le résultat est le même. Donc le dhcp fonctionne bien, les nom de domaine indiqué directement dans le hosts du syno aussi. Par contre le nom de domaine "attribué" au dhcp ainsi que tous les "sous-domaines" qui doivent être liés aux noms d'hôte indiqués dans la partie concernant la "réservation d'adresses" ne fonctionnent pas et là je trouve pas pourquoi, tout ça doit être lié à dnsmasq qui fait mal son travail mais comme je ne trouve rien dans les logs et que j'arrive pas à mettre la mains sur le fichier de configuration...

Merci pour ta réponse, j'ai bien fait tout cela. Tous mes clients sont en attribution auto de l'ip via dhcp. Le serveur dhcp du syno a comme dns principal l'ip du syno et comme dns secondaire un dns externe. Et bien entendu je réalise mes pings depuis un post client. J'ai même fini par ajouter mon domaine "aok.lan" au fichier hosts dans l'espoir que... mais ça n'a rien changé, mamachine.domaine.tld reste inaccessible. Edit: DNS Principal = ip du syno DNS Secondaire = dns externe Nom de domaine = domaine.tld Dans l'onglet "Réservation d'adresse", j'ai tous mes posts local de référencés avec le nom qui leur est attribué et qui sera utilisé pour le dnsmasq.

Aie... j'vais faire mon chiant mais j'ai des ips attribuées qui sont en dehors de ma plage allouée au dhcp et ça fonctionne.

Bonjour, J'essaye de me servir du dnsmasq fournit pour le serveur DHCP. Dans la config du serveur DHCP, j'ai mis comme nom de domaine aok.lan et j'ai bien indiqué plusieurs ordis dans ma liste d'ips réservées avec leur nom en "local". Mais malgré ça, quand je ping aok.lan ou bien mamachine.aok.lan et bien la résolution se fait par le serveur de dns externe...

Côté serveur, voici l'erreur fournie par les logs. openvpn[10161]: read UDPv4 [EHOSTUNREACH]: No route to host (code=113) Edit: L'erreur ci-dessus semble être liée aux "leases" du dhcp, après avoir vidé cela, je n'ai plus eu cette erreur. Et pour le bug qui me déconnectait après quelques secondes d'utilisation, je ne l'ai plus mais je ne saurais pas dire exactement pourquoi. Mais ce qui a pu aider, c'est que j'ai revu le plage ip de mon réseau, je n'utilise plus le 192.168.1.X mais 192.168.88.X. Et j'ai relancé le service du VPN. C'est quelque chose qui semble faire défaut de façon général aux syno, les services ne sont que trop peu relancés et parfois certaines modifs ne sont pas prises en compte.

Bonjour, Cela fait un moment que j'espère de voir sortir un bootstrap pour ces deux nouveaux modèles de NAS (j'ai un DS213+ pour ma part). Pas de chance, avec leur processeur PPC Qoriq, y'a pas grand chose de compatible. Jusqu'à ce que je retombe sur cette page (http://forum.synology.com/wiki/index.php/Overview_on_modifying_the_Synology_Server,_bootstrap,_ipkg_etc) du wiki officiel où on indique comment installer un bootstrap et là, depuis le 30 juin 2013 une petite phrase a été ajoutée !! Alors, je n'ai pas encore eu l'occasion de tester la chose mais si c'est bel et bien compatible, ce serait une très bonne nouvelle pour nous !

Bonjour, Ca fait un petit moment que j'essaye de faire fonctionner une connexion vpn à mon syno mais j'ai un peu de mal. Mon seul et unique soucis, c'est que après quelques secondes je perds la connexion en quelque sorte, c-a-d que je ne peux plus joindre les ordis du réseau distant mais pourtant la connexion à ce réseau est toujours active. Je procède ainsi : - Ouverture de la connexion vpn au syno - Test de ping en boucle sur une adresse ip du réseau distant - Après disons 30 secondes, plus aucun paquet ne passe. Pour info, je tourne sous fedora et j'ai indiqué les paramètres recommandés par synology pour la connexion vpn au syno.

Salut, Pour info le paquet Asterisk publié par Synology est vraiment obsolète. Au début, j'espérais qu'ils allaient suivre leur paquet et le mettre à jour mais ce n'est pas vraiment le cas... Hors ce type de serveur a besoin d'être vraiment sécurisé ! Donc pour le moment, un conseil, passez votre chemin ou alors si vous avez cette chance, installez le serveur via ipkg.

Bonjour, J'étais encore satisfait de mon nas + surveillance station... bah d'accord c'était pas toujours super fluide mais ça tournait bien. Jusqu'à ce que j'aie la mauvaise idée de mettre à jour DSM + surveillance station. Depuis ça saccade énormément sur la lecture des vidéos, voir ça se fige complètement ! Pour info j'étais déjà en DSM 4.2 donc le soucis viendrait plus vite de l'appli surveillance station. J'ai vu dans un autre message qu'il était possible de revenir à une version précédente du paquet, mais y'a-t-il certaines "précautions" à prendre ? -------------- Edit: J'ai essayé d'installer l'ancienne version de Surveillance Station après avoir désinstallé la "nouvelle" et bien ça n'a pas fonctionné, le processus d'installation n'a pas cessé de tourner en boucle... Sinon j'ai résolu mon soucis... je ne cherchais pas au bon endroit, ce n'était ni la faute à DSM ni à Surveillance Station mais un switch défectueux.

Super, merci pour cette réponse rapide ! J'vais faire tourner "Sauvegarder & Restaurer" pour me faire un backup "en local" de la configuration et des applications. Et en même temps faire tourner "TimeBackup" pour avoir un backup externe avec versioning.

Bonjour, J'arrive avec un bon temps de retard sur le sujet mais j'aurais aimé avoir un petite confirmation si possible. Quand tu dis qu'il est possible de le parcourir avec un simple explorateur de fichier... explorateur propre a syno ou explorateur du système d'exploitation ? Je sais que via le système "Sauvegarder & Restaurer" classique, je peux brancher le disque dur sur une plateforme linux et accéder directement au contenu. Et j'aimerais savoir si c'est possible de faire de même avec TimeBackup. Car je suis prêt à perdre le backup de la configuration pour gagner le versioning, à condition qu'en cas de crash je puisse récupérer directement les infos manuellement sans devoir attendre l'achat d'un nouvel NAS, etc. Surtout, qu'il est possible de faire un backup de la config et des "programmes" sur un dossier partagé qui sera lui-même inclus dans TimeBackup, donc ça contourne le problème, la dernière limitation restant la possibilité d'inclure, exclure des dossiers du backup ce qui n'existe pas dans TimeBackup.

Bon, je reviens sur ce que j'ai dis... j'ai pas mal cherché pour voir si la désinstallation du paquet ne laissait pas des traces mais je n'ai rien trouvé, tout est principalement situé dans /volumeX/@appstore/Asterisk et dans /var/packages/Asterisk hors ces deux dossiers sont bien vidés lors de la suppression du paquet. J'ai passé en revue le script de démarrage, je vois rien de particulier non plus. Finalement, je pencherais plus pour un problème lié au syno. J'ai essayé aussi de désinstaller/réinstaller le paquet mais sans accéder à l'interface utilisateur, même résultat... 40 processus. Bahh maintenant que j'ai mis un peu la main à la pâte, je me rend bien compte que ce paquet est loin d'être prêt pour un système en production, dommage.

J'ai fait la même chose, après suppression j'ai vérifié que le dossier "/var/packages/Asterisk/target/etc/asterisk/" n'existait plus mais je n'ai pas creusé plus loin, après la réinstallation de asterisk j'avais de nouveau 40 processus, par contre tout comme toi j'avais la version foireuse avant, ce qui pourrait être un élément de réponse vu que sur l'autre NAS où je n'ai qu'un seul processus, je n'ai installé que la dernière version.

A propos des processus, il y a bien un soucis à ce niveau là mais ça n'impacte pas toutes les versions des NAS. J'ai indiqué ce problème dans la réponse au support ce matin. @nono: Tu veux dire que tu as installé le paquet via le centre de paquet mais que tu l'as configuré manuellement ? Tandis que nous on passe par l'interface de Digium... le sip.conf fait 70Ko et le extensions.conf 35Ko. Bien qu'il contienne plein de commentaires et autre trucs inutiles, il semble contenir aussi certaines choses importantes que tu n'as pas, lié notamment aux macros ou encore des numéros que semblent être réservés à Asterisk.

@nono: Les appels internes et sortants, pas les entrants. Pour ce qui est des fichiers sip.conf et extensions.conf, je te les mettrais bien mais ils sont super long. D'ailleurs, je ne sais pas si Asterisk se base sur les fichiers de conf situés dans "/var/packages/Asterisk/target/etc/asterisk/" mais si c'est le cas, le fichier extensions.conf par exemple semble contenir plein d'informations ne me concernant pas... Est-ce que l'un d'entre-vous pourrait regarder le nombre de processus Asterisk qui tourne, juste pour savoir si je suis le seul à en avoir 40 ou si ce problème affecte d'autres personnes. @rodo: Si désormais tu as une sonnerie, c'est déjà un bon point, de mon côté, lors de mon test hier je n'avais aucune tonalité, ça coupait directement.

Première réponse du support. Je ne leur avais pas clairement expliqué notre soucis, juste demandé si ils pensaient que le paquet était stable, ils m'ont donc demandé de préciser le soucis mais il m'ont indiqué que pour eux tout devait bien fonctionner en dehors d'une erreur sur la page "config/index.html" qui est "there is a script error in the config/index.html page. With this error, the page is not displayed." et qui sera corrigé dans la prochaine version. J'en ai profité pour leur remonter deux petits bugs que j'ai trouvé, le premier concerne la page des logs d'asterisk dans l'interface de Digium qui n'affiche rien. Et le deuxième, sur un DS710+ j'avais la première version du package et je l'ai mise à jour, sur un DS213+ j'ai directement installé la dernière version, sur le DS710+ j'ai plus de 40 process qui font tourner Asterisk et 1 seul process sur le DS213+.

Quelques infos : - J'ai envoyé ce matin un message au support pour voir ce qu'ils vont dire concernant la stabilité du paquet. - Et j'ai trouvé l'erreur sur mon Cisco (après avoir remarqué que ça passait avec une base Gigaset), j'avais forcé la connexion en TCP... Je vais donc pouvoir faire un test plus complet et voir si je bloque au même endroit que vous. - Après un petit test, j'arrive à la même erreur que vous, les appels entrants ne passent pas. Cependant j'ai remarqué que vous aviez juste ajouté une règle "s" pour les appels entrants, il faut aussi ajouter une règle "_X.", avec ces deux règles tous les appels entrants devraient passer. Et je n'ai aucune trace d'un appel entrant dans les logs, ce qui fait plus vite penser à un problème de config réseau.

Bonsoir, Pour un particulier il n'y a pas d'intérêt à utiliser un système tel que asterisk à moins d'être passionné et d'être donc prêt à "perdre" du temps là-dedans. Pour faire court, on peut dire que asterisk te permet de mettre en place un central téléphonique.