Well, I have been procrastinating about this.  My security videos get saved on the linux security server, and are limited to a month or so.  Daily, those sql event images get combined into an .avi video and saved locally and sent via ftp to my main server.  They DO pile up, though, as evidenced by the image on the right.  1.2TB.  They have been saving since 12 Apr 2018, when I added that feature to the script that I wrote that created the video files from the sql images.  The reason I did that was that it made it easier to review and archive the security alerts.  Hand deleting all those directories would be a major pain in the ass.  Enter this command:  😉

[root@cap Cameras]# find -mtime +365 -exec rm -R {} \;

It took a short while to parse through all the directories, but, eventually it finished. I checked on things with du -h –max-depth=0. The max-depth argument will stop all the sub directories from printing to the screen.  The results are in the image below.  436GB.  That’s quite a bit of space saved.  Now, instead of directory saved images dating back to 2018, there is only one year.  While the find/rm command above is suitable to enter directly into a terminal and have it operate on the current directory, it is rather dangerous to use.  Far better to schedule a potentially dangerous command in the cron.  First step, is to create the command.  In order to do that, as root do: nano /sbin/shear , or the name you choose to use.  I chose shear.  Add this & save: find $1 -mtime +365 -exec rm -R {} \;  If you have sharp eyesight, you will notice that I inserted $1 after find.  This is a command variable.  Last part of creating the command will be to make it executable by root, and not even readable by other users.  Do this  as root to do that; chmod 700 /sbin/shear.  Of course, if you can’t use root directly on your system, then use sudo.  Now, you can directly use the command that you created as:

# shear /path/to/directory/you/wish/. (/sbin/ should be in your path. If you saved it elsewhere not in your path,  </path/shear>) 😉

Final step is to create a crontab entry to run it monthly or so.  crontab -e will allow you to edit your crontab,  Of course, you might have to do sudo crontab -e if you can’t become root.  If you need help with the syntax: cat /etc/crontab.  I also have the MAIL=root commented out, so as not to get emails filling up root’s email box.  Then, restart crond.  That’s it.  If anybody needs a review of crontab and how to use systemctl to restart crond, either reach out to me, or just add a comment, and I’ll create a little tutorial. 😉