MS_Totor

test si tu as le temps avec lm-sensors de ipkg sensors-detect ne détecte rien comme driver i2c, normal il n'est pas à jour, mais également la gestion i2c n'est pas compilé en module kernel ou du moins il manque le module core, mais i2c-dev devrais normalement causer, je bosse dessus mais si tu lances sensors, c'est un brin plus verbeux, tu auras un retour par core, et vite vu, il y a effectivement un soucis d'interprétation. comme dit dans l'autre post, je tente ce soir ou demain de compiler la dernière version de lm-sensors qui normalement détecte bien mieux les chipsets de cette génération.

pffe ca sert à quoi que j'en parle si tu me lis jamais http://www.nas-forum...__0&#entry83615 test effectué avec lm-sensors de ipkg je suis en train de compiler la toute dernière version, pour ne plus avoir de refus pour lire les infos "cachées"

bonjour, comme d'habitude, c'est à vous de faire la démarche auprès du support synology, directement sur le site de synology, (mail en anglais) en décrivant votre soucis, là et seulement là si synology a eu une solution, et que cela a un lien avec le firmware, alors vous recevrez un patch sous la forme d'un nouveau firmware dédié à votre soucis particulier. cette démarche est individuelle, pour éviter de rajouter une série de bug généralisé à tous les utilisateurs, si ce patch apporte d'autres bugs non connus ! seuls ces demandeurs reçoivent ces patchs directement du support et après utilisation , si cela est concluant, ces patchs sont diffusés de façon générale et publique à tous les modèles concernés... parfois le problème ne concerne que certains modèles et pas tous, et parfois aussi cela n'a rien à voir avec le firmware, mais aux modifications faite par l'utilisateur. donc difficile de dire quand ou comment tel ou tel bug sera corrigé en réalité, le forum n'est pas une représentation officielle des techniciens et développeurs de synology mais une entraide entre particulier/pro, utilisateurs finaux de cette marque ... ces patchs evoluent à chaque corrections, le 1150 n'est plus et le 1153 est en phase de test par exemple, mais que pour certains modèles, il s'appelle d'un autre nom pour d'autres, au final pour tout le monde il s'appellera peut etre 1160 ou 1170, après maintes corrections si cela n'est pas corrigé parfaitement en version xxxx Espérant avoir éclairé cette question souvent répétée @+

bonjour, en se renseignant un peu, on constate que le module en question est d

salut comme vous l'avez tous remarqué je suppose les derniers firmwares ont fortement diminué la température affichée du système mais qu'en est il exactement ? avez vous la possibilité de contrôler cela via une sonde laser ou infra rouge..., je pense à fredlime par exemple sur un test fait il y a quelques temps de cela. voici un petit test qui me trouble un peu sur cette valeur affichée (cette valeur est une valeur interpolée, donc on peut lui faire dire ce que l'on veut à mon sens) sur mon 1010+ deux DD en raid1 après 2 heures de fonctionnement T° affichée système 31 °, DD1 31 ° et DD2 30 ° hors voulant en savoir plus voici ce que me donne le retour d'info du chipset i8720 it8720-isa-..... temp1 (cpu) 40 ° = thermistor temp2 (DD1) 31 ° = thermal diode temp3 (DD2) 25 ° = thermal diode autre relevé en provoquant une montée de la T° du local T° affichée système 35 °, DD1 30 ° et DD2 35 ° it8720-isa-..... temp1 (cpu) 45 ° = thermistor temp2 (DD1) 35 ° = thermal diode temp3 (DD2) 29 ° = thermal diode étonnant non ? ----------------- je surveille cela pour voir si la T° relevée système n'est pas plutôt celle d'un DD... des ce soir je lance un gros transfert pour tester mais si quelqu'un veut faire un test en parallèle je suis intéresse par son retour avant de remonter l'info à qui de droit avec une petite abaque.

ok je comprends bien mieux dans mon ancienne maison, je m'étais fait un vide sanitaire prévu pour aquarium au début, puis occupé par l'informatique , quelques câbles déportés et hop un mur de salon ou apparaissait uniquement la facade du lecteur DVD, et un écran plat, clavier et souris sans fil etc... le confort de l'informatique et zéro bruit, zéro cable apparant, la vmc ventilant cette pièce cachée et fermée à clef, un filtre de hôte de cuisine sur une grille discrète ton sur ton pour l'aspiration et pas de soucis. le truc à toujours éviter c'est la hauteur, la chaleur montant c'est l'horreur assurée, également prévoir de l'espace autour, mais surtout derrière, sinon le refoulement de calories est mal réalisé et à nouveau aspiré, phénomène de boucle, et truc très utile que nous sommes nombreux à utiliser, quatre bouchons de bouteilles d'eau, pour surélever en facilitant l'aspiration et absorber les vibrations, simple et efficace...... gains facile de 5 ° comme cela

heu... pourquoi vous cherchez

yes je me disais aussi respect pour le stromotruc, qui existe toujours, renommé, amélioré etc..mais la base est la même ! heu j'ai commencé à sh avec la fine équipe et recruté car j'étais un des rares à gazer en doogfight sub vs sub à sh2 contre les ricains LOL oui un peu nostalgique de cette époque avec bzh, mobydik, benassen, phullbrick and co comme tu vois j'ai toujours un ms devant, j'ai oublié mon premier pseudo car inscrit à la première heure, mais plus par habitude de ce vieux pseudo parmi d'autres, tu as raté l'épopée des CDL "chie dans l'eau", sur il2, une énorme marade la bascule a été définitive ensuite sur subcommand, puis dangerous water, un peu d'orbiter et stealbeasts pro, simeur pur et dur, et oui n'aime pas la facilité et aujourd'hui plus rien, manque de temps et/ou d'inspiration pour le syno, la prise en main n'est pas si complexe, et demande un brin de prise en main si tu touche au cambouis via ssh. si tu as le moindre soucis n'hésite pas à poser tes questions sur le fofo, l'ambiance y est bien sympas bonne journée bien connu sous oneping également, tout une histoire ..... ping..... !

salut je crois que tu affirme des choses bien

exemple openvpn via webmin ancienne version, donc plus valide actuellement et en cour de mise à jour configuration du module exemple postfix, et sa gestion sur syno donc oui c'est puissant ! et cela demande de bien connaitre l'harchi des synos et la composition des programmes en général, pour bien pointer c'est donc parfois un peu long

bien utilis

salut rodolphe tu as re

bonjour, loin de moi l'idée de te disperser, je viens de me relire et je suis largement hs du thème abordé initialement, puisque je t'oriente petit à petit vers la solution ssh. j'arrête donc cette partie là que nous pourrons débattre section modifications logicielles, section plus dédiée à ce genre de causette. juste un petit mot pour en terminer sur le sujet, ssh c'est la solution standard justement, vu du côté client n'importe quel OS, intègre facilement l'équivalent de putty. pour le vpn, comme nous le répétons souvent, un simple petit routeur de type wrt54gl, et dd-wrt, intègre openvpn et un iptables complet, ceci pour parer aux manques de paquets integrés aux synos, ou souvent bridés pour satisfaire la lois de la performance vs le nombre de programme qui tournent, du moins c'est la politique d'intégration synology. je ne vois plus comment pusher de la résolution de noms mis à part déclarer un serveur DNS gérant le domaine local au bout du tunel.. je crois que si bind est trop lourd pour ton utilisation, le fichier host sera la seule solution vu le faible nombre de client. comme les paquets venant de la boucle vpn sont re routé par le server vpn en bout de chaine vers le segment réseau que tu as décrit plus haut , une ressource commenté dans le host et hop "le site ou les ressources situés à l'autre bout du tunel, seront accessible sans soucis" MAIS ....vérifie bien également les paramètres des services sur le syno, par defaut, les services comme web, ftp ssh etc, écoutent sur toutes les interfaces réseaux disponibles, donc aussi bien sur eth0 que sur tun0, ce qui ne convient peut être pas à tes règles de filtrages... pour ssh tu peux déclarer par exemple dans sshd_config l'ip sur la quelle tu veux écouter, par defaut si rien n'est changé c'est 0.0.0.0 donc tout quoi. perso sur le syno je gère openvpn via un module dédié sous webmin, c'est bien plus visuel et pratique .. le temps de mettre à jour une partie du site et je te filerai un lien sous peu, pour une vue d'ensemble bon je file @ ++

je n'ai pas mes archives dispo pour pusher des resolv, je regarde cela demain, time to miam pour ssh, de simples sockets sur les principaux services te permettent de faire du ftp over ssh, http over ssh https over ssh ou l'inverse, tout le trafic est encapsulé avec une gestion des bi clé avec un agent ssh, de type pagent sous windows, tu ne rentre qu'une fois le mot de passe pour un serveur, ou pour plusieurs serveurs à la fois, si les clé sont identiques. je m'en sert tous les jours pour de la gestion serveur distant, le serveur distant est fermé à tout via iptables sauf un port ssh et , le socket lie mon appel depuis mon réseau local https au serveur openssh du serveur distant puis le forwarde https/site d'administration comme un appel en boucle interne, bref vu de l'extérieur tout est blindé, alors qu'en fait il y a bien sur plusieurs sites en phase de tests sur le port 81, plusieurs ports accessibles, ftp etc... shorewall est génial pour ca, car il crée deux interfaces dans le process iptables, ce qui permet malgré une simple carte réseau, de gérer le trafic entrant/sortant comme un routeur à deux interfaces, je bosse quand j'ai le temps pour l'intégrer au syno, avec bind cela sera parfait en administration. si je veux me servir de mon serveur depuis l'extérieur pour aller ailleurs, rien de plus simple, via cette méthode, puisque c'est le syno qui transmet le paquet vers le site désiré, la requête initiale https vient bien de mon portable mais à transité en ssh jusqu'au syno, et ressort du syno en https vers le site désiré, proxy quoi...

stevanovich ne fr

bonsoir je ne dis pas que la config est mauvaise..... ! c'est une approche différente par contre n'oublie pas le trafic généré sur une simple box, le volume par client est plus élevé qu'un simple ftp, d'où ma question, quel intérêt de fournir autant d'ip dispo ? combien de client simultané est ce que tu compte avoir en fait l'encapsulation vpn selon le cryptage choisit peut poser soucis en terme de MTU, car selon le cryptage , tu peux avoir des pertes de paquets et pas mal de fragmentations et le temps de latence en traitement ralentiras le trafic..évites un truc paranoïde... je n'ai plus le tableaux MTU vs cryptage pour t'apporter des éléments sur le meilleur compromis, mais cela doit encore ce trouver sur le net, openvpn le gère très bien automatiquement normalement mais parfois pas du tout, et c'est la principale source à problème que j'ai du dépanner .... pour la question de la résolution de nom, tu peux déclarer chaque ressource à pousser au client, via dhcp option ( comme un service ) ou jouer sur les hosts perso j'ai installé bind, car j'en avais besoin également en virtualisation de serveurs, et ensuite faire un push du serveur dns syno au client, c'est lui qui gèrera ensuite la redirection vers d'autres noms de domaines externes au réseau local, soit vers ton provider free, soit vers un dns externe privé, le choix dns à pousser dépends des droits accordés aux client en fait, et via le bind tu peux accorder également qui peut faire des requêtes sur le serveur.... vaste choix de filtrage, sans parler de proxy dans toutes les installations que j'ai fait, systématiquement je jouais avec plusieurs clients, et une config directement dédié à l'admin, une aux synchros/sauvegardes, une à l'intranet. mais depuis quelques années je suis revenu petit à petit à l'encapsulation ssh par choix, et quasi presque plus rien en vpn, donc un peu rouillé

bonjour, pourquoi refaire un autre tuto pour 710+ ? et pourquoi le limitter uniquement au 710+ ? l'installation de openvpn est dorénavant accessible à tous les synos depuis nos demandes répétées au support, bref tun.ko est dispo dans le firmware, mais pas bridge.ko l'autre module kernel nécessaire pour utiliser le mode bridge au lieu du mode routé. ipkg fournit openvpn pou chaque modèle de syno, ensuite le paramétrage est commun pour tous les synos, et dépend uniquement des souhaits de l'utilisateur. la topologie du réseau virtuel et celle du réseau local, choix du mode udp (plus fluide) ou tcp. à partir du moment ou tu as pigé que en mode routé, la carte virtuelle (tun0) possède ces propres paramètres réseaux comme une deuxième carte réseau physique rajoutée, il suffit d'appliquer la même logique que pour du réseau/routage classique. le serveur openvpn agit en serveur DHCP indépendant du réseau local et gère son propre réseau , et comme tout vrais serveur DHCP, (exemple serveur DHCP windows) il peut donner lors d'une demande d'attribution d'ip dynamique, ce que l'on appelle des options supplémentaires. -ou est la passerelle -ou est le serveur DNS, et option DNS pointant vers des services, ftp, web etc......pour l'intranet -plage d'ip dynamique, plage réservée etc..... -intégration à active directory etc... etc.... En relisant ton propos, je me rends compte que cette partie est un peu confuse, d'où mon complément pour éclairer sur la façon dont est géré la chose. en faisant complètement abstraction du réseau local existant vu des clients , sur la carte tun0, le reseau doit être diffèrent de celui du réseau local (pas obligatoire, mais sans rentrer dans les détails, utile quand on ne connais pas le réseau) , et doit etre different également des réseaux les plus souvent rencontrés à l'extérieur, ciber café , adressage ip classique via xxbox très souvent en -192.168.1.0 (255.255.255.0) ou /24 -192.168.0.0 (255.255.255.0) ou /24 pourquoi ? pour éviter des conflit d'adresses IP en adressage ip dynamique, le client sur internet et dans son réseau local recevrai la même ip sur ses deux cartes réseaux (physique et virtuelle), ou le reseau local du client aurais déjà une ip exemple 192.168.0.10 déjà prise par un serveur , et via sa carte virtuelle, rencontrerai un conflit avec un autre appareil ayant la même ip dans le réseau local "distant/maison ", celui du syno ou d'un pc) bref: l'adressage ip du serveur vpn pourrais être tout ce que tu veux à partir du moment ou cet adressage n'est pas sur le même sous réseau que les reseau "locaux" distant et local selon que l'on regarde depuis le réseau ou est situé le syno, ou si on regarde depuis le réseau ou est situé le client. bref 192.168.100.0 ou 192.168.50.0 etc vont très bien et ce sont des adresses faciles à retenir... de même, pratiquant openvpn depuis 2000, il est judicieux de changer la topographie du réseau local ou est situé un serveur openvpn, et de le passer en 192.168.10.0, et là jamais de conflit et facile de tracer les paquets, et pas de souci comme quoi le routeur n'est pas accessible depuis l'exterieur à cette étape, ton client via sa carte virtuelle auras donc une ip dynamique (exemple) 192.168.100.5 et via sa carte physique exemple 192.168.1.20 il a déjà via sa carte physique une passerelle et un DNS donnés par une xxxbox , mais la carte virtuelle en 192.168.100.5 ? bien sur que non, cette carte virtuelle auras ses propres informations via l'autre serveur DHCP ( et les infos de DNS et passerelle) via le fichier client fabriqué à partir de la configuration du serveur openvpn. d'où l'importance dès le départ de comprendre comment gérer les options qui seront transmises aux clients. la doc la dessus est dispo sur le forum) option push , ce sont des options que l'on transmet au client en même temps que l'adresse ip. concernent en général -l'ip de la passerelle -l'ip du DNS.. à ce stade une fois la connexion effectuée, le client a comme dans l'exemple du dessus une ip 192.168.100.5 sur sa carte virtuelle, et ne peut voir ou pinguer que ce qu'il y a sur ce réseau, seul le syno est sur ce réseau (exemple 192.168.100.1 ) !! son firewall doit être réglé en conséquence, sinon pas de ping. pour accéder au réseau local "maison" voir le reste des pc etc... on doit donc rajouter une route, pour que les paquets transitant sur la boucle 192.168.100.0 puissent aller vers le réseau local " maison" exemple 192.168.10.0 push "route 192.168.10.0 255.255.255.0" pour que les paquets soit re dirigés il faut soit forwarder ces paquets soit passer par un proxy, activer le forward echo 1 > /proc/sys/net/ipv4/ip_forward et via iptables on redirige les flux venant de 192.168.100.0 vers le réseau local "maison" iptables -A FORWARD -i tun0 -s 192.168.100.0/24 -d 192.168.10.0/24 -j ACCEPT ou tu peux restreindre un accès unique si le client à une ip réservée et donc statique iptables -A FORWARD -i tun0 -s 192.168.100.5 -d 192.168.10.0/24 -j ACCEPT dernier truc, dans la conf du serveur, la chose très souvent oubliée !! ajoutez cette directive client-config-dir ccd puis créer dans l'arborescence de openvpn si il n'existe pas le repertoire ccd, puis créer le fichier client2 (exemple) avec comme contenu la ligne iroute 192.168.10.0 255.255.255.0 relancer le serveur. pourquoi route et iroute ? route contrôle le routage au niveau noyau du kernel vers openvpn via l'interface tun iroute gère le routage entre openvpn et le client, ici client2 on pourrait créer plusieurs clients globaux, dont seul certains peuvent voir tout l'ensemble du réseau distant "maison", y compris le routeur de la maison, les autres n'ont accès qu'au syno et ces ressources. fin de mon blabla, c'est un petit extrait du tuto général sur openvpn dédié aux synos sur mon site, avec quelques commentaires , mais le site est en travaux actuellement donc pas disponible. bonne journée @++

harrrrrg !! si milpat est en dsm-2.3 et que tes modules pour dsm-2.2 passent chez lui alors c'est ma logique qui n'est pas bonne, ou alors elle est bonne mais il y a changement selon les branches de cpu et des patch specifiques ce qui ne me simplifie pas la tâche pour trouver la bonne méthode pour chaque cpu. du coup ma réponse précédente sur l'impossibilité d'upgrader vers dsm-2.3 et conserver tes modules déjà cross-compiler est à prendre avec des pincettes te concernant mon propos était du à mon retour du support pour 1010+ et une récente discussion en MP avec dino du forum américain, une prochaine série de sources GPL doivent sortir d'ici quelques temps, peut être pour corriger uniquement des patchs pour les i686, du coup je suis dans le flou ... normalement c'est bon pour toi, mais pour t'éviter toute boulette et si tu es méfiant "un brin" , et si tu as un dd sata en stock, même de petite capacité ce que je fais en ce moment, je ne m'en sers que pour des tests, tu supprime via un pc toute partition dessus, et tu l'installe dans le syno, tu y installe dsm-2.3 et teste tes modules, si ils passent alors c'est bon, tu peux upgrader tes DD de productions , sinon tu seras bon pour un downgrade de firmware pour revenir en dsm-2.2 (je précise que je n'ai pas testé de downgrade depuis l'arrivée de dsm-2.3, mais en dsm-2.2 oui)

salut les modules kernel que tu utilises sont pour dsm2.2 ou dsm2.3 ? vu ton autre post sur ton transfert de 2.2 vers 2.3 je me pose la question, si tu avais du coup réussi à franchir le pas..... je suis en train de télécharger les divers kernels en 2.6.24.... pour faire quelques tests ce soir, la suite pendant la semaine

salut tu as eu le temps de tester les patchs pour cross-compiler cette semaine passée ? la semaine qui vient je suis un peu overbook, je ferais quelques tests le soir en rentrant

salut, et bienvenue sur le forum PS: ce pseudo me rappelle un pseudo disparu de la sc

bonjour, l'essentiel des précautions à prendre est là http://www.nas-forum...-beta-testeurs/ bien sur en enlevant les points liés à la bêta, mais en gardant à l'esprit qu'une sauvegarde avant transitions est toujours la précaution de base, y compris la neutralisation de ipkg , décrite dans ce mini tuto, le fait de neutraliser ipkg et de rebooter devrait neutraliser subversion, attention aussi à bien faire une copie de rc.local dans volume1, il suffira ensuite après upgrade de remettre ce fichier et de rebooter pour retrouver ipkg et subversion opérationnels si bien sur les fichier de subversions n'ont pas été installé ailleurs que dans /opt, sinon ,il y a de fortes chances pour qu'ils soient ecrasés il n'y a pas également de transitions intermédiaires entre versions de firmware tu peux passer à la dernière disponible. @++

bonjour je plussois les dire de mes comp

j'ai édité entre temps, penses bien au fichier host "au cas ou " pour faciliter la résolution de nom 127.0.0.1 localhost ..... 127.0.0.1 site1.fr 127.0.0.1 site2.fr puis reboot du syno rajoute le chemin complet vers ton index.php dans open_basedir de php.ini open_basedir = /usr/syno/synoman:/etc:/var/run:/var/services/web/site1.fr:/var/services/web/site2.fr:/..... tu peux vérifier le chemin d'accès j'ai ce petit truc qui me permet de vérifier mes chemins, pioché sur un tuto tu place un fichier rootpath.php contenant le code suivant dans une de tes vh et tu l'appele comme pour info.php <html> <head> <title>Root Path</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <body bgcolor="#e2f5f9" text="#000000"> <?php echo "<b>The Root Path is : '".str_replace('\\','/',getcwd())."'</b>"; ?> </body> </html>

en partant du principe que tes sites sont gérés via /usr/syno/apache/conf/httpd.conf-user puis via virtualhost tu geres tes vh comment, par nom de domaines différents , par numéro de port ou par nom simple. les lignes pointant vers tes virtualhost sont correctes ? si par nom de domaine, ton fichier host est renseigné ? # Virtual hosts Include conf/extra/httpd-vhosts.conf sinon tu peux activer les logs apache pour en savoir plus en changeant le niveau de log et le repertoire de log pour eviter de remplir la partition systeme #ErrorLog /var/log/httpd-error-user.log ErrorLog /opt/var/log/httpd-error-user.log LogLevel debug #ErrorLog /dev/null et # CustomLog /opt/var/log/httpd-access-user.log combined LogLevel debug #CustomLog /dev/null combined tu peux aussi voir la doc sur les vh, et mettre un log par virtualhost, tu verras de suite pourquoi tu es redirigé automatiquement , à voir normalement soit dans les vh, soit un htacces, ou un index.php mal paramétrés