OpenNap-NG 0.49 Reference Manual
Author: Dr. Scholl, Khaytsus, Jondo
Description: Opennap-NG 0.47 reference manual
Keywords: opennap, manual, config, reference, documentation, napster, variables, jondo
Date: 2003-01-21

# OpenNap-NG Reference Manual

### Version 0.49.1

March 2005

## Table of Contents

- Introduction
- Features
- System requirements
- Getting Opennap NG software
- Quick start (if binaries are availble)
- Compiling (creating the binaries, for Unix users)
- Files
  - opennap-bans.txt
  - opennap-block.txt
  - opennap-block-ban.txt
  - opennap-channels.txt
  - opennap-config.txt
    - Changed variables
    - Detailed list of variables
  - opennap-filter.txt
  - opennap-motd.txt
  - opennap-servers.txt
  - opennap-user.txt
- Administration
  - ChanServ
  - NickServ
  - OperServ
- User levels
- Clients
- Glossary

## Introduction

Originally, Napster was a distributed file sharing service which allowed users to transfer files directly between their clients for free. A centralized server kept track of all available files and provided clients the ability to search the index of available files. In addition, instant messages (private chat) and group chat services similar to IRC were also provided.
OpenNap is a free Open Source effort to create a version of the proprietary Napster server. We want to express our thanx here to drscholl, who made an excellent job of programming.
OpenNap-NG is the new generation of Opennap, after drscholl had ceased to develop any further. Many new features and bugfixes have been included.
Opennap NG 0.49 is the latest development efforts from early 2005 to keep the spirit alive.
Note that Opennap NG 0.49 is not a direct successor of previous versions 0.47 and 0.47.2! It's another branch from 0.46 instead, including lot more bug fixes and feature extensions than the 0.47.2 branch. New features marked as "new since NG 0.46" (in config variables section) are not contained in 0.47.2!
We would gladly welcome everyone who also has got new ideas and wants to participate in this project. We also want to announce that we want to merge this fork of opennap with drscholls as soon as he reappears. The main goal is a common codebase. The most current version of this document can be obtained here.

## Features

- Free and open source server software for clients like Lopster / WinLop, XNap, WinMX, AudioGnome and others.
- Supports all features of the original Napster filesharing protocol (filesharing, public and private chats, user levels, blocks, filters, bans) + some custom extensions
- Supports both chat + filesharing and chat-only server operation
- Multiple servers may link together to form networks with yet more users
- Available for multiple platforms, including Linux and Windows
- Small and compact C binary (<300 KB) with no further dependancies, fast execution (little CPU consumption)
- More than 120 adjustable configuration parameters
- Entirely remotely administratable via clients
- Support for GotNap advertising
- Static and dynamic server IP addresses are supported.
- Protects privacy of your users, as no private data (chats, searches, file transfers) of your clients is made visible to others or being logged
- Multilingual graphical configuration tool

## System requirements

General: |  | A computer with reasonable amount of RAM (see below) and an internet connection. Machine availability, including internet connection, of 24h / day is preferred but not required. A flatrate connection to the internet with unlimited (or inexpensive) data transfer volume is recommended.
Operating systems: |  | Precompiled binary versions are available for Linux x86 and Windows. Versions for many other Unices can be created by compiling the sources yourself. We learned that Opennap NG 0.49 compiles and probably also runs fine on FreeBSD and Solaris, however we currently can't support it directly. Recommended minimum Linux kernel version is 2.2. Linux 2.4 or later is required if a server is to serve more than 1000 users. Windows NT, 2K or XP (any editions) should be used for stable server operation. Windows 95, 98 and ME are known not to support server operations very well at all.
CPU: |  | CPU speed is important when it comes to serve file searches and transfer requests for a large number of users. For a standard filesharing Opennap NG server the rule of thumb for x86-compatible CPUs is that every 500 MHz allow you to serve 1000 users. That is, if you have a 2 GHz machine, you should be able (in theory) to serve 4000 users without noteworthy lag on one machine. For chatting only servers, with filesharing disabled, the requirements are believed to be 100 MHz or less per 1000 users.
RAM: |  | Offering filesharing services with Opennap NG is fairly RAM-consumptive. The rule of thumb is that on Linux systems 1000 files take 300 to 350 KB of RAM, while on Windows systems 1000 files take 400 to 500 KB of RAM. The difference comes from the totally different memory management concepts of those operating systems. So if you have 1 GB of RAM to spend, you should be able to handle about 3 million files on Linux and about 2 million files on Windows. For chat-only servers RAM demands are negligible.
Internet bandwidth: |  | Demands for internet bandwidth are highly variable, depending on how many users are connected, how many files are maintained, how many browse and search results per request may be returned, etc. In general, a single server with reasonable settings receives about 3 to 4 times the amount of data of what it sends. During regular operation the demands should be about 15 KB/sec. incoming and 4 KB/sec. outgoing traffic per 1000 users on a standalone server. Especially outgoing traffic can be adjusted or limited by a number of settings, such as max_results (I), max_browse_result (I), notify_exceed_frequency (I) and others. If being connected to other servers of similar capacity, traffic demands can easily be doubled or tripled, due to state and request exchanges with other servers. During initial fillup phase, shortly after a server has been started, almost all availabe bandwidth could be consumed by incoming filelists of newly connecting users. Not having enough bandwidth may just cause some lag for up to half an hour after server restart, but doesn't essentially limit your serving capacity. Opennap NG offers multiple means to throttle initial server fillup, to reduce or prevent lag.
Harddisk: |  | Opennap NG basically operates completely RAM-based. The harddisk is only used to load the server program and occasionally dump updated user and ban lists. All of that should fit well within 1 MB of harddisk space. If you decide to store the log output of Opennap NG for later analysis you should reserve some spare MBs of harddisk space, depending on the level of activity on your server and the verbosity of your log output. Windows users who want to use the GUI config tool need to consider disk space requirements of GTK+ as well, which, if not already being installed, requires another 20 MB.
Additional software requirements: |  | Server operation: no additional software besides standard libraries is required. libz may be the least common of them, especially on some Windows installations. No X windows is required to run the Opennap NG server itself on Unix. The GUI config tool isn't required either to run the server. Build process: Opennap NG 0.49 requires GCC >= 3.x (GNU Compiler Collection), a portable and efficient programmer's toolset available for free at http://www.gnu.org/ (for Unix) and http://www.mingw.org/ (for Windows). Other, proprietary or commercial compilers are not supported at this time. Important: currently Opennap NG 0.49 doesn't compile under GCC 2.95.x or earlier due to a compiler bug (for programmers: the compiler erroneously "forgets" the typedef socklen_t in main.c, starting near line 1166, causing compile errors later in that file). No compiler is required if you just use one of the available precompiled binary packages. GUI configuration tool: The GUI configuration tool requires the Gimp Toolkit (GTK+) 2.x. It's available for free at http://www.gtk.org/download (sources, mainly for Linux / Unix users) and http://gimp-win.sourceforge.net/old.html (binaries for Windows users). Only the GTK+ Runtime version is needed, the GTK+ Development version is not needed. X-windows server: As a GUI application, on Unix / Linux systems the config tool obviously requires an installed X windows server system as well

## Getting Opennap NG software

The homepage and main location to obtain sourcecode and precompiled binary versions of Opennap NG in many flavours from is http://opennap-ng.sourceforge.net.
Via CVS you can also obtain various older (and possibly newer) versions. To get the newest CVS version try this:

- `cvs -d:pserver:anonymous@cvs.opennap-ng.sourceforge.net:/cvsroot/opennap-ng login`
  for the password press return
- `cvs -z3 -d:pserver:anonymous@cvs.opennap-ng.sourceforge.net:/cvsroot/opennap-ng co [modulename]`
  modulname is opennap-ng-0.xx

for updating only type in the Opennap NG directory

- cvs -z3 update -Pd

## Quick start

Advice: before starting your own server you should be familiar with using client software. You should have been connecting to other existing servers and networks to gain some basic understanding about the features provided by the Napster protocol. See http://www.gotnap.com for a list of existing, free servers using the Napster protocol.
After installation of the binary files, before first server start:

1. Set up `opennap-config.txt`!
   It's mandatory you adjust at least some variables in the config file, either using the config tool (preferred way) or via any text editor! Especially variables from the Napigator (GotNap) support and network groups should be set accordingly, namely `server_name`, `server_ports`, `report_name`, `report_port`, `stat_server_user` and `stat_server_pass`. You can adjust other variables later, as you learn about their meanings.
2. Set up your Elite user account!
   Initially the userbase contains just one elite user account named Elite with the password `elite`. Nick and password must be changed prior to launching the server for the first time. Otherwise you'll be experiencing a severe security hazard!
   - For Unix users the script `init-userdb.sh` (in subdirectory `doc/scripts/`) is provided. It allows to create an arbitrary number of elite and other accounts from scratch. The script requires Bash 2.0 or later. Like Windows users, Unix users can also edit the sample file `opennap-users.txt` with any text editor as described next.
   - Windows users need to edit the installed file `opennap-users.txt` with a texteditor of their choice, i.e. Notepad. The file should start with the two words "Elite" and "elite". The first one is the nick, the second one is the password. Change the 1st word "Elite" to your desired nick. Change the 2nd word "elite" to your desired password. Then save and exit.
   Note that after the first start of Opennap NG the passwords will be encrypted and stored encrypted. Plaintext passwords won't be kept or stored by the server at all! After the first server start you must not reedit the password fields of the `opennap-users.txt` file! To change passwords afterwards, start the server, connect with your client (i.e. Lopster, Xnap or WinMX) to it using your elite nick. Then use the client-specific facility to change the password. I.e. in Lopster this is the /pass command, in TekNap it is the /setpassword command. Please check the documentation of your client to see how password changes are carried out.
3. Set up your network, firewall, etc.
   Make sure the configured server port (default: 8888) is open (not firewalled) on your computer. If you are connected to the internet via a router or gateway, make sure the server port is properly forwarded. Your server port must be reachable from the outside world. Otherwise no users from the outside world will be able to connect to your server.
4. Start
   You may then start the server. Note, on Linux / Unix the default data directory is `/usr/share/opennap-ng/` (others can be chosen by using `-c` switch at command line). On Windows it's the current directory. However, start menu entries and desktop icons on Windows are configured to switch to the directory in which Opennap NG was installed prior to launching it, so there's nothing more to care about.

## Compiling the server

These instructions describe building (compiling) Opennap NG the Unix way, which currently is the only supported way. The suggested tool for building Opennap NG natively under Windows is MinGW (Minimalist GNU for Windows, http://www.mingw.org), an open source and free compiler and tools set which bases on common development tools of the Unix world. Since using MinGW requires skills in Unix usage and Unix utilities, which the average Windows user (even many developers) doesn't have, Windows users are encouraged to use the binary package of Opennap NG instead. Currently no in-depth instructions for how to build Opennap NG on Windows are available.

### Unix Platforms

After you have unpacked the source, or obtained the CVS version, run the provided configure script. The following configure options are of note:

`--` | `enable-email` Enables support for storing the email addresses of users obtained from the nickname registration command. By default this information is not kept and the server will always return unknown if this information is requested. Note that sane users don't enter correct email addresses nowadays so this feature is generally of little use.
`--` | `enable-resume` Enables the server-side support for resuming downloads. This option makes the server use more memory because it has to store to MD5 hash values for all shared files in addition to the other information. Note that most clients don't support this feature so it is generally of little use.
`--` | `enable-router` Compiles a routing-only version of the OpenNap-NG server. This disables the file sharing commands for local clients, only allows users of level Admin or greater to log in, and simply routes all other messages to linked servers. This is ideal for use as a hub server to connect a cluster of other servers together.
`--` | `enable-chroot` Compile support for running OpenNap-NG in a chroot() jail. This prevents the server from being able to read/write any files outside of its data directory. Useful for parnoid people. OpenNap-NG must be run setuid root (at which point it will drop privs) in order for this to work.
`--` | `enable-version-stats` Causes the server to keep a running count of each version of connecting clients. Useless, but fun information for client developers to see how much their particular clients are getting used on the server.
`--` | `with-fd-setsize=SIZE` Under BSD systems, this sets the hard maximum number of connections the server can support via the select() system call. Note: under Linux (< 2.4.x) FD_SETSIZE can not be redefined and is always 1024.
`--` | `enable-debug` Turns on debugging information to catch memory leaks and buffer overruns. This is usually not suitable for "production" environments because of the extra memory use, but good for small test servers. The more testing the more likely bugs can be squashed.
`--` | `enable-gprof` Adds the `-pg` option to `gcc` to generate profiling information suitable for digestion by `gprof`. Profiling gives a detailed output of what the server is spending its time doing so that bottlenecks can be detected and server performance can be increased.

Once you have run the configure script, simply type `make`. At this point you may wish to run `make install` to install OpenNap-NG in the default location, but this is not required for the server to run.

## Files

OpenNap NG uses several different configuration files. Typically they are stored in `/usr/local/share/opennap-ng/` for UNIX platforms, and `c:\program files\opennap-ng-0.49\` for Win32 platforms.
Important: regard the changed filenames from previous Opennap versions!
All files are plain ASCII files and may be edited or viewed using any text editor. However, changes apply only if the server gets restarted or rehashed. Some of the files are periodically overwritten by the server while it's running, so the best way is to change and save them only when the server is not running.

- opennap-bans.txt - list of server-wide bans on clients
- opennap-block.txt - list of file patterns to block
- opennap-block-ban.txt - list of file patterns causing a ban for the user who attempts to share them (not implemented as yet!)
- opennap-config.txt - main configuration file containing server options
- opennap-channels.txt - database of predefined group chat channels
- opennap-filter.txt - list of words to skip when searching/indexing files
- opennap-motd.txt - message of the day, the text shown to users when they log in
- opennap-servers.txt - database of servers to link with
- opennap-users.txt - registered users database

### opennap-bans.txt

The `bans` file contains a persistent list of server-wide bans. The server will read this upon startup, and then dump its current list when it shuts down. If you need to edit this file, you must shut down the server prior to editing it, or your changes will be lost. Each line in this file should be of the form:

    	<target> <nick> <when> "<reason>" [timeout]

where target is what is banned, nick is the user that issued the ban, when is the time at which the ban was set (in seconds since Jan 1, 1970 0:00 UTC), and reason is the reason for the ban. Optionally, timeout may be specified which gives the time at which the ban expires and should be removed. See the `sample.ban` file as a basis to start your own configuration.

### opennap-block.txt

This file contains a list of regular expressions, one per line, which are matched against every file that a client attempts to share. If a file matches any of the regular expressions, it will not be indexed by the server, hence can't be searched or returned on server browses. Entries in this file are meant to specify files which are not necessarily criminal but which should not be listed on the server. Users attempting to share files which are matched by entries of this file won't be harmed any further.
If notify_mod_block is set to on then Mods+ will receive a notification for every blocked file a user tries to share. If notify_user_block is set to on then the user who tries to share the blocked file will be informed about its rejection as well. The file is just silently ignored. Empty lines and lines that begin with a hash (#) are considered to be a comment, and are ignored. See the `sample.block` file as a basis to start your own configuration.

### opennap-block-ban.txt

This file / feature is not implemented yet, planned for version 0.50!
This file contains a list of regular expressions, one per line, which are matched against every file that a client attempts to share. If a file matches any of the regular expressions, the client will be killed and banned immediately! So the entries of this file should specify files which are to be considered criminal, i.e. attempting to share them results in immediate ejection and ban! Therefore, it's recommended to take great care and use rather specific expressions only for this file. Otherwise, a lot of innocent users could be banned. Empty lines and lines that begin with a hash (#) are considered to be a comment, and are ignored. See the `sample.block` file as a basis to start your own configuration.

###

### opennap-config.txt

The main configuration file of Opennap NG. Consists of numerous configuration variables, one per line. The form is: var value Each of the values is a string, boolean, integer or list, depending on the variable. Empty lines or lines beginning with a "#" are treated as comments. The configuration variables are typed as follows. (B) = boolean, (I) = integer, (S) = string variable. Booleans can take the values "on" / "1" or "off" / "0".

chat control: irc_channels (B) max_channel_length (I) max_topic (I) max_user_channels (I) strict_channels (B) content management: allow_share (B) ascii_filenames (B) eject_limit_files (I) eject_limit_libsize (I) fix_xnap_path (I) index_ignore_suffix (B) index_path_depth (I) leech_share (B) max_shared (I) min_file_size (I) flood protection: break_mx_queue (B) evaluate_search_abuse_after_secs (I) evaluate_search_abuse_after_tags (I) file_count_threshold (I) flood_commands (I) flood_time (I) ibl_ttl (I) login_interval (I) login_timeout (I) max_clones (I) max_command_length (I) max_searches_per_minute (I) max_tags_per_minute (I) max_whois_ban_ttl (I) max_whois_count (I) max_whois_time (I) register_interval (I log verbosity: critical_delay (I) log_blocked (B) log_channel (B) log_ignore_abuse (I) log_mode (B) log_level (I) log_stdout (B) log_timefmt (S) loopcount_output_interval (I) stat_click (I) verbose_too_many (B) |  | mod+ notification: no_mod_annoying (B) notify_mod_abuse (B) notify_mod_abuse_frequency (I) notify_mod_block (I) Napigator (GotNap) support: report_ip (S) report_name (S) report_port (S) server_alias (S) stats_port (I) stat_server_host (S) stat_server_pass (S) stat_server_port (I) stat_server_user (S) network: auto_link (B) listen_address (S) max_time_delta (I) min_read (I) ping_interval (I) search_timeout (I) server_name (S) server_ports (S) server_queue_length (I) warn_time_delta (I performance: client_queue_length (I) compression_level (I) max_browse_result (I) max_connections (I) max_hotlist (I) max_ignore (I) max_new_users_count (I) max_new_users_time (I) max_reason (I) max_results (I) max_searches_pending (I) max_uploading (I) remote_browse (B) search_max_cache_entries (I) server_chunk (I) |  | security: cloak_user_level (I) level_to_set_flags (I) no_share_level (I) protnet (S) remote_config (B) set_server_nicks (S) user_db_interval (I) usermode (S) user management: allow_dynamic_ghosts (B) alnum_nicks (B) auto_register (B) block_ban_ttl (I) clones_allow_level (I) default_ban_ttl discipline_ignorers_ban_ttl (I) eject_after (I) eject_ban_ttl (I) eject_grace_time (I) eject_leeches (B) eject_no_channels_only (B) eject_when_full (B) ghost_kill (I) invalid_clients (S) invalid_nicks (S) max_block_pct (I) max_block_pct_ban_ttl (I) max_client_string (I) max_nick_length (I) nick_expire (I) registered_only (B) restrict_registration (B) valid_clients (S) who_was_time (I) user notification: browse_nag (B) notify_exceed_frequency (I) notify_user_abuse (B) notify_user_abuse_frequency (I) notify_user_block (B) Unix specific: connection_hard_limit (I) lock_memory (B) max_data_size (I) max_rss_size (I)

### Changed variables

The following variables from previous versions were either removed or changed their type or meaning:

Variable | Change | Note
allow_dynamic_ghosts (B) | Replaced | by ghost_kill (I)
block_winmx (B) | Replaced | by invalid_clients (S) and valid_clients (S)
break_mx_queue (B) | Type change | from integer to boolean
browse_nag (B) | Type change | from integer to boolean
discipline_block (B) | Removed | Might be replaced by separate block file soon. This feature usually didn't help getting rid of users who share dirty stuff, as intended, but rather getting rid of users who share lots of stuff, which was not the intention.
discipline_block_ban_ttl (I) | Renamed | to block_ban_ttl (I) Will apply to entries in file opennap-block-ban.txt.
discipline_block_mod (B) | Removed | ! Mods+ are to be banned automatically under no circumstances! They are part of the staff. De-mod or ban them manually if you want to get rid of them!
discipline_ignorers (B) | Removed | Redundant setting! Set discipline_ignorers_ban_ttl to nonzero to killban Mod+ ignorers, zero to turn it off.
eject_also_bans (B) | Removed | Redundant setting! Set eject_ban_ttl to nonzero to turn this feature on, zero to turn it off. Auto-ejecting without banning is pointless.
eject_leeches (B) |  | from integer to boolean
eject_nochannels (B) | Renamed | to eject_no_channels_only (B) to better reflect its meaning.
ghost_kill (I) | Type change | from boolean to integer to allow multiple modes.
loglevel (S) | Replaced | by log_level (I)
max_new_users_per_minute (I) | Replaced | by max_new_users_count (I) and max_new_users_time (I). This setting never worked correctly.
max_searches (I) | Renamed | to max_searches_pending (I), to better reflect its meaning.
no_mod_annoying (B) | Type change | from integer to boolean
notify_mod_abuse (B) | Type change | from integer to boolean
notify_mod_block (B) | Type change | from integer to boolean
notify_user_abuse (B) | Type change | from integer to boolean

The default values of some variables have changed. This measure has been taken to assist server newbies with values that have proven to be reasonable. For existing config files, in which values are explicitly specified, nothing changes.
However, server owners should feel encouraged to compare their values with recommended values, as some of them are the result of late stress and efficency tests. Also, not all meanings of variables have been properly understood by all server owners in the past. As the verbosity of this documentation increases we hope to be able to address some existing misconceptions.

### Detailed list of configuration variables

The slightly darker fields indicate new variables since Opennap-NG 0.46. They are not contained in previously official versions 0.47 and 0.47.2! Even experienced Opennap server operators should study them on upgrading from an older version.

Variable | Context | Type | Default | Description
allow_share | content managm. | boolean | on | Controls whether or not clients are allowed to share files via the server. If set to off this server doesn't accept any files to share and operates as a chat server only.
alnum_nicks | user managem. | boolean | off | If set to on, only old-fashioned alphanumerical user nicks will be accepted. They may consist of upper and lowercase letters "A" - "Z" and "a" - "z", digits "0" - "9", a hyphen "-" and an underscore "_" only. Nicks containing any other character will be rejected on login by the server.
ascii_filenames | content managem. | boolean | off | If set to on, filenames (including path specifications) being sent from clients must consist entirely of printable 7-Bit ASCII characters, that is, ASCII values 32 to 126. This results in filenames that should be readable in english and a limited number of other languages. Especially filenames consisting of foreign language characters like Kanj (japanese), russian or others are not accepted. This helps keeping out not understandable filenames, hence potentially unwelcome or dangerous content. Filenames containing other characters han 7 Bit ASCII printables are rejected, those files are blocked (and count for max_block_pct, eject_limit_files and similar of that user).
auto_link | network | boolean | off | When set to on, Opennap-NG will automatically attempt to link to all servers listed in the servers file when it starts up for the first time.
auto_register | user managm. | boolean | off | When set to on, the server will automatically register a nickname the first time it is used. When off, nicknames will only be registered when the client explicitly requests it. Please regard that many users don't care about correct passwords in filesharing networks and neither do some clients. Actually, an increasing number of users use random passwords on each connect. Those users won't be able to connect more than once to a server with auto_register set on, See also: registered_only, register_interval and nick_expire.
break_mx_ queue | flood protection | boolean | off | Some buggy clients send a lot of privmsgs containing //WantQueue. If this value is set to on then these privmsgs will be blocked on the server this user is connected to. To get a picture what a waste of bandwidth occures when not switching this to on grep your opennap-ng logfile for "privmsg"opennap/opennap-ng/doc/. It should display something like: `privmsg: all 205: 43000 705596 Bytes - 205WQ: 39096 (90.9%) 431382 Bytes (61.1%) privmsg: all 205: 44000 720813 Bytes - 205WQ: 40030 (91.0%) 441662 Bytes (61.3%)` after only some hours of uptime. 205WQ is the count and the size of privmsgs containing a queueing message.
browse_nag | user notification | boolean | on | When set to on users are nagged when their client issues an old 211 server browse request without at least trying the newer 640 direct browse command.
client_queue_ length | perform. | integer | 102 400 | Sets the maximum number of bytes that can be queued for a client connection. If this threshold is reached, it is assumed that the client is either dead, or the network link can not sustain the level of output, and the server automatically closes down the client connection. This is necessary so that dead clients don't consume all of the servers memory. Smaller values may save a tiny amount of server RAM but increase the risk for connections to be terminated on voluminous transfer operations, such as server browses or large numbers of search results. A value of 49152 is still safe for most users's operations. Don't set this value to less than 32768.
cloak_user_ level | security | integer | 0 | If non-zero, ordinary users who are whois'ing others will always receive "user" as userlevel information of the user being whois'ed. Users won't be able to identify Moderators, Administrators and Elites. This feature is to protect server staff, if responsible ones prefer to stay undiscovered. More precisely, the values of this setting have the following meaning:
0 = | always return real userlevel to all users
1 = | return real user level to users who are at least flagged "friend"
2 = | only Moderators, Administrators and Elites will be reported real userlevels of others on whois'ing
clones_allow_ level | user managem. | integer | 3 | If non-zero, specifies which user levels are exempt from clone detection and ejection. Without clone detection, an arbitrary number of connections from the same IP address are allowed to connect. All user levels equal or above the specified value are exempt from clone detection. The default value is to exempt Admins and Elites from clone detection. Actual clone detection setting is done via the max_clones variable. Here, the possible values are:
0 = | clone detection affects all and everyone
1 = | users (with the friend flag only!) and above are exempt
2 = | Moderators and above are exempt
3 = | Administrators and Elites are exempt
4 = | Only Elites are exempt from clone detection
compression_ level | perform. | integer | 1 | The zlib compression level to use when compressing server to server connections. 0 means no compression, 1 is least effort, 9 is best compression. The higher the number, the more CPU it will consume. Level 1 compresses text by about 50%, which is good enough for most applications.
criticial_ delay | log verbosity | integer | 5 | The server contains some internal performance validation code. After it got stuck in particular subroutines for too long, (freezing, also causing lag), it can report the duration and cause of this event to the log. Messages are of the form "checkdelay: level x, stuck for y seconds in block z". The error log level must be enabled for these messages to be emitted. This setting specifies the threshold in seconds for such delays to be reported. All freezes which have taken longer than this will be reported. These messages may be helpful in detecting and confirming server lag, identify its origins and possibly hint on correcting server parameters to reduce these events. To non-programmers the messages may appear incomprehensible, though.
default_ ban_ttl | user managm. | integer | 17,280,000 | How long bans last if no timeout value was entered. The default value is 200 days (~6 months). Longer and shorter bans can still be specified, and other feature-specific ban ttls aren't affected either. Just absolutely unlimited bans aren't supported any more; every ban has its expiration period.
discipline_ ignorers_ ban_ttl | user managm. | integer | 2 592 000 | When a user ignores a mod+ this is annoying enough. But when the mod killbans the user just to have the user relogging in with another nick this hits the spot multiplied by -1. This feature takes some care of these cases. If you set this value to nonzero then a user who ignores a Mod+ will be killed and banned for this number of seconds. The default is 30 days. Set this to 0 to allow users to ignore Mods+ without sanctions. However, remember the meaning of Moderators is to be listened to and not to be ignored.
eject_after | user managm. | integer | 120 | Specifies the number of seconds after initial login to the server for which the client is exempt from being killed for not sharing enough when the server is full (see eject_limit). This should be large enough to allow a client to start sharing files before getting killed.
eject_ban_ttl | user managm. | integer | 7200 | If a user doesn't share enough appropriate files he gets ejected and banned for this number of seconds. If this value is 0 no general ejection for not sharing enough will occur. However, regard max_block_pct and max_block_pct_ban_ttl, which supplies an independent and different approach for this. Mods+ will never be ejected for not sharing enough. This sort of ejection is affected by the following settings: eject_limit_files, eject_limit_libsize, min_file_size and max_file_size and file opennap-block.txt The default value is 2 hours. Increase it to slightly reduce your internet traffic. Experience has shown that 98% to 99% of users don't care about being banned for not sharing enough on a particular server, resulting in them connecting again and being banned again and again, as soon as this ban TTL expires.
eject_grace_ time | user managm. | integer | 600 | If the `eject_limits` are on then a freshly started server may killban users because the load on such a server is so high that some users are not able to get their files shared in time or even may time out when sharing on a low bandwidth server. The variable `eject_grace_time` is the time in seconds after which the eject_limits are checked right after the serverstart. The default value is ten minutes (600 seconds).
eject_leeches | user managm. | boolean | off | When eject_when_full is set, kill leeches to allow another user to login, even if they are sharing over the required amount of files.
eject_limit_ files | content managm. | integer | 0 | The min amount of files a user has to share in order to be exempt from eject_when_full. Any client that shares either eject_limit_files+1 files or 'eject_limit_libsize+1 Kilobytes will not be disconnected. This setting helps fighting freeloaders. Mods+ will never be ejected for not sharing enough.
eject_limit_ libsize | content managm. | integer | 0 | The min amount of Kilobytes a user has to share in order to be exempt from eject_when_full. Any client that shares either `eject_limit_files`+1 files or `eject_limit_libsize`+1 Kilobytes will not be disconnected. This setting helps fighting freeloaders. Mods+ will never be ejected for not sharing enough.
eject_no_ channels_only | user managm. | boolean | on | Normally eject_when_full will eject users who aren't sharing enough regardless of if they are chatting. `eject_no_channels_only` set to on ejects only users who are not in a channel and not sharing enough. If set to off, users who aren't sharing enough are ejected regardless of if they are in channels or not. In other words: on protects chatters from ejection.
eject_when_ full | user managm. | boolean | on | If set to on, the server will disconnect the longest connected client which is not sharing any files when the server is full (eg., when it has reached max_connections clients). This allows room to be made for those clients which are sharing files. Also see eject_leeches, eject_limit_libsize, and eject_limit_files This setting helps fighting freeloaders. Note: mods+ and Friends are exempt and can always log in even if they are sharing no files.
evaluate_ search_ abuse_after_ secs | flood protection | integer | 120 | After how many seconds should `max_searches_per_minute` be evaluated? This is to prevent that a freshly connected user will be prosecuted because he is initally searching all of his incompletes.
evaluate_ search_ abuse_after_ tags | flood protection | integer | 100 | After how many tags in total should `max_searches_per_minute` be evaluated? This is to prevent that a freshly connected user will be prosecuted because he is initally searching all of his incompletes. After `evaluate_search_abuse_after_tags` requests the counter starts counting.
file_count_ threshold | flood protection | integer | 5 000 | When a indexed file search token (one word) contains more than this number of matching files, the server will warn in its log output. This gives the ability to add this term to the list of filtered words.
fix_xnap_ path | content managm. | integer | 1 | Some versions of the XNap client use to share each file in its own directory named by just a number. The results of browsing such users look stupid on many other clients and make it difficult to get an overview over the files offered. This setting provides some ways to deal with this mess. It only affects files to be shared with a plain number as the top level directory name.
Value | Action
0 | Let messy paths pass unchanged.
1 | Just remove the top level part of the directory. I.e "`2047\This is the song.mp3`" would become "`This is the song.mp3`". This value results in flat filelists for those buggy clients. However, they're usually easier to overview than the original structure.
2 | Put the entry into an artifical directory named by the first letter of the actual file. I.e. "`2047\This is the song.mp3`" would become "T\`This is the song.mp3`". This reduces the number of directories significantly.
3 | (Non-functional!) Put the entry into an artificial directory named by the first word (seperated by the first non-alphanumeric character) of the actual file. I.e. "`2047\This is the song.mp3`" would become "`This\This is the song.mp3`".
flood_ ban_ttl | flood protection | integer | 86400 | If flood_eject is non-zero then this setting specifies the ban TTL in seconds for exceeding flood limits. The default is 1 day.
flood_ commands | flood protection | integer | 0 | This variable, along with flood_time, allow for server-side flood protection. When set to a value greater than zero, the server will not allow clients to issue more than this number of commands in flood_time seconds. Any client attempting to send commands faster than the allowed limit is throttled back. A recommended value pair is 100 commands in 10 seconds, to allow clients to occasionally repeat multiple searches. Intentional flooders will easily exceed this.
flood_time | flood protection | integer | 100 | This variable, along with flood_commands, allow for server-side flood protection. When set to a value greater than zero, the server will not allow clients to issue more than this number of commands in `flood_time` seconds. Any client attempting to send commands faster than the allowed limit is throttled back. A recommended value pair is 100 commands in 10 seconds, to allow clients to occasionally repeat multiple searches. Intentional flooders will easily exceed this.
flood_eject | flood protection | integer | 0 | If flood_eject and flood_ban_ttl are both non-zero, clients exceeding the flood threshold specified by flood_time and flood_commands this number of times will be automatically ejected and banned. Setting this to a low value like 1 or 2 is not recommended! Clients which exceed the flood limits don't always do this on purpose or even knowingly. Occasionally exceeding flood thresholds can happen to many clients. Hence, if this feature is to be used, minimum values of 4 or 5 are recommended. Otherwise you could quickly find large numbers of users getting banned. The same is true, if flood_commands and flood_time are set too low.
ghost_kill | user managm. | integer | 1 | If non-zero, ghosts may be killed. Despite the possibility of ghost kill deadlocks it is recommended to enable ghost kill, since the harmless and innocent ghosts use to outweigh malicious ones by far.
0 = | Disable ghost killing
1 = | Enable ghost killing
This variable was changed in 0.49 from boolean to integer type to implement additional submodes. However, as field tests showed they implied other problems, additional submodes have been withdrawn again, for the time being.
ibl_ttl | flood protection | integer | 0 | The Internal Ban List is an optimization means which is used to keep out excessive clients. If a client reconnects too fast, keeps using an invalid nick or an invalid client, then the IP of this user is banned for `ibl_ttl` seconds. Checks against entries in the IBL are much faster than checks against entries in the main ban list. The user trying to connect will be disconnected immediately, without even getting a "You are banned..." message delivered. Clients may display this as "server read error"s, "connection timeout"s or similar. Please note that if for some reason any Moderator or Admin or Elite gets into this list upon an connection attempt, he won't be able to connect to the server for `ibl_ttl` seconds either! That is because the connection request will be rejected before any nicks or passwords are transmitted to the server. There is currently also no way to "unban" an entry from the IBL. So this value shouldn't be too high. 10 minutes (600) is a reasonable value. It should not exceed 1 hour (3600). A value of 0 disables this feature.
index_ignore_ suffix | content managm. | boolean | on | Controls whether or not the filename extensions of shared files are included in the searchable index. Also see index_path_depth.
index_path_ depth | content managm. | integer | 2 | Controls how many levels of directory are included when adding shared files to the searchable index. Often times the leading parts of the path are completely useless for searching (eg., `C:\Program Files\My Music\Rock\`) and just consumes a lot of memory. This variable counts from the end of the path backwards, so the higher the value, the more of the beginning of the path it will include. Also see index_ignore_suffix.
invalid_ clients | user managm. | string list | (null) | This is a string list of clients that are not allowed on your server. Some clients can't/don't share, some clients are broken, etc. This list can be superseded by valid_clients. Example: `invalid_clients *floodster*,*mp3rage*,*rapigator*`
invalid_nicks | user managm. | string list | (null) | invalid_nicks is a list of invalid client nicks, ones which you do not want on your network for some reason or another. Example: `invalid_nicks joey2cool,*trade*`
irc_channels | chat control | boolean | on | When set, Opennap-NG requires all channel names to begin with # or &.
level_to_ set_flags | security | integer | 2 | Minimum level a user must have to assign userflags to other users. Values are: 0 = Leech, 1 = User, 2 = Moderator (default), 3 = Admin, 4 = Elite. Values below 2 are not sensible.
listen_ address | network | string | 0.0.0.0 | By default, the server will listen on all interfaces on the system. You can force it to listen only on a single interface by specifying the IP address of the interface in this option.
log_blocked | log verbosity | boolean | off | When set to on, each file that a user tried to share and which is blocked will appear in the log. mod+'s can monitor this by joining the &LOG channel. This feature usually produces less traffic than notify_mod_block.
log_channel | log verbosity | boolean | on | When set to on the log will be output in a special channel &LOG. Only mod+'s can join this special channel. Note: this configuration variable replaces the former configure option LOG_CHANNEL.
log_ignore_ abuse | log verbosity | integer | 1 | If set to 1 then each user who tries to ignore more other users than max_ignore will be reported once in the log. If set to 2 then each further attempt to ignore other users will be logged, including the nick which would be ignored. If set to 0 then no logging happens when a user tries to ignore more than max_ignore other users. This variable can be helpful to detect traders or leeches who tend to quickly ignore almost every user who tries to download from them. Note: a client may implement its own management of ignoring other users. This variable has effect only if the client requests ignores on the server. Most clients do so as this is part of the protocol and simpler for them to implement.
log_mode | log verbosity | boolean | off | When set to on, Opennap-NG will log changes in user levels to a file.
log_level | log verbosity | integer | 1423 |
Server: | 1
Client: | 2
Login: | 4
Files: | 8
Share: | 16
Search: | 32
Debug: | 64
Error: | 128
Security: | 256
Channel: | 512
Stats: | 1024
This is a bitflag word to determine what kind of events you want logged. That said, what that means is you look at the left table, and add together the values of the log levels you want to see in your server log (or output) and in the `&LOG` channel. The default value of 1423 enables logging of events of types Server, Client, Login, Files, Error, Security, Stats. If you want Server (1), Client (2), and Files (8), you set log_level to 1+2+8 = 11 Another example, Server, Client, Files, Share, Debug = 1 + 2 + 8 + 32 + 64 = 107.
log_stdout | log verbosity | boolean | on | If set to on then logging of events will happen not only to the &LOG channel but also to stdout (or a log file if the server runs as a background process).
log_timefmt | log verbosity | string | none | If set then this variable specifies a time format which is used to create a time / date string. This date string is prepended to each line which is logged to stdout / the log file / channel. The format of `log_timefmt` must be according to the options of the GNU LIBC strftime() function. It's made up of conversion specifiers which compose the format of the time output (similar to the printf() function variants). A description of all conversion specifiers is beyond the scope of this manual. Look into the GNU LIBC documentation of the function strftime() for that. Only some useful examples are given here:
Format: | Output: | Description
`%H:%M:%S:` | 12:34:56 | <hour>:<minute>:<seconds>:
`%m-%d %H:%M` | 09-23 12:34 | <month>-<day of month> <hour>:<minute>
`%a %H:%M:%S` | Tue 12:34:56 | <weekday> <hour>:<minute>:<seconds>:
login_interval | flood protection | integer | 0 | Specifies how often (in seconds) clients from the same IP address are allowed to connect to the server. This allows you to ignore clients which are reconnecting too fast. Reasonable values are 5 to 30 (seconds). A value of 0 disables the check. Also see register_interval.
login_timeout | flood protection | integer | 60 | If a client has not completed the login process after this number of seconds, it will be disconnected. This is to prevent malicious parties from trying to open up many sockets to the server.
loopcount_ output_ interval | log verbosity | integer | 1000 | If non-zero, specifies the interval for executed main loop iterations being logged (with Debug level). Number of main loop iterations is a rough measure for servicing activity and efficiency since server start. The default value means that every 1000th main loop iteration will be logged.
max_block_ pct | user managem. | integer | 0 | If this value is nonzero it specifies the maximum percentage of blocked files which are allowed per user. If i.e. a user attempts to share 2000 files but 1800 of them are blocked (90%) the user may not be suitable or welcome to the server at all. Files may be blocked because they match patterns in the opennap-block.txt file or are too small (min_file_size) or too large (max_file_size). If the percentage of blocked files of a user is higher than this value and max_block_pct_ban_ttl is nonzero, the user will be immediately banned. Mods+ will never be banned. Banning users who attempt to share a great amount of blocked files also reduces waste of internet bandwidth. The valid range for this value is 0 to 100. A value of 0 disables this feature. 75 seems to be a fair value for public servers. Reduce it to 50 or less to be more restrictive, but possibly also lose interesting content.
max_block_ pct_ban_ttl | user managem. | integer | 60400 | If max_block_pct is set and a user attempts to share more than that percentage of blocked files, the user will be banned for this number of seconds. The default value is one week. This is a reasonable value since you deal with users who share a great amount (percentage) of stuff you don't want to have on your server, and experience has shown that the vast majority of users being banned for that wouldn't quickly change their entire shares just to get on a particular server or network.
max_browse_ result | perform. | integer | 500 | Limits the output of a server browse to this number of files. Because of the limit imposed by client_queue_length, the number of files returned by a browse command is limited to this number. If this is too large, clients will be disconnected when they browse a user with many files. There is also a consideration of bandwidth, a high browse limit imposes a large amount of uplink bandwidth. Mods+ are exempt from this limit, however they are still limited by the max_shared value for the client being browsed. This setting has a high influence on the amount of internet bandwidth the server consumes, especially the upstream. If the server consumes too much upstream bandwidth then reduce this value to 200 or 100. If upstream bandwidth is no issue for you then you may increase this to 1000, 2000 or more. The default value is appropriate for servers running via DSL connections. Note: this limit affects only server based browses. No limit is imposed on direct browses (client to client connections) since the server doesn't control data exchange in that case. Direct browses save server network bandwidth and are therefore the preferred method. Whether direct browses can be performed depends on which client programs are involved. Many client programs don't support direct browses yet. Both (requestor and responder) must support it in order to work and allow unlimited browsing.
max_channel_ length | chat control | integer | 32 | Specifies the max number of characters allowed in a channel name.
max_client_ string | user managm. | integer | 32 | Specifies the max number of characters allowed in the client version string.
max_clones | flood protection | integer | 0 | When set to a value greater than 0, the server will only allow this many connections from the same IP address, to limit clones. Also see login_interval and clones_allow_level. A value of 2 should be acceptable, as this description states.
max_ command_ length | flood protection | integer | 2048 | When set to a value greater than 0, the server will disconnect any client that sends a command longer than this value. Clients that trigger this are either attempting to flood the server or are out of sync. Actually, the default value of 2 KB should not be changed,. as most clients don't issue larger commands anyway, while all clients assume at least this command size to be accepted.
max_ connections | perform. | integer | 1000 | When set to a value greater than 0, the server will only allow this many clients to log into the server. If `max_connections` users are already logged in and new users try to login they will be disconnected with a server full response. This is one of the most important server settings, as it specifies the general user capacity the server will be able to serve. This setting strongly affects CPU consumption, RAM consumption and internet bandwidth consumption of the server. Lower it to reduce server demands regarding those items. See also: connection_hard_limit. Warning: when setting this variable to 0 or a value larger than your operating system limit the server may crash as soon as the number of connections gets close to the OS limit. For all Linux versions < 2.4.x this is 1000. Also consider increasing RAM, CPU and bandwidth consumption of high numbers of connections. Heavy lag and timed out connections are mostly the result of a too high value for `max_connections`. A typical P5-II class machine should be able to safely handle ~500 connections, a P5-III ~1000 and a P5-IV up to 2000 connections (if your OS permits it). Higher numbers may be feasible depending on other settings like max_shared, max_browse_result, max_searches_per_minute and some other flood protection settings.
max_hotlist | perform. | integer | 32 | When set to a value greater than 0, the server will only allow each user to have this many entries on their hotlist.
max_ignore | perform. | integer | 32 | When set to a value greater than 0, this server will only allow each user to have this many entries on their ignore list. If the user tries to ignore more users those requests will simply be ignored. Depending on the setting of log_ignore_abuse such an event may be logged or not. Note: a client may implement its own management of ignoring other users. This variable has effect only if the client requests ignores on the server. Most clients do so as this is part of the protocol and simpler for them to implement.
max_new_ users_count | perform. | integer | 20 | When `max_new_users_count` and `max_new_users_time` are set to nonzero the rate at which new users can connect is limited. During each interval of `max_new_users_time` seconds at most `max_new_users_count` users can connect. Further connection requests are refused until the next interval of `max_new_users_time` begins. This is to avoid splits and timeouts due to the fact that 2000 users who want to connect to the freshly advertised server simultaneously produce a pretty nice bandwidth peak. The default values allow up to 20 users to connect per 10 seconds (or 2 users per second in average).
max_new_ users_time | perform. | integer | 10 | When max_new_users_count and `max_new_users_time` are set to nonzero the rate at which new users can connect is limited. During each interval of `max_new_users_time` seconds at most max_new_users_count users can connect. Further connection requests are refused until the next interval of `max_new_users_time` begins. This is to avoid splits and timeouts due to the fact that 2000 users who want to connect to the freshly advertised server simultaneously produce a pretty nice bandwidth peak. The default values allow up to 20 users to connect per 10 seconds (or 2 users per second in average).
max_nick_ length | user managm. | integer | 19 | If set to a value greater than 0, this specifies the max number of characters allowed in a nickname.
max_reason | perform. | integer | 96 | If set to a value greater than 0, this specifies the max number of characters allowed in the "reason" strings for such commands as ban, kick and kill.
max_results | perform. | integer | 100 | If set to a value greater than 0, this specifies the max number of search results that are returned to a client.
max_searches_ pending | perform. | integer | 3 | Specifies the maximum number of pending searches a user is allowed to have. Once this threshold is reached, no more searches can be issued until one of the others has completed.
max_searches_ per_minute | flood protection | integer | 2 | Set the maximum number of searches (tag 200) a client is allowed to make during his connection. A value of 0 does not check the number of searches at all. This limit is calculated by using: ( count200 - `evaluate_search_abuse_after_tags` ) / onlinetime. So a value of 2 searches should be sufficient.
max_shared | content managm. | integer | 5 000 | If set to a value greater than 0, this specifies the max number of files that any client may share. This also affects the maximum number of browse results for Mods+ (they are exempt from the normal max_browse_result). This setting strongly affects RAM consumption and also affects internet bandwidth consumption of a running server. Increase this value if you have plenty of them left to spend. Decrease this value (or max_connections) if RAM consumption tends to grow too large after the server has been running for some hours. Also regard there may still be some users who like to share 20 000 files and more. They could feel disgusted if this value is too low, especially if they get additionally annoyed by verbose_too_many being on and notify_exceed_frequency being too low.
max_tags_ per_minute | flood protection | integer | 2 | Set the maximum number of certain tags per minute a client could issue to the server. Some analysis showed that the tags 218, 219 and 700 were abusively used by some buggy clients. When the client has more than `max_tags_per_minute` tags the request is simply ignored.
max_time_ delta | network | integer | 90 | Specifies the maximum number of seconds of difference in clock time between two servers in order for them to be able to link. Note that if this value is set too large, users can gain ops in channels even if they were not the first user to join the channel. A value of 0 will turn off this check completely.
max_topic | chat control | integer | 64 | If set to a value greater than 0, this specifies the max number of characters allowed in a channel topic.
max_ uploading | performance | integer | 100 | If non-zero, limits the number of concurrent filelist uploads by clients. Most clients start to transmit their shared files lists immediately after connect. If many files are to be shared by clients this can mean an excessive incoming traffic for the server, especially shortly after the server has been started. Server overload and significant lag can be result of this. With this setting, if more than this number of clients are currently uploading, new logins are rejected until some clients have finished uploading their filelists. The stats log output shows how many users are uploading. However, for technical reasons the value being displayed isn't quite precise and usually a bit higher than the actual number of clients uploading. So it's recommended not to set this value too low, as on large servers this could not only limit incoming traffic but also the number of users being able to connect at all. Don't set this value lower than 50 for small servers. For large servers, values of 200 or 300 are recommended.
max_user_ channels | chat control | integer | 5 | If set to a value greater than 0, this specifies the max number of channels a user is allowed to join.
max_whois_ ban_ttl | flood protection | integer | 604800 | If max_whois_count, max_whois_time and this value are non-zero, determines the ban TTL in seconds for excessively whois'ing clients. The default value is one week.
max_whois_ count | flood protection | integer | 0 | If non-zero, specifies how many whois requests a user may issue within max_whois_time seconds. If the user exceeds this number of whois requests and max_whois_ban_ttl is non-zero, (s)he gets banned. Excessive numbers of whois requests are emitted automatically by some clients with certain settings, when users want to be selective (or denying at all) regarding their uploads, at the expense of server bandwidth. Most server owners don't want to support such behaviour. Since occasional whois'ses of other users aren't anything hostile, if non-zero, this value should not be set too low. A number of 10 to 20 whois requests per hour should be tolerable. Excessive clients will usually exceed this number by far.
max_whois_ time | flood protection | integer | 0 | If non-zero, specifies the period for max_whois_count in seconds. Recommended is a value pair of count 10 to 20 and time 3600 (1 hour)..
min_file_size | content managm. | integer | 0 | Set the lower limit of filesize (in bytes) which a single file must at least have to be shared. If the `min_file_size` is 0 then there is no checking on this parameter. If a user tries to share files with a size of less than `min_file_size` the user will receive a server message informing him about the rejected file. It should be considered that the Napster protocol isn't well suited to transfer large numbers of small files. Also, a significant amount of common small files consists of either images of unwelcome (or dangerous) kind or simply crap, like icon libraries, DLL files, installed driver files or simply fakes! Although noone will be interested in crap it may consume (waste!) significant amounts of server resources if not being filtered out. That's why for public servers a value of 100000 to 300000 (100 to 300 KB) is recommended, although this may suppress a small number of desired small files as well.
min_read | network | integer | 0 | If not 0 specifies the minimum number of bytes expected to be read from a connection. If less than `min_read` bytes are read the number of bytes read will be logged.
nick_expire | user managm. | integer | 604 800 | Specifies the time in seconds of after which unused accounts are expired and returned to the pool of available nicknames. The default is 1 week. See also auto_register.
no_mod_ annoying | mod+ notification | boolean | off | When set to on mod+ are exempt from the notification of tag abuse. This only affects mod+ who are on a server where notify_user_abuse is set to on.
no_share_ level | security | integer | 4 | If nonero, specifies the user level from which on no shares are accepted. I.e. the user will always be listed as sharing 0 files, even if the client is configured to share files. This is helpful for Elites and Admins who connect to multiple networks with the same client and shares setting but don't want to share any files in the network where they are Elite or Admin, due to legal trouble, for instance. Meaningful values are 0 == no sharing restrictions, 2 == Moderators, 3 == Admins, 4 == Elite. The default value 4 means that all Elites won't appear sharing any files, regardless of their client settings.
notify_exceed_ frequency | user notification | integer | 10 | Frequency of notifications which are sent to a user if he keeps trying to share files beyond the max_shared limit. The default value of 10 means that for every 10 rejected files the user gets one notification. The higher this value the less network bandwidth will be wasted.
notify_mod_ abuse | mod+ notification | boolean | on | When set to on the abuse of the tags mentioned above is reported to the mod+ users on your system.
notify_mod_ abuse_ frequency | mod+ notification | integer | 100 | When `notify_mod_abuse` is set to 1 then this following var reports the frequency of notifications which are sent. A `notify_mod_abuse_frequency` of 100 means that every 100th abuse per user is reported via notify_mods().
notify_mod_ block | mod+ notification | boolean | off | When set to on all Mods+ will receive IMs for every file a user tries to share, beginning with the first file of that user which was blocked. This includes also files which are not blocked. Since this option may produce heavy traffic use of log_blocked is recommended instead.
notify_user_ abuse | user notification | boolean | off | When set to on the abuse of the tags mentioned above is reported to the user issueing the tag via a privmsg.
notify_user_ abuse_ frequency | user notification | integer | 1000 | When notify_user_abuse is set to on then this following var reports the frequency of notifications which are sent. A `notify_user_abuse_frequency` of 1000 means that every 1000th abuse per user is reported via privmsg to the user.
notify_user_ block | user notification | boolean | off | When set to on a user will receive a server response for every blocked file he tries to share. This is a way to let the user know which of his files are blocked.
ping_interval | network | integer | 600 | Specifies the interval (in seconds) of how often to sping peer (linked) servers.
protnet | security | string list | * | Protnet is a set of protections granted to an Elite user on the defined IP or list of IPs. The elite is protected from being killed, mkilled, their password changed, or account nuked, and their server killed, by someone NOT on the protnet, even if they are elite. The default setting works like normal, any elite can kill other elites, etc. Note, the protection only works on your own server, it can't protect you on another server, etc. Example: `protnet 128.1.128.1,192.168.0.*`
register_ interval | flood protection | integer | 0 | Specifices how often (in seconds) clients from the same IP address are allowed to register new nicknames. This can be used in conjunction with auto_register to block web/clone clients which attempt to log in with random nicknames.
registered_ only | user managm. | boolean | off | When set to on, the server only allows logins from registered clients. Also see auto_register, register_interval.
remote_browse | perform. | boolean | on | This variable controls whether or not the server supports remote browsing (where the client being browsed is not on the same server). In large networks, remote browsing can account for significant cross server traffic, increasing lag. Lopster or TekNap support´s for clients to directly browse eachother outside of the servers, which is the recommended approach.
remote_ config | security | boolean | on | If set to on then admins from other servers are permitted to change configuration values on this server.
report_ip | Napigator support | string | value of server_ name | Sets the IP address this server listens on to be reported to Napigator (GotNap).
report_name | Napigator support | string | value of server_ name | Sets the name of the server reported to Napigator (GotNap).
report_port | Napigator support | string | value of server_ ports | Sets the TCP port this server listens on to be reported to Napigator (GotNap).
restrict_ registration | user managm. | boolean | off | If set, disallow the automatic registration of new nicknames by clients as they log in for the first time. The only way to create new nicknames (accounts) is then to use the administrator commands to register, or by editing the users file directly (when the server is not running). This option is typically used with the registered_only option to run a private, access-controlled server where users need accounts before they can log in. For public servers this setting should remain off, to offer users the option to register themselves, for instance to avoid nick collisions.
search_max_ cache_entries | perform. | integer | 500 | To give the hub in a distributed network some relief and to speed up repeated searches an internal cache is maintained. How many searches should be cached? The default value is 500 searches. You can query the cache stats using `/raw 10116`. The format of the output is: Counter Rank Usage Starttime LastUsedTime SearchString
search_timeout | network | integer | 180 | When servers are linked, searches will be timed out if no response has been received after this many seconds. This forces the server to send the final ack to the client.
server_alias | Napigator support | string | none | Allows you to specify an alternate name by which the server refers to itself. This is useful for connecting a "hidden" hub (routing-only) server, or if you just want to use a shortcut for the full DNS name.
server_chunk | perform. | integer | 0 | If not 0 then this is the minimum amount of data to queue before being sent to another server. If less data is to be sent the transmission will be delayed.
server_name | network | string | Hostname | Specifies the server's DNS name.
server_ports | network | string | 8888 | This option specifies a list of TCP ports which the server should listen on for client connections. Each port number should be separated by whitespace.
server_ queue_ length | network | integer | 1 024 000 | Specifies the maximum number of bytes that can be queued for a server connection before it is considered dead.
set_server_ nicks | security | string list | (null) | This is a list of names of users who are allowed access to raw 9998 and 9999. The users must still be elite, this adds another layer of security to restrict exactly who is allowed access. I suggest not doing wildcards in this list. Example: `set_server_nicks Khaytsus,ShadoeMynx`
stat_click | log verbosity | integer | 60 | Specifies how often (in seconds) the server should send updates about server statistics (users/files/gigs) to the clients.
stats_port | Napigator support | integer | 8889 | Specifies the TCP port on which the server should listen to reports stats. Typically used by Napigator (GotNap). If this port is set to -1, the server will not listen for stats reporting at all.
stat_server_ host | Napigator support | string | stats. napigator .com | Sets the DNS/IP address of the Napigator (GotNap) server to report stats. Also see report_name, report_ip, report_port, stat_server_port, stat_server_user, stat_server_pass.
stat_server_ pass | Napigator support | string | none | Sets the password for your Napigator (GotNap) account to list live server stats.
stat_server_ port | Napigator support | integer | 8890 | Sets the port number for your Napigator (GotNap) account to list live server stats.
stat_server_ user | Napigator support | string | none | Sets the username for your Napigator (GotNap) account to list live server stats.
strict_channels | chat control | boolean | off | When set to on, the server will only allow privileged users to create new channels. Upon startup of the server the channels listed in the channels file are always created.
user_db_ interval | security | integer | 1800 | Specifies the interval in seconds of how often the server should write out its database files to disk. This is important in case the server crashes prematurely, so that data loss is minimal. The default value of half an hour should be reasonable.
usermode | security | string | `all` | Sets the default usermode for mods+ users. Note: this is not to be confused with user levels!
valid_clients | user managm. | string list | (null) | If not empty this is a string list of clients that are allowed on your server. The client's identification must match one of the entries to be allowed to connect. The default is empty so there are no restrictions. Some clients can't/don't share, some clients are broken, etc. See also: invalid_clients. Example: `valid_clients *lopster*,*xnap*,*winmx*,*audiognome*`
verbose_ too_many | log verbosity | boolean | on | If a user tries to share more files than max_shared there will be a server response to the user and a log entry informing that no more files of him will be accepted. If this setting is on the names and sizes of the rejected files are evaluated and logged. This can be helpful to find users which share lots of fake or useless files. If this setting is off then names and sizes of files will not be evaluated and logged. This reduces CPU consumption.
warn_time_ delta | network | integer | 30 | If the clock on a remote server is more than this many seconds out of sync, opennap-ng will print a warning message. Also see max_time_delta. A value of 0 turns off the warning completely.
who_was_time | user managm. | integer | 300 | Specifies the number of seconds after a user logs out that information on the client's ip address and server is kept in cache, so that mods+ may perform a whowas command. Note: this only controls how often the cache is purged, so some nicks may appear to be older than this amount.

Napigator (GotNap) support:
you should only need to set stat_server_user and stat_server_pass at the minimum. If you have used your correct DNS name for server_name above, then you don't need to use any of the `report_`* variables. If Opennap-NG has trouble detecting the proper values to send to Napigator, then you should set the `report_`* variables appropriately.

###
UNIX Specific Configuration Options

Variable | Context | Type | Default | Description
connection_ hard_limit | Unix specific | integer | Depends on OS | Sets the maximum number of file descriptors available to the server process. Generally this is used to increase the default number availble. Note that in order to increase the default maximum, the server needs to be run as root (OpenNap-NG will drop privileges and run as the uid/gid specified by the configure arguments). Note: under Linux (< 2.4.x) `connection_hard_limit` cannot be changed and is always 1024.
lock_ memory | Unix specific | boolean | off | On supported systems, this will cause the server to lock all of its memory pages into real memory, thus avoiding swapping to disk.
max_data_ size | Unix specific | integer | Depends on OS | Sets the maximum amount of memory the process may consume. Also see max_rss_size.
max_rss_ size | Unix specific | integer | Depends on OS | Sets the maxiumum amount of real memory a process is allowed to consume. Any excess will be swapped to disk. Also see max_data_size.

See the `sample.config` file as a basis to start your own configuration.

### opennap-channels.txt

The `channels` file specifies all predefined channels on the server. Each line in this file should be of the form:

    	<channel> <limit> <level> "<topic>"

where channel is the channel name, limit is the maximum number of users allowed in the channel (0 for no limit), level is the minimum user level required to enter the channel and topic is the default topic for the channel. NOTE: typically you edit this file once before starting your server. You should never edit it while the server is running or your changes will be lost. The server always writes out its state when it shuts down, because new information about the channel may have been set. If you want to edit it by hand, you should first shut down your server. See the `sample.channels` file as a basis to start your own configuration. See also: strict_channels.

### opennap-filter.txt

This file allows you specify a list of words that should not be indexed when clients share files. This is most commonly used to weed out very common words such as `mp3' or `the' to save on server resources, since it is expected that none of these words will be very useful when searching. Note that the file is still indexed, you just can't use these particular words to find that file. In certain cases, a file may contain no valid words and thus won't be able to be found via the search mechanism. However, the file will show up when browsing the client's filelist, and therefore can still be downloaded. See the `sample.filter` file as a basis to start your own configuration.

### opennap-motd.txt

Message Of The Day. This file contains the text the server sends to your client when you log in. MOTDs may be coloured, which is to be controlled by escape codes. However, this is a feature being supported by few clients only.

### opennap-servers.txt

The `servers` file contains a list of servers which are allowed to link. Each line in this file is of the form:

    	<server_name> <remote_pass> <local_pass> <port> [alias]

where server_name is the DNS name of the remote server (the remote server should have its server_name set to this value), remote_pass is the password expected from the remote server to authenticate (prove its identity), and local_pass is the password your server uses to authenticate to the remote server. port is the TCP port on the server to connect to. alias is an optional string which will be used to refer to this server instead of its DNS name. This is useful for defining hub servers where you might not want the DNS name to be revealed to users, or you want to use a different name instead of the ip address (if you don't have a reverse DNS record). Note: lines that begin with a pound sign (#) or any space character (tab, etc.) are ignored. See the `sample.server` file as a basis to start your own configuration.

### opennap-user.txt

Lines starting with a hash (#) are comments and are ignored. Each line of the database should be of the format: nickname password email level created lastseen nickname the nickname that is registered

- password: the password for this nickname, created with `mkpass'
- email: the email address for this user
- level: the default user level of this user. should be one of: leech, user, moderator, admin, elite
- created: the time at which the account was registered (as measured by the time(2) system call
- lastseen: the time at which the user last logged in/out the server (as measured by the time(2) system call

Examples:
`lewser 1,N6BeTWZ4,fWJx95pWVcd2wTJk3ZCFBw blah@email.com Leech 0 0
poweruser 1,3aYmWBkH,o4BAAYyOD61bc28Eef8+5w my@address.com Elite 0 0`
See the `sample.user` file as a basis to start your own configuration.

## Administration

This section describes how to administer the OpenNap-NG server through the use of a connected client. It is assumed by the time you get here that you have set up at least one Elite level (server owner) account on your server (this is done by the setup program if you installed it that way). The first thing you want to do is log into your server with this account. When you log in, you should see a message from the server on your client, something like:

    	server_name set you to level Elite (4).

where server_name is the name of your server. This message will let you know that you have fill privilege to access administrative commands on this server. Clients such as Lopster or TekNap already have all of the OpenNap-NG extensions built into it. Others, such as the official Napster client or WinMX do not (it was not inteded to be used by administrators). If you client is missing functions to directly access these administration commands, not to worry, OpenNap-NG has a way of getting around this. OpenNap-NG provides to pseudo-users, ChanServ for channel related commands, and OperServ for server related commands. For both of these, you can access their functionality by sending a privmsg (instant) message to either of these users (in most clients this will be either `/msg` user or `/tell` user).

### ChanServ

You can administer chat channels either by using your client's built in functions, or by sending private (instant) messages to the user ChanServ. Note that most all of the following that actually affect the channel require the user issuing the command to be a channel operator.

ban | `/msg chanserv ban` #channel nick ["reason"]
| Places a ban on channel such that nick is prevented from joining. You can optionally give a reason for the ban that will be displayed to the user (Note: if you specify the reason, it must be quoted with double-quotes (") or else the server will only show the first word of the reason).
banclear | `/msg chanserv banclear` #channel
| Removes all bans from the channel.
banlist | `/msg chanserv banlist` #channel
| Displays the list of bans for the channel. Note: this does not work for the official Windows Napster client since it doesn't have support for displaying it.
clear | `/msg chanserv clear` #channel
| Kicks all users in the channel out of the channel, only leaving yourself.
deop | `/msg chanserv deop` #channel nick
| Removes user nick as a channel operator and makes him/her a normal channel user.
help | `/msg chanserv help`
| Displays a summary of all available commands.
invite | `/msg chanserv invite` #channel nick
| Send an invitation to user nick allowing them to join a channel which is set +INVITE.
kick | `/msg chanserv kick` #channel nick ["reason"]
| Kick user nick out of the channel. A reason can optionally be given. Note: if reason is given, it must be quoted with double-quotes (") or else the server will only display the first word.
level | `/msg chanserv level` #channel [level]
| Displays / sets the minimum required user level to be allowed to join a channel.
limit | `/msg chanserv limit` #channel [numusers]
| Displays/sets the maximum number of users allowed to join a channel.
mode | `/msg chanserv mode` #channel [mode [mode ...]]
| Displays/sets the channel mode. If no modes are given, it returns what the current channel mode is. Acceptable modes are:
TOPIC | allows any user to change the channel topic (normally only channel operators are allowed)
MODERATED | only channel operators and those who have been given channel voice can speak
INVITE | users must be invited before allowed to join
PRIVATE | makes the channel not show up in the server's channel list
REGISTERED | (mods+ only) makes the channel persist even when no users are present in the channel, and disallows channel operator to the first user that joins it.
To set a channel mode, prefix it with a plus-sign (+). To unset a channel mode, prefix it with a minus-sign (-). You can specify however many different modes on the same command as you like.
muzzle | `/msg chanserv muzzle` #channel nick
| Prevent user nick from being able to send messages to the channel.
op | `/msg chanserv op` #channel [nick [nick ...]]
| If no nicknames are given, it returns a list of the current channel operators. If given one or more nicknames, each user will be given channel operator status (and thus the ability to execute any of the other channel admin commands).
topic | `/msg chanserv topic` #channel [topic]
| Display / set the channel topic.
unban | `/msg chanserv unban` #channel nick
| Remove channel ban against nick, allowing him/her to join the channel again.
unmuzzle | `/msg chanserv unmuzzle` #channel nick
| Allow a previously muzzled user to send messages to the channel.
unvoice | `/msg chanserv unvoice` #channel nick
| Remove the ability to speak in a +MODERATED channel.
voice | `/msg chanserv voice` #channel nick
| Give the ability for a user to speak in a +MODERATED channel
wallop | `/msg chanserv wallop` #channel text
| Send a message to all channel operators on the channel (that is not seen by other users in the channel).

### NickServ

NickServ is a pseudo-user which provides access to registered user accounts. You can /msg (or /tell) it with the following commands.

ghost | `/msg nickserv ghost` user password
| This command allows you to kill a ghost which is holding your nickame so that you can log in again. user is the nick which is ghosting, and password is the password for that account.
register | `/msg nickserv register` password
| Allows a user to register a nickname that has not been previously registered, such that no other user may use the nickname without the corresponding password.
usermode | `/msg nickserv usermode` [flags]
| See usermode.

### OperServ

OperServ is a pseudo-user which allows mods+ level users to execute server administration command. This is primarily intended for those clients which do not have built in support for these commands, but there is no restriction on its use.

add_server | `/msg operserv add_server <hostname> <their_pass> <my_pass> <port> [alias]`
| Adds a temporary server to the servers list
cloak | `/msg operserv cloak`
| Toggles invisibility to normal users. When cloaked, normal users do not see your real nickname when you perform actions such as kill, ban, etc. Instead, it will display Operator. Other mods+ users still see the real nickname.
config | `/msg operserv config` var [value]
| Display / set a server configuration variable. When value is missing, OpenNap-NG displays the value of var. If value is specified, it sets the configuration variable.
connect | `/msg operserv connect` server [remote_server]
| Links the server running on server. If remote_server is specified, it tries to make a connection from remote_server to server instead of from the local server.
disconnect | `/msg operserv disconnect` server
| De-links a server from the cluster.
killserver | `/msg operserv killserver` server
| Causes the specified server to shut down (terminates the OpenNap-NG process).
links | `/msg operserv links`
| Display a list of all linked servers.
list_server | `/msg operserv list_server`
| Display the servers file, the list of known servers.
reconfig | `/msg operserv reconfig` var
| Resets the configuration variable var to its default value.
rehash | `/msg operserv rehash` [server]
| Causes the server to reload its configuration files.
server | `/msg operserv server` nick
| Displays which server a particular user is logged in through.
stats | `/msg operserv stats` server
| Displays stats about the server (uptime, bytes send/recv'd, etc).
userflags | `/msg operserv userflags` Nick FLAG
| Change userflags of a user. Flags can be Friend or None.
usermode | `/msg operserv usermode` [mode [mode ...]]
| Toggles the various server messages. Each message the server sends to mods+ is given a type so that if you don't want to see a particular type of message, you can simply turn it off and still see the other messages.
ERROR | error messages
BAN | server-wide ban messages
CHANGE | messages about user info being modified (password, etc.)
KILL | notifications when users are killed
LEVEL | notifications when a user's level is changed
SERVER | server link messages
MUZZLE | notifications about users being muzzled
PORT | notifications about user's data ports being changed
WALLOP | messages from other mods+
CLOAK | messages about mods+ being cloaked
FLOOD | server flood protection messages
PING | server ping messages (for lag detection)
MSG | private (instant) messages
WHOIS | whois notifications
To stop messages of a particular type, simply prefix the mode with a minus-sign (-). If you wish to only see a particular subset of messages, specify the ones you want with no prefix. You can also use the keyword `ALL` in conjunction with -<MODE> if you want "all but..."
whowas | `/msg operserv whowas` nick
| Displays information about a user that has recently logged out. Information is kept cached for who_was_time seconds.

## User levels

Each user on a OpenNap NG server has a level associated with them that tells the server which commands it may execute. When you first log into a server, you start out at level User. Userlevels are changed via a client command. The exact way is client-dependent, please consult the documentation of your client software how to accomplish it. For instance, in Lopster the command to enter at its chat page is `/level <username> <level>`. Userlevels can bet changed by Moderators, Admins and Elites only. Moderators can just change userlevels between User and Leech, Admins can additionally promote users to Moderators and Elites can set any user to any level. The following user levels are defined by Opennap NG

Level | Num. | Description
Leech | 0 | Leech is a term for someone who is a freeloader. This is the lowest user level of Opennap NG and is given to those users which are misbehaving in some way. Leeches can't do the following things: download files from other users join chat channels send messages to chat channels
User | 1 | A user is a plain-old-joe. This is what the vast majority of users are. Users may do the following: offer lists of files they share search for files from other users download files from other users upload files to other users send PMs to other users or Mods+ join existing chat channels create new chat channels (only if strict_channels is off)
Moderator | 2 | A moderator, or "mod" for short, has the ability to execute some of the administrative functions on the server. Moderators are especially responsible for keeping the order in chat channels and remove disturbing or otherwise misbheaving users. Moderators are assigned by Admins and Elites. A moderator can: kill - disconnect other users from the server muzzle - prevent other users from sending messages to chat channels or joining channels ban - prevent users from logging into the server change data port - reset the data port your client listens on for file transfers announce - send a message to all users wallop - send a message to all mods+ setuserlevel - change a user's level In addition, moderators have the ability to execute all ChanServ functions to adminster chat channels.
Admin | 3 | An admin is a special user level which allows you to execute all of the moderator functions, plus the following: link a server disconnect a server give moderator status to other users read (but not write) server configuration variables
Elite | 4 | An elite user is generally a server owner (the person who actually runs the OpenNap-NG software on their computer). They can basically do whatever they want. Don't step on their toes, these are the people providing you the service!

## Clients

The following is a list of known clients to support the Opennap NG server. Part of the administration of Opennap NG is carried out via clients. The bold entries are recommended clients, as they are

- full featured
- fully compliant to the protocol
- open source
- available for free
- well suited for administrating Opennap NG

Operating system | Client | Remark
Amiga | Amster |
Apple Macintosh | Drumbeat |
| Xnap | Best featured platform-independent client (Java)
BeOS | BeNapster |
Linux | AutoNap | Perl
BitchX | IRC napster plugin
Gnap | Project closed
Gnapster |
Gnome-Napster | Project closed, use Lopster instead
GTK Napster | Project closed, use Lopster instead
Knapster | Project closed
Lopster | Best featured and supported Linux GUI client (GTK+)
Nap | Command line client
TekNap | Formerly called BWap, standalone console Unix client based on bx-nap plugin for BitchX
Xnap | Best featured platform-independent client (Java)
iNapster | WWW interface
OS/2 | Napster/2 |
PMNapster | Project closed
Warpster |
QNX | Phaster |
RiscOS | Riscster |
Windows | AudioGnome |
CQ_EX |
Dagsta |
Duskster | Perl
FileNavigator |
Hackster |
Lopster (WinLop) | Windows port of the famous Lopster Linux client
Lopster Ramadev | Italian Windows port of Lopster
NapAmp | Napster plugin for WinAmp
Napster | Historical, meanwhile uses different protocol and software and has revived as a pay per transfer service
Napster Fast Search |
Rapigator |
Shuban |
Spotlight |
SunshineUN |
Swaptor |
WinLop | Windows port of the famous Lopster Linux client
WinMX |
Xnap | Best featured platform-independent client (Java)
Platform-independent: | Jnapster | Java
Jnap | Java
MyNapster Webclient |
WebNap | PHP
Xnap | Best featured platform-independent client (Java)
Xnapster | Java

## Glossary

Admin |  | A privileged user level, usually assigned to members of network staff only.
Bot |  | Bots are scripts (programs), mainly being used in the context of chat channels. They appear like normal users but usually run autonomous. Their complexity and purpose is highly variable. Some useful bots perform housekeeping duties, like detecting and ejecting channel flooders, greeting other users, attempt to start or manipulate discussions, offer helpful services like emitting server or channel statistics, acting as a chat gateway between different networks or provide some world news on request. Those bots are usually authorized or put in place by Mods+. However, there exist also evil bots, which are usually not authorized. Their most common intentions are either flood attacks of some sort or annoying people in chatrooms or via PM. Technically, bots are implemented via clients with scripting capabilities. For the Napster protocol this is mainly the TekNap client.
Channel operator |  | A channel operator, also known as a chanop or just op, is a user that is allowed to administer a chat channel. See ChanServ for a list of available commands. Channel operators have no special privileges outside of the channel they are opped in. Channel operator status is given either when a user is the first user to join a chat channel, or another channel operator makes a user a channel operator using the `op` command. All channel operators are equivalent, meaning that if you op a user, they can immediately deop you (remove your channel operator privilege). Note that being a channel operator is not a user level. Most channel operators are only normal users.
Client browse |  | Synonym for direct browse, opposite of server browse.
Clones |  | Usually each user who connects to a server has its own, distinct IP address. If multiple users with the same IP address connect to a server they are referred to as clones. A great number of clones from the same IP address can often be regarded a simple form of DoS attack, as each clone consumes one of the limited connections. With the max_clones setting Opennap NG offers to limit this sort of abuse. However, some users and especially Mods+ may wish to use at least one other clone without hostile intentions, maybe to test a secondary client, run a bot or because they have much more than max_shares files to offer and hence want to use two connections to offer separate collections of them. So accepting at least one clone (setting the variable to 2!) usually isn't a bad idea. If only higher user levels like Mods+ should be granted clones then the setting clones_allow_level should be used.
CVS |  | Concurrent Version System, a software system to allow multiple developers to work on a software packages, concurrently submit changes and track version history. Ordinary users are able to obtain any version of a software package from the entire version history tree via CVS. CVS is used by SourceForge for version controlling of and access to various software packages, including Opennap NG.
(Server) desync |  | If two or more servers are linked together to form a network they need to maintain a consistent state, that is, know which users are connected, what files are listed etc. It is possible that occasionally this consistency is lost for some reasons, i.e. server splits, floods, freezes or software bugs. If this happens, the results may be confusing for some users. For instance, a user may appear connected (visible) from one server but not connected (invisible) from another server of the same network. This is especially irritating when userswho want to chat in channels are affected. Similar inconsistencies apply to file lists. Servers can be resynced by manually unlinking and relinking them. Opennap NG versions prior to 0.49 are known to have contained a software bug which effectuated desync inconsistencies.
Direct browse |  | Opposite of server browse, also referred to as client bowse. A client who wants to retrieve the entire filelist of another user directly connects to that other user's client and receives the filelist from it. The server only mediates the request but isn't involved in the actual list data transfer, hence, no server bandwidth is consumed. Direct browses allow to retrieve the entire fileset of other users, even blocked files which were not accepted and aren't listed by the server. Direct browses are an advanced feature of the protocol which isn't supported by all clients. Both clients being involved have to support direct browse, otherwise server browse is used automatically. Since they save server resources, are faster and uncensored, direct browses are preferred over server browses.
DoS |  | Denial of Service, a common result of flood attacks against internet servers of all kinds. A large number of requests is sent to the server with the intention to overload it, cause it to freeze or crash. Opennap NG contains various settings to control possible flood attacks and limit their effects. No harmful large scale DoS attacks against Opennap NG servers have been reported so far.
Elite |  | Highest user level supported by Opennap NG. Usually only assigned to server owners.
Flood / flooding |  | If a client issues a large number of requests of any kind to the server, this is referred to as flooding. This isn't necessarily a hostile act. Some users simply issue a lot of searches or request a great number of file downloads, or even accept a great number of file uploads. In case of ghost kill deadlock floods the corresponding clients are usually misconfigured. If, however, a client starts to issue senseless, random or even disturbing requests in large numbers, intending to provoke a DoS, this is to be regarded a flood attack. Flood attacks, as well as non-hostile floodings, can cause the server to freeze (hang) or even crash. For this reason Opennap NG supports a number of settings to detect and deal with floods. It's generally up to the server owner to decide, how many requests in a given period are to be considered unblamable and from which number of requests on flooding is to be assumed.
Freeloader |  | A user who intends to download a significant number of files without offering own files in return. In other words: they take but refuse to give. Freeloaders share either very little or nothing or crap only when connecting to a server, or they block uploads to other users who request files from them. Freeloaders are often leeches as well, so these two terms are commonly used interchangably. Most server owners won't want to have freeloaders on their system. Freeloaders of the first sort can automatically be dealt with by settings like eject_when_full, eject_limit_files, eject_limit_libsize, min_file_size and the opennap-block.txt file.
Freeze |  | A server which is not responding to any requests, often because it's overloaded and still processing previous requests or experiences internet connection trouble. Freezes can last from a few seconds to several minutes. In most cases the server CPU will be utilized to 100% for these periods. Most freezes are of temporary nature, i.e. the server doesn't crash and will return to business. However, for the time the server freezes especially chatting users experience a severe lag.
Friend |  | A Friend is a user that can join the network at any time, even when the server is full and normally wouldn't accept any more logins by users. Friends are assigned by Mods+. With `/msg operserv userflags USERNAME Friend` you can give this status to any user. Important: For the Friend Flag the user must be a registered user at your network. For Mods+ the Friends flag has no meaning as they are allowed to login any time anyway.
Ghost |  | A ghost is a user whose connection to the server is lost without the server getting to know about this. Normally, when a user disconnects intentionally, the server receives a corresponding disconnect message from that client and immediately knows the user has left. It's a common symptom of dial-up or DSL internet connections of clients or unreliable or faulty network connection of the server that sometimes connections may break without the server getting informed about it. As a result, the server still believes the user is connected, while he is actually not. Those users are referred to as ghosts. Ghosts always stay silent and the actual user doesn't get anything of what is written to him in either public channels or via PM. Since becoming a ghost is almost always an involuntary and unexpected event, the actual user will most likely be trying to reconnect to the server. The user normally won't succeed, because the server believes the user is already and still being connected. Without ghost kill enabled the user would have to wait something between 10 and 30 minutes to be able to reconnect, until the server eventually realizes the connection is dead. This can be very annoying for users and confuse others, especially if the user was chatting when he became a ghost or when others are requesting files from a ghost. Those requests will stay unanswered on ghosts. Ghost kill turned on enables the user to immediately reconnect, despite the server believes he is already being connected. The existing, actually dead, connection will be removed and the user will be allowed to reconnect. Also, turning on ghost kill can save a tiny amount of server resources. Without ghost kill enabled the user will be trying to reconnect again and again, producing quite a bit of wasted incoming traffic and processing power of the server. This can be conserved if the user will be able to immediately reconnect. Most but not all ghost kills come along with a change of the IP address of the user. See also: ghost kill deadlock.
Ghost kill deadlock |  | Users who keep connecting and getting (ghost)killed by the server rather frequently, about once or twice per minute, are experiencing a ghost kill deadlock. All of them can only happen if ghost_kill is enabled. There are three possible reasons for this: 1. misconfigured clients (most common), 2. nick collisions, 3. flood attacks. Misconfigured client here refers to outdated server lists or server lists filled with wrong data. Only clients which support concurrent connections to multiple different networks are affected by this. Any given nick may connect only once to a network. It is possible that in the client's server list two servers appear as belonging to different networks while they actually belong to the same network. This may happen since servers sometimes change their network affiliations indeed. So the client believes it is attempting to connect to two different networks concurrently (which would be okay) while it is actually attempting to connect to two servers of the same network all the time. If both connection attempts use the same nick then the second successful connect will always eject the first successful connect. Usually the first one will immediately start to reconnect again, then ejecting the second one, and so on. Countermeasures: true nick collisions can be avoided / stopped if the affected nick gets registered by one of its users or a Mod+. Misconfigured clients and flood attacks are to be put down by banning their related nicks for some time. Disabling ghost kill at all is not recommended, since the number of harmless ghosts seeking a single, immediate reconnect uses to outweigh deadlocks by far.
GotNap |  | An internet service (http://www.gotnap.com) which can be used by public networks to advertise themselves. Clients may get network / server addresses to connect to from GotNap. New servers and networks who want to attract a large number of users have to advertise in GotNap. This service is up since summer 2004. It's the inofficial successor to Napigator, which provided similar services until early 2004.
IM / Instant Message |  | Basically a private message to another user. However, nowadays the term instant message is mostly used in context of instant messenger programs. Most of those programs feature buffering of messages, to be able to message other users even when they're offline. This isn't supported by Opennap NG. Other users being messaged must be connected to the same network at the time of the message being sent.
Lag |  | In public channels, each message sent by a user gets distributed by the server to all other users in the chat. If the server is mostly idle, this happens almost instantaneously. However, If a server is temporary overloaded or freezes, it either can't process any client requests at all or it takes some seconds for each.. This results in a notable delay between a message being sent by a user and that message becoming available to the other users in a channel. If this delay gets so long that it starts disturbing conversations (more than roughly 10 seconds) the server is said to experience lag or be laggy.
Leech |  | In Opennap NG, leech is a user level. In general, leeches are users who download an enormous amount of files, often from just a few other users, while sharing and / or uploading very little or nothing. Hence they resemble freeloaders and are generally not welcome on servers.
Moderator |  | An advanced user level.
Mods+ |  | All users with a level of Moderator or higher. Generally this refers to the staff of a server or network.
MOTD |  | Message Of The Day. This is the text the server sends to your client when you log in. In Opennap NG the MOTD is contained in file opennap-motd.txt and may be edited using any ASCII text editor. MOTDs may be coloured, which is to be controlled by escape codes. However, this is a feature being supported by few clients only.
Napigator |  | Formerly an internet service with its own website (http://www.napigator.com) and support software, where networks could be publicly advertised and clients got server addresses to connect to from. New servers and networks who want to attract a large number of users had to advertise in Napigator. Napigator has ceased its service in early 2004. Meanwhile GotNap provides a nearly identical and compatible network advertisment service. Technical references to Napigator in this manual are historic and can be regarded as applying to GotNap nowadays.
Net(work) |  | In Opennap NG context, a network is a pool of Opennap NG servers which are linked together to bundle their capacities, especially user and file counts. Servers of a network communicate with each other to maintain a consistent and synchronized state. This means, that all servers of a network should know whether and to which server particular users are connected, what files are searchable and what users are joined in what chat channels. If his client supports it, a user may be connected to several networks concurrently, but only to one server of a given network. Two users must be connected to the same network to be able to chat (publicly or privately) or exchange files via Opennap NG. Networks can be composed of a basically arbitrary number of servers. However, the more servers are linked together, the greater the internal synchronization overhead gets and more internet bandwidth is consumed. Note that in Opennap NG context even single servers, which aren't linked to any others, may be referred to as networks.
Nick |  | The name a user chose for his or her appearance in a network. Opennap NG connections are nick-based, that is, every connection to a server is associated with a nick. Users can choose and change their nicks nearly at will between sessions. However, most users rarely change their nicks, especially if they intend to chat with others. If a server allows clones, one user may connect to a server or network multiple times (up to max_clones times) concurrently, using a different nick for every connection. Nicks should commonly be between 2 and 20 characters long If alnum_nicks is enabled then nicks consisting of upper- and lowercase english letters, digits and characters "-" and "_" only are accepted.
Nick collision |  | Two or more unrelated users may chose the same nick, possibly a common one, and attempt to connect to a network concurrently. If ghost kill is disabled only the first one will succeed, followers will be rejected until the connection of the first one terminates. If ghost kill is enabled then a ghost kill deadlock may occur, where user A connects, gets ghost killed by user B, user B then gets ghost killed by user A, and so on. This can be avoided or stopped if one of the users registers himself with a private password. The other one(s) then won't be able to use the same nick any more as they don't know the password required to use that nick. Nick collisions are a pretty rare event.
Ping |  | Not to be confused with common IP (internet protocol) ping command and action, although the purpose is similar. In the Napster protocol, ping is a special command to test whether other clients are still alive and reachable and responding. The ping command is sent to the server which relays it to the target client. The target client should respond with an automatic pong then, which will be relayed back through the server to the pinging client. Although they appear to be present, other clients may actually not be reachable, for instance, because they have become ghosts or servers are desynced. Usually pings are emitted on manual request only. It's a good idea to precede especially PM conversations with a ping to confirm the other user can receive your messages and isn't ignoring you. In Napster protocol, incoming pings are to be answered automatically with a pong. Unfortunately some clients either don't support or ignore this feature. Hence, a missing pong doesn't always mean the peer is not reachable, while a successful pong always means it is.
PM / Private Message |  | Private Message, a text message which is sent from one user to another, not to be seen by others. Similar in meaning with instant messages Along with public chats and file exchange, PMs are a core feature of the Napster protocol on which Opennap NG bases. To be reachable via PM a user must be connected to the same server or network. Contrary to other server software, in the original (unmodified) Opennap NG server software private messages are really kept private, that is, they aren't stored or made visible to anyone else but the intended recipient. This also means, there is no buffering (as in instant messengers) if the recipient of the PM is currently offline. However, since Opennap NG is open source software, anyone with adequate programming skills would be able to change this fine behaviour. In fact, it is known that some server owners expressed a strong and sick desire to spy on private messages of their users. So users must not be absolutely sure their privacy is kept when communicating via PMs in this sort of network. In Opennap NG, the runtime server administration is mostly done via special PMs to the server.
Server browse |  | The opposite of direct browse. A server browse is initiated if a client wants to retrieve the entire filelist of another user, but either of their clients (or both) doesn't support direct browses. In this case the two clients don't contact each other to transmit the filelist. Instead, the stored copy of the requested filelist is sent from the server to the requestor. This may consume a lot of outgoing server bandwidth. Even more if the requestor and the requested user are connected to different servers (of the same network). Therefore, most servers limit the amount of file data being browsable via server browses. The max_browse_result setting is used to control this. Since they save server resources and are faster, direct browses are usually preferred by both server owners and users. Unfortunately only a few clients support direct browsing as yet.
(Server) split |  | Term used to describe when two linked servers become disconnected from one another (you can generally tell when this happens because if you are in a chat channel you will see a bunch of users leave at the same time).
Sping |  | A term meaning server ping, or how long it takes a server to see your data and respond.

###