Getting started

From zero to a running hub in a few simple steps.

1. Build uhub

Download the sources and compile them. On most systems this is just CMake and make.

2. Create a configuration file

This step is optional — if no configuration files are present, uhub starts with sensible defaults. To customise the hub, edit /etc/uhub/uhub.conf as root:

hub_name = My Public Hub
hub_description = Yet another ADC hub

server_port = 1511
server_bind_addr = any
max_users = 150

3. Start the hub

Run uhub in the foreground for the first time. Stop it with Ctrl+C.

$ uhub
INFO: Starting server, listening on :::1511...

4. Connect with a client

Point an ADC client at adc://localhost:1511, replacing localhost with the correct hostname or IP address.

Note: the adc:// prefix and the port number are required when connecting with DC++ and other ADC clients.

5. Register users (optional)

Registered accounts are served by an authentication plug-in. The usual choice is mod_auth_sqlite: create the database with uhub-passwd, add an administrator, and point the plug-in at it.

uhub-passwd /etc/uhub/users.db create
uhub-passwd /etc/uhub/users.db add alice s3cr3t admin

Then in plugins.conf:

plugin /var/lib/uhub/mod_auth_sqlite.so "file=/etc/uhub/users.db"

Changed in 0.8.0: accounts are no longer defined in the file_acl ACL file. If you are upgrading, migrate any user_admin / user_op / user_reg lines into an auth plug-in — the ACL file now holds only bans and denied nicks. To let users register themselves instead, add mod_selfregister.

6. Use all CPU cores (optional)

uhub is single-threaded, so a single process uses one CPU core. On a multi-core machine you can run the hub as several linked worker processes that share the client port and together present one logical hub. Set in uhub.conf:

workers = 4      # number of worker processes, or 0 for one per CPU core

The top-level process then becomes a master that forks the workers, supervises them (restarting any that exit) and serves no clients itself. Each worker binds server_port with SO_REUSEPORT, so the kernel load-balances incoming connections across cores, and the workers link to each other over Unix sockets in worker_socket_dir (default /tmp) to share one user list and SID space. This mainly speeds up the CPU-bound per-connection work — notably TLS.

Running one hub across cores is a special case of hub linking (federation), which can also join hubs across separate machines. See that guide for the full picture and the trade-offs.

Your mileage may vary — good luck!