README.md

File Management, Permissions and Backup

Costa Rica

brown9804

March, 2022

---

This is a summary based on References

Connect to the server:

ssh <user_name>@<IPadress>

Creating a Directory Structure in Linux:

Understanding how to create a certain directory and subdirectory structure, plus a couple of empty text files.

Create the Parent Directories:

By Hand:

[cloud_user@host]$ mkdir -p Projects/ancient
[cloud_user@host]$ mkdir Projects/classical
[cloud_user@host]$ mkdir Projects/medieval

With Bash Expansion:

[cloud_user@host]$ mkdir -p Projects/{ancient,classical,medieval}

Create the Subdirectories:

By Hand:

[cloud_user@host]$ mkdir Projects/ancient/egyptian
[cloud_user@host]$ mkdir Projects/ancient/nubian
[cloud_user@host]$ mkdir Projects/classical/greek
[cloud_user@host]$ mkdir Projects/medieval/britain
[cloud_user@host]$ mkdir Projects/medieval/japan

With Bash Expansion:

[cloud_user@host]$ mkdir Projects/ancient/{egyptian,nubian}
[cloud_user@host]$ mkdir Projects/classical/greek
[cloud_user@host]$ mkdir Projects/medieval/{britain,japan}

Create Some Empty Files:

[cloud_user@host]$ touch Projects/ancient/nubian/further_research.txt
[cloud_user@host]$ touch Projects/classical/greek/further_research.txt

Rename a Subdirectory:

[cloud_user@host]$ mv Projects/classical Projects/greco-roman

Working with Compressed Files in Linux:

Get the Original File Size:

[cloud_user@host]$ ls -lh junk.txt

Creating zip Files:

Gzip

1. Compressing data:
   [cloud_user@host]$ gzip junk.txt
2. Run ls to view the size of the file:
   [cloud_user@host]$ ls -lh
3. Unzip:
   [cloud_user@host]$ gunzip junk.txt.gz

bzip

1. Compression method instead:
   [cloud_user@host]$ bzip2 junk.txt
2. Run ls to view the size of the file:
   [cloud_user@host]$ ls -lh junk.txt.bz2
3. Unzip:
   [cloud_user@host]$ bunzip2 junk.txt.bz2

XZ

1. Compression method instead:
   [cloud_user@host]$ xz junk.txt
2. Run ls to view the size of the file:
   [cloud_user@host]$ ls -lh
3. Unzip:
   [cloud_user@host]$ unxz junk.txt.xz

Creating tar Files:

1. Compression method instead:
   [cloud_user@host]$ tar -cvzf gztar.tar.gz junk.txt
2. Then, let's make one using bzip2:
   [cloud_user@host]$ tar -cvjf bztar.tar.bz2 junk.txt
3. Finally, we'll use XZ to make one:
   [cloud_user@host]$ tar -cvJf xztar.tar.xz junk.txt
4. Run the ls command again to compare the file sizes:
   [cloud_user@host]$ ls -lh

Practice Reading Compressed Text Files:

How to read the contents of compressed files without having to actually decompress them? There is a way! Let's do that now. First, let's copy over the /etc/passwd file to your home directory: [cloud_user@host]$ cp /etc/passwd /home/cloud_user/

Gzip

1. Compression method instead:
   [cloud_user@host]$ tar -cvzf passwd.tar.gz passwd
2. And we can use the zcat command to read this compressed file:
   [cloud_user@host]$ zcat passwd.tar.gz

bzip2

1. Now let's compress the file, using bzip2, into a tarball:
   [cloud_user@host]$ tar -cvjf passwd.tar.bz2 passwd
2. We can use the bzcat command to read the compressed file:
   [cloud_user@host]$ bzcat passwd.tar.bz2

XZ

1. Finally, let's create an xz tar file:
   [cloud_user@host]$ tar -cvJf passwd.tar.xz passwd
2. And we can use the xzcat command to read its contents:
   [cloud_user@host]$ xzcat passwd.tar.xz

Managing File Attributes and Permissions:

Objectives:

1. Reset a directory's permissions to the following:

• Everyone can access the directory
• Everyone can read the files in the directory
• No one can execute files in the directory

2. Apply all of these permissions to all subdirectories recursively

Grant Access to the Directory:

1. Change to the opt directory:
   cd /opt
2. Next, open all of the directory's files and permissions with the following command:
   ls -la
3. Let's try to access the myapp directory. Run the following command:
   cd myapp/
4. How to fix "Permission denied": sudo chmod 777 myapp
5. Reopen the directory files and permissions using the ls -la command. Now let's try to open the directory again: cd myapp

Change the Directory Permissions:

1. Give all users read and write permissions for this directory:
   sudo chmod -f -x -R *

Just everyone read and write permissions sudo chmod 666 -f -R *

2. List the directory files and permissions again:
   ls -la
3. How to set the directories as executable:
   sudo find /opt/myapp -type d -exec chmod o+x {} \;

Create a Symbolic (Soft) Link:

1. Creating a symbolic (or soft) link from the /etc/redhat-release file to a new link file named release in the home directory:
   ln -s /etc/redhat-release release
2. Verify if the link is valid:
   ls -l
3. Check if you can read the file's contents:
   cat release
4. Check the link's contents:
   cat /etc/redhat-release

Should be the same

Check the Inode Numbers for the Link:

1. Look at the inode number of /home/cloud_user/release:
   ls -i release
2. Check the inode number for /etc/redhat-release:
   ls -i /etc/redhat-release

They should be different, as the symbolic link is just a new filesystem entry that references the original file.

Create a Hard Link:

1. Create docs directory:
   mkdir docs
2. Copy /etc/services into the docs directory:
   cp /etc/services docs/
3. Create a hard link from the /home/cloud_user/docs/services file to a new link location named /home/cloud_user/services:
   ln docs/services services
4. Check the link's inode number as well as the inode number for the original /etc/services:
   ls -l
5. View the contents of the inodes:
   

This should verify for us that this is a hard link, not a soft link. It won't have an arrow pointing to the actual file it's linked to, like a soft link does. Just to verify, check these two with cat and make sure they're the same:

ls -i services
ls -i docs/services

You should see they the same inode number, meaning they're essentially the same file.

Attempt to Create a Hard Link Across Filesystems:

1. View the individual block devices:
   lsblk

Each partition has its own set of inodes, hard links across partitions don't work. Soft links should.

2. Trying to make a hard link from /home/cloud_user/docs/services to /opt/services:
   ln /home/cloud_user/docs/services /opt/services

Should get a failed to create hard link error

Attempt to Create a Soft Link Across Filesystems:

1. Trying to make the same sort of cross-partition link, using the -s flag to make it a soft link:
   sudo ln -s /etc/redhat-release /opt/release

There shouldn't be any output, meaning it was successful.

2. View the contents of the inodes again:
   

ls -i /etc/redhat-release
ls -i /opt/release

You should see they have different inodes, but the linking will work.

Encrypt a File Using GPG:

Understand how to new public GPG key, encrypt a file and sign it, and send that file to another user to decrypt with "A Cloud Guru" public key.

Create a GPG Key for cloud user:

1. Generate a new GPG key:
   [cloud_user@host]$ gpg --gen-key
2. Credentials:

Accept the defaults for each prompt. For the user ID, enter cloud_user, and use cloud_user@localhost for the email address. We can leave the comment field blank by just pressing Enter, and press o at the end for OK. We'll use password321 when we're prompted for a passphrase, and when we're prompted to confirm it.

3. Now that the key has been created, we need to export it so that Gordon Freeman can decrypt files he gets from us. We'll do that like this:
   [cloud_user@host]$ gpg -a -o gfreeman.key --export <KEY_ID>
4. In that command, use the public key reference ID from the output of the key generation. It will be a random string, and the line it's sitting on (in the key generation output) looks like this:
   gpg: key XXXXXXXX marked as ultimately trusted
5. Now, we'll use the mail command to send an email to Gordon Freeman containing the cloud_user public key as an attachment:
   

[cloud_user@host]$ mail -s "here is your key" -a gfreeman.key gfreeman@localhost`
Don't lose this!  I'll call you with the passphrase.
.

Include that final period (on the line by itself) and then press Enter to send the message.

Configure GPG for Gordon:

1. Just as we did with the cloud_user account, we'll generate a GPG key for Mr. Freeman, accepting the defaults for each prompt. The only difference will be having a user ID of gfreeman and an email address of gfreeman@localhost:
   [gfreeman@host]$ gpg --gen-key
2. Once we've created the key for Mr. Freeman, we can open up the mutt email client, and save the public key sent over by the cloud_user account:
   [gfreeman@host]$ mutt

Arrow up and down to highlight the cloud_user message, then press Enter. Press v to view the attachment, and press s to save it to Mr. Freeman's home directory. Finally, press q to quit Mutt.

3. Now, to import the public key from cloud_user into Mr. Freeman's keyring, run the following command:
   [gfreeman@host]$ gpg --import gfreeman.key
4. We can run this to view the contents of Mr. Freeman's keyring:
   [gfreeman@host]$ gpg --list-keys
5. Let's log out of gfreeman's account:
   [gfreeman@host]$ exit

Generate a Signed Document and Send It to Gordon:

1. When we digitally sign a file, we are using our private GPG key to guarantee that this file came from us. The user that receives the file will use their copy of the public key from us to verify that we signed the file. Let's generate a test document:
   [cloud_user@host]$ echo "Just need you to verify this file." > note.txt
2. Now we'll use cloud_user's private key to sign the file:
   [cloud_user@host]$ gpg --clearsign note.txt

Remember that we need to use the passphrase we created earlier (password321). Now there should now be a note.txt.asc file in cloud_user's home directory. We can run a quick ls to make sure.

3. Now that we've made the file, let's email it to gfreeman@localhost:
   

[cloud_user@host]$ mail -s "check this out" -a note.txt.asc gfreeman@localhost
Could you verify this file for me?
.

Verify the Signature of the Emailed Document:

Use the mutt email client, and just as before, view and save the new email message's attachment.

1. Now, verify the note.txt.asc file that was emailed:
   [gfreeman@host]$ gpg --verify note.txt.asc
2. We'll get a warning about the signature not being verified by a third party, and that's ok. What is important is the following line from the output:
   gpg: Good signature from "cloud_user <cloud_user@localhost>"

This is what a verified file displays.

3. Next, encrypt a copy of the /etc/fstab file like this:
   

[gfreeman@host]$ cp /etc/fstab ~
[gfreeman@host]$ gpg -a -r cloud_user -e ~/fstab

You will see a general warning displayed about the key possibly not belonging to the named person. We already know that this key is from cloud_user, so just press y at the prompt.

4. Verify that there is a file called fstab.asc in the gfreeman home directory (by running ls). Create a new email to cloud_user and attach this file:
   

[gfreeman@host]$ mail -s "looks good" -a fstab.asc cloud_user@localhost
Can you decrypt this?
.

5. Log out:
   [gfreeman@host]$ exit

Decrypt the Attached File:

Now, as cloud_user, open up the mutt email client and save the fstab.asc attachment from the new email.

1. Decrypt the saved fstab.asc file with the gpg command, and enter the passphrase for cloud_user's key when prompted:
   [cloud_user@host]$ gpg fstab.asc
2. Now let's verify that we can read the contents of the decrypted file:
   [cloud_user@host]$ cat fstab

References

https://learn.acloud.guru/course/cad92c58-0fd2-4657-98f7-79268b4ff2db/dashboard

Refresh Date: 2025-10-29

Last updated: 2025-08-04