Gdam can be run in many modes, the best one for you depends on how you want to use it.
if you always use gdam through gdam-launcher then it should be completely secure to run it in secure mode, letting it run the server for you.
Serious users will find the convenience of having multiple client connections very valuable; we really intend this more as a "demo" mode, for playing with few security worries.
If you run gdam on a network where you don't trust the computers directly connected to you (for example, if you are on the internet and don't have a firewall), you can add Bind Localhostto the config file to prevent other computers from connecting.
if you more-or-less trust the computers in your network you can probably run gdam without Bind Localhost fairly safely. Make certain that gdam-server ddrops priviledges from root. (use ps)
If you wish to run gdam realtime you will have to run it as root. This is also a situation you must consider if you run gdam-server from an initscript.
If you add Username and Group tags to the configuration file and run it as root, gdam-server drops to that identity before opening the audio devices. This means that the user or group must have unix permission to open sound devices. Either
the audio device must be owned and writable by the specified Username.
the audio device must be owned and writable by the specified Group.
If you don't know what to do, we recommend making your audio devices readable and writable by a group "audio" (which you may have to create using the addgroup or groupadd or by editting /etc/group directly. This boils down to:
% addgroup audio
# may complain if the group exists.
% chgrp audio /dev/dsp*
% chmod 660 /dev/dsp*
# alsa users should add /dev/snd/pcm* |