Private corporate batches, live online cohorts and 1-on-1 mentoring in the RPM package format end to end — querying and verification, spec files, rpmbuild, signing, mock clean-room builds and yum/dnf repositories — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches RPM from both sides of the format: consuming it — querying, verifying, signature checking and diagnosing a broken transaction — and producing it, from build-environment setup and spec file structure through macros, scriptlets, automatic dependency generation and mock clean-room builds. Every step is demonstrated against real packages on a running system, including the failure cases: file conflicts, unowned directories, scriptlets that break on upgrade, and packages that build on one host and nowhere else.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For RPM that means a trainer who has run it in production — the RPM package format end to end — querying and verification, spec files, rpmbuild, signing, mock clean-room builds and yum/dnf repositories — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private RPM batchRPM is the package format and package manager that underpins Red Hat Enterprise Linux, CentOS Stream, Rocky, AlmaLinux, Fedora, SUSE and Amazon Linux. An RPM file is a header section plus a compressed payload: the header carries the package's name, version, release, epoch and architecture, its declared dependencies, the complete file manifest with ownership, permissions and digests, the changelog, and the scriptlets that run at install, upgrade and removal time. The payload carries the files themselves.
The rpm command operates on that format and on a local database of what is installed. It installs, upgrades, freshens, removes, queries and verifies — and verification is the part most engineers never learn. Because the header records a digest, size, mode, owner and mtime for every file, RPM can tell you exactly which files on a running system have drifted from what the package shipped, which package owns a given path, and whether a package's signature matches a trusted key. That makes RPM as much a forensic tool as an installer.
Producing RPMs is a separate skill. A spec file declares metadata, sources and patches, then four ordered sections — prep, build, install and files — that rpmbuild executes inside a controlled directory tree. Dependency metadata is largely generated automatically by scanning the built files, macros keep paths portable across distributions and architectures, and mock builds the package inside a fresh chroot so the result does not silently depend on whatever happened to be installed on the build host.
Enterprise Linux is not going anywhere. RPM-based distributions carry most regulated and long-lived server workloads, and every organisation running them eventually needs software that no upstream vendor packages: an internal agent, a patched library, a Java service that has to be managed by systemd, a compliance tool that must be installable and removable on demand.
The usual workaround — a tarball, a shell installer and a wiki page — fails the moment a fleet grows. Nothing owns the files, upgrades leave debris, removal is guesswork, and there is no way to prove what was installed on a host six months ago. A signed RPM in an internal repository answers all of that, and it costs a spec file.
There is also a security dimension. Signed packages and signed repository metadata are the mechanism by which an enterprise Linux estate establishes that the binaries it runs came from somewhere trusted. Teams building an internal software supply chain, running air-gapped or regulated environments, or responding to component-inventory requirements all end up needing someone who can read and write RPM properly rather than copy a spec file and hope.
What an RPM file actually contains and what the local database tracks. Package naming and the NEVRA identity that dependency resolution is built on, the division of labour between the low-level rpm command and the dnf/yum resolver, and how to find the package you need in the first place.
Topics: Using RPM — the command, the format and the local database · Finding RPM Packages — distribution repositories, EPEL, vendor channels and rebuild sources · Package identity: name, epoch, version, release, architecture · Header and payload structure · rpm versus dnf/yum — what each layer is responsible for · Reading package metadata before installing anything
The transactional operations and the differences that matter in production. Upgrade versus freshen, what happens to configuration files marked as config, how obsoletes drive replacement, and the two flags that turn a package manager into a file copier.
Topics: Installing — transaction planning, test mode, relocation · Uninstalling — removal ordering, leftover files and unowned directories · Upgrading — old package removal ordering and config file handling · Freshening — upgrading only what is already present, and when that is the right tool · Config file handling: rpmnew, rpmsave and noreplace · --nodeps and --force: what they suppress and the damage that follows
The forensic half of RPM, and the part most engineers never use. Query the installed database or an uninstalled file, list files and their attributes, read scriptlets and changelogs before installing, and use verification to find every file on a system that no longer matches what shipped.
Topics: Querying — installed packages, package files, and query by file path · Query formats and custom output with --queryformat · Listing files, documentation, config files and dependencies · Reading scriptlets, triggers and changelogs from a package · Verifying — the verify output flags and what each character means · Whole-system verification and interpreting the noise
How an RPM-based system establishes that a binary came from somewhere trusted. Package signatures versus repository metadata signatures, importing and managing keys on a fleet, and signing your own packages so internal software gets the same guarantee as vendor software.
Topics: Checking a Package's Signature — header and payload signatures · Importing Keys — the RPM keyring and pubkey pseudo-packages · Verifying Signature of Packages across a repository · Generating a signing key and configuring %_gpg_name · Signing packages with rpmsign, including bulk resigning · Key distribution and rotation across a fleet
The situations that actually generate support tickets. Extracting files from a package without installing it, rebuilding a corrupted database, resolving conflicts, downgrading safely, and the everyday query patterns worth committing to muscle memory.
Topics: Practical and Common Examples of RPM Usage · Extracting a package with rpm2cpio and rpm2archive · Rebuilding a corrupted RPM database · Downgrading and pinning a version · Duplicate and multilib package situations · Diagnosing dependency resolution failures at the dnf layer
Everything that has to exist before rpmbuild is useful. The build directory tree and why building as root is a mistake, getting your project into a tarball the way rpmbuild expects, and the layout that keeps sources, spec files and outputs separate.
Topics: Creating a RPM Packages — the workflow end to end · create your rpm build env for RPM — rpmdev-setuptree and the ~/rpmbuild layout · create the tarball of your project — naming, top-level directory and versioning · Copy to the sources dir — SOURCES, SPECS, BUILD, BUILDROOT, RPMS, SRPMS · Why building as an unprivileged user matters · Required build tooling: rpm-build, rpmdevtools, rpmlint
The spec file section by section. The preamble and its metadata, sources and patches, the four build phases and what each is allowed to touch, the files list with attributes and directory ownership, and the changelog that becomes the package's history.
Topics: Inside a .spec file — overall structure and evaluation order · The preamble: Name, Version, Release, Summary, License, URL, Source, BuildArch · BuildRequires versus Requires — build-time and run-time dependencies · %prep, %build, %install and %check — what belongs in each · %files, %attr, %config, %doc, %dir and directory ownership · %changelog conventions and why the format is enforced · Running rpmlint and fixing what it reports
From spec file to installable artifact. Running rpmbuild through its stages, building the source RPM and the binary RPM, reading the build log when a stage fails, and inspecting the result before it goes anywhere near a real host.
Topics: Building a "Hello World" RPM — the smallest complete example · A complete hello.spec file, read in full · Building the package — rpmbuild stages and short-circuit options · build the source and the binary rpm — -bs, -bb, -ba and what each produces · Source RPMs: what they contain and why they are the reproducible unit · Inspecting the built package before shipping it · Reading and diagnosing a failed build log
The features that separate a package that installs from a package that survives upgrades. Macros for portability across distributions and architectures, scriptlets and their argument semantics during upgrade, systemd integration, and controlling the dependency metadata that RPM generates automatically.
Topics: Macros: built-ins, %{_libdir}, %{_unitdir}, dist tags and defining your own · Conditional builds and distribution-specific sections · %pre, %post, %preun, %postun and the $1 argument during upgrade · systemd scriptlet macros for units, timers and presets · Triggers and file triggers · Automatic dependency generation, and filtering or overriding it · Requires, Provides, Obsoletes and Conflicts used deliberately · Subpackages and split -devel, -libs and -doc packages
Making builds reproducible and getting packages to hosts. Building inside a fresh chroot with mock so nothing leaks in from the build machine, then generating repository metadata, signing it and wiring it into a delivery pipeline.
Topics: The mock builds — chroot configuration, distribution and architecture targets · Building an SRPM in mock and diagnosing host-dependency leakage · Reproducibility concerns: timestamps, build paths and SOURCE_DATE_EPOCH · createrepo and repository metadata generation · Signing repository metadata and configuring clients to require it · Hosting an internal yum/dnf repository, including air-gapped mirrors · RPM builds in CI, with signing keys held outside the build agent · Retention, promotion channels and deprecating old builds
We rebuild the agenda around the tools you actually run.
Request a custom agendaUse whole-system verification and targeted queries to identify every file that no longer matches its package, then explain each difference and decide what to do about it.
Generate a GPG signing key, sign a set of packages, distribute the public key to a fleet and prove that an unsigned package is now rejected.
Take a real application tarball and write a complete spec file with dependencies, a systemd unit, config-file handling and a clean rpmlint result.
Write pre and post scriptlets that behave correctly across install, upgrade and removal, then prove it by upgrading a live service without losing its data.
Build the same source RPM under mock for two distribution targets, and track down the host dependency that only showed up once the build environment was clean.
Build in mock from CI, sign outside the build agent, publish to a signed repository, promote between channels and install on a fleet host.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.