summaryrefslogtreecommitdiffstats
path: root/chapter_11.xml
blob: a721dfadcb26a42514f7fe8d487a0ad64de93fdd (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
<?xml version="1.0"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
  "/usr/share/xml/docbook/xml-dtd-4.5/docbookx.dtd">

<chapter>
<title>Working with Filesystems</title>

<section>
<title>The Filesystem Hierarchy</title>

<para>
Slackware Linux stores all of its files and directories under a single
<filename>/</filename> directory, typically referred to as "root". This
is in stark contract to what you may be familiar with in the form of
Microsoft Windows. Different hard disk partitions, cdroms, usb flash
drives, and even floppy disks can all be mounted in directories under
<filename>/</filename>, but do not have anything like "drive letters".
The contents of these devices can be found almost anywhere, but there
are some sane defaults that Slackware sets up for you. For example,
cd-rw drives are most often found at <filename>/mnt/cd-rw</filename>.
Here are a few common directories present on nearly all Slackware Linux
installations, and what you can expect to find there. 
</para>

<table pgwide="0">
<title>Filesystem Layout</title>
<tgroup cols="2">
  <thead>
    <entry>Directory</entry>
    <entry>Explaination</entry>
  </thead>
  <tbody>
    <row>
      <entry>/</entry>
      <entry>The root directory, under which all others exist</entry>
    </row>
    <row>
      <entry>/bin</entry>
      <entry>Minimal set of binary programs for all users</entry>
    </row>
    <row>
      <entry>/boot</entry>
      <entry>The kernel, initrd, and other requirements for booting Slackware</entry>
    </row>
    <row>
      <entry>/etc/</entry>
      <entry>System configuration files</entry>
    </row>
    <row>
      <entry>/dev</entry>
      <entry>Collection of special files allowing direct access to hardware</entry>
    </row>
    <row>
      <entry>/home</entry>
      <entry>User directories where personal files and settings are stored</entry>
    </row>
    <row>
      <entry>/media</entry>
      <entry>Directory for auto-mounting features in DBUS/HAL</entry>
    </row>
    <row>
      <entry>/mnt</entry>
      <entry>Places to temporarily mount removable media</entry>
    </row>
    <row>
      <entry>/opt</entry>
      <entry>Directory where some (typicaly proprietary) software may be installed</entry>
    </row>
    <row>
      <entry>/proc</entry>
      <entry>Kernel exported filesystem for process information</entry>
    </row>
    <row>
      <entry>/root</entry>
      <entry>The root user's home directory</entry>
    </row>
    <row>
      <entry>/sbin</entry>
      <entry>Minimal set of system or superuser binaries</entry>
    </row>
    <row>
      <entry>/srv</entry>
      <entry>Site-specific data such as web pages served by this system</entry>
    </row>
    <row>
      <entry>/sys</entry>
      <entry>Special kernel implimentation details</entry>
    </row>
    <row>
      <entry>/tmp</entry>
      <entry>Directory reserved for temporary files for all users</entry>
    </row>
    <row>
      <entry>/usr</entry>
      <entry>All non-essential programs, libraries, and shared files</entry>
    </row>
    <row>
      <entry>/var</entry>
      <entry>Regularly changing data such as log files</entry>
    </row>
  </tbody>
</tgroup>
</table>

</section>

<section>
<title>Local Filesystem Types</title>

<para>
The Linux kernel supports a wide variety of filesystems, which allows
you to choose from a long list of features to tailor to your particular
need. Fortunately, most of the default filesystem types are adequate
for any needs you may have. Some filesystems are geared towards
particular media. For example, the iso9660 filesystem is used almost
exclusively for CD and DVD media.
</para>

<section>
<title>ext2</title>

<para>
ext2 is the oldest filesystem included in Slackware Linux for storing
data on hard disks. Compared to other filesystems, ext2 is simplistic.
It is faster than most others for reading and writing data, but does
not include any journaling capability. This means that after a hard
crash, the filesystem must be exhaustively checked to discover and
(hopefully) fix any errors. 
</para>

</section>

<section>
<title>ext3</title>
<para>
ext3 is the younger cousin of ext2. It was designed to replace ext2 in
most situations and shares much the same code-base, but adds journaling
support. In fact, ext3 and ext2 are so much alike that it is possible
to convert one to the other on the fly without lose of data. ext3
enjoys a lot of popularity for these reasons. There are many tools
available for recovering data from this filesystem in the event of
catastrophic hardware failure as well. ext3 is a good general purpose
filesystem with journaling support, but fails to perform as well as
other journaling filesystems in specific cases. One pitfall to ext3 is
that the filesystem must still go through this exhaustive check every
so often. This is done when the filesystem is mounted, usually when the
computer is booted, and causes an annoying delay.
</para>
</section>

<section>
<title>reiserfs</title>
<para>
reiserfs is one of the oldest journaling filesystems for the Linux
kernel and has been supported by Slackware for many years. It is a very
fast filesystem particularly well suited for storing, retrieving, and
writing lots of small files. Unfortunately there are few tools for
recovering data should you experience a drive failure, and reiserfs
partitions experience corruption more often than ext3. 
</para>
</section>

<section>
<title>XFS</title>
<para>
XFS was contributed to the Linux kernel by SGI and is one of the best
filesystems for working with large volumes and large files. XFS uses
more RAM than other filesystems, but if you need to work with large
files its performance there is well worth the penalty in memory usage.
XFS is not particularly ill-suited for desktop or laptop use, but
really shines on a server that handles medium to large size files all
day long. Like ext3, XFS is a fully journaled filesystem. 
</para>
</section>

<section>
<title>JFS</title>
<para>
JFS was contributed to the Linux kernel by IBM and is well known for
its responsiveness even under extreme conditions. It can span colossal
volumes making it particularly well-suited for Network Attached Storage
(NAS) devices. JFS's long history and thorough testing make it one of
the most reliable journaling filesystems available for Linux. 
</para>
</section>

<section>
<title>iso9660</title>
<para>
iso9660 is a filesystem specifically designed for optical media such as
CDs and DVDs. Since optical disks are read-only media, the linux kernel
does not even include write support for this filesystem. In order to
create an iso9660 filesystem, you must use user-land tools like
<application>mkisofs</application>(8) or
<application>growisofs</application>(8).
</para>
</section>

<section>
<title>vfat</title>
<para>
Sometimes you may need to share data between Windows and Linux
computers, but can't transfer the files over a network. Instead you
require a shared hard drive partition or a USB flash drive. The humble
vfat filesystem is the best choice here since it is supported by the
largest variety of operating systems. Unfortuantely, being a Microsoft
designed filesystem, it does not store permissions in the same way as
traditional Linux filesystems. This means that special options must be
used to allow multiple users to access data on this filesystem. 
</para>
</section>

<section>
<title>swap</title>
<para>
Unlike other filesystems which hold files and directories, swap
partitions hold virtual memory. This is very useful as it prevents the
system from crashing should all your RAM be consumed. Instead, the
kernel copies portions of the RAM into swap and frees them up for other
applications to use. Think of it as adding virtual memory to your
computer, very slow virtual memory. swap is typically a fail-safe and
shouldn't be relied upon for continual use. Add more RAM to your system
if you find yourself using lots of swap. 
</para>
</section>

</section>

<section>
<title>Using <application>mount</application></title>

<para>
Now that we've learned what (some of) the different filesystems
available in Linux are, it's time we looked at how to use them. In
order to read or write data on a filesystem, that filesystem must first
be mounted. To do this, we (naturally) use
<application>mount</application>(8). The first thing we must do is
decide where we want the filesystem located. Recall that there are no
such things are drive letters denoting filesystems in Linux. Instead,
all filesystems are mounted on directories. The base filesystem on
which you install Slackware is always located at <filename>/</filename>
and others are always located in subdirectories of
<filename>/</filename>. <filename>/mnt/hd</filename> is a common place
to temporarily locate a partition, so we'll use that in our first
example. In order to mount a filesystem's contents, we must tell mount
what kind of filesystem we have, where to mount it, and any special
options to use. 
</para>

<screen><prompt>darkstar:~# </prompt><userinput>mount -t ext3 /dev/hda3 /mnt/hd -o ro</userinput>
</screen>

<para>
Let's disect this. We have an ext3 filesystem located on the third
partition of the first IDE device, and we've decided to mount its
contents on the directory <filename>/mnt/hd</filename>. Additionally,
we have mounted it read-only so no changes can be made to these
contents. The <arg>-t ext3</arg> argument tells
<application>mount</application>
what type of filesystem we are using,
in this case it is ext3. This lets the kernel know which driver to use.
Often <application>mount</application> can determine this for itself,
but it never hurts to explicitly declare it. Second, we tell
<application>mount</application> 
where to locate the filesystem's contents. Here we've chosen
<filename>/mnt/hd</filename>.
Finally, we must decide what options to use if any. These are declared
with the <arg>-o</arg> argument. A short-list of the most common
options follows. 
</para>

<table pgwide="0">
<title>Common mount options</title>
<tgroup cols="2">
  <thead>
    <entry>Option</entry>
    <entry>Description</entry>
  </thead>
  <tbody>
    <row>
      <entry>ro</entry>
      <entry>read-only</entry>
    </row>
    <row>
      <entry>rw</entry>
      <entry>read-write (default)</entry>
    </row>
    <row>
      <entry>uid</entry>
      <entry>user to own the contents of the filesystem</entry>
    </row>
    <row>
      <entry>gid</entry>
      <entry>group to own the contents of the filesystem</entry>
    </row>
    <row>
      <entry>noexec</entry>
      <entry>prevent execution of any files on the filesystem</entry>
    </row>
    <row>
      <entry>defaults</entry>
      <entry>sane defaults for most filesystems</entry>
    </row>
  </tbody>
</tgroup>
</table>

<para>
If this is your first Linux installation, the only options you
typically need to be concerned about are <arg>ro</arg> and
<arg>rw</arg>. The exception to this rule comes when you are dealing
with filesystems that don't handle traditional Linux permissions such
as vfat or NTFS. In those cases you'll need to use the <arg>uid</arg>
or <arg>gid</arg> options to allow non-root users access to these
filesystems.
</para>

<screen><prompt>darkstar:~# </prompt><userinput>mount -t vfat /dev/hda4 /mnt/hd -o uid=alan</userinput>
</screen>

<para>
But Alan, that's appalling! I don't want to have to tell mount what
filesystem or options to use everytime I load a CD. It should be easier
than that. Well thankfully, it is. The <filename>/etc/fstab</filename>
file contains all this information for filesystems that the installer
sets up for you, and you can make additions to it as well.
<filename>fstab</filename>(5) looks like a simple table containing the
device to mount along with its filesystem type and optional arguments.
Let's take a look. 
</para>

<screen><prompt>darkstar:~# </prompt><userinput>cat /etc/fstab</userinput>
/dev/hda1        /                reiserfs    defaults               1   1
/dev/hda2        /home            reiserfs    defaults               1   2
/dev/hda3        swap             swap        defaults               0   0
/dev/cdrom       /mnt/cdrom       auto        noauto,owner,ro,users  0   0
/dev/fd0         /mnt/floppy      auto        noauto,owner           0   0
devpts           /dev/pts         devpts      gid=5,mode=620         0   0
proc             /proc            proc        defaults               0   0
</screen>

<para>
If you have an entry in <filename>fstab</filename> for your filesystem, you
need only tell mount the device node or the mount location. 
</para>

<screen><prompt>darkstar:~# </prompt><userinput>mount /dev/cdrom</userinput>
<prompt>darkstar:~# </prompt><userinput>mount /home</userinput>
</screen>

<para>
One final use for
<application>mount</application>
is to tell you what filesystems are currently mounted and with what
options. Simply run
<application>mount</application>
without any arguments to display these. 
</para>

</section>

<section>
<title>Network Filesystems</title>

<para>
In addition to local filesystems, Slackware supports a number of network
filesystems as both client and server. This allows you to share data
between multiple computers transparently. We'll discuss the two most
common: NFS and SMB. 
</para>

<section>
<title>NFS</title>

<para>
NFS is the Network File System for Linux as well as several other common
operating systems. It has modest performance but supports the full range of
permissions for Slackware. In order to use NFS as either a client or a
server, you must run the remote procedure call daemon. This is easily
accomplished by setting the <filename>/etc/rc.d/rc.rpc</filename> file
executable and telling it to start. Once it has been set executable, it
will run automatically every time you boot into Slackware. 
</para>

<screen><prompt>darkstar:~# </prompt><userinput>chmod +x /etc/rc.d/rc.rpc</userinput>
<prompt>darkstar:~# </prompt><userinput>/etc/rc.d/rc.rpc start</userinput>
</screen>

<para>
Mounting an NFS share is little different than mounting a local filesystem.
Rather than specifying a local device, you must tell mount the domain name
or IP address of the NFS server and the directory to mount with a colon
between them. 
</para>

<screen><prompt>darkstar:~# </prompt><userinput>mount -t nfs darkstar.example.com:/home /home</userinput>
</screen>

<para>
Running an NFS server is a little bit different. First, you must configure
each directory to be exported in the <filename>/etc/exports</filename>
file. <filename>exports</filename>(5) contains information about what
directories will be shared, who they will be shared with, and what special
permissions to grant or deny. 
</para>

<screen>
# See exports(5) for a description.
# This file contains a list of all directories exported to other computers.
# It is used by rpc.nfsd and rpc.mountd.

/home/backup	192.168.1.0/24(sync,rw,no_root_squash)
</screen>

<para>
The first column in
<filename>exports</filename>
is a list of the files to be exported via NFS. The second column is a list
of what systems may access the export along with special permissions. You
can specify hosts via domain name, IP address, or netblock address (as I
have here). Special permissions are always a parenthetical list. For a
complete list, you'll need to read the man page. For now, the only special
option that matters is <arg>no_root_squash</arg>. Usually the root user on
an NFS client cannot read or write an exported share. Instead, the root
user is "squashed" and forced to act as the nobody user.
<arg>no_root_squash</arg> prevents this.
</para>

<para>
You'll also need to run the NFS daemon. Starting and stopping NFS server
support is done with the <filename>/etc/rc.d/rc.nfsd</filename> rc script.
Set it executable and run it just like we did for
<filename>rc.rpc</filename> and you are ready to go. 
</para>

</section>

<section>
<title>SMB</title>

<para>
SMB is the Windows network file-sharing protocol. Connecting to SMB shares
(commonly called samba shares) is fairly straight forward. Unfortuantely,
SMB isn't as strongly supported as NFS. Still, it offers higher performance
and connectivity with Windows computers. For these reasons, SMB is the most
common network file-sharing protocol deployed on local networks. Exporting
SMB shares from Slackware is done through the samba daemon and configured
in <filename>smb.conf</filename>(5). Unfortunately configuring samba as a
service is beyond the scope of this book. Check online for additional
documentation, and as always refer to the man page. 
</para>

<para>
Thankfully mounting an SMB share is easy and works almost exactly like
mounting an NFS share. You must tell mount where to find the server and
what share you wish to access in exactly the same way. Additionally, you
must specify a username and password. 
</para>

<screen><prompt>darkstar:~# </prompt><userinput>mount -t cifs //darkstar/home /home -o username=alan,password=secret</userinput>
</screen>

<para>
You may be wondering why the filesystem type is cifs instead of smbfs. In
older versions of the Linux kernel, smbfs was used. This has been
deprecated in favor of the better performing and more secure general
purpose cifs driver. 
</para>

<para>
All SMB shares require the <arg>username</arg> and <arg>password</arg>
arguments. This can create a security problem if you wish to place your
samba share in fstab. You may avoid this problem by using the
<arg>credentials</arg> argument. <arg>credentials</arg> points to a file
which contains the username and password information. As long as this file
is safely guarded and readable only by root, the likelyhood that your
authentication credentials will be compromised is lessened. 
</para>

<screen><prompt>darkstar:~# </prompt><userinput>echo "username=alan" > /etc/creds-home</userinput>
<prompt>darkstar:~# </prompt><userinput>echo "password=secret" >> /etc/creds-home</userinput>
<prompt>darkstar:~# </prompt><userinput>mount -t cifs //darkstar/home -o credentials=/etc/creds-home</userinput>
</screen>




</section>










</section>

</chapter>