Category:YOUSECURE
Training on YOUSECURE Project KT PART 1. Dated 19 April 2024 - Tetra Support Staff - Alok Singh[edit]
Video summary: "YOUSECURE Project KT PART 1" -- a Hindi-language architecture walkthrough of the YouSecure hosting environment, drawn on a whiteboard/diagram live during the call. YouSecure runs two parallel environments -- "eSign Production" and "Traditional Production" -- both LAMP-based (Linux/Apache/PHP) with separate MySQL database servers, and every server is deployed as an HA pair (e.g. a primary and an "A" duplicate with adjacent IPs, each with its own paired database). The network is split into a DMZ zone (a 192.168.1.x segment, holding the WAF and external HAProxy) and an MZ/internal zone (a 192.168.2.x segment, holding the internal HAProxy, the four LAMP web servers -- each serving a different client domain in the Traditional environment -- and the database servers), with NAT rules on the firewall exposing the private DMZ IPs to the internet. Request flow: internet -> WAF -> external HAProxy -> internal HAProxy -> the correct backend LAMP server per the HAProxy config's per-domain routing rules -> its paired database. HAProxy is configured for priority/failover order rather than even round-robin -- it sends all traffic to the primary backend and only fails over to the secondary if the primary goes down -- and the two MySQL databases behind each pair stay in sync via master-to-master replication so no data is lost on failover. A separate problem is also covered: because uploaded files (PDFs etc.) land only on whichever LAMP server actually handled the request, and the paired servers aren't otherwise replicated, a failover could leave the secondary server missing files the primary had received. This was solved with a shared NFS server -- both paired LAMP servers mount the same NFS-backed directory (e.g. the upload folder), so either server can read files regardless of which one originally wrote them. The eSign environment mirrors this exact design but with a smaller footprint (essentially one web server instead of four).
Training on YOUSECURE Project KT PART 2. Dated 25 April 2024 - Tetra Support Staff - Alok Singh[edit]
Video summary: "YOUSECURE PART 2a" -- a short, focused Hindi-language KT session walking through the actual HAProxy configuration file referenced in Part 1 (`/etc/haproxy/haproxy.cfg`), shared live on-screen. Explains the frontend/backend structure: the external HAProxy frontend listens on ports 80 and 443 and defines an ACL per website (using short truncated names like "ekyc1" for readability) that matches on the incoming domain and routes to a correspondingly-named backend, with separate 80 (`mode http`) and 443 (`mode tcp`) definitions per site; each of the four Traditional-environment sites (KYC, Video, Sign, and a fourth) has its own backend block listing both paired servers' IPs with `balance first`, so requests always go to server 1 until it's marked down, at which point HAProxy fails over to server 2 -- confirming the priority/failover behavior described in Part 1 rather than even load distribution. Also briefly covers the internal HAProxy's MySQL-facing config, which binds to the HAProxy server's own IP and load-balances (same `balance first` pattern) between the two paired database servers, and notes that NTP is configured on every server for clock synchronization across the environment.
Training on YOUSECURE Project KT PART 3. Dated 25 April 2024 - Tetra Support Staff - Alok Singh[edit]
Video summary: "YOUSECURE PART 2b" -- a continuation of the HAProxy walkthrough, this time live-tailing logs and troubleshooting on the actual servers. Demonstrates using `tail` on the HAProxy log (under `/var/log`) to watch real incoming requests in real time and read the log lines to identify which named backend and which specific server (`srv1`/`srv2`) each request was routed to, confirming the `balance first` failover behavior live -- including what the log looks like when the primary is down and traffic is on the secondary. Moves on to NTP troubleshooting: the internal HAProxy servers (two IPs, one per environment -- Traditional and eSign) double as the NTP servers for their environment's VMs, and a support ticket was caused by some VMs having "NTP connection refused" because the NTP client service wasn't running -- the fix is checking the service status per-VM and starting it, with NTP pool servers pulled from a regional (India) pool defined in the client config. Also revisits the NFS setup in more detail: a `/data` partition with per-service subdirectories (video, KYC, etc.) is exported from the NFS server and mounted onto the equivalent local content directory (e.g. mounting over `/home`) on both paired LAMP servers per site, so uploaded content is visible to whichever server is active. Closes with a tour of the oVirt/RHV-based virtualization platform hosting the whole environment (~38 VMs across separate Traditional and eSign manager consoles), a mention of a master-to-master MySQL replication reference doc, brief pointers to related but out-of-scope docs (Amanda backup software, LVM issues), and a note that email relay (a two-hop relay setup) is also part of the environment. The presenter notes the full YouSecure setup took roughly 4-5 months to build.
[edit]
Video summary: "Signxca DR related training to service team" -- a long (~45+ minute), mixed Hindi/English hands-on training session on the SignXCA disaster-recovery setup, aimed at the service/support team. Opens with the conceptual architecture: the primary datacenter (DC) runs both the eSign and Traditional environments across four oVirt/RHV hosts backed by a shared, partitioned storage array, while the DR site is a smaller, half-capacity mirror (fewer hosts, its own storage) connected to the DC via one-way storage-to-storage replication that gets reversed once a DR drill or real failover ends. A key design point is an L2 network extension between DC and DR, meaning VMs can come up at the DR site with the exact same IPs they had at the DC -- during a real DR event, the DC side is shut down, replication is paused, and the full environment (normally ~200-300 VMs, though DR is provisioned at reduced capacity) is expected to boot at DR unchanged. The session then moves into hands-on DR-drill execution: navigating the oVirt "Disaster Recovery" role, generating the DR configuration file (`dr.conf`) from a template using the manager's API credentials, hostnames, and CA certificate copied from the currently-active site, correcting auto-generated/commented-out fields for the secondary (DR) site, verifying host DNS/hosts-file entries and reachability between manager and target hosts, and applying the resulting Ansible playbook-driven failover. Also covers checking storage/data-domain visibility from the DR-side manager UI and using the `admin@internal` oVirt account for command-line/API operations. The recording includes real troubleshooting back-and-forth (access/OTP issues, a mid-session interruption) rather than a clean scripted demo, consistent with an authentic live training call.
[edit]
Video summary: [LONG RECORDING - ~1hr40min live execution; summary reflects the opening planning/kickoff segment, which sets the pattern for the rest of the call] "SignxCa Ovirt Partial DR DRIL" -- a real-time, unscripted recording of the team actually executing a partial disaster-recovery drill for SignXCA (the live counterpart to the separate DR training/walkthrough video). The team coordinates the drill live over call: take backups first, then shut down all VMs across both the Traditional and eSign production environments, and only then update DNS to point at the DR site -- deliberately keeping replication running until each VM is powered off so the final in-flight data is captured before cutover (explicitly distinguishing this from a snapshot, which only captures data up to the moment it's taken). One VM (the hosted engine, running a CRL service) is intentionally kept online longer than the rest. Roles are split between people physically at the DC and at the DR site, with instructions to screenshot each VM's shutdown status for an audit trail of what was on/off and when. The recording captures real coordination overhead (confirming who has DR access, chasing down team members, an aside about a previous long-running migration where staff pulled an all-nighter) rather than a clean procedural walkthrough -- consistent with genuine operational drill footage rather than a rehearsed demo.