Automatically sending outbound files

[Niels Joncheere]

Hello All,

I have recently switched from using binkd in Windows 2000 to binkd (v1.0.1) in
Linux (Fedora 17). I am running binkd as an xinetd service with arguments -isq.
binkd is correctly started at boot, and correctly accepts incoming connections
and receives incoming files. However, on Windows 2000 binkd seemed to
automatically detect new files in the outbound directory, and subsequently send
them without my intervention. In my current Linux configuration, this seems
not to be the case: I have to manually start a poll in order to send the files,
whereas I would like them to be sent automatically as soon as they appear in
the outbound directory. Does anyone have any idea what I may have configured
wrong?

Kind regards,
Niels

[Andre Grueneberg]

Hi Niels

Niels Joncheere schrieb:

NJ> I have recently switched from using binkd in Windows 2000 to binkd
NJ> (v1.0.1) in Linux (Fedora 17). I am running binkd as an xinetd
NJ> service with arguments -isq. binkd is correctly started at boot,
NJ> and correctly accepts incoming connections and receives incoming
NJ> files. However, on Windows 2000 binkd seemed to automatically
NJ> detect new files in the outbound directory, and subsequently send
NJ> them without my intervention. In my current Linux configuration,
NJ> this seems not to be the case: I have to manually start a poll in
NJ> order to send the files, whereas I would like them to be sent
NJ> automatically as soon as they appear in the outbound directory.
NJ> Does anyone have any idea what I may have configured wrong?

(x)inetd only deals with incoming connections. So binkd is not started at boot,
but only upon a new connection attempt. You might want to run binkd as a
daemon.

CU Andre E-Mail: ***@grueneberg.de

[Niels Joncheere]

Hello Andre,

On Sunday November 04 2012 at 22:16, you wrote to me:

NJ>> I am running binkd as an
NJ>> xinetd service with arguments -isq. binkd is correctly started
NJ>> at boot, and correctly accepts incoming connections and receives
NJ>> incoming files. However, on Windows 2000 binkd seemed to
NJ>> automatically detect new files in the outbound directory, and
NJ>> subsequently send them without my intervention. In my current
NJ>> Linux configuration, this seems not to be the case:

AG> (x)inetd only deals with incoming connections. So binkd is not started
AG> at boot, but only upon a new connection attempt. You might want to run
AG> binkd as a daemon.

Thanks for the tip, i got it working by starting binkd as a daemon!

Kind regards,
Niels

[Benny Pedersen]

Hello Andre!

04 Nov 2012 22:16, Andre Grueneberg wrote to Niels Joncheere:

AG> (x)inetd only deals with incoming connections. So binkd is not started
AG> at boot, but only upon a new connection attempt. You might want to run
AG> binkd as a daemon.

if i did that Wilfred will ask me to get back to qico :=)


Regards Benny

... there can only be one way of life, and it works :)

[mark lewis]

NJ> I have recently switched from using binkd in Windows 2000 to binkd
NJ> (v1.0.1) in Linux (Fedora 17). I am running binkd as an xinetd
NJ> service with arguments -isq. binkd is correctly started at boot,

nope... it cannot be started at init since inetd style operations only start
services when a connection comes in requesting such... when that connection is
complete, the service is terminated...

NJ> and correctly accepts incoming connections and receives incoming
NJ> files. However, on Windows 2000 binkd seemed to automatically
NJ> detect new files in the outbound directory, and subsequently send
NJ> them without my intervention.

you are running binkd as a daemon on windows...

NJ> In my current Linux configuration, this seems not to be the case:
NJ> I have to manually start a poll in order to send the files,
NJ> whereas I would like them to be sent automatically as soon as they
NJ> appear in the outbound directory. Does anyone have any idea what I
NJ> may have configured wrong?

you have not configured anything wrongly but you do have a misunderstanding of
how it works... using inetd style operations, you do have to set up something
like a cron job to send the waiting files IF the destination system has not
connected with you to deliver and pick up those that may be waiting...

if you want immediate action, then you want to reconfigure to not use inetd
style operations and instead run binkd as a daemon or even as a program in a
dedicated task...

)\/(ark

[Benny Pedersen]

Hello Niels!

04 Nov 2012 13:12, Niels Joncheere wrote to All:

NJ> may have configured wrong?

nothing, linux only do what you ask it to do

----- pollall-qico begins -----
#!/bin/sh
#
# qico poll script :=)
# qctl is the queue manager
# qico is direct
#
#/usr/sbin/qico -b -i f38.n261.z1.binkp.net:24555 1:261/38
/usr/bin/qctl -pn 1:261/38
#
#/usr/sbin/qico -b -i f854.n292.z2.binkp.net 2:292/854
/usr/bin/qctl -pn 2:292/854
#
----- pollall-qico ends -----

----- start_feddy.sh begins -----
#!/bin/sh
cd /home/xpoint/fidopoint
./bin/fnlc
./bin/fscan
#./binkd -v -p -c -P 2:230/0 binkd.cfg
binkd -v -p -c -P 2:230/0 binkd.cfg
./bin/futilitu tool delete age+1200
./bin/futility purge
./bin/ftoss
./bin/futility link
./bin/futility rescan
./bin/fmbedit
----- start_feddy.sh ends -----

----- binkd.cfg begins -----
domain fidonet /home/xpoint/fidopoint/outbound 2
domain amiganet /home/xpoint/fidopoint/outbound 2
address 2:230/38.1
address 39:140/127.1
sysname "point 1"
location "home.junc.org"
sysop "Benny Pedersen"
nodeinfo 115200,TCP,BINKP
rescan-delay 1
log /home/xpoint/fidopoint/log/binkd.log
loglevel 3
conlog 2
pid-file /home/xpoint/fidopoint/log/binkd.pid
inbound /home/xpoint/fidopoint/inbound
inbound-nonsecure /home/xpoint/fidopoint/inbound
prescan
root-domain binkp.net
# proxy 127.0.0.1:3128
# node 2:230/0 home.tele.ipv6.junc.org password
node 2:230/0 * password
----- binkd.cfg ends -----

----- pollall begins -----
#!/bin/sh
/usr/bin/binkd -p -P 1:261/***@fidonet -P 2:292/***@fidonet
/home/xpoint/fido/config/binkd.conf /dev/null &
----- pollall ends -----

no problem for me to share my problems :)



Regards Benny

... there can only be one way of life, and it works :)