TrV

A priori ce sont les directives php_value qui ne sont pas supportées. Si je les enlève (et que je garde les Add..) ça remarche. Encore un nouveau réglage de cette version de php ?

Arrghh, ca y est j'ai "trouvé", c'est mon .htaccess... Si je le supprime c'est ok. Pourtant celui-ci ne contient aucun filtre utilisateur: AddDefaultCharset UTF-8 AddCharset UTF-8 .html php_value file_uploads 1 php_value upload_max_filesize 16M php_value post_max_size 16M ça me laisse dubitatif... Bon du coup je dois mettre quoi dedans pour que apache veuille bien me lire le index.php ?

Oui c'est bien ça : <mon syno> = son adresse IP sur le réseau local / son nom sur le réseau local. Et oui ça devrait, d'ailleurs ça marche pour certains (toto) et pour d'autres (machin). C'est ça que je ne comprends pas... "machin" existait déjà avant le passage sous DSv5, et http://<ip de mon syno>/machin/ m'affichait bien la page. Donc ce n'est même pas un problème de droits potentiels... c'est incompréhensible !

Bonjour, Je suis passé récemment sur la v5 du diskstation... Depuis j'ai un souci pour accéder à certains de mes sites sur le réseau local. Imaginons que mon domaine est trv.net. J'ai 2 hôtes virtuels paramétrés : - toto -> toto.trv.net - machin -> machin.machin.net toto est bien paramétré chez mon registrar, et tout marche impeccable: http://toto.trv.netà partir de l'extérieur OK http://<mon syno>/toto/ en réseau local OK machin n'est pas paramétré chez mon registrar (nul besoin c'est du pur dev que j'hébergerai ailleurs) http://machin.trv.netà partir de l'extérieur NoK (mais ça n'est normal) http://<mon syno>/machin/ en réseau local NoK et ça ça marchait en DSv4 Alors quelqu'un peut-il m'aider sur ce dernier point svp ? C'est vraiment très handicapant car ça rend inaccessible ma plateforme de dev... Merci d'avance pour votre aide.

RAhhh, damned, après avoir testé du boulot où ça marchait (???? ) et être revenu chez moi où de nouveau ça ne marchait plus (???? ), j'ai tout d'un coup eu une idée "lumineuse" : mon pare-feu faisait des siennes (ouais, super rapide à la comprenette le type). Fou*$£ù§/?@*µ avast de ù#@ç?$^%... Nb: il faut dire que comme mon routeur (nda: 9box) ne fait pas de NAT-loopback, je suis obligé de changer le serveur de mail dans les paramètres de compte de TB si jamais je suis chez moi (serveur = nom_nas_local / IP_locale) où à l'extérieur (serveur = nom_dns / IP_publique). Du coup, mais ça n'a rien à voir, j'ai eu une nouvelle idée d'amélioration de mon addon pour TB dédié à la récupération d'email : permettre de gérer des profils de serveurs pour les différents comptes mails (si ça intéresse qqun : https://addons.mozilla.org/fr/thunderbird/addon/get-selected-mails/). Merci à ceux qui m'ont lu

Bon, j'ai finalement réussi à récupérer le répertoire /usr/syno/mailstation/ et son contenu en utilisant l'astuce de réinstall du firmware décrite ici : http://forum.synology.com/wiki/index.php/How_to_reinstall_current_or_previous_firmware J'avais bien essayé de réinstaller le firmware mais il me bloquait car je voulais réinstaller la même version. Avec cette astuce c'est bon. Je vais donc me refaire toute ma config, et retester mes pbs de mail...

Bonjour, Mon mailstation fonctionnait bien jusqu'à aujourd'hui. Configuration SMTP / PO3 / IMAP4. Après avoir passé quasiment toute la journée à essayer de faire fonctionner avec SSL, j'ai abdiqué, malgré qqes tutaux, impossible de faire fonctionner quoi que ce soit; même après avoir lu et relu, vérifié et re-vérifié, etc. (bon, bref, c'est pas le problème), du coup j'ai boulu revenir en hier. Sauf que mon client mail (TB pour ne pas le nommer) était alors incapable de récupérer les mails alors que ça marchait impeccable la veille. Donc je désinstalle le MailStation, et je vire tous les fichiers de config et répertoires, dont /usr/syno/mailstation/. Je reboote, je réinstalle le MailStation, et là !miracle -si on peut dire- plus de répertoire MailStation. Ce damné répertoire ne s'installe pas avec MailStation (c'est con vu le nom). Donc je fais comment maintenant ? Qqun peut-il m'aider, parce que bon les mails c'est juste légèrement vital pour moi. C'est ma seule messagerie sur le syno. Merci par avance.

Oui ta remarque est très juste, et mes amis ne savent d'ailleurs pas qu'ils ont une boîte mail chez moi... en fait la volonté tacite est liée à la sécurité. J'ai sciemment choisi de mots de passe assez simples à se souvenir (mes parents ne retiendraient jamais "JghE4UY3Rc"...). Si pour du FTP ça n'est pas trop gênant (je connais mes amis, et savent ce qui les intéressent ou pas, donc ce qu'ils peuvent être amenés à télécharger). Dans le cas du mail c'est différent, si l'un des mots de passe se fait cracker, bonjour la porte ouverte aux spammeurs !! Pas envie de me faire blacklister. Tu dis peux qu'on peut "les bloquer" ? Peux-tu m'en dire plus stp ? Oui et non, j'ai tjs séparé mes différentes adresses email en en faisant des comptes différents. Ca permet de mieux organiser ses mails de manière automatique. Enfin, le propos n'était pas vraiment là, mais pour montrer la non-corrélation automatique "compte ftp" <-> "compte mail". Après, du bon choix de cette pratique, à chacun son avis . D'accord, merci de cette précision qui m'apporte déjà un début de réponse. Pour les autres applications (FTP, XXX station, etc.), sais-tu si le principe est identique ? Je pense envoyer un mail à Syno pour voir ce qu'ils en pensent. Après tout, on peut peut-être espérer qu'ils incluent prochainement le mail station en natif avec les autres xxx station.

Pourquoi ? Pour exactement les m

Je faisais r

Pour préciser, dans le cas de l'utilisation des hôtes virtuels (utilisation des sous-domaines) : - Si vous suivez la méthode décrite par Synology (missing.html), placer 1 fichier missing.html dans chacun des répertoires des hôtes virtuels (/volume1/web/vhost1/, /volume1/web/vhost2/, etc.). - Si vous suivez la méthode décrite dans ce thread par Thorfin89 (404.html), laisser le fichier .htaccess à la racine du serveur web du syno (/volume1/web/) et placer 1 fichier 404.html dans chacun des répertoires des hôtes virtuels (/volume1/web/vhost1/, /volume1/web/vhost2/, etc.). Nb : Avec cette dernière méthode, vous pouvez appeler le fichier comme bon vous semble tant que c'est cohérent entre .htaccess et le fichier présent dans chacun des répertoires des hôtes virtuels. Vous pouvez même utiliser des fichiers contenant du code PHP si vous l'avez activé.

Oui, exact, j'ai zappé la mise à jour des alias... je l'inclus dans le topic originel. Pour tout le reste, je ne connais pas... mais libre à d'autres de venir étoffer Quant à ce que "je cherche à faire", c'était une question déguisée... en gros, si qqun sait, je suis preneur

Ce tutorial a pour but de centraliser les descriptions et procédures pour un paramétage avancé de Mail Station. On considère comme acquis et fonctionnel la configuration suivante : - Mail Station installé - Mail Station configuré - Nom de domaine configuré pour renvoyer sur l'IP publique de votre routeur - Ports nécessaires (typiquement SMTP: 25, POP3: 110, IMAP: 147) ouverts dans le firewall du routeur et re-dirigés vers l'IP privée du NAS Concernant l'installation et toute la configuration de l'environnement de Mail Station, vous pouvez vous rapporter aux 2 tutoriaux assez complets de Stevanovich: http://www.nas-forum...topic=7821&st=0 ET http://www.nas-forum...showtopic=7913. Informations globales: - chemin par défaut de Mail Station, noté <mailstation> : /usr/syno/mailstation/ - chemin par défaut des logs, noté <log> : /var/log/ 1) Configuration du serveur relai Ce paramètre permet de spécifier un serveur relai pour délivrer un courrier envoyé depuis Mail Station. Utiliser un serveur relai permet de: - contourner le blocage des FAI (blocage instauré afin de limiter le spam sauvage) - s'assurer que son courrier ne soit pas considéré comme un spam par d'autres serveurs relai) Généralement, le serveur relai utilisé est donc le serveur SMTP de son FAI. Si vous cherchez à utiliser le serveur relai d'un autre FAI, les mails envoyés seront très vraisemblablement refoulés. Fichier <mailstation>/etc/main.cf L#315 : Rajouter la ligne suivante : relayhost = nom_dns_serveur_relai:port Nb : Vous pouvez aussi bien indiquer un nom_dns ou une adresse_ip. 2) Configuration d'alias de nom de domaine Un alias est nom différent qui pointe sur le même ordinateur. Ex.: votre domaine principal est "mondomaine.fr" et vous avez également loué "mondomaine.com". Hors, la configuration de base de Mail Station ne vous permet pas de spécifier des alias. Il est facile de pallier ça en allant modifier la configuration de postfix. Fichier <mailstation>/etc/main.cf L#164 : Modifier la ligne mydestination = $myhostname en mydestination = $myhostname mondomaine.com Nb: $myhostname correspond au nom de domaine principal configuré dans l'interface de configuration de Mail Station dans le Panneau de configuration 3) Configuration d'alias d'utilisateurs Les utilisateurs de base pris en charge par Mail Station sont les mêmes que ceux définis pour accéder aux dossiers partagés et applications partagées. Autrement dit, tous les utilisateurs définis dans Panneau de configuration > Utilisateurs bénéficient automatiquement d'un compte mail (et d'un accès en webmail s'il est activé). Le login et le mot de passe d'accès mail sont les mêmes que ceux définis pour accéder aux dossiers. Pour définir un alias à un utilisateur mail, c'est-à-dire avoir plusieurs adresses dont le courrier sera distribué dans une seule et unique boîte mail, il faut définir les alias. Ex.: les mails adressé à prenom.nom@mondomaine.fr doivent être déposés dans la boîte p.nom@mondomaine.fr. Fichier <mailstation>/etc/aliases L#28 : Ajouter les définitions d'alias à la suite de la ligne "# Put your local aliases here." # Put your local aliases here. alias1: nom_utilisateur alias2: nom_utilisateur Une fois ceci fait, ne pas oublier d'activer les modifications avec la commande : /usr/syno/mailstation/bin/newaliases 4) Configuration des logs du webmail Fichier <mailstation>/etc/main.cf L#64 : Modifier la ligne #log_path = en log_path = /var/log/webmail.log Nb: Vous pouvez bien entendu utiliser un autre nom que webmail.log et un autre chemin que /var/log/ ----- A venir (puisque je cherche actuellement comment faire ça)...: 5) Configuration des logs de postfix En cas de problème, il est possible d'avoir quelques infos en allant farfouiller dans le spooler de postfix (dans /var/spool/postfix/ et notamment le répertoire defer/). 6) Spécifier les utilisateurs autorisés à utiliser le service mail Si vous avez des questions, ou des informations complémentaires, ou des choses à corriger...

Je vois qu'on parle de addns sur ce thread. Pour info, j'ai fais 1 modification (assez minime) du script Perl addns.pl car celui-ci manquait de souplesse. Notamment, il ne me permettait pas de récupérer l'IP à partir d'une page HTML de la config de ma 9box, car le script original ne gérait pas bien les sauts de ligne et les tags html dans la recherche de la chaîne précédent l'adresse IP (paramètre ip_detect_look). Il suffit donc d'ouvrir le fichier "addns.pl" avec vi (ou autre) et de modifier la ligne 674 : if($out =~ m/($host_v{$curr_host}{'ip_detect_look'})[ \t](\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})[<\s\n]/) en if($out =~ m/($host_v{$curr_host}{'ip_detect_look'})[\s]*(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})[<\s]/) Explication sur les modifications: [ \t] --> [\s]* : classe de caractères "espace ou tabulation" 1 et 1 seule fois --> classe de caractères "n'importe quel espace (<espace>, \t, \v, \r ou \n)" 0 ou plusieurs fois [<\s\n] --> [<\s] : classe de caractères "< (ouverture de tag html), n'importe quel espace ou newline" 1 et 1 seule fois --> classe de caractères "< ou n'importe quel espace" 1 et 1 seule fois (nb: en effet, le \n est déjà inclus dans le \s). Pour info, vous pouvez inclure des regex dans le "ip_detect_look", ce qui est une bonne chose !. Cas pratique : IP affichée dans l'en-tête de toute page de configuration de la 9box/SFRbox. Le code source HTML est le suivant: <tr> <th>Adresse IP&nbsp;</th> <td>: 86.68.208.218</td> </tr> (Noter les 2 espaces avant chacune des lignes !) Avec la modification de addns.pl détaillée ci-dessus, une valeur de ip_detect_look "matchant" ce bout de code est : ip_detect_look = "Adresse IP&nbsp;</th>[\s]*<td>:" Addns.pl peut aussi être utilisé avec OVH.com (yippe pour moi!). Exemple avec le contenu actuel et fonctionnel de mon addns.conf : [ovh] { update_host = "mondns.com" detect_method = "router" ip_detect_host = "192.168.1.1" ip_detect_port = ip_detect_look = "Adresse IP&nbsp;</th>[\s]*<td>:" ip_detect_url = "/" system_type = "dyndns" server_host = "www.ovh.com" username = "ovh_username" password = "ovh_password" } [dyndns] { update_host = "mondns.homeip.net" detect_method = "router" ip_detect_host = "192.168.1.1" ip_detect_port = ip_detect_look = "Adresse IP&nbsp;</th>[\s]*<td>:" ip_detect_url = "/" system_type = "dyndns" #server_host = "members.dyndns.org" username = "dyndns_username" password = "dyndns_password" } nb: 192.168.1.1 est l'IP privée de ma 9box.

Salut, Perso, j'ai un nom de domaine chez OVH, qui sont parmi les seuls registrar pros et fiables à proposer un champ A principal dynamique (6€ HT pour un .com ou .net). Sinon, Gandi est très sérieux aussi (il y a en d'autres bien sûr, mais je connais bien ces 2-là). Au tout début, j'avais opté pour 1&1 (n'y connaissant pas grand-chose) sur un .fr... à l'époque où l'ouverture des .fr n'était pas possible pour les particuliers. Du coup, dans un whois c'était pas mes infos persos, mais celles de 1&1 qui étaient mentionnées. Qui plus est, j'ai trouvé que l'interface de gestion était pas pratique, les possibilités très limitées, etc. Je me souviens pas de tout, mais globalement, j'avais très très vite lâché l'affaire car cela ne me semblait pas très pro. Conseil, si tu veux prendre un .fr, ou un .net, ou tout autre qui n'est pas un .com, prend aussi le .com !! Sinon, très vite il sera acheté par une boîte qui espérera ainsi faire de la spéculation pour le jour où tu voudras (peut-être) avoir le .com et qu'il te faudra alors négocier avec la boîte en question. Concernant le nom, là c'est très perso. J'ai choisi le mien sur des critères personnels, modifiés pour une raison de consonnance, modifiés par un besoin graphique... Ca t'aide pas bcp, mais à l'heure actuelle, entre la quantité de noms déjà pris, et les trucs qui ne représentent pas ce pourquoi tu veux un nom de domaine... Pour info, j'en ai précédemment déjà eu un, et entre l'évolution de mes besoins, ainsi que le recul -qqes années après- sur la difficulté des gens à s'en souvenir, j'ai décidé de changer. Cricx t'a sinon déjà donné pas mal d'infos. Avis perso, je suis pas très fan du "www" partout. Pour info, certains sites pourtant très pros ne redirigent même pas le "nomdomaine.tld" vers "www.nomdomaine.tld", ce qui fait que "nomdomaine.tld" ne mène à rien. Alors finalement, si tu gères des sous-domaines, autant l'annoncé clairement. Qui plus, si tu as un vrai www, cela risque d'amener la confusion avec les autres sous-domaines (oui parce qu'en fait www est déjà un sous-domaine). Dernier point, si jamais tu gères des hôtes virtuels avec un nom de domaine de type freens (no-ip ou autre), à ce moment-là, tu te retrouveras avec 4 niveaux dans l'url: hotevirtuel.tonsousdomaine.freedn.tld Sinon, en ce qui concerne les dns gratuits, j'utilise dyndns.org depuis plus de 8 ans maintenant, et en 8 ans, je n'ai pas eu 1 seule interruption de service... en revanche, en 5 ans d'utilisation, j'ai eu 1 période à pbs chez OVH pour la mise à jour du champ A dynamique à distance (lors de la migration de version de leur système de gestion). Bon c'était très ennuyeux à ce moment-là, mais au-delà de ça, ça fonctionne très bien aussi.