Tag: linux

  • Understanding User Crontabs

    Understanding User Crontabs

    Introduction

    Crontab stand for CRON table and it is the primary task scheduler for Linux. The CRON daemon runs every minute and checks each user’s crontab (and the system crontab) for scheduled jobs. CRON will auto start on reboot and record to syslog natively when a job runs. CRON will send “standard out” and “errors” to the scheduled user’s mail account at /var/spool/mail/user. By default, CRON uses the bash shell to execute commands.

    There are two types of crontabs; user crontabs and system crontabs. The system wide CRONTAB jobs are stored in /etc/crontab. It is used to execute scripts that apply to the system change or all users. It requires an additional field in the crontab called a user field. This article will be focused on setting up a user’s crontab.

    If your script runs successfully from the command line, but not when it is run as a CRONTAB job, it is because crontabs are executed by the user CRON. That user has limited rights and does not have the same environmental variables as a regular user. It is recommended to always use absolute paths for shell, commands, and scripts, in your crontab.

    Understanding crontab

    Key Terms:

    • Min = 0 to 59
    • Hour = 0 to 23 (Hours are in Military time)
    • Day of Month = 1 to 31
    • Month = 1 to 12 or Jan, Feb, Mar
    • Day of Week = 0 to 6 (0 is Sunday) or mon, tue, wed
    • @reboot = run once after reboot

    Pattern Matching:

    • * = match everything
    • Range = 0-4 or jan-jun
    • List = 1,3,7,16 or mon,tue,wed
    • Step Values = 0-23/2 = run the job every two hours for 24 hours.

    File Locations:

    • System file =/etc/crontab
    • System jobs = /etc/cron.d/ (Location to store system scripts)
    • System jobs = /etc/cron.daily (Location to store system scripts)
    • System jobs = /etc/cron.weekly (Location to store system scripts)
    • System jobs = /etc/cron.hourly (Location to store system scripts)
    • User’s crontab (debian) = /var/spool/cron/crontabs/<user>. (DO NOT EDIT DIRECTLY)

    Troubleshooting:

    • Crontab Logs = /var/log/syslog (logs, i.e. did command run??)
    • Crontab Job Results (debian) = /var/spool/mail/<user> (output and errors)
    • Verify cron is running = sudo systemctl status cron (Is cron running ??)

    List the current user’s crontab

    Edit current user’s crontab

    NOTE: Some documents say, after you save and install a new CRONTAB, you need to reload the CRON service by running “service cron reload”. But, other documents say you do not to perform this action.

    Remove current user’s crontab

    List another user’s crontab

    Run a job at a specified time

    NOTE: CRON uses military time, which is using hours 0 to 23.

    Potential syntax errors

    Be careful when writing cron jobs. For the day of week and day of month fields, crontab should be interpreted as AND statements. The command will run when either field matches the current time! This example would not run a script on the first Monday of the month. Rather, this job runs on the first day of the month and every Monday.

    Skip values can only operate within the time period they´re attached to. The above will not execute every 35 minutes. Rather, it will execute at 0 minutes and 35 minutes each hour.

    Start a program on server reboot

    “/usr/bin/perl -w” mean to enable and print warning messages.

    Run a script and email the results

    Send stdout&err to syslog w tag “ossec”

    Redirect screen & error output

    Screen output and errors are recorded in the user’s mailbox at /var/spool/mail/<user>. When scripts run overnight, output to the screen (stdout) is not needed. It is common to send standard out to /dev/null and errors to a custom log file. You will need to ensure that the log file does not grow out of control.

    2>&1 means to send any errors to the same location as standard out. Order matters! you can not send errors to location that does not exist. Be sure to identify the location of the screen output first.

    References

    https://krisjordan.com/blog/2013/11/04/timesaving-crontab-tips

    https://www.generateit.net/cron-job/

  • Backup Files to S3 using Bash

    Backup Files to S3 using Bash

    Description

    A bash script will be used to copy a file from a Linux server to an S3 bucket. Next, it will run a checksum on the results to verify the upload. Finally, it will output the local file size, the local etag , the aws file size, and the aws etag value for easy comparison. This should give the end user enough confidence that the uploaded file has maintained it’s integrity.

    The script assumes you have an account in AWS with a login credentials. You have the cli AWS tools and credentials downloaded to /home/user/.aws/config and /home/user/.aws/credentials. These two files are needed to successfully authenticate to the s3 bucket.

    Amazon Web Service S3 Bucket

    AWS is a flat file system. There are no folders or directories. The “full” name of a file includes all the subdirectories as well. i.e. “/file1/file2/file3.txt” is the file name and not “file3.txt”. AWS will show all subdirectories as folders in the console, for ease of human navigate.

    Begin

    Start the script by defining that it will run as bash and add any notes to the head.

    Send any log output to a custom log file and code to exit the script if any commands in a pipeline fails.

    Get the number of processing units available and add it to a variable.

    Define the remaining local variables.

    Define the AWS variables.

    When a file is uploaded to AWS, it will calculate what is called an ETAG value. This is the checksum value of the upload file. To verify file integrity, we will compare the uploaded aws calculated ETAG against the local file’s calculated ETAG.

    The ETAG will match a true md5 hash value if the file size is < 5 GB. If the file is > 5 GB, the aws ‘cp’ command will automatically break the file into 8 MB chunks and upload 4 threads of data simultaneously, until the upload is complete. Each uploaded thread will have an md5 calculated. The resulting ETAG will be a sum of all the uploaded data chunks, rather than a true md5 hash against the completed file.

    In order to compare the ETAG’s and verify they match, we must calculate the local file’s ETAG value. Then compare that value to the value calculated by AWS. The script contains two methods to calculate the ETAG value, you will need to review and consider what is needed. In my case, I always know the value I will upload will be > 5 GB.

    To calculate the local files ETAG value, for files < 5GB. use:

    For files > 5 GB, we can use the code from https://gist.github.com/rajivnarayan/1a8e5f2b6783701e0b3717dbcfd324ba.

    Next, we will copy the files to the s3 bucket using the ‘cp’ command. We will be using the CLI copy command, rather than the s3api command, as the api can not handle file’s large then 5 GB. Copy the content to S3 and tell AWS that the data is just a plain text file.

    Get the ETAG value that AWS calculated during the upload.

    Next, we will get both the local file size and the uploaded file sizes.

    Finally, display the file sizes and the ETAG values of both the uploaded file and the local file side by side for comparison.

  • Validate the Integrity of a File Backup using Ansible

    Validate the Integrity of a File Backup using Ansible

    Introduction

    Running nightly file backups is a common task for administrators. How do we know the file was copied successfully with no errors? In this post, we will set up an ansible script and it will run a file integrity check using MD5 on both the source and the destination files to verify it was not corrupted during the copy process. In this process the Ansible server is assumed to be a separate server from both the source server and the designation server.

    Specifically, we will tell Ansible to execute a bash script on the source and destination servers, gather the results and store them in a temp text file, then it will output the text file to the body of an email and send it to interested parties for review.

    Create the Ansible Script

    Add comments to the head of the script. I like to include an example of the command, so that it can be easily copied to the command line.

    Add the variables to the script. All ansible scripts start with three dashes. Also note the Ansible is very sensitive to the placement of the columns. The names, hosts, and tasks columns must be lined up exact or the script will not execute.

    Add the tasks that must be executed.

    Finally we will send an email to interested parties.

    Build the Bash Script

    In Ansible, it will execute the code on all servers simultaneously. So, we don’t know what server’s results will be returned to Ansible first. That is why we need the server hostname.

    Create the headers.

    Create the variables.

    Execute the comamnds, to gather the needed data.

    Output the results. Remember these results will be returned to Ansible.

    This is my own method for verifying files were copied correctly. I hope you find it useful.