j'imagine qu'avec des noms en toto.com et en toto.biz, ce n'est pas pour un usage interne.
tu ne peux pas avoir un certificat avec juste * dans le CN (ou même *.com) pour des raisons évidentes
par contre *.toto.com est possible (sous condition que le domaine toto.com t'appartienne bien sur), et si ce certificat est signé par une CA reconnue par le navigateur tu peux utiliser celui-ci sur tous les sites en *.toto.com sans que celà mette un warning
il faut garder à l'esprit que ce ne sont pas toutes les CA qui offrent la possibilité de signer de tels certificats et qu'en général ce genre de certificats coute environ 5 fois plus cher qu'un certificat normal (j'ai Thawte en exemple en tête, y en a surement d'autres, je sais que verisign en font, mais bon c'est verisign )
dans tous les cas il te faudra faire la meme chose pour *.toto.biz
donc reste à déterminer ce que tu préfères : utiliser plus d'adresses publiques et plusieurs certificats 'normaux' ou bien deux adresses publiques et deux certificats wildcard.
Si c'est à usage interne la question ne se pose plus, tu fais ta propre CA, tu installes le certificat de la CA sur chaque navigateur (ca se fait tout seul) et voilà
En lisant la réponse au commentaire de dab, je pense que j'ai moi aussi mal compris ta question :) et c'est vrai que ca devient un peu plus compliqué la du coup.
si tu veux modifier l'enveloppe et pas les entetes ou l'inverse, je sais que la directive sender_canonical_classes te permet de définir sur quels éléments agit sender_canonical_map
de la meme maniere canonical_classes permet de définir sur quels éléments agit canonical_maps
je n'ai jamais essayé, mais je pense qu'en combinant les deux on peut arriver au résultat escompté. Un truc du genre :
tu mets dans /etc/postfix/canonical tes règles pour réecrire l'enveloppe et dans sender_canonical les règles pour réecrire l'entete et ca devrait le faire.
C'est le pure fruit d'une réflexion hein, j'ai jamais tester moi même mais ca me paraît assez logique à première vue
je lance sshd => j'ai un processus sshd processus A, celui-ci écoute sur le port 22 et attend une nouvelle connexion
je me connecte en ssh => le processus A fork et j'ai donc un processus sshd B. Ce dernier va gérer cette connexion jusqu'à ce qu'elle soit terminée
je restart sshd => le processus A est kill, mais le processus B est intouché => ma connexion n'a pas été coupée
vérifiable à coup de ps | grep ssh
donc non ce n'est pas bizarre, et c'est en fait très bien, imagine que tu te gourres dans le fichier de conf , tu redémarres le service, ta session se termine et paf plus moyen de te reconnecter sur une machine située à 500 bornes
> Les répertoire public_html des utilisateurs offrent un accès complet à tous.
donc j'imagine que par la tu sous entend que les répertoires public_html ont des permissions rwxr-xr-x
mais est ce que le répertoire de l'utilisateur en lui-meme laisse les droit d'execution pour tout le monde ?
ie mon home directory /home/sgueg
mes fichiers web /home/sgueg/public_html
si /home/sgueg a des droits en rwx------ et bien l'acces te sera refusé quelles que soit les permissions de public_html
y-a-t-il un fichier index.html (ou index.php) dans les répertoires public_html ?
si non il faut verifier que le listing soit activé (la directive Options Indexes, ou all ou +Indexes )
Autre chose a vérifier, les directives de mod_access
un truc du genre
Order allow,deny
Allow from quelquechose
verifie que le quelquechose en question soit all, pour le rendre accessible de n'importe ou (mais ca doit etre le cas par defaut il me semble)
pour celà il place une ligne du genre (de mémoire)
net.ipv4.icmp_echo_ignore_all = 1 dans /etc/sysctl.conf
donc tu as deux moyens de rendre ta machine pingable
- temporairement : echo 0 > /proc/sys/net/ipv4/icmp_ignore_all
- permanente : edite le fichier /etc/security/msec/level.local
ce fichier est utilisé pour customiser les règles qu'applique msec quel que soit le niveau de sécurité choisi.
Plus d'informations sur http://mandrake.vmlinuz.ca/bin/view/Main/MandrakeSecurity(...) par contre ca date un peu alors faudra peut etre y aller a taton et regarder ce qui se passe dans les logs Je crois qu'il requiert certaines permissions sur ce fichier aussi, enfin les messages dans les logs sont assez explicites (pour rafraichir la conf msec tu execute juste la commande msec {niveau})
par contre dans ce niveau de securite il te faudra peut etre modifier ton fichier hosts.allow pour certains service aussi (openssh me vient a l'esprit)
j'aime bien msec dommage que pour trouver de la documentation a jour c'est un peu la croix et la baniere, meme la page de man est antediluvienne
comment travailler entièrement en UTF-8 (encodage interne + output) sachant que je n'ai pas la main sur la conf PHP / Apache (Free)
Si par encodage interne + output tu as en tête les directives de configuration 'mbstring.internal_encoding' et 'mbstring.http_output', il n'est pas nécéssaire d'avoir accès à la configuration du serveur, la fonction ini_set permet de les modifier en live dans le code (bon bien sur faut que l'extension mbstring soit présente sur les serveur de free)
et bien j'ai eu le meme problème après avoir fait une installation minimale n'ayant sélectionné aucun groupe de packages, le programme d'instalaltion m'avait quand meme proposé entre une instalation avec ou sans documentation (j'ai choisi sans).
Bon bref après coup je em suis dit quand meme les pages de man c'est utile de temps en temps, un coup de urpmi man-pages et hop rien d'installer dans /usr/share/man
raison : dans /etc/rpm/macros le programme d'installation avait glissé la ligne:
%_excludedocs yes
supprimer la ligne a réglé le problème
[^] # Re: Je le sens mal.
Posté par eggus . En réponse au message Certificats SSL multi-domaines. Évalué à 1.
tu ne peux pas avoir un certificat avec juste * dans le CN (ou même *.com) pour des raisons évidentes
par contre *.toto.com est possible (sous condition que le domaine toto.com t'appartienne bien sur), et si ce certificat est signé par une CA reconnue par le navigateur tu peux utiliser celui-ci sur tous les sites en *.toto.com sans que celà mette un warning
il faut garder à l'esprit que ce ne sont pas toutes les CA qui offrent la possibilité de signer de tels certificats et qu'en général ce genre de certificats coute environ 5 fois plus cher qu'un certificat normal (j'ai Thawte en exemple en tête, y en a surement d'autres, je sais que verisign en font, mais bon c'est verisign )
dans tous les cas il te faudra faire la meme chose pour *.toto.biz
donc reste à déterminer ce que tu préfères : utiliser plus d'adresses publiques et plusieurs certificats 'normaux' ou bien deux adresses publiques et deux certificats wildcard.
Si c'est à usage interne la question ne se pose plus, tu fais ta propre CA, tu installes le certificat de la CA sur chaque navigateur (ca se fait tout seul) et voilà
# re: Deux interfaces réseaux et deux ip dans le meme network
Posté par eggus . En réponse au message Deux interfaces réseaux et deux ip dans le meme network. Évalué à 2.
pourrais tu faire un route -n sur ta machine avec les deux cartes ?
[^] # Re: re: postifx et modification de entete du mail
Posté par eggus . En réponse au message postifx et modification de entete du mail. Évalué à 1.
si tu veux modifier l'enveloppe et pas les entetes ou l'inverse, je sais que la directive sender_canonical_classes te permet de définir sur quels éléments agit sender_canonical_map
de la meme maniere canonical_classes permet de définir sur quels éléments agit canonical_maps
je n'ai jamais essayé, mais je pense qu'en combinant les deux on peut arriver au résultat escompté. Un truc du genre :
canonical_classes = envelope_sender
sender_canonical_classes = header_sender
canonical_maps = hash:/etc/postfix/canonical
sender_canonical_maps = hash:/etc/postfix/sender_canonical
tu mets dans /etc/postfix/canonical tes règles pour réecrire l'enveloppe et dans sender_canonical les règles pour réecrire l'entete et ca devrait le faire.
C'est le pure fruit d'une réflexion hein, j'ai jamais tester moi même mais ca me paraît assez logique à première vue
# re: postifx et modification de entete du mail
Posté par eggus . En réponse au message postifx et modification de entete du mail. Évalué à 3.
[^] # Re: Quelques précisions
Posté par eggus . En réponse au message pb de modification de droits. Évalué à 2.
http://www.cs.sfu.ca/CC/470/ggbaker/lab/msec(...)
# non
Posté par eggus . En réponse au message ssh bizarre?. Évalué à 4.
je me connecte en ssh => le processus A fork et j'ai donc un processus sshd B. Ce dernier va gérer cette connexion jusqu'à ce qu'elle soit terminée
je restart sshd => le processus A est kill, mais le processus B est intouché => ma connexion n'a pas été coupée
vérifiable à coup de ps | grep ssh
donc non ce n'est pas bizarre, et c'est en fait très bien, imagine que tu te gourres dans le fichier de conf , tu redémarres le service, ta session se termine et paf plus moyen de te reconnecter sur une machine située à 500 bornes
# re: Mandrake Linux et serveur web
Posté par eggus . En réponse au message Mandrake Linux et serveur web. Évalué à 3.
donc j'imagine que par la tu sous entend que les répertoires public_html ont des permissions rwxr-xr-x
mais est ce que le répertoire de l'utilisateur en lui-meme laisse les droit d'execution pour tout le monde ?
ie mon home directory /home/sgueg
mes fichiers web /home/sgueg/public_html
si /home/sgueg a des droits en rwx------ et bien l'acces te sera refusé quelles que soit les permissions de public_html
y-a-t-il un fichier index.html (ou index.php) dans les répertoires public_html ?
si non il faut verifier que le listing soit activé (la directive Options Indexes, ou all ou +Indexes )
Autre chose a vérifier, les directives de mod_access
un truc du genre
Order allow,deny
Allow from quelquechose
verifie que le quelquechose en question soit all, pour le rendre accessible de n'importe ou (mais ca doit etre le cas par defaut il me semble)
# re : Installation "plus sécurisé", mon serveur invisible sur le réseau
Posté par eggus . En réponse au message Installation "plus sécurisé", mon serveur invisible sur le réseau. Évalué à 3.
une liste des valeurs par defaut en fonction du niveau de msec disponible sur http://www.davideous.com/misc/david_harris_020723_msec_docs.html.gz(...)
ainsi que dans un fichier texte dans les docs de la distrib
pour celà il place une ligne du genre (de mémoire)
net.ipv4.icmp_echo_ignore_all = 1 dans /etc/sysctl.conf
donc tu as deux moyens de rendre ta machine pingable
- temporairement : echo 0 > /proc/sys/net/ipv4/icmp_ignore_all
- permanente : edite le fichier /etc/security/msec/level.local
ce fichier est utilisé pour customiser les règles qu'applique msec quel que soit le niveau de sécurité choisi.
Plus d'informations sur http://mandrake.vmlinuz.ca/bin/view/Main/MandrakeSecurity(...) par contre ca date un peu alors faudra peut etre y aller a taton et regarder ce qui se passe dans les logs Je crois qu'il requiert certaines permissions sur ce fichier aussi, enfin les messages dans les logs sont assez explicites (pour rafraichir la conf msec tu execute juste la commande msec {niveau})
par contre dans ce niveau de securite il te faudra peut etre modifier ton fichier hosts.allow pour certains service aussi (openssh me vient a l'esprit)
j'aime bien msec dommage que pour trouver de la documentation a jour c'est un peu la croix et la baniere, meme la page de man est antediluvienne
# re: Problème UTF-8 avec PHP 5 (espace perso free.fr)
Posté par eggus . En réponse au message Problème UTF-8 avec PHP 5 (espace perso free.fr). Évalué à 3.
Si par encodage interne + output tu as en tête les directives de configuration 'mbstring.internal_encoding' et 'mbstring.http_output', il n'est pas nécéssaire d'avoir accès à la configuration du serveur, la fonction ini_set permet de les modifier en live dans le code (bon bien sur faut que l'extension mbstring soit présente sur les serveur de free)
cf: http://fr2.php.net/manual/en/ini.php#ini.list(...)
# re: exec et rsync
Posté par eggus . En réponse au message exec et rsync. Évalué à 2.
Lorsque tu le lances en ligne de commande, le lances tu sous le meme utilisateur que le serveur web (apache ou nobody peut etre ?)
[^] # Re: variable $MANPATH
Posté par eggus . En réponse au message Installation de man imposible. Évalué à 1.
Bon bref après coup je em suis dit quand meme les pages de man c'est utile de temps en temps, un coup de urpmi man-pages et hop rien d'installer dans /usr/share/man
raison : dans /etc/rpm/macros le programme d'installation avait glissé la ligne:
%_excludedocs yes
supprimer la ligne a réglé le problème