Page 1 of 1

Client limit for OPERS only

Posted: Wed Jun 30, 2004 3:47 pm
by Dornal
Hello, I have a problem with clientlimits. When my server is full I cant connect. I've tried to make different classes and allow blocks, but it seems like unreal doesent respond properly.
Could someone make an example of how this may look in the cfg.
I want my normal clients set to a 800 limit, and the opers set to 100.
So even if the normal clients are full, the opers should still be able to connect.
Preferably with no IP/hostname attached in the allow block.

Posted: Wed Jun 30, 2004 4:41 pm
by AngryWolf
So even if the normal clients are full, the opers should still be able to connect.
Perhaps I'm wrong, but this might not true. Your operators, at the time when they connect to the server, are only normal users first. They also match allow blocks as usual, and depending on which one they match, they are put into a class (which is "clients" in your example). Then, when they do an /oper, they are moved into the "opers" class (if oper::class is set to "opers"). What I'm trying to say is, your operators have to get room in the "clients" class first.

Posted: Wed Jun 30, 2004 4:44 pm
by roothorick
I feel like taking a crack at this, so heck. My best guess is setting up ops as a separate class with its own limits:

Code: Select all

class           ops
{       
        pingfreq 90;
        maxclients 100;
        sendq 100000;   
        recvq 8000;
};
(These numbers may need adjusting)

Then, have each op sign on with an arbitrary username (in this case "staff") so they're placed in that class, and have an allow {} block reflecting that:

Code: Select all

allow {
        ip             *staff@*;
        hostname       *staff@*;
        class           ops;
        password "<guess>";
        maxperip 2;
};
(Correct me about the leading asterisks if I'm wrong)

This way, anyone signing on with "staff" as a username and knowing the password will be in a separate connection class, and have their own limits. (I hope)

(To AngryWolf) He wants a setup where ops would still be able to connect even if the server is full with normal users. I hope I provided details on one such setup, feel free to proofread :)

Posted: Wed Jun 30, 2004 6:24 pm
by Syzop
That should work.
Make sure the order of your allow blocks are correct (the *@* block first, then the specic ones, as mentioned in the documention on the allow block.

To double check this, try connecting with a wrong or no password but with the correct ident (you should be denied then).

Also note that you probably need to have set::options::identd-check enabled and also must be running a correct identd server yourself.

Posted: Wed Jun 30, 2004 7:05 pm
by roothorick
Syzop wrote:Also note that you probably need to have set::options::identd-check enabled and also must be running a correct identd server yourself.
Not necessarily. I'd prefer having identd disabled and tell the IRC client what to send for the username, as it's IMO a bit easier. That's part of why the asterisk is there before "staff" in the hostmask.

Posted: Wed Jun 30, 2004 7:35 pm
by AngryWolf
That's okay, however there is little chance that a normal user not being a staff member sets a username (with the IRC client) that matches *staff, and the person will not be allowed to connect. Does that mean you simply don't allow users to connect with such a username? (allow::options::nopasscont doesn't solve this problem either, because of NickServ passwords.) If yes, in my opinion that's not the best idea (but don't either want to start a discussion war about this), and that's why I thought of changing opers' connection class with oper::class when I first read this topic.

Posted: Wed Jun 30, 2004 7:51 pm
by roothorick
AngryWolf wrote:that's why I thought of changing opers' connection class with oper::class when I first read this topic.
The problem with that is, again, the opers have to find room in the "clients" class first. What if there's some form of DoS or DDoS going on that exploits connection limits? Then opers are helpless to the attack without killing the server from shell, and that's even less ideal.

Posted: Wed Jun 30, 2004 7:58 pm
by Dornal
Hmm... Ive been trying out this. Tell me if something is wrong because when I try to connect with OTECHStaff@myaddress it wont ask me for a password.

Code: Select all

class           opers
{
        pingfreq 90;
        maxclients 100;
        sendq 100000;
        recvq 8000;
};

Code: Select all

allow {
        ip             *@*;
        hostname       *@*;
        class           clients;
        maxperip 6;
};

allow {
        ip             OTECHStaff@*;
        hostname       OTECHStaff@*;
        class           opers;
        password "test";
        maxperip 30;
};

Posted: Wed Jun 30, 2004 8:01 pm
by roothorick
Dornal wrote:

Code: Select all

allow {
        ip             OTECHStaff@*;
        hostname       OTECHStaff@*;
        class           opers;
        password "test";
        maxperip 30;
};
Put an asterisk before "OTECHStaff" on both lines. That should catch the leading tilde if you don't have ident running.

Posted: Wed Jun 30, 2004 8:01 pm
by Dornal
Tried that too.

Posted: Wed Jun 30, 2004 8:04 pm
by roothorick
Clip the last F on OTECHStaff on each line. Usernames are limited to 10 characters, and with the probable tilde that's 9. My hostmask for my allow {} block reads *roothoric@* for exactly the same reason (note no K).

Posted: Wed Jun 30, 2004 8:09 pm
by Dornal
Tried it with only OTECH ... still wont ask for password :/
This is a real problem for me. My opers can't connect if the server is full, which it is almost all the time. Thx for helping :)

Posted: Wed Jun 30, 2004 9:32 pm
by Dornal
Got it! :)
If I added options noident it worked just fine.

Code: Select all

allow {
        ip             *OTECH@*;
        hostname       *OTECH@*;
        class           opers;
        password "test";
        maxperip 30;
        options {
                noident;
        };
};