Category:BEETEL: Difference between revisions

Training session on Beetel Project 19 Dec 2023 - Tetra Support Staff - Manish Singh[edit]

Video summary: "Beetel Project" -- a Hindi-language KT session covering support/troubleshooting for Beetel's Java-based website (running on JBoss + Apache httpd + PostgreSQL), originally hosted on a cloud provider and later migrated by Tetra to Beetel's own in-house servers (Tetra retains VPN-based access for support, though day-to-day control sits with Beetel). Establishes the standard troubleshooting sequence for a "site is down" ticket: first check whether the site's front page loads (it may still render by default even if login is broken, so logging in with the help-desk test credentials is required to confirm the app is actually healthy), then check the three core services -- httpd, JBoss, and PostgreSQL -- restarting whichever is down (Apache/Postgres restart cleanly via `systemctl`, but JBoss additionally needs a specific follow-up command/script to fully bring the application back up after a restart). Covers the backup setup in detail: a daily 2am PostgreSQL database backup and a monthly (1st-of-month, 12am) JBoss/application backup, both driven by cron-scheduled scripts stored under root, landing first in a local backup directory (retained 7 days for DB, 4 backups for JBoss, older files auto-pruned by a custom cleanup script) and then rsynced out to a mounted remote Windows backup server share for longer-term retention. Explains how to verify backups are actually landing (checking file dates/sizes under the local and mounted remote backup paths) and flags that very old files sometimes accumulate on the remote mount and may need manual cleanup since retention there isn't automatic. Also references a rough personal migration notes file (IPs, /etc/hosts entries, DB setup steps from the original migration) as background context, explicitly noting it's not needed for day-to-day support -- the three-service-check-plus-backup-monitoring routine is what actually matters for tickets.

Training session on Beetel Snapshot Understanding - Tetra Support Staff - Biswajit Banerjee[edit]

Video summary: [SPARSE TRANSCRIPT - long stretches of silence/background music with little captioned speech; summary reflects only the clearly legible portions] "Beetel Snapshot Understanding" -- an English-language walkthrough of the KVM/libvirt-based VM snapshot and recovery mechanism used for Beetel's ~5-6 VMs. Explains the core approach: each VM's disk state is defined by an XML domain file (used to recreate/register the VM automatically if its host goes down); a script triggers `virsh`-style snapshot creation, which redirects new writes to a temporary overlay disk while the original base disk stays untouched and consistent; a nightly "block commit" operation (taking roughly 35 minutes) then merges the accumulated changes from the overlay back into the base disk. For resilience, each host's VM snapshots/backups are stored on a different physical machine rather than locally -- e.g. one host's ("55") snapshot backups land in a specific data/snapshot path on another host ("54"), and vice versa -- so a host failure doesn't take out its own backups with it. Access to the environment is via a VPN client requiring a one-time password emailed on connect, plus a separate web UI for direct VM console access. Given the heavy audio gaps in this recording, finer procedural detail (exact commands, snapshot restore steps) could not be reliably captured -- this summary reflects only what came through clearly.

Training session on Beetel Project 16 Feb 2024 - Tetra Support Staff - Manish Singh[edit]

Video summary: "Beetle KT" -- a Hindi-language infrastructure-background KT for Beetel, complementing the "Beetel Project" troubleshooting video with the physical layout and access model. Beetel runs two physical host machines (BM1 and BM2). BM1 hosts four VMs: the NF database, the "SDNet" server (the Java/JBoss website Tetra fully supports -- config, install, backup, and snapshots all owned by Tetra), PM Tools, and Partner Portal; BM2 hosts a single VM for a separate Axis Bank server. Tetra's actual support scope is narrow: only the SDNet server itself (application + database backups); the other VMs on BM1/BM2 were provisioned by Tetra as a one-time project delivery but are now the client's (or the client's own downstream client's, in the Axis Bank case) responsibility to back up and maintain. Snapshots for all VMs on BM1 are stored on BM2 (and vice versa was considered during migration planning but rejected in favor of just cross-host snapshot storage, not full replication) on a monthly schedule. Explains the access model in detail: Tetra's VPN IP is allow-listed only on the SDNet server itself, so direct SSH/PuTTY access is limited to that one box; reaching any other VM (Windows servers, etc.) requires a separate Beetel-provided VPN client that routes into a Cockpit-based web GUI, through which individual VMs can be opened/managed -- this is also how Windows-specific issues (e.g. copy-paste not working, permission fixes) get handled, since Cockpit is the only path to those machines. Repeats and adds detail to the SDNet server's backup mechanism already covered in "Beetel Project": application (JBoss) and database backups are each driven by their own cron-scheduled script under `/root/scripts`, written as `.tar` archives into local `_backup` directories (JBoss: max 4 backups retained via `mtime`-based cleanup, run monthly on the 1st; database: 7-day retention) and then rsynced out to an 11TB Windows-server directory mounted locally over the network for offsite retention.

Beetel Database Change Activity for Each Financial Year 01 Sep 2025 - Tetra Support Staff - Tushar Sonawane[edit]

Video summary: "Beetel database change activity for each financial year" -- a short, guided screen-share walkthrough (via remote-desktop tool) of a recurring annual maintenance task for the Beetel system: updating a database "system code" record that stores the current financial year. The presenter talks a colleague through navigating the admin/database interface: searching for the "system" table/section, browsing through paginated records to locate the specific financial-year entry, editing it, and changing the year value from "2024" to "2025" (both the primary field and a "last modified" date field), then saving. Confirms the change took effect by logging into the site afterward and checking it reflects the new financial year. This is a narrow, single-purpose recurring runbook task -- there is no broader architectural or troubleshooting content in this recording beyond the step-by-step navigation to make this one annual change.

RCA Beetel Year End DB Activity[edit]

1) Connect NextExtender VPN

2) Connect DB

Url - https://192.168.12.23/phpPgAdmin/ username - postgres password - HGVR_#dzsds3@

3) click on bttindia

4) click on public

5) search systemcode

6) click on systemcodes

7) click on browse

8) go on 27 number page

9) check for FINYR

10)click on edit

11) change the all value from 2024 to 2025 this done in year 2025 , change current financial year.

12) save

13) login to website and check

14) http://192.168.12.23:8080

15) username : HELPDESK

16) password : helpdesk

Training on BEETEL ORCLE DATA BASE. Dated 20 July 2026 - Tetra Support Staff - Takshay[edit]

Video summary: "BEETEL ORCLE DATA BASE KT SESSION" -- a Hindi-language handoff KT specifically about Beetel's Oracle database server, which previously ran on an aging physical machine (circa 2003-2004 hardware). To eliminate the single-point-of-failure risk of that old hardware, the presenter P2V'd it: took a full disk image of the physical server (a QCOW2 image, visible mounted via NFS in the hypervisor's storage) and imported/ran it as a VM inside a Proxmox VE cluster (referred to as "PRX"), with the original physical server kept powered off and untouched as a fallback (since both share the same IP, only one can be online at a time -- if a rebuild is ever needed, the physical box can simply be powered back on). Walks through the actual recovery/access procedure step by step: log into the Proxmox web UI (root credentials provided), select and start the Oracle VM from the console if it isn't already running, then reach the application's web frontend on a specific port found via `netstat -antp` on the guest (in this case landing on port 9000, one of several Java service ports tried) using the client's own application login. Confirms VM specs (2 vCPU, 8GB RAM) via the Proxmox hardware/summary tabs. This is a narrow, single-purpose recording -- its only content is how to locate, start, and reach this one P2V'd Oracle database VM in an emergency, not general Beetel infrastructure (which is covered in the separate "Beetel Project" and "Beetle KT" videos).