1 # DragonFly BSD Quick Start
3 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.
7 ## Some Unix and BSD Fundamentals
9 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.
11 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.
14 ## Software/Programs and Configuration Files Location
16 The DragonFly default installation contains the base software/programs from the DragonFly project itself and additional software from other sources.
18 The base system binary software programs are located in the folders
25 The configuration files for the base system can be found in `/etc`. Third-party programs use `/usr/local/etc`.
27 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.
29 ## Disk layout of a New Dragonfly BSD System using the HAMMER2 filesystem
31 HAMMER2 is now the default filesystem selected by the installer. It is not quite as feature-full as HAMMER in that there are no automatic snapshots and no undo feature, but HAMMER2 is more robust than HAMMER1 and also sports writable snapshots whereas HAMMER1 only has read-only snapshots. HAMMER2 is also a bit easier to manage.
33 If you chose to install on the HAMMER2 file system during installation you will be left with a system with the following disk configuration:
36 Filesystem Size Used Avail Capacity Mounted on
37 /dev/serno/9VMBWDM1.s1d 288G 12G 276G 4% /
38 devfs 1.0K 1.0K 0B 100% /dev
39 /dev/serno/9VMBWDM1.s1a 1G 500M 500M 50% /boot
40 /dev/serno/9VMBWDM1.s1e 100G 1M 100G 0% /build
41 /build/usr.obj * * * * /usr/obj
42 /build/usr.distfiles * * * * /usr/distfiles
43 /build/var.cache * * * * /var/cache
44 /build/var.crash * * * * /var/crash
45 tmpfs 8G 0B 8G 0% /tmp
46 tmpfs 8G 0B 8G 0% /var/tmp
47 procfs 4.0K 4.0K 0B 100% /proc
50 ## Disk layout of a New Dragonfly BSD System using the older HAMMER1 filesystem
52 If you chose to install on the HAMMER file system during installation you will be left with a system with the following disk configuration:
55 Filesystem Size Used Avail Capacity Mounted on
56 ROOT 288G 12G 276G 4% /
57 devfs 1.0K 1.0K 0B 100% /dev
58 /dev/serno/9VMBWDM1.s1a 1G 500M 500M 50% /boot
59 BUILD 100G 1M 100G 0% /build
60 /build/usr.obj * * * * /usr/obj
61 /build/usr.distfiles * * * * /usr/distfiles
62 /build/var.cache * * * * /var/cache
63 /build/var.crash * * * * /var/crash
64 tmpfs 8G 0B 8G 0% /tmp
65 tmpfs 8G 0B 8G 0% /var/tmp
66 procfs 4.0K 4.0K 0B 100% /proc
70 * `/dev/serno/9VMBWDM1` is the hard disk specified with serial number,
71 * `/dev/serno/9VMBWDM1.s1` is the first slice on the hard disk.
72 * The path-to-path mounts are called NULL mounts, they just alias a directory from one place to another.
74 The disk label looks as follows. Please note that the sizes are just examples, every drive will be different and the label will be populated accordingly. When creating a label you can use '*' to have the disklabel program automatically calculate offset and size parameters so the only offset/size you need to specify is the '0' offset for the 'a' partition.
76 # disklabel /dev/serno/9VMBWDM1.s1
78 # /dev/serno/9VMBWDM1.s1:
80 # Informational fields calculated from the above
81 # All byte equivalent offsets must be aligned
83 # boot space: 1044992 bytes
84 # data space: 312567643 blocks # 305241.84 MB (320069266944 bytes)
86 # NOTE: If the partition data base looks odd it may be
87 # physically aligned instead of slice-aligned
89 diskid: e67030af-d2af-11df-b588-01138fad54f5
91 boot2 data base: 0x000000001000
92 partitions data base: 0x000000100200
93 partitions data stop: 0x004a85ad7000
94 backup label: 0x004a85ad7000
95 total size: 0x004a85ad8200 # 305242.84 MB
97 display block size: 1024 # for partition display only
100 # size offset fstype fsuuid
101 a: 1048576 0 4.2BSD # 1024.000MB
102 b: 8388608 786432 swap # 8192.000MB
103 d: 303392600 9175040 HAMMER2 # 296281.836MB
104 e: * * HAMMER2 # blah blah ('e' partition is optional)
105 a-stor_uuid: eb1c8aac-d2af-11df-b588-01138fad54f5
106 b-stor_uuid: eb1c8aec-d2af-11df-b588-01138fad54f5
107 d-stor_uuid: eb1c8b21-d2af-11df-b588-01138fad54f5
110 The slice has 3 or 4 partitions:
114 * `d` - for `/`, a HAMMER or HAMMER2 filesystem labeled ROOT
115 * `e` - for `/build`, a HAMMER or HAMMER2 filesystem labeled (typically) DATA
117 When you create a HAMMER filesystem, you must give it a label. Here, the installer labelled it as "ROOT" and mounted it as
119 ROOT 288G 12G 276G 4% /
121 When you create a HAMMER2 filesystem the label is optional and a default will be supplied based on the partition letter. Either BOOT, ROOT, SWAP, or DATA.
125 In HAMMER2 the filesystem is typically mounted via its default label. There is no distinction between this PFS and others you might create. You can create additional PFSs or you can snapshot an existing PFS and specify a new PFS name for the snapshot. In HAMMER2, all snapshots must be independently mounted. In addition, HAMMER2 snapshots are writable entities and you can use them just as you would the original filesystem.
127 HAMMER2 does not do automatic history, snapshotting, or undo. You have to snapshot a filesystem manually with the 'hammer2' utility.
129 ## HAMMER1 PFSs (only applicable to HAMMER1)
131 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 `/`.
133 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`:
137 # Device Mountpoint FStype Options Dump Pass#
138 /dev/serno/9VMBWDM1.s1a /boot ufs rw 1 1
139 /dev/serno/9VMBWDM1.s1b none swap sw 0 0
140 /dev/serno/9VMBWDM1.s1d / hammer rw 1 1
141 /pfs/var /var null rw 0 0
142 /pfs/tmp /tmp null rw 0 0
143 /pfs/usr /usr null rw 0 0
144 /pfs/home /home null rw 0 0
145 /pfs/usr.obj /usr/obj null rw 0 0
146 /pfs/var.crash /var/crash null rw 0 0
147 /pfs/var.tmp /var/tmp null rw 0 0
148 proc /proc procfs rw 0 0
151 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)](http://leaf.dragonflybsd.org/cgi/web-man?command=mount_null§ion=8) manpage.
153 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.
155 If you look in `/var`
159 account backups caps cron empty log msgs run spool yp at
160 cache crash db games lib mail preserve rwho tmp
162 you will find the above directories.
164 If you look at the status of one of the PFSes, e.g. `/usr` you will see `/var/hammer` is the default snapshot directory.
166 # hammer pfs-status /usr/
168 sync-beg-tid=0x0000000000000001
169 sync-end-tid=0x0000000117ac6270
170 shared-uuid=f33e318e-d2af-11df-b588-01138fad54f5
171 unique-uuid=f33e31cb-d2af-11df-b588-01138fad54f5
174 operating as a MASTER
175 snapshots directory defaults to /var/hammer/<pfs>
178 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`
181 Snapshots on /usr PFS #3
182 Transaction ID Timestamp Note
184 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.
186 # sudo hammer cleanup
187 cleanup / - HAMMER UPGRADE: Creating snapshots
188 Creating snapshots in /var/hammer/root
189 handle PFS #0 using /var/hammer/root
195 cleanup /var - HAMMER UPGRADE: Creating snapshots
197 cleanup /tmp - HAMMER UPGRADE: Creating snapshots
199 cleanup /usr - HAMMER UPGRADE: Creating snapshots
201 cleanup /home - HAMMER UPGRADE: Creating snapshots
203 cleanup /usr/obj - HAMMER UPGRADE: Creating snapshots
205 cleanup /var/crash - HAMMER UPGRADE: Creating snapshots
207 cleanup /var/tmp - HAMMER UPGRADE: Creating snapshots
209 cleanup /var/isos - HAMMER UPGRADE: Creating snapshots
212 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`.
214 After performing nightly housekeeping, a new directory called *hammer* will be found in `/var` with the following sub directories:
219 drwxr-xr-x 1 root wheel 0 Oct 13 11:51 home
220 drwxr-xr-x 1 root wheel 0 Oct 13 11:42 root
221 drwxr-xr-x 1 root wheel 0 Oct 13 11:43 tmp
222 drwxr-xr-x 1 root wheel 0 Oct 13 11:51 usr
223 drwxr-xr-x 1 root wheel 0 Oct 13 11:54 var
226 Looking inside `/var/hammer/usr`, one finds:
231 drwxr-xr-x 1 root wheel 0 Oct 13 11:54 obj
232 lrwxr-xr-x 1 root wheel 25 Oct 13 11:43 snap-20101013-1143 -> /usr/@@0x0000000117ac6cb0
235 We have a symlink pointing to the snapshot transaction ID shown below.
238 Snapshots on /usr PFS #3
239 Transaction ID Timestamp Note
240 0x0000000117ac6cb0 2010-10-13 11:43:04 IST -
243 You can read more about snapshots, prune, rebalance, reblock, recopy etc from [hammer(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=hammer§ion=8). Make especially sure to look under the heading "cleanup [filesystem ...]".
245 You can learn more about PFS mirroring [here](http://www.dragonflybsd.org/docs/how_to_implement_hammer_pseudo_file_system__40___pfs___41___slave_mirroring_from_pfs_master/)
247 In order to correctly map hard disk sernos to device names you can use the 'devattr' command.
250 # devattr -d "ad*" -p serno
268 If your disks are 'da', change as appropriate.
272 **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.
274 **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.
276 ### Advantages of Using OpenSSH
278 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.
282 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:
284 % ssh sgeorge@172.16.50.62
285 The authenticity of host '172.16.50.62 (172.16.50.62)' can't be established.
286 RSA key fingerprint is 46:77:28:c2:70:86:93:1a:23:32:5f:01:2c:80:de:de.
287 Are you sure you want to continue connecting (yes/no)? yes
288 Warning: Permanently added '172.16.50.62' (RSA) to the list of known hosts.
289 Permission denied (publickey,password,keyboard-interactive).
291 This is because of the following configuration option in the default **/etc/ssh/sshd_config** file:
293 # To disable tunneled clear text passwords, change to no here!
294 PasswordAuthentication no
298 PasswordAuthentication yes
300 and reload **sshd** configuration:
302 # /etc/rc.d/sshd reload
303 Reloading sshd config files.
305 Now you can login to the dragonfly system as a normal user:
307 % ssh sgeorge@172.16.50.62
308 sgeorge at 172.16.50.62's password:
310 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.
312 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.
314 The ssh(1) command can be forced to use either protocol by passing it the `-1` or `-2` argument for v1 and v2, respectively.
318 The scp(1) command works similarly to rcp(1); it copies a file to or from a remote machine, except in a secure fashion.
320 # scp user@example.com:/COPYRIGHT COPYRIGHT
321 user@example.com's password: *******
322 COPYRIGHT 100% |*****************************| 4735
326 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.
330 The system-wide configuration files for both the **OpenSSH** daemon and client reside within the **/etc/ssh** directory.
332 If you look in **/etc/ssh**, you will find the SSH host key files:
335 moduli ssh_host_ecdsa_key ssh_host_rsa_key
336 ssh_config ssh_host_ecdsa_key.pub ssh_host_rsa_key.pub
337 ssh_host_dsa_key ssh_host_ed25519_key sshd_config
338 ssh_host_dsa_key.pub ssh_host_ed25519_key.pub
340 **ssh_config** configures the client settings, while **sshd_config** configures the daemon.
342 Additionally, the **sshd_program** (**/usr/sbin/sshd** by default), and **sshd_flags** rc.conf(5) options can provide more levels of configuration.
344 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**:
347 Hostname shell.example.com
354 If you try to login by SSH as root you will get the following error.
356 % ssh root@172.16.50.62
357 root at 172.16.50.62's password:
358 Permission denied, please try again.
360 If you investigate the log of the dragonfly system **/var/log/auth.log** you will find a line similar to:
362 Oct 19 07:29:36 dfly-vmsrv sshd[17269]: Failed password for root from 172.16.2.0 port 56447 ssh2
364 even if you typed the right password for root.
366 If you want to log in as root, change the following line in **/etc/ssh/sshd_config** file:
368 #PermitRootLogin prohibit-password
374 and reload **sshd** configuration:
376 # /etc/rc.d/sshd reload
377 Reloading sshd config files.
379 you can login as root:
381 % ssh root@172.16.50.62
382 root at 172.16.50.62's password:
383 Last login: Fri Jan 12 02:01:22 2018
384 DragonFly v5.0.2-RELEASE (X86_64_GENERIC) #4: Sun Dec 3 17:42:25 EST 2017
386 Welcome to DragonFly!
390 Now in the **/var/log/auth.log** you will find a line similar to
392 Oct 19 07:30:32 dfly-vmsrv sshd[17894]: Accepted password for root from 172.16.2.0 port 56468 ssh2
396 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](http://en.wikipedia.org/wiki/Password_cracking). If you are victim of one such attack you can find entries like the following in your **/var/log/auth.log** file.
398 Oct 18 18:54:54 cross sshd[9783]: Invalid user maryse from 218.248.26.6
399 Oct 18 18:54:54 cross sshd[9781]: input_userauth_request: invalid user maryse
400 Oct 18 18:54:54 cross sshd[9783]: Failed password for invalid user maryse from 218.248.26.6 port 34847 ssh2
401 Oct 18 18:54:54 cross sshd[9781]: Received disconnect from 218.248.26.6: 11: Bye Bye
402 Oct 18 18:54:55 cross sshd[27641]: Invalid user may from 218.248.26.6
403 Oct 18 18:54:55 cross sshd[3450]: input_userauth_request: invalid user may
404 Oct 18 18:54:55 cross sshd[27641]: Failed password for invalid user may from 218.248.26.6 port 34876 ssh2
405 Oct 18 18:54:55 cross sshd[3450]: Received disconnect from 218.248.26.6: 11: Bye Bye
406 Oct 18 18:54:56 cross sshd[8423]: Invalid user admin from 218.248.26.6
407 Oct 18 18:54:56 cross sshd[3131]: input_userauth_request: invalid user admin
408 Oct 18 18:54:56 cross sshd[8423]: Failed password for invalid user admin from 218.248.26.6 port 34905 ssh2
409 Oct 18 18:54:56 cross sshd[3131]: Received disconnect from 218.248.26.6: 11: Bye Bye
410 Oct 18 18:54:57 cross sshd[7373]: Invalid user admin from 218.248.26.6
411 Oct 18 18:54:57 cross sshd[28059]: input_userauth_request: invalid user admin
412 Oct 18 18:54:57 cross sshd[7373]: Failed password for invalid user admin from 218.248.26.6 port 34930 ssh2
413 Oct 18 18:54:57 cross sshd[28059]: Received disconnect from 218.248.26.6: 11: Bye Bye
414 Oct 18 18:54:58 cross sshd[12081]: Invalid user admin from 218.248.26.6
415 Oct 18 18:54:58 cross sshd[22416]: input_userauth_request: invalid user admin
416 Oct 18 18:54:58 cross sshd[12081]: Failed password for invalid user admin from 218.248.26.6 port 34958 ssh2
417 Oct 18 18:54:58 cross sshd[22416]: Received disconnect from 218.248.26.6: 11: Bye Bye
421 Instead of using passwords, ssh-keygen(1) can be used to generate RSA keys to authenticate a user:
424 Initializing random number generator...
425 Generating p: .++ (distance 66)
426 Generating q: ..............................++ (distance 498)
427 Computing the keys...
428 Key generation complete.
429 Enter file in which to save the key (/home/user/.ssh/identity):
431 Enter the same passphrase again:
432 Your identification has been saved in /home/user/.ssh/identity.
435 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.
437 This will allow connection to the remote machine based upon RSA authentication instead of passwords.
439 **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`.
441 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.
443 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`.
445 DSA public keys are also placed in `~/.ssh/authorized_keys` on the remote machine.
447 ssh-agent(1) and ssh-add(1) are utilities used in managing multiple passworded private keys.
449 **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.
453 **OpenSSH** has the ability to create a tunnel to encapsulate another protocol in an encrypted session.
455 The following command tells ssh(1) to create a tunnel for **telnet** :
457 % ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com
459 The `ssh` command is used with the following options:
463 :: Forces `ssh` to use version 2 of the protocol. (Do not use if you are working with older SSH servers)
467 :: Indicates no command, or tunnel only. If omitted, `ssh` would initiate a normal session.
471 :: Forces `ssh` to run in the background.
475 :: Indicates a local tunnel in `***localport:remotehost:remoteport***` fashion.
477 `user@foo.example.com`
479 :: The remote SSH server.
481 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.
483 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.
485 This can be used to wrap any number of insecure TCP protocols such as SMTP, POP3, FTP, etc.
487 **Example 10-1. Using SSH to Create a Secure Tunnel for SMTP**
489 % ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com
490 user@mailserver.example.com's password: *****
491 % telnet localhost 5025
493 Connected to localhost.
494 Escape character is '^]'.
495 220 mailserver.example.com ESMTP
497 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.
499 ### Practical SSH Tunneling Examples
501 #### Secure Access of a POP3 Server
503 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:
505 % ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com
506 user@ssh-server.example.com's password: ******
508 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`.
510 #### Bypassing a Draconian Firewall
512 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.
514 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.
516 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.
518 % ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org
519 user@unfirewalled-system.example.org's password: *******
521 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.