For the standard VPS user, there are two useful cfg/ locations: User and Local. The "User" cfg/ will be located in ~/.byond most generally. The local cfg/ is never created unless you create it.
What is it?
cfg/ contains files that describe to DreamDaemon what it should do, including hostban.txt, keyban.txt, ipban.txt, admin.txt, and env.txt. ipban.txt/keyban.txt should be deprecated in favor of the new hostban.txt (DD Bans).
Why does this matter to me?
admin.txt and hostban.txt provide the functionality is more transparent with the Linux DreamDaemon than it is with the Windows equivalent. admin.txt grants keys 'admin' functionality, such as Profiling and Debugging, allowing you to do such things even in a deployed environment.
How do I use these?
The format for admin.txt is very extremely simple, and hostban.txt's format is only slightly different. The basic format is as follows:
key1 params1 key2 params2 ...
params uses the same basic format that GET uses:
param1=value1¶m2=value2¶m3=value3. For the key, use the ckey.
For admin.txt, the params have no significant other than for yourself. Generally 'role' is specified just for your own notes, but it's not necessary. In fact, no flags are necessary. Listing your ckey in admin.txt and then loading up DreamDaemon will give you the Profile, Reboot World, and other debugging options in DreamDaemon.
hostban.txt is only a little more complicated in that it's a little more flexible. Unfortunately, not all of the features that it currently provides are accessible to Linux users. Perhaps in the future we could manage to rally for them. Anyhow, a breakdown of hostban.txt:
hostban.txt's basic format is the same as admin.txt, except the params actually matter.
- flags - Bitflag (See below), this tells DreamDaemon when the ban is supposed to expire. Currently, session bans are not supported as we do not have a way to provoke DreamDaemon to reload hostban.txt.
- message - The message that is sent to the user when they attempt to login, url_encode()d.
- reason - The reason (internal) that the user was banned, also url_encode()d text.
- keys - Comma-delimited list of ckeys that are also wrapped up in this ban.
- time - The time at which the ban expires, based on Unix Epoch Time (`date +%s` in the command line)
Use a combination of the following values for the reason:
Session ban = 1 (doesn't work properly)
Timed ban = 2 (use 'time' flag)
Sticky ban = 4
Key only ban (no IP) = 8
So, for instance, if you want a sticky ban that expires at a certain time, you'd use 4 | 2 = 6.
A word on session bans
Session bans, if they are implemented, have their own way of working that isn't implemented in the params. Instead of using params, the pid (process id) is pre-pended to the key, to look like so:
That's all, folks! Stay tuned for more potential Linux goodies...