LPI Linux LPIC1 - Politechnika Opolskapelc.we.po.opole.pl/LinuxShortCourse/LPI Linux LPIC1 - Module 7.pdf · Determine and configure hardware settings Managing users and groups Linux

LPI Linux LPIC1

Module 7

Module Contents

• 1 Evans Ikua Lead Editor Kenya [email protected] • 2 Chris Brown Content Author UK [email protected] • 3 Mark Clarke Content Author RSA [email protected] • 4 Brian Ssennoga Content Author Uganda [email protected] • 5 Trust Zifa Material co-editor Zimbabwe [email protected] • 6 John Matogo Material co-editor Kenya john [email protected] • 7 Ken Mutua Material co-editor Kenya [email protected] • 8 Bernard Owuor Material co-editor Kenya [email protected] • 9 Sisay Adugna Material co-editor Ethiopia [email protected] • 10 Balthas Seibold Senior Project • Manager - GIZ • Germany [email protected] • 11 Petra Hagemann Project Manager - GIZ Germany [email protected] • 12 George Nyambuya Africa Coordinator - • ict@innovation • RSA [email protected] • 13 David Paulus Intern - GIZ Germany [email protected]

Module Contents

• Managing users and groups

• Scheduling jobs

• Maintain system time

• System logging

Determine and configure hardware settings

Managing users and groups

Linux is a multi-user system that relies on accounts—data structures and procedures used to identify individual users of a computer.

Linux uses groups as a means of organizing users. In many ways, groups parallel users. In particular, they’re defined in similar configuration files, have names similar to usernames, and are represented internally by numbers (as are accounts). Groups are not accounts, however. Rather, groups are a means of organizing collections of accounts, largely as a security measure.


Managing users and groups Every group has anywhere from no members to as many members as there are users on the computer. Group membership is controlled through the /etc/group fi le. This file contains a list of groups and the members belonging to each group. In addition to membership defined in /etc/group, each user has a default or primary group. The user’s primary group is set in the user’s configuration in /etc/passwd (the file that defi nes accounts). To run programs or create files with a group other than the primary one, however, the user must run the newgrp command to switch current group membership. For instance, to change to the project2 group, you might type the following: $ newgrp project2


Mapping UIDs and GIDs to Users and Groups As mentioned earlier, Linux defi nes users and groups by numbers, referred to as user Ids (UIDs) and group IDs (GIDs), respectively. Internally, Linux tracks users and groups by these numbers, not by name. For instance, the user sam may be tied to UID 523, and ellen may be UID 609. Similarly, the group project1 may be GID 512, and project2 may be GID 523. For the most part, these details take care of themselves—you use names, and Linux uses /etc/passwd or /etc/group to locate the number associated with the name. You may occasionally need to know how Linux assigns numbers when you tell it to do something, though. This is particularly true when you’re troubleshooting or if you have cause to manually edit /etc/passwd or /etc/group.


Mapping UIDs and GIDs to Users and Groups Linux distributions reserve at least the first 100 user and group IDs (0–99) for system use. The most important of these is 0, which corresponds to root (both the user and the group). Subsequent low numbers are used by accounts and groups that are associated with specific Linux utilities and functions. The fi rst normal user account is usually assigned a UID of 500 or (more often) 1000. When you create additional accounts, the system typically locates the next-highest unused number, so the second user you create is UID 1001, the third is 1002, and so on.


Managing users and groups Adding Users

Adding users can be accomplished through the useradd utility. (This program is called adduser on some distributions.) Its basic syntax is as follows: useradd [-c comment] [-d home-dir] [-e

expire-date] [-f inactive-days][-g default-

group] [-G group[,...]] [-m [-k skeleton-

dir] | -M][-p password] [-s shell] [-u UID

[-o]] [-r] [-n] username


Managing users and groups Adding Users You want to make the new user a member of the project1 and project4 groups, with default membership in project4. The user has also requested tcsh as her default shell. The following commands accomplish this goal: # useradd -m -d /home2/sally -g project4 -G project1,project4 -s /bin/tcsh sally

# passwd sally

Changing password for user sally

New UNIX password:

Retype new UNIX password:

passwd: all authentication tokens updated successfully


Managing users and groups Modifying User Accounts

User accounts may be modified in many ways: You can directly edit critical fi les such as /etc/passwd, modify user-specific configuration fi les in the account’s home directory, or use system utilities like those used to create accounts.


Managing users and groups Setting a Password Although useradd provides the -p parameter to set a password, this tool isn’t very useful when directly adding a user because it requires a pre-encrypted password. Therefore, it’s usually easiest to create an account in disabled form (by not using -p with useradd) and set the password after creating the account. You can do this with the passwd command, which has the following syntax: passwd [-k] [-l] [-u [-f]] [-d] [-S] [username]


Managing users and groups Using usermod The usermod program closely parallels useradd in its features and parameters. This utility changes an existing account instead of creating a new one, though. The major differences between useradd and usermod are as follows: • usermod allows the addition of a -m parameter when used with

-d. The -d parameter alone changes the user’s home directory, but it doesn’t move any fi les. Adding –m causes usermod to move the user’s fi les to the new location.

• usermod supports a -l parameter, which changes the user’s login name to the specifi ed value. For instance, typing usermod -l sjones sally changes the username from sally to sjones.


Managing users and groups Using usermod

• You may lock and unlock a user’s password with the -L and -U options, respectively. These options duplicate functionality provided by passwd. The usermod program changes the contents of /etc/passwd or /etc/shadow, depending on the option used. If -m is used, usermod also moves the user’s fi les, as already noted.


Managing users and groups Directly Modifying Account Configuration Files

You can directly modify user configuration fi les. The /etc/passwd and /etc/shadow fi les control most aspects of an account’s basic features. Both fi les consist of a set of lines, one line per account. Each line begins with a username and continues with a set of fields, delimited by colons (:). Many of these items may be modified with usermod or passwd. A typical /etc/passwd entry resembles the following: Name:Password: UserID:PrincipleGroup:Gecos: HomeDirectory:Shell

sally:x:1029:100:Sally Jones:/home/sally:/bin/bash


Managing users and groups Directly Modifying Account Configuration Files

Like /etc/passwd, /etc/shadow may be edited directly. An /etc/shadow line resembles the following: Name:Password:Last:Minimum:Maximum:Warn:Inac

tive:Expire

sally:$6$EmoFkLZPkHkpczVN2XRcMdyj8/ZeeT5UnTQ

:15505:0:-1:7:-1:-1:

Most of these fields correspond to options set with the chage utility, although some are set with passwd, useradd, or usermod


Managing users and groups Using chage The chage command enables you to modify account settings relating to account expiration. It’s possible to confi gure Linux accounts so that they automatically expire if either of two conditions is true:

• The password hasn’t been changed in a specifi ed period of time.

• The system date is past a predetermined time.

These settings are controlled through the chage utility, which has the following syntax:

chage [-l] [-m mindays] [-M maxdays] [-d

lastday] [-I inactivedays][-E expiredate] [-W

warndays] username


Managing users and groups Deleting Accounts On the surface, deleting user accounts is easy. You may use the userdel command to do the job of removing a user’s entries from /etc/passwd and, if the system uses shadow passwords, /etc/shadow. The userdel command takes just three parameters: • Remove User Files The -r or --remove parameter causes the system

to remove all fi les from the user’s mail spool and home directory, as well as the home directory.

• Force Deletion You can force deletion of the account while a user is logged in by using the -f or --force option in conjunction with -r. This option also forces removal of the mail spool even if it’s owned by another user and forces removal of the home directory even if another user uses the same home directory.


Managing users and groups Deleting Accounts

As an example, removing the sally account is easily accomplished with the following command:

# userdel -r sally

You may omit the -r parameter if you want to preserve the user’s fi les. Be aware of one potential complication: Users may create fi les outside their home directories.


Managing users and groups Adding Groups

Linux provides the groupadd command to add a new group. This utility is similar to useradd but has fewer options. The groupadd syntax is as follows:

groupadd [-g GID [-o]] [-r] [-f] groupname

In most cases, you’ll create groups without specifying any parameters except for the group name itself:

# groupadd project3

This command creates the project3 group, giving it whatever GID the system finds convenient—usually the highest existing GID plus 1.


Modifying group infomation Using groupmod and usermod The groupmod command modifi es an existing group’s settings. Its syntax is as follows:

groupmod [-g GID [-o]] [-n newgroupname]

oldgroupname

One of the most common group manipulations you’ll perform is not handled through groupmod; it’s done with usermod. Specifi cally, usermod enables you to add a user to a group with its -G parameter. For instance, the following command sets sally to be a member of the users, project1, and project4 groups, and it removes her from all other groups:

# usermod -G users,project1,project4 sally


Modifying group infomation Using gpasswd

The gpasswd command is the group equivalent to passwd. The gpasswd command also enables you to modify other group features and to assign group administrators—users who may perform some group-related administrative functions for their groups. The basic syntax for this command is as follows:

gpasswd [-a user] [-d user] [-R] [-r] [-A

user[,...]] [-M user[,...]] group


Modifying group infomation Using gpasswd

The options for this command modify its actions:

• Add a User The -a user option adds the specifi ed user to the specifi ed group.

• Delete a User The -d user option deletes the specifi ed user from the specifi ed group.

• Disallow newgrp Additions The -R option confi gures the group to not allow anybody to become a member through newgrp.

• Remove Password The -r option removes the password from a group.

• Add Group Administrators The root user may use the -A user[,...] parameter to specify group administrators. Group administrators may add members to and remove members from a group and change the group password.


Modifying group infomation Directly Modifying Group Configuration Files

Group information is stored primarily in the /etc/group fi le. Like account configuration fi les, the /etc/group file is organized as a set of lines, one line per group. A typical line in this fi le resembles the following:

Group:Gpassword:GID:users

project1:x:501:sally,sam,ellen,george


Tuning User and System Environments Text-mode user environments are controlled through shell configuration fi les. For bash, these fi les include /etc/profile, /etc/bash.bashrc, ~/.profile, ~/.bashrc, ~/.bash_profile, and ~/.profile. The fi les in /etc are global configuration files, which affect all users; those in users’ home directories (which are usually copied from the skeleton directory at account creation, as described earlier) affect individual users’ accounts and can be

customized by individual users.

For instance, you might set the $EDITOR environment variable to the name of your favourite text editor as:

export EDITOR=/usr/bin/mcedit


Tuning User and System Environments In addition to setting default environment variables and otherwise modifying users’ text-mode login environment by adjusting their bash configuration fi les, you can adjust the default set of fi les created by useradd. As described earlier, in “Adding Users,” useradd copies fi les from the skeleton directory (/etc/skel by default) into a newly created home directory. Typically, /etc/skel contains a handful of user configuration fi les, such as .bashrc.


Using System Log Files Most Linux systems employ a special daemon to handle log maintenance in a unified way. The traditional Linux system logger is syslogd, which is often installed from a package called sysklogd. The syslogd daemon handles messages from servers and other user-mode programs. It’s usually paired with a daemon called klogd, which is generally installed from the same sysklogd package as syslogd. The klogd daemon manages logging of kernel messages..


Using System Log Files Setting Logging Options

The format of the /etc/syslog.conf fi le is conceptually simple but provides a great deal of power. Comment lines, as in many Linux configuration fi les, are denoted by a hash mark (#). Non-comment lines take the following form:

facility.priority action

In this line, the facility is a code word for the type of program or tool that generated the message to be logged; the priority is a code word for the importance of this message; and the action is a fi le, remote computer, or other location that’s to accept the message. The facility and priority are often referred to collectively as the selector.



Valid codes for the facility are auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, security, syslog, user, uucp, and local0 through local7. Many of these names refer to specific servers or program classes. For instance, mail servers and other mail processing tools typically log using the mail facility. Most servers that aren’t covered by more-specific codes use the daemon facility.


Using System Log Files Setting Logging Options Valid codes for the priority are debug, info, notice, warning, warn, error, err, crit, alert, emerg, and panic. The warning priority is identical to warn, error is identical to err, and emerg is identical to panic. The error, warn, and panic priority names are deprecated; you should use their equivalents instead. Other than these identical pairs, these priorities represent ascending levels of importance. The debug level logs the most information; it’s intended, as the name implies, for debugging programs that are misbehaving. The emerg priority logs the most important messages, which indicate very serious problems. You can specify multiple selectors for a single action by separating the selectors with a semicolon (;). Note that commas are used to separate multiple facilities within a single selector, whereas semicolons are used to separate multiple selectors as a whole.



Some examples should help clarify these rules. First is a fairly ordinary and simple entry:

mail.* /var/log/mail

This line sends all log entries identified by the originating program as related to mail to the /var/log/mail fi le. Most of the entries in a default /etc/syslog.conf file resemble this one. Together, they typically cover all of the facilities mentioned earlier. Some messages may be handled by multiple rules.



For instance, another rule might look like this one:

*.emerg *

This line sends all emerg-level messages to the consoles of all users who are logged into the computer using text-mode tools. If this line and the earlier mail.* selector are both present, emerg-level messages related to mail will be logged to /var/log/mail and displayed on users’ consoles.



A more complex example logs kernel messages in various ways, depending on their priorities:

kern.* /var/log/kernel

kern.crit @logger.pangaea.edu

kern.crit /dev/console

kern.info;kern.!err /var/log/kernel-info


Using System Log Files Manually Logging Data

For the most part, the system logger accepts log entries from system tools, such as servers. Occasionally, though, you may want to manually create a log entry or have a script do so. The tool for this job is known as logger, and it has the following syntax:

logger [-isd] [-f file] [-p pri] [-t tag] [-

u socket] [message ...]



Options to logger permit changing its default function:

• Record logger PID The -i option records the process ID (PID) of the logger process along with other data.

• Output to Standard Error You can echo data to standard error, as well as to the log fi le, by using the -s option. An interactive script might use this feature to alert users to problems.

• Log Using Datagrams The -d option causes logger to use datagrams rather than a stream connection to the system logger socket. This is an advanced feature that you should use only if you’re instructed to do so in documentation or if you understand the networking issues involved.



• Log a File You can log the contents of a fi le by using the -f file option. Be cautious with this option; if file is big, your system log fi le can grow to ridiculous size!

• Identify a Priority The -p pri option specifi es a priority, as described earlier.

• Log Tags By default, logger includes its name in the log fi le as a tag. You can change this tag with the -t tag option. This is useful if you want to identify a script or other program that created the log entry and don’t care to record the fact that logger was involved in the process.

• Specify a Socket Ordinarily, logger calls the default system log tools to do its job. You can log directly to a network socket using the -u socket option if you prefer.


Using System Log Files Manually Logging Data • Specify a Message If you don’t specify a fi le using -f file, logger will log

whatever you type after other options as the message to be logged. If you don’t provide a message on the command line, logger accepts input you type on subsequent lines as information to be logged. You should terminate such input by pressing Ctrl+D.

As an example, suppose you want to log the message “shutting down for system maintenance” to the system log. You can do so by typing the following command:

$ logger shutting down for system maintenance

The result will be an entry like the following, probably in /var/log/messages:

Jul 29 14:09:50 nessus logger: shutting down for system maintenance


Using System Log Files Rotating Log Files

Log fi les are intended to retain information about system activities for a reasonable period of time, but system logging daemons provide no means to control the size of log fi les. Left unchecked, log fi les can therefore grow to consume all the available space on the partition on which they reside. To avoid this problem, Linux employs log fi le rotation tools.


Using System Log Files Rotating Log Files

Sample /etc/logrotate.conf file

# Rotate logs weekly

weekly

# Keep 4 weeks of old logs

rotate 4

# Create new log files after rotation

create

# Compress old log files

compress


Using System Log Files Rotating Log Files # Refer to files for individual packages

include /etc/logrotate.d

# Set miscellaneous options

notifempty

nomail

noolddir

# Rotate wtmp, which isn’t handled by a specific program

/var/log/wtmp {

monthly

create 0664 root utmp

rotate 1 }


Maintaining the System Time Linux, like other Unix-like OSs, sets its clock to Coordinated Universal Time (UTC), which for most purposes is identical to Greenwich Mean Time (GMT)—the time in Greenwich, England, unadjusted for daylight saving time. This approach means that Linux systems in New York and Los Angeles (and London and Moscow and Tokyo) should have identical times, assuming all are set correctly. For communicating with users, though, these systems need to know their time zones. For instance, when you type ls -l to see a fi le listing complete with time stamps, Linux reads the time stamp in UTC and then adds or subtracts the appropriate amount of time so that the time stamp appears in your local time.


Maintaining the System Time Manually Setting the Time

You can manually set your system’s clock—or more precisely, its clocks, because as noted earlier, Linux maintains two clocks: the hardware clock and the software clock. The main tool to set the software clock is date, which has the following syntax when setting the clock:

date [-u|--utc|--universal]

[MMDDhhmm[[CC]YY][.ss]]



Because x86 and x86-64 hardware maintains both software and hardware clocks, Linux provides tools to synchronize the two. Specifi cally, the hwclock utility enables you to set the hardware clock from the software clock, or vice versa, as well as do a few other things. Its syntax is fairly straightforward:

hwclock [options]



• Show the Hardware Clock To view the hardware clock, pass the -r or --show option. The time is displayed in local time, even if the hardware clock is set to UTC.

• Set the Hardware Clock Manually To set the hardware clock to a date you specify, you need two options: --set and --date=newdate. The newdate is in the date format that the date program accepts.

• Set the Hardware Clock Based on the Software Clock If you’ve set the software clock, you can synchronize the hardware clock to the same value with the --systohc option.



• Set the Hardware Clock Based on the Hardware Clock If your hardware clock is accurate but your software clock isn’t, you can use the --hctosys option to set the software clock to the hardware clock’s value.

• Specify UTC or Local Time You can tell Linux to treat the hardware clock as storing UTC by using the --utc option or to treat it as holding local time by using the --localtime option. The default is whichever was last used when the hardware clock was set.


Maintaining the System Time Using NTP

One of the most popular, flexible, and accurate network time tools is NTP. This protocol creates a tiered hierarchy of time sources.





The key to NTP is the fact that each server can deliver time to an expanding number of clients. For instance, if a stratum 1 server has 1,000 clients, each of which has 1,000 clients, and so on, stratum 3 will consist of 1,000,000 systems, and stratum 4 will contain 1,000,000,000 systems. Each increase in the stratum number slightly decreases the accuracy of the time signal, but not by much; even a stratum 4 system’s clock should be accurate to well under a second, which is accurate enough for almost all purposes.


Maintaining the System Time Locating time source

To locate an NTP server, you should consult one or more of several sources: • Your ISP Many Internet service providers (ISPs), including

business networks and universities, operate NTP servers for the benefit of their users.

• Your Distribution’s NTP Server Some Linux distributions operate NTP servers for their users.

• Public NTP Server Lists Lists of public NTP servers are maintained at http://support.ntp.org/bin/view/Servers/WebHome.


Maintaining the System Time Locating time source

• Public NTP Server Pool The pool.ntp.org subdomain is dedicated to servers that have volunteered to function as public NTP servers. These servers are accessed in a round-robin fashion by hostname, so you can end up using different servers each time you launch NTP.


Maintaining the System Time In order to use NTP, the ntpd daemon needs to be installed. Once NTP is installed, look for its configuration fi le, /etc/ntp.conf. This fi le contains various NTP options, but the most important are the server lines:

server clock.example.com

server ntp.pangaea.edu

server time.luna.edu

Each of these lines points to a single NTP server. When your local NTP daemon starts up, it contacts all the servers specified in /etc/ntp.conf, measures their accuracy against each other, and settles on one as its primary time source.


Maintaining the System Time You can obtain a server list by passing -p or --peers to ntpq, as in ntpq -p, without entering interactive mode. Consult ntpq’s man page for more information about its operation.

The server to which yours is synchronized is denoted by an asterisk (*), other servers with good times are indicated by plus signs (+), and most other symbols (such as x and -) denote servers that have been discarded from consideration for various reasons.


Maintaining the System Time Configuring NTP Clients

Once you’ve configured one or more NTP servers, you can configure the rest of your computers to point to them. Their configuration is done just like the NTP server configuration, with a couple of exceptions:

• You set your NTP clients to refer to the NTP server (or servers) you’ve just configured rather than to an outside NTP source. This way, your local systems won’t put an unnecessary burden on the outside NTP server you’ve selected.



You may want to ensure that your NTP clients can’t be accessed as servers. This is a security measure. You can do this with an iptables firewall rule or by using the restrict default ignore line in ntp.conf. This line tells the server to ignore all incoming NTP requests. Ideally, you should use both methods. Once you’ve confi gured a client, restart its NTP daemon. You can then use ntpq to

check its status.



In some cases, a simpler way to set the time on a client is to use ntpdate. This program is part of the NTP suite, and it performs a one-time clock setting. To use it, type the command name followed by the hostname or IP address of an NTP server:

# ntpdate clock.example.com


Running Jobs in the Future Creating System cron Jobs

The /etc/crontab fi le controls system cron jobs. This fi le normally begins with several lines that set environment variables, such as $PATH and $MAILTO (the former sets the path, and the latter is the address to which programs’ output is mailed). The fi le then contains several lines that resemble the following: 02 4 * * * root run-parts /etc/cron.daily



* * * * * command to execute

┬ ┬ ┬ ┬ ┬

│ │ │ │ │

│ │ │ │ │

│ │ │ │ └ day of week (0 – 7, 7 is Sunday)

│ │ │ └────────── month (1 - 12) #

│ │ └─────────────── day of month (1 - 31) #

│ └──────────────────── hour (0 - 23) #

└───────────────────────── min (0 - 59)



Entry Description Equivalent to

@yearly (or @annually) Run once a year at midnight in the morning of January 1

0 0 1 1 *

@monthly Run once a month at midnight in the morning of the first day of the month

0 0 1 * *

@weekly Run once a week at midnight in the morning of Sunday

0 0 * * 0

@daily Run once a day at midnight 0 0 * * *

@hourly Run once an hour at the beginning of the hour

0 * * * *


Running Jobs in the Future Creating User cron Jobs

To create a user cron job, you use the crontab utility, not to be confused with the /etc/crontab configuration file. The syntax for crontab is as follows: crontab [-u user] [-l | -e | -r] [file]

If given without the -u user parameter, crontab modifies the cron job fi le (or user crontab) associated with the current user.


Running Jobs in the Future Creating User cron Jobs

If you want to work directly on a crontab, use the -l, -r, or -e option. The -l option causes crontab to display the current crontab; -r removes the current crontab; and -e opens an editor so that you can edit the current crontab. (Vi is the default editor, but you can change this by setting the VISUAL or EDITOR environment variable.)


Running Jobs in the Future Using anacron

Although cron is a great tool for performing certain tasks, such as rotating log fi les, on systems that are up most or all of the time, it’s a much less useful tool on systems that are frequently shut down, such as notebook computers or even many desktop systems. Frequently, late-night cron jobs are never executed on such systems, which can lead to bloated log fi les, cluttered /tmp directories, and other problems. One solution to such problems is anacron.



Like cron, anacron is controlled through a confi guration fi le named after itself: /etc/anacrontab. This fi le consists of three main types of lines: comment lines (denoted by a leading hash mark, #), environment variable assignments (as in SHELL=/bin/bash), and job definition lines. This last type of line contains four fields:

period delay identifier command



Sample /etc/anacrontab file:

SHELL=/bin/bash

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:

/usr/sbin:/usr/bin

# format: period delay job-identifier command

1 5 cron.daily run-parts /etc/cron.daily

7 10 cron.weekly run-parts /etc/cron.weekly

30 15 cron.monthly run-parts /etc/cron.monthly


Running Jobs in the Future Using at

Sometimes cron and anacron are overkill. You may simply want to run a single command at a specific point in the future on a one-time basis rather than on an ongoing basis. For this task, Linux provides another command: at.



at [-V] [-q queue] [-f file] [-mldbv] TIME at -c job [job...] atq [-V] [-q queue] atrm [-V] job [job...]

Examples to be found at:

http://content.hccfl.edu/pollock/unix/atdemo.htm



• at executes commands at a specified time.

• atq lists the user's pending jobs, unless the user is the superuser; in that case, everybody's jobs are listed. The format of the output lines (one for each job) is: Job number, date, hour, job class.

• Atrm deletes jobs, identified by their job number.

Exercise

EXERCISE 7.1 – User accounts Creating User Accounts This exercise explores the process of creating user accounts. After performing this exercise, you should be familiar with the text-mode Linux account-creation tools and be able to create new accounts, including preparing new users’ home directories. To add and test a new account, follow these steps: 1. Log into the Linux system as a normal user. 2. Launch an xterm from the desktop environment’s menu system, if you used a GUI login method. 3. Acquire root privileges. You can do this by typing su in an xterm, by selecting Session New Root Console from a Konsole, or by using sudo (if it’s confi gured) to run the commands in the following steps. 4. Type useradd -m username, where username is the name you want to be associated

Exercise

EXERCISE 7.1 – User accounts – continued 5. Type passwd username. You’ll be asked to enter a password for the user and to type it a second time. Enter a random string or select a password as described in “Setting a Password.”

6. Press Ctrl+Alt+F2 to go to a fresh text-mode login screen. (If you’re already using multiple virtual terminals, you may need to use a function key number greater than F2.). Alternatively, just logout from the system.

7. Try logging in as the new user to verify that the account works properly.

8. Using the chage command set the password lifetime to 60 days and the account expiry to 10.10.2014.

Exercise

EXERCISE 7.2 – crontab Creating User cron Jobs

cron jobs can be a useful way to run programs at regular times. In this exercise, you’ll create a simple user cron job that will mail you the output of an ifconfig command on a daily basis. This exercise assumes that you’re authorized to use cron as an ordinary user. To configure your cron job, follow these steps:

1. Log into the Linux system as a normal user.

2. Launch an xterm from the desktop environment’s menu system, if you used a GUI login method.

3. Create and edit a fi le called cron job in your home directory. Use your favorite text editor for this purpose. The fi le should contain the following lines:

Exercise

EXERCISE 7.2 – crontab - continues SHELL=/bin/bash

MAILTO=yourusername

00 12 * * * /sbin/ifconfig

Be sure to type these lines exactly; a typo will cause problems. One exception: Substitute your email address on the Linux system or elsewhere for yourusername; cron uses the MAILTO environment variable to determine to whom to email the output of cron jobs.

4. Type crontab cronjob to install the cronvjob file as a cron job. Note that this command replaces any existing user crontabs that may exist. If you’ve already defi ned user crontabs for your account, you should edit your existing cronjob fi le to add the line calling ifconfig rather than create a new fi le, or type crontab -e to edit its copy from the crontab storage directory.

Exercise

EXERCISE 7.2 – crontab - continues 5. Wait for noon (00 12 in the cron time format). When this time rolls around, you should have a new email waiting for you with the contents of the ifconfig output.

Instead of waiting for noon, you can substitute a time that’s a couple of minutes in the future.

Exercise

EXERCISE 7.3 – user management 1. Thoroughly examine what chenged in the /etc/passwd, /etc/shadow

and /etc/group files after you add a user. Also, examine the /home directory so that you would know what has changed once you add a new user.

2. Add a new user to the system using useradd command. Set his shell by default to /bin/tcsh and make his initial group to be users.

3. Change the user password.

4. Again, Thoroughly examine what chenged in the /etc/passwd, /etc/shadow and /etc/group files. Also, examine the /home directory and try to identify what has changed.

5. Logout from the system and try to login as the newly added user.

Exercise

EXERCISE 7.4 – user management 1. Do the same as in Exercise 7.3, but DO NOT user useradd nor passwd

command nor usermod. Yet what is expected is that you will have another new user added to the system, being able to login and having exactly the same stuff in his home directory as the user added by the use of standard user administration related commands.

Exercise

EXERCISE 7.5 – system logs 1. Check if there is any loging daemon running in the system. If not –

install it.

2. Identify the daemon configuration file (you may need to consult the daemon man file, what is for quite sure is that the file will be somewhere in the /etc directory).

3. Edit the daemon configuration file and add at the end the following:

*.* /var/log/all

4. Restart the daemon. What happened?

5. How would you add an entry requesting the daemon to log all events that are generated by crond daemon.

Exercise

EXERCISE 7.5 – jobs 1. How would you force your system to display system time every 3

minutes.

2. How would you register (store informaiton) about currently logged in users .

3. How would you scheduele a job so that it was executed in 10 minutes couting from now?.

Exercise

EXERCISE 7.6 – more on crond 1. Thoroughly inspect the /etc/crontab file?. Does it contain anything?

Does the content indicate that some system-level jobs will be executed?

2. Add to your /etc/crontab file the following lines:

# run-parts

01 * * * * root run-parts /etc/cron.hourly

02 4 * * * root run-parts /etc/cron.daily

22 4 * * 0 root run-parts /etc/cron.weekly

42 4 1 * * root run-parts /etc/cron.monthly

Exercise

EXERCISE 7.6 – more on crond 3. Now add one more line to the /etc/crontab file that would make execte

every 5 minutes the contents (scripts) in /etc/cron.custom directory.

4. Create in the /etc/cron.custom directory script (make sure the file permissions are appropriate) file with the following contents:

#!/bin/bash

date > /dev/console

5. Wait until the scheduled time in order to see if the script was executed.

6. How you would modify the script in order to log information about its execution? Or maybe the information is already being logged in? Where would you check if it is. If it is not, how to make it log into, say /var/log/cron.custom log file?

Documents

LPI Linux LPIC1 - Politechnika Opolskapelc.we.po.opole.pl/LinuxShortCourse/LPI Linux LPIC1 - Module 7.pdf · Determine and configure hardware settings Managing users and groups Linux