# Fiverr # fiver-tc ### **Terms and Conditions – Open Source Software Deployment Services** Thank you for choosing my service for deploying open-source applications such as **osTicket, Nextcloud, etc.** By placing an order, you agree to the following terms and conditions: ### **1. Service Scope** - Deployment will be performed as per the selected package (e.g., Shared Hosting, Standalone VPS/Server, or Docker-based setup). - This service **only covers installation and initial configuration** of the selected application. - I am **not responsible** for application-level support, customizations, troubleshooting internal software bugs, or usage training post-deployment. ### **2. Prerequisites to Start the Order** To begin work and ensure a smooth and successful deployment, you must provide the following: - **Root SSH access** to the server or relevant hosting control panel access. - A **valid domain name** and either: - DNS already pointed to the server IP, or - **Domain registrar access** if DNS configuration is needed on your behalf. - If you have a **custom or paid SSL certificate**, please provide the necessary certificate files (CRT, KEY, and CA-Bundle if available). - The server must be **fresh/clean**, with no conflicting applications or services running unless discussed in advance. - If your hosting is **shared** (non-root), please confirm that it supports all required technologies (PHP, MySQL, etc.) for the requested application. ### **3. Delivery & Acceptance** - Once deployment is complete, I will notify you for review. - You are responsible for **checking and testing the deployment** before marking the order as complete. - Post-completion support is **not included** unless explicitly purchased as an add-on or agreed upon in the gig extras. ### **4. Responsibility Disclaimer** - I am not liable for: - Issues related to your hosting provider. - Application updates or third-party plugin/module issues. - Data loss due to your hosting environment or mismanagement after delivery. - Security and backup setups are **not included** unless specifically requested and included in the order. ### **5. Communication & Order Delays** - Orders may be **delayed** or **cancelled** if prerequisites are not provided within a reasonable time (e.g., 48 hours). - Incomplete or incorrect information may result in additional charges or cancellation depending on the complexity involved. ### **6. Additional Services** - Any service beyond the defined gig (e.g., application tuning, advanced security hardening, or customization) may incur extra charges. # alexbaik ##### **📦PBX Voice Recording Backup & Web Access Plan** ##### **✅ Scope** \- Automatically archive and transfer PBX call recordings from GCP-hosted Linux servers to an on-premises FTP server. \- Provide web-based, password-protected access to recordings for internal staff. ##### **🔁 Daily/Weekly Backup Workflow** Step 1: Prepare the PBX Nodes (GCP Linux Hosts)** \- Confirm recordings are stored under structured directories like: /var/lib/freeswitch/recordings/{hostname}/archive/{year}/{month}/ \- Ensure correct file ownership (e.g. www-data) and read access. **Step 2: Create a Bash Script for Scheduled Archiving** \- Script will: \- Compress the current day/week’s recordings into a dated .tar.gz archive. \- Upload the archive securely to the FTP/scp server. **Step 3: Automate with Cron** \- Schedule the script at 12:01 AM weekly or daily, depending on retention needs: ##### **🌐 Web Access Setup (On-Prem FTP Server)** Step 4: Install IIS & Configure Web Root \- Set FTP destination path as IIS web root: C:\\inetpub\\wwwroot\\pbx-recordings \- Configure basic authentication. Step 5: Implement Access Restrictions \- Restrict login to local subnet IPs (e.g. 192.168.x.x) via IIS IP Restrictions. Step 6: Password-Protect Recording Directory \- Use IIS features or .htaccess equivalent to secure the /pbx-recordings folder. Step 7: Simple Listing Page (Optional) \- Create a minimal HTML index or use a file-listing tool for browsing recordings: 🔒 Security Checklist \- ✅ Use strong FTP/SCP credentials. \- ✅ Validate archive before upload. \- ✅ Enable firewall rules to limit access. \- ✅ Monitor backups and access logs. # hiteshpatel601
**Server****OS****Provider**
1WindowsHetzner
2Linux - UbuntuHetzner
3Linux - UbuntuDigital Ocean
4Linux - UbuntuIONOS
5Linux - UbuntuIONOS
6Windows
7WindowsClouldy
8Linux - UbuntuIONOS
#### **Prerequisites to Begin** **1. Server Access** - ✅ SSH access to Linux/Ubuntu servers - ✅ RDP or admin access to Windows servers **2. Network & Firewall Rules (optional if no internet restrictions)** - ✅ Allow outbound traffic to New Relic endpoints (TCP 443) - ✅ If needed, whitelist these New Relic domains/IP ranges: [New Relic Network Requirements](https://docs.newrelic.com/docs/new-relic-solutions/get-started/networks/) **3. Server Info to Share** - Operating System and version for each server (already Shared) - Hostname and internal IP - Role (web, DB, app server, etc.) - Business priority (helps tailor alert thresholds) **4. Admin Account** - Create a New Relic account or invite us to yours - Provide admin-level access for setup ##### **🛠️ Setup Plan** **Step 1: Install New Relic Infrastructure Agents** - Linux/Ubuntu: install via shell script or package manager - Windows: install via MSI or PowerShell **Step 2: Enable Server-Level Alerts** - Alerts for: - Server down - High CPU/RAM usage - Low disk space - Network issues - Application crash (if applicable) - Synthetic Monitoring **Step 3: Dashboard Creation** - Custom dashboard showing server health, online status, CPU, RAM, disk, and real-time analytics **Step 4: Notification Channels** - Set up alerts via: - Email **Step 5: Optional Add-ons** - Synthetic monitors for uptime checks