DragonFly BSD


DragonFly BSD Quick Start

This document describes the DragonFly environment one will find on a newly installed system. While you are getting started, please pay careful attention to the version or level of DragonFly that the documentation was written for.

Some Unix and BSD Fundamentals

If you have used another Unix flavor before, you may need to spend some time learning the differences between DragonFly and the system you are experienced in. If you have never used any flavor of Unix and have only used Windows or something else before, please be prepared for a lengthy period of learning.

If you already know your way around a Unix filesystem, and already know what the /etc folder is, how to use vi or vim or emacs to edit a file, how to use a shell like tcsh or ksh or bash, how to configure that shell, or change what shell you're using, how su and doas or sudo work, and what a root account is, the rest of this page may be enough to orient you to your surroundings.

Software/Programs and Configuration Files Location

The DragonFly default installation contains the base software/programs from the DragonFly project itself and additional software from other sources.

The base system binary software programs are located in the folders


The configuration files for the base system can be found in /etc. Third-party programs use /usr/local/etc.

There are several different ways to install software and which version you use depends on which DragonFly BSD version you have. You can compile things from source code, or you can use binary packages.

Disk layout of a New Dragonfly BSD System using the HAMMER filesystem

If you chose to install on the HAMMER file system during installation you will be left with a system with the following disk configuration:

# df -h
Filesystem                Size   Used  Avail Capacity  Mounted on
ROOT                      288G    12G   276G     4%    /
devfs                     1.0K   1.0K     0B   100%    /dev
/dev/serno/9VMBWDM1.s1a   756M   138M   558M    20%    /boot
/pfs/@@-1:00001           288G    12G   276G     4%    /var
/pfs/@@-1:00002           288G    12G   276G     4%    /tmp
/pfs/@@-1:00003           288G    12G   276G     4%    /usr
/pfs/@@-1:00004           288G    12G   276G     4%    /home
/pfs/@@-1:00005           288G    12G   276G     4%    /usr/obj
/pfs/@@-1:00006           288G    12G   276G     4%    /var/crash
/pfs/@@-1:00007           288G    12G   276G     4%    /var/tmp
procfs                    4.0K   4.0K     0B   100%    /proc

In this example

The disk label looks as follows:

# disklabel /dev/serno/9VMBWDM1.s1

# /dev/serno/9VMBWDM1.s1:
# Informational fields calculated from the above
# All byte equivalent offsets must be aligned
# boot space:    1044992 bytes
# data space:  312567643 blocks # 305241.84 MB (320069266944 bytes)
# NOTE: If the partition data base looks odd it may be
#       physically aligned instead of slice-aligned
diskid: e67030af-d2af-11df-b588-01138fad54f5
boot2 data base:      0x000000001000
partitions data base: 0x000000100200
partitions data stop: 0x004a85ad7000
backup label:         0x004a85ad7000
total size:           0x004a85ad8200    # 305242.84 MB
alignment: 4096
display block size: 1024        # for partition display only

16 partitions:
#          size     offset    fstype   fsuuid
  a:     786432          0    4.2BSD    #     768.000MB
  b:    8388608     786432      swap    #    8192.000MB
  d:  303392600    9175040    HAMMER    #  296281.836MB
  a-stor_uuid: eb1c8aac-d2af-11df-b588-01138fad54f5
  b-stor_uuid: eb1c8aec-d2af-11df-b588-01138fad54f5
  d-stor_uuid: eb1c8b21-d2af-11df-b588-01138fad54f5

The slice has 3 partitions:

When you create a HAMMER file system, you must give it a label. Here, the installer labelled it as "ROOT" and mounted it as

ROOT                      288G    12G   276G     4%    /

A PFS is a Pseudo File System inside a HAMMER file system. The HAMMER file system in which the PFSes are created is referred to as the root file system. You should not confuse the "root" file system with the label "ROOT": the label can be anything. The installer labeled it as ROOT because it is mounted at /.

Now inside the root HAMMER file system you find the installer created 7 PFSes from the df -h output above, let us see how they are mounted in /etc/fstab:

# cat /etc/fstab

# Device                Mountpoint      FStype  Options         Dump    Pass#
/dev/serno/9VMBWDM1.s1a         /boot           ufs     rw      1       1
/dev/serno/9VMBWDM1.s1b         none            swap    sw      0       0
/dev/serno/9VMBWDM1.s1d         /               hammer  rw      1       1
/pfs/var                /var            null    rw              0       0
/pfs/tmp                /tmp            null    rw              0       0
/pfs/usr                /usr            null    rw              0       0
/pfs/home               /home           null    rw              0       0
/pfs/usr.obj    /usr/obj                null    rw              0       0
/pfs/var.crash  /var/crash              null    rw              0       0
/pfs/var.tmp    /var/tmp                null    rw              0       0
proc                    /proc           procfs  rw              0       0

The PFSes are mounted using a NULL mount because they are also HAMMER file systems. You can read more on NULL mounts at the mount_null(8) manpage.

You don't need to specify a size for the PFSes like you do for logical volumes inside a volume group for LVM. All the free space in the root HAMMER file system is available to all the PFSes; it can be seen in the df -h output above that the free space is the same for all PFSes and the root HAMMER file system.

If you look in /var

# cd /var/
# ls
account   backups   caps   cron    empty   log   msgs   run   spool   yp  at        
cache     crash     db     games   lib     mail  preserve   rwho  tmp

you will find the above directories.

If you look at the status of one of the PFSes, e.g. /usr you will see /var/hammer is the default snapshot directory.

# hammer pfs-status /usr/
/usr/   PFS #3 {
    operating as a MASTER
    snapshots directory defaults to /var/hammer/<pfs>

At installation time, it will be seen that there is no hammer directory in /var. The reason for this is that no snapshots have yet been taken. You can verify this by checking the snapshots available for /usr

# hammer snapls /usr
Snapshots on /usr       PFS #3
Transaction ID          Timestamp               Note

Snapshots will appear automatically each night as the system performs housekeeping on the Hammer filesystem. For a new volume, an immediate snapshot can be taken by running the command 'hammer cleanup'. Among other activities, it will take a snapshot of the filesystem.

# sudo hammer cleanup
cleanup /                    - HAMMER UPGRADE: Creating snapshots
        Creating snapshots in /var/hammer/root
 handle PFS #0 using /var/hammer/root
           snapshots - run
               prune - run
           rebalance - run..
             reblock - run....
              recopy - run....
cleanup /var                 - HAMMER UPGRADE: Creating snapshots
cleanup /tmp                 - HAMMER UPGRADE: Creating snapshots
cleanup /usr                 - HAMMER UPGRADE: Creating snapshots
cleanup /home                - HAMMER UPGRADE: Creating snapshots
cleanup /usr/obj             - HAMMER UPGRADE: Creating snapshots
cleanup /var/crash           - HAMMER UPGRADE: Creating snapshots
cleanup /var/tmp             - HAMMER UPGRADE: Creating snapshots
cleanup /var/isos            - HAMMER UPGRADE: Creating snapshots

No snapshots were taken for /tmp, /usr/obj and /var/tmp. This is because the PFSes are flagged as nohistory. HAMMER tracks history for all files in a PFS. Naturally, this consumes disk space until history is pruned, at which point the available disk space will stabilise. To prevent temporary files on the mentioned PFSes (e.g., object files, crash dumps) from consuming disk space, the PFSes are marked as nohistory.

After performing nightly housekeeping, a new directory called hammer will be found in /var with the following sub directories:

# cd hammer/
# ls -l
total 0
drwxr-xr-x  1 root  wheel  0 Oct 13 11:51 home
drwxr-xr-x  1 root  wheel  0 Oct 13 11:42 root
drwxr-xr-x  1 root  wheel  0 Oct 13 11:43 tmp
drwxr-xr-x  1 root  wheel  0 Oct 13 11:51 usr
drwxr-xr-x  1 root  wheel  0 Oct 13 11:54 var

Looking inside /var/hammer/usr, one finds:

# cd usr/
# ls -l
total 0
drwxr-xr-x  1 root  wheel   0 Oct 13 11:54 obj
lrwxr-xr-x  1 root  wheel  25 Oct 13 11:43 snap-20101013-1143 -> /usr/@@0x0000000117ac6cb0

We have a symlink pointing to the snapshot transaction ID shown below.

# hammer snapls /usr
Snapshots on /usr       PFS #3
Transaction ID          Timestamp               Note
0x0000000117ac6cb0      2010-10-13 11:43:04 IST -

You can read more about snapshots, prune, rebalance, reblock, recopy etc from hammer(8). Make especially sure to look under the heading "cleanup [filesystem ...]".

You can learn more about PFS mirroring here

In order to correctly map hard disk sernos to device names you can use the 'devattr' command.

# udevd
# devattr -d "ad*" -p serno
Device ad4:
        serno = Z2AD9WN4
Device ad4s1:
Device ad4s1d:

Device ad5:
        serno = 9VMRFDSY
Device ad5s1:
Device ad5s1d:

Device ad3:
        serno = Z2AD9WLW
Device ad3s1:
Device ad3s1a:
Device ad3s1b:
Device ad3s1d:

If your disks are 'da', change as appropriate.


OpenSSH is a set of network connectivity tools used to access remote machines securely. It can be used as a direct replacement for rlogin, rsh, rcp, and telnet. Additionally, any other TCP/IP connections can be tunneled/forwarded securely through SSH. OpenSSH encrypts all traffic to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks.

OpenSSH is maintained by the OpenBSD project, and is based upon SSH v1.2.12 with all the recent bug fixes and updates. It is compatible with both SSH protocols 1 and 2.

Advantages of Using OpenSSH

Normally, when using telnet(1) or rlogin(1), data is sent over the network in an clear, un-encrypted form. Network sniffers anywhere in between the client and server can steal your user/password information or data transferred in your session. OpenSSH offers a variety of authentication and encryption methods to prevent this from happening.

SSH Client

The ssh(1) utility works similarly to rlogin(1), at this point if you try to ssh to the DragonFly you will get the following error:

% ssh sgeorge@
The authenticity of host ' (' can't be established.
RSA key fingerprint is 46:77:28:c2:70:86:93:1a:23:32:5f:01:2c:80:de:de.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (RSA) to the list of known hosts.
Permission denied (publickey,password,keyboard-interactive).

This is because of the following configuration option in the default /etc/ssh/sshd_config file:

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no

Change it to:

PasswordAuthentication yes

and reload sshd configuration:

# /etc/rc.d/sshd reload
Reloading sshd config files.

Now you can login to the dragonfly system as a normal user:

% ssh sgeorge@
sgeorge at's password:

The login will continue just as it would have if a session was created using rlogin or telnet. SSH utilizes a key fingerprint system for verifying the authenticity of the server when the client connects. The user is prompted to enter yes only when connecting for the first time. Future attempts to login are all verified against the saved fingerprint key. The SSH client will alert you if the saved fingerprint differs from the received fingerprint on future login attempts. The fingerprints are saved in ~/.ssh/known_hosts, or ~/.ssh/known_hosts2 for SSH v2 fingerprints.

By default, OpenSSH servers are configured to accept both SSH v1 and SSH v2 connections. The client, however, can choose between the two. Version 2 is known to be more robust and secure than its predecessor.

The ssh(1) command can be forced to use either protocol by passing it the -1 or -2 argument for v1 and v2, respectively.

Secure Copy

The scp(1) command works similarly to rcp(1); it copies a file to or from a remote machine, except in a secure fashion.

#  scp user@example.com:/COPYRIGHT COPYRIGHT
user@example.com's password: *******
COPYRIGHT            100% |*****************************|  4735

The arguments passed to scp(1) are similar to cp(1), with the file or files in the first argument, and the destination in the second. Since the file is fetched over the network, through SSH, one or more of the file arguments takes on the form user@host:<path_to_remote_file>. The user@ part is optional. If omitted, it will default to the same username as you are currently logged in as, unless configured otherwise.


The system-wide configuration files for both the OpenSSH daemon and client reside within the /etc/ssh directory.

If you look in /etc/ssh, you will find the SSH host key files:

% ls /etc/ssh
moduli                          ssh_host_ecdsa_key              ssh_host_rsa_key
ssh_config                      ssh_host_ecdsa_key.pub          ssh_host_rsa_key.pub
ssh_host_dsa_key                ssh_host_ed25519_key            sshd_config
ssh_host_dsa_key.pub            ssh_host_ed25519_key.pub

ssh_config configures the client settings, while sshd_config configures the daemon.

Additionally, the sshd_program (/usr/sbin/sshd by default), and sshd_flags rc.conf(5) options can provide more levels of configuration.

Each user can have a personal configuration file in ~/.ssh/config. The file can configure various client options, and can include host-specific options. With the following configuration file, a user could type ssh shell which would be equivalent to ssh -X user@shell.example.com:

Host shell
Hostname shell.example.com
Username user
Protocol 2
ForwardX11 yes

Login as root

If you try to login by SSH as root you will get the following error.

% ssh root@
root at's password:
Permission denied, please try again.

If you investigate the log of the dragonfly system /var/log/auth.log you will find a line similar to:

Oct 19 07:29:36 dfly-vmsrv sshd[17269]: Failed password for root from port 56447 ssh2

even if you typed the right password for root.

If you want to log in as root, change the following line in /etc/ssh/sshd_config file:

#PermitRootLogin prohibit-password


PermitRootLogin yes

and reload sshd configuration:

# /etc/rc.d/sshd reload
Reloading sshd config files.

you can login as root:

% ssh root@
root at's password:
Last login: Fri Jan 12 02:01:22 2018
DragonFly v5.0.2-RELEASE (X86_64_GENERIC) #4: Sun Dec  3 17:42:25 EST 2017

Welcome to DragonFly!


Now in the /var/log/auth.log you will find a line similar to

Oct 19 07:30:32 dfly-vmsrv sshd[17894]: Accepted password for root from port 56468 ssh2


It is not advisable to allow Root Login with password especially if your System is connected to the Internet unless you use Very Strong Passwords. You could be a victim of ssh password based brute force attacks. If you are victim of one such attack you can find entries like the following in your /var/log/auth.log file.

Oct 18 18:54:54 cross sshd[9783]: Invalid user maryse from
Oct 18 18:54:54 cross sshd[9781]: input_userauth_request: invalid user maryse
Oct 18 18:54:54 cross sshd[9783]: Failed password for invalid user maryse from port 34847 ssh2
Oct 18 18:54:54 cross sshd[9781]: Received disconnect from 11: Bye Bye
Oct 18 18:54:55 cross sshd[27641]: Invalid user may from
Oct 18 18:54:55 cross sshd[3450]: input_userauth_request: invalid user may
Oct 18 18:54:55 cross sshd[27641]: Failed password for invalid user may from port 34876 ssh2
Oct 18 18:54:55 cross sshd[3450]: Received disconnect from 11: Bye Bye
Oct 18 18:54:56 cross sshd[8423]: Invalid user admin from
Oct 18 18:54:56 cross sshd[3131]: input_userauth_request: invalid user admin
Oct 18 18:54:56 cross sshd[8423]: Failed password for invalid user admin from port 34905 ssh2
Oct 18 18:54:56 cross sshd[3131]: Received disconnect from 11: Bye Bye
Oct 18 18:54:57 cross sshd[7373]: Invalid user admin from
Oct 18 18:54:57 cross sshd[28059]: input_userauth_request: invalid user admin
Oct 18 18:54:57 cross sshd[7373]: Failed password for invalid user admin from port 34930 ssh2
Oct 18 18:54:57 cross sshd[28059]: Received disconnect from 11: Bye Bye
Oct 18 18:54:58 cross sshd[12081]: Invalid user admin from
Oct 18 18:54:58 cross sshd[22416]: input_userauth_request: invalid user admin
Oct 18 18:54:58 cross sshd[12081]: Failed password for invalid user admin from port 34958 ssh2
Oct 18 18:54:58 cross sshd[22416]: Received disconnect from 11: Bye Bye


Instead of using passwords, ssh-keygen(1) can be used to generate RSA keys to authenticate a user:

% ssh-keygen -t rsa1
Initializing random number generator...
Generating p:  .++ (distance 66)
Generating q:  ..............................++ (distance 498)
Computing the keys...
Key generation complete.
Enter file in which to save the key (/home/user/.ssh/identity):
Enter passphrase:
Enter the same passphrase again:
Your identification has been saved in /home/user/.ssh/identity.

ssh-keygen(1) will create a public and private key pair for use in authentication. The private key is stored in ~/.ssh/identity, whereas the public key is stored in ~/.ssh/identity.pub. The public key must be placed in ~/.ssh/authorized_keys of the remote machine in order for the setup to work.

This will allow connection to the remote machine based upon RSA authentication instead of passwords.

Note: The -t rsa1 option will create RSA keys for use by SSH protocol version 1. If you want to use RSA keys with the SSH protocol version 2, you have to use the command ssh-keygen -t rsa.

If a passphrase is used in ssh-keygen(1), the user will be prompted for a password each time in order to use the private key.

A SSH protocol version 2 DSA key can be created for the same purpose by using the ssh-keygen -t dsa command. This will create a public/private DSA key for use in SSH protocol version 2 sessions only. The public key is stored in ~/.ssh/id_dsa.pub, while the private key is in ~/.ssh/id_dsa.

DSA public keys are also placed in ~/.ssh/authorized_keys on the remote machine.

ssh-agent(1) and ssh-add(1) are utilities used in managing multiple passworded private keys.

Warning: The various options and files can be different according to the OpenSSH version you have on your system, to avoid problems you should consult the ssh-keygen(1)] manual page.

SSH Tunneling

OpenSSH has the ability to create a tunnel to encapsulate another protocol in an encrypted session.

The following command tells ssh(1) to create a tunnel for telnet :

% ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com

The ssh command is used with the following options:


:: Forces ssh to use version 2 of the protocol. (Do not use if you are working with older SSH servers)


:: Indicates no command, or tunnel only. If omitted, ssh would initiate a normal session.


:: Forces ssh to run in the background.


:: Indicates a local tunnel in ***localport:remotehost:remoteport*** fashion.


:: The remote SSH server.

An SSH tunnel works by creating a listen socket on localhost on the specified port. It then forwards any connection received on the local host/port via the SSH connection to the specified remote host and port.

In the example, port ***5023*** on localhost is being forwarded to port ***23*** on localhost of the remote machine. Since ***23*** is telnet , this would create a secure telnet session through an SSH tunnel.

This can be used to wrap any number of insecure TCP protocols such as SMTP, POP3, FTP, etc.

Example 10-1. Using SSH to Create a Secure Tunnel for SMTP

% ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com
user@mailserver.example.com's password: *****
% telnet localhost 5025
Connected to localhost.
Escape character is '^]'.
220 mailserver.example.com ESMTP

This can be used in conjunction with an ssh-keygen(1) and additional user accounts to create a more seamless/hassle-free SSH tunneling environment. Keys can be used in place of typing a password, and the tunnels can be run as a separate user.

Practical SSH Tunneling Examples

Secure Access of a POP3 Server

At work, there is an SSH server that accepts connections from the outside. On the same office network resides a mail server running a POP3 server. The network, or network path between your home and office may or may not be completely trustable. Because of this, you need to check your e-mail in a secure manner. The solution is to create an SSH connection to your office's SSH server, and tunnel through to the mail server:

% ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com
user@ssh-server.example.com's password: ******

When the tunnel is up and running, you can point your mail client to send POP3 requests to localhost port 2110. A connection here will be forwarded securely across the tunnel to mail.example.com.

Bypassing a Draconian Firewall

Some network administrators impose extremely draconian firewall rules, filtering not only incoming connections, but outgoing connections. You may be only given access to contact remote machines on ports 22 and 80 for SSH and web surfing.

You may wish to access another (perhaps non-work related) service, such as an Ogg Vorbis server to stream music. If this Ogg Vorbis server is streaming on some other port than 22 or 80, you will not be able to access it.

The solution is to create an SSH connection to a machine outside of your network's firewall, and use it to tunnel to the Ogg Vorbis server.

% ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org
user@unfirewalled-system.example.org's password: *******

Your streaming client can now be pointed to localhost port 8888, which will be forwarded over to music.example.com port 8000, successfully evading the firewall.