Editing Category:NFC (section)

==Training on NFC Project KT PART 3. Dated 16 Nov 2024 - Tetra Support Staff - Raviraj==

{{#ev:youtube|5dYgl9Sf-D0|640}}

'''Video summary:''' "RAVIRAJ NFC KT 3" -- a detailed, mostly Hindi Q&A-style KT session covering several distinct NFC operational topics. Confirms that NFC-to-NFC mail (e.g. Kota to JTC) stays entirely on the internal gateway and never touches the internet path. Walks through the two ways new mailboxes get created: an automated bash script that interactively prompts for username, mail ID, display name, storage quota tier (2/6/12/18/32 GB), and site (Hyderabad/Kota/JTC), then auto-creates and mounts the matching archive (AR) account for Kota/JTC users -- versus manual creation through the Zimbra admin console (referred to as "GI"), which requires the AR account to be created and mounted by hand afterward. Goes deep on the DRBD replication risk at Kota/JTC: it's active-passive, so if the primary disk fails while the secondary is only partially synced (e.g. 50%), only that synced portion survives -- recovering from a "StandAlone" (out-of-sync) state requires manually disconnecting and reconnecting DRBD to force a resync, with no automatic reverse-sync. By contrast Hyderabad's mailbox cluster is active-active, storing identical data on both nodes in parallel, so this failure mode doesn't apply there. Also covers: checking HAProxy status per site (`systemctl status proxy`) as a first troubleshooting step; SSL certificate deployment on the proxy servers, where three separate cert files are combined into a single `bundle.pem`, the previous bundle is backed up (renamed `.old`) before the new one is deployed, Hyderabad's proxy is the single point where certs are uploaded/renewed (Let's Encrypt for one flow, a purchased commercial cert handed off by the vendor for another) and then synced out to Kota/JTC's proxies, and that RocketChat on this environment uses the same certificate; that antivirus/patch management for the gateway is handled entirely by the vendor, out of Tetra's support scope; domain-based mail routing through the internal gateway versus the internet path, including updating Postfix's `postmap` after adding/renaming a routed domain; and how to rename a user's mailbox/alias (demonstrated with a promoted senior officer's account) so mail to both the old and new address keeps reaching them via an alias pointed at the renamed account. Closes with configuring the three per-site public-circular distribution lists (Hyderabad/Kota/JTC) in the admin console -- setting which specific accounts are permitted to send to each circular list versus the full list of members who receive it.