CST8177 – Assignment 3

Lock/Unlock Accounts

Objectives

  1. To understand how to plan and design a system administration script;

  2. To design a Test Plan for testing the script to ensure that it operates correctly, and doesn't allow erroneous actions;

  3. To write a brief User's Guide for the completed script;

  4. To understand how to write and debug a script;

Submission

This project requires only one submission, a paper-based submission in your lab teacher's physical dropbox. The submission has to be stapled and need not be submitted in an envelope.

The submission contains:

Plagiarism

Plagiarism will not be tolerated. College plagiarism policy will be strictly enforced, although you may submit your solution as a team of two. You can even work in a larger group, but each pair or individual must prepare their own solution and submit only their own work. Luckily (for me), copied code is not difficult to identify. It's almost as though you leave fingerprints or DNA fragments on your work.

Background

Problem description

For this assignment, you will be the system administrator of a fictional company called AlgoTech, a medium-sized software development company. As such, you are in charge of the user accounts on the company-wide computer complex, which is implemented as a Fedora Linux server cluster.

Your supervisor has realized that for some business reasons, a large amount of sysadmin time is taken up with locking and later unlocking user accounts. She asks you to develop a simple script to improve the automation of lists of accounts, making use of the passwd -l and passwd -u commands.

Proposed solution

There will be a single script used as the CLI tool (note: you may choose to build the solution as several scripts or functions to minimize duplicate code, but the user will only operate with one apparent script) named lock (to lock accounts) with a hard link with the name unlock (to unlock accounts). Both entries will reside in and run from the directory /usr/local/sbin.

The command line for this script will support all of these three forms:

  1. Prompt for and read in any number of account ids from stdin (one per line) to be locked or unlocked; detect end-of-file (Control-D) in order to terminate the script. This is the no arguments case.

xxx# lock

Enter Account: user123

Enter Account: ^D

Accounts user123 locked

xxx#

  1. The filename (and optional path, absolute or relative) given is read and each user account id (one per line) is locked or unlocked. This is the exactly 2 arguments case.

xxx# lock -f accounts.text

Accounts user567 user678 locked

xxx#

where accounts.text is:

user567

user678

  1. Use any number of arguments supplied as account ids to be locked or unlocked. There is no practical limit to the number of account ids that can be supplied as long as the command line does not exceed 256 characters total. This case has at least 1 argument.

xxx# unlock user123 user234 user345 user456

Accounts user123 user234 user345 user456 unlocked

xxx#

Note these restrictions:

Sample Logic Summary

You may use this as an outline of the logical for solving this problem, or you may create your own (Steps 1 to 3 from Section A of the Method below).



Method

Section A – Analysis and Design

Use the method provided below to work through the steps for solving this problem:

  1. Write down all the things your script has to do in a point-form list;

  2. Re-arrange them as necessary to get a reasonable sequence;

  3. Add in details about tests and loops;

  4. Identify all the messages and prompts you need and where to read any answers, and determine the structure of any data files you need;

  5. Walk through your refined list and check it against the problem as given - you may have to add further details or re-arrange items;

  6. Now write the PDL in good pseudocode from the list in step 5;

  7. Walk through the pseudocode and check it for accuracy and completeness, repeating steps 6 and 7 until you're satisfied;

  8. Make a list of all the variables you will need and what data they will contain Data Dictionary), and create your data files from step 4;

Section B – Building the script

Use the method provided to write and test the script:

  1. Write your script from the PDL, a few lines at a time and not the whole script at once, and test it at every step. It is much simpler to test and correct a script a few lines at a time than it is to write a long script and debug it all at once.

    1. Use the final PDL and information from your Data Dictionary and input/output text to translate every few lines into script. You may wish to leave in your PDL statements as comments;

    2. Test your script so far (small chunks of code are easier to check than big blocks) - you may need to add script lines and echo statements to make your partial script work;

  2. Repeat steps 1a and 1b until your script is complete;

  3. Finally, test it thoroughly against the original problem statement (this is not the Test Plan).

Be sure to make frequent back-up copies while you're working.

Section C – Testing and Using Test Results

Your Test Plan is not complete after you first create it during Analysis and Design. You will come across concerns and issues while you are writing your script and get an unexpected result. Go back immediately and update your Test Plan (and your PDL, if your logic changes).

Each test consists of a test id, the actual input, the purpose of this test, and the expected result. Start with test number 1, and continue test by test until the actual output does not match your expected output. Find and correct the defective part of the script (or correct this test if it's a Test Plan error). Resume at test 1, since you can't tell if new errors have been introduced.

Continue until you have completed a successful execution of every test. Use the script typescript command to make a file of this successful run of your Test Plan for inclusion in your submission.