
README for MultiSiteSync - Thanks AnnnA for the name =) Beats usersync.sh

DISCLAMER: If this script fucks up your userbase, be happy you had that backup before starting
playing with it.

This script is not for everyone. It requires knowledge of sharing dirs over the
internet in a secure way. I wont help with that part if you get stuck.

----------------------------------------------------------------------------------
If you find any errors in this readme, please let me know. Its tough keeping it
updated between versions ( efnet - #glftpd - Turranius ).
----------------------------------------------------------------------------------

index. Search for '# number' to get there.
 1.1 = Questions and Answers (Q&A).
Slave part:
 2.1 = MSS-CORE.SH / MSS-SLAVE.CONF
 2.2 = TRANSFERCREDITS.SH
 2.3 = SLAVESERVER.SH
 2.4 = MSS-RLSCOMP manual
 2.5 = MSS-CUSTOM manual
Hub part:
 3.1 = MSS-HUB.CONF manual.
 3.2 = MSS-SITE / MSS-POST manuals
 3.3 = MSS-CUSTOMHUB manual
 3.4 = MSS-REPORT manual
 3.5 = MSS-HUBTRANSFER manual
General part:
 4.1 = Actionfile in deep and personal
 4.2 = Replication system.
 4.3 = Report back / Alive? System

#############################################################################################
# 1.1 : Questions and answers
#############################################################################################

"What is this?"

These are a few scripts ment for people who wants to run multiple sites
with the same userbase.

*

"But I already do that by mounting etc and users from one site to another."

Sure, that works. But what happens when the source go down? All other sites
go down too. I didnt like that. 
Plus the fact that when the bandwidth on the source site is high, it is 
terribly slow to log on to the other site, unless you know your firewall =)

So this script allows for each site to keep its own userfiles, including passwd
and group file, but syncing it from a central point. That way you will have one
HUB server and one or more SLAVE servers. The slaves run MSS-CORE and will update its
own userfiles with those from the hub. 
How often it does this is entirely up to you and how you run it. You may crontab the script
to do a full sync as often as you like and there is also an actionsystem in place that will
lead to near realtime syncronisation.
All changes will be made on the hub server and then replicated, using this script, to 
the slave server(s).

The users wont notice if the replication is slow, because its all done in the 
background.

*

"Does it work with both glftpd 1 and 2?"

Yes, although not in a mixed ring. The ring must consist of either glftpd 1 OR
glftpd 2 sites.

*

"Who made these scripts?"

The first versions were made by Turranius (myself). Since version 2.0 though,
void0 has helped with a lot of stuff, including getting us going on the actionfile
system etc etc. void0 is also responsible for mss-rlscomp.sh which will tell mss-core.sh
to move stats after each race is finished.

Nowdays, its back in Turranius's hands 100%

*

"Why so many scripts? And whats the 'hub' and 'slave' dir in the package?"

Ok, lets describe the scripts.
slave/mss-core.sh    - This is the main mss script ment for the slave(s). This one
                       does all the sync/move stats work.

slave/mss-slave.conf - This is the config file for mss-core.sh. Easier to upgrade
                       if the config is seperate.

slave/mss-slave.id   - This contains two lines. GLROOT and DESTNAME.
                       All other scripts can be updated from the hub incase of new
                       versions, but the DESTNAME setting must be unique, so that is
                       kept seperate. GLROOT can also differ so thats kept in here too.

                       

slave/mss-rlscomp.sh - For zipscript-c. After a release is complete, this will be run
                       to write all usernames to the actionfile so the stats are moved
                       after each race. 

slave/mss-custom.sh  - This is for the actionfile system. If you want some kind of sync
                       when doing any kind of command, you can use this as a cscript.
                       More info in the script itself or see section 2.5.

slave/transfercredits.sh - Since credits are seperate for each site, this is 
                           the script used as a custom command on the slave to
                           transfer creds between hub<->slave.

slave/slaveserver.sh - Just used as a custom command on the slave to disable
                       commands like adduser, chgrp etc, since all that should
                       be done on the hub.

slave/mss-pong.sh    - Sends "alive" pongs to the hub so it knows its alive.
                       mss-core.sh does the same thing. This is just an addon
                       if you get a lot of false alarms.

Thats all thats needed for the slave.

hub/mss-site.sh    - This is a script ment as a custom command for the hub.
                     Its kinda like an admin interface where you can force
                     syncs, fetch the logs from the slaves, replicate scripts
                     from the hub to all slaves, etc etc.

hub/mss-post.sh    - Used as a cscript on the hub for all administrative commands
                     like addip, adduser, purge etc etc. It creates the actionfiles
                     that mss-core.sh reads and executes so you get near instant
                     replication on all slaves.

hub/mss-hub.conf   - Config file for mss-site.sh & mss-post.sh

hub/mss-hub.id     - Like for the slave, This contains SOURCENAME and GLROOT.

hub/mss-customhub  - Same as mss-custom.sh for the slave, but this is used for the
                     hub for triggering syncs/stats moves on any command you like.

hub/mss-report.sh  - This is for checking up/down status of the slaves and repoting
                     any errors to glftpd.log for bot pickup.

hub/mss-hubtransfers.sh - Ment as a custom command for the hub.
                          Enables users to decide, for each slave, if they want to
                          move credits back to the hub automatically after a race.

And thats all thats needed on the hub, for now =)

*

"Ok, what will mss-core.sh sync?"

mss-core.sh will do most of the work. It will sync users/move stats etc etc.
When syncing, the following fields are checked from the hub:
GENERAL
LOGINS
FLAGS
TAGLINE
RATIO
GROUP
PRIVATE
IP
DNS

It will keep track of primary groups for a user, so it wont mix the group order
up.

As you notice, it does not sync SLOTS. Why? Well, any changes you do to users
should be made on the HUB server. ( glftpd 2.+ dosnt have a SLOTS field in the userfiles).

*

Now then, what if a user does NOT exist on the slave (just added to hub).
In that case, it will simply copy the userfile over, setting CREDITS and all
the stats to 0 ( 0 0 0 actually. 0 0 0 0 for TIME ).
That includes:
CREDITS
ALLUP
ALLDN
WKUP
WKDN
DAYUP
DAYDN
MONTHUP
MONTHDN
NUKE
TIME
SLOTS

So, the users will have a nice and clean userfile.

*

"But what about passwd and group files?"

The first thing it does, before checking any users (hm, this readme is backwards)
is to run md5sum on both the hub server's passwg/group files, then on the slave server. 
If they do not match, it will simply overwrite the file on the slave. Well, since v2.0, it
will copy the hub's to a temp location on the slave. Then check if the md5sum still matches
the one on the hub and if it does, overwrite the slaves file.

The above functions will only READ from the source site, so no changes will be made
to the hub servers userfiles/passwd/group from the slave.

The actionfile system (mss-post.sh) will tell the slave to sync passwd and/or group
file whenever it is needed for the command executed on the hub.
For instance, adding a user called 'gurra' would result in a sync of passwd as well as 
the user himself. See section 4.1 if you dont understand the actionfile system.

*

"Stats?"

Yepp. Stats can be moved. It will move the stats from the slave and hub server
add it together, then write the added value to the hubs userfiles. 
After that, it sets all stats on the slaves userfiles, to 0.
This is so any trial scripts or similar can be run on one server (the hub).
It is the only time, part from transfering credits, that we write to the hubs
userbase.
Which stats it will move is entirely up to you. Perhaps you just want ALLUP and ALLDN
to be moved the hub? No problem. There are settings for each of them.
Perhaps you dont want stats moved? Keep it seperated if you want =)

This can either be crontabbed at predefined times to move stats from all users or 
you can use the mss-rlsconf.sh script, ment for zipscript-c, to move stats after
each race.

You also have an option to only move the DAYUP and DAYDN to all the other stats
on the hub, thus saving the stats on the slave.

*

"What is this 'actionfile' system I read about?"

Previous versions only did a fullsync at crontabbed intervals. Say every 60 minutes.
This ment that if you changed or added a user on the hub, it could take up to
60 minutes before the change replicated onto the slave.
With the new actionfile system, its done within a minute. 

How?

You load mss-post.sh as a POST script on the hub, for all the administrative commands, like
adduser/chgrp/purge etc. What it does is write to a file.
Say you add an ip to the user turranius. mss-post.sh will then write to a file:
SYNC USER turranius

When mss-core.sh runs with argument "actionfile" from the slave, it will read that line
and sync user turranius. Then it will clear the actionfile.

Most commands do not execute the POST script if the command failed, ie a user tries to 
add another user, but dont have the permissions to do so, the POST script is not executed.

Not all commands are like that though. BUT, the neat thing is, if you add an ip to a user,
it dosnt actually write "Add this ip" in the actionfile. It simply says "Sync this user from
the userfile on the hub". So even if a user manages to write to the actionfile, if its not 
actually done to the hub's userfile then it wont do crap to that user on the slave. No harm
done.

*

"How does it get the sources userfiles?"

That part is up to you. As I said, some sites who run this setup usually just NFS
mount the hubs 'users' and 'etc' to the 'users' and 'etc' on the slave server.

Per default, I want you to mount the hubs /glftpd/ftp-data, to 
/glftpd/ftp-data.ext on the slave.

Same with the etc dir. Mount the hubs /glftpd/etc to /glftpd/etc.ext on the slave.
I dont care how you do this. If you are using NFS and firewall, here is a nice article:
http://nfs.sourceforge.net/nfs-howto/security.html

I will not give support for how to solve this. You can do it in anyway you like, as long
as the slave server can access the userfiles/group/passwd from the hub.
It requires READ access for syncing users and READ/WRITE for moving stats / credits ( in
other words, read/write access everywhere ).

Its also been tested with Samba if you'd rather use that, but it has some built in tools
to maintain and automatically remount NFS shares, should they come down and back up again.

HINT:
If you have NFS mounted dirs inside your ftp-data dir on the hub, the NFS server wont let
you export them. Dont see why you would have that though...

HINT2:
For nfs, this is the /etc/exports file for my hub.
/glftpd/etc             x.x.x.0/255.255.255.0(rw,no_root_squash,sync)
/glftpd/ftp-data        x.x.x.0/255.255.255.0(rw,no_root_squash,sync)
where x.x.x.0/255.255.255.0 means that only that slave can access the share.
Read the NFS documentation for best practice but please use rw,no_root_squash

*

"Speed?"

How long the syncing or moving of stats take is entirely up to your line and CPU's. 
If its loaded it will take a lot longer. MSS will read the userfiles quite a 
few times, so it wont be that fast. It is, after all, a bash script with over
4000 lines in it ( mss-core.sh ).

It does, however, come with an option to first copy the hubs userfiles to the slave
server, and sync from those files. This is much faster and highly recomended.

The actionfile system does not copy the files locally since its usually just one user
it checks at a time. No point to copy files for that.

*

"Backup?"

MSS also come with an option to backup all and every files before starting on a full sync. 
You can also set how many backups it should keep in the backup dir before deleting the 
oldest ones.
If you also use the option to copy the hubs userfiles to the slave (see above), then
it will backup those too. So the slave(s) will hold a backup of both its own, and the hubs
userfiles. Neat Neat.

Same as above, it will not backup when just running the actionfile system, only on full,
fullstats and fullsync. mss-core.sh also have an option to just run the backup part when
executed from shell. You can run mss-core.sh on the slave, without any arguments, to get
a full list of functions.

*

"Multiple slaves?"

Yes, in theory, you can have as many slaves as you want. Just mount the hubs users
and etc dir to each one and run this script. 
If you have lots of sites linked, you can also make one or more servers act as both
slave and hub. Just make it a normal slave, then share its users/etc to another computer
who runs mss-core too. Updates to userfiles will obviously be slower, but it works =)
Actionfile system wont work too good though, if even at all.

*

"Logging?"

There are 3 types of logging.
1: Normal log : All changes to userfiles and stats are logged here.
2: HighDebug  : It will log everything it does. Very spammy but good never the less.
                If you have a problem, this is the log I want.
3: Debug      : Normal debug. Running it with the argument 'debug' will show on screen
                what it does (not logged to file). Almost the same as HighDebug, but to
                screen instead of file. Not quite as "deep and spammy" as HighDebug.

Syncing users, moving stats and the highdebug can be 3 different logs if you like. 
Easier to read as stats-sync can get quite spammy, even without highdebug.
Logging can also be turned off entirely (maniac).

Its recomended that you keep highdebug output to a seperate file incase something goes
wrong somewhere.

*

"Permissions?"

You can select which permissions it should chmod the userfiles too. I dont know if its
just me, but glftpd has an annoying feature to change permissions on my userfiles so root/users
cant change in them. This, ofcourse, can be turned off.
It will also use this value when chmodding log files/actionfiles etc etc.

*

"What if the link goes down as it is syncing. Will it delete a user because he cant be read?"

No. We do a LOT of checks to see if the link is ok here. When I find a user that is on a slave
but not on the hub, I will do the following:

If its running with COPYLOCAL on TRUE, that is, copy the userfiles locally, and the slave servers
user does not exist in the copylocal dir, it will switch back and try and check from the the
hubs users dir. If he does exist there, that means the copy of userfiles were interuppted, and
he will not be deleted, just skipped for syncing this time.

If however, he does not exist as a userfile in either the slaves local copy or the hubs userdir
it will check with the passwd file. The passwd file is already synced at this stage, so it will be
up to date. 

If he does NOT exist in the passwd file, he must be deleted, and will be deleted on the slave too.

However, if he does exist in the passwd file, that can only mean two things
1: The link went down. Cant read the userdir on the hub.
2: The usersdir vs passwd file are not synced on the hub. He has a passwd entry, but no
   userfile.
In either case, he will not be deleted on the slave.

MSS will do one more thing to make sure it does not delete anyone by mistake IF you use the
backup feature.
It will make a directory, if it dosnt exist, in the backup dir, called "deleted".
Then, instead of deleting the userfile, it will move it to that dir.

If it should happen to find him on the hub server again later, it will make a new clean user
of the hubs file BUT log that there is an old userfile for this user. You can then decide to 
either delete that old file or restore it over the newly created one.

If you do not use the backup feature, the user will simply be deleted.

As I said, we do a lot of checks for link or permission problems. Before every write
to a userfile, it will verify that it CAN do it first. If not, it will report it and leave the
user alone.

--------------------------------------------------------

"Ok, so whats this transfercreds.sh script?"

The transfer credits script is loaded as a custom command on the slave server(s).
It allows a user to transfer credits back and from the hub and slave. 

It also supports moving from slave -> slave, but that is a bit trickier and will be
discussed later in this readme.

This script is only ment to be loaded onto the slave servers.

So if a user wishes to move 500 megs to the hub, he would type:
site transfer give 500

If he wishes to move 500 megs from the hub, he would type:
site transfer take 500.

It comes with its own logfile, as well as a limit on the min/max limit to move.
You can also check your current credits on both stats with the argument 'status'
as well as the state of the link.

If you want your users to pay for transfering credits, you may specify a % of what
it will cost (TAX).

* END OF Q&A.



#############################################################################################
# 2.1 MSS-CORE.SH / MSS-SLAVE.CONF
#############################################################################################

Oki, lets go over the options of the scripts. Lets do this in the order they should be installed
starting with the big one, mss-core.sh on the slave(s).

mss-core consists of 3 files. mss-core.sh, mss-slave.conf and mss-slave.id. 
Put mss-slave.conf anywhere you like. Preferebly in the same dir as mss-core.sh. If you not put
them in the same dir then you will need to edit mss-core.sh and specify where the config is.

Start editing mss-slave.id. Only 2 settings in here

GLROOT=         The path to glftpd. Default is just /glftpd

DESTNAME=       This slave servers name. Will be used in the logging and when reading
                the actionfile. Make sure this is unique for all your slaves.
                Do not use - or . or so in the name. Just use normal chars.
                The shorter the better, like 3 chars or so, but thats optional of course.

HINT: If you want to keep a generic config for each slave, but have some settings in mss-slave.conf
that differs from slave to slave, put those settings in mss-slave.id instead.
That way, mss-slave.id is kept but you can sync the config from the hub or whatever.

mss-slave.id is read before mss-slave.conf though, so if you do this, you must either remove
that config setting or remark it, using a # before it, in mss-slave.conf.
For example, move the STAT_SECTIONS= settings from mss-slave.conf to mss-slave.id incase you have
different stat section setups on the different slaves.


Now, edit mss-slave.conf
NOTE: The hub server is called the source and the slave is called dest, short for destination.

GL_VERSION=     This is set to either 1 or 2. Note that you can NOT mix 1 and 2 sites in
                the same ring.

SOURCENAME=     The hub servers name. Will be used in the logging.
                Do not use - or . or so in the name. Just use normal chars.

FTP_DATA_EXT=   Where is ftp-data.ext mounted? By default, its /glftpd/ftp-data.ext

                As I said before, HOW you mount this is up you you, be it samba
                NFS or a friggin laplink cable. As long as MSS can READ it for the
                syncing of users and WRITE to it if you want to move stats back 
                there from the slave.

USERSOURCE=	Where are the hubs source files, relative to FTP_DATA_EXT above?
                The default is $FTP_DATA_EXT/users and you really shouldnt need
                to change this.

USERDEST=	Where are this slaves userfiles located? This is the "live" dir. Usually
		just /glftpd/ftp-data/users

PASSWDSOURCE=	Where is the hubs passwd and group file?
                Imagine you mounted the hubs /glftpd/etc dir to /glftpd/etc.ext on
                the slave. In that case, make it /glftpd/etc.ext

PASSWDDEST=	Where is the passwd file on this slave? Usually /glftpd/etc

BACKUPDEST=	This is where it will make backups. The default is /glftpd/ftp-data/backup
                so you have to create that dir if it dosnt exist.
                If you leave this empty, it will not make backups (not recomended).

MAXBACKUPS=   	How many backups should I keep in the above dir before I start removing
                the oldest ones?

PINGTEST=       TRUE/FALSE. Do you want to do a ping test to the hub before running?
                If your hubs firewall accepts pings, I suggest you set this to TRUE.
                It will send 2 pings. If 2 pings are recived, it will simply continue.
                If 1 ping goes through, it will log to the HIGHDEBUGLOG if that is on and then
                continue as normal.

                If 0 pings go through, it will umount PASSWDSOURCE and FTP_DATA_EXT and quit.
                Umounting will be done with umount -f, umount -l and finally a umount.
                Errors here are shown on screen when running with 'debug' and in the log.

PINGOPTIONS=    What options to give the ping command, if set to TRUE above. What you want it
                to do is send 2 pings only, so check 'man ping' for how to get it to do that.
                On RedHat/Mandrake, its -w2 so that is the default. According to [Acido], you'll
                want to use -c2 on Debian.

USENFS=         If you are mounting the hub shares with NFS, you can enable this
                one and it will verify, with rpcinfo, that the services are answering on the 
                hub. If one of them does not, it will unmount in the same way as PINGTEST does 
                ( very hard! ).

                It should contain a list of NFS services to check, space seperated. Something
                like: USENFS="rquotad nfs nlockmgr mountd"
                You may use this together with PINGTEST if you like.
                Errors here are shown on screen when running with 'debug' and in the log.

                Hint: From the slave, do 'rpcinfo -p hubip/hubname' to get a list of
                      services that answers. You can specify any or all of these.
                Settings this to "" or "FALSE" disables NFS check.

DNSHUB=         This is used by PINGTEST and USENFS only. Basically the name of the hub.
                You can use either the DNS name or the IP. If you leave this one blank, it
                will attempt to read the name from /etc/fstab where I suppose you mount 
                FTP_DATA_EXT and PASSWDSOURCE. Having the mounts in /etc/fstab and leaving this
                blank is recomended.
                Errors here are shown on screen when running with 'debug' and in the log.

REMOUNT=        If you mounted ftp-data.ext and etc.ext so they show up when you run 'df' and you
                have the entries for them in the /etc/fstab, then you can set this to TRUE.
                What it will do is; if it can not find the VERIFYUSER (below), it will attempt
                to unmount ftp-data.ext and etc.ext and mount them again. If the hub server is on a
                dynamic IP and it changes, the slave servers will loose contact with it and
                MSS will stop running, so set this one to TRUE and you dont have to bother
                about it. Strongly suggested to use this with PINGTEST and/or USENFS since those
                umounts the drives if they find any errors and REMOUNT mounts them again when
                the hub comes back up.

VERIFYUSER=	A username that must exist on both the hub and the slave. I will use this 
                user to do some checks. Mostly to see if the link is up. 
		The default is glftpd, because that user is there by default.
                If you specify a user that does not exist, nothing will work.

LOG=		Which file should I do all the usersync logging to? The default is
		/glftpd/ftp-data/logs/usersync.log
		You can also make this empty to disable logging (not recomended).

STATLOG=	You may want a seperate logfile for moving stats with the 'stats' argument
		since that can be quite spammy in itself. If you want it in the same log as
		above, just use the same file.
                This will only log the actual moving of stats. Errors and others will still
                be logged to LOG above.
		As above, leave this empty to disable logging.

HIGHDEBUGLOG=   Where to log highdebug output. You can set this to a seperate file or 
                to the same as LOG or STATLOG. Leave this empty or put a # infront of it
                to disable logging of this type.

TMP=		A temporary dir where I will edit userfiles and stuff.
		The default is $GLROOT/tmp. Might have to create that dir. If so, set chmod 777 on
                it while you're at it.

EXCLUDE=	Any users you do NOT want synced can be added here.
		The default is just: EXCLUDE='default.user'
		Seperate users with a | and make sure you encase it with ' ', as the default.
		so EXCLUDE='default.user|pella|pekka|blabla'

                Note that you can NOT have a user that is not on the hub though. I copy the passwd
                and group files right over, so if he exists only on the slave, he wont get any 
                password and cant log in.

MD5BIN=		To verify that the passwd/group files match with the hub, MSS will use
		md5sum. This must be installed, and this is the full path to it.
		Default is /usr/bin/md5sum
                To find where it is, either do 'which md5sum' or 'locate md5sum' from shell.
                This is also used when running glftpd 2+ to check the group information files.

                FBSD boxes can use md5 instead. Just specify that binary here instead as
                MD5BIN="/sbin/md5 -r" (thanks zsb for the tip).

LOCKFILE=	Where to put the lockfile so the script does not run once its already running?
		The default is: /glftpd/tmp/usersync.lock

                Note. If the slave goes down in the middle of a sync, the lockfile will still bere
                there and the script wont run. I therefor recomend you add the following to your
                /etc/rc.local file (or whatever your system runs at bootup) on the slaves.

                If the lockfile exists when trying to start, it will check how old the lockfile is.
                If its more then 60 minutes it'll be deleted and the script will continue.

PERMS=		What to change the permissions to on all userfiles I encounter? The default is
		666. Make this empty to disable the feature, but be prepared that MSS will complain
		that I cant read or write to certain userfiles if so.
                This will mostly affect transfer of credits since thats done as the user from inside
                glftpd.

RUNLOCAL=	TRUE/FALSE. Do you want to first copy the userfiles from the hub to the 
		temporary dir on the slave, then sync from there? This is HIGHLY recomended
		as speeds will improve alot by it. It also has the added benefit of backing
		up a that copy on the slave (as well as the slaves usersdir), if you
		have not disabled backups above.

SHAREALLOTMENT= TRUE/FALSE. Do you want the same allotment on the slave as you do on the hub?
                If you set this on TRUE and the user has 10gig allotment on the hub, he will get
                the same on the slave, thus doubling his credits (since he can move it between sites).
                You can halve the amount on the hub and he will get 50% of the orignal value on the
                hub and 50% on the slave.

                If, however, you like to keep weekly allotment on the hub ONLY, set this to FALSE.
                When FALSE, it will set any weekly allotment, on the slave, to 1000 Kb. That means
                the user will get 1 Mb credits on the slave when the weekly allotment resets.
                He will then have to manually move credits from the hub to the slave.
                It will not change allotment when adding the user, but the time after, when syncing.

SLOWTIME=	Between each userfile, you have the option to wait for a while. This is to preserve
		both CPU and bandwidth, or if you are searching for an error and dont like it to
		just spam by. Set the number of seconds to wait between each userfile.
		The default is 0.1 so the HD's get a little break.
                If you get sleep errors, try 0,1 instead of 0.1. Slackware users; set either 0 or 1.
                Yes, you can just set this to 0 as well.

FILES_TO_SYNC=  You can specify to sync any other file if you like. All it requires is that the slave
                can access it on the hub. That means, any file in /glftpd/etc or /glftpd/ftp-data on the hub.

                The function works like this:
                sourcefile>destfile or destfile<sourcefile
                
                Ofcourse, you have to specify full path to it. So if you want to sync site.rules from
                the hub to the slave, it would look like this:
                "$FTP_DATA_EXT/misc/site.rules>$GLROOT/ftp-data/misc/site.rules"

                You can also use < if you want to sync the other way (or just change the
                order of them).

                Seperate files to sync with a space. Something like this works fine
                FILES_TO_SYNC="
                $FTP_DATA_EXT/misc/site.rules>$GLROOT/ftp-data/misc/site.rules
                $FTP_DATA_EXT/misc/welcome.msg>$GLROOT/ftp-data/misc/welcome.msg
                "

                If you need to use a space in a path, use [:space:] instead.

                They will be synced when running 'actionfile' and when manually syncing passwd/group 
                files with 'mss-core.sh syncfiles'.

SYNCGENERAL=    TRUE/FALSE. Do you want it to sync the GENERAL field when syncing user info?
                If FALSE, you can have seperate information on the slave from the hub.

             >  Note for all the SYNC* options: When adding the user for the first time to the
             >  slave, all the info from the hub will be synced, no matter what you set here.

SYNCLOGINS=     TRUE/FALSE. Same as above, but for the LOGINS field.

SYNCFLAGS=      TRUE/FALSE. Same as above, but for the FLAGS field.

SYNCTAGLINE=    TRUE/FALSE. Same as above, but for the TAGLINE field.

SYNCRATIO=      TRUE/FALSE. Same as above, but for the RATIO field.

SYNCIP=         TRUE/FALSE. Same as above, but for the IP field(s).

SYNCTIME=       TRUE/FALSE. This one is a bit different from the rest of the options.
                Normally, when syncing a user, we just read from the hub and add any changes
                to the slave. This works in the opposite direction and ONLY on the TIME value in
                the userfile that specifies WHEN the user last logged on.

                If you run any 'listidle' or 'lastseen' scripts on the hub, they might be misleading
                since a user might just log on to the slave(s).
                With this on TRUE, whenever we sync a user (not moving stats), it will check if the
                time on the slave is later then that on the hub.

                If it is, mss-core.sh will update that value in the HUBs userfile, thus making you
                'listidle' scripts show the correct values.

                This is the only time when syncing userinfo (not stats) that we write in the userfile.


                Note that SYNCGROUP is not an option since the group/passwd files would fudge up if
                we have a group on the slave thats not on the hub, or vice versa.

KEEPSTATS=      TRUE/FALSE. When moving stats from the slave to the hub, do you want to keep the stats
                on the slave? If FALSE, it will simply move all stats and set them to 0 0 0 on the slave.
                This is the safest and prefered way to do it? Why?

                Well, if you set it to TRUE, we will add to the stats on the hub based on DAYUP and DAYDN
                on the slave. For instance, if you uploaded 1000 MB on the slave and move stats, it will
                add those 1000 MB it read from DAYUP and add it to DAYUP, WKUP, MONTHUP and ALLUP on the
                hub. It will then set DAYUP to '0 0 0' on the slave the rest of the values alone.

                Example:
                KEEPSTATS=TRUE       |       KEEPSTATS=FALSE
                Slave  -> Hub        |       Slave  -> Hub
                                    -|-
                DAYUP  -> DAYUP      |       DAYUP  -> DAYUP
                DAYUP  -> WKUP       |       WKUP   -> WKUP
                DAYUP  -> MONTHUP    |       MONTHUP-> MONTHUP
                DAYUP  -> ALLUP      |       ALLUP  -> ALLUP
                                    -|-
                Only DAYUP is 0'ed   |       All stats are 0'ed
                on the slave.        |       on the slave.

                And the same for DAYDN, etc.

                Why is this bad? If the link between sites is down or it does not sync stats for whatever
                reason and the reset binary runs on the slave, reset will set DAYUP/DAYDN to 0 0 0 on the
                slave. If so, those stats are gone. Well, they are not gone since they are still in the
                other *UP values, but its gone from the HUB's point of view. Cant move it back. Trial script
                does not register it, etc.

                So, unless you have a good reason to keep the stats on the slave or have a flakey line,
                leave this on FALSE so it syncs the stats from, say, ALLUP->ALLUP instead of DAYUP->ALLUP.

                The actionfile system minimizes the chance of lost stats, using mss-rlscomp.sh, but 
                if a user just leeched today, he isnt caught by mss-rlscomp.sh since it only moves stats from
                those participating in the race.

                If you run this, make a file that you crontab instead of the reset binary. Something like:
                Create file /glftpd/bin/midnight.sh

                Put in it:
                /glftpd/bin/mss-core.sh fullsync debug > /glftpd/ftp-data/logs/mss-todayfull.log
                /glftpd/bin/reset -r /etc/glftpd.conf

                Chmod this file to 755 or something.

                Crontab it like you did with reset ( 0 0 * * * /glftpd/bin/midnight.sh ).

                That way, it will always sync first, if the line is up, before resetting any stats.

                Another way to do this is to NOT run reset everyday on all slaves.
                Just run it at the start of each new week and 00:01 at the start of each month, and then 
                specify that it should only reset weekly or monthly stats (reset --help). That way, daily 
                stats are never cleared unless its moved by MSS. Safer is better but in this case, it requires
                two reset lines in the crontab. One for resetting weekly and one for resetting monthly.
                However, the midnight.sh way is really prefered and the above text probably just made you
                confused =)

        Get  >  If set to TRUE, the MOVESTATS settings below still counts for where to add the DAYUP/DAYDN
         it  >  stats to. If you dont define ALLUP in MOVESTATS, it will NOT touch that stat on the hub, no
          ?  >  matter what KEEPSTATS is set to.


STAT_SECTIONS=  Ok, another long read, sorry. Since mss-core 2.8 (2.10 package), mss supports multiple
                stat sections. This is how you define which stats goes where on the hub.
                Its quite simply; Slave_Section>Hub_Section.
                Stat sections starts with 0 (DEFAULT) and goes up to 8 (glftpd dosnt support more).
                In other words; 0>0 up to 8>8

                These are the sections defined with "stat_section" in glftpd.conf.

                So, "0>0" will move all stats from the first (DEFAULT) stat section into the same section
                on the hub. This is how it worked before and is also the default in mss-slave.conf.

                "0>1" would move stats from 0 (DEFAULT) stat section into stat section 1 on the hub.
                It does not do any checks (would take too long) so make bloody well sure you DO have a second
                stat section defined on the hub when doing that. Defining a section on the slave that dosnt exist
                is not as bad, but still pointless.

                You can also merge, if for some reason you'd want that. For instance; "0>1 1>1 2>1"
                would move stat sections 0, 1 & 2 from the slave into section 1 on the hub, all merging it
                together.
                If you do use this function, there is one requirement. The section on the hub (>?) must be setup
                next to each other. So "0>1 1>1 2>0" works, but "0>1 2>0 1>1" does not because there is a
                0 between two 1's. Yes, this can be fixed with a few more lines, but I doubt many people will use
                this function to merge stats. Theres really no point in seperating stats on the slave if you're 
                going to merge it on the hub anyway.

                One thing you can NOT do is "0>1 0>2"
                Why? Because when 0>1 is done, stats in section 0 on the slave will be "0 0 0", thus nothing is left
                to be moved to section 2 on the hub for 0>2.

                Most people who only use one stat section will be happy with just "0>0".

                Hint: If you have less then 9 slaves, you could add 8 (DEFAULT (0) is already there) dummy stat 
                      sections on the hub that each points to a non-existant dir. 
                      Then define each slave to move stats into its own stat section.
                      For example: Slave1 has 0>1, Slave2 has 0>2 etc. 
                      Then you can keep track of which slave the user is most active on by checking stats on the hub.

                Remember one thing; The more stats you set to move, the longer mss-core.sh will take to complete.

MOVESTATS=      Here you define, in a list, which stats are to be moved back to the hub. Valid entries are
                ALLUP ALLDN MONTHUP MONTHDN WKUP WKDN DAYUP DAYDN
                All of those are the default setup in mss-slave.conf.
                Again, no checks if you did this correct are made, so make sure you do it right.
                It IS case sensitive.

MOVENUKE=       TRUE/FALSE. Do you want to move the NUKE values back to the hub too?

WITHDRAWNUKE=   Heres the thing: When stats are moved from the slave to the hub and
                the user is nuked on the slave, he gets to keep his stats since they
                will not go below 0 on the slave. So, this one will check the NUKE field
                on the user when syncing stats. If he's nuked, it will subtract the MB amount
                from his stats on the hub.

                So, here you define which fields we should deduct the NUKE values from.
                Valid entries are 
                ALLUP MONTHUP WKUP DAYUP

                If you would rather have the user keep his stats, leave this empty.

                No, you should not add any *DN stat fields here. That would produce some
                strange download values (Get nuked, suddenly you leeched less? hmm, no thanks).

                One issue, although small, with DAYUP is:
                If he was upping something yesterday and you nuke him today, it will
                subtract the nuked stats from todays uploaded stats on the hub, even though
                his stats there are 0. 
                It will never go below 0 on the hub either though, so no biggie.

                Note: Values are always withdrawn from the DEFAULT section (0). Not definable (yet).

AUTONUKERESET=  There is a bug in glftpd in that it sets the nuked MB value waaaay to high
                ( like 50 TB nuked ). If this happens, it might not be so good to deduct those
                stats from the hub since we would pretty much always get 0 stats left =).
                It will always detect this failure and skip/warn the moving of nuked stats
                from this user, but with this option set to TRUE, it will reset the nuke
                value back to 0 on the slave and keep syncing. Setting this to FALSE will 
                skip the user if it detects an obviously wrong NUKE value.

FETCHLOGSDIR=   This is the dir the keep actionfiles in. It should be a dir that the slave
                can reach, located on the hub. Therefor, the default is 
                $PASSWDSOURCE/msslogs since PASSWDSOURCE is mounted above. 
                ( /glftpd/etc/msslogs/ on the hub ).

MSSREPL=        This is a dir where all the replicated files are on the hub.
                More on replication later.
                Default is $PASSWDSOURCE/mssrepl

ALLOW_RUNCMD=   TRUE/FALSE. In mss-site.sh on the hub, there is a 'site mss runcmd' that
                will allow anyone with access to that command to execute anything on the slave(s).
                If you do not wish to allow that on this slave, set this to FALSE.

*               There are also settings for mss-rlscomp.sh, mss-custom.sh and
                transfercredits.sh below. 
                Those will be covered in their respective section below.

mss-core.sh can do a few other things as well. To check, configure mss-slave.conf, then 
run mss-core.sh from shell.

> The first time you run a full sync, leave the users dir on the slave totally empty so it can
> make an exact match. Any previous users in the slaves users dir will most likely be
> deleted if they are not on the hub too.

> You cant NOT have users on the slave that isnt on the hub. The slave is a ... slave only!
> Also, you can NOT just merge 2 sites passwd and/or group files together. They contain uid
> and gid for each user and group and if they match someone else, well.. dont know what would
> happen really.

Thats everything there is to know about mss-core.sh. Run it manually a few times or something, then
crontab it.


The crontab should be made to do the actionfile. I run it every minute since it just checks
if there is an actionfile. If so, sync what it says and if not, quit.

* * * * * /glftpd/bin/mss-core.sh actionfile

If you also wish to move the stats back to the hub twice a day, this line will do it at
11:50AM and once again at 11:50PM.
50 11,23 * * * /glftpd/bin/mss-core.sh fullstats

Otherwise, just use the mss-rlscomp.sh script to move stats after each race.
Note though, mss-rlscomp.sh only runs after each race to move stats from those racing.

To be on the safe side, do a full sync instead of fullstats.
50 11,23 * * * /glftpd/bin/mss-core.sh full

NOTE: If you have more then one slave, play it safe and spread out the time so the slaves
      does not all sync stats at the same time. MSS uses a lockfile system so the slaves should
      never write to a userfile at the same time, but it never hurts to be on the safe side.

NOTE2: You might not think you need a 'full' in the crontab because of the actionfile, but
       not all changes in the userfiles trigger the actionfile to run. 
       You might have other scripts that changes a userfile. 

       Also, if you have SYNCTIME=TRUE in the script, so it updates the 'last seen' value in
       the userfile in the hub, you'll want a 'fullsync' to run atleast once or twice a day.
       Logging into the slave is definetly not something that triggers the actionfile, so therefor
       a fullsync cant hurt to get the 'last seen' values updated on the hub.


#############################################################################################
# 2:2 TRANSFERCREDITS.SH
#############################################################################################

Options in transfercredits.sh

transfercredits.sh is the script that is ment to be loaded in the slaves glftpd.conf
file, allowing the user to move credits to and from the hub.

It can move credits from slave to slave too, but that requires a bit more work since the slaves
do not have any contact with eachother. See section 4.3.

NOTE: MORA has created a tcl version of this for bots, using the botnet. Its hosted at my website
      but I do not support it one bit. The name of it is sitecreds and resides in the Guest section.

      There is also a script called CTS (Credits Transer System) that you might want to check out.
      Check the download section at www.ioftpd.com for it.

The configuration is set in mss-slave.conf. It also reads GLROOT from mss-slave.id or if you
hardset that in the script itself (leave it in mss-slave.id if possible).

> Only credits from the DEFAULT stat_section will be moved. If you have seperate creditsections, those
> credits can NOT be moved.

Zie options:

COMMAND=	This is just the command you use for the script in glftpd.conf
		the default is "transfer"
		Its just for the help texts, so it matches what you set it to.

TRANSFERLOG=	Where to log user transfers? It will log before doing any transfers
		so if the script craps out, or the users claim they didnt get the
		creds, verify with the log.
                It will also log any shit the users try to pull. Like site take -1000 or so.
		Default is $GLROOT/ftp-data/log/transfers.log

                When transfering from slave to slave, the first part will be logged on the
                slave its executed on and the second part (adding creds) will be on the 
                recieving slave.

BIN=		The location of glftpds bin dir.
                Had one user who this was different for, so I made it an
                option.

MINAMOUNT=	The minumum amount of megs the users can transfer at once.
		The default is "10" (Mb). Shouldnt set it lower then this.

MAXAMOUNT=	The maximum amount of megs the users can transfer at once.
		The default is "10000" (10Gb).

AUTOMATICSTATUS= TRUE/FALSE. When someone transfers credits, the previous and the
                 new credits will be displayed at the end so the user can verify
                 that the transaction took place ok. Its like doing a 
                 'site transfer status' before and after moving credits.
                 This might take a second or so longer, so its an option too.

TRANSFERTOHUB   = TRUE/FALSE. Setting this to FALSE will disable users
                  from transfering credits back to the hub from this
                  slave. Some people want one way transfers only so this
                  is the easy solution (for you).

TRANSFERTOSLAVE = TRUE/FALSE. Setting this to FALSE will disable users
                  from transfering credits from the hub to this slave.
                  Same as above, but the other way around.

                  Setting both this and the one above to FALSE will disable
                  the script totally, duh.

TRANSFERTAX     = This is a percentage between 1-99. Its a tax which will be
                  deducted from the credits on the server thats being transfered
                  to. So, setting this to 10 and a user tries to transfer 100 MB
                  will cause it to deduct 100 MB on the source and give 90 MB on
                  the destination.

                  Setting it to "" or "0" will disable this function and no tax
                  will be deducted (default).

                  A new line in the log will appear for each transfer, if you
                  have this enabled. Also, the help text has been updated to show
                  if it is on or not.

                  When executing transfercreds.sh from shell, tax will NOT be used.
                  Dont know why you would want to use this from shell though, as
                  mss-core.sh supports moving credits much better.

NO_TAXED        = If you use TRANSFERTAX (above) and SLAVE2SLAVE (below), these
                  servers will NOT be taxed when transfering to. You enter
                  the names, space seperated, of the servers that wont be taxed.

                  So if you have 3 slaves, SLV1, SLV2 & SLV3. 
                  This script is loaded on SLV1. 
                  You want tax to SLV2 but not to SLV3, you enter
                  NO_TAXED="SLV3"
                  More slaves: NO_TAXED="SLV2 SLV3 SLV4" etc...

                  Leave empty to disable. This setting has no use if TRANSFERTAX is
                  not set. If SLAVE2SLAVE is not set, its useless too since you can
                  only transfer to the hub then. If so, its easier to not set a 
                  TRANSFERTAX to disable the tax functions.

SLAVE2SLAVE     = TRUE/FALSE. This will enable slave to slave transfers. See
                  section 4.3 and set it all up before enabling.
                  If you only have one slave, set it to FALSE (default).

DENY_SLAVES     = Only valid if SLAVE2SLAVE is set to TRUE.
                  You may add a number of slaves here, space seperated, that the users
                  should NOT be able to transfer to using the slave2slave function.

                  If left empty, the user can send credits to all slaves.
                  Its not case sensitive, but add the slavenames as they are defined
                  in every slaves mss-slave.conf.

                  If you add all your slaves here, it will call you a moron for not
                  setting SLAVE2SLAVE to FALSE instead =) (yes, really).

SLAVE_INTERNAL  = If you have multiple credit sections on this slave and would like
                  users to be able to transfer credits between then, here is what you
                  define which section is which.
                  For example, if you have 2 stat sections with seperate credits, you
                  could do something like ="0:Movies 1:MP3" (always starts with 0).
                  If you do not want this functionality, leave SLAVE_INTERNAL at =""
                  or put a # infront of it.  

                  TRANSFERTAX has no effect when moving credits internally.

INTERNAL_ALLOW  = If SLAVE_INTERNAL is enabled (defined), here is where you set from 
                  which credit sections users can transfer, to where.
                  Using the above example, we could set "0>1 1>0" to allow them to 
                  transfer from both section 0 to section 1 and vice versa.
                  Should you only want them to be able to transfer from MP3 to Movies
                  then we make this "1>0".
                  If you have 4 stat sections and you want them to be able to transfer
                  anywhere, here is what it would look like:
                  "0>1 0>2 0>3 1>0 1>2 1>3 2>0 2>1 2>3 3>0 3>1 3>2"

                  However, to simplify things, you can also set INTERNAL_ALLOW="ALL"
                  to gain the same result.

                  If you define, for example, 3>0 or similar, make SURE you have atleast
                  4 credit sections (0-3=4). If you dont, it will most likely take credits
                  from section 2 or somthing instead.
                  If you dont know how many stat_sections with seperate credits you have, or
                  dont know how to verify this with the userfiles, I suggest you leave
                  SLAVE_INTERNAL empty to disable this functionality.


Naturally, it uses parts on the general config too, like SOURCENAME, TMP and the paths to
userfiles.

Thats all about transfercreds.sh. Load it on the slaves glftpd.conf, like
site_cmd TRANSFER       EXEC    /bin/transfercredits.sh
custom-transfer         *

Running 'site transfer' will give you the options. There's not that many.
It will probably spit out some error about missing files, but it should be 
fairy obvious what to do.

If you find any exploits in this one, please let me know. I've done
everything I could think of to make it as secure as possible.

Oh yeah. glftpd or something has a nasty way of chmodding userfiles so users get access
denied on them. The lazy way to solve this is by adding this to crontab:
* * * * *     chmod 666 /glftpd/ftp-data/users/* >/dev/null 2>&1


#############################################################################################
# 2.3 SLAVESERVER.SH
#############################################################################################

slaveserver.sh options

This really just outputs some text. Weither you want to use this is 
up to you. Open it up and change:

SOURCENAME=	The name of the HUB. Should match SOURCENAME in mss-slave.conf but dosnt have to.

Changes the text as you please. I disable the following commands by
writing this to the slaves glftpd.conf since those commands should be executed
from the hub or they would be overwritten on a full sync.

Note that if you have SYNCTAGLINE=FALSE, it might not be too smart to disable the
'site tagline' command for example.

site_cmd TAGLINE        EXEC    /bin/slaveserver.sh
site_cmd ADDUSER        EXEC    /bin/slaveserver.sh
site_cmd DELUSER	EXEC	/bin/slaveserver.sh
site_cmd CHANGE         EXEC    /bin/slaveserver.sh
site_cmd CHPASS         EXEC    /bin/slaveserver.sh
site_cmd ADDIP          EXEC    /bin/slaveserver.sh
site_cmd DELIP          EXEC    /bin/slaveserver.sh
site_cmd GADDUSER       EXEC    /bin/slaveserver.sh
site_cmd PURGE          EXEC    /bin/slaveserver.sh
site_cmd GRPNFO         EXEC    /bin/slaveserver.sh
site_cmd GRPREN         EXEC    /bin/slaveserver.sh
site_cmd GRPADD         EXEC    /bin/slaveserver.sh
site_cmd GRPDEL         EXEC    /bin/slaveserver.sh
site_cmd FLAGS          EXEC    /bin/slaveserver.sh
site_cmd CHGRP          EXEC    /bin/slaveserver.sh

custom-tagline          *
custom-adduser          *
custom-deluser		*
custom-change           *
custom-chpass           *
custom-addip            *
custom-delip            *
custom-gadduser         *
custom-purge            *
custom-grpnfo           *
custom-grpren           *
custom-grpadd           *
custom-grpdel           *
custom-flags            *
custom-chgrp            *


#############################################################################################
# 2.4 MSS-RLSCOMP manual
#############################################################################################

mss-rlscomp.sh goes to the slave. Its function is to make sure the stats are moved from the
slave to the hub on two different occations. 

1: When a race is completed, it will make sure all stats of those involved are moved.
2: When a user logs out from a slave, stats from that user will also be moved.

You can choose to only run #1 or #2 if you so choose.

Copy the script to /glftpd/bin on the slave and chmod it to 755 so everyone can run it.

For option #1:
  These instructions are for zipscript-c. Install it by editing zsconfig.h and set:

  #define enable_complete_script TRUE
  #define complete_script        "/bin/mss-rlscomp.sh"

  Note: That is not a script so the #'s should be there. Dont remove them.
  Once added, recompile zipscript-c as usual.
  ( make clean; ./configure; make; make install )

  Note2: Those two lines are in zscofig.h by default. You are supposed to change those lines
  to match the text above, not adding them again. <- Its when you have to add this to a 
  README that you wonder if some people perhaps are in the wrong business =)

  This means that when zipscript-c completes a release, it will run mss-rlscomp.sh with the
  last file as argument. mss-rlscomp will check which directory this file is in, by reading
  the last 500 lines of the xferlog, take all usernames and write it to an actionfile in 
  your /glftpd/etc dir on THIS SLAVE.

For option #2:
  This is for moving the stats whenever a user logs out. This is neat too since option #1
  only moves stats for those that was involved in the race. Other users, just leeching or
  something else, is not synced automatically so the stats only gets moved on a full
  or fullstats sync from the slave.

  Using this function can cause a little bit more overhead on your box since everytime a 
  user logs out, the stats are moved back to the hub. Its well worth it though, IMO.

  Installation of this one is also a lot easier. Just add to glftpd.conf on the slave:
  cscript  QUIT           PRE     /bin/mss-rlscomp.sh
  
  Then the script will execute when users log out and it will understand this itself (hence
  the same script in zsconfig.h for option #1).

  It should be noted that I dont think this will ALWAYS be executed when a user logs out.
  There might be some occations where the users disconnects in a weird way so the cscript
  never triggers. However, I've tested to disconnect in all ways I can with FlashFXP and it
  always triggers, even if I just close flash.

Since the actionfile that mss-rlscomp.sh produces are stored in /glftpd/etc on the current
slave (not on the hub), /glftpd/etc MUST be writable by everyone. It also logs to 
/glftpd/ftp-data/logs so its the same with that one.

In other words:
chmod 777 /glftpd/etc; chmod 777 /glftpd/ftp-data/logs

Option #1 above also reads the /glftpd/etc/passwd file to match uid with a username so
chmod 644 /glftpd/etc/passwd 
should do the trick. If not, 666 is the key (as always).

The files mss-rlscomp produces will then be read by mss-core.sh when executed with 'actionfile' 
and move stats from those users that were affected, back to the hub.


mss-rlscomp.sh takes its settings from mss-slave.conf and mss-slave.id.

The settings in mss-slave.conf for mss.rlscomp.sh:

 GLXFERLOG="$GLROOT/ftp-data/logs/xferlog"           This is your path to the xferlog file.
                                                     As read above, GLROOT is taken from mss-slave.id
                                                     and should be kept as $GLROOT here.

 EXCLUDE="/site/0day|/site/mp3"                      If you have sections where it should NOT move stats when
                                                     a release is complete, add them here, | separated.
                                                     Start from /site here. Not from /glftpd.
                                                     If your affils do not get stats until they pre, you should
                                                     add your predir here too. Like /GROUPS/

 RLSCOMPLOG="$GLROOT/ftp-data/logs/mssrlscomp.log"   This is where mss-rlscomp will log to. Create the file and 
                                                     set something like chmod 766 on it.

 LOGOUT_EXCLUDE="User1|User2"                        This is only for the cscript in glftpd.conf when a user
                                                     logs out. If you have services or users that log in and
                                                     you DONT want to trigger a statmove, add that username here.
                                                     Example might be a bnc check script that logs into the slave
                                                     every 10 minutes to see if its up. We dont want to trigger a 
                                                     statmove every 10 minutes for that user.

                                                     Should users that are added here join a race, stats are still
                                                     moved though (if using option #1 above too).

 VERBOSE="FALSE"                                     TRUE/FALSE. When testing from shell, you should set this to
                                                     TRUE. When running it live from zipscript-c or glftpd, you 
                                                     MUST set it to FALSE. <- REMEMBER THAT! =)

***
I'll say this again since its a source of lots of PMs:
Since this is executed from inside glftpd as the user themselfs, make sure everyone have read rights 
on /glftpd/etc/passwd. 
Everyone must also have write permissions to the logs dir, the RLSCOMPLOG file and /glftpd/etc.
***


If you can not get this one working, using #1:
  Problem with mss-rlscomp.sh when running from zipscript-c is that it cannot output any error 
  messages so you wont see what is wrong with it.
  One way to test it is to chroot to /glftpd and trying to execute it with
  a filename as argument ( ./mss-rlscomp.sh filename.rar ). Use a filename that was uploaded
  not too long ago (since it only checks the last 500 lines of xferlog).

  That usually works since you are root, but its executed as the user from inside glftpd.
  So, even if this works, you might still have permission problems.

  Another way is to add it as a custom command in glftpd. First, set VERBOSE="TRUE" in mss-slave.conf
  Something like:
  site_cmd test EXEC /bin/mss-rlscomp.sh
  custom-test *
  Then execute it from inside glftpd with 'site test filename.rar'. As with the first test,
  make sure the file was actually uploaded to the site very recently.

  If it spits out any errors, you'll know what to do. If it does not and it works fine this way
  it probably means that your zipscript does not execute it at the end of a race for some reason.

  Do not try this as the glftpd user. The glftpd user has uid0 by default and is therefor
  treated as root. Thus you wont see any possible permissions errors on dirs or files.


The most common problem is solved by: chmod 777 /glftpd/etc; chmod 777 /glftpd/ftp-data/logs


#############################################################################################
# 2.5 MSS-CUSTOM manual
#############################################################################################

This is basically a script ment to be used as a pre/post script to any other command. 

Make sure your actionfile system works before playing with this one. See section 4.1 below
for more information on how the actionfile system works.

What it writes to the actionfile can be defined with the SEND setting in the script.

For instance: You want it to sync full stats when someone does a pre? Add this to glftpd.conf
 cscript  site[:space:]pre post /bin/mss-custom.sh
Then set SEND to 'SYNC STATS *' in mss-custom.sh

That will send SYNC STATS * to the actionfile whenever one does a site pre.

*-[ IMPORTANT ]-************************************************
You can use it as a post command, but that does not appear to be
working on custom scripts, only glftpd internal commands, or so.
*-[ IMPORTANT ]-************************************************

$2 can be used in SEND for the username of the person giving the command and $3 can 
be given for the users primary group (although no functions exist for groups in mss-core.sh).
Use a * to execute it on all users.

Commands you can use in SEND, accepted by mss-core.sh.
SYNC STATS <user/*>   = Move stats back to hub.
SYNC BASIC <user/*>   = Sync userinfo.
SYNC FULL <user/*>    = Sync userinfo and move stats.
FETCHLOG              = Move this slaves logs back to hub.
INTEGRITY             = Check integrity of userfiles/passwd
DELREPORTS            = Remove all reports on the hub from this slave.
DELLOGS               = Delete all logs on the hub from this slave.
BACKUP                = Run a userbackup.

If you want another function for another command, just copy the script to another name, set 
in SEND what it should do and add a cscript in glftpd.conf, with the command that you want
it to trigger on.

Logging from this script will go to the same log as mss-rlscomp.sh uses. 
You set that in mss-slave.conf.

mss-core.sh will complain to the LOG (defined in mss-slave.conf) if you set commands here 
that is not accepted by mss-core.sh.

---------------------

And that concludes the installation on the slave. Lets move over to
the hub installation and the actionfile system.

#############################################################################################
# 3.1 MSS-HUB.CONF manual.
#############################################################################################

Scripts for the hub server.
mss-site.sh
mss-post.sh
mss-hub.conf
mss-hub.id
mss-report.sh

Copy all 5 files to /glftpd/bin.

Start editing mss-hub.id. Set the hub's name and path to /glftpd.

Make mss-site.sh and mss-post.sh executable (755 or so).
mss-site.sh and mss-post.sh reads its settings from mss-hub.conf and mss-hub.id.

The reason a few settings are in mss-hub.id instead in the scripts themselfs is because
you can have multiple hubs. If so you might want to use the replication system to move
out new version of hub userfiles. With the settings as they are, you dont have to edit
anything in mss-site.sh and mss-post.sh but can instead just push them out.

Lets move over to config mss-hub.conf. That is used for both mss-site and mss-post.
It is described in the conf as well, but lets go over it anyway.

SLAVES=         Names of the slaves to write actionfiles to, space separated.
                These names must match the name in DESTNAME in mss-slave.id as
                configured on the slaves. So if you have 2 slaves and they are
                DESTNAME="Slave1" on the first and DESTNAME="Slave2" on the other, make
                this one; SLAVES="Slave1 Slave2"
                
GLETC=          Default: "$GLROOT/etc"
                The path to the /glftpd/etc path on the hub. GLROOT is defined in the
                mss-post and mss-site scripts. It has to be done that way since they can
                be executed from both shell as well as from inside glftpd and chrooted
                from shell...

GLUSERS=        Default: "$GLROOT/ftp-data/users"
                The path to your users dir on the hub. As above, use $GLROOT to define
                the path to /glftpd.

LOG=            Default: "$GLROOT/ftp-data/logs/msspost.log"
                Where to log to? Both logs from mss-post and mss-site goes here.

GL_VERSION=     Version of glftpd. Either 1 or 2. Note that you can NOT mix v1 and v2
                in the same ring.

MSSLOGS=        Default: "$GLETC/msslogs"
                This should match the dir defined as FETCHLOGSDIR in mss-slave.conf
                on the slave, but seen from the hub.
                Since FETCHLOGSDIR are set as $PASSWDSOURCE/msslogs on the slave, it will 
                be $GLETC/msslogs, seen from the hub.

MSSREPL=        Default: "$GLETC/mssrepl"
                This should match the dir defined as MSSREPL in mss-slave.conf
                on the slave, but seen from the hub.
                This dir will be used for updating/replicating files (see section 4.2).

VERBOSE=        Default: "FALSE"
                If you want to test mss-post from shell, set this on TRUE.
                Since a POST script can not put anything on screen from glftpd,
                it is designed to not say anything incase of errors (since you wont
                see it inside glftpd anyway). While this is on TRUE, mss-post will NOT
                work from inside glftpd.

                mss-site.sh works from both shell and glftpd without this setting so this
                one only affects mss.post.sh.

Ok, that covers the config.

#############################################################################################
# 3.2 MSS-SITE / MSS-POST manual
#############################################################################################

These files go on the hub.

Start playing with mss-site.sh since it can and will display any errors. mss-post can not due
to it being a POST script but they work in pretty much the same way. If mss-site works, mss-post
should too.

To install mss-site.sh and mss-post.sh, edit them and they include that
information.

Unless you changed the trigger, do a 'site mss' from glftpd and it will display a menu
for you to play with. Try a few commands and make sure it is written to the actionfile.

Both mss-post and mss-site will create one actionfile for each slave defined in mss-hub.conf.
The files, unless changed, are stored in /glftpd/etc/ on the hub and called <slavename>.actions

Make sure something is written in them for each command when you test the scripts.

(mss-core.sh will, when executed from the slave with argument 'actionfile', pick up its own file and do
everything in it. Once finished, the file will be deleted.)

Now that you got mss-site.sh to write stuff in the actionfile(s), install mss-post.sh if
you didnt already. Try adding a user or changing someones group etc and check that it writes
to the actionfile(s) like mss-site does.
Note, if you do 'adduser' for instance, it will write:
SYNC passwd
SYNC USER <username>

If it does not, check that you've added all you should to glftpd.conf, that VERBOSE="FALSE" and
that you have permissions to write to /glftpd/etc (unless changed). If it does not work then
try logging on as user glftpd and try it again. If it works as user glftpd, you have a 
permissions error somewhere (glftpd user has uid 0, hence treated as root). Try
chmod 777 /glftpd/etc

mss-core.sh (slave) will, when executed with 'actionfile', read the file and first sync passwd 
then the user.
mss-core.sh is smart when reading. It will read the actionfile first, then structure what to
do and finally do it. So even if the actionfile says
SYNC USER <username>
SYNC passwd
it will always do the passwd part first because certain commands have higher priority then 
others. Rename for instance, have the highest priority. In that case we check for deleted users
by verifying with passwd, so that one must come first.

It will also remove duplicates when reading it, so dont worry if your actionfile contains
SYNC USER turranius
SYNC passwd
SYNC USER turranius
then it will only sync turranius once. No reason to do it twice.


#############################################################################################
# 3.3 MSS-CUSTOMHUB manual
#############################################################################################

This is the same type of script as mss-custom, but for the hub.
It is ment to be used as a pre/post script to any other command. 

Make sure your actionfile system works before playing with this one. See section 4.1 below
for more information on how the actionfile system works.

What it writes to the actionfile can be defined with the SEND setting in the script.

For instance: You want it to sync the user when he issues a 'site vacation'? Add this to glftpd.conf
 cscript  site[:space:]vacation pre /bin/mss-customhub.sh
Then set SEND to 'SYNC BASIC $2'

That will send 'SYNC BASIC <username>' to the actionfile whenever one does a site vacation.

*-[ IMPORTANT ]-********************************************************
You can use it as a POST command as well, but that does not appear to be
working on custom scripts, only glftpd internal commands, or so.
*-[ IMPORTANT ]-********************************************************

$2 can be used in SEND for the username of the person issuing the command.
Use a * to execute it on all users.

Commands you can use in SEND, accepted by mss-core.sh.
SYNC STATS <user/*>   = Move stats back to this hub.
SYNC BASIC <user/*>   = Sync userinfo.
SYNC FULL <user/*>    = Sync userinfo and move stats.

If you want another function for another command, just copy the script to another name, set 
in SEND what it should do and add a cscript in glftpd.conf, with the command that you want
it to trigger on.

Logging from this script will go to the same log as mss-post.sh uses. 
You set that in mss-hub.conf (LOG option).

mss-core.sh will complain to the LOG (defined in mss-slave.conf on the slave ) if you set
commands here that is not accepted by mss-core.sh.


#############################################################################################
# 3.4 MSS-REPORT manual
#############################################################################################

See section 4.3

#############################################################################################
# 3.5 MSS-HUBTRANSFER manual
#############################################################################################

As you already read in section 2.4, mss-rlscomp.sh is used on the slaves to automatically
move back stats to the hub after a race on the slaves.

mss-core.sh also has the ability to move back credits to the hub, automatically, in a 
similar manor.

mss-hubtransfer.sh is a script ment to be loaded as a custom command on the hub, enabling
users to decide weither they want to automatically move credits back, for each slave.

So, this goes in /glftpd/bin as well. Add the following to glftpd.conf on the hub.

site_cmd transfer       EXEC    /bin/mss-hubtransfer.sh
custom-transfer         *

It uses the actionfile system, so if you are not familiar with that, read section 4.1 first, 
then come back here.

Heres how it works:
Since version 0.6 of mss-rlscomp.sh, it will always write two lines in the actionfile for
each user that took part in the race. The moving of stats which it always did and
one line for moving creds. It looks like: CREDMOVE turranius

* When mss-core.sh reads it, when running 'actionfile', it will check on the hub's etc dir for a
  file called mss-automove.db. If found, it will look for a line that goes like this:
  ThisSlaveName:UserName:ON

*  If that is found, all credits from the user will be moved back to the hub. 

*  If that is not found or the file dosnt exist, it will not move credits (stats still works
   as before).

So if you, on the hub, enable automatic credit transfers by loading mss-hubtransfer.sh, it 
simply writes SelectedSlave:UserName:ON to the mss-automove.db file.

transfercredits.sh (section 2.2) will also check for this file, but that one only reports
to the user, when running 'site transfer' with no arguments from the slave, if automatic 
moving of creds is enabled from this slave or not.

How do you disable this function? Dont load mss-hubtransfer.sh on the hub. If the file
it creates ( /glftpd/etc/mss-automove.db ) does not exist, it disabled.


---------------------------------------------------------------------------------------------
If you get confused by all this, join the club and do it one step at a time.
Install mss-core.sh on the slave first. Make sure it can sync stats/users manually
from shell by executing mss-core.sh.
Once that part works, install mss-site.sh on the hub. Once that works, install
mss-post.sh on the hub, etc.



#############################################################################################
# 4.1  Actionfile in deep and personal
#############################################################################################

Here is how the actionfile system works.

The actionfile is processed by mss-core.sh on the slave. To start the procedure, you run
'mss-core.sh actionfile <debug>'.

The actionfile will contain a number of entries writtes by the other scripts
(mss-post.sh (hub) / mss-site.sh (hub) / mss-rlscomp.sh (slave).

mss-post.sh for instance, is executed as a POST script on the hub when executing commands that
deals with editing users (adduser/deluser/purge/change/addip etc). If you add a user on the 
hub, the text 'SYNC PASSWD' & 'SYNC USER <username>' will be written to the actionfile.
If you change group on a user, it will be 'SYNC GROUP' & 'SYNC USER <username>'.

It writes this file to the hubs /glftpd/etc dir and will be named <slavename>.actions.
mss-post and mss-site reads the list of slaves from mss-hub.conf. 
One file per slave will be created, all containing the same information.

The slave have the hubs /glftpd/etc mounted as /glftpd/etc.ext and when mss-core.sh sees an
actionfile with its name on it, it will start to process it. It does this in a rather clever way
by reading through the file and building a todo list. In the above case of adding a user it
will first sync the passwd file, then sync the user. Each command has a special priority so mss-core
will run them in a specific order.

So, if we first add the user test1 and then add test2 (2 users), the actionfile will contain
SYNC passwd
SYNC USER test1
SYNC passwd 
SYNC user test2

mss-core will read the actionfile, building the todo list. It will see that SYNC passwd is already
in the queue and skip any duplicates of it. So in this case it will 
first sync passwd
then sync the userfile for test1 and finally the userfile for test2.

Likewise, if you have 2 action for the same user. Sync user and move stats, mss-core.sh will
ignore those and do a full sync on him instead. All to save time.

Renaming a user is a bit tricky, but it works and has the highest priority so it does work
even if you add a new user right afterwards with the same name. void0 did a great job on this
part ( he trashed my version of it =(( ).


When mss-core starts to read an actionfile it will rename it to .locked so that if mss-core.sh
should run again it will detect that the .locked file exists and exit. Once it is finished
processing the .locked file, it will delete it. Should a .locked file exist but it can not find
mss running as another process, it will rename the .locked to .notdone (see below) so it can
pick it up the next time it runs. That instance will still quit after renaming it though.


mss-core does a lot of checks to make sure the link is still up. Should the link go down in the
middle of a execution, it will save the actionfile to .notdone in the /glftpd/etc dir on the
SLAVE. 
The next time it runs and the link is up again, it will start with the .notdone file before processing
any possible new actionfiles.

This is where mss-rlscomp comes in (zipscript-c's instant stats mover). Since this is executed on the
slave, its not valid to save it to the actionfile that is located on the hub. If we did and the slave
gets a race when the hub is down, mss-rlscomp would not be able to write the actionfile and those stats
would not be moved until you did a full stat move from all users.

SO.. mss-rlscomp writes directly to a .notdone file on the slave. As we said before, mss-core will, when
running with 'actionfile', do this .notdone file first.

In conclusion, if we crontab mss-core.sh to run every minute with the argument 'actionfile', there will
be a total waiting time of max 1 minute before the user is synced or the stats from the race on the slave
are moved back to the hub.


-- Other hints on actionfile:

* If, for example, you had executed a command or similar that caused mss-core.sh to hang 
  when running actionfile, the actionfile is not cleared. 
  This is because its smart and can detect if an actionfile has not yet been processed 
  completely (incase of shutdown/powerloss etc).

  Since the actionfile isnt removed if not finished, it is reprocessed and the "hang" will happen again.

  Executing 'mss-core.sh cleanup (debug)' from the slave will remove any queued actionfile 
  or "live" actionfiles.

  This was added because it was hard to clean these up yourself since they are in 3 locations 
  (live actionfile on the hub, being processed now & not yet completed).

  So, should you have problems with the actionfile system where the actionfile only grows 
  and grows and never finishes, use this command from the slave(s) in question.
  (only seen this once or twice so you probably wont need to ever use it).

  You can also issue the mss-site.sh command cleanup, as 'site mss cleanup' and the slaves
  will do this, even if the actionfile is busted, as CLEANUP in the actionfile have the highest
  priority. It will clean them out and then quit, skipping any other commands you've given.
  Should be followed up by a full sync incase of missed events.


* FOR SCRIPTERS who edit the userfiles or similar on the hub and want this replicated using
  the actionfile system, you can use mss-customhub.sh in your scripts to write the actionfile. 
  (other people do not have to read this).

  Should you want to do this yourself directly in the script instead, its quite easy.

  Say you edit something in the OstNisse user. You want each slave to sync this information.
  1: We need a list of the defined slaves since each slave has its own actionfile.
     To get this list, we can either read the mss-hub.conf file ( . /bin/mss-hub.conf )
     and then use the SLAVES variable, or we can read just that value ourselfs using:
     SLAVES="`grep "^SLAVES=" /bin/mss-hub.conf | cut -d '=' -f2 | tr -d '"'`"

     Grabbing it, using grep, is probably prefered since mss-hub.conf contains a LOT of 
     variables and we might overwrite some of the ones you're using in your script.

     So ne now have the slaves as a list in $SLAVES.

  2: To sync this information to all slaves, you can do something like this.
     for slave in $SLAVES; do
       echo "SYNC BASIC $USER" >> /etc/$slave.actions
     done

     That will make one file for each slave, containing SYNC BASIC username
     where username is the name of the user currently logged on ( $USER ).

     Of course, if you only have one slave, we might as well just
       echo "SYNC BASIC $USER" >> /etc/slavename.actions
     to produce the same result.

    All commands that the actionfile accepts are:
    SYNC BASIC [*] <user> [<user> ...]     = Will sync basic userinfo
    SYNC STATS [*] <user> [<user> ...]     = Will move users stats back to hub
    SYNC FULL [*] <user> [<user> ...]      = Will do both of the above.
    SYNC PASSWD                            = Sync the passwd file.
    SYNC GROUP                             = Sync the group file.
    RENUSER <user> <newuser>               = Rename a user.
    PURGE <user>                           = Check if we should delete a user.
                                             (wont be purged unless actually deleted)
    FETCHLOG                               = Send MSS logs from the slave to the hub.
    TRIM <size>                            = Trim all MSS logs down to this MB value.
    DELREPORTS                             = Tell the slaves to delete all their reports
                                             from the hubs msslogs dir.
    UPDATE <scriptname> (destinationdir)   = Update a file. The file must exist
                                             in the MSSREPL= directory in mss-slave.conf first.
                                             destinationdir is optional. If omitted, it will copy
                                             the file to the same dir as mss-core.sh is in.
    GIVECREDS <user> <MB Creds>            = Give the user this much credits on the slave(s)
    RUNCMD <command>                       = Tell the slave to execute this command. Be careful.
    VERSION <script to check>              = Tell the slave to check the version of the defined
                                             script and report it back into the reportdir on the
                                             hub.

    So, if you create a Slave1.actions file with GIVECREDS OstNisse 500, then Slave1 will
    do this. If you use our 'for slaves' loop above, each slave will do it.

 

#############################################################################################
# 4.2  Replication system.
#############################################################################################

Since version 2.1, there is a replication system in place to push out new versions to the
slave(s) from the hub. This works the following way:

mss-site.sh will, the first time it is executed from the hub (site mss), create a dir. 
By default, this is in /glftpd/etc/mssrepl on the hub but it is definable in mss-hub.conf
It has to be a dir that the slave has access to, so I used the etc dir by default.

If you, from the hub, inside glftpd, do 'site mss repllist', it will list the contents of this dir.
If will of course be empty unless you put something in there.

If you get a new version of say, mss-rlscomp.sh and you are going to push that out to 10 slaves, do this:
Put the new script in /glftpd/etc/mssrepl on the hub. Then, from the hub, inside glftpd, do:
site mss replicate mss-rlscomp.sh -all
That will cause mss-site.sh to write that all slaves actionfiles. The next time the slave(s) 
run 'mss-core.sh actionfile' it will copy that file to the same location as mss-core.sh is 
located (/glftpd/bin).

You may also specify 'site mss replicate mss-rlscomp.sh -all /glftpd/bin', but seeing how glftpds /bin dir can be
in different locations on the many slaves, giving no 'destinationdir' argument will copy the file to the same dir
as mss-core.sh is in, on the slave. Each slave will detect where it is running mss-core.sh from.

You can also define the slavename instead of using -all if you dont want it on all slaves. Slaves are defined in
mss-hub.conf.

If the file should already exist in the slave directory it will create a dir called mss_oldfiles, copy the old
file in there and finally overwrite the old one with the new one. Restoring from mss_oldfiles must be done manually
if you (or I, tihi) screw something up.

Once updated, mss-core.sh will write a report to the FETCHLOGSDIR defined in mss-slave.conf. So, depending on how
often you crontab 'mss-core.sh actionfile' on the slave, you can check on the hub that the slaves took the new version
by doing 'site mss readreports' from inside glftpd. That is the same way you do it as if you issued the
'check integrity' mode in mss-site.sh.

If mss-core.sh finds the version number at the 2 top lines of the new file, it will report that too. ( version number
should be in the format VER= or VERSION= at the 1st or 2nd line at the file for it to find it. )

You can replicate mss-core.sh, even though that is the script that does the updating, but the updated file will not
be used until the next time mss-core.sh runs.

Also note, you can replicate any file you wish to the slave. As long as the destinationdir exists (if entered) and
the user running mss-core.sh has write permissions there. You really should use root for this.

The backupdir 'mss_oldfiles' is always in the same dir as mss-core.sh is in, even if you specify another location
to copy the files to.

Ok, so say you want to replicate a new mss-slave.conf? No problemo. The only settings that should never be replicated
from a central point is GLROOT and DESTNAME since that can differ between slaves. Those 2 settings are located in
mss-slave.id on the slave and ofcourse, that file should NEVER be replicated (unless you only have one slave).

Other then that, every file ment for the slave can be replicated out from the hub.

IMPORTANT: Make bloody well sure the permissions on the file are ok before pushing it out to 
the slaves. If you push out mss-core.sh with non executable permissions, the slave wont be 
able to execute it. The files will get the same permissions as they have in the replication
dir on the hub when you push them out.


#############################################################################################
# 4.3  Report back / Alive? System
#############################################################################################

Since version 2.6 of mss-core (MSS 2.8 package) there are some new functions to let the hub
know if the slave(s) is alive or not and announce link/usersync/all errors to irc. Perhaps
you'd like a message in your staff channel when a slave drops the link or comes back?

The reporting is done with mss-core.sh. It does this in 2 parts. 
1: Alive? Every time you run 'actionfile', it will write "Im alive" (kinda) to a file on
   the hub. This is required for slave to slave credit transfers.

2: If there is an error on the link/syncing of user or other generic error, it will write
   that error to the same file as #1 does.

The file in question is named SlaveName.msg Each slave make its own file and put on the hub.

Ok, thats simple, right? What then?

Well, the hub needs to read this file and report whatever it finds.
Therefor, mss-report.sh comes into place. Its supposed to be crontabbed at the hub, at 
regular intervals. Every minute is fine for fast responses on errors.

SLAVE: In mss-slave.conf, you set the options for mss-core.sh on what to write to the log.
HUB  : In mss-hub.conf, you set the options for what mss-report.sh will read from this log.

In other words, of you only enable #1 on the slaves, you should only enable #1 on the 
hub.

Now then. It will check this file (or files if you have multiple slaves) every minute (lets
pretend its crontabbed every minute on the hub).

If #1 is enabled, it will check that the file is there. If it IS, the slave has created it
and the slave is alive and well. -> The file will then be deleted by the hub. <-

If #2 is enabled, it will look for any errors in this file (Yes, it will do this before #1 really
since otherwise, the file is deleted already).

If any errors are reported (or, as with #1, nothing is reported), it will write to glftpd.log
on the hub so your bot can pick it up and announce it.

Also, and this is kinda important; The Alive? function was only ment to be executed when
running 'actionfile'. However, when running 'fullsync' and such, actionfile dosnt run
at the same time due to the lockfile. This gave me "site down" at midnight every day because
the Alive file wasnt created. 
So, every 10th user it syncs with 'full', 'fullsync', 'fullstats' & 'integrity', the Alive 
file is written.
That is ofcourse, if REPORTLIFE is set to TRUE (check below).

Oh yeah. A "database" called mss-slavestatus.db will be created as well by mss-report.sh on
the hub, to show the current status of up/down slaves. That is, if REPORTLIFE is set 
to TRUE (It will be created regardless but the slaves will have NoStatus status if 
REPORTLIFE is not enabled).

This file should never be edited manually ! Its not ment to be displayed for the public
as is. However, you may write a script that reads this file to show the users which slaves
are up or down.

So lets go over the options for these functions.

On the slave, we have the following settings in mss-slave.conf:

## Defaults:
 REPORTLEVEL=3
 REPORTDIR=$PASSWDSOURCE/msslogs
 REPORTLIFE=TRUE
 REPORTFULL=2

REPORTLEVEL = This sets the level for which errors you want mss-core.sh to write to the file.
              0 = Totally off. Dont send any errors that occur on lines or syncs.
              1 = Report any errors on the link between the hub and slave.
              2 = #1 + also report any errors on syncing users. Failed to read userfile or
                  settings in it, etc.
              3 = #1 + #2 + All other errors. Lockfile found, quitting, etc etc.

REPORTDIR   = Where should I write this file. This should of course be a location on the hub.
              By default, its $PASSWDSOURCE/msslogs. That means 
              /glftpd/etc/msslogs from the hubs perspective and
              /glftpd/etc.ext/msslogs from the slaves perspective.

REPORTLIFE  = TRUE/FALSE. Every time it runs 'actionfile', it will write a "I'm alive" to
              the file specified above.
              This will let the hub know its still alive and kicking.

REPORTFULL  = 0/1/2. Send announce when starting full syncs? (full, fullsync & fullstats)
              0 = No. 1 = Yes. 2 = Yes, and also when completed.


 If you find you get false alarms sent every now and then, it might be because mss-core.sh does
 so many things that it sometimes sends a "pong" too late. In that case, I've included a 
 script called mss-pong.sh.
 All that script does it send an alive pong back to the hub in the same way as mss-core.sh does.

 False alarms usually happens when syncing is rather slow. Usually due to a 10 mbit line thats
 getting hammered or the box mss-core.sh is running on is slow.

 Anyway, simply copy mss-pong.sh to the same place as everything else on the slave(s) and 
 crontab the following:
 * * * * *       /glftpd/bin/mss-pong.sh

 It still uses REPORTLIFE=TRUE/FALSE from mss-slave.conf, so if you disable that, mss-pong.sh will
 not send "I'm alive" either.

 mss-core.sh will also still send them as well, but thats ok. Better too many then too few.


Thats it on the slave. Easy huh?

-------------

Now to the hub. In mss-hub.conf, we have a few more options. These are read by mss-report.sh:
Part from the ones below, it also reads GLROOT from mss_hub.id and SLAVES from mss-hub.conf.

## Defaults:
 REPORTDIR="$GLETC/msslogs"
 GLLOG="$GLROOT/ftp-data/logs/glftpd.log"
 CHECKERROR=TRUE
 CHECKALIVE=TRUE
 SEND_ON_FIRST_FAILURE=TRUE
 SEND_ON_ALIVE=TRUE
 WAITING_TIME=15


REPORTDIR             = This is the same dir as defined in REPORTDIR in mss-slave.conf, but
                        seen from the hub (duh), so by default its $GLETC/msslogs

                        The reportfile for up and down status on all slaves; mss-slavestatus.db
                        will be created in this directory as well.

GLLOG                 = Path to your glftpd.log file for writing errors to.
                        It uses $GLROOT. Thats read from mss.hub.id as all the other scripts
                        are. You can hardcode the full path if you rather like that.

CHECKERROR            = TRUE/FALSE. Check for reported errors? This will pick up the errors
                        on the link/sync etc that you set in REPORTLEVEL in mss-slave.conf.

                        This can always be TRUE really but to speed it up, set it to FALSE
                        if REPORTLEVEL=0 in mss-slave.conf. Might earn you 1/10th of a sec.

CHECKALIVE            = TRUE/FALSE. This will check that the file is created each time it runs.
                        If the file is not there, it will assume the slave is down (actionfile
                        didnt run on the slave).

                        If this is TRUE, then REPORTLIFE must be TRUE in mss-slave.conf or 
                        you'll get a "slave blabla is down" each time mss-report.sh runs.

SEND_ON_FIRST_FAILURE = TRUE/FALSE. This is for CHECKALIVE only. If TRUE, it will send
                        a warning to glftpd.log the first time it couldnt find the file created
                        by the slave. It will then send another warning the second time it
                        runs too.

                        If FALSE, it will not report the first failure and only if it happens
                        again, the next time mss-report.sh runs.
                        If you get a lot of false alarms, setting this to FALSE might be a good idea.

SEND_ON_ALIVE         = TRUE/FALSE. This is also only for CHECKALIVE. If TRUE, it will send
                        an OK to glftpd.log when the slave that previosly was reported
                        down finally creates the "Im alive" file.

WAITING_TIME          = Time in seconds to wait after it starts, before it actually checks
                        for the file.

                        Why? Lets say you crontab 'actionfile' every minute on the slave.
                        Now lets say you crontab mss-report.sh on the hub every minute too.
                        "mss-core.sh actionfile" starts at 00 and takes a few seconds to
                        do all the checks/write the file. In the meantime, mss-report.sh on
                        the hub is finished, but it didnt find any file. Slave must be down!

                        So, setting this to 15 will wait til 15 seconds past every minute
                        before it actually starts.
                        
                        Do not set this above 60 seconds. You'll get an error then.

Now crontab mss-report.sh on the hub. Lets say you want to run it every minute.

* * * * *       /glftpd/bin/mss-report.sh >/dev/null 2>&1


Thats all? No. Now we must configure your bot to pickup the errors reported and announce
it to the channel on irc.

As usual, only instructions for dZSbot.tcl is available from me.

 -> To the already existing 'set msgtypes(DEFAULT)', you should add: MSSREP

The following you should add where there are others of the same kind:

 Add: set chanlist(MSSREP)  "#your_staff_chan"
 Add: set disable(MSSREP)   0
 Add: set variables(MSSREP) "%msg"
 Add: set announce(MSSREP)  "-%sitename- \[MSS\] - %msg"

There. Rehash the bot.

If it still announces in your DEFAULT channel instead of the one specified in 'set chanlist'
we need to modify your dZSbot.tcl some more.
All creds for this modification goes to a friend who wants to remain anonymous due to this being an
"ugly hack". =)

First, find:

  proc readlog {} {
  global location lastoct disable defaultsection variables msgtypes chanlist

Make sure 'chanlist' is in this one (just add it to the end, like above).

Then, find this part ( also in proc readlog ). Should look exactly like this:

  if { $disable($msgtype) == 0 } {
    set echoline [parse $msgtype [lrange $line 6 end] "DEFAULT"]
    sndall "DEFAULT" $echoline

Remove the 'sndall "DEFAULT" $echoline' and instead, paste this part in its place:

  if { [info exists chanlist($msgtype)] } {
    sndall "$msgtype" $echoline
  } else {
    sndall "DEFAULT" $echoline
  }

Might need to .restart the bot after this change.

You can test this the following way.
In mss-slave.conf, set REPORTLEVEL=3
On the hub, add an ip to a nonexistant user: site addip reporter-test *@127.0.0.1
 (It wont do it, but its still written to the actionfile system).
Run 'mss-core.sh actionfile debug' on the slave. It should spit out an error about
not finding reporter-test.

Run mss-report.sh on the hub. It should announce the error to irc.

If you want to test the 'Alive?' feature, simple stop 'actionfile' from running in your
crontab and execute mss-report.sh on the hub a few times after one another.


#############################################################################################

Thats about it. Have fun =)

/Turranius
