Bonjour,
J'ai été confronté à problème avec l'attribution de ports par portmap/rpc sur un de nos serveurs RHEL5 :
Le service gérant la communication avec la baie SAN (qlremote pour ceux qui connaissent) s'est vu attribué le port 873 par rpc mais il se trouve que ce port se trouve être celui de rsyncd ...
Heureusement, il s'agit d'un serveur qui n'est pas encore en prod et les tests que nous avons à faire avec rsync peuvent attendre demain.
Je vais donc planifier un reboot du serveur cette nuit pour que qlremote soit mappé sur un autre port. Cela permettra de contourner le problème à court terme mais j'aimerais une solution plus pérenne.
Je cherche donc à réserver certains ports afin d'éviter qu'un autre soucis de ce genre se reproduise (avec rsync ou autre), surtout que ça deviendra vite plus critique une fois le serveur en prod.
En recherchant avec l'ami google je suis tombé sur des infos sur portreserve : https://fedoraproject.org/wiki/Features/Portreserve
Ca correspond exactement à ce que je cherche à faire, mais ce qui me gène c'est "Percentage of completion: 60% " indiqué dans le site.
Sachant qu'il s'agit d'un serveur critique (une fois qu'il sera en prod évidemment) je ne peut pas me permettre d'installer des programmes en plein développement.
Je vais continuer mes recherches, mais si quelqu'un a une piste pour paramétrer rpc/portmap pour l'empêcher d'utiliser certains ports précis je suis preneur.
Je ne suis pas contre des retours d'expériences concernant portreserve au passage ... ça à l'aire très prometteur...
Au passage une petite question subsidiaire : il me semblait que les ports jusqu'à 1024 étaient réservés pour éviter ce genre de pépins, pourquoi donc rpc viens me squatter le 873 ?
Forum Linux.redhat Réservation de ports RPC sur RHEL5
28
août
2008
# port quand tu nous tiens
Posté par nono14 (site web personnel) . Évalué à 1.
Le premier logiciel qui listen sur ce port gagne.
Le logiciel qui tente par la suite d'ouvrir le même port echouera.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: port quand tu nous tiens
Posté par Enoch (site web personnel) . Évalué à 1.
Le problème c'est que le démon en question (et les autres utilisant rpc comme mountd) se voit attribuer un port par rpc et donc risque à chaque reboot de la machine d'utiliser un port normalement réservé à un autre démon comme c'est arrivé avec rsync.
En changeant le port de rsyncd, le problème reste le même, le nouveau port risque également d'être occupé par un démon géré par rpc ...
>Le premier logiciel qui listen sur ce port gagne
justement, vu que rsyncd est lancé à la demande par xinetd, il se lance forcément après les démons gérés par rpc. Donc c'est toujours lui qui perd à ce petit jeu.
Pour moi la solution serait de paramétrer rpc pour exclure une plage de ports ou certains ports précis comme le permet portreserve.
Mais je recherche une façon de faire ça qui n'implique pas d'installer un paquet potentiellement instable (apparemment en version 0.0.0-6 actuellement)
Description du paquet portserv :
"The portreserve program aims to help services with well-known ports that lie in the bindresvport() range (currently 600-1023). It prevents programs requesting a port to the libc from occupying a real service's port by occupying it itself, until the real service tells it to release the port (generally in its init script). "
C'est précisément ce que je cherche à faire, mais sans utiliser portserve.
Vu le nombre de ports dispo, la probabilité que cet incident se reproduise est très faible mais ça me déplaît fortement d'avoir cette épée de damoclès au dessus de la tête ...
[^] # Re: port quand tu nous tiens
Posté par nono14 (site web personnel) . Évalué à 1.
le but de rpc/portmap est de pouvoir se connecter a un service dont
le numero de port n'est pas connu à l'avance.
c'est une solution possible.
mes 2 centimes
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: port quand tu nous tiens
Posté par Enoch (site web personnel) . Évalué à 1.
Effectivement, je commence à envisager cette solution ... mais ça voudrait dire qu'on ne peux plus utiliser xinetd sans risquer ce genre d'emmerdes, c'est quand même dommage, c'est pratique xinetd ...
> le but de rpc/portmap est de pouvoir se connecter a un service dont le numero de port n'est pas connu à l'avance.
D'accord, mais ce que je ne comprends pas bien c'est pourquoi il utilise des ports inférieurs à 1024 qui sont normalement réservés ...
Je vais continuer à chercher de mon côté et au passage me documenter sur le fonctionnement de RPC/Portmap, n'ayant que des connaissance assez superficielles dessus, ça ne me fera pas de mal ...
Il doit quand même bien exister un moyen de régler ce problème ... je ne suis pas le seul à être confronté à ce genre de "conflit", sinon un projet comme portreserve n'aurait pas de raison d'être...
# port et privilège
Posté par nono14 (site web personnel) . Évalué à 2.
les autres 1024...65535 pour les utilisateurs
Cela permet de faire tourner des services well known ( ex: apache, etc? ... )
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.