           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/

	or at the Services home page:

	http://achurch.dragonfire.net/services/


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, unless you can find someone to support it for you.


4. How about OS/2?

	You may have better luck there; as of version 4.0, Services tries
	to be compilable on OS/2 through patches and suggestions from
	others.  I've never tested it, though (I don't use OS/2).


5. 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.


6. There is no question number 6.


7. When I run "make", I get an error message like "make: missing separator".

	You need a make program which supports the "include" and "ifdef"
	directives.  GNU make is such a program, and may be obtained from
	ftp://prep.ai.mit.edu/pub/gnu/.  Note that GNU make may already be
	installed on your system; try using the command "gmake" instead of
	"make".

	The make programs bundled with SunOS/Solaris and FreeBSD have been
	reported not to work; you will need to use GNU make on these
	systems.

8. 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 has also been reported to
	work with Services; support has been added in Servicse 4.0 for
	ircu 2.10.x, but has not been tested.  Support is also present for
	base irc2.x distributions (with or without the TS8 addition), but
	also has not been extensively tested.  See the README for more
	information.

	As always, you can check the log file (services.log by default) for
	error messages.


9. I need support for the XYZ protocol.

	Tough luck, unless you want to write support for it yourself.  See
	the previous answer.  (Alternatively, I may consider adding or
	extending support for a protocol if I am given a complete RFC-style
	description of the protocol, but even then it depends on how common
	and useful (compared to the protocols already present) I perceive
	that protocol to be.)


10. 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.


11. 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.


12. 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.


13. 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.

	  - DON'T run in debug mode!

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


14. 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 8 for details.


15. Services crashed with a segmentation fault.

	It does that sometimes.  I don't know why (or I'd've fixed it).
	Live with it, unless you can fix it yourself.  crontabs are useful
	for dealing with this.


16. Services' channel mode setting doesn't work.  I can't set modes with
    OperServ, and every time ChanServ 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

	As of version 4.0, Services will report this in a WALLOPS or
	GLOBOPS message the first time it discovers it cannot change modes.


17. 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 (and possibly others), 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


18. I can't use the ADMIN command to add Services admins--it tells me
    "Permission denied."

	Did you define yourself as the Services root in config.h?  (The
	#define is SERVICES_ROOT.  Yes, this will go into configure
	someday.)


19. When I add an AKILL, the users matching it don't get killed.

	1) Did you include a nick in the mask?  If you did, DON'T.
	   Autokill masks must not include nicks; Services will consider
	   *!*@host.name to be "a username containing !", not "any nick and
	   any username".

	2) Services does not kill users when an autokill is added; it only
	   kills them when they next connect.  This is designed behavior,
	   intended to reduce the possibility of a mistyped autokill
	   getting the wrong users.  (Suppose you typed "AKILL ADD *@*" and
	   then accidentally hit Return before finishing the host mask...)


20. When I link nicks, the URL and E-mail fields aren't copied.

	This is designed behavior (though it may be changed in a future
	version).


97. Services spracht nicht Deutsch!, etc.  (Services doesn't speak my
    language!)

	If you would like to supply a new language module for Services,
	take a look at lang/en_us.l, which is the language module for
	English, as well as the comments at the top of lang/langcomp.c,
	which describe the language module file format.  If/when you have
	completed a module for your language, E-mail it to me
	(achurch@dragonfire.net) for inclusion in Services.  However--
	warning, legal stuff follows--by sending me a language module for
	inclusion in Services, you agree to waive all copyright claims to
	that file and the text it contains.  (I will give credit, of
	course, but the copyright remains mine.)  Also, it would be very
	helpful if you would be willing to continue updating the module as
	changes are made to the base English module.

	If any British/Canadian English speakers want to make another
	version of the English language file which seems more natural to
	them, I'll take that too. (^:


98. I've found a bug that's not mentioned here or in the README or
    KnownBugs files.  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, and make sure the
	corresponding part of the log file is included.


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.  If I choose not to include it, you're always free to
	keep and/or distribute the patch yourself.

	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 in my opinion 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 most of them of no real use, and
	  supporting them would only make Services more bulky.  The same
	  applies to any new features Undernet's ircu-2.10 may have, and
	  any other servers with "nifty" features added to their protocols.

	- 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.
