UnrealIRCd Forums

Hi there :

I wanna know if I can create a c-clients class besides a c-opers class by specifying a password for this c-opers class, and when the client connects if the pass is correct, then he can log in as an oper, otherwise as a normal user he would not be allowed, because I force him in the OPER block to belong at the c-opers class. I've allready tried using the "passcont" setting in the allow block, but it doesnt work, it keeps treating the oper as a normal user.

Thanks

You can't restrict oper logins by class. The oper::class setting is the class the oper is put into once he/she successfully opers.

hi there Stealth, thank for ur help,
JIVXor and I work in the same server, so his doubts are so much mine too,
Im sure he will reply once he gets a chance,
the idea he had, lets see if I can explain our*his* point,
when u are adding or editing a server in the script u use, mirc, x-chat, etc ,
there is the option when u can specify a password for the server, only needed by some especial types of users, the point is, ask for this password only to the opers in our server when connecting, and if the password is
correct, then they can oper normally, this its meant for security reasons,
the last time we talked, this was his point, and is a doubt of mine as well,
thanks,

Basing to me on this official documentation:



nopasscont : continue matching if no password was given (so you can put clients in special classes if they supply a password).


The user connects, if hi specify a password, UnrealIRCd takes him as an oper otherwise as a client. I have understood : if I put that JIVXor operator belongs to the class opers, Undertaker cannot come (from client class) and take the operator status.
Am I wrong?

JIVXor wrote:Basing to me on this official documentation:



nopasscont : continue matching if no password was given (so you can put clients in special classes if they supply a password).


The user connects, if hi specify a password, UnrealIRCd takes him as an oper otherwise as a client. I have understood : if I put that JIVXor operator belongs to the class opers, Undertaker cannot come (from client class) and take the operator status.
Am I wrong?

Classes are not really used to authenticate users (From my understanding), it's used to have people on different ping/send/receive limits.

Opers/servers/bots need different "liberties" on the server, so different classes allow them to exceed limits that would flood a normal user.

For example i have a bot that needs a higher ping frequency so that it won't time out, this ping frequency is too high for a user or remote clients (55 seconds in my case, the server times out the session at 60), so it's in it's own class that nothing but my bots use, the ping/pong keeps the bot alive.

I don't want normal users to use this class, so it's limited, in my case, based on IP (localhost) but a password would be just as easy.

Another real world example would be again for multiple bots.

Say you have 10-15 bots connecting from one server, but you want to limit everyone to a maximum of 2 connections per IP.

you would have a classes for "clients" that has a max per IP of 2.
you would then have a classe for your bots that has a max per IP of 10

Now, you want to keep clients off the class for the bots cause then they could clone flood your server more easily so you set a password for it. The bots provide the password and have the ability to log on many many more from the same IP then normal clients.

Classes are not really used to authenticate users (From my understanding), it's used to have people on different ping/send/receive limits.


I use classes for that purpose too. I'm just looking for a way to protect my operators in case that they show they password in the channel for example.

Lets see this :


class c-clients
{
pingfreq 40;
maxclients 300;
sendq 100000;
recvq 8000;
};

class c-opers
{
pingfreq 40;
maxclients 10;
sendq 100000;
recvq 8000;
};

allow {
ip *@*;
hostname NOBODY;
class c-clients;
maxperip 230;
};

allow {
ip *@*;
hostname NOBODY;
class c-opers;
maxperip 2;
password "test";
};


With this block I guarantee that if a client enters by the class c-clients is recognize as c-clients && if a client supply a password UnrealIRCd takes him as c-oper client?
Should I put the sentence "passcont" in WHAT "allow block" ?

Thanks

Matridom wrote:Opers/servers/bots need different "liberties" on the server, so different classes allow them to exceed limits that would flood a normal user.

Not necessarily. If all you change is, say, the recvq then don't bother with a second class - recvq is mostly unused because an IRCop isn't command-throttled. sendq makes sense though, you especially want slightly elevated sendq if you have a lot of glines :) (Max SendQ on /stats G is never fun). pingfreq is something doesn't really reflect "privilege". See below for why.

matridom wrote:For example i have a bot that needs a higher ping frequency so that it won't time out, this ping frequency is too high for a user or remote clients (55 seconds in my case, the server times out the session at 60), so it's in it's own class that nothing but my bots use, the ping/pong keeps the bot alive.

pingfreq shouldn't reflect a "privilege" really. Rather it's more of a tradeoff. Users with more stable connections (typically cable and dsl) can be given higher pingfreqs to reduce bandwidth, while less stable connections (typically dialup) can be given a lower pingfreq to reduce ghost lingering. It's a tradeoff between bandwidth and how quickly the ircd notices a dead link. Take note: too low of a pingfreq can garuntee disconnects even across a loopback interface! If users are getting "Ping timeout"d for no reason, it's a sign that you should up the pingfreq :) . Also, if you want your bot to not ping out then have it properly reply to PINGs as soon as it's received (meaning if it uses a queue based sending mechanism or anything like that, you might want to have the PONG bypass the queue and go straight back so your bot doesn't timeout because the PONG was last in a line of messages 2MB big (consider that without ircop access, your effective bandwidth (sent and processed) to an IRC server is 256 bytes/sec on average :) ). Don't just cheat and set a timer to pong every 40 seconds :) .

matridom wrote:you would have a classes for "clients" that has a max per IP of 2.
you would then have a classe for your bots that has a max per IP of 10

Now, you want to keep clients off the class for the bots cause then they could clone flood your server more easily so you set a password for it. The bots provide the password and have the ability to log on many many more from the same IP then normal clients.

That'd be nice, except maxperip is an allow block setting, not a class block setting (you might be thinking of maxclients, which is a limit on the TOTAL number of connections using that class?).

aquanight wrote:pingfreq shouldn't reflect a "privilege" really. Rather it's more of a tradeoff. Users with more stable connections (typically cable and dsl) can be given higher pingfreqs to reduce bandwidth, while less stable connections (typically dialup) can be given a lower pingfreq to reduce ghost lingering. It's a tradeoff between bandwidth and how quickly the ircd notices a dead link. Take note: too low of a pingfreq can garuntee disconnects even across a loopback interface! If users are getting "Ping timeout"d for no reason, it's a sign that you should up the pingfreq . Also, if you want your bot to not ping out then have it properly reply to PINGs as soon as it's received (meaning if it uses a queue based sending mechanism or anything like that, you might want to have the PONG bypass the queue and go straight back so your bot doesn't timeout because the PONG was last in a line of messages 2MB big (consider that without ircop access, your effective bandwidth (sent and processed) to an IRC server is 256 bytes/sec on average ). Don't just cheat and set a timer to pong every 40 seconds .

The problem here is that this is a php bot, i do not want to change the apache timeout setting on the server globaly and for some reason the change won't take effect if i set it on the script itself, so, if nothing happens after 60 seconds, apache will stop the script the bot exits. I set my ping/pong response to 55 seconds so that the webserver will not time out the script when it hits the 60 seconds inactivity.

So the lower ping is not to keep unreal from booting the bot, but to keep the webserver running the script from killing it. Sorry if i did not make things clear there.

Thanx for the clarification on the rest of it.

You don't have to run php bots through apache ;) . If it doesn't need interactive components (and if it did there's still a way to do it), you could just run through the php interpreter directly :) .

aquanight wrote:You don't have to run php bots through apache . If it doesn't need interactive components (and if it did there's still a way to do it), you could just run through the php interpreter directly .

well, I'll have to get some additional info on that from you, since i don't want to hijack this thread, would you prefer to go over this in pm or start a new thread?

Could someone pliz, help me with my problem?

As been said, you can't limit oper logins by connection class. Use hostnames for that. :)

Hint: with a reasonably secure login name, password, and hostmasks, what more do you really need? :)

I'm agree.

Thanks.

PD: I'm still having doubts in the use of


oper test { class c-clients; from { userhost *@*; };


class c-clients ,means what? that belongs to c-clients?

By the way, I CAN'T use the userhost sentence 'cause all the operators and clients come from the same IP(proxy). That is the reason for which I am looking for another way.

Thanks for your patience.

The class means that when someone /opers to that login, they will be moved to the given class. (So class could limit number of simultaneous opers or something.)

I wouldnt recommend that use. Use oper::maxlogins. Though you can raise a oper's sendq to nearly infinite. Mine is pretty close to the max for opers. Also perhaps opers shouldnt be counted in your user limit. Perhaps the oper class is also accessible by a passwored allow block, so opers can get in beyond the userlimit. (Though thats not strictly related to oper::class, it is a useful reason for a seperate class for opers) Etc.