On Sunday 01 October 2017 03:34:19 to...@tuxteam.de wrote: > On Sun, Oct 01, 2017 at 01:28:39AM -0400, Gene Heskett wrote: > > [...] > > > > > Assuring that my port is not in this IANA list is not enough to > > > > ensure that my port number will not clash with a port number > > > > used by a Debian package (by default). > > > > > > > > So your answer to my question is wrong. > > > > In which case debian should publish the unlisted ports they do use, > > if for no other reason than to "stake a claim". > > "Debian" "should". Gene, you "should" know better ;-) > > Want to start with it? Write a script which scans the /etc files in > all Debian packages for network configurations. > That might be possible IF you wanted to use a tool like grep, but in 30 years I've not found a way to silence the "binary file matches" messages from grep. That apparently un-muffle-able noise without chaining two or more invocations of grep makes it worthless for 95% of the searches I might do. The best I can do finds 460 instances of " port " in my own /etc tree, but from looking at that output, less than 100 actually assign a number, most use the output of some other function to assign the port.
So opening up every deb in /var/cache/apt/archives to search thru each ones /etc files might take this machine a week or more, and you would still have less than 25% of the numerical values. One things for sure, it would take a more imaginative approach than mine because so much of it appears to be dynamic assignments. One would have to emulate how each goes about it, and then its only valid for that machine at that box of time, however long it took. However, since it seems so much of that is dynamic, one could possibly use the dynamic method to find a currently unused server port when the client requests a connection, and the client can check the number assigned against its own list of ports, and accept or reject, wash rinse repeat until one is usable by both. Correctly done, I see at least 20,000 possibilities in the /etc/services list. The OP just needs to find a coder who can write such a critter. Sometimes necessity IS the mother of invention. If I am reading between the lines with sufficient clairvoyance, he wants another level of isolation to prevent data cross leakage between clients while all the traffic is on one switch per floor or some such a cable build. > What else have folks forgotten here? > > - dynamic port assignments (X, rpc/portmapper: the last is known for > having conflicted with CUPS in some distant past). > > - semi-dynamic things (e.g. Debian's way to migrate PostgreSQL) > > Unfortunately, there's no "perfect" solution for the OP's problem > (among other things because there are other people having the same > problem and solving it the same way). > > My advice: start with /etc/services. Find a suitable "hole", far away > from others (note that typical "dynamic" or "semi-dynamic" assignments > tend to cluster around canonical values, e.g. PostgreSQL: 5432, 5433, > 5434...). Plan for collissions (this might be something as complicated > as re-trying ports until success plus some "registry" to look up where > things ended or something as simple as "notify the sysadmin", lest she > spends a night debugging the bugger). > > Cheers > -- tomás Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>