Postfix is good at retrying mail on its own, but over time a busy server collects two kinds of junk in its spool: messages that have been deferred for days and will never deliver, and partial or misplaced files left behind by a crash or an abrupt restart. This guide sets up a safe, scheduled cleanup for both — using Postfix's own tools, not manual file surgery.
Having two MX hosts is not the same as knowing failover works. The only way to trust it is to test it: confirm both hosts answer on port 25 and accept mail for your domain, and once in a while prove that when the primary is down, the secondary still takes the message and holds it. This guide gives you a small probe script you can run on a schedule, and a controlled live drill for the real thing.
CISA added CVE-2026-60004 , described as a Gitea code injection vulnerability, to its Known Exploited Vulnerabilities catalog on 25 August 2026. The KEV listing is the important part: CISA doesn't add things to that catalog on theory. It adds them when there's evidence of active exploitation in the wild. So this isn't "a bug was disclosed" — it's "somebody is using this against real servers right now."
This script reads your Postfix relay-control settings with postconf and flags configurations that could let outsiders relay mail through your server — the classic "open relay" that gets you onto blocklists and turns your box into a spam cannon. It is read-only. It changes nothing, writes nothing, and reloads nothing , so there is no config to back up and nothing to roll back. It simply reports.
This guide sets up a small bash script, run on a schedule, that reads the resident memory (RSS) of every process inside the dovecot.service cgroup and warns you when one crosses a threshold you set. It only reads and reports — it writes a line to syslog and optionally sends an email. It does not kill processes, change Dovecot config, or touch any mailbox.
Most of the people who read this blog run mail, not print servers, so let me be honest up front: if you don't have PaperCut NG or MF anywhere in your estate, you can close this tab. But a lot of us run it next to the mail infrastructure — it's the thing that meters departmental printing and holds scanned documents — and the way this one broke is worth understanding even if you're patched, because it rhymes with problems we already know from Zimbra.
This sets up a weekly job that walks your Maildir tree, computes a SHA-256 for every message file, and compares this week's checksums against last week's to catch silent corruption (bit rot, a bad disk, a botched restore) in files that should never have changed once written.
This guide builds a Python tool that looks up the _dmarc.<domain> TXT record for one or more domains, parses it, and reports where the DMARC policy is missing, malformed, or weaker than the baseline you set. In its default form it only reads DNS — it changes nothing. The optional second half pushes a corrected record through a DNS provider API (I use Cloudflare as the concrete example).
This guide gives you a small Python 3 script that reads Postfix's delivery log lines, extracts the recipient domain and the delivery status ( sent , bounced , deferred , etc.) from each line, and prints a per-domain, per-day count as CSV so you can spot volume trends. It is read-only : it opens log files, counts lines, and writes nothing back to the system. It does not touch Postfix, the queue, or the logs themselves.
Two big enforcement stories broke on the same day, and both are worth reading, but neither is the thing that should change what you do this week. Help Net Security reported that the DOJ and FBI seized the infrastructure behind QScan and QTRouter , a pair of tools a Nanjing-linked outfit called QTFY used to build an obfuscation network out of hijacked IoT devices — the kind of story where NASA, the Federal Reserve and the U.S. Senate turn up on the victim list. Separately, Australian police, working with the FBI, arrested two men alleged to be part of TeamPCP , the crew that cloned the Shai-Hulud worm and poisoned open-source packages to harvest credentials at scale.
A backup you have never restored is a hope, not a backup. The cheapest way to turn hope into evidence is to restore something small on a schedule and check it landed. Here I restore one sample Maildir from the latest snapshot into a throwaway directory, confirm it looks like a real mailbox, log the result, and clean up. Run it weekly and you will know your mail backups are restorable before the day you need them.
This is a read-and-report job. It runs doveadm quota get to list every mail user's quota usage, picks out the ones over a percentage you set, and emails you a summary. It does not change quotas, delete mail, or touch mailboxes — nothing here is destructive.
When systemd hands a listening socket to a service, the kernel keeps completed connections in an accept queue until the service calls accept() on them. If the service falls behind — thread-starved, blocked on a slow database, whatever — that queue fills. Past the socket's backlog it silently drops or refuses connections. This guide sets up a small, read-only monitor that watches the accept-queue depth on your listening sockets and raises an alert before you hit that wall.
This guide gives you a small bash script that rebuilds a Postfix transport map from its flat-file source, validates the configuration, and reloads Postfix so the new routing takes effect. postfix reload re-reads configuration and recycles daemons gracefully — it does not drop in-flight SMTP connections or stop the queue, which is why we use it instead of restart .
On 21 August 2026 Canonical pushed out a broad set of kernel security notices, and threaded through most of them is one identifier: CVE-2026-64531 , nicknamed OVSwrap , an Open vSwitch flaw in the Linux kernel that leads to local root. The oss-security post that carries the name declines AI crawlers , so I only have its subject line to confirm the classification — Linux kernel / OVS, local privilege escalation. The details of the write-up I can't quote, and won't guess at.
This script is a read-only audit . It walks your virtual mailbox tree and a couple of mail config directories and reports three things: mailbox files or directories that are readable or writable by group/other, mailbox files not owned by the expected mail user, config files that contain secrets but aren't locked down, and the service account's login shell. It changes nothing — no chmod , no chown , no account edits. Remediation is a separate, manual step at the end that you run deliberately, one finding at a time.
This guide gives you a read-only Python script that parses a Postfix mail log and reports two things: authenticated senders (SASL users) who sent an unusually large number of messages or recipients — the classic signature of a compromised mailbox being used to blast spam — and source IPs that keep tripping "Relay access denied", which is relay probing. The script does not change anything : it reads the log, counts, and prints a report. It never touches Postfix config, never disables an account, never blocks an IP.
This guide sets up a read-only pull of the firewall's config.xml to a separate Linux host, scheduled nightly with cron, so you have off-box, dated copies of every configuration. The backup script itself never writes to the firewall — it only copies one file off it over SSH.
The script below reads an X.509 certificate and prints a TLSA record . That is all it does: it computes a SHA-256 hash of the certificate's public key and formats it as a DNS TLSA resource record you can paste into your zone. It changes nothing on the machine, and it needs no elevated privileges — except that if your certificate file is only readable by root you will need sudo to read it.
This sets up a weekly, unattended package upgrade on each server, then emails you a plain-text report of what was upgraded and whether a reboot is now pending. The upgrade step runs apt-get upgrade non-interactively, so it changes installed software on the host. Package upgrades are not cleanly reversible: apt has no "undo the last upgrade" button, so treat this with the same caution as any change to a running server.
This is a small bash wrapper that reads a list of hostnames from a file and runs the same command on all of them over SSH, several at a time in parallel , tagging every line of output with the host it came from. The purpose is to save you from looping through servers by hand when you want to check a value, restart a service, or gather a fact fleet-wide.
This guide sets up an automated, repeatable scan of the TLS protocols and cipher suites your own services advertise — the sort of thing you'd otherwise do by hand before a PCI review or after a config change. It uses testssl.sh , a widely-used bash script that connects to a service and negotiates handshakes to see what's on offer (TLS 1.0–1.3, weak ciphers, known issues like ROBOT/BEAST reporting, cert details).
A full disk is one of those failures that takes half your services down at once — the mail queue stops, the database goes read-only, journald starts dropping entries — and it almost always announces itself in advance as a slowly climbing df percentage. This guide sets up a small, boring watchdog that checks free space and the biggest offenders under your log directories, then emails you before the disk is full instead of after.
This guide pushes a name-resolution change — either a static entry in /etc/hosts or an upstream DNS server change — to a group of servers at once using Ansible. Getting name resolution wrong across a fleet is one of the fastest ways to take down a whole environment: a bad /etc/hosts line or a dead DNS server means services can't find each other, monitoring goes dark, and package mirrors and time sync stop working.
A use-after-free landed on oss-security this week as CVE-2026-64564 , in the Linux kernel's SCTP code — specifically the ASCONF transport handling. The advisory and a follow-up describe it as local privilege escalation and container escape. Those two phrases are what make people forward a CVE to their whole team on a Friday, so it's worth stopping to ask what it actually means for the machines this blog is about: Postfix relays, Dovecot backends, Zimbra boxes, iRedMail stacks.
This is a read-only reporting script . It reads your Postfix/Dovecot mail log and your Fail2ban log, extracts the source IPs behind SMTP SASL failures, Postfix rejects and Dovecot auth failures, cross-references them against the IPs Fail2ban actually banned, and prints one ranked summary. It does not touch your firewall, your jails, your mail queue, or any config. There is nothing to undo except deleting the report file and removing the cron entry you add at the end.
This guide builds a small bash script that pings a fixed list of hosts on a schedule, records latency and packet loss to a CSV file, and optionally measures throughput to a host you control. It is read-only from a system-configuration standpoint : it changes no firewall rule, route, or setting. It only sends test traffic and appends lines to a log file.
This guide installs Sanoid and configures it to take ZFS snapshots on a schedule (hourly, daily, monthly) and to automatically destroy snapshots older than the retention you set. Snapshots are your cheap, instant, on-box rollback points; the pruning half is what stops them from filling the pool forever.
This guide builds a single bash script that takes a read-only snapshot of a server's security posture — logged-in users, listening sockets, running services, UID 0 accounts, the effective SSH config, pending updates, SUID/SGID binaries, and world-writable files — and writes it to a timestamped text file. It inspects and records; it never edits config, kills processes, changes permissions, or installs anything.
This script applies one literal find-and-replace across every zone file in a directory (for example, retiring an old IP or NS name), bumps each changed zone's SOA serial so slaves pick up the change, validates every touched zone, and reloads BIND only if all of them pass . If any zone fails validation it restores the backups and aborts before touching the running server.
This guide sets up a dead man's switch for a cron job: the job pings an external monitor every time it runs, and if that ping is late or reports a non-zero exit, the monitor pages you. It exists to catch the failure mode plain cron misses entirely — a job that silently never ran , or ran and failed on a box whose mail is broken.
CISA put two WordPress core flaws into its Known Exploited Vulnerabilities catalogue on 21 July, alongside a DD-WRT overflow and a Langflow bug. The pair that matters here — CVE-2026-63030 and CVE-2026-60137, chained under the name wp2shell — gives an anonymous attacker remote code execution against a stock WordPress install with a single HTTP request. No login, no plugin, no theme required. By the reporting in The Hacker News, exploitation was underway within hours of the public proof-of-concept, and watchTowr's honeypots logged tens of thousands of attempts.
This script runs a series of read-only and send checks against a mail domain you control: it looks up MX, SPF, DKIM, and DMARC records with dig , tests the STARTTLS handshake on the submission port with openssl , and then sends one real test message through your server with swaks . Its purpose is to confirm, in one pass, that mail for your domain is configured to leave and arrive correctly.
A bond only earns its keep when a NIC or switch port dies and nobody notices — because the traffic kept flowing on the surviving link. The failure mode I care about is the silent one: you lose a slave, run degraded for three weeks, then lose the second one and take an outage that looks instant but was really two failures spread over a month. This guide sets up a small, read-only script on a systemd timer that watches your bond and shouts when a slave goes down.
This sets up a background service that watches a directory and, whenever a new JPEG or PNG lands there, produces a resized, stripped, and re-compressed copy in a separate output directory. Its purpose is to keep uploaded or generated images small and consistent without anyone running a command by hand.
Ubuntu and Debian both shipped a Samba fix on 28 July 2026 — USN-8621-1 on the Ubuntu side, DSA-6401-1 on Debian's. It's a fat advisory: eight CVEs in one go. But counting CVEs is the wrong way to read it. Seven of the eight are denial-of-service, and exactly one of them is the reason you should stop reading and go patch.
I like knowing exactly what changed under /etc and when — after a package upgrade, after I "just tweaked one thing," after someone else touched a box. A nightly git snapshot gives me a dated, diffable trail I can read with git log and git diff . It is not a substitute for real config management, but it is cheap, honest history.
This guide configures systemd to automatically restart a service when it fails, with an increasing delay between attempts (backoff), and to fire an alert when it exhausts its retries and stays down. Nothing here touches your application's data — it only changes how systemd supervises the unit — but a badly tuned restart loop can hammer CPU, disk, or an upstream database by relaunching a broken process over and over, so treat the values as production settings, not guesses.
Two things landed on the same day, 28 July 2026, and it's worth being clear about which one you can act on.
This is a bash script that offboards a single local Linux user on a standalone server: it locks the account, expires it so no login (password or key) succeeds, kills any live sessions, backs up the user's crontab, disables their SSH authorized_keys , and archives their home directory to a tarball. It does not delete the account or the home directory — removal is left as a deliberate, manual step so you have an undo path.
This playbook installs Postfix on one or more target hosts and configures it as a send-only relay (a "smarthost" client) : local mail is handed to an upstream provider over an authenticated, TLS-encrypted SMTP submission connection, and the host does not accept mail from the network. Its purpose is to give servers a reliable way to send notifications, cron output, and application mail without each app talking to your provider directly.
If you only read one Linux kernel headline this week it was probably Phoronix noting that 7.2-rc5 fixes a longstanding bug in IPv4 over FireWire . File that under trivia. Nobody reading this blog is carrying mail over an IEEE 1394 cable, and it landed in a release candidate anyway. The actual reason to look at your kernel version this week is buried under a mountain of near-identical advisories.
This playbook drops a single sshd configuration file ( /etc/ssh/sshd_config.d/99-hardening.conf ) onto every host in your inventory and reloads the SSH service. It disables root login, disables password authentication, requires public-key auth, and tightens a handful of session and auth limits.
The standard, boring way to block IPs that hammer your mail server is Fail2ban. It watches the mail log, counts matching failures per source IP inside a time window, and when a source crosses a threshold it inserts a firewall rule to drop that IP for a while. You could write a bash script that greps the log and pipes IPs into nft , and I'll say where that fits at the end — but reinventing Fail2ban is more error-prone than configuring it, so that's what this guide does.
Everything in this guide is read-only . The awk , sort , and uniq commands here only read the Nginx access log and print summaries to your terminal — they do not modify, rotate, or delete the log, and they change nothing on the server. There is nothing to undo.
Some services don't crash cleanly. The process stays alive, systemctl still calls it active , but it has stopped answering — a wedged worker pool, a deadlocked thread, a leaked connection table. systemd's own Restart=on-failure handles a process that exits , but it won't help you with one that's technically running and doing nothing. This guide sets up a periodic health check that catches that case, restarts the unit when it's genuinely stuck, and logs every decision so you can prove what happened at 3 a.m.
This guide has two parts. The check part is a read-only script that queries DNS for your published DKIM record and confirms it still matches the private key OpenDKIM signs with — safe to run any time, and safe to put on cron. The renewal part generates a new key under a new selector, has you publish a DNS record, and then switches signing over to it.
This sets up an unattended nightly job that dumps your MySQL/MariaDB databases and tars up a couple of directories, uploads both to an S3-compatible bucket with rclone , and then deletes backups in that bucket older than a retention window. Its purpose is a hands-off off-site copy that prunes itself so the bucket doesn't grow forever.
Okta's Red Team gave this one a name, HollowByte, and named things get attention. What deserves the attention here isn't the trick — it's the paperwork, or rather the lack of it.
Docker hosts fill up quietly. Every docker pull , every CI build, every image rebuild leaves layers behind, and /var/lib/docker grows until a deploy fails with "no space left on device" at the worst possible moment. This guide sets up a scheduled job that prunes unused images older than a threshold you choose, so the host reclaims space on its own without you babysitting it.
This script reads your filesystem and reports two classes of risky files: world-writable files and directories (anyone on the box can modify them) and SUID/SGID binaries (they run with the owner's or group's privileges, often root). It writes a timestamped report and, optionally, a baseline you can diff against later. It does not change any permissions, delete anything, or modify a single file — it only runs find and writes a text report to a directory you choose.
Canonical shipped a batch of Linux kernel security fixes this month, and LWN flagged three stable kernel updates landing upstream in the same window. None of this is dramatic. It is the ordinary heartbeat of running Linux under a mail stack — but "ordinary" still means a reboot, and there are two details worth reading before you schedule one.
This guide sets up two things: a small script that dumps your host's live packet-filter ruleset to a timestamped, versioned file, and a scheduled systemd timer to run it. It also shows the standard restore path. The backup part is read-only and safe. The restore part is not — reloading a ruleset replaces your firewall's entire running state in one transaction, and a bad ruleset can drop your SSH session and cut the host off the network instantly.
This script creates one LDAP user entry (an inetOrgPerson / posixAccount ) under your people container and adds that user's uid as a memberUid to one or more existing groups. Its purpose is to make user provisioning repeatable instead of hand-crafting LDIF every time.
This guide builds a small read-only status page. A bash script checks whether a list of systemd services are active and whether a few HTTP endpoints answer, then writes a plain HTML file that your web server already serves. Cron re-runs it every few minutes so the page stays current. Nothing here restarts, reconfigures, or stops any service — it only reads state and writes one HTML file.
I keep ending up with directories that are one flat dumping ground — exported reports, scans, camera dumps — hundreds of files with no order. This guide builds a small bash script that reads each file's modification date, renames it with a YYYY-MM-DD_ prefix, and moves it into DEST/YYYY/MM/ folders. It is safe by default: it prints what it would do and moves nothing until you explicitly tell it to.
This guide configures rsyslog on your Linux hosts to forward their system logs over the network to one central collector, and configures that collector to receive them and file each sender's logs into its own directory. The point is to have every machine's logs in one place so you can search, retain, and back them up centrally.
This guide gives you a small bash script that logs into a list of servers over SSH, and on each one dumps two things to a text file on your control machine: the list of installed packages (via dpkg-query on Debian/Ubuntu or rpm on RHEL/Alma) and the list of systemd service unit files. The purpose is a point-in-time software and service inventory you can diff, audit, or archive.
This guide builds a small daemon that watches a source directory with inotifywait and, whenever a file there changes, runs rsync to mirror those changes into a destination directory. The result is one-way, near-real-time replication: destination follows source, never the other way around.
This guide builds a small bash script that connects to a list of hostnames over TLS, reads the expiry date from each certificate, and emails you a summary of anything expiring within a threshold you choose (30 days by default). It is a read-only monitor : it makes outbound TLS connections and sends mail. It does not touch, renew, or modify any certificate, and it changes nothing on the servers it checks.
This is a read-only monitor . The script queries DNS with dig , compares each answer against a baseline file you control, and prints (and by cron, emails) a line for every record that no longer matches. It changes no DNS records, no zone files, and no configuration — the worst it can do is send you an email or write to a file you point it at. Because of that there is nothing to roll back on the DNS side.
This guide sets up a small script, run by a systemd timer, that does three things on a schedule: refreshes the package lists ( apt-get update ), installs available upgrades non-interactively, and — only if the upgrade left the system needing a reboot — reboots the machine during a maintenance window.
This guide builds a read-only bash script that parses your SSH log, counts failed password attempts, and prints a summary of the busiest source IP addresses and the usernames they tried. Its purpose is visibility — spotting brute-force patterns — not blocking. It does not change firewall rules, ban anyone, edit config, or delete anything. Running it and re-running it leaves your system exactly as it was.
This guide gives you a small bash script that reads a plain-text config file and passes each line to ufw , so your firewall rules live in one readable, version-controllable file instead of your shell history. It adds the rules you list; it does not remove rules that aren't in the file.
This guide replaces a cron job with three small systemd units: a service that runs your task, a timer that schedules it, and a small notification service that emails you when the task fails. The point is to get the two things cron does not give you for free — the task's output captured in the journal, and an alert when it exits non-zero.
This script applies a standard first-boot baseline to a fresh Ubuntu server: it creates a non-root sudo user with your SSH key, turns on the UFW firewall (allowing only SSH), disables direct root login and SSH password authentication, enables automatic security updates, and installs fail2ban to throttle SSH brute-forcing. Its purpose is to take a default cloud or VM image from "wide open with a root password" to a sane, keys-only baseline in one pass.
Two scripts here. The first ( mysql-backup.sh ) makes a gzipped mysqldump of every database on the server, drops the file in /var/backups/mysql , and deletes any dump older than a retention window. The second ( mysql-restore-test.sh ) proves a backup is usable by loading the newest dump for one database into a throwaway database, counting the tables, and dropping that throwaway again.
This guide builds a small shell script that runs doveadm quota get for every mailbox on a Dovecot server, writes a plain-text usage report to a file, and emails you a summary that flags anyone at or above a threshold (90% by default). It is a read-only reporting script. It queries quota figures that Dovecot already tracks; it does not create, resize, recalculate, or delete anything in a mailbox.
This guide sets up a bash script that runs pg_dump (and pg_dumpall for cluster-wide roles) on a schedule, writes each backup to a directory with a timestamped filename, and then deletes any backup older than a retention window. The purpose is a hands-off nightly logical backup you can restore from.
This procedure reads a CSV of new users and generates a batch file of createAccount commands that zmprov executes to create real, live mailboxes on your Zimbra server. Creating accounts is a provisioning action that touches your directory and mail store. It is not destructive on its own — but the rollback (deleting an account) is irreversible: deleteAccount removes the mailbox and all of its mail with no undo. Treat the delete step accordingly.
This script checks how full a filesystem is with df . If it is at or above a percentage you set, it deletes files older than a chosen age from one directory you designate — typically a cache, spool, or temp directory — using find . Its purpose is to keep a disk from filling up unattended, not to be a general cleanup tool.
This script reads fail2ban's current state — the list of active jails and how many IPs each one has banned — and posts a short text summary to a Slack channel through an incoming webhook. Its purpose is visibility: you get a scheduled report of what fail2ban is blocking without SSHing in to run fail2ban-client status by hand.
Certbot renews your certificates on a timer, but a renewed certificate sitting on disk does nothing until the service using it reloads and reads the new file. This guide sets up a deploy hook — a small script Certbot runs only when a certificate actually changes — so the reload happens automatically and only when it needs to.
A mail queue that quietly grows is one of those failures you notice late — usually when a user asks why their mail from three hours ago hasn't arrived. A backlog can mean a dead relay host, a DNS problem, a downstream server rejecting everything, or an outbound spam run from a compromised account. This guide sets up a small cron job that counts the queue and emails you when it crosses a threshold, so you hear about it early.
This guide sets up a small bash script that reads yesterday's Postfix log, runs it through pflogsumm to build a delivery summary (messages received/delivered/deferred/ bounced, top senders, deferral reasons), and emails that summary to you once a day from cron.
This guide sets up logrotate to rotate and compress the log files of a custom application on a schedule, so a chatty app doesn't fill the disk. logrotate is already installed and running on Debian/Ubuntu; what you're adding is one small config file that tells it how to handle your app's logs. logrotate itself does the scheduling, compression, and pruning — you only describe the policy.
This guide builds a small shell script that runs once a night from cron. Each run it makes a compressed tar archive of one source directory, encrypts that archive to a GPG public key , deletes the plaintext copy, then pushes the encrypted file to a remote server over SSH with rsync . The result is a backup that is encrypted at rest (GPG) and in transit (SSH). Only someone holding the matching GPG private key can read it — so keep that private key off the backup box.
Creating one Linux account by hand is fine. Creating thirty from a spreadsheet a manager emailed you is a job for a script. This walks through a small, boring, reliable bash script that reads a CSV and provisions local users and their groups with the standard shadow-utils tools.
Debian shipped DSA-6389-1 for ntfs-3g on 15 July, and Ubuntu followed with USN-8554-1 the next day. Between them they close a batch of nine CVEs: seven heap buffer overflows (CVE-2026-42616, 42617, 42618, 46569, 46570, 46572 and 56135) and two out-of-bounds reads (CVE-2026-46571 and 56136). The overflows can lead to arbitrary code execution; the reads can leak memory contents.
Are you getting many spam requests from IP addresses? Do you want to block or allow IPs instantly? It’s been one hectic task for Email Administrators when they need to manage IP based whitelist and blacklist. Well here is the hassle free solution…!!! Check out my other Zimbra Batch files: Zimbra User Management Zimbra Group / Distribution Lists Management You will have to apply and modify some of the changes to get this work for you on your Zimbra Open Source Collaboration Server. Here is the guide that you need to follow first before going further below. Click HERE I believe you have changed your…
My another batch file to manage Groups or Distribution lists on Zimbra server from your Windows PC. Check out my Zimbra User Management – Batch File : HERE Find our more information about Zimbra here – Zimbra Collaboration Open Source Edition It is very simple batch file, just to achieve three simple activities from Zimbra Group Management – Batch File using SSH from any windows PC: Create Distribution List Add Member to Group List Remove member from Group Here are the basic requirements that you need when you use this batch file: Install PUTTY on your windows PC where you will be using this batch file. (Get PUTTY –…
Everybody loves Zimbra. The best in class Zimbra Collaboration Open Source Email server with contacts, tasks and calendar management on your finger tips. I indeed love it and recommend it to small and medium businesses when they ask me how can we achieve best in-house Email server. Even many big data enterprises are also using this feature rich daemon. Find our more information about Zimbra here – Zimbra Collaboration Open Source Edition System / email administrators manages users from Zimbra Admin Panel where they can create / modify and delete users and do many things. However I find it quite lazy myself when administering users using Zimbra Admin Panel. Believe me, login on to Zimbra Admin panel, issuing…
Often I have seen that OpenLDAP Master Slave Replication seems heavy job for server administrators. Many articles are available to achieve this scenario but majority of the articles are so detailed that mostly administrators gets confused about their replication. Many time they applies replication configuration on server but loses data on either server or sometime whole database. Or gets locked out from database where they are not able to recover data. Many time, I also have made mistakes in learning OpenLDAP Master Slave Replication on my test servers, but just to understand and learn the whole process. Here is how you can achieve OpenLDAP Master Slave Replication in just a minute. Applied on CentOS Linux…
Here is step-by-step guide to achieve two way Dovecot server replication / mirroring. I had been searching a lot to achieve two way dovecot server replication / mirroring and had been trying out many things. None methods were giving me sure shot and performance intensive results. Well you all do is, play with it more to understand it more and achieve more. This is what I did and achieved what I needed. Sharing with you all that what configuration I made with my both live production servers which are now replicating each and every emails with each other. I have not received any single email replication related issue since last 2 years. And still it is…
