           Frequently Asked Questions (FAQ) concerning Services
           ====================================================

0. What is Services?

	Services is a package of services for IRC networks.  See the README
	file for more information.


1. Where can I find Services?

	The latest version can always be found at the official Services
	distribution site:

	ftp://ftp.dragonfire.net/software/unix/irc/


2. It doesn't work on my Windows machine!

	You're very observant.  If you want to run Services, get a decent
	operating system, like Linux or FreeBSD.  Services does not and
	will not run under Windows, because I have better things to do with
	my time than port a decent program to a half-brained buggy
	operating system.


3. But I like Windows!

	Tough luck.


4. Can I send you questions without reading the FAQ or README files?

	Sure you can.  It's one of the easiest ways I know to get your
	messages ignored.


5. When I try to run "make", it says something like "make: missing
   separator" or another error message before it gets to compiling
   anything.

	You need a make program which supports the "include" directive.
	GNU make is such a program.


6. There is no question number 6.


7. I typed "./services" at the command line, but nothing happened!

	Services puts itself in the background when it starts, so you get
	your shell prompt right back.  Meanwhile, Services will continue
	setting up, then connect to the IRC server specified in config.h
	(or on the command line).  If it doesn't connect, you probably
	specified the wrong server type when running the configure script.
	(Also make sure that you are actually running one of the supported
	servers.  There are a gazillion different variations on the basic
	IRC protocol out there, and I have neither the time nor the desire
	to add support for them.)  The recommended server, under which
	Services has been developed, is DALnet 4.4.x (x < 15); version
	4.4.10 of that server is also present at the official Services
	distribution site.  The Undernet server (before version 2.10) has
	also been reported to work with Services.  Support is present for
	base irc2.x distributions (with or without the TS8 addition), but
	has not been extensively tested.  See the README for more
	information.


7.5. I need support for the XYZ protocol.

	Tough luck, unless you want to write support for it yourself.  See
	above.


8. Whenever I start Services, I get a message on my IRC server saying
   "connection refused" or something similar.

	You need to configure your IRC server to accept Services as an IRC
	server.  For most IRC servers (those based on the irc2.x
	distribution), that involves adding two lines like the following to
	your ircd.conf file:

	C:127.0.0.1:password:services.whatever.net::99
	N:127.0.0.1:password:services.whatever.net::99

	See the example ircd.conf provided with most distributions for the
	meaning of each field.


8.5. My IRC server is giving me messages like "Connection to
     services.whatever.net[127.0.0.1] activated" and then "Access denied --
     no N line".  Why?

	This is typically caused by including a port number in the C:line
	for Services, which tells your server to try to autoconnect to it
	(depending on the class (Y:line) settings).  This is not what you
	want, because Services will connect to the server itself, but does
	not listen for servers to connect to it.  The solution is to remove
	the port number from the C:line.


9. Services always dies after about five minutes, saying "FATAL ERROR!
   Can't back up nick.db".

	Make sure that the user Services runs as has write access to the
	data directory, and that the data directory actually exists (the
	latter shouldn't be a problem if you ran the configure script).
	This means Services needs write and execute permission on the data
	directory itself and execute permission on every parent directory
	of the data directory.


10. Services starts up okay, but if I try to register a nickname, it comes
    back with "Sorry, registration failed."

	Make sure you've selected the correct IRC server type in the
	configure script; see question 7 for details.


11. None of the online help works--everything I try comes back with "No
    help available for XYZ."

	You need to install the Services help files; use the command
	"make install-help".


12. Services crashed with a segmentation fault.

	It does that sometimes.  I don't know why.  Live with it, unless
	you can fix it.  crontabs are useful for dealing with this.


13. Services' channel mode setting doesn't work.  Every time it tries to
    set a mode, my server reverses the change.

	If you're running the DALnet (and maybe Undernet) daemon, make
	sure EVERY server on your network has a U: line for Services in
	ircd.conf, for example:

	U:*::services.whatever.net


14. Using the OperServ JUPE command results in server messages like
    "Server juped.server introduced by non-hub server services.my.net".

	In all irc2.x-derived IRC servers, every server on the network must
	have an H: line for Services in the ircd.conf file, which looks
	something like:

	H:*::services.whatever.net


15. Using the XYZ OperServ command (e.g. UPDATE) says "unknown command",
    but I can get help on it just fine!

	Several OperServ commands are limited to Services admins.  If you
	are not either the Services root (see config.h) or a Services
	admin, or you have not identified to NickServ, you will not be able
	to use those commands.


16. Services can't keep up with my network--it eventually falls off with
    "Max SendQ exceeded".  What can I do about this?

	If you have a really large network (tens of thousands of
	simultaneous users), Services in its default configuration may not
	be able to keep up with all the network traffic.  Here are some
	possible ways to speed Services up:

	  - Disable clone detection by undefining CHECK_CLONES in config.h.

	  - Reduce the nickname and channel expiration periods.

	  - Increase EXPIRE_TIMEOUT in config.h to reduce the frequency of
	    checking for nickname and channel expiration.

	  - Increase UPDATE_TIMEOUT in config.h, but beware that this will
	    mean more potential data loss if/when Services falls off your
	    network or crashes.

	Services is known to be functional on networks as large as 4000
	simultaneous users (with 60,000 registered nicks).


98. I've found a bug that's not mentioned here or in the README.  What
    should I do?

	Send a report of the bug with as many details as possible to
	achurch@dragonfire.net.  Even if something seems obvious to you,
	like what you think Services should be doing that it isn't, mention
	it anyway, because what seems obvious to you may not be obvious to
	me.  Include in any case a copy of or excerpt from the Services log
	file, usually "services.log" in the Services data directory,
	  **** generated with the "-debug" command-line option, ****
	which includes a demonstration of the bug.  (This is important!)
	If the bug occurs in response to something you do (like sending a
	ChanServ command), also send the sequence of steps necessary to
	reproduce the bug, preferably starting with nickname or channel
	registration if NickServ or ChanServ is involved.


98.5. Your Services program doesn't do XYZ like DALnet Services.  What's
      wrong?

	Nothing is wrong, except your expectations.  Services is a
	completely different program from that used on DALnet; they are
	similar in concept only.


99. I've got a great new idea for Services.  Do you want it?

	I'm always interested in hearing new ideas.  HOWEVER, I have very
	specific plans for what to include and not to include in Services.
	As a rule, I don't add anything that can be equivalently done by
	other means, or that I don't consider useful.  For example, several
	people have suggested adding a function to ChanServ to always keep
	a channel open (i.e. always keep a pseudo-client in the channel);
	that's something I have no intention of adding, as (1) it is
	unnecessary in the face of Services' channel privilege functions
	and (2) it can be just as easily achieved using a standard bot.
	If you have actually added something to Services you think would be
	useful to include in the standard distribution, feel free to send a
	context or unified diff along with (but not instead of!) your
	description.

	My general intent is for Services to provide as much functionality
	as possible--while staying as lean as possible (as opposed to, say,
	recent versions of Microsoft Word, which provide so much
	functionality you can't do anything).  So features which are
	arguably beneficial will tend to be added, while features of
	limited or no benefit or which can be equally provided by something
	else already in use will tend to be passed over.


99.5. Other examples of features I have been asked about and why I won't
      add (or haven't yet added) them--so don't ask me about them:

	- A "kill" feature for Services' clone detection:  This would be a
	  Very Bad Idea, because it's really easy to fool the clone
	  detector.  Example: a server run by an ISP splits and reconnects
	  to the network, bringing on a dozen or more users from the same
	  shell machine.  That looks like clones to Services.  Or someone
	  could, from said shell machine, launch a bunch of clones and get
	  everyone else on that machine kicked off.

	- The various features of DALnet's ircd since version 4.4.15:
	  Unlikely at best.  I consider virtually all of them of no real
	  use, and supporting them would only make Services more bulky.

	- A "current time" field in NickServ and ChanServ INFO displays:
	  Most people have clocks of some sort either on their computer
	  screens or on their walls (or both), and all IRC servers, as well
	  as Services, have a command to return the server's current time.
	  Thus a current-time field in INFO displays would simply take up
	  extra space for no reason.
