DOLDACOND(8) Dolda Connect manual DOLDACOND(8) NAME doldacond - Dolda Connect daemon SYNOPSIS doldacond [ -hnsV ] [ -C configfile ] [ -p pidfile ] [ -f facility ] DESCRIPTION The doldacond program is the primary part of the collection of software that makes up Dolda Connect. It runs in the background and carries out all the actual work of filesharing. Other programs, such as dolcon(1), connect to doldacond over a socket in order to command it and/or dis‐ play its status to a user. The configuration of doldacond is controlled via the doldacond.conf(5) file, which is described in detail in its own manual page. OPTIONS -h Displays a brief usage message on stdout and exits. -s Normally, doldacond will print log messages to stderr before it has daemonized, and switch to syslog output after daemonization. With the -s option, however, it will log to syslog directly, and never to stderr. It is probably only useful when starting dolda‐ cond from an init script. -n Causes doldacond to not daemonize. As a side-effect of avoiding daemonization, log messages will be printed to stderr rather than to syslog even after the point where the daemon would nor‐ mally have daemonized (unless the -s option is also specified). -V Displays version and build information on stdout and exits. -C configfile Use configfile instead of the normal search list for configura‐ tion files. See doldacond.conf(5) for the normal behavior. -p pidfile Write the daemon’s PID to pidfile after daemonization. Works even if the -n option has been specified. -f facility Use facility when logging to syslog. The facility can be any of auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, sys‐ log, user, uucp or local0...7, although only a subset probably make sense for doldacond. The default is daemon. Also see the BUGS section. FILES The configuration file will normally be called /usr/local/etc/dolda‐ cond.conf, /etc/doldacond.conf or ~/.doldacond.conf, but a multitude of others are possible. See the doldacond.conf(5) manual page for details. SIGNALS SIGHUP Causes the daemon to reread its configuration file and update its operation accordingly, and to rescan all shared directories. SIGHUP can safely be sent at any time - no connected clients or hubs will be affected. SIGINT, SIGTERM Shut down the daemon cleanly, unlinking temporary files and sockets. SIGUSR1, SIGUSR2 Used for debugging. USR1 will cause the daemon to fork and dump a core file, and USR2 will dump some memory usage information to /tmp. SECURITY Dolda Connect, including doldacond and its assorted clients, are capa‐ ble of a number of different authentication methods. The default con‐ figuration will cause the daemon to only listen for client connections on a Unix socket, over which authentication will be made using Unix credentials passing. When running clients over a network, authentication can be done using either PAM, Kerberos 5 (requires the MIT libraries) or client trust (no authentication). Unix credentials passing and Kerberos authentication should be perfectly secure. PAM authentication should be secure in itself, but the client protocol is not encrypted, and therefore causes passwords to be sent over the network in the clear. Authentication-less operation is, obviously, not secure at all and is disabled by default. It may be useful on a trusted network, however. BUGS doldacond has proved to be surprisingly stable. I have had it running for far longer than a month without any sign of instability or memory leaks, which is probably a lot longer than a program of this kind really needs to be able to stay running. That said, it is not without bugs. Here follows a list of the more prominent ones. Most importantly, doldacond will fail miserably at sharing files from filesystems that do not have persistent i-numbers, since hashes are indexed by the i-number of the file. This is done so because indexing by i-numbers rather than file names allows the daemon to not rehash files that have merely been renamed. However, among the filesystems that do not have persistent i-numbers is the Linux implementation of FAT, which means that it is impossible to share files that are shared with Microsoft Windows. All the standard Unix filesystems, including at least ufs, ext2/3, reiserfs, xfs or any of them shared over nfs are known to be safe. From time to time, the hash controller can get stuck, and stop process‐ ing more files. The obvious work-around is to restart doldacond, at which point it will continue where it left off. If you feel adventurous and/or really need to not restart it, you can attach gdb(1) (or your debugger of choice) to the running doldacond process and set the hashjob variable to -1, which will force doldacond to resume hashing. Don’t do that while a hash job is actually running, though. AUTHOR Fredrik Tolf SEE ALSO doldacond.conf(5), dolcon(1) 2008-02-14 DOLDACOND(8)