Client class sorting

[DJ747]

I am having issues with the class and allow blocks. I have setup an extra class and an extra allow block. The class is for opers so that they are pinged less and have different sendq and recvq limits and more hosts per ip than normal users. I have made an allow block for me so that it puts me in the opers class if I specify a password (if not I'll just be classified as a client). The classess appear to be working fine but the allow block isn't putting me where I should be. I put in the correct password, it puts me in the clients class, if I put in no password or an incorrect password, it puts me in the clients class. But if I remove the allow block that puts people in the clients class then it works great, but then no normal users can connect. Here are my classes and allow blocks (in order of the config):

Code: Select all

class           opers
{
        pingfreq 600;
        maxclients 50;
        sendq 200000;
        recvq 16000;
};
class           clients
{
        pingfreq 120;
        maxclients 500;
        sendq 100000;
        recvq 8000;
};

class           servers
{
        pingfreq 400;
        maxclients 10;
        sendq 1000000;
        connfreq 120;
};

Code: Select all

allow {
        ip              *@<myip>;
        hostname        NOTHING;
        class           opers;
        password        "<my md5 password that i will remove>" { md5; };
        maxperip        10;
        options {
                nopasscont;
        };
};
allow {
        ip             *@*;
        hostname       *@*;
        class           clients;
        maxperip 3;
};

[Stealth]

The first allow block should be last...

[Stealth]

Also, you might want to set oper::class to the opers class, so you don't need to have an allow block for all of your opers

(oper::class will change that opers class to the one specified IIRC)

[DJ747]

I believe this server notice should explain it:

Code: Select all

[16:10:18] -irc.<mynet>.com- *** Notice -- Client connecting on port 6667: DJ` (dj747@<myip>) [clients]

[DJ747]

also speaking of my o:line here is my o:line

Code: Select all

oper DJ747 {
        class           opers;
        from { userhost *@<myip>; };
        password "<pass>" { md5;} ;
        flags NDRvXHWZtz;
        snomask cfFkejvGnNqsSo;
};

Here are some server notices:

Code: Select all

[16:16:06] -irc.<mynet>.com- *** Notice -- Client connecting on port 6667: DJ` (dj747@<myip>) [clients] 
[16:16:10] -irc.<mynet.com- DJ` ([email protected]) [DJ747] is now a network administrator (N)

Funny how when it comes to o:lines classes don't matter...

[Stealth]

Because once you oper, Unreal changes your class...

Use /trace <yournick>, and you will see that it does.

[DJ747]

well that sucks, I thought you needed to be in oper::class for your o:line to work, now it just sortof seems pointless. Is there any way so that a user must be in a class or something in order to oper (like a double protection for opers)

[Stealth]

Not that I know of...

[TigerKatziTatzi]

about ur oper class.
a seperate class for opers (or any other additional user class ) is only usefull if u need other class settings, like recvq and sendq.

[Stealth]

about ur oper class.
a seperate class for opers (or any other additional user class ) is only usefull if u need other class settings, like recvq and sendq.

Yes, that is what he os trying to accomplish. He thought opers needed to connect in the oper::class class to be able to oper for that user. He did not understand that once opered, your class is changed to the class specified in oper::class.

The docs should be more clear on this.

[w00t]

I'll also mention that by increasing the ping time, you're more likely to see opers get "Software caused connection abort" errors as the socket will more than likely get closed if no data is sent through it in a long time - one of the reasons pings exist .