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....

 BS> What UNIX systems did you work with?

Let's see if I can remember the various flavor's I've used....

* BSD 4.3 on old Vax 11/780 based (and newer) hardware...
* Various flavor's (and renames) of DEC's version of Unix (Ultrix, True64,
etc.), on various DEC based equipement (DEC-20, Vax 11/780, Alpha, etc.)
* Hmmm....  Sun's variation of Unix (Solaris?) 
* NeXT Step (3.1, 3.2, 3.0, 2.?), which is really the NeXT Step GUI on top
of a BSD (4.3?) flavor of Unix running on a Mach kernal.
* Irix (System V based) on 

I may have forgotten a few I've played on.  At one point, I prefered BSD
based Unix systems over System V based systems, but at this point, either
will do.

 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.  

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

Hopefully, any protocol that leads to an FTS based fidonet session will be
handled prior to Max starting, so I see no reason for Max to call a mailer.
 There are no options for Max to call the mailer under OS/2 or DOS when Max
is used in a wait-for-caller mode (i.e. where Max answer's the phone
line)....

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

That's why we should be using a flavor of getty for answering the serial
ports or even TCP/IP "telnet" type ports.  [The TCP/IP telnet
ports used to be PTYxx while RS-232 based ports used to be TTYxx on most
systems I've used.  Ah....  I see PTS# under my Debian Linux setup for the
pseudo terminals instead of PTYxx devices.]

 BS> You don't see my point?

We may still have a communication gap.....  I'm not sure....

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

For the most part, terminal IO [including ncurses issues] doesn't matter
wether it is telnet or RS-232 serial port (to modem) or some other lower
level connection methoid.  If the Unix error /signal handling (interupts)
are properly implemented, then a disconnect (modem hang up or TCP/IP port
closure) comes in to Max with the proper signal.  I'll admit I haven't
looked at how Linux may be different than BSD flavored Unixes in this
regard.....  I may be getting into differences between System V and BSD
flavors....  And Linux was (originally?) a System V flavored clone.

Now it may matter for when Maximus needs to disconnect the session..... 
Because Max may need to force the modem to hang up in that case.  On the
other hand, the system services code that (re)starts getty (or getty it
self) may need to be properly configured to "hang up" the modem
when Max closes out the session.....

 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.

 BS> Agree captian, so the things work.

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

Using getty can get us completely out of the issue of handling opening up
TCP sockets, etc...  The TCP/IP socket handling / deamon code will only
handle TCP/IP based connections.  Getting Max to talk running under getty
based connections gets us both TCP/IP and serial port type connections with
the exact same code.  Have you ever looked at pseudo terminals in a Unix
based environment?  Unfortunately, using getty will mean needing to look
into some IOCTL functions to make sure we are 8 bit clear and not
interpreting control caracters, etc.

 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.

 BS> .. 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.

Agree that we may need one or more command line arguments to flag Max being
rung from inetd....

 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 
 BJ> 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.

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

See my reference to pseudo terminals above....  You used to set up pseudo
terminals with getty the same way you set up regular RS-232 terminals.  The
difference was in the device names (TTYxx versus PTYxx (old) or PTS/#
(current linux).  I think when the PTYxx to PTS/# change was made, there
was a change in how this was done.  Part of the reason for the change was
that you used to have to declare and configure every pseudo terminal device
you were going to use on a system in advance.  Busy systems could run out
of pseudo terminals, and at that point you could not open up a new shell
window until a pseudo terminal (device) became available.  I expect the PTS
structure resolved that problem, but haven't dug into it yet.  We might
have to set up a second set of PTS devices to configure them for Maximus to
allow standard shell processing to continue....  We might look at how both
SSH and telnet co-exist on a system and see if we can get Max to use a
similar stradegy....  I still will need to dig into this.....  Your TCP/IP
based code may be the better solution for the short term, since you know
understand what you are doing there....

 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?

It can.  A POTS / ISDN call to a modem on the physical system will
(typically) come in on a TTY port (see the devices listed by 'ls
/dev/tty*').  The telnet call will (typically) come in on a pseudo terminal
port (PTY port in older systems, see the devices listed by 'ls /dev/pty*').
 If you get into the OS information of those devices you will find the
differences at the operating system level.

 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 
 BJ> terminals or telnet'ed 
 BJ> into the system....

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

Yes it does when you dial into a system expecting to log in and instead you
are connected to the system and are already logged in as some *other* user!
 From memory, there is a hook that we need to handle to take care of
hanging up the modem in an RS-232 based / modem connection that we don't
have to handle in a TCP/IP based connection.  I believe it doesn't hurt the
TCP/IP connection (because it may have already properly handled the session
termination), but I believe the modem based connection needs an extra IOCTL
call to get the modem hung up....  either at the user application level or
in the code related to getty.

 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... 

Ah....  Yes....  If Maximus was a TCP server (deamon), and if all Maximus
nodes were TCP/IP based, then yes, we could rely on the internal chat
function relying on a parent / child process and the items this allows
(potential common memory, or pipes, etc.).  Unfortunately, this doesn't
handle (a) a local console session (moot point with telnet to local host),
or (b) serial port based connections (needed for the modem based
sessions).....  

 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.....

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

Ah....  As I mention above, this only handles the TCP/IP based sessions if
max is a TCP/IP server / deamon.  Another method is running a chat deamon
for Maximus, and have each node connect to it for interprocess
communication.  I believe Max under OS/2 does something like this.  If I
remember correctly, if Max doesn't see an IPC process running, it starts
it, and in either case then connects.  Chat, Who is on, and maybe one or
two other things use this piece of code....

 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....

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

Which is why compatibility with fidoconf via some methoid (scripts, direct
support, etc.) will be useful in the Unix / Linux environment.  And with
the Husky tool set ported to OS/2 and Windows based environments, will also
help there.

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

Good.....

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

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

As seen above, this could actually be optional....  But it is how you have
started porting the code....

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

Be it hardwired terminal, modem, or a (telnet or TCP/IP) pseudo terminal
connection.....

 BS>     * Maximus should _never_ be a telnet only bbs.

Agreed....

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01