Client limit for OPERS only

These are old archives. They are kept for historic purposes only.
Post Reply
Dornal
Posts: 5
Joined: Wed Jun 30, 2004 3:42 pm

Client limit for OPERS only

Post 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.
AngryWolf
Posts: 554
Joined: Sat Mar 06, 2004 10:53 am
Location: Hungary
Contact:

Post 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.
Last edited by AngryWolf on Wed Jun 30, 2004 4:46 pm, edited 2 times in total.
roothorick
Posts: 12
Joined: Wed Jun 30, 2004 2:37 pm

Post 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 :)
Syzop
UnrealIRCd head coder
Posts: 2179
Joined: Sat Mar 06, 2004 8:57 pm
Location: .nl
Contact:

Post 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.
roothorick
Posts: 12
Joined: Wed Jun 30, 2004 2:37 pm

Post 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.
AngryWolf
Posts: 554
Joined: Sat Mar 06, 2004 10:53 am
Location: Hungary
Contact:

Post 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.
roothorick
Posts: 12
Joined: Wed Jun 30, 2004 2:37 pm

Post 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.
Dornal
Posts: 5
Joined: Wed Jun 30, 2004 3:42 pm

Post 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;
};
roothorick
Posts: 12
Joined: Wed Jun 30, 2004 2:37 pm

Post 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.
Dornal
Posts: 5
Joined: Wed Jun 30, 2004 3:42 pm

Post by Dornal »

Tried that too.
roothorick
Posts: 12
Joined: Wed Jun 30, 2004 2:37 pm

Post 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).
Dornal
Posts: 5
Joined: Wed Jun 30, 2004 3:42 pm

Post 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 :)
Dornal
Posts: 5
Joined: Wed Jun 30, 2004 3:42 pm

Post 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;
        };
};
Post Reply