Hello Bob!

May 29 07:55 03, Bob Jones wrote to Bo Simonsen:

 BS>> Now i understand!

 BJ>   The "fun" of old unix systems.  One of the
first things I 
 BJ> needed to do when getting on a new unix system was to figure out the 
 BJ> various terminals I had available and get the TERMCAP settings edited 
 BJ> properly so I could get vi to work properly.....  [Oh, oh....  
 BJ> mentioned specific editor....  No, I don't need to start that type of 
 BJ> editor religious war.....]  

I actually doesn't care.. The most of the time am i using mcedit, and nano
then i'm going copy-paste.

 BJ> At the time vi was about the only editor 
 BJ> I could guarentee to be on the system.  Yes, you could bring in GNU 
 BJ> EMACS, but that was always secondary....  And then there was also 
 BJ> PICO.....  I think I've used all three at various times over the 
 BJ> years, and then even a few others that were on specific computer 
 BJ> systems....

What UNIX systems did you work with?

 BJ> Yes, I even had a termcap mode for properly using the 132 column mode 
 BJ> of the old VT-100.....  And on the H-19 (VT-52 look a-like), I even 
 BJ> had code that took advantage of the 25th line.....

Aha ok.

 BJ> ...
 BJ>> There is a version of GETTY that is supposed to 
 BS>> differenciate between 
 BJ>> Fidonet hand shakes, PPP and regular modem calls, FAX calls, and 
 BJ>> possibly even a voice (on a voice modem) call.....  

 BS>> It's mgetty as i wrote. But if maximus is taking care 
 BS>> of listening at the port, and so on, it's quite hard to 
 BS>> get it in tuch with a mailer.

 BJ> My point isn't about handling the TCP/IP port, but in the ability to 
 BJ> maintain the old style modem login.  When I switch the BBS over to a 
 BJ> linux based system, I still want the phone line capable to be 
 BJ> answered by the BBS.  

And if the BBS got a **EMSI_something_there_is_not_IEMSI i should call the Mailer? 

Then we got a underfull tool like mgetty, i don't find it smart to program
your own serial communication unit.

You don't see my point?

But there is a terminal issue, that it's the IO now over telnet is using
ncurses and it won't work out over mgetty, but maybe we could use the RAW
IO, so max just is called by max -pots or something, then it start up like
local login.

 BJ> This is longer term issue.  It probably doesn't 
 BJ> need to get addressed to get the basics functioning.  It might need 
 BJ> to get addressed when it comes to figuring out the download issues.  
 BJ> Yes, I also want to be able to get to Maximus via TCP/IP based 
 BJ> connections.

So far i agree, maximus should _not_ be a telnet only BBS, like fx. Synchronet.

 BJ> ...
 BS>> Yes.. Well it could call Maximus directly, like fx. it does with 
 BS>> MBSE...

 BS>> Then the telnet IO module, will be useless, because it 
 BS>> could smoothly be called from inetd.

 BJ> The telnet IO module?  If you mean your existing code for running as 
 BJ> a TCP/IP service, that should be minor.....  Most programs that can 
 BJ> be started under inetd also can be run standalone or via the same 
 BJ> code that runs inetd.  I believe this is done with relatively minor 
 BJ> code differences and probably a command line switch.

Agree captian, so the things work.

If we provide the two things, we could get mgetty, working quite quickly.

 BS>> So it's the arguments of what max is beeing called 
 BS>> with, there is telling max if it's a telnet user or a 
 BS>> dialup user..

 BJ> Maybe, maybe not.

.. if we use inetd.

 BS>> Inetd calls a program with -h hostname and other 
 BS>> arguments, mgetty calls it with -b connect bound ... Or 
 BS>> something.

 BJ> But getty can be (is) used with both TCP/IP and serial port 
 BJ> (including modem) connections -- at least in a standard Unix 
 BJ> environment.  On the surface, it doesn't matter to the application if 
 BJ> the pipe is comming in via TCP/IP or via a serial port.  And if the 
 BJ> "hangup" signals are properly implemented, max shouldn't need a 
 BJ> command line switch to differenciate either, as long as appropriate 
 BJ> defaults are used for unspecified command line options.

How would you configure mgetty/getty for tcp connection? (without the
program is listening on a tcp port)

 BS>> But in a unix environment, i really can't see the 
 BS>> difference of a TELNET call or a POTS/ISDN call.

 BS>> I wonder if the operating system can?

 BJ> At a low enough level, yes.  One of the problems with some folks 
 BJ> imeplementing the isolated one or two modems on a unix system was 
 BJ> folks didn't always turn on the options to "logout" when
modems got 
 BJ> disconnected.  It's not a good security "feature" to be
able to call 
 BJ> back on a modem line and pick up exactly where you left off -- 
 BJ> without any login prompts.  This was a fairly common mistake on 
 BJ> systems where most users came in via hardwired terminals or telnet'ed 
 BJ> into the system....

But obviosly on the high level, i mean what the user in the other end sees,
it doesn't.

 BS>> The idea in having maximus listening on a port, could 
 BS>> be it would control the chat system and so on, but it 
 BS>> doesn't do that... 

 BJ> What did you have in mind?  The current maximus chat option is not 
 BJ> dependant on listening to ports.....  If Maximus is running under 
 BJ> it's own user ID and file space in a Unix / Linux enviornment, we 
 BJ> should be able to keep a table (i.e. set of files) of active users 
 BJ> around like Max does for the OS/2 implementation.  When my OS/2 gets 
 BJ> shut down improperly with some one logged in to Maximus, the next 
 BJ> time Max runs on that node number, the table gets cleaned up and the 
 BJ> error noted in the Maximus log.....

If one process was fork()ing them all, there could be inter process
communication, so the chat system and so on will be working, multinode.

 BS>> Well i don't have the big interest in using Squish, 
 BS>> because it get all what squish can with the hpt tosser 
 BS>> from the husky project..

 BJ> Ok.  That's reasonable for now.  I believe the Husky project has the 
 BJ> Squish stuff debugged at this point.....

I've never got problems about it, i've never discovered bugs in their
MSGAPI smapi. Actually i borrowed some code from SMAPI for fixing a bug in
MSGAPI. 

 BS>> Even more, it share configfile with my ticker, 
 BS>> msgeditor and other programs.

 BJ> Understand.  I haven't broken down to configure fidoconfig yet....

All my fidonet utillities except for my mailers and fastlst is using fidoconf.

 BS>> I wrote a quick and durty C program there is using the 
 BS>> fidoconf-liberay to get hpt's area configuration and 
 BS>> write msgareas.ctl.

 BJ> That will be a usefull conversion tool that we should include in a 
 BJ> Maximus / Linux-Unix disstribution.  It would also be usefull to go 
 BJ> the other direction (msgareas.ctl --> fidoconfig configuration) if 
 BJ> possible.  On the other hand, awk or perl scripts could probably also 
 BJ> be easily whipped up for this.

fidoconfig --> fidoconfig could be written in perl, the other way could
also, but it only require 3 lines of code, to access the fidoconfig
structure, and there you can get all the interformation.

Well, to collect the threads of our discussion (so far vi agreed):

    * Maximus should have 2 options for using tcp/ip connections, it should
be listening on some port by it self, and it should be called from inetd.

    * Maximus should be called from mgetty, after it detects it's a human call.

    * Maximus should _never_ be a telnet only bbs.

Regards,
Bo

--- Msged/LNX 6.1.2