ServerAdmin Policies
From ChekMate Security Group
Contents |
For Admins And Co-Admins
As admins on this network, you are expected to participate in its running. If you are due to be away from the network temporarily (holiday/vacation/work trip etc.) then you must appoint an acting admin. This is usually your co-admin, but may be any individual who is not already serving as a member of staff on another server.
Neglecting to vote is a serious failing for you as an admin. Servers that persist in not voting WILL FACE A DELINK NO MATTER HOW MANY USERS THEY HAVE ON THEM OR WHO RUNS THEM. If you are not willing to help run the network, you do not belong here as an admin. Failure to vote may, at the discretion of the Server Admins, lead to temporary loss of voting privilege.
- All of the above rules for IRC Operators and users apply to admins.
- Manage your server staff:
- Make sure they are trained.
- Make sure they are doing their job.
- Help them when they are unsure of what their duties are and/or how to do them.
- Deal with any complaints regarding them before they turn into real problems for the network.
- Comply with guidelines for adding IRC Operators (see Managing O-lines).
- Maintain your ircd:
- When a new version of the ircd is released, you have one week to apply the change. If the upgrade is a major one (incompatible with previous versions) then expect your ircd to be juped until the upgrade is complete.
- Promote the network:
- Bring users, make us noticed, anyhow and anyway you can (besides spamming!)
- Participate in votes:
- New policy will be determined for the most part by vote of the admins.
- Keep your colleagues informed:
- If you are unable to attend the network temporarily, inform your staff and colleagues, and arrange for an acting admin to vote on your behalf.
- If your server is not able to handle its normal client load for whatever reason, you are required to notify the Admin Team and expect it to be temporarily removed from the DNS pools so that it does not take clients. If your server is malfunctioning enough to seriously affect the rest of the network, expect it to be temporarily juped.
Server Hubs
Server Hubs are key systems within the network, and as such they must be handled properly. The server hubs connect the IRCd nodes, and services together. They are the key servers within the network and it is highly visible when the availability of the hub servers are impacted. All hub servers will not shutdown their server without proper notification and will take every step posible to ensure high availability.
Each node will have an alternate node link to ensure that netsplit windows will be minimized as much as possible.
Services Proposal
- Services are set up to have alternate servers to connect to:
- If services can't connect to the RemoteServer, they will try RemoteServer2 (if defined). If they can't connect to RemoteServer2, they will use RemoteServer3 (if defined).
- RemoteServer is localhost
- RemoteServer2 is node within geographical area
- RemoteServer3 is another node within geographical area
- Services database is sync'd with alternate site every 30 minutes.
- If services goes offline for more then 30 minutes, alternate site loads their services and jupes the other services.host
- If the primary services.host comes back online, then the alternate services is jupe'd and the primary runs.
- If the alternate is online for a significant time, then a database sync should occur prior to restoring primary services.
Netsplits
After a netsplit, if the reason for the split is known, send a WALLOPS message explaining the reason.
If a split is planned, announce on WALLOPS as soon as the time has been finalized, and on global notice (if it effects more than 5% of the network) at least 5 minutes beforehand.
Linking in general
- There has to be worked out an UnrealIRCd configuration template, which will force servers to have the same network wide affecting configuration. ( in work )
- Server admins are free to name their servers as they wish.
- All other configuration points have to follow the standard template
Linking with other networks
- Linking with other networks must be decided by the opers of both networks.
- Many things will change on a link; for example, services must be consolidated.
- There must be a general consensus among opers (at least 2/3).
- A survey of users' opinions is also recommended, but not required.
- The remote network should not be a general chat network - we want to link with other security-related networks
- Please refer to the Linking/Delinking Procedures
Linking with other servers
- Linking with other server must be decided by the network admins.
- The future server admin has to obey this policy and accept the existing network services.
- Existing services on the merging server which would interfere with ours have to be shut down.
- There must be a general consensus among opers (at least 2/3).
- The remote server should not be a general chat server - we want to link with other security-related servers
- Please refer to the Linking/Delinking Procedures
Server routing
All global IRC Operators are expected to help with routing and recovering from network disruption. If server rerouting is required, an IRC Operator must first warn fellow staff:
/chatops I'm about to reroute penguin, scream now if this is bad
(wait 10 seconds or so)
Then users due to be affected by the upcoming split MUST be warned via services global notice or a mass-notice:
/notice $penguin.*ChekMate.org haven users, the server you are using is shortly going to be rerouted to reduce lag. Please bear with us.
And finally the reroute takes place.
Please note that servers normally recover from netsplits themselves due to autoconnects defined in their configs. There should be no need to intervene unless there is a problem. For example, a server may be able to connect to its primary hub but packet loss on that link may be unacceptable, therefore requiring a reroute to its secondary hub.
Unnecessary rerouting of client servers is frowned upon - a few hundred milliseconds extra lag is not normally noticeable for users, unlike a netsplit.
The current optimal routing plan for the network is decided and documented by The Admin team.
Shared File Templates
Emergency Action
Any admin or services admin may take emergency action to immediately resolve or mitigate network problems. This includes actions that would normally require a full admin vote.
This can include immediate delink of servers or linking of new servers without the normal test-link procedure being followed.
The staff member is required to explain their actions in full to the Admin Team ASAP. Obviously, these actions should not be taken lightly and staff causing unnecessary damage to the network should expect to be reprimanded once the dust has settled.
Change Of Server Details
Admins are permitted to alter their server's details such as operating system, hardware, and/or bandwidth. The Admin Team should be informed of any such changes.
Should a server need to move location net-wise from its current local network, then the server may need to reapply for a test-link period. This, of course, will be approved/denied at the discretion of the Routing Team.
Any change of admin will require a full link application as normal from the new admin.
IRC Opers Forum Area
We have an IRC Operators Forum area located at http://forum.netgarage.org/
- Join forum.netgarage.org
- Register your account
- Place a request with cr to add you to the "IRC Ops" Forum
- Reply to the threads providing an update status of your servers
