Re: tcpsvd vs. tcpserver

On 23-Sep-04, at 9:55 AM, Gerrit Pape wrote:

Sorry for the slow response on this one... I thought I had time earlier 
to convert things but I was mistaken, but now I'm looking to get past 
this particular hurdle.

>> I'd like to mimic the tcpserver behaviour as much as possible, so I'd
>> perfer to use cdb files rather than directories, although it looks to
>> me like there isn't much difference since the directories are used to
>> build the cdb files (at least that's what I understand).  Before I 
>> dive
>
> Yes, the constant database for ipsvd is created from an instructions
> directory using ipsvd-cdb(8).

Ok, so I was right regarding that.

>> With tcpserver if I use -X, it tells tcpserver to allow everything if
>> foo.cdb doesn't exist.  Does tcpsvd (and the others) do this
>> automatically?  Or is the default to deny?  There is no -X (or 
>> similar)
>> switch in tcpsvd that I can see.
>
> If an ipsvd has trouble opening or reading the instructions directory 
> or
> cdb, it closes/drops the connection.  So if the cdb doesn't exist, the
> connection is denied; a feature similar to tcpserver's -X option isn't
> supported currently.

Ok, but looking at:

http://smarden.org/ipsvd/examples.html

I see it state for the in.telnetd example that by default all 
connections are permitted.  It's not using a cdb but the ./peers 
directory.  If I have an empty directory that ipsvd is looking at, does 
it allow all connections?  It seems to imply that.  But when I look at 
the ipsvd-instruct.5.html page I see the "catchall file 0", which seems 
to contradict what I thought the example page implied.  (I'm likely 
being lazy here as I haven't actually started on the conversion, I'm 
just doing some more reading... I plan to test this shortly with the 
cvspserver).

>> I would also suspect that using:
>>
>> tcpserver -c30 -HRXv -llocalhost -x /etc/tcprules.d/cvspserver.cdb 0
>> cvspserver /usr/sbin/cvspserver 2>&1
>>
>> is the same as:
>>
>> tcpsvd -c 30 -v -l localhost -x /etc/tcprules.d/cvspserver.cdb 0
>> cvspserver /usr/sbin/cvspserver 2>&1
>>
>> correct?
>
> Yes, except for the -X option, and that the cdbs are not compatible, 
> you
> can't use a cdb created with tcprules with ipsvd(7), you would need to
> create a new one using ipsvd-cdb(8), or use the directory directly.

I think using the directory makes more sense since the directory needs 
to exist anyways (I can see it being different for a large directory 
with a lot of rules, but I think by and large the directory method 
would be the simplest).

>> I suppose that using the directories would be simplest, but I'm trying
>> to make things as easy as possible because this is for a Linux server
>> distribution that I'm working on, so it needs to be fairly simple for
>> others to use.  Using cdb files with tcpserver was simple... one 
>> config
>> file, one cdb.  Keeps things easy.  This directory scheme doesn't seem
>> quite as straightforward.  =)
>
> ipsvd supports more instructions than tcprules, and may provide more
> instructions in the future.  Using a directory to define the per-peer
> instructions is more flexible than a single config file.  It also 
> speeds
> up access to the instructions if no cdb is used.  I think the directory
> scheme is straightforward if you're used to it, see ipsvd-instruct(5)
> for reference, and the examples[0] to get an idea.

Yeah, that's what I've been doing.  Seems to make sense well enough, 
but I'm used to (more or less) the directory-is-a-config approach since 
I use djbdns.  =)  Others, however, for whom the whole supervised 
service concept will be new may not catch on quite so quickly.

> And here are some hints on how to create an instructions directory from
> a tcpserver rules file:
>  http://article.gmane.org/gmane.comp.misc.pape.general/530
>
> [0] http://smarden.org/ipsvd/examples.html#instruct

Thanks very much for all the info, Gerrit.

-- 
Annvix - Secure Linux Server: http://annvix.org/
*Please note gpg keyid FE6F2AFD has been replaced with keyid FEE30AD4*
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}