Enables or Disables the buddy list feature set.
Example:
/as services set buddylists on
An Enterprise Edition only feature.
This command sets how many days a room must go without services opping anyone before it expires.
Example:
/as services set chanexpire 30
Expiration is important because it frees up rooms that are no longer being used or properly managed for others to take over and run. This is especially important if room registration is open to all users. Many users will register rooms and then forget about or abandon them. Short expiry times make it easier for new users to find good room names. However, too low an expiry time will cause people's rooms to expire too easily. Even well managed rooms may have quiet times, especially if most of the users are students and have vacations at the same time.
This command changes the registration behavior of channels, limiting who can register.
The restrictions for each of the settings are as follows:
disable Channel registration is disabled. Existing registered channels remain registered and usable.
open Channel registration is available to everyone.
oper Channel registration is only available to users with server operator privileges.
Example:
/as services set chanreg diable
/as services set chanreg open
/as services set chanreg oper
The default for this is "open" which allows anyone with a registered nickname to register a channel.
If the number of clones from a specific IP exceeds "multiplier * trigger" services automatically akills that IP.
Example:
/as services set clone-kill-multiplier 10
This command sets the default trigger level for clone warnings. Clone warnings go off when there are multiple users from the same address.
Example:
/as services set deftrigger 7
Low trigger values will pick up several legitimate sources for multiple users from the same address, primarily cybercafes. Although you can set custom triggers for specific addresses, see SECURITY TRIGGER. A large default trigger will fail to pick up many examples of harmful clones. A setting between 5 to 12 is probably best and then each warning can be investigated and dealt with appropriately.
The folder commands set the limits for how many folders each user can have, how many memos each folder can hold, and how many memos from the same nick each folder can hold. The FOLDER commands work with MemoServ, which is an Enterprise-only feature.
CAPACITY - Set how many memos each folder can hold or how many memos from the same nick each folder can hold.
LIMIT - Sets how many folders each user may have.
Examples: /as help services set folder <topic>
When setting your folder limits, decide how you want to your users to use MemoServ and set limits that encourage that use. Larger limits will make memos more useful and encourage their use. Smaller limits may encourage users to only send memos for quick notes and to use other options, such as email, for more important messages.
Granularity works with clone alerts. After the first clone alert is triggered, the granularity determines when a second clone alert is sent if the user keeps adding more clones. If the trigger is at 10 and the granularity is at 5 then the next warning comes at 15, another at 20, and so forth.
Example:
/as services set granularity 6
Larger granularities decrease the number of clone warnings, which can be useful on larger networks. Smaller granularities make it more obvious which clone alerts need to be dealt with more urgently. Hosts that increase rapidly are almost always harmful clones, since valid hosts such as cybercafes will rarely have users all deciding to log in to your server within seconds of each other.
This command sets the host name for your services. It will show up when people /whois the nicks for any of the services and also in the messages sent with kills.
Example:
/as services set host webmaster.com
Your host should probably be set to something related to your network. This is merely an aesthetic detail, it doesn't affect the actual operation of the chat server, but allows for a more professional or personalized appearance for your network. For other commands that customize the appearance of services see SET USER and SET HOST.
Have NickServ log all e-mail addresses used to register nicknames.
Example:
/as services set logemail enable
An Enterprise only feature.
This command sets the type of network that you are running. The default is CRnet, which stands for ConferenceRoom network.
Example:
/as services set network CRnet
This information will show up at times when a response includes the network type. It is an aesthetic detail rather than a functional one.
This command lets you set how many days without use it takes before a registered nickname will be dropped.
Example:
/as services set nickexpire 25
As with CHANEXPIRE, the larger the expiry time the harder it will be for new users to find available nicks. But the lower the expiry time the more difficult it is to keep them. The nickexpire should probably allow for moderate vacations or temporary loss of internet access without causing the user to lose a nick, but still be small enough to clean out unused nicks. Especially since some people will register nicks and either forget they had them or become bored with chat and stop altogether. A limit between 20 and 35 is probably good.
This command changes the registration behavior of nicknames, limiting who can register, or what kind of verification should be required before finalizing the registration.
The restrictions for each of the settings are as follows:
disable: Nickname registration is disabled. Existing registered nicknames remain registered and usable.
open: Nickname registration is available to everyone. No verification is performed.
verify: Nickname registration is available to everyone. Verification of the e-mail address specified is performed, and a registration code which must be supplied to services within 24 hours in order to complete the registration is sent back via e-mail. Existing registered but unverified nicknames remain registered, but cannot be added to channel access lists unless verified.
oper: Nickname registration is only available to users with server operator privileges. No verification is performed.
Example:
/as services set nickreg diable
/as services set nickreg open
/as services set nickreg verify
/as services set nickreg oper
The default for this is "open" which allows everyone to register nicknames without additional verification. When using "VERIFY" mode, the SMTP feature must be properly configured. If it is not, mails may not reach their intended destination, and registrations may expire.
Notice: Services maintains an extensive database of valid top-level domains that it uses to verify if a nickname is valid or bogus. The database is processed once during startup and kept in memory after that. In the event that a new top-level domain is created, it may be necessary to receive an updated version of the database (or edit the file) to ensure proper validation of e-mail addresses.
This command configured the built-in services password filtering engine. This can be used to enforce limitations on what is a valid password. It can be very useful because it can prevent users from using their nickname, channel name or the word "password" as their password.
Example:
/as services set passwdfilter none
/as services set passwdfilter basic
/as services set passwdfilter extended
Passwords must always be at least 4 characters long, but not longer than 32 characters, and cannot contain non-printable characters, such as the "bold attribute" (Ctrl-B in mIRC) or the "color attribute" (Ctrl-K in mIRC). Each setting implies all restrictions imposed by lower settings
The following restrictions apply only when the filter level is set to "basic":
The minimum password length is increased to 6 characters
The password cannot contain the word "password" or"drowssap"
The password of a nickname cannot contain the nickname being registered
The password of a channel cannot contain the name of the channel being registered
The following restrictions apply only when the filter level is set to "extended":
The password must contain at least one character from at least two of the following character groups: uppercase letters (A-Z), lowercase letters (a-z), digits (0-9) and symbols (punctuation marks, currency symbols, arithmetic operators, etc)
The password of a nickname cannot contain the e-mail address or "real name" field of the nickname being registered
The password of a channel cannot contain the description of the channel being registerered
The password of a channel cannot be the same as the password of the channel founder's nickname.
This command will configure how services will allow users to register channels. You can disallow all users, let all users or only allow server operators:
Disable: Channel registration is not enabled.
Open: All users can register channels.
Opers: Only Server Operators can register channels.
Example:
/as services set regchan open
/as services set regchan opers
/as services set regchan disable
You could, in theory, only allow the registration of rooms. But since having a registered room requires a registered nickname, this is not a generally useful configuration. You can disallow both, allow both, or allow only registration of nicknames. The advantage of only allowing nick registration is that you can set up all the rooms you want in advance and then close registration.
CHANS - Allows you to disable channel registration.
NICKS - Allows you to disable nickname registration.
These commands allow you to allow or disallow registration of nicknames and rooms. You can allow registration of just nicknames while not allowing people to register rooms.
Example:
/as help services set register <topic>
You could, in theory, only allow the registration of rooms. But since having a registered room requires a registered nickname, this is not a generally useful configuration. You can disallow both, allow both, or allow only registration of nicknames. The advantage of only allowing nick registration is that you can set up all the rooms you want in advance and then close registration. But nickname registration is much more important for an enjoyable chat experience. Nicknames give users a persistent identity on the chat network.
This command will configure how services will allow users to register nicknames. You can disallow all users, require email verification, let all users without verification or only allow server operators:
Disable: Channel registration is not enabled.
Open: All users can register channels.
Opers: Only Server Operators can register channels.
Verified: Used when you want to have email verification for nicknames.
Example:
/as services set regnick disable
/as services set regnick open
/as services set regnick verify
/as services set regnick opers
If verified is set then you must have an SMTP server configured otherwise this will default to open.
This will define the SMTP server that services will use for nickname registration.
Example:
/as services set smtp 127.0.0.1
Make sure that the smtp server you select will allow this server to use it as a relay. If no SMTP server is set services will not use registration verification.
The type can be one of the following:
register, verify, drop, email-change, passwd-change, passwd-request
Example:
/as services set template verify verify.tem
The filename is optional. It is relative to the root of the CR install, so if you have your file in db/mail/templates you should use "db/mail/templates/mymailtext.txt" as the filename used. If it is not specified, services will use a default mail template.
If the same host keeps setting off clone alerts, then services will send a message saying it is stopping alerts concerning that address. It will then stop sending alerts for a number of seconds equal to the throttle setting. This is designed to prevent network operators from being flooded with redundant information.
Example:
/as services set throttle 30
A good throttle should probable be between 15 and 45. That gives the network operators a chance to deal with the clones, but allows for new warnings if necessary.
This command sets the ident for services. It will show up whenever a user does a /whois on one of the services' nicknames or when services sends a kill.
Example:
/as services set user chatservices
This ident is another aesthetic detail that you can customize. This command along with SET HOST and SET SERVERNAME allow you to control exactly what your services look like.