[mohaa] Admin tool ready for testing

[[-SF-]Shockwave]

Hello Warren,

> Now,screen is working nicely, and the server is broadcasting the messages
> just right.  But I can still join from my "banned" laptop.

It sounds to me like one or more of the following is happening:

(1) The server can't read the ban.cfg file for some reason
    - doesn't exist
    - looking in the wrong spot
    - bad permissions
    - the path to the ban.cfg file isn't a fully qualified pathname
(2) The "developer 1" setting isn't set or working properly
(3) The IP address in the file isn't entered properly
    - wrong IP address
    - extra characters on the line other than whitespace

Let me explain how the ban logic works and we can proceed from there.  The
server monitoring process sifts through the server output stream looking for
certain events.  In the case of the ban logic, it looks for a string that
ends in " has entered the battle".  Once this message is intercepted, the
process re-reads the ban.cfg file and issues a "status" command to the game
server.  As the status display is produced, each player's IP address is
compared to the array of banned IP's in memory.  A match causes a
"clientkick" command to be issued, followed by a ban message.

The first thing I would do is check to see if you generate a " has entered
the battle" message in the server output when you connect.  If not, ensure
that you have the "developer" cvar set to either "1" or "2" and see if that
fixes it.  It's pretty easy to spot because if this is set correctly, every
time a player joins a status display gets printed to the output
automatically.  If this message isn't being generated, then that's what's
wrong.

If you are generating the message and nothing happens, then I would check to
be sure your ban.cfg file is where it's expected and is readable.  You can
also try running "mohaa_admin --defaults" on the command line and you'll see
where the default ban file location is for your system.  Try leaving out
the --ban option and placing the file in the default location to see if the
ban logic works.  Failure to read the ban.cfg file isn't a fatal error at
this point so it won't be advertised if it isn't working properly.  If you
still can't get it to work, write back to me with what happens when you try
each of the steps I've outlined and I will change the code in order to
provide better feedback regarding the disposition of the ban file.

I did find something that I do want to mention.  The default server
configuration file "mohaa_admin.cfg" doesn't have the BAN_MSG_START and
BAN_MSG_END options commented out.  In this configuration you will only see
the player's name print if a ban message is broadcast.  This is because the
player name is sandwiched between these two variables in order to generate
custom ban messages.  To get the default ban message to print correctly,
simply comment out the two options in the server configuration file by
placing a single "#" in front of each.  I've already made this change to the
default server configuration file so this won't be an issue in the future.

> ...  Also, is there
> anything in effect yet in the client tool that automatically adds a banned
> IP to the ban.cfg?  Or does it need to be added manually?  And if so, does
> the client need to be restarted, or will it read the edited ban.cfg on the
> fly?

There is no method for adding an IP to the ban.cfg file without manually
editing it ...yet.  That is one of the things I wanted to add but I decided
to table it for this initial release.  The client doesn't have anything to
do with the ban.cfg file at this point.  It is handled exclusively by the
server monitoring process and is re-read with each player connection to the
server.

> One other thing. What's the clean kill command for this?  Anytime I ctrl-c
> it, I have to clean up leftover tails, etc.  Not a big problem... just
> wondering if it's been addressed yet.  I know, I know... give them an
> inch...
>

I have tested this on my own RedHat 7.2 server and have seen it tested on a
RedHat 7.3 box and a <Ctrl><C> effectively cleans up everything.  Let me
give you some background information.  When the admin tool is running, it
will spawn 3 processes.  The first process launches the game server and is
responsible for providing input to the game server interface itself.  It
then launches two more processes that handle server output monitoring and
new client connections respectively.  With no clients connected to the admin
tool, you should see a process for the game server and 3 processes for the
admin tool.  Each client that connects causes the tool's communication
process to spawn two more processes: one for input and one for output.  The
client utility does the same thing.  Killing the client utility with a
<Ctrl><C> should cause it's 2 processes to go away as well as the 2
processes spawned by the tool to handle the I/O.  If you attempt to manually
kill any of the processes for either program, you will circumvent the
clean-up logic in place and the processes won't be disposed of properly.

If you are connected to the screen process and issue a <Ctrl><C>,  you
should see all server processes disappear.  To test this, use the "top"
program from another terminal when the server tool is running and hit "M" to
filter active processes by memory usage.  You should see what I have
described.  Record the process ID's of the server processes and then try
connecting with a client form another terminal.  Record the new process ID's
and then disconnect the client by doing a <Ctrl><C> from it.  Everything
should happen just as I described it above.  If not, let me know what
happened to what processes.  By the way, don't do anything funky to start
the client utility like use "screen" with it while you're doing the test.
Keeping it "vanilla" is the best way to figure out what's happening.  Also,
please tell me your OS version, kernel version, and perl version if you
still are having problems.

Keep 'em coming, Warren!


Shockwave

----- Original Message -----
From: "Warren Woodward" <warrenw at xmission.com>
To: <mohaa at icculus.org>
Sent: Monday, September 09, 2002 4:54 PM
Subject: Re: [mohaa] Admin tool ready for testing


> OK, that made too much sense for me to have considered early on a Monday
> morning.  I get it now, and this is pretty slick (I also made a full-path
> alias to the client for ease).
>
> Now,screen is working nicely, and the server is broadcasting the messages
> just right.  But I can still join from my "banned" laptop.  Also, is there
> anything in effect yet in the client tool that automatically adds a banned
> IP to the ban.cfg?  Or does it need to be added manually?  And if so, does
> the client need to be restarted, or will it read the edited ban.cfg on the
> fly?
>
> One other thing. What's the clean kill command for this?  Anytime I ctrl-c
> it, I have to clean up leftover tails, etc.  Not a big problem... just
> wondering if it's been addressed yet.  I know, I know... give them an
> inch...
>
> Sorry if you've answered these already.  Somewhere in the midsts of
> playing with all this I have a few thousand DSL users to take care of,
> too.  :p
>
> Incidentally, if you're interested in trying this server out yourself,
> it's freakshow.xmission.com (default port, the other on 12204 isn't
> running this code yet).
>
> But seriously, this rules.  I like it.
> --
> warren woodward
> XMission DSL
> Domo/Mailman
> warrenw at xmission.com
> (801) 303-0819
> (877) XMISSION
>
>
>
>