When I started using binkd one of the first things that did strike me
as odd (and akward), is that it has no default for the config file.
Binkd was the first application (and so far the only) on my system
that requires the config file to always be specified explicitly in the command line.
Every other application I have ever used and that can use more than
one config file has a default. Except binkd...
the only times i've used binkd.cfg for my config file name was on
systems that are/were 8.3 limited... on (my) *nix systems, the
preferred extension is .conf or .config which should be compatible
with today's winwhatever systems... i'm not sure how i feel about
having a default configuration file name... wouldn't it be easier to
write yourself a script that you feed the address to??
If writing small scripts and using long file names is your preferrerd method of doing things, than by all means use that method. My request
for a default binkd.cfg does not stop you from doing things your way
does it?
I found it odd too. In linux most applications with a config file
asume it is in some default location unless otherwise specified.
Then make one binkd.bat make sure it is found before the before the binkd.exe and put all your default whishes in that batchfile, and
allow the defaults to be overwritten by comand line parameters. Your choise is to contaminate the main source with your default whishes and that is o.k. because you donot see it.
I found it odd too. In linux most applications with a config file
asume it is in some default location unless otherwise specified.
how new to *nix systems are we??
I agree, default path for config file and option for override it is
common practice. I'll merge pull-request with this feature (and with backward compatibility) if anybody make it.
In my PoV, on unix binkd should look for binkd.conf in sysconfdir set by configure (/usr/local/etc by default), then ~/binkd.conf.
Not sure about win32. May be current directory is reasonable choice.
I agree, default path for config file and option for override it
is common practice. I'll merge pull-request with this feature
(and with backward compatibility) if anybody make it.
In my PoV, on unix binkd should look for binkd.conf in sysconfdir
set by configure (/usr/local/etc by default), then ~/binkd.conf.
Not sure about win32. May be current directory is reasonable
choice.
Besides the current dir, probably: CSIDL_COMMON_APPDATA\Fido\binkd\ is
a good place.
Besides the current dir, probably: CSIDL_COMMON_APPDATA\Fido\binkd\
is a good place.
What is CSIDL_COMMON_APPDATA?
I agree, default path for config file and option for override it is
common practice.
In my PoV, on unix binkd should look for binkd.conf in sysconfdir set
by configure (/usr/local/etc by default), then ~/binkd.conf.
Not sure about win32. May be current directory is reasonable choice.
Not sure about win32. May be current directory is reasonable
choice.
Besides the current dir, probably: CSIDL_COMMON_APPDATA\Fido\binkd\ is
a good place.
Besides the current dir, probably: CSIDL_COMMON_APPDATA\Fido\binkd\
is a good place.
What is CSIDL_COMMON_APPDATA?
Should I explain how google works? ;)
Not sure about win32. May be current directory is reasonable choice.
Besides the current dir, probably: CSIDL_COMMON_APPDATA\Fido\binkd\
is a good place.
Besides the current dir, probably: CSIDL_COMMON_APPDATA\Fido\binkd\
is a good place.
What is CSIDL_COMMON_APPDATA?
Should I explain how google works? ;)
What is google? I cannot find a reference in the FTSC documents.
Besides the current dir, probably:
CSIDL_COMMON_APPDATA\Fido\binkd\ is a good place.
What is CSIDL_COMMON_APPDATA?
Should I explain how google works? ;)
CSIDL_COMMON_APPDATA is a constant you feed to the windows api
function SHGetFolderPath()
Not sure about win32. May be current directory is reasonable choice.
Not sure about win32. May be current directory is reasonable
choice.
Absolutely! Current as in the directory where your EXE-file is
located.
Sorry, but I cannot agree. It is not good to have configuration files
and executables in one directory. Microsoft used that bad practise in Windows 9x, but later they abandoned it.
Absolutely! Current as in the directory where your EXE-file is
located.
Sorry, but I cannot agree. It is not good to have configuration files
and executables in one directory. Microsoft used that bad practise in Windows 9x, but later they abandoned it.
I see you prefer answering with a question. Why do you think ANYTHING\Fido\binkd\ is a good place? Only because you use it? I have
no such a directory in my fidonet box.
CSIDL_COMMON_APPDATA is a constant you feed to the windows api
function SHGetFolderPath()
IMHO it is not a good idea to use a Windows API function in a multi-platform project.
I have no problem with the current way; no default.
Sorry, but I cannot agree. It is not good to have configuration
files and executables in one directory. Microsoft used that bad
practise in Windows 9x, but later they abandoned it.
Strange. It seems to work for every other program I use on my
XP-boxes as well as on my Win7-boxes.
I like to have everything related to a program at one single place. What's so bad about it?
Executables are stored in Program Files
That's DOS practise! Not WIN32! On modern windows users don't have
write access to subdirectories of C:\Program Files[ (x86)]\, where programs are normally installed!
CSIDL_COMMON_APPDATA is a constant you feed to the windows api
function SHGetFolderPath(), which gives you back "The file system directory that contains application data for all users". On XP this is "C:\Documents and Settings\All Users\Application Data" (or equivalent
for different languages). On Windows 7 this is C:\ProgramData\.
According to microsoft standards, an installer (or program) is
supposed to create/use a subdirectory structure in there like: "\company\product", and use that for it's common, non user specific,
data.
Please don't shoot the messenger! ;)
Absolutely! Current as in the directory where your EXE-file is
located.
Sorry, but I cannot agree. It is not good to have configuration files
and executables in one directory.
Microsoft used that bad practise in Windows 9x, but later they
abandoned it.
I like to have everything related to a program at one single place. What's so bad about it?
Yeah, well, YMMV of course...
Absolutely! Current as in the directory where your EXE-file
is located.
Sorry, but I cannot agree. It is not good to have configuration
files and executables in one directory. Microsoft used that bad
practise in Windows 9x, but later they abandoned it.
In OS/2 I still prefer the directory where the executable is located.
Also the husky way would be ok, use environment variable for pointing
the config file.
I have no problem with the current way; no default.
I see you prefer answering with a question. Why do you think
ANYTHING\Fido\binkd\ is a good place? Only because you use it? I
have no such a directory in my fidonet box.
(See my answer to Michiel.) Because it's a windows standard.
Executables are stored in Program Files
Only when installed the usual Windows way.
Binkd isn't "installed" per se, it's just unpacked in a directory
of your choice. Big difference...
Executables are stored in Program Files but if you work in a
restricted account, you will not be able to write to Program Files. It
is done on purpose. If you for example click by accident on a
reference in a fishing e-mail message and download and run some
malware while you work in a restricted account, the malware will not
be able to infect the executables in Program Files. That is why application store their data in %APPDATA% and not in %ProgramFiles%.
Use a standard way and make Program Files a directory of your choice. :)
Microsoft used that bad practise in Windows 9x, but later they
abandoned it.
CSIDL_COMMON_APPDATA is a constant you feed to the windows api
function SHGetFolderPath()
IMHO it is not a good idea to use a Windows API function in a multi-platform project.
I see you prefer answering with a question. Why do you think
ANYTHING\Fido\binkd\ is a good place? Only because you use it? I have
no such a directory in my fidonet box.
(See my answer to Michiel.) Because it's a windows standard.
Oh, c'mon, when was the last time a _Fidonet_ executable was infected
by malware by clicking on a link in a fishing mail?
In my PoV, on unix binkd should look for binkd.conf in sysconfdir set by configure (/usr/local/etc by default), then ~/binkd.conf.
~/.binkd/binkd.conf or ~/.ftn/binkd.conf??In my PoV, on unix binkd should look for binkd.conf in sysconfdir set by
configure (/usr/local/etc by default), then ~/binkd.conf.
perhaps the second place to look would be better known as
me? my binkd is built for private use in my personal home directory so allof it resides within ~/... spcifically, i use
--prefix=~/ftn/there are other users on the system that want or
in my script that updates, configures, builds and installs binkd... if
need to use binkd, they can build their own copy ;)
If you want to stay compatible with future windows versions, it might
be a good idea to follow microsoft best practice guide lines!
Anyway one doesn't exclude the other. Binkd could check both the
windows default directory and the current directory for it's
configuration file, so everybody would be happy! ;)
Oh, c'mon, when was the last time a _Fidonet_ executable was
infected by malware by clicking on a link in a fishing mail?
really?? /ANY/ executable can be infected or affected by numerous
means...
wouldn't it be better to use %APPDATA%/FTN/binkd? %APPDATA% because... well, it is winwhatever...
FTN because fidonet is not the only FTN and there are many folks in
other FTNs that are not in fidonet and never will be... FTN covers all FTNs ;)
If you want to stay compatible with future windows versions, it might
be a good idea to follow microsoft best practice guide lines!
This is not about your personal preference! ;)
This is not about your personal preference! ;)
wouldn't it be better to use %APPDATA%/FTN/binkd? %APPDATA%
because... well, it is winwhatever...
That's equivalent to using CSIDL_APPDATA with SHGetFolderPath().
But when you are running binkd as a daemon I don't think you want to
use a users private appdata directory for this, but maybe you should?
wait, what? are you ""stuck"" on one machine, one person? i certainly do not want other folks' mail in my stuff nor do i want mine in their's... they can run their own point or node with or without full bbs if they
want and i'll run mine... long gone are the days where one machine is tasked with one job... now those types of things are done per account
and machines have numerous accounts... each standing alone and separate from the others...
But when you are running binkd as a daemon I don't think you want to
use a users private appdata directory for this, but maybe you should?
wait, what? are you ""stuck"" on one machine, one person? i certainly
do not want other folks' mail in my stuff nor do i want mine in
their's... they can run their own point or node with or without full
bbs if they want and i'll run mine... long gone are the days where one
machine is tasked with one job... now those types of things are done
per account and machines have numerous accounts... each standing alone
and separate from the others...
I don't know how you start your binkd,
but here I have a DOS window reading D:\WINDOWS\system32\cmd.exe in
the top bar.
And all files, other than binkd.cfg, is automatically found by binkd
in it's current directory.
Isn't this a storm in a glass of water?
I like to have everything related to a program at one single place. What's so bad about it?
That's equivalent to using CSIDL_APPDATA with SHGetFolderPath().
never heard of that CSIDL thing until you brought it up...
But when you are running binkd as a daemon I don't think you want to
use a users private appdata directory for this, but maybe you should?
wait, what? are you ""stuck"" on one machine, one person? i certainly do not want other folks' mail in my stuff nor do i want mine in their's... they can run their own point or node with or without full bbs if they want and i'll run mine... long gone are the days where one machine is tasked with one job... now those types of things are done per account and machines have numerous accounts... each standing alone and separate from the others...
But when you are running binkd as a daemon I don't think you want to
use a users private appdata directory for this, but maybe you should?
Please read FAQ 37 where it is explained how to configure binkd to run as a Windows service owned by a restricted user account. Why should one use a common directory instead of a private one? I see not a single reason.
But when you are running binkd as a daemon I don't think you want to
use a users private appdata directory for this, but maybe you
should?
wait, what? are you ""stuck"" on one machine, one person? i certainly
do not want other folks' mail in my stuff nor do i want mine in
their's... they can run their own point or node with or without full
bbs if they want and i'll run mine... long gone are the days where
one machine is tasked with one job... now those types of things are
done per account and machines have numerous accounts... each standing
alone and separate from the others...
You do have a valid point, although I think your usecase is very unlikely.
But what does happen is that sysops with more than 1 nodenumber
(sometimes in fidonet, sometimes in different othernets), want to run
more than 1 instance of binkd with seperate configurations. If they
run those in different user accounts, you don't want to have those
binkd instances look in the same location for their default
configuration file.
So although binkd is a server application and can be run as a daemon, APPDATA might be a good place for the default binkd configuration file location...
My binkd server is "multi homed". It can be reached via two different ways.O.k.
So, apply the following patch:As GoldED invalidates three dashes in a row because of tearline signature, "+" should be changed to "-" here.
===
-+- server.c.orig 2016-05-12 10:57:44.548610913 +0300
So, apply the following patch:
===
-+- server.c.orig 2016-05-12 10:57:44.548610913 +0300
+++ server.c 2016-05-12 10:54:42.000000000 +0300
@@ -255,9 +255,12 @@
}
else
{
+ struct sockaddr server_acceptaddr;
It's against binkd v1.1a-94.
So, apply the following patch:
It's against binkd v1.1a-94.
Thanks.
Unfortunately I am unable to do my own compile. So I hope it will be included in v1.1a-95.
Meanwhile you may run two parallel servers with different "listen" and perhaps "log" lines in your configs.
So I hope it will be included in v1.1a-95.You have to spend some time kicking the ass of 463/68. :)
So I hope it will be included in v1.1a-95.You have to spend some time kicking the ass of 463/68. :)
BTW, my own BinkD works with this patch (or you will not see this message).
--- ÅÑα«¼ »« »Ñαúá¼Ñ¡Γπ
So I hope it will be included in v1.1a-95.
You have to spend some time kicking the ass of 463/68. :)
The easiest way to include a patch is create pull request on github.I dislike Github as any other public software development collaboration platforms.
In this particular case I doubt that this patch is really useful. OnYet. But as IPv6 deployment become wider, multihoming will 'an usual case'.
most cases binkd is not multihomed,
If you need this info, you can get it by either run two separate binkd servers (with "include" common part in config) or get this informationOr just apply a patch with 10 lines.
in the on_handshake() perl hook and put it to log.
You have to spend some time kicking the ass of 463/68. :)
Got it. ;-)
In this particular case I doubt that this patch is really useful. On
most cases binkd is not multihomed, or it does not matter which local
IP address was used, so it's redundant information in the log,
obstructing to read it for most of sysops.
IMHO it's make sense to log local IP if multiple "listen" keywords specified in config. But you faced some problem in such configuration. I'll try to catch it, but not sure.
case'.In this particular case I doubt that this patch is really useful. OnYet. But as IPv6 deployment become wider, multihoming will 'an usual
most cases binkd is not multihomed,
In this particular case I doubt that this patch is really useful.
On most cases binkd is not multihomed,
Yet. But as IPv6 deployment become wider, multihoming will 'an usual case'.
Yet. But as IPv6 deployment become wider, multihoming will 'an
usual case'.
If you mean multistack (IPv4 + IPv6) than you can understand which IP protocol was used by remote IP address.
Multihome is not usual case for binkd.
Multihome is not usual case for binkd.
Multihome usually implemented on specialized hardware routers.
Linux server with binkd and multiple network interfaces is exotic configuration. Two uplinks, hardware router, then PC with binkd is
more common solution.
I do not object adding this information with debug log level.
A Perl hook might work. Something like:
sub on_handshake
{
Log(3,"incoming to $our_ip $our_port");
}
A Perl hook might work. Something like:
sub on_handshake
{
Log(3,"incoming to $our_ip $our_port");
}
* Origin: No REPLY kludge - no reply (2:280/464.47)
It shows outgoing too. Had to remove "incoming" :)
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,049 |
| Nodes: | 15 (0 / 15) |
| Uptime: | 66:38:46 |
| Calls: | 236,052 |
| Files: | 60,364 |
| D/L today: |
29 files (34,836K bytes) |
| Messages: | 289,686 |