RHCSA Study Guide – Objective 3 : System Administration

############################
Everything below are my raw notes that I took while attending an unofficial RHCSA training session.  I am posting them here in hopes they will assist others who may be preparing to take this exam.  

My notes are my own interpretation of the lectures, and are certainly not a replacement to classroom training either through your company, or by taking the official RHCSA classes offered through Red Hat.  If you are new to the Red Hat world, I strongly suggest looking into their training courses over at Red Hat.
############################

Kickstart : The kickstart file is nothing more then a flat file answer file.

Anaconda will look for this, and use it to install/configure your server. Stuff you can set are:

- Partitioning and filesystems
- Software packages
- Users, groups, passwords
- Features, networking and more

You can build them:

a.  From scratch
b.  From an existing kickstart file (Probably most common way)
c.  Using system-config-kickstart (Tool is very basic in nature)

How does this work exactly? When you start up anaconda, it will look for a ks line within the kernel section, then fetch the path to your kickstart file.

EXAM NOTE: While this is an objective, this is not on the test as there is no way to test for this.

Network Administration

2 ways to set network ip’s:
– Static
– Dynamic

There are a few different methods of doing this.

1.  Type:  setup
2.  Edit the files directly:  vi /etc/sysconfig/network-scripts/ifcfg-ethX
3.  Using the GUI

Interesting note:
ifconfig – deprecated. Replaced with ip addr list
The ip also has ip route, ip link show, etc, etc.

EXAM NOTE: This likely won’t make a difference on the test. Just make sure your settings are persistent cause redhat will reboot your server before they grade it!

To view routes:

[root@web01 ~]# ip route show

Consider differences between:

/etc/hosts
/etc/resolv.conf
/etc/nsswitch.conf

EXAM NOTE: Shouldn’t have to worry about those 3 really. They shouldn’t be broken.

When changing your ip, hostname, etc, you need to watch with RHEL6, as its slightly different from RHEL5, and that is that RHEL6 uses network manager. So what do most people do? Remove network manager and go back to the old way using:

/etc/sysconfig/network-scripts/ifcfg-ethX
/etc/sysconfig/network

For DHCP configurations, setup the configuration as follows:

[root@web01 ~]# vim /etc/sysconfig/network-scripts/ifcfg-ethX
...
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
...

For STATIC configurations, setup the configuration as follows:

[root@web01 ~]# vim /etc/sysconfig/network-scripts/ifcfg-ethX
...
DEVICE=eth0
BOOTPROTO=none
IPADDR=x.x.x.x
NETMASK=xxx.xxx.xxx.xxx
ONBOOT=yes
GATEWAY=x.x.x.x  <--- THis required in RHEL6... no longer in /etc/sysconfig/network
DNS1=8.8.8.8 <---These 2 are also new to RHEL6
DNS2=8.8.4.4 <--- These 2 are also new to RHEL6
DOMAIN=www.blah.com
...

When configuring the network settings, its recommended to use nmcli or nm-connection editor.

In practice, its a pain for server administration. If you want, you can remove network manager and just go back and use your normal things.

[root@web01 ~]# service NetworkManager stop
[root@web01 ~]# chkconfig NetworkManager off

Network Manager is great for desktops, but when you are doing server administration, it just gets in the way.

EXAM NOTES: Your first tasks may be to reset root password and fix networking. So be comfortable with this stuff!

Cron

/etc/anacrontab defines the system cron jobs : This is a more flexible way to run cron. So anacrontab wakes up and realizes it missed a job, it'll go back and run it, when it feels like it. Basically this is useful if you are using a desktop, and your system is asleep in the middle of the night, the next morning when you wake the laptop, it'll run its stuff within reason to get things caught back up intelligently. In theory, this is bogus for servers since they run 24/7, but useful for desktops.

EXAM NOTES: If a user can't run a cron job, check for a cron.deny file. The test is known to throw this out there. So this one sounds critical.

EXAM NOTE: Read the man 5 crontab before taking test as it'll be on there.

Lab:

1.  Create a cronjob for the user root that checks the amount of available space on the system every Friday at 12:34PM

2.  Create a crontjob as a regular user that lists teh contents of /tmp at 3:54AM on Sunday, January 2.  

Answer (Plus interesting note)

man 5 crontab : note: The day of a command's execution can be specified by two fields -- day of month, and day of week.  If both fields are restricted (ie, are not *), the command will be run when either field matches the current time.  For example, `30 4 1,15 * 5'' would cause a command to be run at 4:30 am on the 1st and 15th of each month, plus every Friday.

Syslog

RHEL6 is now using rsyslog as the system logger. They did this cause rsyslog can be sent over TCP, and it also supports a cache function so if the message doesn't get out to the log, it'll cache it till it the message actually makes it to the remote device.

Log messages consists of 3 parts:

a.  Facility : Describes where it came from in the OS.  Ie. Kernel, auth, etc
b.  Level  : what is the priority of the message
c.  Messages : the actual log itself

NOTE: local0-local7 are reserved for your own use/defination.

So to use it, you basically just pipe your stuff through logger out to one of these and create a defination within /etc/rsyslog to redirect the output to a file. Another note: Redhat uses local7 for boot.log as they have a built in library which displays all the fun startup messages. IE: HTTPD OK

Config file: /etc/rsyslog.conf
Defines where all the messages should go. Not much different from /etc/syslog.conf

Interesting Note:
*.err /dev/root # If you set this, or any username, the console will get the message displayed on their screen. Def didn't know that.

When you use a .none (ie. *.none;mail.none;authpriv;none /var/log/messages, this means all will be catched except mail and authpriv since those are set to .none.

EXAM NOTE: Most of this will not be applicable to the test. The test will have everything setup to its default locations.

Logrotate

Config file: /etc/logrotate.conf
Basically RHEL6 rotates once a week, with a retention rate of 1 month total. Interesting note, they no longer appear to do 1.gz, 2.gz, etc. They apparently pop the timestamp at the end of the file.

Extended configurations are stored in /etc/logrotate.d file. Each one of these is its own logrotate configuration file. Just use this for your applications, etc.

You can force log rotation to go through by:

[root@web01 ~]# logrotate -vf /etc/logrotate.conf (or whatever file)

In the logrotate.d/blah file:

sharedscripts - Means run all the global scripts
postrotate - This is where you can run your custom thing such as:  service httpd restart

Troubleshooting

A lot of the troubleshooting objectives on the exame are permissions based, and possibly some minor SELinux, as well as locating error messages in logs.

Some useful tools that will be used on test:

- top
- df -h
- ldd : list library dependecies
- ldconfig: Update library locatation database.  Think mlocate.  It basically just reads /etc/ld.so.conf and /etc/ld.so.conf.d/* to create its indexes.

EXAM NOTE: Thankfully, the ldd/ldconfig stuff won't be on test really.

Nice level

The kernel users these priorities when figuring out what needs to run when. Ranges are from -20 to 19. Its not the actual priority, but just a minor tunable. Its not guaranteed to do anything cause its up to the process scheduler at the end of the day, but it'll at least tell it to try to give your (ie database) more priority.

So if you want to give yourself a higher priority, then give yourself a -20. Regular users cannot set their stuff to be a higher priority. Only root can do that. Regular users can however give themselves a lower priority of like 20.. therefore, their application will not impact others as hard.

EXAM NOTE: Probably won't be on test.

Lab

1.  Take a few minutes to browse through the various logs in /var/log.  Familiarize yourself with the kinds of info available.

2.  Browse the man page for rsyslog.conf

3.  Find where the audit service keeps its log and add a corresponding new entry to your logrotate configuration.  Force a rotation to see everything work.

Answer:  it logs to /var/log/audit/*.  So create a new config:  cp cups.conf to audit.conf
Modify the log entry.  Rerun: logrotate -vf /etc/logrotate.conf

4.  Remove the audit logrotate configuration and restart the auditd service

5.  Locate the PIDS of the highest memory and highest CPU utilization processes.  Play with their nice levels.