Category:NFC: Difference between revisions

Training on NFC Project KT PART 1. Dated 13 Nov 2024 - Tetra Support Staff - Narendra Chall[edit]

Video summary: "Narendra NFC KT 1" -- an English-language KT session covering the NFC (National Fertilizers Corp-type client) Zimbra mail environment, deployed at three locations: Hyderabad, Kota, and JTC, migrated from Rediffmail to Zimbra Network Edition 10.0.0.2. Incoming mail flow is: KSMG (a secure mail gateway that applies spam/allow-block rules and can bounce mail) -> IMSVA (Trend Micro InterScan Messaging Security Virtual Appliance, doing further per-IP/domain/account filtering) -> a Postfix daemon pair -> the MTA -> the destination mailbox; every user also has a separate archive (AR) account that a linked archive server populates for all in/outbound mail. Hyderabad runs four physical servers -- two paired mailbox/MTA/proxy servers (PCS cluster + fencing, so the standby takes over automatically if the active one fails), a shared pair of NAS storage boxes (primary/secondary) behind them, a dedicated AR server, and an internal mail gateway serving ~18-20 internal domains (with manual internet-relay as a fallback if that gateway fails). Kota and JTC mirror this setup but use DRBD replication instead of PCS/NAS, which the presenter flags as the single most important thing to monitor: DRBD sync must be checked daily, since if the primary fails while sync is only partially complete (e.g. 60%), the un-synced portion of data is permanently lost on failover. All outbound internet mail from Kota/JTC users must route through the Hyderabad MTA hub -- intra-site mail doesn't need this. Mailbox sizing (Class of Service) is tied to employee designation/grade (e.g. 2GB/7GB/12GB/18GB tiers), and user creation is scripted to auto-provision the matching archive account and notify designated stakeholders. Common support scenarios covered: 90-day mandatory password rotation and reset requests, a 30MB outbound attachment size cap, password-protected PDFs being blocked/bounced on delivery (unprotected PDFs pass), mailbox quota checks for "can't send mail" tickets, and a protected "public circular" dynamic distribution-list folder that only one admin account can modify.

Training on NFC Project KT PART 2. Dated 16 Nov 2024 - Tetra Support Staff - Raviraj[edit]

Video summary: "RAVIRAJ NFC KT 2" -- continues the NFC KT series with a support/operations-focused walkthrough. Covers the two Zimbra webmail clients NFC users may be on (Classic and Modern) and why it matters to ask which one a caller is using before troubleshooting; per-site public-circular distribution lists (Hyderabad, Kota, JTC); a two-tier attachment policy enforced via mail transport groups -- "Group One Transport" permits attachments, "Group Two Transport" (assigned by officer designation) does not -- plus separate sender restrictions that limit some users to internal-only mail. Describes the KVM-virtualized server layout per site (each physical/base machine hosts a paired mailbox/MTA/LDAP/proxy set) and the failover model: connectivity or load issues trigger automatic cluster failover to the secondary node, but a mailbox-specific problem requires a manual cluster shift; console access via the KVM host's URL is the fallback when SSH/PuTTY access fails, and if even the console doesn't respond the VM must be power-cycled. Notes an important operating constraint: NFC (a central government client) does not permit any remote login access to their environment -- support is done by walking NFC staff through fixes verbally on calls rather than connecting directly. Covers day-to-day troubleshooting patterns: slow mail delivery caused by a full mailbox quota; users' archive mount getting incorrectly pointed at another site's archive server (checked/fixed via `zmmailbox` commands to unmount and remount correctly); the full outside-to-inside mail path (KSMG -> IMSVA -> Postfix -> MTA -> mailbox) and where to check first when external mail isn't arriving, including manually releasing genuine mail that IMSVA quarantines as unscanned/spam (safe to release, and released mail doesn't get re-quarantined); and daily DRBD replication-status checks required only at Kota and JTC (which use active-passive DRBD replication), since Hyderabad's mailbox setup is active-active and doesn't need this check.

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

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.

Training on NFC Project KT Final. Dated 06 Dec 2024 - Tetra Support Staff - Raviraj[edit]

Video summary: "RAVIRAJ NFC KT FINAL" -- the wrap-up session of the NFC KT series, re-walking the full mail architecture (KSMG -> IMSVA -> Postfix -> MTA -> mailbox for inbound; the reverse for outbound) and the KVM base-machine layout at each site (JTC and Kota each run 3 base machines -- two paired MTA/LDAP/mailbox/proxy nodes plus a dedicated archive/AR machine; Hyderabad separates internet-facing servers, KSMG/IMSVA/Postfix, from intranet servers including a RocketChat VM), before going deeper into day-to-day maintenance procedures than the earlier KT videos. Explains the manual PCS cluster failover procedure step by step: check cluster status to see which node (mailbox1/mailbox2) is currently live and confirm both nodes are online, then standby the active node and un-standby the other to force a controlled switch -- only done in response to a real connectivity/overload issue, not routinely. Covers the DA-domain bypass procedure: if NFC's local email gateway can't reach a particular DA (government) domain, editing Postfix's transport config to comment out that domain's local-gateway routing so mail for it goes via the internet path (IMSVA) instead. Reiterates the with-attachment/without-attachment/internal-only sender group model and the DRBD up-to-date-disk check that only applies at JTC/Kota (not Hyderabad, which is active-active NAS replication). Adds new maintenance detail: daily ClamAV signature updates (main.cvd, bytecode.cvd, daily.cvd) pushed via script to the MTA antivirus scanning layer across all three sites, and confirms SSL certificates and RocketChat are both maintained without downtime as part of routine operations. Functions as a consolidated review/summary of the architecture and procedures already covered piecemeal in the earlier NFC KT videos, rather than introducing an unrelated topic.