Special users

Sometimes you want to give trusted users or bots more rights or higher flood rates than regular users, but you don't want to make them IRCOp. This page explains how.

NOTE: The same method can also be used to give less rights to a group (so the other way around).

Define a security group
It starts with putting users you trust (or distrust) in a security group. Security groups can be based on IP addresses, but also on services accounts via  or certificate fingerprints via. There are actually 15+ other criteria, for all see the Security-group block. There are also standard security groups like known-users and unknown-users (see the same article).

Let's define a security group for people we trust, and assume they all have a Services account and log in to that using SASL.

security-group staff { account { User1; User2; User3; } }

Applying specific settings
In UnrealIRCd 6.1.1 and higher you can create a specific set block for the security-group: set staff { maxchannelsperuser 50; }

The following settings can be overridden in a set block for a security group:

You can also set specific set::anti-flood settings, see next section.

Overriding anti-flood settings
You can use the set::anti-flood block to give higher flood limits (all UnrealIRCd 6 versions): set { anti-flood { staff { /* Allow more concurrent PM's */ max-concurrent-conversations { users 10; new-user-every 1s; }                       /* Allow users to flood 3 times faster than regular identified users */ lag-penalty 250; lag-penalty-bytes 0; }       } }

Flood rates
In the example of above, we allow the security group staff to send a command every 250 milliseconds due to the  setting.

This means:
 * 4 commands per second (1000/250=4)
 * And bursting of 10000/250=40 commands (if, after such a burst, not sending higher than 4 commands per second).

If you need faster rates then here is a cheat sheet for the lag-penalty setting:

The above is the easy explanation. For exact details of lag-penalty and lag-penalty-bytes and the fake lag algorithm, see the set::anti-flood block but this is a fairly complex topic.

Exempting from server bans
You can exempt security groups from server bans (not channel bans) via the Except ban block:

except ban { mask { security-group staff; } type all; }

The  will exempt them from *LINEs, SHUN, Spamfilter, but also give them unlimited maxperip.

If you feel like this is too much, then you can also choose to only exempt the group from certain types of server bans, see the Except ban block article on how to fine-tune this.

Allow and class block
You can create a class { } block with a higher sendq/recvq, like: class staff { recvq 16k; sendq 1M; pingfreq 120; maxclients 128; }

And then you need to create an allow { } block to put users with the security group staff in the class staff: allow { mask { security-group staff; } class staff; maxperip 99; }

IMPORTANT: This allow block must be placed BELOW your general allow block that has. So the general allow block with  must come first, and then after that the allow block with.

Verifying it works
After rehashing the IRCd, let a user connect and use SASL to identify to their Services account.

When the user connects, you will see in the "Client connecting" server notice staff listed in the  portion.

If you want to verify the class { } a user is in, use

IMPORTANT: We assume you use a security-group with account here. If you do, then be sure to use SASL to identify to the services account. If you do not use SASL and use old fashioned  then the identifying takes place too late and the user will not be exempt from server bans like gline and will not be put in a special class. Some other settings still work (like set and set::anti-flood), but only work after the NS IDENTIFY. So, long story short: use SASL and not NS IDENTIFY!