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...