From CGW Wiki
Jump to: navigation, search

Columbia Gadget Works current security system consists of physical locks for access control and security cameras to document what goes on the in and around the hackerspace. A full access control system is still in the works, but for the time being paying members are provided the garage door security code for 24/7 access to the space. Non-members need to be accompanied by a member or attend one of our events to enter.

Security Cameras

Several network cameras have been kindly donated to CGW to improve the security of our hackerspace. We use the Linux-based Motion software to record and manage events captured from these cameras. If you need to review these recordings and do not have access to the security camera systems, please talk to one of the officers.


All of our network cameras are various models of Foscam. These are definitely more budget-minded IP cameras, but they have held up well for our uses and documentation is relatively easy to find. We also utilize donated USB web cameras where applicable for further camera coverage.

Motion Configuration

Our configuration for Motion is pretty standard for a multiple camera set up. You can read more about the ideals behind this configuration in the Motion documentation or on blog posts like this one.


Because we configured Motion for multiple cameras, we've removed lines from this file that are specific to capture devices. Those belong in the individual thread configuration files. This is partially to ensure that none of these options get overwritten for our threaded capture devices, but also to signal to anyone reading this motion.conf file that the video capture occurs elsewhere. Specifically, we've made sure the following options are commented out:

 ; videodevice
 ; tunerdevice
 ; netcam_url
 ; netcam_userpass
 ; target_dir
 ; webcam_port

Options that are shared among all of our cameras are kept in the motion.conf file. This includes options related to capturing events and the file encoding of videos Motion creates. We also ensure that any thread.conf files we have configured are included at the end of the motion.conf file with a line like the one below:

 thread /etc/motion/thread1.conf


With many of the more complicated options left in the motion.conf file, our individual camera configurations (in this example, thread1.conf) end up relatively simple. We only need the options for how Motion will retrieve the video and any options that are specific to that camera (such as rotate for cameras mounted upside-down). For example, a new network camera could be added to our system by creating a new configuration file with only the following options.

 netcam_url <url>
 netcam_userpass <username>:<password>
 text_left <camera name>
 target_dir <directory to save events>
 webcam_port <port to view camera>

Cleanup of Events

To keep from filling up all of our hard drive space, we have to delete events after a certain period of time. Unfortunately, Motion does not have a built-in mechanism to do this for us. So, we created the below Bash script which can delete old files en masse. In our case, our cameras store their events into individual directories under a single Motion directory. This script searches through all those directories to delete any files older than the upper limit we set.

 # This script will clean up files generated by motion that were modified more
 # than $SAVE_DAYS days before midnight on the day this is run. This is
 # to prevent motion from taking up all of our HDD space.
 SAVE_DAYS=<number of days to store events>
 MOTION_DIR='<root directory where motion stores events>'
 for CAM_DIR in `ls $MOTION_DIR`
    echo "Removing files older than $SAVE_DAYS from $MOTION_DIR/$CAM_DIR"
    find $MOTION_DIR/$CAM_DIR -mtime +$SAVE_DAYS -and -type f | xargs rm -f

We then set a cron job to run this script every day at midnight by adding the following line to the crontab of our Motion user. For more information about cron, please check out this resource.

 0 0 * * * <script dir>/ > <log dir>/cleanup_motion.log 2>&1

Note: It's important that this script runs under a user that has write permissions to the directories where the Motion events are stored, otherwise it will fail.