home *** CD-ROM | disk | FTP | other *** search
/ The Net: Ultimate Internet Guide / WWLCD1.ISO / pc / java / in4wjcxu / other / irc / doc / example.conf < prev    next >
Encoding:
Text File  |  1996-08-14  |  14.3 KB  |  323 lines

  1. # IRC - Internet Relay Chat, doc/example.conf
  2. # Copyright (C) 1994, Helen Rose
  3. #
  4. #   This program is free software; you can redistribute it and/or modify
  5. #   it under the terms of the GNU General Public License as published by
  6. #   the Free Software Foundation; either version 1, or (at your option)
  7. #   any later version.
  8. #
  9. #   This program is distributed in the hope that it will be useful,
  10. #   but WITHOUT ANY WARRANTY; without even the implied warranty of
  11. #   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  12. #   GNU General Public License for more details.
  13. #
  14. #   You should have received a copy of the GNU General Public License
  15. #   along with this program; if not, write to the Free Software
  16. #   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  17. #
  18. # This is an example configuration file for the IRC server
  19. # You only need an ircd.conf (IRC server configuration file) if you are
  20. # running an IRC server. If you are running a standalone client this file
  21. # is not necessary.
  22. #
  23. # This file will explain the various lines in the IRC server
  24. # configuration file. Not all lines are mandatory. You can check to make
  25. # sure that your configuration file is correct by using the program
  26. # "chkconf", provided in the server distribution (and when you do "make
  27. # install" this program will be installed in the same directory as the irc
  28. # server). 
  29. # The options for whether a line is needed or not are: 
  30. # MANDATORY: you absolutely MUST have this line
  31. # NETWORKED: you must have this line if you are connecting this irc
  32. #            server to any other server (servers can run standalone).
  33. # SUGGESTED: it is highly suggested that you use this line
  34. # OPTIONAL: it's completely up to you whether to define this or not
  35. # DISCOURAGED: you really really should not use this line if at all
  36. #              possible. 
  37. # NOT NECESSARY: an old or out of date line that isn't needed.
  38. #
  39. # MANDATORY lines are absolute *musts*, that is, if you do not have this
  40. # line then your server will not work properly. SUGGESTED lines are
  41. # close-to-mandatory (that is, the server will run without it, but you are
  42. # highly encouraged to use these lines).
  43. #
  44. # Note that "*" in a field indicates an "unused" field.
  45. #
  46. #
  47. # ========================================================================
  48. # NOTE! this entire configuration file is read UPSIDE-DOWN! So if you have
  49. # to put something in a specific order (for example, client-connection
  50. # lines), put them in reverse order!
  51. # ========================================================================
  52. #
  53. #
  54. # M: [MANDATORY]. This line sets your server's name, description, and
  55. # port number. Fields, in order, are: 
  56. #
  57. # M:hostname:*:Description Of Your Server:6667
  58. #
  59. M:csa.bu.edu:*:Boston University Computer Science Department:6667
  60. #
  61. # A: [MANDATORY]. This line lists your administrative information
  62. # (contact address, etc). To view this information, /admin (server) will
  63. # show it to you.
  64. #
  65. # The A: line has no set information, in fact, you can put arbitrary text
  66. # in there if you wish (it is encouraged that you put at *least* a contact
  67. # address for a person responsible for the irc server, however)
  68. #
  69. A:Boston University CS Department:Main Client Server:Helen Rose <hrose@cs.bu.edu>
  70. #
  71. # Y: [SUGGESTED]. These lines define connection classes. Connection
  72. # classes allow you to fine-tune your client and server connections. It is
  73. # suggested that clients and servers be placed in seperate classes, and if
  74. # you have lots of server connections (if you do have lots of servers you
  75. # shouldn't be reading this file :-) each set of servers (defined
  76. # arbitrarily by you) should have its own class. If you have clients
  77. # coming in from lots of different sites, you may want to seperate them
  78. # out into classes. For instance, you may want to put local users in one
  79. # class, with remote users in another class.
  80. #
  81. # The class numbers are not arbitrary. In auto-connecting servers -- that
  82. # is, servers that you have a port number (e.g. 6667) on the end of the C:
  83. # line (see below) the higher the number the higher the priority in
  84. # auto-connecting.
  85. #
  86. # The fields in order are: class number, ping frequency (in seconds),
  87. # connect frequency (in seconds), maximum number of links (used for
  88. # auto-connecting, and for limiting the number of clients in that class),
  89. # and sendq (this overrides any value set in include/config.h for #define
  90. # MAXSENDQLENGTH).
  91. #
  92. # Note that it is a good idea to have ping frequency the same at both ends
  93. # of the link.
  94. # in this case, connect-frequency is 0 indicating that this is a client
  95. # class (servers never connect to clients, it is the other way around).
  96. Y:1:90:0:20:100000
  97. #
  98. # this is a normal server connection (normal as of March, 1994)
  99. Y:2:90:300:1:600000
  100. #
  101. Y:10:90:0:3:100000
  102. #
  103. # I: [MANDATORY]. The I: lines are client-authorization lines. Without
  104. # these lines, no clients will be able to connect to your server.
  105. # Wildcards ("*") are permitted. Passwords are also permitted (clients can
  106. # be configured to send passwords).
  107. # Ident (for more information on this, see rfc1413) can also be used by
  108. # placing a @ in the appropriate fields.
  109. #
  110. # Fields are as follows:
  111. # I:IP-address-mask:optional password:domain-mask::connection class (opt)
  112. #
  113. # With a password..... This will allow anyone from anywhere to connect
  114. # as long as they know the password ("foobar"). Note listing this I: line
  115. # first, it will be read *last*, meaning it is the "fall-through". That
  116. # is, anyone who doesn't match the I: lines listed below must know the
  117. # password ("foobar") to connect.
  118. #
  119. I:*@*:foobar:*@*::1
  120. # This is a standard vanilla I: line which will permit anyone with an IP
  121. # address starting with 128.197 OR with a hostname ending in .bu.edu to
  122. # connect to the server. NOTE, the ircd matches on the *right-most* match,
  123. # so if I connect as hrose@csa.bu.edu (which is hrose@128.197.10.3) I will
  124. # show up on irc as hrose@csa.bu.edu since that is the first match it
  125. # found. (Even though the second match is valid).
  126. I:128.197.*::*.bu.edu::1
  127. # using ident
  128. I:*@128.197.*::*@*.bu.edu::1
  129. # and you can even specify just certain usernames running ident (as long
  130. # as the client's site is running the ident daemon):
  131. I:NOMATCH::hrose@csa.bu.edu::1
  132. # putting NOMATCH in the first field will stop the ircd from matching
  133. # automatically against the IP address and it will force the server to
  134. # match against the hostname. (the "NOMATCH" string is not mandatory, you
  135. # can use any arbitrary text in the first field).
  136. #
  137. # O: [OPTIONAL]. These lines define operator access. You do not need to
  138. # have an operator to run a server. A well configured leaf site should not
  139. # need an operator online, if it's connections are well defined, the irc
  140. # administrator can use kill -HUP on the ircd to reload the configuration
  141. # file. 
  142. # The fields are as follows:
  143. # O:hostname (ident "@" permitted):password:NickName
  144. # if the person in "NickName" is not coming from the hostname defined in
  145. # the first field then the person will get the error message "No O: lines
  146. # for your host". 
  147. # NOTE that since Crypted Passwords are defined by default in
  148. # include/config.h this text probably will not be plaintext. See
  149. # ircd/crypt/README for more information.
  150. #
  151. O:*.bu.edu:Zaphod:Trillian::10
  152. #
  153. # and this line forces ident:
  154. O:hrose@csa.bu.edu:Zaphod:Trillian::10
  155. # This line is a "local operator", it is specified with a lower-case "o"
  156. # -- it is the only lower-case type in the ircd.conf file.
  157. #
  158. # this line permits the nickname "jhs" with the password of "ITBites" to
  159. # be a local operator only (be able to issue commands locally -- can /kill
  160. # and /squit and /connect -- but *only* locally)
  161. #
  162. o:*.bu.edu:ITBites:jhs::10
  163. #
  164. # a crypted password line (NOTE that if you have crypted passwords, *all*
  165. # of you passwords must be crypted! In fact, if you are getting an error
  166. # "Incorrect Password" it may well be because crypted passwords are
  167. # defined and you have used plaintext.  So my example of plaintext and
  168. # crypted strings in the same IRC server configuration file is an
  169. # impossibility (but it is just theoretical, which is why I explained both).
  170. #
  171. O:rocker@csa.bu.edu:T0eiVgHrqeKTQ:Rocker::10
  172. #
  173. # U: [NOT NECESSARY]. This line defines the default server for the IRC
  174. # client that ships with the server -- the default client is in irc/irc
  175. # You should not use U: lines but instead use the UPHOST definition in
  176. # include/config.h 
  177. U:csa.bu.edu:foobar:csa.bu.edu
  178. #
  179. # C: [NETWORKED]. These lines define what servers your server tries to
  180. # connect to. 
  181. # N: [NETWORKED]. These lines define what servers your server permits
  182. # connections to be initiated from. 
  183. # C/N lines MUST be used in pairs. You cannot have one without the other. 
  184. #
  185. # C: lines contain the following fields:
  186. # C:remote server's hostname:passwd:remote server's name:port:conn class
  187. # (connection class)
  188. # N: lines contain the following fields:
  189. # N:remote server's hostname:passwd:remote server's name:host mask:conn class
  190. # (connection class)
  191. # "host mask" is the number of parts in *your* hostname to mask to. For
  192. # instance, with my servername being "csa.bu.edu", if I wanted to present
  193. # my servername to be "*.bu.edu" I would have a host-mask portion of "1". 
  194. #
  195. # it is *strongly* advised that your C/N line passwords be different for
  196. # security's sake.
  197. #
  198. # ident is allowed in the server's hostname part of the field.
  199. # these lines tell the server to automatically (note the port number, that
  200. # means automatic connection) connect to cs-ftp.bu.edu:
  201. C:hrose@cs-ftp.bu.edu:bigspark:cs-ftp.bu.edu:6667:2
  202. N:hrose@cs-ftp.bu.edu:bigalpha:cs-ftp.bu.edu::2
  203. #
  204. # This server's connection lines are more vanilla, masking the host to
  205. # *.bu.edu (as described above):
  206. C:irc-2.mit.edu:camelsrk00l:irc-2.mit.edu::2
  207. N:irc-2.mit.edu:andsoarellamas:irc-2.mit.edu:1:2
  208. #
  209. # K: [OPTIONAL]. These lines define user@host patterns to be banned from
  210. # this particular server (with an optional time field). Note that K: lines
  211. # are *not* global, and if you ban a user they can still use any other IRC
  212. # server (unless they have specifically been banned there as well).
  213. # the fields are defined as:
  214. # K:hostmask:time field:username
  215. # wildcards are permitted in any one of the fields, in other words, you can
  216. # K:*::* if you wanted (but your server wouldn't be used much ;-)
  217. #
  218. # This K: line bans the username "FSSPR" (the wildcards are used to make
  219. # sure that any ident-checking character will match) on any machine from
  220. # the University of Alaska.
  221. K:*.alaska.edu::*FSSPR*
  222. #
  223. # This K: line bans any users from acs*.bu.edu between the hours of 8am
  224. # and 12pm and 1pm and 5pm (the time is always the server's local time):
  225. K:acs*.bu.edu:0800-1200,1300-1700:*
  226. # Note that 24 hour time is used (no "AM" or "PM").
  227. #
  228. # R: [DISCOURAGED]. These lines restrict user access based on a more
  229. # stringent checking system than is available in the K: line. It looks for
  230. # a match (based on hostname and username) and then runs an outside
  231. # program (which MUST be specified using a full pathname). The output of
  232. # the program should be a string in the form "Y <message>" (which permits
  233. # access for the user) or "N <message>" (which denies access for the
  234. # user). If "Y <message>" is received by the server, the server ignores
  235. # the message and permits access for the user. If "N <message>" is
  236. # returned, the server tells the user that he/she is not permitted to
  237. # access that irc server, and gives the reason.
  238. #
  239. # Again, like K: lines, R: lines are local and thus not very effective in
  240. # blocking certain machines from having IRC access.
  241. #
  242. # Use of R: requires that you have defined R_LINES in include/config.h
  243. #
  244. # The fields are as follows:
  245. # R:hostmask:/full/path/to/program:username
  246. # you can use wildcards in either the hostmask or username portion
  247. #
  248. R:csl.bu.edu:/home/hrose/bin.sun3/sun3access:*
  249. #
  250. # Q: [DISCOURAGED]. These lines "quarantine" specified servers.  Because
  251. # of the way they operates, the same Q: lines MUST be installed by
  252. # everyone or the net will keep breaking. I CANNOT EMPHASIZE THIS ENOUGH.
  253. # Do NOT use Q: lines lightly!
  254. #
  255. # The fields are as follows:
  256. # Q:*:reason why quarantine is in place:servername
  257. #
  258. Q::this server is too slow and lags the net:cm5.eng.umd.edu
  259. #
  260. # L: [OPTIONAL]. These lines "Leaf" specified servers. They are only
  261. # useful if you are a non-leaf site yourself. There are two ways you can
  262. # use L: lines. The first will limit one particular site to a particular
  263. # tree depth (including 0, which would mean the server has to connect with
  264. # no servers linked behind it otherwise the connection will fail). The
  265. # second will allow you to be selective about which other servers you wish
  266. # the connecting server to behave as a leaf towards.
  267. #
  268. # The fields are as follows:
  269. # L:disallow connections to this hostmask::server name:depth
  270. # For example, this will force kaja.gi.alaska.edu to connect only as a
  271. # leaf (if it is not a leaf, the link will be dropped):
  272. L:::kaja.gi.alaska.edu
  273. # This line will force cm5.eng.umd.edu to have a depth of only 1 below it
  274. # (that is, it is allowed to have only leaves connected to it):
  275. L:::cm5.eng.umd.edu:1
  276. #
  277. # This line will prohibit anything matching *.edu to be connected behind
  278. # any server matching *.au:
  279. L:*.edu::*.au
  280. #
  281. # H: [OPTIONAL]. These lines define who you permit to act as a "hub" to
  282. # you (that is, who you permit to connect non-leafed servers to you).
  283. #
  284. # the first field may use wildcards, the third field *must* be an exact
  285. # match for a server's name (NOT a server's hostname, if they differ, the
  286. # server's name must be used). If the servername is a wildcard (e.g. *.au)
  287. # that is an acceptable name for the third field. 
  288. #
  289. # The fields are as follows:
  290. # H:servers which are permitted entry::hub server
  291. #
  292. # Example, permit cs-ftp.bu.edu to allow any servers behind it to connect:
  293. H:*::cs-ftp.bu.edu
  294. #
  295. # Example, permit irc-2.mit.edu to allow any MIT servers behind it to
  296. # connect: 
  297. H:*.mit.edu::irc-2.mit.edu
  298. #
  299. # P: [OPTIONAL]. This field allows the server to listen on various ports
  300. # (other than 6667) for connections. Any internet domain port that is
  301. # below 1024 means the ircd has to be run from inetd. The server can
  302. # listen to ports in the UNIX domain or the internet domain. If you wish
  303. # to create a port in the UNIX domain you must compile with UNIXPORT
  304. # defined in include/config.h. If you are permitting connections to a
  305. # seperate port, you can control access to that port by the host field.
  306. #
  307. # The fields are as follows::
  308. # P:hostmask or UNIX socket file:*:*:port number
  309. # for example, an internet domain socket on port 6665 for South African
  310. # users: 
  311. P:*.za:*:*:6665
  312. #
  313. # This line is an example of a UNIX domain socket in /tmp
  314. P:/tmp/.ircd:*:*:6666
  315.