% CST8207 Assignment 12 – CentOS: User and Group management % Ian! D. Allen – – [www.idallen.com] % Winter 2015 - January to Apil 2015 - Updated Sat Apr 4 03:32:18 EDT 2015 Due Date and Deliverables ========================= > **Do not print this assignment on paper!** > > - On paper, you will miss updates, corrections, and hints added to the > online version. > - On paper, you cannot follow any of the [hyperlink URLs] that lead you > to hints and course notes relevant to answering a question. > - On paper, scrolling text boxes will be cut off and not print properly. - **Due Date**: `15h00 (3pm) Tuesday April 7, 2015 (Week 13)` - You must have a working CentOS installed to do this assignment - Late assignments or wrong file names may not be marked. Please be accurate and punctual. - College policy does not allow assignments to be due after classes end. - **Available online** - Version 1 – 05:50 March 29, 2015 - **Prerequisites** - All [Class Notes] since the beginning of term. - All your previous [Assignments] and [Worksheets]. - Completed [CentOS Install and Configure] virtual machine installation (done in a previous assignment). - An ability to **READ ALL THE WORDS** to work effectively. - **Deliverables** 1. Modifications to your [CentOS Install and Configure] as given in this assignment. - **Do not delete any assignment work from your CentOS VM until after the term is over!** 2. One plain text file uploaded to Blackboard according to the steps in the [Checking Program] section below. 3. Directory structure and files created and left for marking on the [Course Linux Server] (**CLS**).\ **Do not delete any assignment work from the CLS until after the term is over!** **WARNING:** Some inattentive students upload Assignment #12 into the Assignment #11 upload area. Don’t make that mistake! Be exact. Purpose of this Assignment ========================== > **Do not print this assignment on paper!** On paper, you cannot follow any > of the hyperlink URLs that lead you to hints and course notes relevant to > answering a question. This assignment is based on your weekly [Class Notes]. 1. Review account administration commands from the [Class Notes]. 2. Practice managing [Users and Groups] in your own virtual machine. Remember to **READ ALL THE WORDS** to work effectively and not waste time. Introduction and Overview ========================= This is an overview of how you are expected to complete this assignment. Read all the words before you start working. For full marks, follow these directions exactly. 1. Complete the readings in your weekly [Class Notes]. 2. Complete the **Tasks** listed below, in order. 3. Verify your own work before running the **Checking Program**. 4. Run the **Checking Program** to help you find errors. 5. Submit the output of the **Checking Program** to Blackboard before the due date. 6. **READ ALL THE WORDS** to work effectively and not waste time. Save your work -------------- You will create some minimal file system structure in your HOME directory on the CLS. Most work will involve changes in your own Linux Virtual Machine running Centos 6.6. You can use the [Checking Program] to check your work as you go. You can check your work with the [Checking Program] as often as you like before you submit your final mark. When you are finished, leave the files and directories in place on both the CLS and your own CentOS Virtual Machine as part of your deliverables. **Do not delete any assignment work until after the term is over!** Assignments may be re-marked at any time on the CLS; you must have your term work available on the CLS right until term end. Searching the course notes on the CLS ------------------------------------- All course notes are available on the Internet and also on the CLS. You can learn about how to read and search these CLS files using the command line on the CLS under the heading *Copies of the CST8207 course notes* near the bottom of the page [Course Linux Server]. Commands, topics, and features covered -------------------------------------- This is a Users and Groups assignment. Review course notes [Users and Groups]. See the course notes or use the on-line help (`man` command) for the commands listed below for more information: - `chown` – (change owner) Change the owner and/or group of an existing inode (needs `root` privilege) - `gpasswd` – administer groups: set group administrator users, set group members, add and remove users from a group, change or remove the group password - `groupadd` – add a new group to the `/etc/group` file - `groupdel` – remove a group from the `/etc/group` file - `groupmod` – modify group name, number, password account information in the `/etc/group` file - `groups` – list the groups you (or another account) are in (from `/etc/group`) - `id [user]` – display current account, current groups, and SELinux security context information - `passwd` – change your own password, or another user’s password (as `root`) - `su [-] [user]` – (substitute user) Become another user (default `root`), with that user’s permissions - `useradd` – add a new user account and home directory - `userdel` – delete an account (and possibly the home directory as well) - `usermod` – modify account information (and possibly home directory as well) - `whoami` – (who am I?) Display current account userid Correct user, command lines, and command output ----------------------------------------------- - Parts of this lab are done as different non-root users. Other parts are done as the `root` user. Pay attention to which part is done by which user. You must use the `su` command to start a shell with the permissions of another user. The `root` user can use `su` to become any other user without requiring a password. - If you start a `root` subshell, your prompt will tell you if you are the `root` user by changing to include a `#` character instead of a `$` character. You can also use the commands `id` or `whoami` to show your current userid. - Some answers require you to record **command lines**. Do **not** include the shell **prompt** with your command lines. Give only the part of the command line that you would type yourself. - Make sure you know the difference between a command **line** (which is what you type into the shell) and command **output** (which is what the command displays on your screen). Pay attention to whether the question asks you to record the command **line** or the command **output**. Backup and Recovery on CentOS ----------------------------- 1. Take a snapshot of your virtual machine before you begin each section of this lab so that you can recover back to the snapshot if needed. - You can delete the unused snapshots if everything works well. - CentOS snapshots are very small and fast compared to your Windows snapshots; you can save lots of them. 2. You may find it useful to also make a backup copy in a safe place of the `/etc/passwd` file and its **shadow** and the `/etc/group` file and its **shadow** on your CentOS system. - You can compare the old and new files using `diff` to know what has changed during this lab, and you can sometimes recover these files without reverting everything back to a snapshot. Use a remote login, not the VMware console ------------------------------------------ I recommend that once you have booted your CentOS VM, you connect to it and work using a remote login session (e.g. `ssh` or `PuTTY`) where copy-and-paste works and where you can have multiple simultaneous connections into the VM. The VMware console is not friendly. Note that SSH sessions (and whatever you are doing inside them) do not survive across a VMware suspend. Make sure you save your editor files and exit your SSH session before you pause or suspend your virtual machine. (Editor sessions that run inside the VMware console do survive across suspend and resume, since they don’t depend on a network connection.) > Interested users may look into the various Linux virtual terminal programs > such as `tmux` and `screen` that do allow you to suspend and resume your > sessions even from a remote login. CentOS No `root` files in non-root accounts ------------------------------------------- Files saved anywhere under your sysadmin HOME directory in CentOS should be owned by you and in one of your groups, not owned by `root` or in the `root` group. (The presence of `root` files in non-root accounts is often a sign that your machine has been cracked!) Do not leave root-owner or root-group files in your account. You should change the owner and group to you of anything you create as `root` in your account. To find files not owned by you or not in your own group in your account: [abcd0001@abcd0001 ~]$ cd ; pwd ; echo "$USER" ; find . ! -user "$USER" -ls /home/abcd0001 # your HOME directory not abcd0001 abcd0001 # your own userid not abcd0001 [... any non-abcd0001 owner files are listed here ...] [abcd0001@abcd0001 ~]$ cd ; pwd ; echo "$USER" ; find . ! -group "$USER" -ls /home/abcd0001 # your HOME directory not abcd0001 abcd0001 # your own userid not abcd0001 [... any non-abcd0001 group files are listed here ...] **Note** that the above commands were run when logged in as **your sysadmin account**, not when logged in as `root` – make sure the `$USER` variable contains your own userid not the `root` userid. You want to find files not owned by or in the group of your *own* userid. If you find any files that are not owned by or in the group of your own sysadmin userid, you should change the owner and group of these files to be your own userid and group. (The command that does this has a *recursive* option that lets you change everything under a directory.) **Hints:** You need to know which account has permissions to change the ownership and group of a file. You need to know how to make the change. See the examples in [Users and Groups]. > Advanced users can modify the above `find` to send pathnames into `sudo` > running `xargs` with `chown`. See [Find and Xargs]. Tasks ===== - Do the following tasks in order, from top to bottom. - **READ ALL THE WORDS!** and do not skip steps. - Pay attention as to which tasks must be done in your own CentOS VM and which must be done in your account on the [Course Linux Server]. **Put the prompt escape for your current machine name into your SHELL prompt so you know which machine you are working on!** - Tasks done on your own Centos VM require you to run a marking program in that Virtual machine. That marking program will transfer marking data from the VM to the CLS for marking. - Your instructor will mark on the due date the work transferred to account on the CLS. Leave all your work on the CLS and do not modify it. - **Do not delete any assignment work from the CLS until after the course is over.** CentOS Snapshot --------------- 1. Complete your [CentOS Install and Configure]. 2. Before you begin this assignment, create a snapshot of your CentOS Virtual Machine. - Enter a comment explaining where and when you took this snapshot. - You can restore back to this snapshot if anything goes wrong. Set Up – On The CLS ------------------- 1. Do a [Remote Login] to the [Course Linux Server] (**CLS**) from any existing computer, using the host name appropriate for whether you are on-campus or off-campus. 2. Make the CLS directory `~/CST8207-15W/Assignments/assignment12` CentOS Set Up – The Base Directory on CentOS -------------------------------------------- 1. In your own sysadmin account in your CentOS Virtual Machine, also make the CentOS directory `~/CST8207-15W/Assignments/assignment12` (the same hierarchy as you have already made on the CLS). **This CentOS `assignment12` directory in your sysadmin account is the [Base Directory] for all pathnames in this assignment. Store your CentOS files and answers below in this sysadmin [Base Directory].** Run the **Fetch** and [Checking Program] to verify your work so far. > Pay careful attention to whether you are working on the CLS or CentOS, and > which account you are using! Watch the userid and hostname values in your > `PS1` prompt string! All answer files in this assignment get stored in the > CentOS **Base Directory**, not on the CLS. CentOS `adduser` and `useradd` are the same ------------------------------------------- > Do the commands in this section using your own sysadmin non-root account. > Use `sudo` only as needed. As mentioned above, all output files must be > owned by you and saved on CentOS in the [Base Directory] for this > assignment in your system admin account (not in the `root` account!). On CentOS, `useradd` and `adduser` are the same command with two different names. On some versions of Linux – Debian, Ubuntu, etc. – `adduser` is a different command with different options. 1. On CentOS, try `man adduser` and then `man useradd` and see that they are exactly the same thing. (If the `man` command is not found, you missed a step in a previous assignment. Go back and install the missing package.) 2. On the CLS (not CentOS), try the same two `man` command lines and see that the two commands `useradd` and `adduser` are different and have different `man` pages on the CLS. (The CLS runs Ubuntu Linux, which is a Debian-based distribution. CentOS is a Red Hat distribution.) 3. On CentOS, find the absolute pathnames of the two command names `adduser` and `useradd`. (Note: The `which` command won’t find the location of these two commands when run as a non-root user. Use the other command that locates the pathname and manual pages of a command name. Review the “related commands” in the [Search Path] notes.) You will need these two absolute pathnames for the next question. ### `adduser.txt` {#adduser.txt .floatright .unnumbered} 4. On CentOS, save into output file `adduser.txt` in your CentOS [Base Directory] the two lines of output from a long `ls` listing of the two above absolute pathnames. Your file will be two lines and 20 words. Look at the `ls` output lines in `adduser.txt`: - Note why `useradd` and `adduser` are the same command on CentOS. - Note why the `which` command did not work to find the absolute pathnames of either of these commands when run as a non-root user. (**Hint:** `which` only finds executable programs. Who has permissions to execute the `useradd` command?) Run the **Fetch** and [Checking Program] to verify your work so far. CentOS The Simpsons Follies: `homer` and `flanders` --------------------------------------------------- Review the course notes on [Users and Groups]. > Reminder: You will need `root` privileges to run account management > commands, but all other commands should be done using your unpriviileged > sysadmin account. > > Always log in and use your sysadmin account and use `sudo` only when > needed. As mentioned above, all output files must be owned by you and saved > on CentOS in the usual place for this assignment in your account (not in > the `root` account!). For this section you will require two more ordinary user (non-root, non-system) accounts. We will use two names from **The Simpsons** television series. ### `homer` {#homer .floatright .unnumbered} 1. Create an account named `homer` (no options needed) and then give it a simple password. ### `flanders` {#flanders .floatright .unnumbered} 2. Create an account named `flanders` (no options needed) and then give it the same password. ### `simpsons.txt` {#simpsons.txt .floatright .unnumbered} 3. Use some `id` commands to record the account information for each of the two Simpsons accounts into a `simpsons.txt` file. Your file will be two lines, six words, 105 characters; one line for each of the two new Simpsons accounts. ### `simpasswd.txt` {#simpasswd.txt .floatright .unnumbered} 4. Extract the account information lines for the two new accounts from the system password file and save the information in a `simpasswd.txt` file. Your file will be two lines, two words, 84 characters; one line for each Simpsons account. Each password file line will have seven colon-separated fields in it. ### `simpath.txt` {#simpath.txt .floatright .unnumbered} 5. Put the long `ls` listing of the absolute pathname of each Simpsons account HOME directory (not the contents of the directory – just the directory itself) into a `simpath.txt` file, one per line. Your file will be two lines and 18 words. If you get **permission denied**, you aren’t using the correct option to `ls` to show only the directory, not the contents. ### `simperm.txt` {#simperm.txt .floatright .unnumbered} 6. Put the three-digit **numeric** permissions of either of the above HOME directories in a `simperm.txt` file. Your file will be one line, one word, four characters. (Remember why three digits in a file is saved as four characters? Review *Text file line end differences* in [File Transfer].) Run the **Fetch** and [Checking Program] to verify your work so far. ### Creating a World-Writable Public Directory ### `simpub.txt` {#simpub.txt .floatright .unnumbered} **The SB Output File**: In the next steps, where you are required to save a command line or its output, **do** the command and then copy and **record** the command line or its output as a separate line into an output file named `simpub.txt` in your CentOS [Base Directory] that will be noted as *the SB output file* below. If you can’t answer a question, leave a blank line in this output file. (The `vim` option `:set number` may be useful to you as you edit.) > If you use redirection to append lines to the output file, instead of using > an editor, make sure you back up the file before each try, in case you > accidentally over-write the file and lose the previous answers. You could > also create snapshots after each question. Below, we will create a `/public` directory in the system ROOT directory in which *any user* can create files. The directory will allow any user to create names in it (or remove names, or rename). Recall that the permissions on a directory are not the same as the permissions on the things named in the directory. Permission to change file names does not grant permission to change file content. You will need to use a command that lets you start a subshell as another user. Review [Users and Groups]. > In this section you will need to run commands as different users. You may > find it helpful to have separate windows open into your CentOS VM, with > subshells in each window running as a different user. Then, you can simply > change windows to change users instead of having to exit and enter > subshells in the same window. Be lazy! (You could also use the `suspend` > command and `fg` to change sub-shells.) ### `/public` {#public .floatright .unnumbered} 1. Use appropriate privileges to create a directory called `/public` under the top-level ROOT directory. The exact name is `/public` (*NOT* `/root/public` and *NOT* `./public` and *NOT* `public`!). 2. Now, give the `/public` directory *full access permissions* for *everybody*. 3. You should be able to `touch` and remove a file in this new `/public` directory as any non-root account. Test this (not as `root`). 4. Start up a subshell that runs as the `flanders` user. - Optionally use a new window for this, so you have two windows. - Use the command that displays who you are to make sure it says `flanders`! ### `flanfile` {#flanfile .floatright .unnumbered} 5. As the `flanders` user, redirect the current date into a new `flanfile` file in the above `/public` directory. The file will be one line, 6 words, 29 characters. - If this fails, you didn’t set the correct directory access permissions on the directory, above. 6. As your sysadmin user, record just the **owner** and **group** of the `flanfile` file as Line 1 in the SB output file in your CentOS [Base Directory] (two words only). - See why having two windows is useful here? You could be executing commands as one userid in one window and recording the results using your sysadmin account in the other window. 7. Record the current **numeric** permissions of the `flanfile` file as Line 2 in the SB output file (three digits only). ### Removing (only) other permissions from a file 8. Remove only all **other** permissions from `flanfile` and use the syntax that *does not change any other permissions*, no matter what they might be. - Record the exact *command line* used as Line 3 in the SB output file. - **Hint:** You can’t use numeric permissions, since numeric permissions set *all* permissions, not just **other** permissions. Review [Permissions] especially [Changing Permissions]. 9. Record the new resulting **numeric** permissions for the `flanfile` file as Line 4 in the SB output file (three digits only). ### Renaming and deleting other users’ files 10. Start a subshell that runs as the `homer` user. - Optionally use a new window for this, so you have three windows. - Use the command that displays who you are to make sure it says `homer`! 11. As the `homer` user, try to display the contents of the `flanfile`. - You should get a “Permission denied” error message; `homer` does not have permission to read the file content. - If you didn’t get an error message, you didn’t correctly remove *other* permissions from the file. - If you get an error “No such file”, you typed the wrong pathname. ### `homfile` {#homfile .floatright .unnumbered} 12. As the `homer` user, rename the `flanfile` file (still owned by `flanders`) to have the new name `homfile` (in the same directory as `flanfile`). - No error message should print. 13. Do a long `ls` listing of that new name confirming that the renamed file is still owned by `flanders`. - Record the long `ls` output as Line 5 in the SB output file. 14. As the `homer` user, remove the `homfile` name. - This name is the name of a file still owned by `flanders`. - You will need to answer “yes” to a question about write-protection. - The file had only one name; removing this one name means the data in the file (data owned by `flanders`) is now gone forever. - Verify that the `/public` directory is now completely empty. Understand clearly why `homer` can **rename** and then **delete** a file that he doesn’t own and can’t read. Review [Links and Inodes]. Run the **Fetch** and [Checking Program] to verify your work so far. ### One file multiple write permissions > In this section you will need to run commands as different users. You may > find it helpful to have separate windows open into your CentOS VM, with > subshells in each window running as a different user. Then, you can simply > change windows to change users instead of having to exit and enter > subshells in the same window. Be lazy! (You could also use the `suspend` > command and `fg` to change sub-shells.) ### `homflan` {#homflan .floatright .unnumbered} 1. Create a new empty file `homflan` in the `/public` directory that has the **owner** and **group** of `homer` and `homer`. - **Hint:** You could log in as `homer` to create this file, or you could create the empty file as any user first, then use super-user privilege to change the owner and group. - Do a long `ls` listing of the file and verify that both the owner and group are `homer`. 2. As the `flanders` user try (and fail) to append the `date` to the `/public/homflan` file. You should get `Permission denied`. 3. As the `homer` user try (and succeed) to append the `date` to the `/public/homflan` file. There should be no error message. 4. Change only the file **group** and group **permissions** of the `homflan` file so that *both* `homer` *and* `flanders` can read and write the `homflan` file. **Hint:** `homer`, the owner of the file, will read and write the file using the **owner** permissions. Arrange that the file will be in one of the **groups** of the non-owner `flanders` and so **group** permissions will apply to `flanders`, allowing `flanders` to read and write the file using the group permissions. Other users will be neither the owner of the file nor in the group of the file, so **other** permissions will apply to them and they cannot write the file. - Do not change anything in the system except the group and the group permissions of the file! - Do not enable **other** write permissions! - Do not create any groups or do anything other than change the file group and group permissions. 5. Test it as *three* users. Both `homer` and `flanders` should be able to append data to the file, while your sysadmin (non-root) account should *not* be able to append data. 6. Exit from all the Simpsons user subshells and return to your sysadmin account shell. Run the **Fetch** and [Checking Program] to verify your work so far. CentOS Star Wars account management ----------------------------------- ### `starwars.txt` {#starwars.txt .floatright .unnumbered} **The WA Output File**: In the next steps, where you are required to save a command line or its output, **do** the command and then copy and **record** the command line or its output as a separate line into an output file name `starwars.txt` in your CentOS [Base Directory] that will be noted as *the WA output file* below. If you can’t answer a question, leave a blank line in this output file. (The `vim` option `:set number` may be useful to you as you edit.) Take a snapshot of your virtual machine. Review [Users and Groups]. ### `luke` {#luke .floatright .unnumbered} 1. Create an account named `luke` (all lower-case; no options needed). 2. Give the new `luke` account a simple password. ### `luke.txt` {#luke.txt .floatright .unnumbered} 3. Use a single command to search for lines containing `luke` in the four system accounting files (in the password and password shadow files and in the group and group shadow files – four files in total). When you see four lines of output, put them into a new `luke.txt` file. That file should contain the four lines that contain `luke` in each line. Each line will be preceded by the name of the file in which it was found. 4. As your sysadmin account user (not `root`), run a long `ls` listing on the new HOME directory (just the directory, not the contents) of the new `luke` account. Only one line should output. - If you get **permission denied**, you aren’t using the correct option to `ls` to show only the directory, not the contents. - You should see one line of detail information about the directory itself (permissions, owner, etc.). Save the one line as Line 1 in the WA output file in your CentOS [Base Directory]. ### Modifying a user account with `usermod` The `usermod` command modifies user account attributes, as recorded in the **password** file. Use **only** this command to make the following account change. > Do **not** use any other commands to make these changes unless told to do > so. Do not text-edit any account files; use the commands designed for the > purpose. ### `darth` {#darth .floatright .unnumbered} 1. Use a command to modify the **login** name of the `luke` account to be `darth` - Record the exact command line used as Line 2 in the WA output file. - Confirm the change by looking in the system password file: The `luke` user should be renamed to `darth`. - Run `id luke` and confirm that it **fails** with “No such user” 2. Run `id darth` and confirm that `darth` exists, but the account is still in the group named `luke`. - Save the output as Line 3 in the WA output file. 3. Run `ls -ld` on the HOME directory for this account (which hasn’t changed) and note that the owner has changed, but not the group (it’s still `luke`). The name of the directory hasn’t changed, only the owner name. If you didn’t get the above results, restore the snapshot and try again. ### Modifying a group with `groupmod` The `groupmod` command modifies the group attributes, as recorded in the **group** file. Use **only** this command to make the following account change. > Do **not** use any other commands to make these changes unless told to do > so. Do not text-edit any account files; use the commands designed for the > purpose. ### `darth` {#darth-1 .floatright .unnumbered} 1. Use a command to modify the **group** name of the `luke` group to be `darth` - Record the exact command line used as Line 4 in the WA output file. - Confirm the change by looking in the system group file: The `luke` group should be renamed to `darth`. - Run `id darth` and confirm that the account is now in the group named `darth`. - Run `ls -ld` on the HOME directory for this account (which still hasn’t changed) and note that both the owner and group have been changed (but not the name of the directory). If you didn’t get the above results, restore the snapshot and try again. ### Moving a HOME directory with `usermod` ### `sith` {#sith .floatright .unnumbered} 1. The new `darth` account still uses an unchanged home directory of`/home/luke`. Use a command to change and move (in one command line) this old home directory from its current `luke` name to the new name `sith` in the same parent directory as `luke`: - Record the exact command line used as Line 5 in the WA output file. **Hints:** - Use both options `-d` and `-m` strictly according to the course notes (or read the man page). - Do not insert anything between `-d` and its following argument. - Use the correct absolute path for the new HOME directory. 2. Check your work: - Run `ls -ld` on the new changed and moved `sith` HOME directory for this account and confirm that both the owner and group are still `darth`. - Use a command to search in the four system accounting files and make sure the word `luke` does not appear anywhere in those four files. - Start a login subshell in the `darth` account using `su` with the correct option. There should be no errors and the current directory should be the `sith` HOME directory. - Exit the `darth` subshell and return to your sysadmin account shell. If you didn’t get the above results, restore the snapshot and try again. Run the **Fetch** and [Checking Program] to verify your work so far. ### Changing shells with `chsh` 1. Use the appropriate option to the `chsh` command to print the list of possible shells (four lines). 2. Change the shell for `darth` to be the one that prevents logins. (Choose the shell pathname that allows “**no logins**”.) 3. Try to start a subshell in the `darth` account using `su`. You will be rejected with `This account is currently not available.` Run the **Fetch** and [Checking Program] to verify your work so far. CentOS Group management: The Megadeth Project --------------------------------------------- - This section uses some commands you have not used before. - Every command you need to use is mentioned in the opening page of this assignment document and is described in the lecture notes on [Users and Groups]. Become familiar with this list of commands before you continue, so that you know what command name to choose below. Every command also has a man page. - You do not need to text-edit any files in this section. All the commands you need are noted at the top of this document (and again in the [Users and Groups] course notes). **RTFM**! ### Requirements for Megadeth Group Management The four-person band [**Megadeth**] (note the unusual spelling of **Megadeth**) uses the following work approach and has the following **Requirements**: A. [Song files] can be created by one band member who is the single **group administrator** account. Only this one **group administrator** account can create, delete, modify and write song files. B. Files must only be readable (not writable or removable) by the other three non-administrator group (band) members. These three ordinary band members must only be able to read the song files, not change or remove or rename them. C. Anybody who is not a **band member** is not allowed to view song files. You must prevent all public access of any kind to the song files. These people do not share their songs for free. - Follow the directions below to create accounts and directories that implement the above **Requirements**. Some of the work will need to be done as the `root` super-user. (Only the `root` user can create new accounts.) Most group maintenance work can be done as the band member who is assigned to be the **group administrator**. - The four **Megadeth** band members are (get the name and account spellings correct when you create these accounts, below! Case matters): - **Dave Mustaine** – login name: `mustaid` - **David Ellefson** – login name: `ellefsd` - **Chris Broderick** – login name: `broderc` - **Shawn Drover** – login name: `drovers` ### Creating and configuring the Megadeth Working Group 1. Take a VM **snapshot** before you begin this section, so you can return here if you make many mistakes. Keep a separate record of the exact commands you use in this section, for study purposes. ### `mustaid`, `ellefsd`, `broderc`, `drovers` {#mustaid-ellefsd-broderc-drovers .floatright .unnumbered} 2. Create the four new band accounts. The only option you need is the correct option to include each band member’s **full name** in each account you create. That is all. - Remember to **quote** shell arguments containing blanks. - Don’t worry about any special groups yet. - If you forget to include the full names when you create the accounts, you can modify the information afterword with the correct command. 3. Give all four accounts some simple passwords. ### `megadeth` {#megadeth .floatright .unnumbered} 4. Use a command to add a new **group** named `megadeth` (spelled all lower case) to the system accounting files. - Do *not* make this `megadeth` group a *system group*. Keep it ordinary. - Verify that the new `megadeth` group is now in the system group file and has a numeric GID larger than `GID_MIN`. (Recall looking up this value when you created your own sysadmin account.) - If not, delete it and try again. 5. Use a command to set band member **Chris Broderick** as the only **group administrator** of the new `megadeth` group. - Verify that the `megadeth` group in the group shadow file lists Chris’ account userid in the third field. - If not, delete it and try again. 6. Log in (start a subshell) as the `megadeth` *group administrator*. Using his account, use a command four times to **add** each of the **four** band members to the `megadeth` group, one-by-one. - The *group administrator* can add members to the group. - The *group administrator* can only add users one-at-a-time. - The message `Adding user` will print each time. 7. Confirm that the system **group** file contains the new `megadeth` group with all **four** band members listed beside it. 8. Exit the Chris subshell when you are done adding four members. ### `music` {#music .floatright .unnumbered} 9. Create a new song directory named `music` (lower-case) in the same parent directory where all the user HOME directories are stored. (Your sysadmin HOME directory is in this directory.) 10. The band wants to store its song files under this `music` directory, with permissions that implement the **Requirements** given above. Set ownership and permissions for the `music` directory to implement the given **Requirements**: a. Which band account should be set as the **owner** of directory `music`? - Make it so. b. Which group should be set as the **group** of directory `music`? - Make it so. c. Which **permissions** should be set on directory `music`? - Make it so, so that the **Requirements** are met. ### Test Plan for the Megadeth Group Project You need to **verify** that the requirements have been **met** using a **Test Plan**. Here it is: ### `test` {#test .floatright .unnumbered} 11. Become the **group administrator** and do these read/write tests: - Redirect the current `date` into a new file named `test` in the `music` directory. It should be possible without any errors. - Display the file on your screen to make sure the file has content you can read and write while you are logged in as the group administrator. - Exit the group administrator account when you are done testing. 12. Become a non-group-administrator band member and do these read-only tests:. - Make sure the member can read the `test` file, but can not change it, rename it, or remove it. 13. Become any other ordinary user (e.g. your own sysadmin account) and test for no access: - Make sure that the `music` directory cannot be listed or entered by any user who is not a band member. ### Finishing touch – four symbolic links ### `music` {#music-1 .floatright .unnumbered} 14. Log in as each band member (four times) and create the shortest relative (not absolute) **soft link** ([Symbolic Link]) named `music` in their HOME directory that links up to `/home/music` so that each band member can then use the soft link to access the `/home/music` directory instead typing the entire pathname. - Test that `ls music` and `ls /home/music` show the same files, when run from the HOME directory of each band member. Run the **Fetch** and [Checking Program] to verify your work so far. When you are done ----------------- That is all the tasks you need to do. Read your CLS Linux EMail and remove any messages that may be waiting. See [Reading eMail] for help. Check your work a final time using the [Checking Program] and save the standard output as described below. Submit your mark following the directions below. > Optional: Keeping your main configuration snapshots, remove any > intermediate snapshots you no longer require, to free up disk space. - Be > careful not to remove your current work! Checking, Marking, and Submitting your Work =========================================== See [CentOS Remote Checking, Marking, and Submitting your Work]. **READ ALL THE WORDS. OH PLEASE, PLEASE, PLEASE READ ALL THE WORDS!** -- | Ian! D. Allen - idallen@idallen.ca - Ottawa, Ontario, Canada | Home Page: http://idallen.com/ Contact Improv: http://contactimprov.ca/ | College professor (Free/Libre GNU+Linux) at: http://teaching.idallen.com/ | Defend digital freedom: http://eff.org/ and have fun: http://fools.ca/ [Plain Text] - plain text version of this page in [Pandoc Markdown] format [www.idallen.com]: http://www.idallen.com/ [hyperlink URLs]: indexcgi.cgi#XImportant_Notes__alphabetical_order_ [Class Notes]: indexcgi.cgi#Important_Notes__alphabetical_order_ [Assignments]: indexcgi.cgi#Assignments [Worksheets]: indexcgi.cgi#Worksheets__not_for_hand_in_ [CentOS Install and Configure]: 000_centos_install.html [Checking Program]: #checking-marking-and-submitting-your-work [Course Linux Server]: 070_course_linux_server.html [Users and Groups]: 700_users_and_groups.html [Find and Xargs]: 185_find_and_xargs.html [Remote Login]: 110_remote_login.html [Base Directory]: #centos-set-up-the-base-directory-on-centos [Search Path]: 400_search_path.html [File Transfer]: 015_file_transfer.html [Permissions]: 500_permissions.html [Changing Permissions]: 500_permissions.html#changing-permissions-using-chmod [Links and Inodes]: 455_links_and_inodes.html [**Megadeth**]: https://en.wikipedia.org/wiki/Megadeth [Song files]: http://www.youtube.com/watch?v=VXpjtWZn_vU [Symbolic Link]: 460_symbolic_links.html [Reading eMail]: 070_course_linux_server.html#email-on-the-cls [CentOS Remote Checking, Marking, and Submitting your Work]: 000_centos_marking.html [Plain Text]: assignment12.txt [Pandoc Markdown]: http://johnmacfarlane.net/pandoc/