adding a pass to folder

Step 1: Enable .htaccess Usage

<Directory /var/www/html>

    Options Indexes FollowSymLinks

    AllowOverride All

    Require all granted

</Directory>

2) sudo systemctl restart apache2

3) Install utils for pass file

 sudo apt-get install apache2-utils

4) Create pass file

  sudo htpasswd -c /etc/.htpasswd yourusername

5) Create a  .htaccess on the folder

cd /var/www/html/recordings

nano .htaccess

Add the following lines to the file:

AuthType Basic

AuthName "Restricted Access"

AuthUserFile /etc/.htpasswd

Require valid-user

Test and  additional considerations

sudo chmod 644 /etc/.htpasswd

sudo chmod 644 /var/www/html/recordings/.htaccess

removing files

 To delete all .wav files in the subdirectories of a specific directory, such as /var/spool/asterisk/monitor/2024/07, you can use a combination of the find command with rm in a Unix-like operating system. Here’s how you can do it safely and efficiently:

Deleting .wav Files in Subdirectories

1. Open a Terminal:

   Make sure you have the necessary permissions to delete files in the target directory. You might need sudo if the directory requires elevated permissions.

2. Use the find Command:

   The find command is a powerful utility for searching and performing actions on files. To find and delete all .wav files in subdirectories, use the following command:

   bash
   

3. find /var/spool/asterisk/monitor/2024/07 -type f -name '*.wav' -exec rm {} +

Explanation:

• find /var/spool/asterisk/monitor/2024/07: Starts the search from the specified directory.
• -type f: Searches for files (not directories).
• -name '*.wav': Matches files with the .wav extension.
• -exec rm {} +: Executes the rm command on the matched files. The {} is a placeholder for the filenames found, and + means that rm will be called with as many filenames as possible at once.

Verify the Files to be Deleted (Optional):

Before actually deleting the files, you might want to list them to confirm what will be removed. Use the following command to list all .wav files in subdirectories:

find /var/spool/asterisk/monitor/2024/07 -type f -name '*.wav'

Additional Tips

• Dry Run: To perform a dry run and see what would be deleted without actually removing the files, you can use:

  bash
  

• find /var/spool/asterisk/monitor/2024/07 -type f -name '*.wav' -print
• 
  

https://docs.docker.com/reference/dockerfile/

 https://docs.docker.com/reference/dockerfile/

stop all docker and remove

 docker stop  $(docker ps -qa) && docker rm  $(docker ps -qa)

https://docs.docker.com/reference/compose-file/build/

 https://docs.docker.com/reference/compose-file/build/

Git

Version control 

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later 

 stream of snapshots.

 With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots.

Git is Distributed Version Control Systems

Distributed Version Control Systems

This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial or Darcs), clients don’t just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history. Thus, if any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it. Every clone is really a full backup of all the data.

Figure 3. Distributed version control diagram

Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.

Nearly Every Operation Is Local

Most operations in Git need only local files and resources to operate — generally no information is needed from another computer on your network. If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous.

For example, to browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you — it simply reads it directly from your local database. This means you see the project history almost instantly. If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally.

This also means that there is very little you can’t do if you’re offline or off VPN. If you get on an airplane or a train and want to do a little work, you can commit happily (to your local copy, remember?) until you get to a network connection to upload. If you go home and can’t get your VPN client working properly, you can still work. In many other systems, doing so is either impossible or painful. In Perforce, for example, you can’t do much when you aren’t connected to the server; in Subversion and CVS, you can edit files, but you can’t commit changes to your database (because your database is offline). This may not seem like a huge deal, but you may be surprised what a big difference it can make.

Git Has Integrity

Everything in Git is checksummed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without Git knowing about it. This functionality is built into Git at the lowest levels and is integral to its philosophy. You can’t lose information in transit or get file corruption without Git being able to detect it.

The mechanism that Git uses for this checksumming is called a SHA-1 hash. This is a 40-character string composed of hexadecimal characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. A SHA-1 hash looks something like this:

24b9da6552252987aa493b52f8696cd6d3b00373

You will see these hash values all over the place in Git because it uses them so much. In fact, Git stores everything in its database not by file name but by the hash value of its contents.

Git Generally Only Adds Data

When you do actions in Git, nearly all of them only add data to the Git database. It is hard to get the system to do anything that is not undoable or to make it erase data in any way. As with any VCS, you can lose or mess up changes you haven’t committed yet, but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository.

This makes using Git a joy because we know we can experiment without the danger of severely screwing things up. For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see Undoing Things.

The Three States

Pay attention now — here is the main thing to remember about Git if you want the rest of your learning process to go smoothly. Git has three main states that your files can reside in: modified, staged, and committed:

• Modified means that you have changed the file but have not committed it to your database yet.

• Staged means that you have marked a modified file in its current version to go into your next commit snapshot.

• Committed means that the data is safely stored in your local database.

This leads us to the three main sections of a Git project: the working tree, the staging area, and the Git directory.

Figure 6. Working tree, staging area, and Git directory

The working tree is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.

The staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit. Its technical name in Git parlance is the “index”, but the phrase “staging area” works just as well.

The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.

The basic Git workflow goes something like this:

1. You modify files in your working tree.

2. You selectively stage just those changes you want to be part of your next commit, which adds only those changes to the staging area.

3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

If a particular version of a file is in the Git directory, it’s considered committed. If it has been modified and was added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. In Git Basics, you’ll learn more about these states and how you can either take advantage of them or skip the staged part entirely.

The basic Git workflow goes something like this:

1. You modify files in your working tree.

2. You selectively stage just those changes you want to be part of your next commit, which adds only those changes to the staging area.

3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

If a particular version of a file is in the Git directory, it’s considered committed. If it has been modified and was added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. In Git Basics, you’ll learn more about these states and how you can either take advantage of them or skip the staged part entirely.

https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository

Docker Network