RT> Here are a number of suggestions that might have merit 
 RT> where Maximus BBS is 
 RT> concerned:

 RT> Run Maximus as user maximus, and belonging to group 
 RT> squish, reason being that 
 RT> other Fido programs already use fido, bbs. ftn as users 
 RT> and groups, and thus 
 RT> cause conflicts. Maximus and squish, are not likely to 
 RT> be used by any other 
 RT> fidonet software, now and/or in future.

As to user and group stuff, Max/Squish isn't forced to any particular user
name / group name at the moment.  I do have a problem with BinkD running
under user ftn and squish running under user maximus, both under group ftn,
on my Debian 3.0r1 (Woody) based system.  Squish places files in the
outbound area in the current setup with a umask of 600 instead of 660,
which then hangs BinkD from being able to properly send outbound files. 
Reception by BinkD and processing by Squish is working.  So, I need to
change the umask for squish to 660, probably by burring how squish is run
under a shell script.....  Or finding a rc file that is currently setting
the umask to 600 and change that to 660 for the account squish is running
under....

 RT> Then again, not many people are going to try running 
 RT> Maximus and MBSE BBS on 
 RT> the same system.

Only a few of us, but as software developers, we're more likely to try both out.....

 RT> In my case, it is problematic running MBSE BBS and Maximus on the same 
 RT> system, even if one stops MBSE, and then runs Maximus, 
 RT> with MBSE user bbs, is 
 RT> the username that a new user is instructed to use, when 
 RT> he dials into a MBSE 
 RT> BBS for the first time. User bbs, does not have a password, and takes one 
 RT> imeidiately to the new user login/registration screen.

Thats just a matter of configureing different accounts for running
different things.  This gets back to how you set the accounts up (i.e. the
install scripts) rather than the programs themselves.....  So far,
everything above can be tweaked via how one creates users and groups, and
how /etc/passwed works, etc.

 RT> Here is the issue file that mgetty shows when a caller 
 RT> calls my MBSE system,


 RT> === Cut ===

 RT>       .--.                Welcome at Rusty's BBS
 RT>      |o_o |               ----------------------
 RT>      |:_/ |
 RT>     //   \\ \\   Abandon all hope ye, who have entered cyberspace.
 RT>    (|     | )
 RT>   /'\\_   _/\`\\                 ENJOY!!
 RT>   \\___)=(___/                   -------
 RT>                  If you already have a bbs login, please login useing it.
 RT>                  If you are a new user, login as user: bbs

 RT> Powered by Linux.

 RT> === Cut ===

 RT> Instead of/in place of, username, bbs, a username of ccs (Computer 
 RT> Comunication System) could be used for Maximus.

 RT> Use mgetty or getty_ps for answering the telephone 
 RT> line, as both are capable 
 RT> of "detecting" Fido type connections / and or mailers 
 RT> and work well in this 
 RT> role.

I'm hopeing to see fido type connections (mailers), maximus, fax and
possibly voice mail handled all via mgetty using a capable modem.....  For
max, one will probably be tolled to log into a specific account, leaving
shell logins to linux on other accounts an option.  Maximus uses it's own,
internal accounting, and doesn't use the Unix/Linux UID/GID stuff, and I
don't expect that to change, since the intent is to eventaully have Maximus
running under Linux and OS/2, and probably Win32 systems.....  Possibly
others if other folks decide to contribute to porting it.

 RT> For a mailer use ifcico, or Qico with the above getty's. This method, is 
 RT> prefered as it allows one to use your com ports with other programs like 
 RT> minicom or seyom (terminal programs) to connect to other BBS systems. 
 RT> Comports on Intel systems being scarce items, and with 
 RT> Linux boxes being able 
 RT> to connect to the internet via the same ports and modem as the BBS uses, 
 RT> makes sense.

And is the style I expect for handling the modem....

 RT> BinkleyTerm XE also works a treat, with the exception 
 RT> that it takes complete 
 RT> control of the comport, and does not allow it to be 
 RT> used by other programs 
 RT> while it is running. To use the comport you have to 
 RT> kill Binkley, do what you 
 RT> want to do, and then restart Binkley, which is not 
 RT> required with the getty's 
 RT> mentioned above.

I believe BinkleyTerm should be able to be configured to be called from
MGETTY, but I haven't tried that yet.  Most folks who come from a DOS, Win
or OS/2 background expect Binkley to run as you have stated, and have
probably brought their control files over from their past systems, and
continue to think in those terms.....  But, I thought I remembered that
Binkley could be handed a hot comm port if properly configured.....  That
should work with MGETTY, but may need a tweak in code to handle the intial
handshake detection that MGETTY has to eat.....

 RT> It might be of value, if you take a look at the way 
 RT> MBSE BBS'es setup scripts 
 RT> work, they are quite good, tho not perfect, it might be educational, then 
 RT> again, it might be "old news".

 RT> Hopefully this post makes some sense to all. :-))

Thanks for the comments.....  I don't think it will have an immediate
impact because there are some issues needing to get worked before the
install process gets further tailored.....  But I may be wrong about what
Wes and Bo (and others) are currently working on first....

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01