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 

 

 

 1 

 Windows 

 Hetzner 

 

 

 2 

 Linux - Ubuntu 

 Hetzner 

 

 

 3 

 Linux - Ubuntu 

 Digital Ocean 

 

 

 4 

 Linux - Ubuntu 

 IONOS 

 

 

 5 

 Linux - Ubuntu 

 IONOS 

 

 

 6 

 Windows 

   

 

 

 7 

 Windows 

 Clouldy 

 

 

 8 

 Linux - Ubuntu 

 IONOS 

 

 

 

   

 

 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 

 

 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