FreeBSD Basics

Apart from the traditional method of installing software on UNIX® (download sources, unzip, edit the source, and compile), FreeBSD offers two alternatives for installing programs: packages and two alternatives for installing programs: package and ports. A list and ports. There is a complete list of available ports here.

PACKAGES
The “packages” are precompiled programs, equivalent in FreeBSD to the files .deb on Debian/Ubuntu systems and .rpm on Red Hat/Fedora systems. Packages are installed using pkg_add(1). For example, you can install Apache 2.2 as follows:

# pkg_add /tmp/apache-2.2.6_2.tbz

By using the option -r, pkg_add(1) It will automatically download the indicated package and install it, as well as all those it needs for its operation. These are the dependencies.

# pkg_add -r apache22
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/Latest/apache22.tbz... Done.
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/All/expat-2.0.0_1.tbz... Done.
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/All/perl-5.8.8_1.tbz... Done.
[snip]

To run apache www server from startup, add apache22_enable="YES"
in your /etc/rc.conf. Extra options can be found in startup script.

For more information on packages see section 4.4 of the Handbook: Using the package system.

PORTS
The second method that FreeBSD offers for installing programs is to use the Port Collection. The Ports Collection is a file environment Makefile and patches specifically adapted to be able to install the most diverse applications from source code on FreeBSD systems. If you install a port, the system will download the sources, apply the necessary patches, compile the code and install the program (and do exactly the same with all the dependencies).

The Ports Collection, also known as the ports tree, is in /usr/ports if it was installed during the FreeBSD installation process. If the Ports Collection is not installed you can do it from the installation disks using sysinstall(8) or from the FreeBSD servers thanks to csup(1) either portsnap(8). It has detailed instructions for installing the Port Collection on the section 4.5.1 of the Handbook.

Installing a port is (usually) as simple as entering the port directory and running the build process. The example shown below installs Apache 2.2 from the Ports Collection:

# cd /usr/ports/www/apache22
# make install clean

One of the main advantages of using ports to install software is the ability to adjust installation options. For example, it is possible to activate mod_ldap inside your Apache 2.2 during installation by using the variable WITH_LDAP of make(1):

# cd /usr/ports/www/apache22
# make WITH_LDAP="YES" install clean

For more information about the Ports Collection, consult the section of the Handbook dedicated to the Ports Collection.

WHICH

Packages are simply precompiled ports, so it's a matter of choosing between installing from sources (ports) or installing binaries directly (packages). Either has its own advantages:

Package (binary)

• Faster installation (compiling large programs can take time).
• You don't have to understand the process of compiling software.
• There is no need to install compilers on your system.

Ports (source)

• You can adjust the installation options. (Packages are typically generated with the standard options. With ports you can adjust various options, such as having additional modules or changing the default path.)
• You can use your own patches if you tend to.

If you don't have special requirements the packages will probably cover your needs without a problem. If you ever need something tighter you can use the ports. Keep in mind that if you need a program tailored to your needs but still prefer to use packages, you can make one to your liking using make patch and then copy the package to other machines.

Command List

oduction

The next chapter covers the basic functionality and commands of the FreeBSD operating system. Much of this material is relevant to any UNIX® type operating system. You can skip this chapter if you feel you already know how UNIX works. If you have no prior experience with FreeBSD you should read this chapter very carefully.

After reading this chapter, you will know:

· How to use FreeBSD “virtual consoles”.

· How UNIX file permissions work in relation to file flags in FreeBSD.

· The default filesystem layout in FreeBSD.

· The FreeBSD disk organization.

· How to mount and unmount file systems.

· What are processes, daemons and signals.

· What is a shell, how to modify its default login environment variables.

· How to use basic text editors.

· What are devices and device nodes.

· What binary format is used in FreeBSD.

· How to search for information in man pages.

FreeBSD can be used in many ways. One of them is by typing commands into a text terminal. Thus, much of the flexibility and power of a UNIX® operating system is immediately in your hands when you use FreeBSD. This section describes what “terminals” and “consoles” are, and how you can use them in FreeBSD.

If you have not configured FreeBSD to automatically start a graphical environment at boot, the system will present you with an input prompt after boot, immediately after the startup scripts finish running. You will see something similar to this:

Additional ABI support:

Local package initialization:

Additional TCP options:

Fri Sep 20 13:01:06 EEST 2002

FreeBSD/i386 (pc3.example.org) (ttyv0)

login:

The messages may be a little different on your system, but you will see something similar. The last two lines are the ones that interest us at the moment. The penultimate line says:

FreeBSD/i386 (pc3.ejemplo.org) (ttyv0)

This line contains information about the system that has just booted. You are looking at a “FreeBSD” console that runs on an Intel or compatible x86 architecture processor.[1]. The name of this machine (every UNIX machine has a name) ispc3.example.org, and you are now at your system console (the terminal ttyv0).

Finally, the last line is always:

login:

This is the part where you are supposed to type your “username” to log into FreeBSD. The next section describes how to do this.

FreeBSD is a multi-processor multi-user system. This is the formal description usually given to a system that can be used by many different people, simultaneously running many programs on a single machine.

Every multi-user system needs some way to distinguish one “user” from the rest. On FreeBSD (and all UNIX-like operating systems) this is achieved by requiring that each user must “log in” to the system before being able to run programs. Each user has a unique name (the “username”) and a personal, secret key (the “password”). FreeBSD will ask for both before allowing a user to run any program.

Right after FreeBSD boots and finishes running its startup scripts [2], it will present a “prompt” and request a valid username:

login:

login: john
Password:

# name getty type status comments
#
ttyv0 «/usr/libexec/getty Pc» cons25 on secure
# Virtual terminals
ttyv1 «/usr/libexec/getty Pc» cons25 on secure
ttyv2 «/usr/libexec/getty Pc» cons25 on secure
ttyv3 «/usr/libexec/getty Pc» cons25 on secure
ttyv4 «/usr/libexec/getty Pc» cons25 on secure
ttyv5 «/usr/libexec/getty Pc» cons25 on secure
ttyv6 «/usr/libexec/getty Pc» cons25 on secure
ttyv7 «/usr/libexec/getty Pc» cons25 on secure
ttyv8 «/usr/X11R6/bin/xdm -nodaemon» xterm off secure

# name getty type status comments
#
# Si la consola está marcada como «insecure», entonces init
# le pedirá la contraseña de root al entrar a modo monousuario.
console none unknown off secure

In this example we will assume that your username is john. Type john at the prompt and press Enter. You should be presented with a prompt where you can enter a “password”:login: johnPassword:Now type john's password and press Enter.

The password is not displayed on the screen, but you don't have to worry about it. This is done for security reasons. If you have typed your password correctly you are now on a FreeBSD system, ready to try all the available commands. You will see the MOTD (message of the day) followed by a “prompt” (a #, $ or %) character.

This confirms that you have successfully validated your user in FreeBSD.2.3. Multiple ConsolesRunning UNIX commands in one console is fine, but FreeBSD can run many programs at once. Having a console where you can type commands can be a bit of a waste when an operating system like FreeBSD can run dozens of programs at the same time.

This is where “virtual consoles” can be very helpful. FreeBSD can be configured to present you with different virtual consoles. You can switch from one of them to any other virtual console by pressing a couple of keys on your keyboard. Each console has its own output channel, and FreeBSD takes care to correctly redirect keyboard input and monitor output when switching from one virtual console to the next. Certain special key combinations have been reserved for switching between virtual consoles in FreeBSD [3]. You can use Alt-F1, Alt-F2 and so on up to Alt-F8 to switch to a different virtual console in FreeBSD. While you are switching from one console to the next, FreeBSD takes care of saving and restoring the screen output. The result is the “illusion” of having multiple “virtual” screens and keyboards that you can use to type commands for FreeBSD to execute.

The program you launch in a virtual console does not stop running when the console is not visible. They continue to run when you switch to a different virtual console.

2.4. The /etc/ttysLa file

FreeBSD's default configuration will start with eight virtual consoles.

This is not a static hardware configuration and you can easily customize your system to boot with more or fewer virtual consoles. The number and properties of the virtual consoles are detailed in /etc/ttys.

Use /etc/ttys to configure FreeBSD virtual consoles.

Each uncommented line in this file (lines that do not begin with a # character) contains properties for a single terminal or virtual console. The default version of this file in FreeBSD configures nine virtual consoles and enables eight of them.

They are the lines that start with ttyv:

# name getty type status comments

#

ttyv0 "/usr/libexec/getty Pc" cons25 on secure

# Virtual terminals

ttyv1 «/usr/libexec/getty Pc» cons25 on secure

ttyv2 "/usr/libexec/getty Pc" cons25 on secure

ttyv3 «/usr/libexec/getty Pc» cons25 on secure

ttyv4 "/usr/libexec/getty Pc" cons25 on secure

ttyv5 «/usr/libexec/getty Pc» cons25 on secure

ttyv6 "/usr/libexec/getty Pc" cons25 on secure

ttyv7 "/usr/libexec/getty Pc" cons25 on secure

ttyv8 «/usr/X11R6/bin/xdm -nodaemon» xterm off secure

if you want a detailed description of each column in this file and all the options you can use to configure the virtual consoles

.2.5. Console in single-user mode

See Section 14.6.2 for a detailed description of what “single-user mode” is. It doesn't matter that there is only one console when you run FreeBSD in single-user mode. There are no virtual consoles available.

Console configurations in single-user mode can also be found in /etc/ttys. Find the line that starts with console:

# name getty type status comments

#

# If the console is marked "insecure", then init

# will ask you for the root password when entering single-user mode.

.console none unknown off secureNote: As the comments above the console line indicate, you can edit this line and change secure to insecure. If you do this, when FreeBSD boots in single-user mode you will be prompted for the root password. Be careful if you change this to insecure. If you forget the root password, booting in single-user mode will certainly be more complicated. It is still possible, but it will be a bit difficult for someone who is not familiar with the FreeBSD boot process and the programs involved in that process.

Grades

FreeBSD, whose historical root is UNIX BSD, is based on several key UNIX concepts. The first and most important is that FreeBSD is a multi-user operating system. The system can manage several users working simultaneously and on tasks that are not related to each other. The system is responsible for sharing and managing requests for hardware devices, peripherals, memory and Central Processing Unit (CPU) time equitably for each user.
Because the system is capable of supporting multiple users, everything the system manages has a set of permissions that it uses to decide who can read, write, and execute a resource. These permissions are saved as octets divided into three parts: one for the owner of the file, one for the group to which the file belongs, and one for all other groups and users. Let's look at a numerical representation of this:

You can use the -l command-line parameter to ls(1) to view a long listing that includes a column with information about file permissions for the owner, group, and others. For example, an ls -l on an arbitrary directory might display something like this:

Here is how the first column is divided ls -l:

These values ​​are applied with chmod(1) in the same way as the previous ones, but with letters. For example, you could use the following command to block other users from accessing FILE:

A comma-separated list can be used when you want to apply more than one set of changes to a file. For example the following command will remove group and “world” write permissions from FILE, and add execute permissions for everyone:

Written by Tom Rhodes.

In addition to the file permissions previously discussed, FreeBSD allows the use of “file flags.” These flags add an additional level of security and control over files, but not directories.

These file flags add an additional level of control over files, helping to ensure that in some cases not even root can delete or alter files.

File flags are modified by chflags(1), thanks to a very simple interface. For example, to enable the system unclearable flag on file1, type the following:

And to disable the unclearable system flag, simply type the previous command with “no” before sunlink. Observe:

To view the flags of this file, use ls(1) with the options -it:

The output should be like this:

-rw-r–r– 1 trhodes trhodes sunlnk 0 Mar 1 05:54 file1

Several flags can only be added or removed from files by the user root. In other cases, the file owner can activate these flags. It is recommended that the person in charge of system administration consult the man pages for more information. chflags(1) and chflags(2).

The FreeBSD file system hierarchy is essential for complete system compression. The most important concept to understand is the root directory, “/”. This directory is the first to be mounted at boot and contains the basic system necessary to prepare the operating system for operation in multi-user mode. The root directory also contains mount points for any other file systems that you intend to mount.

A mount point is a directory where filesystems can be inserted into the root filesystem. This is explained in detail in the Section 3.5. Standard mounting points include /usr, /var, /tmp, /mnt and /CD-ROM. These directories usually correspond to entries in /etc/fstab. /etc/fstab It is a table that serves as a reference to the system and contains the different file systems and their respective mount points. Most file systems in /etc/fstab They are automatically mounted at startup thanks to the “script” RC(8), unless they contain the option noauto. If you want more information see the Section 3.6.1.

We will now see a description of the most common directories. If you want more complete information, consult hier(7).

The smallest unit that FreeBSD uses to locate files is the filename. File names are case-sensitive, which means that readme.txt and README.TXT They are two different files. FreeBSD does not use the (.txt) of a file to determine whether it is a program, or a document, or some other form of data.

The files are stored in directories. A directory can be empty, or it can contain hundreds of files. A directory can also contain other directories, allowing you to build a directory hierarchy within another. This makes organizing your data much easier.

To refer to files or directories, the file or directory name is used, followed by a slash, /, followed by any other directory names necessary. If you have a directory such, which contains the directory which, which contains the file readme.txt, then the full name or route to the file is such/such/readme.txt.

Directories and files are stored in a file system. Each file system contains a single directory at the highest level, which is the root directory of that file system. This root directory may contain other directories.

What you've seen so far is probably similar to any other operating system you may have used, but there are a few differences; For example, MS-DOS® uses  to separate file and directory names, while macOS® uses :.

FreeBSD does not use drive letters, or other drive names in the path. Therefore, you will not be able to writec:/such/such/readme.txt on FreeBSD.

In FreeBSD, however, a file system is called a root file system. The root directory of the root file system is represented as /. Any other file system, therefore, is ride under the root file system. No matter how many disks you have on your FreeBSD system, each directory will appear to be part of the same disk.

Suppose you have three file systems, named TO, b and c. Each file system has a root directory, which contains two other directories, called A1, A2B1, B2 and C1, C2). (and in the same way

we will use TO as root file system. If I used ls To see the contents of this directory you would see two subdirectories, A1 and A2. The directory tree would look like this:

A filesystem must be mounted in a directory of another filesystem. Now suppose you mount the filesystem b in the directory A1. The root directory of b replaces A1, and the directories in b They appear this way:

Any file that is in the directory B1 either B2 can be found with the route /A1/B1 either /A1/B2 as needed. Any file that is in /A1 has temporarily disappeared. They will appear again if b HE dismantle of A.

Yeah b rides on A2 then the diagram would look like this:

and the routes would be /A2/B1 and /A2/B2 respectively.

File systems can be mounted on top of each other. Continuing the previous example, the file system c could be mounted in directory B1 in the file system b, which would lead us to this:

EITHER c could be mounted directly to the filesystem TO, under the directory A1:

If you are familiar with MS-DOS this is similar, although not identical, to using join.

This is not something you need to worry about on a regular basis. Typically you will create filesystems when you install FreeBSD and decide where to mount them; Typically, you don't move them unless you add a new disk.

It is perfectly possible to have an extensive root file system and not need to create others. This scheme has a few drawbacks and one advantage:

Advantages of having multiple file systems

· If you have several file systems you can choose to use different mounting options. For example, through careful planning, the root filesystem can be mounted read-only, making it impossible to inadvertently delete or edit a critical file. By maintaining separate file systems that users can write to, such as /home, other filesystems also allow you to mount with the option nosuid; This option prevents the bits suid/guide on executables stored in the file system to take effect, somewhat improving security.

· FreeBSD automatically optimizes the file scheme on a file system, depending on how the file system is being used. A file system that contains many small files that are written to frequently will be optimized for one that contains fewer and larger files. If you only have a large file system this optimization has no option to act.

· FreeBSD filesystems are very robust in the event of a power failure. However, a power failure at a critical moment can damage the file system structure. Spreading your data across multiple file systems will make it more likely that the system will boot after one of these failures, and will also make it easier for you to restore it from a backup if necessary.

Advantages of a single file system

· File systems are of a fixed size. If you create a file system when you install FreeBSD and give it a specific size, you may discover later that you need to make the partition larger. This is not easy to do without making a backup, recreating the filesystem with the new size, and then restoring the backed up data.

Important: FreeBSD 4.4 and later versions have growfs(8), which makes it possible to increase the size of the file system “on the fly”, eliminating this limitation.

File systems are hosted on partitions. This is a very important detail, since the term partition does not mean here the same as in other environments (e.g. partition MS-DOS), due to inheritance UNIX® by FreeBSD. Each partition is identified with a letter from to until h. Each partition can contain only one filesystem, which means that filesystems are typically defined by their mount point in the filesystem hierarchy or by the letter of the partition on which they are hosted.

FreeBSD also uses disk space as swap space. Swap space gives FreeBSDvirtual memory. This allows your system to behave as if it has more memory than it actually does. When FreeBSD runs out of memory it moves some of the data that is not currently being used to the swap space, and moves it back (by moving something else) when it needs it.

Some partitions have certain representations associated with them.

Each partition-containing-a-filesystem is stored in what FreeBSD calls a slice. Portion is the FreeBSD term for what is commonly known as a partition, and again, known as a partition, and again, this is due to inheritance UNIX from FreeBSD. The slices are numbered, starting with 1, up to 4

.The slice numbers follow the device name, preceded by a yes, starting from 1. Thus, “da0s1" is the first slice on the first SCSI drive. There can only be four physical slices on a disk, but there can be logical slices within physical slices of the appropriate type. These extended slices are numbered starting from 5, so "ad0s5" is the first extended slice on the first IDE disk. These devices are used in file systems that are expected to occupy a slice.

Both slices and “dangerously dedicated” physical drives, as well as other drives, contain partitions, which are designated by letters from to until h. This letter is added to the device name, so “da0to” is partition a on the first da drive, which is “dangerously dedicated.” “ad1s3and” is the fifth partition in the third slice of the second IDE disk drive.

Finally, each disk in the system also has its designation. The disk name begins with a code indicating the type of disk, then a number, indicating which disk it is. Unlike slices, disk numbering starts from 0. Common codes you will see are shown on the Table 3-1.

When referring to a partition, FreeBSD requires that you also name the slice and the disk containing the partition, and when referring to a slice you must also refer to the disk name. This is done by listing the disk name, yes (slice), the slice number and finally the letter of the slice and finally the letter of the partition. partition. You can see several examples in the Example 3-1.

The Example 3-2 shows a conceptual model of a disk layout that should help clarify things.

In order to install FreeBSD you must first configure the disk partitions, then create partitions within the slice that you will use for FreeBSD and then create a file system (or swap space) on each partition, and decide where those file systems are going to be mounted.

Table 3-1. Disk device codes

3-1. Example of disk, slice and partition names

Example 3-2. Conceptual model of a disk

This diagram shows how FreeBSD sees the first IDE disk in the system. The disk is assumed to be 4 GB, and contains two 2 GB partitions (partitions MS-DOS). The first partition contains a disk MS-DOS, C:, and the second partition contains a FreeBSD installation. This example installation has three partitions, and one swap partition.

Each of the three partitions has a file system. The partition to will be used for the root file system, and for directory hierarchy /var, and F for directory hierarchy /usr.

The file system is best viewed as a tree, rooted, as it is, in /. /dev, /usr and the other directories in the root directory are branches, which can have their own branches, such as /usr/local, and so on.

There are several reasons to house some of these directories on separate file systems. /var contains the directorieslog/, spool/ and various types of temporary files and as such, it can fill up. Running out of root filesystem space is not a good idea, so detach /var of / It is usually highly recommended.

Another common reason to put certain directory trees on other filesystems is if they are going to be hosted on separate physical disks, or if they are separate virtual disks, such as a mount of network file system, or CDROM drives.

fstab

During the boot process, the filesystems listed in /etc/fstab are mounted automatically (unless listed with the option noauto).

/etc/fstab contains a list of lines with the following format:

device

A device name (must exist).

mounting-point

A directory (which must exist), where to mount the file system.

fstype

The type of file system to pass to mount(8). The default filesystem type of FreeBSD is ugh.

options

Whether it's rw for read-write file systems, or ro for read-only filesystems, followed by any other options that are necessary. A common option is noauto for filesystems that are not normally mounted during the boot sequence. There are other options in the man page mount(8).

dumpfreq

dump(8) uses it to determine which filesystem requires dumping. If the field is not declared, a value of zero is assumed.

passno

Determines the order in which filesystems should be checked. The filesystems that must be skipped must have their passno steel. The root filesystem (which obviously needs to be checked before any other) must have its passno set to one, and other filesystems must have values ​​greater than one. If more than one filesystem has the same passno so fsck(8) will try to review them in parallel if possible.

See the man page for fstab(5) for more information about the file format /etc/fstab and the options it contains.

mount

mount(8) it is what is ultimately used to mount filesystems.

In its most basic form, the following is used:

There are a large number of options, as stated in mount(8), but the most common are:

Mounting options

-to

Mount all filesystems listed in /etc/fstab. Except those marked “noauto”, excluded by the flag -t, or those that are already assembled.

-d

Perform everything except the actual system mount call. This option is useful along with the flag -v to determine what mount(8) is actually trying to do.

-F

Force mount a dirty filesystem (i.e. dangerous), or force revocation of write access when changing the status of a file system from read-write to read-only.

-r

Mount the filesystem as read-only. This is identical to using the argument ro (rdonly for versions older than FreeBSD 5.2) in the option -either.

-t fstype

Mount the given filesystem with the filesystem type, or mount only filesystems of the given type, if the option is provided -to.

“ufs” is the default root file system.

-or

Update mount points in the file system.

-v

Show more information.

-w

Mount the file system as read-write.

The option -either takes a comma-separated list of options, including the following:

nodev

Do not interpret special devices in the file system. It is a security option that can be very useful.

noexec

Do not allow the execution of binaries on this file system. This is also a useful security option.

nosuid

Do not interpret setuid or setgid flags in the filesystem. This is also a useful security option.

umount

umount(8) takes, as a parameter, a mount point, a device name, or the option -to either -TO.

All forms take -F to force disassembly, and -v to display more information.

Please note what to use -F It is not usually a recommended way to proceed. Forcibly unmounting filesystems can result in freezing the machine or corrupting data in the filesystem.

-to and -TO are used to unmount all mounted filesystems, with the advantage of being able to choose the type of filesystem used after -t. Anyway -TO it does not try to unmount the root filesystem.

FreeBSD is a multitasking operating system. This means that it appears as if more than one program is running at the same time. Each program that runs at any given time is called process.

Each command you execute will start at least one new process, and there are many processes running at all times, keeping the system running.

Each process has an individual identifier consisting of a number called process ID, either P.I.D., and, as a file, each process also has an owner and a group. The owner and group information is used to determine which files and devices the process can open using the file permissions explained above. Most processes also have a parent process.

The parent process is the process that started them. For example, if you are typing commands into the shell, the shell is a process, and any commands you execute will be a process as well. In this way, each process you run will have its shell as its parent process. The exception is a special process called init(8). init is always the first process, so its PID is always 1. init It is automatically started by the kernel when FreeBSD boots.

There are two commands particularly useful for viewing processes in the system, ps(1) and top(1). ps is used to display a static list of the processes currently running on the system, and can show their PIDs, how much memory they are using, the command line they were started with, and much more. top It displays all the processes that are running, and refreshes the screen every few seconds so you can see what your system is doing.

Default ps it only shows you the orders that are being executed and owned by your user. For example:

As you can see in this example, the output of ps(1) It is organized in columns.

P.I.D. is the process ID previously exposed. PIDs are assigned starting from 1, up to 99999, and loop back to the beginning when the numbers run out. The column T.T. shows the tty on which the program is running, and we can safely ignore it for the moment. STATshows the status of the program, and we can also ignore it.

TIME is the amount of time the program has been running on the CPU (usually not the time elapsed since the program started, since most programs spend a lot of time waiting before they need to spend time on the CPU. Finally, COMMAND is the command line that was used to execute the program.

ps(1) supports many different options about what information you want to see. One of the most useful sets is auxww. todisplays information about all the processes running, not just yours. or displays the username of the process owner, as well as the memory usage. x displays information about the daemon processes and ww makes ps(1)display the entire command line, rather than truncating it when it is too long to fit on the screen.

The departure of top(1) It's similar. Let's look at an example:

The exit is divided into two sections. The header (the first five lines) shows the PID of the last process to run, the average system load (a measure of system load), the system uptime (time since the last reboot), and the current time. The other figures in the header relate to how many processes are running on the system (47 in this case), how much memory and swap space is in use, and how long the system is in different CPU states.

Below are a series of columns with information similar to the output of ps(1). As before, you can see the PID, username, amount of CPU time in use, and the command that was executed. top(1) It will also show by default the amount of memory space used by each process.

This is divided into two columns, one for the total size and one for the resident size (the total size is how much memory the application has needed and the resident size is how much is being used at that particular time). In this example it can be seen that netscape® required almost 30 MB of RAM, but currently it is only using 9 MB.

top(1) It automatically updates the list every two seconds, but this period can be changed using the option yes.

When you run an editor it is easy to control it, tell it to load files and so on. It can be done because the editor allows that control, and because the editor depends on a terminal. Some programs are not designed to be run with continuous user input, so they disconnect from the terminal at the first opportunity. For example, a web server spends all day responding to web requests, and typically requires no input from you. Programs that transport email from one site to another are another example of this type of application.

We call these programs daemons. The Dæmons were characters from Greek mythology; They were neither good nor bad, they were small servant spirits who, to a large extent, did useful things for humanity. Something very similar to how web servers and mail servers do so many useful things for us today. That's why, for a long time, the BSD mascot has been that proud-looking dæmon with his trident and comfortable sports shoes.

There is a rule that programs that typically run as daemons are named with a final “d.” BIND is the Berkeley naming daemon (and the program that actually runs is called named); the web server Apache is calledhttpd, the line printer spool daemon is lpd and so on. This is an agreement, not an iron law; for example the main mail daemon sendmail is called sendmail, and not maild, as could be assumed from the above.

Sometimes you will need to communicate with a daemon. These communications are called signs; It is possible to communicate with a daemon (or any other running process) by sending it a signal. There are several different types of signals that you can send (some of them have a special meaning, others are interpreted by the application, and the application's documentation will tell you how that application interprets the signal).

You can only send a signal to a process that you own. If you send a signal to another user's process with kill(1) either kill(2) You will see a system message telling you that you do not have permission to do so. The exception to this is the user root, which can send signals to the processes of any user in the system.

FreeBSD will also send application signals in certain cases. If an application is poorly written, and tries to access memory that it is not intended to access, FreeBSD sends the signal to the process Segment violation (SIGSEGV). If an application has used the system call alarm(3) to be notified after a period of time has elapsed, the alarm signal will be sent (SIGALRM), and so on.

There are two signals that can be used to stop a process, SIGTERM and SIGKILL. SIGTERM It's the nice way to kill a process; the process can receive the signal, realize that you want it to shut down, close any log files you may have open, and generally finish whatever task you are currently doing before shutting down. In some cases a process may even ignore SIGTERM if you are immersed in a task that cannot be interrupted.

In contrast, a process cannot ignore a signal

SIGKILL. This is the “I don't care what you're doing, stop right now” signal. If you send a SIGKILL to a process FreeBSD will stop that process immediately.[1] .

Other signals you can use: SIGHUP, SIGUSR1 and SIGUSR2. They are general purpose signals, and different applications can do different things when used.

Suppose you have changed the configuration file of your web server; seems like a good time to tell the web server to read and apply the configuration. I could stop and restart httpd, but this would imply a short period of suspension of the service of your web server, which may not be acceptable. Most daemons were created thinking that they would be able to respond to the signal SIGHUP rereading its configuration file. Instead of killing and restarting httpd I could send him the signal SIGHUP. Since there is no standard way to respond to these signals, different daemons will have different behavior, so be sure to read the documentation for the daemon in question.

Signals are sent via kill(1), as can be seen in the following example.

Sending a signal to a process

This example shows how to send a signal to inetd(8). The configuration file inetd is /etc/inetd.conf and inetdwill reread said configuration file when a message is sent to it. SIGHUP.

1. Identify the process ID of the process you want to send the signal to using ps(1) and grep(1). grep(1) is used to search for text strings of your choice on standard output. It can run as a normal user, while inetd(8) runs as root, so you must pass the parameters ax to ps(1).

We see that the PID of inetd(8) is 198. In some cases grep inetd may also appear in this output. This is due to the way in which ps(1) you have to find the list of running processes.

4. Use kill(1) to send the signal. Because inetd(8) is being executed by root will have to use first his(1) to turn root.

Just as most orders UNIX® kill(1) It will not print any output if it has worked fine. If you send a signal to a process that you are not the owner of then you will see “kill: P.I.D.: Operation not permitted". If you type the PID incorrectly you may send the signal to a different process, which can be bad, or, if you are lucky, you will have sent the signal to a process that is not in use, and you will see "kill: P.I.D.: No such process”.

Why use /bin/kill?: Many shells incorporate their own kill; that is, the shell will send the signal directly, instead of executing /bin/kill. This can be very useful, but different shells have different syntax for specifying the name of the signal you send. Instead of trying to learn all of them, it's easier to use /bin/kill... whatever shell you prefer to use.

Sending other signals is very similar, just substitute TERM either KILL on the command line as needed.

Important: Killing random processes on the system is a bad idea. In particular, init(8), process ID 1, is very special. Execute /bin/kill -s KILL 1 It is a quick way to shut down your system. Always double check the arguments you run with kill(1) before to press Enter.

Grades

In FreeBSD much of the daily work is done in a command line interface called a shell. The main job of the shell is to receive orders through an input channel and execute them.

Many shells also have built-in functions to help with daily tasks such as file manipulation, file management with regular expressions, command-line editing, command macros, and environment variables. FreeBSD includes various shells, such as sh, the Bourne shell and tcsh, the improved C shell. There are many other shells available in the FreeBSD ports collection, such as zsh and Bash.

What shell to use? It's really a matter of taste. If you are going to program in C you may prefer to use a C-type shell, such as tcsh. If you are coming from the Linux world or if you are new to the command line interface of UNIX® you can try with Bash.

Keep in mind that each shell has unique properties that may or may not work with your preferred work environment, and you can choose which shell to use.

One of the common properties of shells is that they complete file names. Once you have entered the first letters of a command or file name, you can have the shell automatically complete the rest of the command or file name by pressing the key tab.

Let's look at an example. Suppose you have two files called as is and as is. You want to delete as is. What you would have to type is: rm ta[tab].[tab].

The shell would display on the screen rm fo[BEEP].which.

The [BEEP] is the console bell, meaning the shell is telling me that it couldn't completely complete the filename because there is more than one match. So much as is as as is start with ta, but it could only be completed untilsuch. If you type ., and again tab, then the shell is able to add the rest of the filename.

Another function of the shell is environment variables. Environment variables are pairs of key values ​​stored in the shell's environment space. This space can be read by any program invoked by the shell and therefore contains a lot of program configuration. This is a list of the most common environment variables and their meaning:

Establecer una variable de entorno difiere ligeramente de shell a shell. Por ejemplo, en las shells al estilo C como tcsh and csh, would be used setenv to set the environment variables. Under Bourne shells like sh and Bash, would be used export para establecer las variables de entorno actuales.

For example, to set or modify the environment variable EDITOR (low csh either tcsh) the following order establishes EDITOR as /usr/local/bin/emacs:

Under Bourne shells:

Most shells can also be made to display the contents of an environment variable by placing the character $in front of the variable name on the command line. For example, echo $TERM will display whatever value you have set for $TERM, because the shell expands the value of $TERM and passes it to the program echo.

Shells handle many special characters, called metacharacters, as special representations of data. The most common is the character *, which represents any number of characters in a file name. These special metacharacters can be used for filename expansion. For example, type echo * It is almost the same as entering ls because the shell takes all the files that match * and put them on the command line so that echo see them.

To prevent the shell from interpreting these special characters, they can be escaped from the shell by prefixing them with a backslash ().echo $TERM prints the terminal name you are using. echo $TERM print $TERM, literally.

The easiest way to change shells is by chsh. chsh will place you inside the editor that is configured in the environment variable EDITOR; If you have not modified it, the system will execute I saw, the default editor. Change the “Shell:” line as you prefer.

It can also be supplied to chsh the option -s; This will establish the shell without needing to enter the text editor. If for example you want Bash be your default shell, you can configure it as follows:

Execute chsh without parameters and editing the shell from there also works.

Note: The shell you want to use has to be included in /etc/shells. If a shell has been installed from port collection this should be done automatically.

If you have installed the shell manually, you will have to make this modification/etc/shells.

For example, if you manually installed Bash and placed it in /usr/local/bin, you should do the following:

and run again chsh.

Much of the FreeBSD configuration is done by modifying text files. For this reason, you may want to become familiar with a text editor. FreeBSD comes with a few as part of the base system and you'll find many more in the ports collection.

The simplest and easiest to learn text editor is one called ee, whose name comes from the English "easy editor." To start ee must be typed on the command line ee file-name, where file-name is the name of the file you want to edit. For example, to edit /etc/rc.conf type ee /etc/rc.conf. Once inside eeAll commands to manipulate the editor functions are listed at the top of the screen. The character ^ represents the key Ctrl of the keyboard, therefore ^e expands to key combination Ctrl+and. To get out of ee, press the key Esc and choose to leave the editor. The editor will then ask if you want to keep the changes if the file has been modified.

FreeBSD also comes with much more powerful text editors, such as I saw, as part of the base system, while other editors, such as Emacs and vim, are part of the FreeBSD ports collection (editors/emacs and editors/vim). These editors offer much more functionality and power with the disadvantage of being a little more complicated to learn how to use. Either way if you plan to do a lot of text editing work, learn how to use a more powerful text editor like vim either Emacs It will save you more time in the long run.

A device is a term most often used for activities related to system hardware, such as disks, printers, graphics cards, and keyboards. When FreeBSD boots, most of what FreeBSD displays are devices at the time they are detected. If you wish, you can review all the messages that the system issues during boot by consulting /var/run/dmesg.boot.

For example, acd0 is the first IDE CDROM drive, while kbd0 representa el teclado.

In an operating system UNIX®, most of these devices must be accessed through special files called device nodes, which are located in the directory /dev

When you add a new device to your system, or build support for additional devices, you may need to create one or more device nodes.

In systems without DEVFS (this concerns all versions prior to FreeBSD 5.0), device nodes are created using MAKEDEV(8) as can be seen in the following example:

This example should create the appropriate device node for the second installed IDE drive.

DEVFS Device File System (DEVice File System)

The file system device, or DEVFS, provides access to devices in the kernel namespace in the global filesystem namespace. Instead of having to create and modify device nodes, DEVFS is responsible for the dynamic maintenance of this file system.

Consult devfs(5) if you want more information.

DEVFS It is used by default in FreeBSD 5.0 ​​and later.

To understand why FreeBSD uses the format elf(5), you should first know a few things about the three “dominant” executable formats in UNIX®:

· a.out(5)

The format object of UNIX older and “classic”. It uses a short, compact header with a magic number at the beginning that is frequently used to identify the format (see a.out(5) for more information). It contains three loaded segments: .text, .data, and .bss as well as a symbol table and a string table.

· COFF

The target format of SVR3. The header consists of a section table, so it can hold more content than just the .text, .data, and .bss sections.

· elf(5)

The successor of COFF; It has multiple sections and possible 32-bit or 64-bit values. A big disadvantage: ELF It was also designed assuming that there would only be one ABI for each system architecture. That assumption is actually quite incorrect and even in the commercial SYSV world (which has at least three ABIs: SVR4, Solaris and SCO) it can be taken as good.

FreeBSD tries to solve this problem in some way by offering a tool to tick an executable ELFknown with information about the ABI it works with. If you want more information see the man page ofbrandelf(1).

FreeBSD comes from the “classic” camp and has used the format a.out(5), a technology used and tested in many, many generations of BSD versions until the start of the 3.X branch. Although it was possible to compile and run native binaries ELF (and kernels) on a FreeBSD system for some time before this, FreeBSD at first stayed “against the grain” and did not switch to ELF as default format. Because? Well, when the Linux world made its painful transition to ELF It wasn't so much to escape from the format a.out as well as for its inflexible shared library mechanism based on jump tables, which made building shared libraries equally difficult for both developers and vendors. Since the toolsELF available offered a solution to the problem of shared libraries and were seen by many people as “the way forward”, the cost of migration was accepted as necessary and the transition was made. The FreeBSD shared library mechanism is designed more closely to the style of the FreeBSD shared library system. SunOS™ from Sun and, as such, is very easy to use.

So why are there so many different formats?

In a time far, far away, simple hardware existed. This simple hardware supported a small, simple system. a.out It was ideal for the job of representing binaries on this very simple system (a PDP-11). As people carried UNIX From this simple system, they retained the format a.out because it was enough for the first shipments of UNIX to architectures like Motorola's 68k, VAXen, etc.

Then some brilliant hardware engineer decided that if he could force the software to do some dirty tricks he could get around certain design hurdles and allow his CPU core to run faster. Although it was made to work with this new type of hardware (known then as RISC), a.out was not well suited for this hardware, so several formats were developed to get better performance from this hardware than the limited, simple format a.outCOFF,ECOFF and some other stranger formats were invented and their limitations explored until the choice was reached in favor of ELF. could offer. That's how

Additionally, program sizes were becoming gigantic and disks (and physical memory) were relatively small, so the concept of a shared library was born. The VM system also became more sophisticated. While each of these advances was made using the format a.out, its usefulness was gradually reduced with each new option. Additionally, people wanted to load things dynamically at runtime, or discard parts of their program after the startup code ran to save main memory and swap space. As languages ​​became more sophisticated, people began to see the need to enter code before the start of the program automatically. Many hacks were made to the format a.out to allow all these things to happen, and the truth is that for a while they worked. But a.out It was not there to solve all these problems without increasing the load and complexity of the code. Although ELFELF had to wait until it was more painful to stay with a.out to migrate to ELF. solved many of these problems, at that time it would have been terrible to abandon a system that simply worked, so

However, as time went by, the build tools from which FreeBSD derived its own (the assembler and loader, most notably) evolved into two parallel trees. The FreeBSD tree added shared libraries and fixed some bugs. The GNU people who originally wrote these programs rewrote them and added a simpler way to have cross compilers, using different formats at will, etc. Although many people wanted cross compilers targeting FreeBSD, they were out of luck, because the sources that FreeBSD had for aceand ld They were not ready to fulfill that task. The new GNU toolchain (binutils) supports cross compilation, ELF, shared libraries, C++ extensions, etc. Additionally, many vendors are releasing binaries ELF, and it's a very good thing that FreeBSD can run them.

ELF is more expressive than a.out and allows a more extensible base system. The tools ELF They are better maintained and offer cross-compilation support, which is very important for many people. ELF may be a little slower than a.out, but trying to measure it can be difficult.

There are also numerous details that are different between the two in how they map pages, how they handle startup code, etc. None of these are very important, but there are differences. Over time, support fora.out will be removed from the kernel GENERIC, and it is quite possible that the ability to run such binaries will be removed from the kernel once the need to use programs a.out has passed.

The most comprehensive FreeBSD documentation is in the man pages. Almost all system programs come with a brief reference manual explaining the basic operation and its different arguments. These manuals can be reviewed through man. The use of man It's simple:

order is the name of the order you want to know about. For example, for more information about ls write:

The online manual is divided into numbered sections:

1. User commands.

2. System calls and error numbers.

3. Functions in C libraries.

4. Device drivers.

5. File formats.

6. Games and other hobbies.

7. Information on various topics.

8. Commands related to system maintenance and its operation.

9. Kernel developers.

In some cases, the same topic may appear in more than one section of the online manual. For example, there is a user command chmod and a system call chmod(). In this case you can tell man which one you want to consult by specifying the section:

This will display the manual page for the user command chmod. References to a particular section of the online manual are traditionally placed in parentheses in written documentation, so chmod(1) refers to the user commandchmod and chmod(2) refers to the system call.

This is great if you know the name of the program and simply want to know how to use it. But what if you can't remember the name of the order? You can use man to perform a keyword search on program descriptions using the argument -k:

This order will display a list of orders that contain the keyword “mail” in their descriptions. This is functionally equivalent to using apropos.

So, are you watching all those sexy shows on /usr/bin but you don't have the slightest idea what most of them do? Do the following:

either

which does exactly the same

FreeBSD includes many applications and utilities produced by the FSF (Free Software Foundation). In addition to the corresponding manual pages, these programs come with more detailed hypertext documents, called filesinfo, which can be viewed with info, or if you have installed emacs, with the info mode of emacs.

If you want to use the order info(1) just type:

For a brief introduction, type h. For quick reference, type ?.

Copyright © 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 The FreeBSD Documentation Projec

Fountain:

https://www.ibercom.com/soporte/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=71

http://www.freebsd.org

http://www.nierox.com/2007/10/lista-de-comandos-basicos-para-freebsd/