Administration
  Home arrow Administration arrow Page 10 - Kernel, Cron, and User Administration,...
Dev Shed Forums 
Administration  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Dedicated Servers 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Download TestComplete 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
ADMINISTRATION

Kernel, Cron, and User Administration, Part 2
By: McGraw-Hill/Osborne
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 7
    2004-10-06

    Table of Contents:
  • Kernel, Cron, and User Administration, Part 2
  • Updating Your Boot Loader
  • The Kernel Source Tree and Documentation
  • The Kernel RPMs
  • GUI Kernel Source Management
  • The Linux Kernel tar File
  • Understanding Kernel Configuration Options
  • Compiling and Installing a Custom Kernel
  • The cron and at Systems
  • Setting Up cron for Users
  • Certification Summary
  • Self Test
  • Lab Questions
  • Self Test Answers
  • Lab

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
     
    ADVERTISEMENT

    Stay one step ahead of the competition. Evaluate and give feedback on some of the hottest web development tools on the market today. Make your opinion heard! Click Here

    Kernel, Cron, and User Administration, Part 2 - Setting Up cron for Users
    (Page 10 of 15 )

    Each user can use the crontab command to create and manage cron jobs for their own accounts. There are four switches associated with the crontab command:

    • -u user Allows the root user to edit the crontab of another specific user.
    • -l Lists the current entries in the crontab file.
    • -r Removes cron entries.
    • -e Edits an existing crontab entry. By default, crontab uses vi.

    If you want to set up cron entries on your own account, start with the crontab -e command. It opens the vi editor, where you can add the variables and commands of your choice, similar to what you’ve seen in /etc/crontab.


    Exercise 5-4

    Create a cron Job

    In this exercise, we will modify the basic Red Hat cron job settings to read a text file at 1:05 P.M. every Monday in the month of January. To do so, you’ll need to create a directory for yearly cron jobs. To do this, use the following steps:

    1. Log in as the root user.

    2. Create a /etc/cron.yearly directory. Add a file called taxrem, which reads a text file from your home directory. A command such as the following in the taxrem file should suffice:

      cat ~/reminder

    3. Make sure to add appropriate lines to the reminder file in your home directory.

    4. Add an appropriate command to your /etc/crontab file. Based on the conditions described, it would read as follows:

      5  13  *  1  1   root run-parts /etc/cron.yearly

    5. Save and exit.


    Running a Job with the at System

    Like cron, the at daemon supports job processing. However, you can set an at job to be run once. Jobs in the cron system must be set to run on a regular basis. The at daemon works in a way similar to the print process; jobs are spooled in the /var/spool/at directory and run at the specified time.

    You can use the at daemon to run the command or script of your choice. For the purpose of this section, assume that user michael has created a script named 7e7 in his home directory to process some airplane sales database to another file in the same directory called sales.

    From the command line, you can run the at time command to start a job to be run at a specified time. That timecan be now, in a specified number of minutes, hours, or days, or at the time of your choice. I illustrate several examples in Table 5-5.

    You can use one of the example commands shown in Table 5-5 to open an at job. It opens a different command line interface, where you can specify the command of your choice. Assume you’re about to leave work, and want to start the job in an hour. From the conditions specified above, you’d run the following commands:

    $ at now + 1 hour
    at> /home/michael/7e7 > /home/michael/sales
    at> Ctrl-D

    The CTRL-D command exits the at command shell and returns to your original command line interface. To check the status of your jobs, so you can see if it will work, run the following job queue command:

    $ atq
    1       2004-4-12   17:18  a  michael

    If there’s a problem with the job, you can remove it with the atrm command. For the output shown, you’d remove job number 1 with the following command:

    $ atrm 1

    Table 5-5  Examples of the at Command

    Time Period Example Description
    Minute at now + 10 minutes Associated jobs will start in 10 minutes.
    Hour at now + 2 hours Associated jobs will start in 2 hours.
    Days at now + 1 day Associated jobs will start in 24 hours.
    Weeks at now + 1 week Associated jobs will start in 7 days.
    n/a at teatime Associated jobs will start at 4:00 P.M.
    n/a at 3:00 6/13/04 Associated jobs will start on June 13, 2004, at 3:00 A.M.

    Securing cron and at

    You may not want everyone to be able to run a job in the middle of the night. If there is a security flaw in your system, someone may download important data or worse, and it could be days before you discover the security breach.

    As with network firewalls, you can allow or deny users the privilege of using cron. You can set up users in /etc/cron.allow and /etc/cron.deny files. If these files don’t exist, cron usage is not restricted. If users are named in /etc/cron.allow file, all other users won’t be able to use cron. If there is no /etc/cron.allow file, only users named in /etc/cron.deny can’t use cron.

    These files are formatted as one line per user; if you have the following entries in /etc/cron.deny and no /etc/cron.allow file, users elizabeth and nancy aren’t allowed to set up their own cron commands:

    elizabeth
    nancy

    You can secure access to the at system in the same way. The corresponding security configuration files are /etc/at.allow and /etc/at.deny.

    This is part one from the fifth chapter of Red Hat Certified Engineer Linux Study Guide (Exam RH302), fourth edition, by Michael Jang. (McGraw-Hill/Osborne, 2004, ISBN: 0-07-225365-7). Check it out at your favorite bookstore today. Buy this book now.

    More Administration Articles
    More By McGraw-Hill/Osborne


     

       

    ADMINISTRATION ARTICLES

    - Configuring Load-Balanced Clusters
    - Load-Balanced Clusters
    - UNIX Time Format Demystified
    - Making Changes in the CVS
    - Building Your First CVS Repository
    - CVS Quickstart Guide
    - Authorizing Users in Samba
    - Handling User Accounts in Samba
    - Authentication in Samba
    - Accounts, Authentication, and Authorization
    - Advanced Concepts on Dealing with Files and ...
    - Dealing with Files and Filesystems
    - More Hacks for the User Environment in BSD
    - Personalizing the User Environment in BSD
    - Customizing the User Environment in BSD

     
    Accelerating Trading Partner Performance
     
    Competing on Analytics
     
    Cost Effective Scaling with Virtualization and Coyote Point Systems
     
    Five Checkpoints to Implementing IP Telephony
     
    Hosted Email Security: Staying Ahead of New Threats
     




    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 1 hosted by Hostway