It's annoying when something other than rsyncd listens on tco/873

Paul Schmehl pschmehl_lists at tx.rr.com
Tue Aug 17 15:18:09 UTC 2010


--On Monday, August 16, 2010 20:20:31 -0400 jhell <jhell at dataix.net> wrote:

> On 08/16/2010 01:49, David Wolfskill wrote:
>> My build machine is noisy & generates heat, so I leave it powered off
>> when it's not actively in use.
>>
>> As a consequence, it gets rebooted rather often.
>>
>> It is configured to run rsyncd(8) so I can update my laptop's local mirror
>> of the FreeBSD SVN repository.
>>
>> A couple of mornings ago, I woke up, ready to start my daily builds (on
>> the laptop & build machine), but noticed that the SVN mirror on the
>> laptop hadn't been updated.  Eventually, I discovered that the reason
>> was that amd(8) [on the build machine] was listening on 873/tcp, which
>> is the port for rsync.  I restarted amd(8); it happened to get other
>> ports, so I restarted rsyncd(8), and was able to perfomr the mirroring.
>>
>> Mind, that was the first time since around February that I've had a
>> problem with using rsyncd(8) in this fashion.
>>
>> Since then, I've become a bit ... sensitized .... to the issue, so a
>> quick "sockstat -4l" immediately after powering it on helps avoid ths
>> sort of thing.
>>
>> So this evening, such a check showed that ypbind(8) was listening on
>> 873/tcp.
>>
>> The most straightforward way to make this a non-issue (it seems to me)
>> would be to start rsyncd(8) before other services that grab arbitrary
>> ports; however, the start-up script for rsyncd s[ecifies:
>>
>> # PROVIDE: rsyncd
>> # REQUIRE: LOGIN
>> # BEFORE:  securelevel
>> # KEYWORD: shutdown
>>
>> and both amd & ypbind specify
>>
>> # BEFORE:  DAEMON
>>
>> so that approach doesn't seem to quite work out.
>>
>> (I note that I recently stopped tracking stable/7 on the build machine,
>> so I now boot into stable/8; perhaps something changed between stable/7
>> and stable/8 that inicreases the probability of such an unfortunate
>> collsion.)
>>
>> Also, rsyncd(8) doesn't appear to consider this a condition worthy of
>> note -- at least, I wasn't able to find any whines, and the daemon was
>> still running.
>>
>> Anyone have suggestions for avoiding a recurrence (vs. working around
>> the coiindition should one occur)?
>>
>
> I have been at this point once or twice and it always boiled down to
> rpcbind in my situation on a few NIS+ boxen.
>
> The problem that I came across was that /usr/local/etc/rc.d is parsed
> long after /etc/rc.d contents so adding the BEFORE to the rsync start
> script would not help or didn't at that time.
>
> One thing that comes to mind is that script that Jeremy? posted for
> waiting for the network a certain period of time before initializing
> services. Maybe this could also play a role in a situation to have a
> services script that could be controlled by rc.conf(5) to wait for a
> service to come up before continuing its own operation. And of course it
> should continue no matter what in either case but would allow you to
> introduce possibly needed delays in the rc.
>
> Here is a slightly modified version of Jeremy's script that I use.
> http://bit.ly/cpbrlm
>
>

The IP_PORTRANGE value, which is used by ypbind and amd to select a port, is 
adjustable according to your needs.  man (4) ip

"IP_PORTRANGE_DEFAULT  use the default range of values, normally
                           IPPORT_HIFIRSTAUTO through IPPORT_HILASTAUTO.  This
                           is adjustable through the sysctl setting:
                           net.inet.ip.portrange.first and
                           net.inet.ip.portrange.last."

Note that the man page is incorrect for FreeBSD 8.
# uname -r
8.1-PRERELEASE

# sysctl net | grep portrange
net.inet.ip.portrange.randomtime: 45
net.inet.ip.portrange.randomcps: 10
net.inet.ip.portrange.randomized: 1
net.inet.ip.portrange.reservedlow: 0
net.inet.ip.portrange.reservedhigh: 1023
net.inet.ip.portrange.hilast: 65535
net.inet.ip.portrange.hifirst: 49152
net.inet.ip.portrange.last: 65535
net.inet.ip.portrange.first: 10000
net.inet.ip.portrange.lowlast: 600
net.inet.ip.portrange.lowfirst: 1023

So set net.inet.ip.portrange.lowlast to 874.  That should keep rsyncd's port 
from being grabbed, unless I'm misunderstanding this, in which case Matthew or 
someone else will correct me.

-- 
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
*******************************************
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson



More information about the freebsd-ports mailing list