this is about the banlist file
over at skymoco we have to
manually add a cheat or tk'r
to the banfile if we dont our
banlist resets to none when
we reset the server...
whenever we /ban xx.xx.xx.xx
shouldnt that be editing the banfile?
adding or subtracting from the file
or am i mis-understanding the
command...
this seems to work for password
files fine etc...but not the banfile
talk about a noob question from an old admin LOL
adding to data files in bz
It should indeed, if you set up a banfile for BZFS and you told BZFS the correct file name. This is the first time I've heard a problem like this.
It most likely does write to the banfile as you use /ban, but the server reset kills it. It shouldn't do that either, but that is what I have a hunch is erasing the file.
It most likely does write to the banfile as you use /ban, but the server reset kills it. It shouldn't do that either, but that is what I have a hunch is erasing the file.
blast,
You might want to get on viper.pimpi.org and talk to Manu. He was having the same problem and I think he fixed it recently. It did have something to do with permissions, and there are more than one server in that domain, too.
You might want to get on viper.pimpi.org and talk to Manu. He was having the same problem and I think he fixed it recently. It did have something to do with permissions, and there are more than one server in that domain, too.
-toaster
"So there I was, all alone, facing all of the enemy. I started driving in circles, until I had them surrounded, and then I escaped in the confusion."
"So there I was, all alone, facing all of the enemy. I started driving in circles, until I had them surrounded, and then I escaped in the confusion."
Just looked over the code quick, and it seems that adding a ban writes a new ban file. However, let's say that Server A and Server B both load a blank ban file. Server A bans someone, and it gets written to the file. Server B will not see this ban, so when they ban someone, it will write out their ban list. Server A's ban will no longer be in the ban file. Reloading the ban file just before adding a new ban fixed this. You can either do a /reload, or modify the handleBanCmd(...) in commands.cxx as follows, assuming 1.10.6 codebase.
Before:
After:
Something like this may very well have been implemented in an existing patch, or in CVS. Of course, it would also be nice to update the banlist on a regular basis, like every 5 or 10 minutes.
Before:
Code: Select all
if( argv.size() < 2 ){
strcpy(reply, "Syntax: /ban <ip> [duration] [reason]");
sendMessage(ServerPlayer, t, reply, true);
strcpy(reply, " Please keep in mind that reason is displayed to the user.");
sendMessage(ServerPlayer, t, reply, true);
}
else {
int durationInt = 0;
std::string ip = argv[1];
std::string reason;
Code: Select all
if( argv.size() < 2 ){
strcpy(reply, "Syntax: /ban <ip> [duration] [reason]");
sendMessage(ServerPlayer, t, reply, true);
strcpy(reply, " Please keep in mind that reason is displayed to the user.");
sendMessage(ServerPlayer, t, reply, true);
}
else {
// reload the banlist
clOptions->acl.load();
int durationInt = 0;
std::string ip = argv[1];
std::string reason;
CVS dosn't reload the banlist. and actualy it's goten a bit more complex, becasue the banlist is more then a local file now. So there are bans from multiple sources. We'd have to flush the local bans, reload them and then save. If you just reload, you flush out the bans from the master banlist as well as the local bans.
It is something we should do tho. Probably just make it part of the save function itslelf, as there is no reason to ever NOT do it.
It is something we should do tho. Probably just make it part of the save function itslelf, as there is no reason to ever NOT do it.
JeffM