Category:WBOBPASS: Difference between revisions

Training on WBOBPASS Project. Dated 23 Feb 2024 - Tetra Support Staff - Manish Singh[edit]

Video summary: Architecture walkthrough of the West Bengal "OBPASS" (online building-plan approval) government application. Staging is a simple single proxy/single app/single DB server chain. Production is more redundant: two proxy servers behind a load balancer, two application servers (one handling the bulk of traffic, the second more of a standby that can't fully absorb the load alone if the first goes down), and two database servers in a manual master/slave setup (failover to the slave is not automatic -- has to be brought up by hand). A separate Windows "scrutiny" server, connected to both staging and production, receives files pushed from the application during the citizen-facing form-submission flow. Shared document/PDF storage is an NFS mount, synced from the primary to secondary app server by a script whenever a developer changes data. Covers a recent migration of the whole 7-server production estate onto the state government's own "SCI platform" data center (new floating IPs for every server), with the NFS disk's actual mount-point cutover still pending (scheduled for a maintenance window later that night) and a related planned hardware upgrade (RAM/disk) once the state data center processes the request. Briefly mentions NKDA as a related project on the same platform, with its staging server ready but production not yet built.

Training on UDMA-ARCH.. Dated 02 nov 2024 - Tetra Support Staff - Manish Singh[edit]

Video summary: Architecture overview of UDMA (Urban Development & Municipal Affairs), another West Bengal state government application on the same general platform family as OBPASS/NKDA/the upcoming Panchayat project -- all hosted and infrastructure-provisioned by the state's own data center (SDC), with Tetra handling installation and infra-level support only (application-level PHP bugs are a separate PHP team's responsibility). Production architecture: a hardware load balancer in front of two active-active reverse proxy servers sitting in a DMZ zone (deliberately holding no data, so a compromise there can't leak anything), forwarding to two active-active application servers and a master/slave database pair (again, manual failover only) in a protected "MZ" zone -- plus two Windows servers handling form-scrutiny checks and an unused ticketing server built at initial setup but never adopted. Application and database servers share a common NFS-mounted disk for uploaded PDFs/documents. Staging is a simpler single proxy/app/DB LAMP stack. Access to all of it is via the state data center's own VPN (OTP-based, provisioned by a named Tetra contact who liaises with the SDC). Also notes a recent platform migration for these servers from a previous hosting provider onto the current one.