Configuring OpenSSH

Configuring OpenSSH



SSH server (sshd)




/etc/ssh/sshd_config 


Directives:

- AllowUsers

- DenyUsers

- HostKey

- ListenAddress

- PermitRootLogin

- Port

- Protocol







SSH client 





/etc/ssh/ssh_config





file.







The





/etc/ ssh/ssh_config 






file is used to specify default parameters for all users running ssh on the system.





A user can override these defaults using the





~/.ssh/ssh_config 






file in his or her home directory.






The precedence for ssh client configuration settings are as follows:





1. Any command-line options included with the ssh command at the shell prompt



2. Settings in the ~/.ssh/ssh_config file



3. Settings in the /etc/ssh/ssh_config file










Connect




ssh –l user_name ip_address





Don’t forget the –l parameter. If you don’t, the SSH client will
attempt to authenticate you to the remote system using the same
credentials you used to authenticate to the local system.







Encryption III

Encryption IV

Tunneling Traffic Through SSH

One of the key security issues you must deal with as a system
administrator is the fact that many commonly used network protocols
transfer information as clear text. Good examples of this are the POP3
and IMAP daemons we discussed in the preceding chapter. We noted that
for your Linux MTA to download e-mail messages to client systems, you
must first enable either your POP3 or IMAP daemon via xinetd. Once
done, end users can use an e-mail client to connect to the MTA and
download their mail using the appropriate protocol. The problem,
however, is the fact that both of these daemons transfer data as clear
text by default. That means the usernames and passwords users send to
authenticate to the MTA are sent as clear text along with all the con-
tents of their e-mail messages. This allows anyone with a sniffer to
capture packets and view the contents of the transmissions.



The good news is SSH can be used to encrypt clear-text traffic by
tunneling it through an SSH connection. When client software for the
tunneled protocol (such as an e-mail client using POP3) establishes a
connection with the local SSH client, the traffic is encrypted using
SSH and tunneled through to the SSH server. On the SSH server end, the
traffic is decrypted and then forwarded to the appropriate target
service (in this case, the POP3 daemon). This is great, because the
information is encrypted before being transmitted, even though the
original protocol (in this case, POP3) doesn’t support encryption.




Let’s walk through an example of how you can use SSH to tunnel POP3 traffic:



1. Make sure the ssh client is installed on the local system where the
   e-mail client will run.


2. Make sure the sshd daemon is installed and running on the POP3 server.


3. Ensure IP port 22 is open on the server where sshd is running.


4. On the system where sshd is running, switch to root and edit the
 


  /etc/ssh/sshd_config 



   file.


5. Locate the AllowTcpForwarding parameter, uncomment it if necessary,
   and then set it to a value of yes. An example is shown here:



    AllowTcpForwarding  yes



6. Save your changes to the file and exit the editor.


7. Restart the sshd daemon by entering systemctl restart sshd at the
   shell prompt (as root).



8. Switch to the client system.



9. Create a local ssh tunnel from a local high IP port (in this
   example, port 2345) to port 110 on the POP3 server using the following
   command (enter the remote user’s password when prompted):



    ssh -f -N -L 2345:pop3_host_address:110 user_name@pop3_host_address




   The options specified in this command do the following:



   • –N and –f 

     Tell ssh not to execute a command remotely on the server
      and to run in the background after prompting for the remote user’s
      password


   • –L 

      Specifies three things:

      • The local port to be used for the client end of the tunnel (in
        this case, 2345)

      • The hostname or IP address of the remote POP3 server

      • The port on the remote server that will be used for the server
        end of the tunnel (in this case, 110)



   You don’t have to use port 2345. You can use the same port on both
   ends if desired. However, be aware that you will need to switch to the
   root user if you want to use a port number less than 1024 on the
   client side of the tunnel. These are called privileged ports.



10. With the tunnel established, configure the local e-mail client
    program to retrieve mail from the local system on the port you
    configured for the client end of the SSH tunnel. In this example, you
    would configure it to get mail from the local system’s IP address on
    port 2345. An example of how to do this with the Evolution e-mail
    client is shown in Figure 18-6.


    Note that I used the hostname of the local host, not the POP3 server, in the Server field.
    I also added the port number of the workstation end of the tunnel to the end of the
    hostname.




At this point, when the client uses the POP3 protocol to download new
messages, the SSH client on the local system will encrypt the request
and forward it to the SSH server through the SSH tunnel you
established. The SSH server will receive the request, decrypt it, and
then pass the data on to the local port 110, where the POP3 daemon is
listening. The cool thing about this process is that it is completely
transparent to the e-mail client software. As far as it’s concerned,
it’s retrieving e-mail from a local POP3 server.



You can test the tunnel you created using the telnet command from the
client end of the tunnel. The syntax is


telnet localhost client_tunnel_port


Here’s an example:



telnet localhost 2345



When you do this, you should see a connection established with the remote system where the POP3 daemon is running. An example is shown in Figure 18-7.




You can also tunnel your X server traffic to remote X clients using an SSH connection. This is important because unencrypted X traffic provides an attacker with a gold mine of information that he or she can use to compromise your systems.






To configure a remote X client without encryption, you can use the
following procedure:


1. On the remote X client, enter



   xhost +X_server_hostname



   This tells the client to accept connections from the X server.



2. On the X server, enter



   DISPLAY=X_client_hostname:0.0



   and then enter



   export DISPLAY



   This tells the X server to display its output on the remote X client.




3. From the X client, use the ssh client to access the shell prompt on
   the X server and then run the graphical application you want displayed
   on the X client. For example, you could enter gedit at the shell
   prompt to remotely display the gedit text editor. You could also enter
   office at the shell prompt to remotely display the OpenOffice.org
   suite.








This procedure works, but all the X traffic is transmitted
unencrypted. This isn’t good. Instead, you should use SSH to tunnel
the X server traffic between the X server and the X client. You can do
this using one of the following options:



• Use the –X option with the ssh client program.


• Set the 


ForwardX11 


option to a value of 


yes


in the


 /etc/ssh/ssh_config 


  file on the X client system.




Once this is done, you then need to set the


X11Forwarding 


option to



yes 



in the



/etc/ssh/sshd_config 



file on the X server system.












LX0-104 Exam Objectives (X)

Securing I

Configuring xinetd and inetd


In this part of this chapter, you learn how to configure Linux
“super-daemons.” Most Linux distributions install a wide variety of
network services during the system installation process. Most of these
services, such as Telnet, are very handy and provide a valuable
service. However, they aren’t needed most of the time. We need a way
to provide these services when requested but then unload them when
they aren’t needed, saving memory, reducing CPU utilization, and
increasing the overall security of the system.



Depending on your distribution, there are two ways to do this. The
following options are discussed here:



• Configuring xinetd
• Configuring inetd





Configuring xinetd

Many Linux distributions include a special daemon called xinetd that
can be used to manage a number of different network services. In this
part of this chapter, you learn how to configure and use xinetd. We’ll
discuss the following topics:



• How xinetd works
• Configuring xinetd network services
• Using TCP Wrappers



Let’s begin by discussing how the xinetd daemon works.



How xinetd Works

The xinetd daemon is a super-daemon. It’s called a super-daemon
because it acts as an intermediary between the user requesting network
services and the daemons on the system that provide the actual
service. This is shown in Figure 17-26.




When a request for one of the network services managed by xinetd
arrives at the system, it is received and processed by xinetd, not the
network daemon being requested. The xinetd daemon then starts the
daemon for the requested service and forwards the request to it. When
the request has been fulfilled and the network service is no longer
needed, xinetd unloads the daemon from memory.




Some of the network services managed by xinetd include the following:



• chargen
• daytime
• echo
• ftp
• pop3
• rsync
• smtp




Configuring xinetd Network Services


As with all the network services I’ve discussed, the xinetd
configuration files are stored in /etc. The xinetd daemon itself is
configured using the



/etc/xinetd.conf 


file. Generally speaking, you won’t need to make many changes to this file. The default
configuration usually works very well.



At the end of this file you will notice a directive that reads



includedir /etc/xinetd.d



This line tells the xinetd daemon to use the configuration files in
/etc/xinetd.d. These files tell xinetd how to start each service when
requested. Each of these files is used to configure the startup of a
particular service managed by xinetd.


For example, the 


vsftpd file 


in


/etc/xinetd.d 


is used to configure the vsftpd FTP server daemon. The xinetd configuration
settings for vsftpd in this file are shown here:



service ftp
{

socket_type     = stream
protocol        = tcp
wait            = no
user            = root
server          = /usr/sbin/vsftpd

# server_args        =
# log_on_success     += DURATION USERID
# log_on_failure     += USERID
# nice               = 10
   disable            = yes


}




This file doesn’t configure the daemon itself. It only tells xinetd
how to start up the daemon. The actual configuration file for the
vsftpd daemon itself is in /etc/vsftpd.conf.


One of the most important parameters in the 


/etc/xinetd.d/vsftpd



file is the disable directive.


This directive specifies whether or not xinetd is allowed to start the
daemon when requested.



In the preceding example, this directive is set to yes, which means the daemon will not 
be started when requested. 



The daemon to actually start is specified by the 


server = directive


In the example, xinetd will start the /usr/sbin/vsftpd daemon. 


server          = /usr/sbin/vsftpd



To enable this daemon, you need to edit this file and change the disable
parameter to a value of no.



disable            = no




After changing a value in any of the files in /etc/xinetd.d, you need to 
restart the xinetd daemon using its init script in /etc/rc.d/init.d or /etc/init.d.



TIP  If you enable a service provided by xinetd, you’ll need to create
an exception in your Linux system’s host firewall to allow traffic for
the IP port used by the daemon.






Using TCP Wrappers


If you enable a particular service using its configuration file in the
/etc/xinetd.d/ directory, any host can connect to it through xinetd.



However, depending on how your system is deployed, you may need to
control access to these network services. You may want to limit access
to only a specific set of hosts and deny access to everyone else.



If this is the case, you need to configure these services to use TCP
Wrappers, which are used by xinetd to start and run the network
services using a set of configuration files that specify who can and
who can’t access the service.




To use TCP Wrappers, you first need to enable the functionality in
each service’s configuration file in /etc/xinetd.d. Do the following:



1. Verify that the tcpd package has been installed on your Linux system.


2. Open the appropriate configuration file in a text editor.


3. Comment out the existing server = line from the file.


4. Add the following line:


     server      = /usr/sbin/tcpd


This will cause xinetd to start the tcpd daemon instead of the service
daemon itself.



5. Add the following line:


     server_args       = path_to_daemon


This tells the tcpd daemon to then run the requested network daemon.
In the example shown here, the /etc/xinetd.d/telnet file has been
configured to run the vsftpd daemon within a TCP Wrapper:



service ftp
     {
# #
socket_type     = stream
protocol        = tcp
wait            = no
user            = root
# server          = /usr/sbin/vsftpd


server          = /usr/sbin/tcpd
server_args     = /usr/sbin/vsftpd


# log_on_success     += DURATION USERID
# log_on_failure     += USERID
# nice               = 10
   disable            = no

}



6. Save the file and restart the xinetd daemon.





Next, you need to create your access controls. The tcpd daemon uses
the 



/etc/hosts.allow 


and


/etc/hosts.deny 



files to specify who can access the services it manages.



Entries in /etc/hosts.allow are allowed access.


Hosts in /etc/hosts.deny are not allowed access. 



The syntax for both of these files is



service: host_addresses



As these files are processed, the search stops as soon as a matching
condition is found in a file. Files are no longer processed after this
occurs. The following steps occur in the order shown:


• Access will be granted if a matching entry is found in the
  /etc/hosts.allow file.

• If not, access will be denied if a matching entry is found in the
  /etc/hosts.deny file.

• If this does not occur, access will be granted.




For example, suppose you needed to configure the /etc/hosts.allow file
to allow access to the vsftpd daemon for just a few specific hosts.
The following entry grants access to the vsftpd service to hosts with
the IP addresses of 192.168.1.10 and 192.168.1.102.



vsftpd:     192.168.1.10, 192.168.1.102




Some distributions use the inetd daemon instead of xinetd. This daemon
works in much the same manner as xinetd. Let’s learn how it works
next.







Configuring inetd


The inetd daemon is a super-daemon like xinetd, but it is typically
used on older Linux distributions. Like xinetd, the inetd daemon acts
as a mediator for connection requests to network services running on
the Linux host. It accepts connection requests from client systems,
starts the requested service, and then forwards the requests from
clients to the newly started daemon. When the transaction is complete
and the connection from the client is terminated, the daemon is
stopped on the Linux host.



As we discussed with xinetd, managing the network services on your
Linux host in this way has advantages and disadvantages. Key among
these is the fact that it conserves system memory and CPU resources.
The network daemon is started only when it is needed. When it isn’t
needed, it’s removed from memory until it is requested again. However,
this benefit comes at a cost in terms of latency. When a service is
requested by a client, the client must wait for a short period of time
while the necessary daemon is loaded and the connection established.
Therefore, inetd (and xinetd) should only be used to manage network
services that are needed only occasionally on the system.




The inetd daemon is configured using the 



/etc/inetd.conf 



file. Unlike the xinetd daemon, all the services managed by inetd are configured in
this single configuration file. 



Each line in this file configures a single service to be managed by inetd. The syntax used in 
inted.conf is shown here:



service_name  socket_type  protocol  flags  user  executable  arguments




Each of the parameters in this line is described in Table 17-6. Here
is a sample entry in inetd.conf for the vsftpd daemon:

ftp    stream    tcp    nowait    ftp      /usr/sbin/tcpd     vsftpd




Notice in this example that you can use TCP Wrappers with inetd just
as you did with xinetd. In this example, when a client tries to
establish an FTP connection with this Linux host, the inetd daemon
will start the tcpd daemon and pass to it the name of the actual
daemon to be started (vsftpd) as a server argument. As with xinetd,
using TCP Wrappers with inetd allows you to control access to the
network services running on the host using




the



/etc/hosts.allow 



and



/etc/ hosts.deny 



files.










LX0-104 Exam Objectives (V and U, 323, 647 - 689)

Controlling User Access IV

Configuring User Limits

You can impose limits on how many times users may log in, how much CPU
time they can consume, and how much memory they can use on a Linux
system. This can be done in two ways:



• Using pam_limits to restrict access to resources

• Using ulimit to restrict access to resources





Using pam_limits to Restrict Access to Resources


You can limit user access to Linux system resources using a Pluggable
Authentication Modules (PAM) module called pam_limits, which is
configured using the


/etc/security/limits.conf



file. This file contains resource limits that you can configure using the following
syntax:



domain     type     item     value



This syntax is described here:



• domain 

   Describes the entity to which the limit applies. You can use
   one of the following values:

        • user Identifies a specific Linux user
        • @group_name Identifies a specific Linux group
        • * Specifies all users


• type 

  Defines a hard or soft limit. A hard limit cannot be exceeded.
  A soft limit can be temporarily exceeded.


• item 

  Specifies the resource being limited. You can use the values
  shown in Table 17-1.



• value 

  Specifies a value for the limit.





For example, to configure the rtracy user with a soft CPU limit of 15
minutes, you would open the


/etc/security/limits.conf 


file in a text editor and then enter the following:



rtracy     soft     cpu     15



This limit could be useful if the user is running a CPU-intensive
program that is hogging cycles away from other users. Likewise, you
could also limit the rtracy user to a maximum of two concurrent logins
by entering the following in the file:



rtracy     hard     maxlogins     2



This would prevent any logins to the system as the rtracy user after
two initial logins were successful.



In addition to using pam_limits, you can also limit user access to
system resources using the ulimit command. Let’s look at how this is
done next.




Using ulimit to Restrict Access to Resources


You can also use the ulimit command to configure limits on system
resources. However, be aware that the limits you configure with ulimit
are applied only to programs launched from the shell prompt. The
syntax for using ulimit is ulimit options limit. You can use the
following options with ulimit:


• –a

view the current value for all resource limits



• –c   (max size files)

Sets a limit on the maximum size of core files in blocks. If you set
this limit to a value of 0, core dumps on the system are disabled.


• –f   (max created files)

Sets a limit on the maximum size (in blocks) of files created by the shell.


• –n   (max open files)

 Sets a limit on the maximum number of open file descriptors.


• –t (max cpu time)

Sets a limit on the maximum amount of CPU time (in seconds) a process may use.


• –u (max processes)

Sets a limit on the maximum number of processes available to a single user.


• –d (max data)

Sets a limit on the maximum size (in KB) of a process’s data segment in RAM.


• –m (max resident)

Sets a limit on the maximum resident size (in KB) of a process in RAM.


• –s (max stack size)

Sets a limit on the maximum stack size (in KB).


• –H

Sets a hard resource limit.


• –S

 Sets a soft resource limit.




You can use the –a option with the ulimit command to view the current
value for all resource limits. This is shown in Figure 17-5.






You can also use ulimit to set resource limits. For example, to set a
soft limit of 50 processes, you would enter



ulimit –S –u 50 



at the shell prompt. The current user could then own no more than 50
concurrent shell processes.

















LX0-104 Exam Objectives (V and U, 323, 647 - 689)

Controlling User Access II

To root or Not to root?


As we discussed earlier in this book, every Linux system, whether a
workstation or a server, includes a default superuser account named
root. This account has full access to every aspect of the system. As
such, it should be used with great care. In this part of this chapter,
we’ll discuss the following:



• Proper use of the root user account

• Using su

• Using sudo





Let’s begin by discussing the proper way to use the root user account.



Proper Use of the root User Account

One of the key mistakes made by new Linux users is excessive use of
the root user account. There’s a time and a place when the root user
account should be used. However, most of your work on a Linux system
should be done as a non-root user account. The rule of thumb that you
should follow is this: only use root when absolutely necessary. If a
task can be completed as a non-root user, then it should be done so.




Why is the proper use of the root user account of concern? A few pages
back, we discussed the risks of leaving a logged-in system unattended.
Imagine the havoc an intruder could wreak if they were to happen upon
an unattended system that was logged in as root! All of the data on
the system could be accessed and copied. Major configuration changes
could be made to the daemons running on the system. Heaven only knows
what kind of malware could be installed.



In a nutshell, a system logged in as root represents a serious
security risk. Leaving such a system unattended represents a critical
security risk. Everyone, including the system administrator (that’s
you!), should have a standard user account that they always use to log
in to the system.


If you find that you need root-level access while working on the
system, you can use the su command to temporarily gain root-level
privileges to the system. Let’s discuss how this is done next.





Using su

By now, you should already know how su works. We’ve used it countless
times in this book’s exercises. This command allows you to change to a
different user account at the shell prompt. The syntax for using su is



su options user_account


If no user account is specified in the command, su assumes you want to switch to the root user account. Some of  the more useful options you can use with su include the following:


• –

Loads the user’s environment variables. Notice that we’ve always
used the su – command to switch to the root user account. This changes
to root and loads root’s environment variables.


• –c command 

Switches to the user account and runs the specified command.

• –m 

Switches to the user account but preserves the existing environment variables.



The su command will be your best friend as a Linux administrator.
However, there are times when other users may need root-level access.
You can use sudo to give them limited root access. Let’s discuss how
sudo works next.





Using sudo

Suppose you have a power user on your Linux system. This user may be a
programmer, a project manager, or a database administrator. Users in
this category may frequently need to run some root-level commands. But
do you really want to give them your root password? Probably not. You
want them to be able to run a limited number of commands that require
root privileges, but you don’t want them to have full root access.
This can be done using sudo.



The sudo command allows a given user to run a command as a different
user account. As with su, it could be any user account on the system;
however, it is most frequently used to run commands as root. The sudo
command uses the


/etc/sudoers 


file to determine what user is authorized to run which commands. This file uses the following aliases
to define who can do what:



• User_Alias  Specifies the users who are allowed to run commands

• Cmnd_Alias  Specifies the commands that users are allowed to run

• Host_Alias  Specifies the hosts users are allowed to run the commands on

• Runas_Alias Specifies the usernames that commands may be run as



To edit your


/etc/sudoers 


file, you need to run the


visudo 


command as your root user. The /etc/sudoers  file is loaded in your default editor, which is usually vi. Your changes are written to


/etc/sudoers.tmp 

until committed. This is shown in Figure 17-3.



On most distributions, the sudoers file is configured by default such
that users must supply the root password when using sudo. Obviously,
this configuration doesn’t accomplish anything. If the user already
knows the root password, what’s the point of configuring sudo? This
configuration is specified by the following lines in sudoers:



# In the default (unconfigured) configuration, sudo asks for the root password.
# This allows use of an ordinary user account for administration of a freshly
# installed system. When configuring sudo, delete the two
# following lines:


Defaults targetpw   # ask for the password of the target user i.e. root
ALL     ALL=(ALL) ALL   # WARNING! Only use this together with 'Defaults
targetpw'!


1.

To fix this, comment out the two lines specified here in the sudoers
file. Then you can begin your sudoers configuration in the file.
First, you need to use User_Alias to define an alias containing the
user accounts (separated by commas) you want to allow to run commands.
The syntax is


User_Alias alias = users

For example, to create an alias named PWRUSRS that contains the tux,
rtracy, and ksanders user accounts, you would enter the following in
the /etc/sudoers file:



User_Alias PWRUSRS = student, ksanders, rtracy




TIP All alias names must start with a capital letter!




2.

You next need to use Cmnd_Alias to define an alias that contains the
commands (using the full path) that you want the users you just
defined to be able to run. Separate multiple commands with commas. For
example, if your users are programmers who need to be able to kill
processes, you could define an alias named KILLPROCS that contains
your kill command, as shown here:


Cmnd_Alias KILLPROCS = /bin/kill, /usr/bin/killall





3.

Then you need to use Host_Alias to specify what systems the users can
run the commands on. For example, to let them run the commands on a
system named WS1, you would use the following:

Host_Alias MYHSTS = openSUSE



4.

Finally, you need to glue these aliases together to define exactly
what will happen. The syntax is

User_Alias Host_Alias = (user) Cmnd_Alias



Using the aliases just defined, you could allow the specified users to
run the specified commands on the specified hosts as root by entering

PWRUSRS     MYHSTS = (root) KILLPROCS




To exit the editor, press esc and then enter :exit. 

The visudo utility will check your syntax and inform you if you’ve made any errors. At
this point, the users you defined can execute the commands you
specified as root by entering sudo command at the shell prompt.


For example, the rtracy user could kill a process named vmware-toolbox
(owned by root) by entering


sudo killall vmware-toolbox


at the shell prompt. After the rtracy user supplies his password, the process will
be killed.








LX0-104 Exam Objectives (V and U, 323, 647 - 689)

Groups

Groups


The /etc/shadow File With most Linux distributions that use local
authentication, your users’ passwords will be stored in encrypted
format in the /etc/shadow file. This file is linked to the /etc/passwd
file we discussed previously. Each of the user accounts listed in
/etc/passwd has a corresponding entry in /etc/shadow, as shown in this
example:



openSUSE:~ # cat /etc/shadow
...
root:$2a$05$h03HfGFSi2i8GlotOYgreeBelUlHc.z/2KxyQQF7RSo./TdLOrDJa:15035::::::
sshd:*:14796:0:99999:7:::
uucp:*: 16015::::::
wwwrun:*: 16015::::::
hsaez:$6$JbgjOmU1SXu1$ON0iVUmsrzvVxd7D2AeYbriZ1gDRS/W/
xnoeXVzcBkZIeNSJMAKFWfMvl4RvWki0HIQLrfV6bkNIAk6vCEOyP0:16392:0:99999:7:::
ksanders:$2a$05$KL1DbTBqpSEMiL.2FoI3ue4bdyR.eL6GMKs7MU6.nZl5SCC7/
REUS:15043:0:99999:7:::
rtracy:$6$L58Cq/vWQJaM$u7.1.UmlGVquz6qQ0LaHXQzbTgc6kC6uc1sR/GgelNjbF/
FqJUkwmhVdxO3Qxs3HgXQJLIptYJ4HD7bvMoxbd0:16392:0:99999:7:::





As with /etc/passwd, each user account is represented by a single line
in the /etc/shadow file. Each record is composed of the following
fields, each separated by a colon:



Username:Password:Last_Modified:Min_Days:Max_Days:Days_Warn:Disabled_Days:Expire



For example, the record for ksanders is as follows:



ksanders:$2a$05$KL1DbTBqpSEMiL.2FoI3ue4bdyR.eL6GMKs7MU6.nZl5SCC7/
REUS:15043:0:99999:7:::




Here’s what each of these fields contains:



• Username 

This is the user’s login name from /etc/passwd.


• Password

This is the user’s password in encrypted format. In the
preceding example, the password for ksanders is M3linux273. However,
to prevent someone from accessing the /etc/shadow file and grabbing
the user passwords from it, it is stored in encrypted format. You may
notice that all of the system user accounts have a simple asterisk in
this field (*). This indicates that these accounts aren’t allowed to
log in to the system. For example, if I tried to log in to my system
as ftp, I would be denied access even though the ftp user account
exists.


• Last_Modified 

This field displays the number of days since January
1, 1970, that the password was last changed. In this example, it has
been 15,043 days.


• Min_Days 

This field displays the minimum number of days required
before a password can be changed. In this example, it is set to 0
days.


• Max_Days 

This field displays the maximum number of days before a
password must be changed. In this example, it is set to 99,999 days.
Effectively, this means a password change isn’t required.


• Days_Warn 

This field displays the number of days prior to password
expiration that the user will be warned of the pending expiration. In
this case, it’s set to 7 days.


• Disabled_Days 

This field displays the number of days to wait after a
password has expired to disable the account. In this example, it’s set
to a null value.


• Expire 

This field displays the number of days since January 1, 1970,
after which the account will be disabled. In this example, it is set
to a null value, indicating the account never expires.





As you can see, it is very important that these two files stay
synchronized with each other. If they get out of whack, then it’s
possible that a user may not be able to log in or a service may not be
able to access the file system correctly.



The good news is that these files usually stay in sync as they are
supposed to without any intervention on the part of the administrator.
The only times I’ve seen these two files become unsynchronized is when
the administrator decides to manually edit these files with a text
editor. I strongly discourage this practice. Your Linux system
includes a wide variety of utilities that are used to manage user
accounts and passwords on your system. (We’ll discuss how to use these
utili- ties later in this chapter.) You should always use these
utilities instead of a text editor to manage user accounts. Doing so
will ensure that both files are edited appropriately and stay
synchronized with each other.



To verify your /etc/passwd and /etc/shadow files, you can use the



pwck



command at the shell prompt. This utility will verify each line in the
two files and make sure they are valid. Any errors are reported on the
screen, as shown in this example:



openSUSE:/ # pwck
Checking '/etc/passwd'
User 'pulse': directory '/var/lib/pulseaudio' does not exist.
User 'usbmux': directory '/var/lib/usbmuxd'  does not exist.
Checking '/etc/shadow'.




As you can see, pwck found that the home directories specified for the
pulse and usbmux system user accounts don’t exist. Everything else
checked out. If, for some reason, the


/etc/passwd



and the


/etc/shadow 


files are out of synchronization, you can use the


pwconv 



command at the shell prompt to fix the files.



This utility will add any missing user accounts from /etc/passwd to /etc/shadow.









LX0-104 Exam Objectives (V and U, 323, 647 - 689)

Configuring Network V

Configuring Name Resolver Settings



When configuring IP settings for a network interface, you also need to
specify the system’s host- name and the IP address of your DNS server.
Because you are most likely a savvy Internet user, you know that you
can use domain names to navigate to particular hosts on the Web.
However, your Linux system (or any other operating system, for that
matter) actually can’t work with the alphanumeric domain names that we
are used to.





For example, when you open a browser window and enter
http://www.google.com in the URL field, your browser, IP stack, and
operating system have no clue where to go to get the requested
information. To make this work, your local system needs to first
resolve these domain names into IP addresses.





In the old days, basic hostname-to-IP-address resolution was performed
by the 


/etc/hosts 


file, which contains IP-address-to-hostname mappings.




NOTE

The /etc/hosts file still exists on Linux systems. In fact, it is
the first name resolver used by default. 

Only if a record for the requested domain name doesn’t exist in the hosts file 
will the operating system then try to resolve the hostname using DNS. Because
of this, you have to manage your hosts file very carefully. Many
network hacks exploit this function of the operating system. A
malicious website or malware may try to rewrite your hosts file with
name mappings that point you to fake websites on the Internet that
look like your favorite auction or banking site but instead are
elaborate phishing websites designed to steal your personal
information.




The hosts file contains one line per host record. The syntax is



IP_address host_name alias



For example, consider the following hosts file entry:



192.168.1.1 mylinux.mydom.com mylinux



This record resolves either the fully qualified DNS name of
mylinux.mydom.com or the alias (CNAME) of mylinux to an IP address of
192.168.1.1. Usually this file only contains the IP address and
hostname of the local system, but you can add other entries too.




Using the hosts file to resolve hostnames works just fine; however, it
really isn’t feasible as the sole means of name resolution. The file
would have to be huge in order to resolve all the domain names used by
hosts on the Internet. In addition, you would have to manually add,
remove, and modify hostname mappings in the file whenever a domain
name changed on the Internet. What a nightmare! Can you imagine trying
to manage this type of hosts file for an entire network of users?




A better option is to submit the domain name to a DNS server. When a
DNS server receives a name resolution request, it matches the domain
name submitted with an IP address and returns it to the requesting
system. Your system can then contact the specified host using its IP
address. Here’s how it works:



1. The system needing to resolve a hostname sends a request to the DNS
   server it has been configured to use on

IP port 53.


If the DNS server is authoritative for the zone where the requested hostname resides,
it responds with the appropriate IP address. If not, the process
continues on to step 2.


NOTE A DNS server is considered to be authoritative if it has a record
for the domain name being requested in its database of name mappings.



2. The DNS server sends a request to a root-level DNS server. There
   are 13 root-level DNS servers on the Internet. Every DNS server is
   automatically configured with the IP addresses of these servers. These
   root-level DNS servers are configured with records that resolve to
   authoritative DNS servers for each top-level domain (.com, .gov, .edu,
   .au, .de, .uk, .ca, and so on).


3. The root-level DNS server responds to your DNS server with the IP
   address of a DNS server that is authoritative for the top-level domain
   of the domain name you are trying to resolve.


4. Your DNS server sends the name resolution query to the DNS server
   that is authoritative for the hostname’s top-level domain (such as
   .com).


5. The top-level domain DNS server responds to your DNS server with
   the IP address of a DNS server that’s authoritative for the DNS zone
   of the hostname you need to resolve.

6. Your DNS server sends a name resolution request to the DNS server
   that’s authoritative for the zone where the hostname you are trying to
   resolve resides.


7. The authoritative DNS server responds to your DNS server with the
   IP address for the hostname.


8. Your DNS server responds to your system with the IP address mapped
   to the hostname, and the respective system is contacted using this IP
   address.



NOTE Once this process happens for a particular name mapping, most DNS
servers will cache the mapping for a period of time. That way, if a
resolution request for the same hostname is received again, they can
respond directly to the client without going through this whole
process again.




Therefore, to make this system work, you must provide your system with
the IP address of the DNS server you want it to use. This is
configured in the


/etc/resolv.conf 


file. This file defines the search prefix and the name servers to use. Here is some
sample content from my openSUSE system’s resolv.conf file:



search mydom.com
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 192.168.2.1



As you can see in this example, the file contains two types of entries:


• search 

Specifies the domain name that should be used to fill out
incomplete hostnames. For example, if you were to try to resolve a
hostname of WS1, the name will be automatically converted to the fully
qualified domain name of WS1.mydom.com. The syntax is search domain.



• nameserver 

Specifies the IP address of the DNS server you want to
use for name resolution. You can configure up to three DNS servers. If
the first server fails or is otherwise unreachable, the next DNS
server is used. The syntax is



nameserver DNS_ server_IP_address




You can use the



/etc/nsswitch.conf



(name service switch) file to define the order in which services will be used for name resolution.
Here are the two lines of the file you need to be concerned with:



hosts:        files dns
networks:     files dns



These two entries specify that the /etc/hosts file (files) is
consulted first for name resolution. If there is no applicable entry,
the query is then sent to the DNS server (dns) specified in the
resolv.conf file.


TIP You can use the



hostname 



command at the shell prompt to show or set the system’s hostname. You can also use the



dnsdomainname 



command to show the system’s DNS domain name.










LX0-104 Exam Objectives (S)

Printing V

Configuring the CUPS Service


The CUPS service is configured using several text files within the
/etc/cups directory.


The


/etc/cups/cupsd.conf



file is the main configuration file you will use to configure the cupsd
daemon (calledt he scheduler). Remember that cupsd is also an HTTP server,
like Apache. Accordingly, the cupsd.conf file is very similar to the Apache
web server configuration file.




A sample cupsd .conf file is shown in Figure 16-4.



Figure 16-4 only shows a very small portion of the cupsd.conf file,
which is quite long. The cupsd.conf file is composed of many server
directives, which specify how cupsd operates. We don’t have the time
or space in this book to cover all the configuration options in
cupsd.conf. I’m just going to cover the most important ones here. For
more information, see the man page for cupsd.conf. You can also open



http://localhost:631/help/ 


in a browser on your Linux system to see an extensive list of cupsd.conf directives,
or you can visit



http://www.cups.org/documentation.php/ref-cupsd-conf.html 



Some of the more useful cupsd.conf directives include those shown in Table
16-1.




The way you configure cupsd.conf will largely depend on the particular
network you are implementing the system in. The good news is that you
don’t need to do much with cupsd.conf to configure a basic
implementation that provides local printing.



However, if you want other Linux systems to be able to print through
your CUPS printer, you must


enable BrowseAddress 


or else CUPS won’t announce its printers on the network. This directive is
not enabled by default on many distributions. Sample configurations for this
directive include the following:



BrowseAddress 255.255.255.255:631

BrowseAddress 192.168.1.255:631

BrowseAddress mydom.com:631

BrowseAddress @LOCAL




The BrowseAddress directive is usually set to a value of @LOCAL.



This causes CUPS to send printer announcement broadcasts to all local
network interfaces in the system.


You can set this directive to


@IF(interface_name) 



to limit broadcasts to a specific network interface.




After making any changes to cupds.conf, be sure to restart the cupsd
daemon. 



After configuring your cupsd.conf file, you next need to set
up a Linux user account that will be used as the CUPS administrator.


CUPS does not use the same user accounts that your Linux system uses.


Instead, CUPS is configured to use the


/etc/cups/passwd.md5 


file to store user accounts.


To create an administrative user in the passwd.md5 file named root that
is a member of the CUPS administration group named sys, you would enter



lppasswd –g sys –a root









LX0-104 Exam Objectives (Q)

MTA Management Commands: mail III

Using MTA Management Commands on Linux


Let’s first look at reading messages stored in your local MTA. When
you log in to a shell session, you will receive a notification if
there are mail messages waiting for you. You can read messages for
local users from the local MTA directly from the command line using
the mail command at the shell prompt. When you do, a list of messages
is displayed. An example is shown in Figure 16-15.



Some services running on Linux are configured to send notification
messages to the root user.



These messages are stored in your user’s mail queue, which is located
in the


/var/spool/mail/ 


directory. The mail utility reads yourmessages directly out of your user’s queue file.
Because you’rerunning the mail utility on the same system where your queue resides,
you don’t need POP3 or IMAP support configured. You can enter the mailcommands shown in
Table 16-4 at the ? prompt.



An example of viewing a received message with the t command is shown
in Figure 16-16.



To send a message, you can also enter


mail recipient_address


at the shell prompt. You can then enter a subject line and the text of
your message. Press

ctrl-d 

when you’re done to actually send the message. When you do, the message is delivered to the other user’s mail queue by your local MTA.


To view a list of unread messages in your mail queue, you can enter


mailq


at the shell prompt.



In addition to mail, many other packages are available that you can
install to read mail from the shell prompt. The key thing to remember
is that the user must run the mail command from the local shell
prompt. If the user isn’t using the local computer system, they must
ssh into the system to read mail.


You can also configure aliases for the MTA running on your Linux
system. Mail aliases redi- rect mail addressed to one user to another
user’s account. You use the

/etc/aliases 


file to configure aliases.


This file defines one alias per line. The alias you define must point
to an existing e-mail address. The syntax for this file follows:


alias: list of real e-mail addresses (separated by commas)


For example, the following two aliases must be present in this file on
most Linux distributions:


postmaster:  root

mailer-daemon:     postmaster



These aliases cause any e-mail messages sent to the postmaster to be
automatically redirected to the root user. Likewise, any e-mail
messages sent to mailer-daemon will be redirected to post- master
(which will then be redirected to root). Depending on your
distribution, you will probably find that many aliases are defined for
you by default.


Here is an example:

# General redirections for pseudo accounts in /etc/passwd.

administrator:     root

daemon:     root

lp:     root

news:     root

uucp:     root

games:     root

man:     root

at:     root

postgres:     root

mdom:     root

amanda:     root

ftp:     root

wwwrun:     root

squid:     root

msql:     root

gnats:     root

nobody:     root


# "bin" used to be in /etc/passwd

bin:         root


Of course, you can enter your own custom aliases if needed. Just open
the aliases file in a text editor and add the appropriate aliases, one
per line. When done configuring aliases, you must run the



newaliases



command at the shell prompt as root to enable them.



You can also use the



~/.forward 



file in your user’s home directory to configure forwarding. Most Linux MTAs 
check for the existence of this file in the user’s home directory to configure 
forwarding of messages.



You can open/create the file in a text editor and enter the e-mail
address to which you want to forward e-mail. If you are forwarding to
a local user, just enter the username. If you’re forwarding to a
remote user account, enter username@domain.com. If you need to forward
messages to multiple recipients, separate them with a comma.



The MTA will treat the addresses you enter in this file as an alias.
This causes all e-mail to be forwarded to the forwarding e-mail
address. Messages will not be delivered to the original user’s
mailbox.





LX0-104 Exam Objectives (P)

syslogd : Configuring Log Files I

Configuring Log Files 

syslogd 


Logging on a Linux system that uses init is usually handled by the syslogd daemon. Instead of
each daemon maintaining its own individual log file, most of your Linux services are configured
to write log entries to /dev/log by default. This device file is maintained by the syslogd daemon.
When a service writes to this socket, the input is captured by syslogd.

The syslogd daemon then uses the entries in the

/etc/syslog.conf file

shown in Figure 17-16, to determine where the information should go.



The syntax for the syslog.conf file is


facility.priority file 


A facility refers to a subsystem that provides a message. Each process on your Linux system that
uses syslog for logging is assigned to one of the following facilities:


• authpriv 
  Facility used by all services associated with system security or authorization 

• cron 
  Facility that accepts log messages from cron and at

• daemon 
  Facility that can be used by daemons that do not have their own facility

• kern 
  Facility used for all kernel log messages

• lpr 

  Facility that handles messages from the printing system

• mail 
  Facility for log messages from the mail MTA (such as postfix or sendmail)

• news 
  Facility for log messages from the news daemon 

• syslog 
  Facility for internal messages from the syslog daemon itself

• user 
  Facility for user-related log messages (such as failed login attempts)

• uucp 
  Facility for log messages from the uucp daemon

• local0–local7 

  Facilities you can use to capture log messages from your own applications 
  that you develop 




In addition to facilities, the syslogd daemon also provides priorities that you can use to customize how logging occurs on your system. Prioritization is handled by the klogd daemon on most
distributions, which runs as a client of syslogd. You can use the following priorities with syslogd:

• debug 
   All information
• info 
  Informational messages
• notice 
  Issues of concern, but not yet a problem
• warn 
  Noncritical errors
• err 
  Serious errors
• crit, alert, or emerg
  Critical errors

For example, in [Figure 17-16, p 675] the

 syslog.conf

file directs messages of all priority levels (*) from the cron facility to the 

/var/log/cron

file. If desired, you could customize your syslog.conf file to split messages of different priority levels to different files.

Your Linux distribution should also include a utility named

logrotate

 The logrotate utility is run daily, by default, by the cron daemon on your system.

You can customize how your log files are rotated using the


/etc/logrotate.conf 


file.


[Figure 17-17, p 674]



/etc/logrotate.conf 


This file contains default global parameters used by logrotate to determine how and when 
log files are rotated.


However, these defaults can be overridden for specific daemons using the configuration files located in the 


/etc/logrotate.d/ 

directory.


For example, in [Figure 17-18, p 676] the


/etc/logrotate.d/apache2


file is used to customize logging for the apache2 daemon.


In this figure, the /var/log/apache2/access_log file will be compressed. It can have a maximum
age of 365 days, after which it will be removed (maxage 365). Old versions of the file will be
archived using a date extension (dateext). The log file will go through 99 rotations before being
removed (rotate 99). If the file grows larger than 4096KB, it will be rotated (size=+4096k). The
file will not be rotated if it is empty (notifempty). No error message will be generated if the file
is missing (missingok). The file will be created with 644 permissions, will have the root user as
owner, and will be owned by the root group (create 644 root root). After a log file is rotated, the
/etc/init.d/apache2 reload command will be run (postrotate /etc/init.d/apache2 reload).



One of the cool features of the syslogd daemon is that it supports logging to a remote host.
Moving your log files from the local system to a different computer on the network can be a
very valuable administrative and security measure. For example, you could redirect all logging by
Linux systems on your network to a single log host. Then, if a user calls with a problem, you have 
instant access to their log files on the log host.



In addition, remote logging increases the security of your systems. Inexperienced intruders
tend to leave footprints all over in your log files. However, savvy intruders will try to erase their
tracks by altering the log files after accessing the system, making it very difficult to detect the
intrusion. If you redirect your logging, however, the intruder can’t cover their tracks nearly so
easily. To redirect logging, complete the following:



1.Open a terminal session and su – to root.

2.Open /etc/syslog.conf in a text editor.

3.Add the following line to the beginning of the file:

  *.* @IP_address_of_loghost 


  For example, to redirect all messages to a log server host with an IP address of
  192.168.1.10, you would enter

  *.* @192.168.1.10 

4. Save the file and exit your editor.

5. Restart the syslogd daemon.

6. To configure the log server host to receive log messages from the other systems, complete
    the following:


   a.In a text editor, open /etc/sysconfig/syslog.
   b. Locate to the SYSLOGD_PARAMS directive.
   c. Set the value of the SYSLOGD_PARAMS directive to –r 
   d. Save the changes and exit the file.
   e. Restart syslogd.



LX0-104 Exam Objectives (O)

System Time V

Configuring NTP 


In order to use NTP to configure system time with an NTP time provider, you must first install 
the ntpd daemon on your Linux system. You can use the


rpm –q ntp 


command at the shell prompt to do this, like so:



openSUSE:~ # rpm -q ntp
ntp-4.2.6p5-15.5.1.i586




1) NTP is usually installed by default on most Linux systems. If it hasn’t been, you can use the
software package management utility of your choice to install it. Once this is done, you need to
next edit the

/etc/ntp.conf 

file in a text editor. The first thing you need to do is ensure that the
following entries exist for the local clock, which is used if the time server is not available:


server 127.127.1.0 # local clock (LCL) 
fudge 127.127.1.0 stratum 10 # LCL is unsynchronized 



These directives tell the ntpd daemon to get time from the local clock in the event it can’t reach 
any of the configured NTP time providers. 



2) Next, you need to add entries to the file for network time providers you want your system to
sync time with. Here is the syntax:



server time_server_IP_address_or_DNS_name 

You can specify the IP address or DNS name of any NTP time provider you want to use.



It could be any of the following:



• An NTP time provider on your network 

• A public NTP time provider on the Internet 
You can visit http://support.ntp.org/bin/view/Servers/WebHome to view a list of publicly available
NTP time providers on the Internet. If you wish, you can use an NTP pool time server. The
pool.ntp.org domain uses DNS round robin to make a random selection from a pool of time providers who have volunteered to be in the pool. That way, no one public NTP server is overloaded with
time synchronization requests. To use this, simply add the following server directive in
addition to the local clock server directive just discussed:



server pool.ntp.org 



When you’re done, save your changes and then close the file. Before you actually start the
ntpd daemon, however, you need to do a quick, one-time synchronization with your NTP time
provider. The issue here is insane time. If your system time is already more than 17 minutes off
from the time on the NTP time provider, you must get the two systems within this time window
before NTP will work.



3) You can eliminate insane time issues by entering 


ntpdate address_of_time_provider


at the shell prompt. This will perform an initial synchronization to get time close before you start the daemon. You may actually need to run the command multiple times if the times are really far apart between your system and the NTP time provider. The ntpd daemon must be stopped 
before you run the ntpdate command!


Newer versions of NTP on newer Linux distributions also allow you to use the ntptimeset 
option with the ntpd daemon itself to accomplish the same thing. Instead of specifying start,
stop, or restart with the daemon init script, you enter (on an system that uses init)


/etc/init.d/ntp ntptimeset 


or


rcntp ntptimeset 


at the shell prompt. When you do, a quick time sync takes place
with the time provider, as in this example:



ws1:/ # rcntp ntptimeset
Time synchronized with pool.ntp.org



4) Once this is done, you can then start the ntpd daemon using its init script in the appropriate
init script directory used by your distribution. If your system uses rc scripts, you can simply enter



rcntp start 



at the shell prompt, like this:



ws1:/ # rcntp start
Time synchronized with pool.ntp.org
Starting network time protocol daemon (NTPD) done



5) You should configure the ntpd daemon to start every time the system boots using the



insserv ntp 



command. After starting the daemon, you can check the ntp log file with the tail command 
to verify that no errors occurred. 



If your distribution uses systemd, you start and stop ntpd using the systemctl command. For
example, to start the ntpd daemon, you would enter



systemctl start ntp 



at the shell prompt. You can verify that it started correctly by entering



systemctl status ntp 



at the shell prompt.



LX0-104 Exam Objectives (N)

Time Zone Settings III

Configuring the Time Zone 


During the initial installation of your Linux system, you are prompted to specify the time zone the
system is located in. On some distributions (such as Ubuntu), the time zone you specify is saved
in the


/etc/timezone 


file. You can view your system’s current time zone by displaying the contents
of this file at the shell prompt using the cat command. Here’s an example:



rtracy@ubuntu:~$ cat /etc/timezone 

America/Denver

Other distributions (such as openSUSE) save this information in the /etc/sysconfig/clock file
instead. The TIMEZONE= directive in this file configures the zone file to use, as you see here:

TIMEZONE="America/Boise"




You can also view the current time zone by entering


date 


at the shell prompt, as shown next:

openSUSE:~ # date
Wed Feb 9 11:40:05 MST 2014
openSUSE:~ #



If you need to change time zones after installation, you can use the


tzselect 


or


tzconfig 


command at the shell prompt. Debian-based distributions use the tzconfig command whereas other
distributions such as openSUSE and Fedora use the tzselect command. This command must be
run as root.



Here is an example:

openSUSE:~ # tzselect
Please identify a location so that time zone rules can be set correctly.
Please select a continent or ocean.
1) Africa
2) Americas
3) Antarctica
4) Arctic Ocean
5) Asia
6) Atlantic Ocean
7) Australia
8) Europe
9) Indian Ocean
10) Pacific Ocean
11) none - I want to specify the time zone using the Posix TZ format.


The tzselect command first displays a list of continents and oceans. Enter the appropriate 
number for the region where the time zone you want to switch to is located. When you do, a list 
of countries in the region is displayed. Enter the number for the country where the system will be located; then enter the number for the appropriate time zone.


You are prompted to confirm the time zone change, as shown in this example:



The following information has been given:
United States
Mountain Time
Therefore TZ='America/Denver' will be used.
Local time is now: Wed Feb 9 11:50:10 MST 2011.
Universal Time is now: Wed Feb 9 18:50:10 UTC 2011.
Is the above information OK?
1) Yes
2) No
#?

If the change is correct, enter 

1 

to confirm. 



Notice in the preceding example that tzselect switches time zones by setting the value of the

TZ environment variable.


You can actually change time zones from the shell prompt without tzselect by setting the value of the TZ environment variable and then exporting it. This is useful in situations where you don’t have the root password for the system or if you want to use a different time zone for your account without changing the time zone used by other users. The syntax is


export TZ=time_zone 



A list of available time zones can be found in the



/usr/share/zoneinfo/ 



directory, as shown here:



openSUSE:~ # ls /usr/share/zoneinfo/
Africa Canada Factory Iceland MST7MDT Portugal Zulu
America Chile GB Indian Mexico ROK iso3166.tab
Antarctica Cuba GB-Eire Iran Mideast Singapore posix
Arctic EET GMT Israel NZ Turkey posixrules
Asia EST GMT+0 Jamaica NZ-CHAT UCT right
Atlantic EST5EDT GMT-0 Japan Navajo US zone.tab
Australia Egypt GMT0 Kwajalein PRC UTC
Brazil Eire Greenwich Libya PST8PDT Universal
CET Etc HST MET Pacific W-SU
CST6CDT Europe Hongkong MST Poland WET
ws1:~ #



Be aware that this change is not persistent. If you reboot your system, the time zone change
will be lost. You can make the time zone change persistent for your user account by adding the
following to the

.profile 

file in your user’s home directory:


export TZ='America/Denver' 



You can also change time zones using the 

/etc/localtime 

file and the various zone files in


/usr/ share/zoneinfo 

that we looked at earlier.


To do this, create a symbolic link to the appropriate time zone file in 


/usr/share/zoneinfo 


from


/etc/localtime

For example, if you wanted to switch to the Mountain Standard Time zone in the United States, you would enter



ln –sf /usr/share/zoneinfo/MST /etc/localtime 



at the shell prompt.




LX0-104 Exam Objectives (M)

Time Zone Settings II

How Time Works on Linux 

Before managing time zones on Linux, you need to understand how time works on Linux. The
first thing you need to understand is that there are two main clocks in a Linux system:



• Hardware clock 
  This clock runs independently all the time, even when the system is
  powered off. The hardware clock is called by a variety of names, including the Real Time 
  Clock (RTC) or the BIOS/CMOS clock.

  You can use the hwclock command at the shell prompt to set the time in the hardware clock.


• System time 
  This clock runs via software inside the Linux kernel itself. It is driven by
  an ISA timer interrupt. System time is measured as the number of seconds since 00:00:00
  January 1, 1970 UTC.




The key thing to remember is that the hardware clock and the system time may not be the 
same. When managing a Linux system, we are more concerned with the system time than the
time reported by the hardware clock. The role of the hardware clock is pretty basic. Its job is to 
keep time when the system is powered off. The system time is synchronized to the hardware clock
time when the Linux operating system starts. After booting, Linux only uses system time. The
hardware clock is ignored.


When setting the time on your hardware clock, you should set it to one of the following:




• Universal Time Coordinated (UTC) 
  UTC is the standard by which the world regulates time. UTC is the current mean solar time at the
  Royal Observatory in Greenwich, London, in England. Thus, UTC is also referred to as
  Greenwich Mean Time (GMT).

  Your local time is determined by adding or subtracting one hour to or from
  UTC for each time zone you are away from UTC. For example, I live seven time zones
  away from Greenwich, so my time is UTC –7. Therefore, at 10:58 a.m. my local time,
  it’s 5:58 p.m. UTC.

  If your hardware clock is set to UTC instead of the local time, you
  need to set the

  HWCLOCK directive 

  in the

  /etc/sysconfig/clock 

  file to

  –u.

  Your Linux system will automatically calculate daylight savings time offsets according to your    local time zone.


  For Linux systems, it is actually preferred that you set your hardware
  clock to UTC instead of local time.


• Local time 
  The hardware clock in most systems you will encounter will be set to local
  time by default. If this is the case, the

  HWCLOCK directive 

  in the

  /etc/sysconfig/clock

  file will be set to

  --localtime



Setting your hardware clock to UTC is the preferred option when working with Linux systems.
Using UTC makes calculating time zone differences much easier. In fact, if you install certain
groupware applications on your Linux system, you may be required to set your hardware clock to
UTC because it makes it easier to coordinate time stamps among a large number of computers
located in different time zones.




LX0-104 Exam Objectives (M)

cron Daemon IV: Scheduling Processes

cron Daemon IV: Scheduling Processes 

Scheduling Processes 

Using anacron 

Some distributions use anacron along with cron to automate the running of tasks. The two services working pretty much the same manner. The key difference is that cron assumes that your computer system will remain up and running 24 hours a day, 7 days a week. That’s fine for some systems, such as servers anddesktops, but not for others. For example, a notebook system is very likely to be off or asleep during certain periods of the day. If a system is not powered on when a scheduled cron job should run, it is skipped.


The anacron service attempts to work around this issue. If a job is scheduled in anacron, but
the system is off, then the missed job will automatically run when the system comes back up.
Just as cron uses the /etc/crontab file,

anacron uses the


/etc/anacrontab


file. This file uses the following fields:



period delay job-identifier command


The first field specifies the recurrence period (in days). For example, you could use any one of
the following values in this field:

• 1
  The task recurs daily.

• 7
  The task recurs weekly.

• 30
  The task recurs monthly.



The second field specifies the delay (in minutes) anacron should wait before executing a
skipped job after the system starts up.



The third field contains the job identifier. This is the name that will be used for the job’s timestamp file and must be unique for each anacron job. This file is created in the

/var/spool/anacron


directory and contains a single line with a timestamp that indicates the last time the particular job
was run.


The fourth field specifies the command or script that should be run.



Consider the following example in which anacron is configured to run the /usr/bin/updatedb.sh
script once a day. If the system is down when the anacron job is supposed to run, the script will
be executed 30 minutes after the system comes back up.



openSUSE:/ # cat /etc/anacrontab
1 30 updatedbtime.log /usr/bin/updatedb.sh



Notice that this file does not specify the exact time when the job will run. This is configured
by the START_HOURS_RANGE variable in the /etc/anacrontab file. In the following example,
the start range is set to 3-22, which specifies a time range from 3 a.m.to 10 p.m.



openSUSE# cat /etc/anacrontab
...
START_HOURS_RANGE=3-22



It’s important to note that anacron also adds a random number of minutes to whatever value
you specified in the second field of the anacrontab file. The number of minutes that can be added is constrained by the RANDOM_DELAY variable within the /etc/anacrontab file. By default,this variable is set to a value of 45, which causes anacron to add a random number of minutes between 0 and 45 to the delay time in the anacrontab file. This is shown here:



openSUSE# cat /etc/anacrontab
...
RANDOM_DELAY=45






LX0-104 Exam Objectives (L)

cron Daemon III: Scheduling Processes

cron Daemon III: Scheduling Processes 


Scheduling Processes 

Using cron to Manage Scheduled System Jobs 

Using cron to run scheduled system jobs is an extremely useful tool for a Linux system administrator. You can configure your systems to perform a wide variety of tasks on a regular schedule automatically, thus saving you a ton of time and effort.


Remember when I mentioned the problems with running regular backups? Creating a system
job in cron that runs a backup on a regular schedule saves me tons of time. If I don’t have time to
visit a client site on a particular day, I don’t have to worry. I know that cron will run a backup at
the preconfigured time. All I have to do is drop by now and then to verify that everything is still
working properly and to perhaps rotate the backup media. I love cron!



To run system jobs, the cron service uses the 


/etc/crontab 

file, shown next, to configure what jobs to run:



openSUSE:/etc # cat ./crontab
SHELL=/bin/sh
PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
MAILTO=root
#
# check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly
#
-*/15 * * * * root test -x /usr/lib/cron/run-crons &&
/usr/lib/cron/run-crons >/dev/null 2>&1




As you can see in this example, the

/etc/crontab 

file contains commands that are used to run scripts found in four different directories:



• /etc/cron.hourly 
  Contains cron scripts that are run every hour 

• /etc/cron.daily 
  Contains cron scripts that are run every day

• /etc/cron.weekly 
  Contains cron scripts that are run once a week 

• /etc/cron.monthly 
  Contains cron scripts that are run once a month



All scripts found in any of these directories are automatically run by cron according to the
specified schedule. For example, the /etc/cron.daily directory contains a variety of scripts that are used to clean up your system and rotate your logs once each day. These scripts are shown here:


openSUSE:/etc/cron.daily # ls
logrotate suse-clean_catman suse.de-backup-rpmdb
mdadm suse-do_mandb suse.de-check-battery
packagekit-background.cron suse.de-backup-rc.config suse.de-cron-local



If you have a system task that needs to be run on one of these four schedules, you can simply 
create a script file and copy it into the appropriate cron directory in /etc. 
What do you do, however, if your system job needs to run on a schedule other than one of the
four used by the cron directories? No problem. The cron daemon has got you covered.



In addition to the four directories just presented, there’s a fifth directory in 

/etc/ called cron.d. 


If you need a system job to run on a custom schedule, you can create a crontab file in this
directory where it will be read and run by the cron daemon.



How do you create a crontab file? It looks difficult but it really isn’t. A crontab file is simply a text 
file that uses one line per job.

Each line has six fields, separated by tabs, as detailed in Table 13-3.



Many times, you will see an asterisk (*) in one or more fields in a given crontab file. This wildcard means “match everything.”


For example, suppose I wanted to run the tar command to back up the /home directory using
the


tar –cvf /media/usb/backup.tar /home


command every day of every month, except Sundays, at 11:05 p.m.



I could create a crontab file in /etc/crontab.d and add the following line: 


5 23 * * 1-6 /bin/tar -cvf /media/usb/backup.tar /home 

This line in the crontab file specifies that the command be run at 5 minutes after 11:00 p.m. 
(23) every day (*) of every month (*) on Monday (1) through Saturday (6). 



System cron jobs run as the root user!



[Table 13-3: The crontab File Fields, p 488]







LX0-104 Exam Objectives (L)

Where Linux User Accounts Are Stored

Where Linux User Accounts Are Stored


If your system is going to participate on a network where lots of different users will need access
to your system, you may want to consider using LDAP, NIS, or Windows Domain authentication.
For our purposes here, we’re going to focus on the Local option.

For your LPIC-1/Linux+ exam, you need to be concerned with the Local option. All Linux distributions can use the /etc/passwd and /etc/ shadow files for authentication.

This option stores user and group information in the following files in the file system:

• /etc/passwd
  This file contains the user account information for your system.
  Here’s an example:

  ksanders:x:1002:100:Kimberly Sanders:/home/ksanders:/bin/bash

  Here’s what these fields contain:
    • Username
      The Username field simply identifies the username the user will supply
      when logging in to the system. In this example, it is ksanders.
    • Password
      This is a legacy field. At one time, the user’s password was stored in
      encrypted form in this field in the passwd file. However, for security reasons, the
      password has been moved from /etc/passwd to /etc/shadow. (We’ll look at this file in
      more detail later.) Therefore, only the character x is shown in this field.
    • UID
      This is the user ID for the user account. We discussed the UID earlier in this
      chapter. In this example, the UID for the ksanders account is 1002.
    • GID
      This field references the group ID number of the user’s default group. In this
      example, the GID for the ksanders account is 100. As you’ll see later in this chapter, this
      references the users group.
    • Full_Name
      This field contains the user’s full name. In this example, it’s Kimberly
      Sanders.
    • Home_Directory
      This field contains the path to the user’s home directory. In this case,
      the home directory is /home/ksanders.
    • Default_Shell
      This field specifies the shell that will be used by default. For ksanders,
      this is /bin/bash (the Bourne-Again SHell).


• /etc/shadow
  This file contains passwords for your user accounts.
  For example, the record for ksanders is as follows:
  ksanders:$2a$05$KL1DbTBqpSEMiL.2FoI3ue4bdyR.eL6GMKs7MU6.nZl5SCC7/
  REUS:15043:0:99999:7:::
  Here’s what each of these fields contains:
    • Username
      This is the user’s login name from /etc/passwd.
    • Password
      This is the user’s password in encrypted format. In the preceding example,
      the password for ksanders is M3linux273. However, to prevent someone from accessing
      the /etc/shadow file and grabbing the user passwords from it, it is stored in encrypted
      format. You may notice that all of the system user accounts have a simple asterisk in this
      field (*). This indicates that these accounts aren’t allowed to log in to the system. For
      example, if I tried to log in to my system as ftp, I would be denied access even though the
      ftp user account exists.
    • Last_Modified
      This field displays the number of days since January 1, 1970, that the
      password was last changed. In this example, it has been 15,043 days.
    • Min_Days
      This field displays the minimum number of days required before a password
      can be changed. In this example, it is set to 0 days.
    • Max_Days
      This field displays the maximum number of days before a password must
      be changed. In this example, it is set to 99,999 days. Effectively, this means a password
      change isn’t required.
    • Days_Warn
      This field displays the number of days prior to password expiration that
      the user will be warned of the pending expiration. In this case, it’s set to 7 days.
    • Disabled_Days
      This field displays the number of days to wait after a password has
      expired to disable the account. In this example, it’s set to a null value.
    • Expire
      This field displays the number of days since January 1, 1970, after which the
      account will be disabled. In this example, it is set to a null value, indicating the account
      never expires.
• /etc/group
   This file contains your system’s groups.
  As with the /etc/passwd and the /etc/shadow files, each line in /etc/group is a single record that
  represents one group. Each record is composed of the following four fields:
  Group:Password:GID:Users




  For example, in the preceding example the record for the video group reads as follows:

  video:x:33:gdm,hsaez,jsanders

    • Group
      Specifies the name of the group. In the example, the name of the group is “video.”
    • Password
      Specifies the group password, if one is assigned.
    • GID
      Specifies the group ID (GID) number of the group. In this example, the GID of
      the video group is 33.
    • Users
      Lists the members of the group. In this case, the gdm, hsaez, and jsanders users
      are members of the video group.


LX0-104 Exam Objectives (K)