Snipe-It Servers - Ubuntu - MEDAZR-P3T-521

Body

If this article is covering dev / test / production severs within one article, then each environment may have any differences specified within in each category below. Some sections may need multiple outside resources created and added to this page (e.g. a Visio diagram for each environment).

Index

  1. Overview - Executive Summary
  2. How to access
    1. Administrative access
    2. Customer access
  3. Compliance
    1. Copy of Data Use Agreement
    2. FSU Data Classification Level
    3. Compliance Standards this system must meet
  4. Setup and Configuration
    1. Prerequisites
    2. Server(s) Configuration
    3. Server Requirements
    4. Networking
    5. Installing Roles / Features / Applications
    6. Security
    7. Scheduled Jobs
    8. Data Protection
  5. Functionality and Monitoring
    1. Functionality of the system
    2. Service Health
    3. Monitoring
  6. Support
    1. Links to relevant MED KB articles (in TDX)
    2. Links to online support documents from vendors
    3. Initial Procurement Info (if not on the TDX Asset Pages)
    4. Support contact information
  7. Troubleshooting
    1. Common issues to look out for and resolutions to them
  8. Ongoing Maintenance Needs
    1. Special Considerations for OS Updates
    2. Vendor Updates
    3. Is other recurring work required to have this system function optimally?

 

Overview - Executive Summary

Who is the system primarily designed for?

This system is designed for the Service Desk and other relevant Information Technology personnel to manage and track assets, and it will function as the primary CMDB and centralized information hub for systems in the Med IT environment.

What is this system designed to accomplish?

This machine will host an installation of Snipe-It, which is a free and open source inventory management software. It is web based.

How to access

Administrative access

  1. SSH access is available via IOPS VMs and Powershell Azure remote app using the fsucomadmin accounts (which can elevate with sudo)
    1. Prod- Secret Details - Secret Server
    2. Dev- Secret Details - Secret Server
  2. VNC Access via the TurboVNC Azure remote app, first using admin creds to auth into TurboVNC, then the same fsucomadmin accounts to establish the GUI connection
  3. https://inventory.med.ad.fsu.edu/ - Members of the SuperUsers groups within the Snipe-It application can use the management tools within Snipe-It to perform regular tasks like backups, ldap configuration, etc.

 

Customer access

Customers will exclusively access via the web interface from FSU Med IT network space - https://inventory.med.ad.fsu.edu/

Log into the web portal at inventory.med.ad.fsu.edu with domain credentials.

Compliance

Copy of Data Use Agreement

 

FSU Data Classification Level

 

Compliance Standards this system must meet

 

Setup and Configuration

Prerequisites

  1. What needs to exist before this document can be used to fully recreate this application / server?

Server(s) Configuration

Follow the standard procedure for servers, physical or virtual - KBs exist for both

  1. List of Assets Involved in the Application
    1. MEDAZR-P3T-521 - Production Snipe-It Server MEDAZR-P3T-521 - Microsoft Azure
    2. MEDAZR-D4T-789 - Dev Snipe-It Server MEDAZR-D4T-789 - Microsoft Azure
  2. What is the function of each part of the system?
    1. Basic LAMP Stack
    2. Apache/PHP functions as the web frontend
    3. MySQL runs the underlying DB for the Snipe-It system
  3. Link to code repo

Server Requirements

  1. Minimum Hardware requirements for the server(s)
    1. 2 CPU / 8GB RAM / 120GB OS Disk space plus a 32 GB Data Disk
  2. Vendor Requirements document(s)
    1. Requirements

Diagrams

  1. Insert relevant diagrams about how the systems interact
    1. network, server, storage, logical, etc.
    2. You may choose to use Draw.io, Visio, or other compatible tool to create the diagrams.
    3. Please store the originals in Microsoft Teams.

Networking

  1. DNS names
    1. Production Host (A) Record - Forward Lookup Zones> med.ad.fsu.edu>MEDAZR-P3T-521 static
      Uploaded Image (Thumbnail)
       
    2. Production cName Alias - inventory.med.ad.fsu.eduUploaded Image (Thumbnail)
    3. Production Static Pointer Record in 6.164.10
      Uploaded Image (Thumbnail)Uploaded Image (Thumbnail)

Installing Roles / Features / Applications

  1. What needs to be installed and what is the purpose?
  2. How to install each item

Security

  1. User Permissions
    1. Customer permissions
      1. AD Groups and what they have access to
    2. Administrative permissions
      1. AD Groups and what they have access to
      2. What passwords / keys are used? Link to Secret Server secrets.
  2. Logging
    1. Apache logs are stored in the following locations:
      1. "/var/log/apache2/access.log*"
      2.  "/var/log/apache2/other_vhosts_access.log*"
      3.  "/var/log/httpd/access_log*"
      4. "/var/log/apache2/snipe-it_access.log*"
      5. "/var/log/apache2/error.log*"
      6. "/var/log/httpd/error_log*"
      7. "/var/log/apache2/snipe-it_error.log*"
    2. All logs can be found for this server indirectly by accessing Elastic. Filter *logs or *metrics views for agent.name and use the prod or dev server hostname.
      1.  
  3. Necessary Firewall Rule Documentation
    1. Rules needed for Windows firewall
    2. Rules needed for external (Sophos) firewall

Scheduled Jobs

  1. What jobs or tasks have been configured to run to ensure that this system functions optimally, and at what frequency?
    1. The following crontab configuration is how scheduled jobs have been set up on this server. This is how Snipe-It handles it's own pre-built "artisan schedule" as well as where we put user configurations for Snipe-It backups. These backups are set to run at 10 PM, just as they were on the prior system.

      1. # -----------------------------------------------------------------------------
        # SNIPE-IT AUTOMATION SCHEDULE
        # User: www-data
        # Path: /datadisk/snipe-it/
        # -----------------------------------------------------------------------------

        # 1. Application Heartbeat (Internal Scheduler)
        # Runs every minute to check for queued application tasks (Alerts, Cleanups).
        # Output is silenced to prevent syslog spam.
        * * * * * /usr/bin/php /datadisk/snipe-it/artisan schedule:run >> /dev/null 2>&1

        # 2. Daily Backup Routine
        # Forces a full backup (DB + Files) at 10:00 PM Server Time.
        # Output is piped to Syslog with tag 'snipeit_backup' for Elastic monitoring.
        0 22 * * * /usr/bin/php /datadisk/snipe-it/artisan snipeit:backup 2>&1 | /usr/bin/logger -t snipeit_backup

      2.  Detailed Jobs Breakdown

        1. Job A: The Application Heartbeat

          1. * * * * * /usr/bin/php /datadisk/snipe-it/artisan schedule:run >> /dev/null 2>&1

          2. Schedule (* * * * *): Executes every minute of every day.

          3. Command: Triggers Laravel's internal "Manager." It checks the code to see if weekly/monthly tasks are due.

          4. Output Handling: >> /dev/null 2>&1. Both standard output and errors are discarded.

            • Reasoning: This job runs 1,440 times a day. Logging every execution would flood the system logs with "Nothing to do" messages.

            • Monitoring: We monitor the existence of the schedule:run execution via the syslog log stream in Elastic (Proof of Life).

        2. Job B: The Daily Backup

          0 22 * * * /usr/bin/php /datadisk/snipe-it/artisan snipeit:backup 2>&1 | /usr/bin/logger -t snipeit_backup

          1. Schedule (0 22 * * *): Executes at 22:00 (10:00 PM) system time.

          2. Command: Bypasses the internal scheduler and forces the snipeit:backup command immediately.

          3. Output Handling: 2>&1 | /usr/bin/logger -t snipeit_backup.

            1. Monitoring: Elastic is configured to alert if the string "Backup completed" associated with process.name : snipeit_backup is not seen for 25 hours.

            2. Reasoning: Instead of discarding output, we capture success/fail messages and pipe them into the System Log using the tag snipeit_backup.

Data Protection

  1. Backup Process
    1. Where are backups stored?
      1. MEDAZR-P3T-521 - Microsoft Azure - Azure Backups
      2. Backups :: FSU College of Medicine - Inventory Backups

        1. Local Storage Path: /datadisk/snipe-it/storage/app/backups/

        2. Retention Policy: Configured in /datadisk/snipe-it/.env.

          • The system automatically deletes backups older than the configured threshold (currently set to keep 7 days of daily backups).

          • Cleanup is handled by the "Heartbeat" job (Job A, detailed above) which runs backup:clean automatically.

    2. How often are backups run?
      1. Daily
  2. Restore Process
    1. How long of an outage (approximately) does it take to restore?
      1. Inventory Backup restore to an otherwise working Snipe-It server takes roughly 10 minutes
      2. Restoring an Azure backup has taken roughly 20 minutes, including the Snipe-It restore.
      3. Rebuild server plus Snipe-It Inventory Backup is roughly 50 minutes to 1 hour for bare essential service restoration, plus DNS record resync time for pointer records which can take 30-90 minutes

Functionality and Monitoring

Functionality of the system

  1. What are the key functions that customers rely on for this system?
    1. Inventory website with the ability to view and manipulate records
  2. How are these functions configured in technical detail?
    1. Granular detail is found here, following the instructions for Using Apache: Linux/OSX

Service Health

Monitoring

  1. What special alerting needs does this system have?
    1. IOPS - Snipe-It Inventory System Heartbeat Log - Availability - Rules - Alerts - Observability - Elastic - If less than 28 heartbeats in the last 30 minutes, alert that the service may be unavailable and should be validated.
    2. Snipe-It Scheduled DB Backups Logs must have 1 entry every night at 10 PM. Intend to have an email alert come in at 7am indicating that the prior evening's run didn't produce a backup in case of failure. For now, this just runs when the detection occurs: IOPS - Snipe-It Automated App Database Backup Did Not Succeed - Rules - Alerts - Observability - Elastic
    3. The following two alerting rules on TLS certificates
      1. Synthetics TLS certificate 30 Day Rule - Rules - Alerts - Observability - Elastic
      2. Synthetic TLS Certificate 5 Day Rule - Rules - Alerts - Observability - Elastic

Support

Links to relevant MED KB articles (in TDX)

 

Links to online support documents from vendors

 

Initial Procurement Info (if not on the TDX Asset Pages)

 

Downtime Policy

Define uptime requirements, who to notify, and how to request unscheduled downtime:

  • Shane Weatherby - Service Desk - Primary customer stakeholder for broadest user group. May be involved in Snipe-It data backup/restoration or user assistance.
  • IOPS - Will be involved in any infrastructure maintenance/updates and any full-system restoration.
  • Downtime needs to be scheduled and coordinated between Service Desk, IOPS, ETCs, Client Management. Announcements will need to be made to MED Maintenance | MED OIT | Microsoft Teams

Support contact information

  1. No vendor support for this system, consult the documentation Introduction

Troubleshooting

What can we do to troubleshoot during the day

  • This system needs to be available from 8a.m. - 6 p.m. unless scheduled maintenance is approved.
  • Do we need approval for a therapeutic reboot
    • IOPS and Service Desk need to approve along with a detailed change log, and warning needs to be given to relevant stakeholders in Med Maintenance.
    • Are there special steps needed to ensure the reboot doesn't break things or to bring the server back up?
      • No, all services should start automatically and be available within 3-5 minutes of boot time.

Common issues to look out for and resolutions to them:

1. If you need to change the email address that the system is using-

  1. Make a copy of /datadisk/snipe-it/.env in case you make a huge mistake

  2. Modify the file by running:
    sudo nano /datadisk/snipe-it/.env

  3. Find the comment block in the file for email settings
    1. Header will start with:
      # -------------------------------------------- # REQUIRED: OUTGOING MAIL SERVER SETTINGS # --------------------------------------------
    2. Modify the following values, replacing the address after the equals sign with your intended new address/alias:
      1. MAIL_FROM_ADDR=you@example.com
      2. MAIL_REPLYTO_ADDR=you@example.com
  4. Apply the reconfiguration by running:
    sudo php artisan config:clear

 

Ongoing Maintenance Needs

Special Considerations for OS Updates

Vendor (application) Updates

  1. Name of software - Snipe-It
  2. Downtime estimate for an update - 2-4 Hours
  3. release cadence of Vendor Updates - High Frequency, intermittent
  4. Steps to Install Vendor Updates - Follow Git instructions here, as this will be dynamic: Upgrading

Is other recurring work required to have this system function optimally?

  1. Downtime estimate
  2. Frequency of the work
  3. Steps to complete the activities
  4. Does the system need a scheduled reboot

Details

Details

Article ID: 168836
Created
Tue 9/16/25 11:46 AM
Modified
Mon 12/8/25 4:28 PM