Florian Weimer <[EMAIL PROTECTED]> - Sun, Oct 10, 2004:
> > While I see the benefit of your suggestion, for packet filters, I don't
> > see how that would help average people experiencing the problem? Would
> > you require the admin to configure each port for each RPC service as it
> > is ins
* Loïc Minier:
> Florian Weimer <[EMAIL PROTECTED]> - Thu, Oct 07, 2004:
>
>> I think the best option would be to allow the system administrator to
>> statically allocate the ports used by RPC programs. This would help
>> packet filters, too.
>
> While I see the benefit of your suggestion, for p
Mark Brown <[EMAIL PROTECTED]> - Sat, Oct 09, 2004:
> I don't think it's really sensible to have each and every package
> provide this warning. If we want to trigger this on package install
> it'd be better to arrange for a single warning rather than having a new
> one pop up for each package.
On Sat, Oct 09, 2004 at 04:18:36PM +0200, Loïc Minier wrote:
> Conclusion, I am going to file bug reports of wishlist priority for the
> above packages, linking to this thread and suggesting a notice /
> warning that RPC port are not fixed and could collide with services
> that are installed o
Loïc Minier <[EMAIL PROTECTED]> - Thu, Oct 07, 2004:
> Ok, and a warning on all RPC programs not using a static port number?
> The only one I use right now is nfs-common, and I see following
> packages depending on portmap:
> rwalld am-utils nfs-common bootparamd nfs-user-server drac nis
>
Mark Brown <[EMAIL PROTECTED]> - Thu, Oct 07, 2004:
> > This could be documented in a note with low priority when one installs
> > portmap for example? I'd like admins to have a chance to read they
> > can expect port usage collisions.
> Not all ONCRPC programs have this problem: it's perfectl
On Thu, Oct 07, 2004 at 02:08:18PM +0200, Loïc Minier wrote:
> This could be documented in a note with low priority when one installs
> portmap for example? I'd like admins to have a chance to read they
> can expect port usage collisions.
Not all ONCRPC programs have this problem: it's perfec
Andrew Suffield <[EMAIL PROTECTED]> - Thu, Oct 07, 2004:
> Yes, sunrpc sucks. It's wanton consumption of address space is just
> one of many ways in which it makes the life of a sysadmin miserable.
> The proper approach would have been for sunrpc to carve out a few
> ports exclusively for its own
On Thu, Oct 07, 2004 at 01:31:24AM +0200, Lo?c Minier wrote:
> This causes random errors -- like on my system -- when a RPC service is
> already listening and you install a program which should listen on a
> standard port.
> I see no obvious solution to this:
> - you can't know in advance whi
Florian Weimer <[EMAIL PROTECTED]> - Thu, Oct 07, 2004:
> I think the best option would be to allow the system administrator to
> statically allocate the ports used by RPC programs. This would help
> packet filters, too.
While I see the benefit of your suggestion, for packet filters, I don't
s
* Loïc Minier:
> The best option would be for RPC services to ue a "port pool", not
> overlapping standard ports, but this might be impossible.
I think the best option would be to allow the system administrator to
statically allocate the ports used by RPC programs. This would help
packet filte
Hi,
Today, cupsys failed to start after its installation because a RPC
service (rpc.statd) was already listening on TCP port 631.
I wondered how portmap assigned such a port, and looked it up in glibc.
portmap uses svctcp_create to create such a socket. svctcp_create
calls bindresvport
12 matches
Mail list logo
