Training 2022 Linux team/

Training on Mail Sending & Receving Problem & Bouncing Problem Part-1 . Dated 01 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Training Sending,Recieveing Bouncing part1" -- a clear, well-structured English-language training session on the methodology for diagnosing mail sending/receiving/bouncing issues, using SysNet Global as a running example. The central teaching point: a support engineer should NOT jump straight to logging into the server -- first understand exactly what the customer is reporting (not receiving mail vs. sending bounces vs. sent-but-not-received-and-not-bounced are three different problems needing different investigation paths) and understand how mail is supposed to flow for that specific domain, since 40-60% of issues can be diagnosed or at least narrowed down without ever logging in. Walks through the actual discovery process: use `host`/`nslookup` (both Linux and Windows CMD demonstrated) or a tool like MXToolbox to find a domain's MX record and confirm where mail is actually supposed to land; check whether port 25 (SMTP) on that mail server is even reachable via telnet, since a dead SMTP port typically means the whole world can't reach that server (a different problem shape than one-off delivery failures); and cross-check by asking the customer to test sending to an external address like Gmail to isolate whether the problem is inbound-only, outbound-only, or both. Only once external factors (DNS/MX/port reachability) are ruled out does the engineer log into the server itself -- at which point the priority is knowing what platform is running (Zimbra/Postfix account for the large majority of environments, with a small remainder split between Kloxo -- a free cPanel-like panel for small/shared customers -- and a handful of consulting-only environments) and reading the relevant logs. Ends mid-session (to be continued in a Part 2) citing time constraints, having covered the discovery/triage methodology but not yet reached the actual server-side log-reading portion.

Training on Mail Sending & Receving Problem & Bouncing Problem Part-2 . Dated 02 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Training Sending,Recieveing Bouncing part2" -- continues directly from Part 1's SysNet Global example, moving from external discovery into actual server-side log reading. Recaps the principle: only log into the server once external checks (MX record, port reachability) confirm the problem is internal. Once logged in, first identify the mail platform running (checking running processes for Postfix vs. Zimbra vs. qmail -- Zimbra always runs on top of Postfix) before touching logs, since Zimbra's Postfix-derived mail log (`/var/log/zimbra.log`, referred to as "mail log") is the key artifact, rotated daily with roughly 4 days retained by default (older logs must be pulled from dated/rotated files if the issue is older). Demonstrates actually searching the log with `grep`/`cat` for a sender domain to confirm mail was received, then explains Zimbra's internal mail-tracing pattern in detail: Postfix accepts an inbound message and assigns it an internal queue/message ID; that message is handed to Amavis (running on the Postfix-Amavis integration, itself wrapping ClamAV for antivirus and SpamAssassin for spam scoring) for antivirus/anti-spam scanning; once Amavis clears the message ("passed clean"), Postfix picks it back up under a *new* message ID (since it now moves to an internal delivery queue) -- so tracing a single email end-to-end in the logs requires following the ID chain from the original SMTP-accepted ID through to this second internal ID; final local delivery happens over Postfix's LMTP protocol on port 7025 into the user's actual mailbox, and once that final "sent via LMTP" line appears for a given message ID, delivery is confirmed successful with nothing further to look for. Notes this Amavis-based two-ID tracing pattern is specific to Zimbra environments; plain Postfix (without Zimbra) doesn't generate this secondary internal queue ID, making its logs comparatively simpler to trace. Explicitly calls this pattern "very critical" and pauses to check the trainees understood it before moving on.

Training on Mail Sending & Receving Problem & Bouncing Problem Part-3 . Dated 03 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Training Sending,Recieveing Bouncing Part3" -- continues the series, shifting from receiving-mail diagnosis to sending-mail diagnosis, which the presenter notes is harder because outbound problems can't be fully diagnosed from outside. Covers checking domain expiry as a first, quick external check for both directions (using `whois` locally or via web tools -- domain expiry is rare but cheap to rule out) and confirming the mail server itself is reachable (ping/traceroute/login) as a sign of whether the issue is DNS/domain-level or server-level. The core topic of this part is Tetra's outbound mail-relay architecture and why it's necessary: many cloud/hosting ISPs (Google Cloud, DigitalOcean, and others) block direct outbound SMTP (ports 25/587/465) to prevent spam abuse, while a few (Linode, AWS) allow it. For platforms that block outbound mail, Tetra runs its own relay servers (built on plain Postfix, not Zimbra) hosted on an ISP that does allow outbound SMTP, and binds them to non-standard, harder-to-block custom ports (e.g. 588, 589) that the client's mail server relays through instead of sending directly -- illustrated with a live diagram of a Zimbra server on GCP (where outbound 25 is blocked) relaying mail out through one of these dedicated relay servers. Notes this relay setup is standard for most of Tetra's hosted mail environments but not universal -- it depends on the specific customer/hosting arrangement, and briefly mentions there are three relay servers in total (consistent with the "server-relay1/2/3" setup described in other Zimbra-architecture videos on this wiki).

Training on Mail Sending & Receving Problem & Bouncing Problem Part-4 . Dated 05 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Training Sending,Recieveing Bouncing part4" -- continues the series, focused on discovering how outbound mail is actually routed for a given customer and diagnosing outbound-specific delivery problems. Demonstrates checking a live Postfix config to see whether a relay host is defined (its presence/absence in the config tells you immediately whether mail leaves the box directly or via one of Tetra's relay servers), using Pahwa as a live example of a client currently routing through Trend Micro's cloud gateway with a known ongoing issue affecting Microsoft-destined mail specifically. Reiterates the ~4-5 day log retention limit on Zimbra's rotated mail logs as a hard constraint on how far back an issue can be traced. Introduces "CBPolicyd" (Postfix's policy daemon) as the mechanism controlling sending restrictions on the relay servers -- covering things like greylisting and per-domain/per-user sending quotas or rate limits -- and explains that a customer hitting an undocumented sending restriction (e.g. exceeding an outbound quota) is a real, if less obvious, cause of "my mail isn't going out" tickets; points to internal wiki documentation covering the relay servers' CBPolicyd deployment for anyone who needs to go deeper on that topic (called out as a separate, more involved topic not covered fully in this session). Session ends with the presenter noting time is up and to continue in the next part, having covered outbound relay discovery and policy-based blocking as the two main outbound-specific diagnostic angles beyond what was already covered in Parts 1-3.

Training on Mail Sending & Receving Problem & Bouncing Problem Part-5 . Dated 07 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Training Sending,Recieveing Bouncing part5" -- shifts to diagnosing actual bounce cases, live, on one of Tetra's real relay servers (`server-relay1.tetrain.com`, confirming there are three relay servers total as mentioned in Part 4). Opens with the retry logic behind Postfix queuing: a failed outbound message isn't simply dropped -- it retries on a roughly logarithmic backoff (e.g. ~6 minutes, then ~30 minutes, then hours, then up to a day later), and the specific error encountered determines how long the next retry waits (a temporarily unavailable server retries soon; a nonexistent domain waits much longer). Demonstrates searching the relay's Postfix mail log for "bounce" and walks through several real bounce cases found live: one where a message triggers a bounce/delivery notification for unclear reasons requiring deeper log tracing by message ID; one where a specific recipient address is explicitly rejected by the receiving mail server (meaning the sender's own admin needs to contact the receiving domain's admin, since the sending side has no control over another domain's rejection policy); and one caused by a missing/incomplete SPF record on the sender's domain -- diagnosed by pulling the domain's TXT/SPF record via MXToolbox and confirming the sending relay server's IP isn't authorized in it, which is why the receiving Gmail-side server rejected the mail as likely spam. Notes bounce causes are numerous and case-specific, and that this topic continues into the next session. Ends mid-topic due to time (session capped at ~30 minutes as usual for this series).

Training on Mail Sending & Receving Problem & Bouncing Problem Part-6 . Dated 08 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Training Sending,Recieveing Bouncing part6" -- continues the bounce-diagnosis series with more live examples (interrupted partway by an unrelated live infrastructure task the presenter was simultaneously monitoring -- a data-sync operation being tracked in parallel). Covers reverse-DNS (PTR) records as another critical factor in deliverability -- checking that a relay server's IP resolves back to the expected hostname, since receiving mail servers commonly reject mail from IPs with missing/mismatched reverse DNS. Walks through an SMTP 554/571 "sender address rejected" bounce for a SysNet Global user, and makes an important diagnostic point: seeing "sender address rejected" from Tetra's own relay server (not the destination server) doesn't just mean that one recipient domain is blocked -- if the sending mail server is configured to route ALL outbound mail through a dedicated relay, then a sender-address rejection at the relay level blocks that user's mail to everywhere, not just the one destination they were testing with, which matters for correctly scoping the ticket. Explains the two-file Postfix relay configuration structure used across Tetra's relay servers: a "network" file whitelisting which IPs are allowed to relay mail through the server, and a sender-restriction file where specific sender addresses can be explicitly listed with `reject` to block them from using the relay (found to be the actual cause of the case being debugged -- the user's address had been deliberately blocked at some earlier point). Also covers reading Postfix's log symbols for identifying bounce/mailer-daemon messages (a message with no outbound queue ID reaching a "mail delivery subsystem"-style sender is characteristically a bounce), an oversized-attachment bounce example, and closes by answering a trainee's question distinguishing CBPolicyd (the milter/policy daemon Tetra primarily uses for quota-style sending limits) from milters more generally, noting CBPolicyd or other milters can also be configured to reject based on content, not just volume, depending on setup.

Training Genral Discussion for Mail Bounce. Dated 09 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Training Genral Discussion for Mail Bounce" -- a wrap-up/general-discussion session for the bounce-diagnosis series, working through several real support-ticket examples pulled live from the presenter's mailbox. Opens with a client-specific policy note: a client called "GoodLife" is the sole exception permitted to use IMAP (allowed because they carry very large mailboxes, up to ~70GB) while every other customer ("MotorCorp" and others) must be configured on POP3 with a 15-day server-side retention limit -- a useful concrete policy to know before troubleshooting a client's mail-client configuration complaints. Walks through several real bounce/undelivered-mail tickets and how to reason about each: a "triple bounce" case traced to a customer's own script/PHP code failing to send correctly (requiring back-and-forth log correlation between the customer's app logs and Tetra's server logs, since the fault could be on either side); a case where the *receiving* server explicitly denies mail by policy (meaning the customer needs to be told to contact the recipient's admin, since Tetra's side has no control over another organization's denial policy); a case where Outlook itself reports the sending error, meaning the diagnostic path is straight to Zimbra's own logs to find the real underlying cause (possibly a Zimbra/Postfix-level CBPolicyd restriction misconfigured for that domain); and a broader "mail bouncing from all domains" case root-caused to the customer changing their router/outgoing IP without notifying Tetra, so the new IP wasn't allow-listed on Tetra's relay servers -- fixed live by adding the new IP to the relay's Postfix "networks" allow-list file and re-running `postmap`, with the presenter stressing that customers changing their outbound IP without notice is a recurring, easily preventable cause of sudden full-domain bounce issues.

Training SSLCertificate Training Part 1. Dated 10 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [VERY POOR TRANSCRIPT QUALITY - largely unusable ASR output, filled with recurring nonsense "subscribe" filler phrases] "SSLCertificate Training Part 1" -- an SSL certificate fundamentals training session. Legible fragments cover self-signed vs. commercial certificates, browser-enforced maximum certificate validity periods (mentioning a 3-year cap), and a News Nation certificate-application example. Given the severity of the transcription failure, no reliable detailed summary of the actual deployment steps can be produced.

Training SSLCertificate Training Part 2. Dated 11 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: "SSLCertificate Training Part 2" -- a clear English-language session on commercial SSL certificate generation and deployment, contrasted with the Let's Encrypt process covered in an earlier (unrecorded or untranscribed) session. Explains that every certificate is one of three types: domain-specific, wildcard (e.g. `*.tetrain.com`, valid for any subdomain), or the much rarer IP-based certificate, and that mismatched domains/certs produce browser "not certified" warnings. Walks through the commercial issuance flow using real client examples (CareIndia, News Nation): generate a CSR (Certificate Signing Request) either via a vendor's web portal or with OpenSSL locally, submitting identifying details (common name = the domain, organization, country, state, city); a CSR always generates a paired private key that must be preserved exactly -- regenerating the CSR changes the key and invalidates any certificate already tied to it, which is why the presenter deliberately avoids re-generating one mid-demo. Covers domain-ownership verification methods vendors use before issuing (hosting a verification file/key on the site, or emailing the domain's registered admin contact for click-to-approve), and that a completed order returns multiple files -- the actual domain certificate, plus intermediate and root certificates that must be chained together correctly on deployment (matching the `chain.crt` + main cert pattern used in the team's Let's Encrypt process). Distinguishes Zimbra's admin-console CSR generator (used only to *generate/request* a certificate, since Zimbra's UI doesn't understand automated ACME renewal the way an Apache/Nginx site can) from `certbot`, which Tetra uses only in "get cert" (not full install) mode against Zimbra since Zimbra isn't a web server Certbot recognizes -- versus a plain Apache/Nginx-backed site (demoed on Beetel's server), where Certbot can both obtain and fully deploy the certificate automatically. Ends by assigning homework: come prepared for the next session to deploy a commercial certificate manually on Apache (matching cert, key, and intermediate cert), with the presenter stressing self-directed exploration as essential for Linux administration skill-building.

Training On Engineers queries. Dated 14 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [VERY POOR TRANSCRIPT QUALITY - largely unusable ASR output, same gibberish pattern as several other recordings in this training archive] "Training On Engineers queries" -- a Q&A-style session answering engineer questions, per the title. Legible fragments touch on WHOIS domain lookups (checking domain registration/ownership info), cron jobs, and a specific mail-delivery ticket discussion. Given the severity of the transcription failure, no reliable detailed summary of the questions/answers can be produced.

Training On Letsencrypt SSL Certificate renewal for Apache Server for Beetelcsd in. Dated 15 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [SPARSE TRANSCRIPT - long stretches of silence/background music] "Letsencrypt SSL Certificate renewal for Apache Server for Beetelcsd in" -- a hands-on Let's Encrypt/Certbot certificate renewal walkthrough for Beetel's CSD Apache-based site, following up on the SSL Certificate Training series. The legible portion shows the renewal running into an issue where nothing could reach the server on port 443, traced to the server's own iptables firewall blocking traffic -- the presenter checks the INPUT/OUTPUT chain policies to diagnose whether inbound HTTPS or outbound validation traffic (or both) was being blocked, consistent with the earlier training's point that Certbot's automated flow can fail for reasons unrelated to the certificate itself (like a firewall) and needs manual troubleshooting when it does. Given the sparse transcript, the specific fix applied could not be reliably captured.

Training On Commercial SSL Certificate Deployment for zimbra for Customer Jacob Ballas. Dated 15 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [MIXED/PARTIAL TRANSCRIPT QUALITY - first ~5 minutes is unusable gibberish filler, remainder is legible] "Commercial SSL Certificate Deployment for zimbra for Customer Jacob Ballas" -- a hands-on commercial certificate deployment for client Jacob Ballas's Zimbra server. The legible portion shows the deployment being complicated by discovering the server is running a very old, end-of-life Zimbra version (8.6, several major versions behind the 8.7/9.0 series current at the time), which the presenter flags as a real security concern -- an outdated web-facing portal being a plausible attack vector -- and states that a version upgrade is a prerequisite before the certificate work can safely proceed, since the current version is past its supported line. The recording then shows Zimbra services being restarted/brought back up after applying changes. Given the transcript quality, the exact upgrade or certificate-application commands used could not be reliably captured.

Training Zimbra Mail Backup. Dated 15 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [VERY POOR TRANSCRIPT QUALITY - largely unusable ASR output, same gibberish pattern as several other recordings in this archive] "Training Zimbra Mail Backup" -- per the title, a training session on Zimbra's built-in backup mechanisms (mentioning NetBackup integration for Zimbra Network Edition/professional tiers). Legible fragments touch on basic Linux commands for backup operations, rsync-style copy behavior for incremental/changed files, and general backup fundamentals. Given the severity of the transcription failure, no reliable detailed summary of the actual backup configuration steps can be produced.

Training CapitalBank VA fix and Jakson Archive Piler. Dated 17 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [VERY POOR TRANSCRIPT QUALITY - largely unusable ASR output, same gibberish pattern as several other recordings in this archive] "CapitalBank VA fix and Jakson Archive Piler" -- per the title, a session covering a vulnerability-assessment (VA) remediation for Capital Bank and Jakson's Piler mail-archiving setup. Legible fragments reference checking system/package versions and RPM-based updates (Capital Bank appears to be on an RPM-based OS), and general system checks. Given the severity of the transcription failure, no reliable detailed summary of the specific fixes applied can be produced.

Training Zimbra Cli part 1. Dated 17 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Zimbra Cli Training part1" -- opens by triaging a list of previously-requested training topics against what's already been covered (undelivered mail, backup, certificate renewal all done in earlier sessions), pointing to the internal wiki for a couple of smaller documented topics (adding a new archive account/ID -- explained inline: create the archive user on the archive server, then map it to the corresponding main-server user in the "archivelist" file and run `postmap` so mail starts flowing to the archive automatically) and flagging "server not working" and "new domain configuration" as too generic/out-of-scope to teach as a single topic. Then begins the actual CLI training: explains that while most Zimbra administration can be done via the GUI, CLI is essential for engineers actually managing environments, and introduces `zmprov` as the single most powerful and heavily-used Zimbra CLI command -- capable of managing accounts, calendars, global config, class-of-service, domains, blocked senders, mailbox-level settings, and especially server-level configuration (demonstrated with `zmprov help server`, showing create/delete/modify-server options and inspecting a server's `zimbraMyNetworks` -- the whitelisted IP ranges, by default including `127.0.0.1`/localhost and the server's own IP). Also distinguishes `*ctl` commands (e.g. `zmamavisctl status`, `zmmailboxdctl status`) as service-level start/stop/status controls, one per Zimbra service (MTA, mailbox, Amavis, MySQL running behind the mailbox service, etc.), from `zmprov`'s broader configuration-management role. Session is cut short by a live infrastructure interruption (an SDWAN probe connectivity issue the presenter had to step away to handle) and closes with a plan to continue the `zmprov` deep-dive in the next session.

Training Zimbra Cli part 2. Dated 19 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Zimbra Cli Training part2" -- continues the `zmprov` deep-dive live against a real SysNet Global Zimbra server. Establishes the core naming convention that unlocks the whole command family: the first letter(s) tell you the operation -- `g` = get/query (safe, read-only), `c` = create, `m` = modify, `d` = delete, `sp` = set password -- so `ga` = get all accounts, `ca` = create account, `ga <account>` = get one account's full attribute dump, `am` = modify account, `gs`/`ms` = get/modify server (per-host settings, requires specifying the hostname), `gcf`/`mcf` = get/modify the global config (environment-wide settings, no hostname needed). Demonstrates: listing all accounts (`zmprov ga | wc -l` to count ~4000 accounts) and grepping the output for a specific surname to find matching accounts; reading and then safely (without actually applying) walking through changing a server's MTA relay-host (`zimbraMTArelayhost`) setting via `gs`/`ms`; and inspecting `zimbraMtaMyNetworks`, explaining its security significance -- any IP listed there is fully trusted to relay mail through the server without authentication, so it should only ever contain localhost and the server's own IP, plus rare, deliberate additions for specific non-authenticating applications (each addition requires copying the full existing value, appending the new IP, and re-running the modify command since it's a single space-delimited attribute, not an appendable list). Also shows the equivalent lookup for global SMTP settings via `gcf`/`zimbraSmtpHostname`. Closes by encouraging trainees to build their own personal Zimbra server to practice `zmprov` hands-on, take a live Q&A question about the practical risk of an unauthenticated relay IP (confirming any user, not just a specific account, could send mail from a trusted IP without credentials), and ends with an unrelated live production interruption (the presenter noticing and fixing an unexpected configuration value change on a real server before closing the session).

Training Zimbra Cli part 3. Dated 22 Feb 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [VERY POOR TRANSCRIPT QUALITY - largely unusable ASR output, same gibberish pattern as several other recordings in this archive] "Zimbra Cli Training part3" -- continuation of the zmprov CLI training series. Legible fragments reference the local server config file (holding credentials like the LDAP/root/admin passwords), multiple mailboxes in a multi-server architecture, and a mention of Ordnance Factory Board as an example client. Given the severity of the transcription failure, no reliable detailed summary of the specific commands taught can be produced (see the clearer Parts 1 and 2 of this same series for the bulk of the reliably-captured CLI content).

Training session Tetra team on Isgec samba Nextcloud understanding. Dated 27 Oct 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Training session Tetra team on Isgec samba Nextcloud understanding" -- an architecture-and-handoff training session covering the ISGEC client's multi-platform environment (four platforms total including Zimbra, Samba, and Nextcloud, accessed via a dedicated customer-care VPN), explaining the rationale for the multi-server split as reducing the blast radius of spam/compromise incidents across services. Covers Samba fundamentals: it's a single-box, no-real-"architecture" service used to share files/drives between roughly 100 Windows client machines over a common authenticated share (accessed via a UNC path/IP in Windows Explorer, where each user can only browse into directories they have credentials for -- demonstrated with two named users unable to see each other's private folders); all user/permission/share configuration lives in `smb.conf`; because command-line user management wasn't practical for ISGEC's own staff to operate, Tetra additionally deployed a GUI tool for them to add/remove users themselves. Briefly notes name-service/NIS configuration is notoriously syntax-heavy and error-prone, and that Zimbra installs typically take 2-3 days end-to-end (not the "couple of hours" some expect). Moves into a live walkthrough of ISGEC's single-server Nextcloud instance (a relatively recent migration): demonstrates its Collabora-based real-time online document editing (Excel- and Word-equivalent collaborative documents, no local software install needed) and mobile/desktop client support with automatic user sync from the customer/lab-users directory. Flags a concrete, actionable item live in the session -- the SSL certificate on this Nextcloud instance is set to expire around October 12 and needs renewal, framed explicitly as a process/follow-up issue rather than a technical one ("this isn't about who's technically capable, it's about making sure it gets followed up and done"). Also recaps a previously-resolved real support issue: users of a specific lab application (with ~1.2TB of data) were unable to copy large datasets through Nextcloud, which was diagnosed and fixed by the presenter, with a reference to the original deployment documentation for the lab app's PHP/module prerequisites.

Training With mithlesh GSTN explian. Dated 28 Oct 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [SPARSE TRANSCRIPT - a ~30+ minute recording with very little captioned speech, long stretches of silence/background noise] "With mithlesh GSTN explian" -- an architecture explanation session for the GSTN (government) client's environment, presented to/by Mithlesh. Legible fragments reference roughly 25 services, standard documentation, Windows services, share creation and permissions, logical volume creation, user/AD (Active Directory) management, and CRM status -- consistent with GSTN's Samba-as-AD-replacement architecture described in other training sessions on this wiki (e.g. "Training Session 2021 march 1"). Given how sparse the captioned audio is, no reliable detailed summary of the specific architecture walkthrough can be produced.

Training session Tetra team on Sysnetglobal understanding. Dated 31 Oct 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [NO ACCESS - VIDEO REMOVED] This video has been removed by YouTube entirely for violating YouTube's policy on harassment and bullying. This is distinct from the "private video" cases found elsewhere on this wiki (McFiFCgjdAM and others) -- a removed video cannot be restored by the uploader and the content is permanently gone. No content, transcript, or even a title is retrievable. Whoever owns this wiki page should be aware the embed is not just broken but pointing at content that no longer exists anywhere on YouTube -- worth investigating why a training recording would have triggered this kind of policy removal, and the embed/link should likely be removed from the page rather than repaired.

Training session Tetra team on CDIL understanding. Dated 05 Nov 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [MIXED/PARTIAL TRANSCRIPT QUALITY - patchy throughout with long silent gaps] "Training session Tetra team on CDIL understanding" -- an architecture discovery/handoff session for client CDIL, similar in format to the ISGEC session on this same page. The presenter explains that unlike other clients, CDIL's environment wasn't handed over with documentation -- the team had to independently discover what existed (mail, "Diamond" application, backup setup) rather than being briefed on it, describing this as a first-time situation requiring active reverse-engineering of the architecture rather than a walkthrough of known documentation. Covers a Chandigarh/Shimla dual-location setup (two servers with fixed IPs that can't be changed, one acting as a base/primary server), TetraControl as the monitoring/chat platform used to track this and other environments, and an application running on Tomcat as its backend (traffic hits an Nginx/proxy layer in front, which forwards to Tomcat, rather than users hitting the app server directly). Also touches on a disk-space risk -- a log or data directory at risk of filling up, where clearing it would resolve the space issue but at the cost of taking the affected service down, so it's treated as a last-resort fix rather than routine maintenance. Given how patchy the transcript is throughout, this summary reflects only the clearly identifiable topics, not a complete architecture walkthrough.

Training Spectra Handover with Alok. Dated 05 Nov 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Spectra Handover with Alok" -- a hands-on infrastructure handover for the Spectra client's environment. Opens covering the hosting/instance access basics (credentials, control panel), then a load-balancer troubleshooting scenario: internal access to a service resolves and works correctly (verified by taking web nodes 2 and 3 down in turn and confirming the site still loads, proving the load balancer is actively distributing traffic), but external packets aren't landing -- traced to a DNS mapping issue on the global/public DNS side rather than the internal network, which the presenter walks through live without fully resolving on-camera. The bulk of the session is a detailed PCS (Pacemaker/Corosync) cluster walkthrough with DRBD-backed storage: checking `pcs status` to see which of two nodes is active/online, manually taking a node offline/standby with `pcs node standby` (and back online with `unstandby`, watching DRBD resync progress and timing, ~49 seconds observed for a small dataset), and checking DRBD sync state directly via `/proc/drbd` (states include "Connected" vs "StandAlone," and node roles "Primary"/"Secondary" -- data is only current on the Secondary if it shows fully synced with the Primary). Explains why certain cluster resources are configured with "failure ignore" -- because Pacemaker's default behavior is to fail over the service to the other node on any restart or config-triggered reload, which is undesirable for a brief, expected restart, so failure-ignore prevents an unnecessary cluster shift for these specific resources. Also covers the day-to-day support pattern the client should follow: temporarily disabling/re-enabling a specific cluster resource (`pcs resource disable/enable`) when a service appears stuck, rather than restarting the whole cluster (which can trigger a full failover); a monitoring dashboard the client was given to self-check service/sync status, with a known recurring gap where the client isn't receiving the latest alerts and needs to check manually. Closes by clarifying that the client's monitoring/NMS access needs to be verified with them directly, and to escalate immediately if the client can't see something that should be visible.

Training session Tetra team on TATAELECTRONICS ZIMBRA DLP understanding. Dated 07 Nov 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [PARTIAL TRANSCRIPT - substantial silent/music gaps throughout] "Training session Tetra team on TATAELECTRONICS ZIMBRA DLP understanding" -- an architecture and scope-boundary session for Tata Electronics' Zimbra environment, with a strong emphasis on clarifying what is and isn't Tetra's responsibility. The presenter is explicit that writing or modifying DLP (Data Loss Prevention) policy content itself is out of scope for the team -- that's owned by Amit's team -- and pushes back on the idea of guessing at policy configuration via "Google search," stressing the team should understand and support the environment, not experiment on it. Describes Tata Electronics' architecture: a single Zimbra instance hosted as a VM (likely on VMware), not exposed to the internet and reachable only over a client-controlled secure internal network limited to factory staff -- noted as having diminishing relevance since most day-to-day work is handled through other channels. Covers the DLP solution running on top as a 4-point (or similarly-tiered) Boldon/BB-type add-on, and briefly reviews what a DLP policy conceptually is at a high level. Later in the session, introduces an "FSM" (Affiliate/Field Service Management-type) server and a secondary/primary routing concept relevant to escalation paths. A trainee's live question about whether DRBD-style replication could be reused for a different context ("YouSecure") prompts the presenter to caution that DRBD is a genuinely complex technology that shouldn't be reached for by default, and that NFS, while simpler, is meaningfully slower than proper SAN-based storage -- a reminder that infrastructure choices should match the actual requirement rather than defaulting to what's familiar. Session closes with an unresolved escalation waiting on confirmation from another team member (Yogesh) before the topic can be closed out.

Training session Tetra team on Reachingcriticalwill some kloxo understanding. Dated 09 Nov 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [PARTIAL TRANSCRIPT QUALITY - patchy in places but core content legible] "Training session Tetra team on reachingcriticalwill some kloxo understanding" -- an architecture walkthrough for the "Reaching Critical Will" client, a LAMP-stack website. Explains that the site isn't directly exposed to the internet -- the actual Apache/LAMP service runs on a local, non-public-facing address and is reached only through a proxy layer, demonstrated by contrasting opening the site via its normal domain versus attempting to hit its underlying IP directly. Walks through the Kloxo (free cPanel-alternative) control panel used to manage this and similar small-website hosting accounts, showing how to define/locate a website's configuration in the panel and find its actual backing IP address. Shares root credentials live via chat for the demo environment, and shows checking Apache's actual running configuration directly from the config files as the reliable way to confirm what's serving a given site rather than assuming, since panel entries and reality can drift. Given some transcript gaps, finer procedural detail beyond this overview could not be reliably captured.

Training session Tetra team on Infosys DOP Amanda understanding. Dated 10 Nov 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [PARTIAL TRANSCRIPT QUALITY - some gaps but core content legible] "Training session Tetra team on Infosys DOP Amanda understanding" -- an architecture and handover session for Tetra's long-running relationship with Infosys, specifically the Department of Posts (DOP) project using Amanda backup software. Sets context first: Infosys is a very large, structured organization, so remote access typically isn't available for Infosys-owned environments the way it is with smaller clients -- Tetra has delivered many projects with Infosys over roughly 11-12 years, some now finished and some still ongoing, and for this particular DOP engagement the implementation itself required physical, on-site work in Delhi (near Rajokri Road) because of the department's requirements, even though ongoing support is remote after that. Notes the Income Tax Department is a related/relevant reference program with its own data center presence in Delhi (GK-2 area) -- likely mentioned as an architecturally similar or connected engagement. On Amanda itself: it's the backup solution deployed for DOP, backing up multiple machines from a single data-center (DC) server, with a second environment configured as DR (disaster recovery) alongside the primary DC. The presenter pauses mid-session to check whether formal documentation exists for this deployment before continuing, suggesting institutional documentation for this particular engagement may be incomplete or hard to locate. Given the transcript gaps, deeper Amanda-specific configuration detail beyond this overview could not be reliably captured.

Training session Tetra team on Infosys ITD zimbra understanding. Dated 11 Nov 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [PARTIAL TRANSCRIPT QUALITY - patchy but core content legible] "Training session Tetra team on Infosys ITD zimbra understanding" -- continues directly from the DOP/Amanda session, now covering the Income Tax Department (ITD) side of the Infosys engagement, which runs Zimbra rather than Amanda. Recaps the two Infosys sub-projects side by side (DOP on Amanda backup; ITD on Zimbra) before walking the ITD Zimbra architecture: a DC (data center) with Zimbra 8.8.15 components and a separate DR (disaster recovery) environment that is currently NOT properly replicating -- root-caused to someone having disabled DR-DC replication entirely by mistake, so it isn't functioning until re-enabled/fixed. Notes the architecture as documented is missing a piece around HA/clustering that needs to be reconciled with what's actually deployed, and references comparable documented architectures (e.g. GSTN) as a pattern to check against. Reviews some account details shared with the team (admin/mailbox counts, credentials) and works through an architecture diagram live. Closes with the presenter redirecting a trainee's tangential question about Docker/microservices back on topic, reiterating this session is specifically about understanding this customer's existing multi-server architecture, not a general technology discussion.

Training session Tetra team on some kloxosites Adani understanding. Dated 15 Nov 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [PARTIAL TRANSCRIPT QUALITY - patchy but core content legible] "Training session Tetra team on some kloxosites Adani understanding" -- covers two related small-hosting topics. First, a quick tour of several small websites hosted on Kloxo (mentioning a client like "Rajeev Associates," where both mail and website are hosted together), checking that mail is actually functioning by looking it up externally (e.g. confirming DNS/MX resolves correctly via a Google search-style check) and cross-referencing against a conceptual documentation diagram that notably wasn't part of the original migration paperwork. The larger portion of the session covers Adani's secure access setup: logging into `myadani.com` requires both an email address and a registered mobile number, and critically, actions like accessing a "Security" section trigger a second-factor approval step delivered to a companion mobile app (an RSA-style authenticator) that the user must approve on their phone before the access is granted -- explained as Adani's standard "secure ID" two-factor access model applied to their admin/portal login flow. Given some transcript gaps, finer detail beyond this overview could not be reliably captured.

Training Zimbra Admin Console Training for Apsecuritas. Dated 18 Nov 2022 - Tetra Support Staff - Pappu

Video summary: "Zimbra Admin Console Training for Apsecuritas" -- a client-facing (Apsecuritas) walkthrough of the Zimbra admin console, aimed at teaching the client's own staff which day-to-day tasks they can safely self-serve versus what must go through Tetra. Opens by showing the server console (port 7071) and confirming running Zimbra services from both the OS level and the admin console's own service status view. Covers admin console basics: viewing the Zimbra version, total account and domain counts on the server dashboard, creating a new account (name + password, domain auto-selected), and viewing/managing an existing account's mail directly from the admin console (view mail, reset password). Explicitly draws the boundary for the client: day-to-day account creation/password resets are fine for them to do themselves, but domain-level configuration changes should always be discussed with Tetra first, since self-service misconfiguration at that level has caused difficult mail-recovery incidents before. Walks through the "Manage" section listing all accounts, aliases, and distribution lists on the server, and briefly tours per-server config (Advanced tab, message/index data storage volumes) as read-only informational context rather than something the client should change. Also addresses a few live client questions: acknowledges a slow support-response complaint and commits to the standard 30-minute reply SLA going forward; explains that a case of a domain's own mail getting caught in that same domain's junk filter isn't something fixable from the admin console -- it requires server-level (MTA/filter) investigation, not just whitelisting; and defers questions about installing Zimbra on mobile or configuring third-party mail clients to a follow-up with a colleague (Mukul), promising an email with the procedure.

Training session Tetra team on Infosys ITD ELK understanding. Dated 24 Nov 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Training session Tetra team on Infosys ITD ELK understanding" -- a detailed architecture walkthrough of the Income Tax Department (ITD)'s ELK-based logging platform, part of the same Infosys engagement covered in other sessions on this wiki. Opens with the underlying business rationale: the Income Tax environment generates enormous volumes of application logs across many machines, and reading raw text logs server-by-server has no practical value -- what's needed is a visual, aggregated view of connection counts, server/application performance, data throughput, and error rates across the whole environment, which is exactly what ELK (Elasticsearch/Logstash/Kibana) is for. Explains the cluster's real scale: 2 master nodes plus a large number of additional Elasticsearch/Kibana/Logstash nodes, totaling roughly ~99 machines across three parallel environments -- PDC (a testing/staging predecessor, referred to loosely as "Non-Prod"), a UAT-like environment, and BCP (Business Continuity Planning, i.e. the actual primary/DR production data center pairing) -- with security protocols and single sign-on experimented on first in the pre-prod environments before being promoted to production. Contrasts self-built open-source ELK (where every component -- Filebeat/Logstash shipping, Elasticsearch nodes, Kibana -- must be assembled and wired together manually) against fully-managed cloud logging platforms (e.g. AWS/GCP's built-in equivalents) that ship as a ready-made UI with nothing to build. Walks through ITD's actual deployment documentation live: PDC has 3 master nodes plus dedicated Elasticsearch data machines and a separate log-test machine; installation followed a standard pattern of setting each node's data directory, getting nodes talking to each other, then layering on Kibana with reverse-proxy access in front of the application servers; explains Logstash's per-pipeline configuration (input source, filter, output -- e.g. targeting all three master nodes as Elasticsearch output, indexing rules, multiple parallel pipelines for different log types) and how filters can be written from scratch, found pre-built, or auto-detected via plugins to parse/tag incoming log fields for later visualization. Uses the practical framing that even in a well-organized log stream, an engineer should be able to eyeball raw records and get an intuitive sense of pattern/category (e.g. "which kind of log entries are these, and what do they mean") before formalizing that into filter rules -- and that when in doubt, the right move is to just ask the person who built the original pipeline rather than guess.

Training session Tetra team on Infosys ITD Nagios understanding. Dated 26 Nov 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Training session Tetra team on Infosys ITD Nagios understanding" -- a detailed handover of the ITD monitoring platform built on NagiosXI, covering roughly 1200 devices. Demonstrates the live monitoring web dashboard/console and reviews original architecture documentation. Explains SNMP as the core monitoring protocol -- pulling metrics like traffic, memory, and port status from network devices and storage without needing local agents -- and that "NRPE proxying" (routing monitoring traffic through an intermediary) is only needed for devices not directly network-reachable or on a segmented network, which wasn't required here since ITD's devices were all directly reachable. Covers WMI (Windows Management Interface) as the equivalent mechanism used for Windows hosts. Walks through the range of what's actually monitored: network switches/devices (fan speed, dual power-supply failover status, temperature, per-interface bit/error rates); physical server health via IPMI/BMC-style out-of-band management ports (remote OS install, hardware status, disk/memory failures) on IBM AIX and other platforms; virtualization platforms (VM failure detection, storage consumption, snapshot/backup counts); and Hitachi enterprise storage (capacity, per-volume utilization, disk failure) queried via a dedicated query package rather than plain SNMP. Notes the full onboarding of this many unique device types took roughly 5-6 months of iterative work, and that AIX support specifically required NRPE-based agents rather than SNMP given the platform's specifics (RPM package copied and installed per-client machine, with documented troubleshooting steps for common install errors). Explains the team's standard troubleshooting handoff pattern for network-device monitoring gaps: check the target device output first using a documented reference command/expected-output pair; if no output comes back, escalate to the relevant network team (separate teams typically own switches/routers, firewalls, and other device classes respectively) since a missing SNMP response at that layer isn't something the monitoring team can fix themselves. Closes noting that despite the platform's scale, day-to-day support tickets are rare because the client's own on-site team (named contacts including Sudhanshu and Ashish) handles ground-level operations, with Tetra mainly stepping in for upgrades or platform-level issues.

Training session Tetra team on Safeexpress OBPASS Punjab Noida understanding. Dated 28 Nov 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Training session Tetra team on Safeexpress OBPASS Punjab Noida understanding" -- covers two separate, unrelated projects. First, SafeExpress: a ticket-management LAMP application with a frontend where users log in and generate/view support tickets, and a backend built on a UPI-style internal API for the ticket workflow -- support ownership sits mainly with a colleague (Rakesh) who has the deepest platform knowledge and direct customer contact, so calls on this platform are infrequent and get routed to him. A real past incident is recalled: outbound notification email hit Microsoft 365's default outbound-sending cap (1000 messages/day per account), causing many customer notification emails ("your ticket has been generated") to fail to send during high volume -- resolved by working with the client to raise that limit and tuning based on what the mail logs showed. Second and larger: the OBPASS (Online Building Permission/Approval System) platforms for Punjab and Noida/West Bengal -- a government building-permit approval workflow where an application (e.g. for a house/building in Patiala) routes automatically through the relevant approving authority (e.g. fire department) for review/approval, with multiple government bodies plugged into the same automated routing system. Explains the vendor split: Tetra built the integration/architecture and the overall system routing, while a separate company, Vinjas, built the actual "scrutiny engine" (the core rules/validation logic that checks submitted applications) which plugs into Tetra's architecture. Clarifies scope explicitly: Tetra does NOT manage the underlying infrastructure for this platform (Windows-based) -- support is reactive only, triggered by escalations that come in via a WhatsApp group shared with the client and a partner company (Medha) that also has visibility into both the Punjab and Noida deployments. The application layer is PHP/LAMP-based, built by Tetra's PHP team, with per-client PHP version and module customization handled case-by-case depending on what the original application build required (e.g. serving PHP 7.2 to match what a given deployment was built against, since installing modules independently for a mismatched PHP version won't work). Closes with an open Q&A, noting light attendance (only two trainees present) and encouraging questions be raised immediately rather than saved for later.

Training session Tetra team on PHDCCI RADICO understanding. Dated 29 Nov 2022 - Tetra Support Staff - Biswajit Banerjee

Video summary: [NO ACCESS - VIDEO REMOVED] This video has been removed by YouTube entirely for violating YouTube's policy on harassment and bullying -- same situation as -Oi7OkupzWA elsewhere on this page. No content, transcript, or title is retrievable, and this cannot be fixed by the uploader since the video is permanently gone. The embed/link on the wiki page should likely be removed rather than repaired. Two removals for the same reason on the same "Training_2022_Linux_team" page is worth flagging as a pattern to whoever manages the uploading account.

Training Session OTRS, Wiki & Nagios Monitoring. Dated 03 Dec 2022 - Tetra Support Staff - Alok

Video summary: "Training Session OTRS, Wiki & Nagios Monitoring" -- a practical onboarding session covering three internal tools new team members need to use daily. OTRS (the ticketing tool): explains that client issues arrive via a dedicated support email address and generate tickets automatically; tickets show up in the "Status View" with a ticket number, title, timestamp, and an assigned owner (assignment is done by Pradeep, and each engineer's queue reflects the specific clients they're responsible for -- e.g. HP and Spectra tickets go to whoever owns those accounts); covers the ticket state model in detail -- "New" (just arrived, no work started), "Open" (actively being worked), and "Pending Reminder" (used when work is done on Tetra's side but the ticket is waiting on the client, e.g. for confirmation), stressing that engineers are responsible for moving tickets through these states correctly rather than leaving them stale. Nagios monitoring (the bulk of the session): demonstrates the live dashboard showing ~758 monitored hosts across many clients/servers/cloud locations, with per-host status codes (e.g. "0" meaning no active issue) and per-server service checks (CPU load, disk partition usage, Apache status, SSL certificate expiry, current logged-in users, and service-specific checks like MySQL for database servers or SMTP/IMSVA-Trend-Micro anti-spam status for mail gateways). Explains that these checks are implemented via NRPE plugins -- separate plugins exist per check type (disk, load, database, NTP/ping, swap, etc.), each with configurable warning/critical thresholds (e.g. a "check_users" plugin warning at 5 logged-in users and critical at 10; disk space warning at 20% free, critical at 10%) -- and that adding a new server to monitoring means installing/configuring NRPE on the target host (config typically lives under `/etc` or `/usr/local`), then registering that host as an object on the Nagios server itself with its IP and the correct client "host group" (functioning like a WhatsApp group -- all servers belonging to one client sit together under that client's group). Frames this as foundational knowledge -- new engineers are expected to study what NRPE/NCPA/NSClient plugins exist so they know which one to reach for when asked to monitor a new service type. The Wiki portion of the session's title is not covered in the transcribed content reviewed here (likely addressed in a portion with poor or missing captions).

Training L0 And L1 calls training session Part 01. Dated 15 Dec 2022 - Tetra Support Staff - Varad

Video summary: "L0 And L1 calls training session Part 01" -- a hands-on training session for the most common L0/L1 support call types, walked through live in a Zimbra-style admin panel using Motocorp (Hero MotoCorp) as an example client. Covers: verifying a user's identity/contact details before making changes (checking postal code and other stored contact info against what the caller provides, matching the client's on-file address in Raipur); resetting a user's password when a client has already created one but it needs to be reset -- entering the new password twice and confirming, then separately verifying the reset actually worked by copying a verification link into a pre-built notepad template, pasting in the user's email and password, and confirming login succeeds (troubleshooting a case live where the password initially appeared not to take effect); blocking a mail ID on client request (toggling account status from Active) and creating a new mail ID for a client (entering the ID, pressing Insert/Escape at the right points in the panel flow). Also touches on a related backend step -- after certain account changes, restarting the relevant Zimbra service (Amavis is mentioned specifically) using the appropriate restart command so the change takes effect. Summarizes the four core L0/L1 ticket types covered: create ticket, delete mail ID, block mail ID, and create mail ID (demonstrated for Hero MotoCorp). Ends by telling trainees they'll need to rejoin for a continuation session since this one is wrapping up.

Training L0 And L1 calls training session Part 02. Dated 15 Dec 2022 - Tetra Support Staff - Varad

Video summary: "L0 and L1 training session Part 02" -- continues the L0/L1 call-handling series, working through real ticket examples end to end. Covers CLI-based user management via `zmprov`-style commands: a lookup command to view a client's full account info before making changes, a create-account command (demonstrated creating a marketing address), and setting/resetting a password. Walks through a CareIndia IP-whitelisting ticket: editing a specific two-line section of a config file (never anything below it) to swap out the old whitelisted IP for the new one provided in the ticket, with a strict "always edit exactly the first two lines, proper spacing" convention. Covers postfix relay-domain onboarding for CareIndia: adding a new mail domain/extension into the relay config with correct spacing, then running `postmap` to apply it -- flagged as one of three recurring CareIndia ticket types (alongside the other two just covered) that come in roughly every 8-15 days. Moves into Nagios-adjacent mail-queue management for Hero MotoCorp: checking mail queue status (`postqueue`-style commands) to see counts of active/deferred mail, checking how many messages are stuck pending, and flushing/clearing the queue with the appropriate flush command when messages are stuck -- repeated for a second server ("Relevant") with a much larger queue backlog (37 messages) using the same two-command pattern. Closes with an Arihant Electricals new-mailbox-creation ticket: stresses that when a client's ticket specifies both the mail ID and the desired password, that exact password must be used rather than generating a new one; walks through logging into that client's specific webmail admin URL, creating the account with the client-specified first/last name and password, and verifying the account works by logging in and changing the password via the admin panel as a final confirmation step.

Training session Tetra team on Reachingcriticalwill some kloxo understanding. Tetra Support Staff - Biswajit Banerjee

Video summary: [DUPLICATE CONTENT] This video is byte-for-byte the same recording as HK-WXK5CCeo elsewhere on this wiki -- identical title ("Training session Tetra team on reachingcriticalwill some kloxo understanding") and identical transcript from the opening seconds onward. See the summary for HK-WXK5CCeo for the actual content (Reaching Critical Will client's LAMP website behind a Kloxo-managed proxy). Worth flagging to the page owner as a likely duplicate upload/embed rather than two distinct recordings -- one of the two embeds on this page is probably redundant.

Nagios training session Dated 29 Dec 2022 - Tetra Support Staff - Varad

Video summary: "Nagios training session 29 12 2022" -- a dedicated dashboard-navigation training for the Nagios monitoring platform (complementing the shorter Nagios segment in "Training Session OTRS, Wiki & Nagios Monitoring"). Tours the main views: Hosts (every monitored client/server, with up/down status -- demonstrated live with an actually-down server, "IMSS Tribune"), Host Groups and Hostgroup Grid (per-client server groupings with rolled-up OK/warning/critical/pending counts), and the technical overview dashboard showing totals (~758 services monitored, at the time 1 service in a problem state). Explains what specific alerts mean and how each gets resolved: SSL certificate expiry alerts (checked by domain expiry date, e.g. flagging a domain expiring in ~66 days as not yet urgent versus one expiring next month, escalated to L2 engineers, with a reminder to update the client and remove the domain from the watch list once renewed); root-partition/disk-usage warnings (won't clear until the underlying disk space is actually freed, unlike CPU-load or memory-utilization alerts which are typically transient and self-clear); and the difference between alerts requiring action versus those that just need a 15-minute wait-and-refresh cycle to auto-clear (e.g. temporary load spikes). Demonstrates the mail-queue-clearing workflow live for two named servers -- a relay server ("Relay 2") and Hero MotoCorp's mail server -- explaining that persistent mail-queue-count alerts require logging into that specific server and running a queue-flush command (distinct commands per server/context), unlike other alert types. Also covers reading the graph view for a host (total/down/warning counts visualized over time) and reiterates the standing team norm: any alert encountered should be posted/updated in the team's alert-tracking group as part of the response, not just resolved silently.

Training session on Nagios Alert 07 Feb 2023 - Tetra Support Staff - Alok

Video summary: "Training session on Nagios Alert Tetra Support Staff Alok" -- a focused session on the judgment call behind mail-queue-growth alerts specifically: when a queue-size warning fires but the support engineer on shift doesn't have credentials to log into that particular mail server, the correct move is NOT to guess whether it's normal or a problem -- it's to call the engineer who does have access and ask them to check the actual mail contents. Uses Hero MotoCorp as the running example: it has 3000+ dealer/account recipients, so any single outbound campaign naturally spikes the queue as it fans out to all of them, making a growing queue completely normal there and not something to escalate reflexively. Teaches the actual verification method for engineers who do have access: log into the server and read the queue contents directly to confirm whether messages are genuine business mail or spam, and if genuine, no action is needed even though the count keeps climbing -- but recommends watching the trend for at least 20-30 minutes before concluding it's benign, since a queue that keeps climbing without leveling off is the actual red flag. References a real recent incident as a contrast case: spam sent through one relay mail ID caused a relay server's queue to spike to ~2000+ messages overnight, which was NOT normal and required immediate escalation -- explicitly reasoning that queue growth can't just be assumed harmless, because if it actually is spam, the sending IP risks getting blocklisted by receiving mail providers, which is the real business risk driving the urgency to verify rather than wait.

Training session on Basic qmail training 24 March 2023 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Basic qmail training" -- a clear English-language session explicitly scoped as diagnosis/troubleshooting knowledge, not qmail installation (Tetra doesn't build new qmail environments, but still supports the few legacy ones that exist, plus Kloxo's internal use of qmail). Demonstrates identifying a running qmail environment via `netstat -ntplu` (spotting MySQL, ClamAV, a separate spam-scanning engine, POP3, and port 25/SMTP via `tcpserver` -- notably no IMAP on this particular primitive setup) and `qmailctl stat` to confirm all qmail sub-services are up. Covers the SMTP relay/control-file configuration for outbound mail: a client (HACO India) is shown routing all outbound mail through `server-relay.tetrain.com` via qmail's `smtproutes` control file, where a blank/no-domain entry acts as a catch-all default relay; explains how to safely change which relay server a domain uses (first confirm the new relay server's IP is allow-listed on the target relay, then update the control file) and explicitly warns against changing it reflexively on a single complaint -- if mail were truly going to spam/junk for everyone using that relay, many customers would be reporting it, so an isolated complaint usually means something specific to that one customer, not the shared relay. Walks through qmail's multi-log tracing pattern in detail, paralleling the Zimbra/Postfix tracing training elsewhere on this wiki: SMTP-level connections land in `/var/log/qmail/qmail-smtpd/current` (piped through `tai64nlocal` to get human-readable timestamps); antivirus/spam scanning results appear in the mail log (ClamAV plus the separate spam engine, tagged with spam-score info); and actual delivery status is tracked separately in `qmail-send`'s log, where entries are tagged "local" (delivered to a local/virtual-domain mailbox) or "remote" (relayed onward, typically via the configured relay server's IP) with numeric delivery/message IDs and explicit "delivered"/"bounced" (symbol-marked) outcomes -- e.g. a bounce caused by "no such mailbox." Clarifies virtual-domain handling: a domain not present locally as a virtual domain gets routed remotely rather than delivered locally. Ends with a brief live Q&A confirming the local/remote distinction, before the session is interrupted by an unrelated incoming maintenance-window request for a database downtime window.

Training session on Zimbra8 6 OS centos6 to zimbra8 8 15 RHEL8 migration session1 30 March 2023 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Zimbra8 6 OS centos6 to zimbra8 8 15 RHEL8 migration session1" -- a detailed walkthrough of migrating a Zimbra 8.6 Open Source instance on CentOS 6 to Zimbra Network Edition 8.8.15 on RHEL 8, following Zimbra's official migration documentation closely (explicitly flagged as important since rsync binaries are OS-version-specific -- reusing binaries built for the wrong OS release will break things). Covers the documented flow: confirm backups exist first; on the old server, take an LDAP dump (`slapcat`-equivalent), back up mail/message data, and export it; provision a brand-new target server (rather than in-place upgrading) and run the appropriate Zimbra install/restore process there. Walks through setting the new server's admin/LDAP/MySQL passwords to match the old server's -- pulled directly from the old server's `localconfig.xml`, since matching credentials are required for the LDAP data restore to work. Details the LDAP import itself: stop Zimbra on the new server, back up the existing empty LDAP directory, then import only the actual database content (explicitly skipping config and access-log databases as unnecessary for this migration, unlike a master/master replication setup which would need them) using the previously-exported LDAP dump file, followed by an `ldap-config`/reindex-equivalent structural rebuild step that must exactly match between old and new (any mismatch causes problems) -- this rebuild step being the most time-consuming part of the whole process. Covers the actual mail-data transfer approach: rsync the full mailstore/index directories from old to new server, timing a couple of incremental rsync passes first to estimate how long a final sync will take (recommending doubling the observed time as a safety margin when scheduling the actual cutover window, since some additional work is always needed beyond the raw sync). Also covers practical field-support realities: confirming with the trainee whether remote access to the target site is available before the actual cutover, since at least one deployment location has no internet connectivity requiring physical presence. Session closes previewing the next topics -- building a Zimbra cluster and the incremental upgrade path (8.6 to 8.7 first, not straight to 8.8, since intermediate hops are required) -- promising the recording will be shared afterward as a reference alongside hands-on practice.

Training session on Hero forwarding delegated admin 07 April 2023 - Tetra Support Staff - Biswajit Banerjee

Video summary: [NO ACCESS - VIDEO REMOVED] This video has been removed by YouTube entirely for violating YouTube's policy on harassment and bullying -- the third such removal found on this "Training_2022_Linux_team" page (alongside -Oi7OkupzWA and jvQ3KWMbCTU). No content, transcript, or title is retrievable, and this cannot be fixed by re-uploading under the same account necessarily fixing anything -- three strikes on one page for the same policy is a pattern worth investigating with whoever manages the uploading account, since it may put the account itself at risk. The embed/link on the wiki page should be removed rather than repaired.

Training session on SORBS Security admin 05 June 2023 - Tetra Support Staff - Manish Singh

Video summary: "Sorb Security Google Chrome 2023 06 01 16 08 58" -- a business/product overview session on why commercial-grade mail security is necessary, explicitly separate from a technical deep-dive (framed as covering the commercial/administrative angle). Opens with a candid admission: Tetra has lost customers in the past due to not having a strong enough security solution, citing real recurring support calls -- clients like Arihant and HCF calling to get senders blacklisted -- as evidence that basic spam filtering alone isn't enough anymore; modern threats require ATP (Advanced Threat Protection covering phishing and content filtering) on top of traditional antivirus/antispam. Describes Trend Micro's evolution as a case study: their older IMSVA (InterScan Messaging Security Virtual Appliance) product required a dedicated on-prem machine routing mail traffic through it, whereas their newer offering is fully cloud-based -- customers simply point their MX record at Trend's cloud security layer. Covers rough cost comparison to frame the business case: a basic Zimbra-based add-on security layer runs roughly ₹100/mailbox/year at scale (3-4000 users), while dedicated enterprise-grade security gateway solutions (naming "Sorb Security" among ~12 comparable vendors in this space) start around a ₹2000/mailbox minimum, historically positioning them as enterprise-only -- but the presenter notes newer entrants are bringing that cost down significantly as they push into the Indian market. Explains the underlying technology at a high level: these solutions route mail through a sandboxed cloud environment where AI-driven rules analyze the full message context (not just static signature matching) before delivery, with sandboxing specifically defeating novel/zero-day spam techniques that wouldn't be caught by traditional pattern matching.

Training session on Radico Client Training Video - Tetra Support Staff - Alok Singh

Video summary: "Radico Client Training Video" -- a hands-on MySQL master-slave replication architecture walkthrough for the Radico client, run over remote desktop rather than VPN since this client doesn't provide VPN access. Radico's application is a LAMP-style setup (a separate Apache server) with dedicated database servers split across two physical locations, Sitapur and Rampur -- each location runs one MySQL master and one MySQL slave (4 database servers total, 2 pairs). The presenter built the Sitapur pair personally (Rampur's was inherited/pre-existing but functionally identical) and documented the setup on the internal wiki. Explains the replication mechanics: MySQL Community Edition installed on both nodes; the master grants a dedicated replication user/password to the slave; key config values on the master include `server-id` and `gtid_mode`, and GTID (Global Transaction ID) is the mechanism used to verify replication is actually in sync -- checked via `SHOW SLAVE STATUS` on the slave and comparing its GTID reference against the master's `SHOW MASTER STATUS` / executed-GTID-set output, which must match. Config changes (e.g. raising `max_connections` from a default like 500) go in `my.cnf` under the `[mysqld]` section, requiring a MySQL restart to take effect. Explains the operational significance of master-slave (as opposed to master-master, contrasted with the YouSecure architecture covered elsewhere on this wiki): failover here is NOT automatic -- the application server only ever points at the master's IP, so if the master goes down, promoting the slave requires manually and completely shutting down the dead master first, then reassigning its IP to the slave, since the application has no built-in awareness of the slave's existence; this must never be done to a live/running master, only after confirming it's fully down, since two servers simultaneously claiming the master IP would cause serious problems. Contrasts this with a master-master setup (like YouSecure) where both nodes replicate bidirectionally and either can serve as primary behind a load balancer, with automatic failover. Closes confirming Radico's total footprint is 4 database servers (2 master-slave pairs, one per location), with a light aside about the recording being on.

Training session on Carbonio Internal Presentation - Tetra Support Staff - Biswajit Banerjee

Video summary: "Carbonio Internal Presentation" -- a strategic internal presentation introducing Carbonio as Tetra's planned successor to Zimbra Open Source. Sets the business context up front: Zimbra Open Source is effectively end-of-life -- no further binary updates/upgrades are expected from Zimbra, and even where upgrades were technically possible they're no longer straightforward the way they used to be -- so an alternative open-source mail platform is needed. Explains why Carbonio specifically over other open-source alternatives (Group-Office, iRedMail-type platforms mentioned as considered but passed over): Carbonio is built by Zextras, a company that has long built commercial add-ons and enhancements for Zimbra itself (mobile sync, backup tooling, etc. for the open-source edition), so its architecture, CLI (a `zextras`-equivalent to `zmprov`), and overall feel are intentionally very close to Zimbra, minimizing the relearning curve. Notes Carbonio's community edition (CE) comes with a 5-year open-source commitment from Zextras, distinguishing it from a purely commercial-only product, and that after evaluation the platform is judged stable enough to start onboarding real customers, with a concrete plan to migrate Tetra's own Zimbra mail onto Carbonio within about two weeks as an internal pilot, working with the service team through that migration for hands-on familiarity. The bulk of the session is a live demo comparing feature-by-feature against Zimbra: the admin console runs on a different port (6071) with a default `zextras`-named admin account rather than Zimbra's `admin`, but otherwise closely mirrors Zimbra's admin structure -- account creation, domains, Class of Service, global address books, LDAP-based authentication (with the same external LDAP/AD integration options used on real client environments like GSTN), per-user/group mailbox quotas, and a genuinely new capability: a built-in disclaimer/footer editor in the admin UI itself, versus Zimbra where this required CLI work. Covers resource booking (shared meeting rooms/projectors), multi-server architecture support (relevant since most of Tetra's open-source Zimbra deployments are single-server, unlike commercial multi-server setups such as ISGEC's separate MTA/mailbox/LDAP split), storage/data-volume management, and an MTA-monitoring panel (queues, spam/antivirus status, TLS config) that in Zimbra required CLI access. On the user-facing side: near-identical mail composition/attachment flow (including attaching from a server-side drive, not just local files) but with several features built in that Zimbra needed bolted on separately -- integrated chat (vs. Zimbra requiring a separate chat add-on), built-in video/screen-sharing meetings with presence indicators (positioned as a possible internal Zoom alternative), a Zimbra-Drive-equivalent file-sharing feature with mobile support, and native ActiveSync plus first-party mobile and desktop apps (versus Zimbra needing a separately-built ActiveSync server for Outlook-based clients). Session includes some live technical hiccups (screen-share/Zoom glitches) consistent with an unpolished, in-progress internal evaluation rather than a rehearsed product pitch.

Training session on Aadani Pariyojna Traning Video - Tetra Support Staff - Manish Singh

Video summary: "Adani Project Training Video" -- an architecture and support-process handover for Adani's LAMP application. Two identical LAMP servers run in active-passive HA (same credentials on both, automatic failover if one goes down), plus a separate UAT server used for pre-production testing. Explains the primary recurring type of ticket: vulnerability-assessment remediation, where Adani provides a spreadsheet of specific vulnerabilities to close, applied identically to both production servers since they're kept in sync -- gives concrete past examples (disabling TRACE method via config changes, tracking exactly which of several possible methods was used for later reference; renewing an expired SSL certificate on both production servers, keeping notes on the config file paths touched at the time for future reference). Covers login access: reached via a client-provided VPN link and URL, with login requiring approval from a specific person (Rakesh) as an access-control step -- new team members needing access must go through him. Explains the collaboration model for fixes that aren't purely infrastructure-level: some vulnerability findings are developer-side (PHP/application-level) rather than server-level, requiring coordination with the client's own dev team or their assessment vendor's team via a walkthrough meeting to fully understand and properly close an issue rather than guessing. Covers service-restart etiquette: when implementing config changes that require restarting Apache or MySQL, the client should always be told the expected downtime up front (e.g. "Apache restart is roughly 30-40 seconds" or a few minutes for other changes) so they can choose a low-impact time to schedule it, rather than restarting unannounced. Clarifies database ownership: Tetra's own team (naming a colleague, Deepika, who handles the PHP/application side) manages the database directly; database credentials aren't kept readily on hand and need to be requested from her via chat when actually needed for a login.

Training session on Nagios Training Service team part2 03 March 2024 - Tetra Support Staff - Biswajit Banerjee

Video summary: [PARTIAL TRANSCRIPT QUALITY - frequent dropped words/audio glitches throughout, likely a mic/connection issue on the presenter's end; summary reflects the identifiable topic flow] "Nagios Training Service team part2" -- continues directly from a prior Nagios session (recapping NRPE, NSClient, NCPA, and SNMP as the device-onboarding mechanisms already covered). Goes deeper into application-level and platform-level monitoring: using Nagios's built-in Oracle and MySQL database plugins directly rather than building custom checks; monitoring VMware at both the host and guest VM level. Introduces SNMP traps as a concept distinct from the polling-based checks used so far -- a trap is the monitored device proactively pushing an alert (e.g. "I've crossed 80% utilization") to Nagios rather than Nagios polling for it -- but explicitly recommends against using traps in most environments in favor of standard polling, flagging it mainly as something worth understanding conceptually since it may come up in questions. Walks through Nagios's config file structure directly on the server under `/usr/local`: `commands.cfg` for check-command definitions, and separate host/service definition files, with an explicit warning not to hand-edit certain auto-generated config files. Mentions a config/CRM-style ID system used to identify/relate hosts to specific customers. Given the significant transcript quality issues throughout this recording, finer procedural detail beyond this topic outline could not be reliably captured.

Zimbra-Daffodil-Webinar-session 12 Dec 2024 - Tetra Support Staff - Biswajit Banerjee

Video summary: "Zimbra Daffodil Webinar 12 12 2024" -- a ~2-hour public marketing/partner webinar (not an internal training session, unlike most other videos on this page), jointly hosted by Zimbra, Sorb Security, and Tetra Information Services, aimed at prospective customers. Structure: Tetra's Mukul Mahajan opens with company background (established for years, open-source-focused, 24x7 support, partnerships with Red Hat, Elastic, Sorb Security, and a ~10-year Zimbra service partnership) and introduces the panelists -- Biswajit Banerji (Tetra's Technical Director, 30+ years experience, 15+ years in Zimbra specifically), Push Mathur (Zimbra's senior sales engineer for the APAC/India region), Mr. Ban (CEO of Sorb Security, email-security specialist), and Mukul himself. Push Mathur presents Zimbra's product pitch: positioned as a full open-core collaboration suite (mail, calendar, contacts, chat, video conferencing in one interface, not just email), with hundreds of millions of mailboxes deployed across government/education/enterprise/banking customers; a key differentiator is deployment flexibility (on-prem, colocated data center, private/public cloud, or hosted) versus competitors that lock customers into cloud-only; positions Zimbra as lowest total-cost-of-ownership, horizontally scalable without service disruption, and strongly data-sovereign since Zimbra itself never touches or stores customer mail data when self-hosted; covers mobile/MDM support (ActiveSync, remote wipe, corporate-approved-device enforcement) and open APIs enabling third-party integrations. Mr. Ban then presents Sorb Security's email-security product (the same product covered in more technical depth in the separate "Sorb Security" video on this wiki) -- highlighting an anti-phishing approach based on containerized/sandboxed link browsing (so a user can safely click a suspicious link inside an isolated container without actually being able to submit credentials, framed as 100% prevention rather than probabilistic detection) and a "MySpace" self-service portal for end users to release quarantined mail, maintain business continuity if the mail server is down, manage personal allow/block lists, and use AI-assisted features like automatic translation of foreign-language email content -- pitched as enterprise-grade capability at a more accessible price point than established competitors. Biswajit Banerji then covers Tetra's value proposition as the implementation/support partner: extensive migration experience from Google Workspace, Microsoft 365, and other open-source mail platforms onto Zimbra, claiming near-zero-downtime migrations even at multi-million-mailbox, hundreds-of-servers scale, using in-house-built migration tooling. Includes live audience quiz/poll segments and a Q&A collected via chat for a later session. Given the marketing/webinar format and its length, this summary reflects the overall pitch structure and key claims rather than a full transcript of all two hours.

Technology Presentation BB for Eng Onboarding 27 Dec 2024 - Tetra Support Staff - Biswajit Banerjee

Video summary: New-engineer onboarding presentation given by Biswajit Banerjee covering Tetra's company history and full technology breadth (not a client-specific support session like most others). History: founded 1995 by four co-founders (the name "Tetra" = four), spun out of a company called PCL, started in hardware sales and Novell Netware deployments in the pre-internet era, moved into Linux around 1997-98, built early internet/mail/proxy/Samba solutions for client offices, weathered the Y2K migration, and evolved its mail-hosting stack over the years from sendmail to qmail to Postfix/Zimbra (Zimbra since ~2006-07). Second half covers the company's current scope: hybrid Zimbra + Microsoft 365 deployments, ELK and Prometheus/Grafana monitoring, their own in-house CloudStack private-cloud platform (a major current growth focus), Kubernetes/microservices/DevOps work, their OTRS-based "iHelpDesk" ticketing product, document management via Nextcloud/Alfresco, and custom LAMP-based government/enterprise software projects (notably an "online building plan" application used at scale in West Bengal, Punjab, and Haryana, integrating with third-party scrutiny software and pitched internationally). Closes with a client-name overview spanning large enterprises (Adani, ICICI Bank, NTPC) and SIs (Infosys, HP), framed as context for why new engineers need to stay comfortable picking up new technology rather than specializing narrowly.

Take backup on Simple storage (S3) 23 Aug 2025 - Tetra Support Staff - Tushar

Video summary: "Take backup on Simple storage (S3)" -- a hands-on walkthrough of backing up server data (specifically database dumps) to S3-compatible object storage using rclone. Covers the AWS-side prerequisites: creating a dedicated IAM user in AWS IAM with full S3 access, selecting the "third-party tool access" user type (rather than AWS Management Console access) when creating it, and generating that user's access key ID and secret access key for use by rclone. Walks through installing rclone via a curl-downloaded install script, then configuring a named "remote" (visible later via `rclone config show`) pointing at the S3-compatible endpoint -- demonstrated using DigitalOcean-style object storage as one example endpoint, but explicitly generalized: rclone/most S3 clients (including the S3 Browser GUI tool also demoed) support any S3-compatible provider, not just AWS S3 itself, selectable via an account-type dropdown ("Amazon S3" vs "S3 Compatible Storage"), with the connection URL/endpoint and region needing to match the chosen provider. Explains the actual backup command structure: `rclone sync` (not `copy` -- sync mirrors changes to the destination rather than accumulating duplicate copies each run) with the source being a local database dump file/variable and the destination written as `remotename:bucketname/folderpath`; notes the target bucket and folder are auto-created on first run if the third-party access permissions are set correctly, and that bucket names must be globally unique across all of S3 (not just within the account) -- if the sync command doesn't auto-create the bucket, that's a signal the chosen name is already taken elsewhere and needs to change. Covers two important tuning flags used in Tetra's actual backup scripts: retention logic that deletes all but the 7 most recent incremental backups as new ones land (rolling 7-copy retention), and `--tpslimit 5` to rate-limit the client's own outbound API requests (GET/HEAD checks against the bucket) so as not to exceed the storage provider's request-rate limits, which otherwise produces rate-limit errors during sync -- particularly relevant since `sync` (versus plain `copy`) does more existence-checking against the destination and is more prone to hitting this limit. Also briefly demonstrates the equivalent GUI workflow in S3 Browser for managing multiple S3-compatible accounts/credentials side by side.

NIC-CODE update recording session 04 OCT 2025 - Tetra Support Staff - Vinod

Video summary: [NO ACCESS - VIDEO REMOVED] This video has been removed by YouTube for violating YouTube's Terms of Service (a general ToS violation, distinct from the three harassment/bullying removals found elsewhere on this "Training_2022_Linux_team" page -- -Oi7OkupzWA, jvQ3KWMbCTU, and KwKpsjt2x5k). No content, transcript, or title is retrievable. This is the fourth video removal found on this single page, which strongly suggests a systemic problem with the uploading account rather than four unrelated incidents -- worth raising directly with whoever manages that YouTube account, since repeated ToS strikes can put the account itself at risk of suspension, which would take down every other (currently working) video on this and other wiki pages hosted under the same account.