> > What is currently the expert way to avoid/handle such port conflicts
> > in Debian?
>
> /etc/bindresvport.blacklist
Thanks for the hint, this is what I was looking for.
So the world has moved since 2005, at list a bit.
873 (rsync) is not listed in this file.
- Is this a "bug" in libc6?
- ...
Hi,
what is the collected wisdom nowadays on how to avoid random port
conflicts when booting?
In 2005 I wrote:
"On boot some daemons (like nis/ypbind) obtain priviledged ports
via portmap/bindresvport(). Portmap assigns ports that are not in use
at the time of request, usually above 600. This str
> First, there is no safe way to revoke privileges from a user. If a user
> gets access to a certain group he/she can arrange ways to keep it,
> even after being logged out (make a suid binary for example).
I admit that I don't know much about the internals of Unix/Linux.
So, if upon login of us
> > Having to add users to particular groups is not reasonable in a
> > desktop setting. There, one would like to have the current user
> > at the console (logged in via gdm or similar) to be the one with
> > exclusive rights on local devices (fixed ones like audio and video
> > as well as variable
Dear DDs & D-friends,
what is the standard/canonical way of handling device permissions
in Debian ("etch" in my case) on desktop PCs running a GUI?
It seems that users have to be added to group "audio"
in order to be able to access audio devices, group "video" to access
video devices, "cdrom" to
Package: wnpp
Severity: wishlist
Owner: Gernot Salzer <[EMAIL PROTECTED]>
* Package name: xpbiff
Version : 1.27-11
Upstream Author : Kazuhiko Shutoh, [EMAIL PROTECTED]
* URL : http://www.logic.at/staff/salzer/xpbiff
* License : Debian compatible
Progr
> This was already brought up to debian-devel. This thread has more
> solutions, but addresses less problems: what if the service is to be
> started when the package is installed but a RPC programs already
> listens there? The solution of shipping port reservations or of init
> dependencies
> FWIW, this bug has only been reported once (and reassigned to portmap)
> see #261484
No. See also
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306465
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257876
In each thread several people report of similar problems.
> so its seems Debian user
> why not request a fixed port for ypbind?
It is not ypbind that is broken but the service that hands out
the port numbers and that is called by ypbind (and by other
services). It just happens that most clashes occur in connection
with ypbind, due to its prominence and its place in the init sequen
On boot some daemons (like nis/ypbind) obtain priviledged ports
via portmap/bindresvport(). Portmap assigns ports that are not in use
at the time of request, usually above 600. This strategy sometimes
conflicts with daemons that rely on fixed ports and that
start after ypbind (like cups, slapd): t
10 matches
Mail list logo
