ITOM Discovery Best Practices for Linux Servers (9tips+privilege exmp)

[Rafael P]

1. Credential Strategy (Most Common Failure Point)

Discovery on Linux lives or dies by credentials.

Best practices

• Prefer SSH key-based authentication over password.

• Use a dedicated technical account (not personal users).

• Grant least privilege, but ensure:

  • sudo access for required commands

  • Non-interactive sudo (no TTY / no password prompt)

Defaults:snc_discovery !requiretty
snc_discovery ALL=(ALL) NOPASSWD: ALL

Exam mindset:

If Discovery connects but doesn’t classify → credential or sudo issue.

---

2. SSH & OS Readiness

Discovery uses standard Linux commands, not agents.

Verify before Discovery

• SSH daemon running (sshd)

• Port 22 open (or custom port configured)

• Commands available:

  • uname

  • lsb_release

  • cat /etc/*release

  • ps, netstat / ss

  • df, free

Avoid

• Restricted shells

• Banner prompts

• MFA on SSH (breaks automation)

---

3. MID Server Placement & Configuration

MID placement is architectural, not optional.

Best practices

• Place MID as close as possible to Linux hosts (network latency matters)

• Ensure MID can:

  • Reach target IPs

  • Resolve DNS correctly

  • Access required ports

Scale considerations

• One overloaded MID = partial Discovery

• Separate MIDs by:

  • Environment (Prod / Non-Prod)

  • Network zone

  • Cloud vs On-Prem

Exam tip:

Discovery failures often start at MID connectivity, not credentials.

---

4. Use OOTB Linux Patterns First

Patterns are opinionated and tested.

Best practices

• Always start with OOTB Linux patterns

• Customize only when:

  • Proprietary software is missing

  • Custom processes must be identified

• Never modify OOTB directly:

  • Clone → version → test

Pattern flow

1. Identification

2. Classification

3. Exploration

If classification fails, CI becomes Computer only.

---

5. Identification & Reconciliation (IRE) Alignment

Linux servers are high-risk for duplicates.

Best practices

• Ensure unique identifiers:

  • Serial Number (preferred)

  • VM UUID

  • Cloud Instance ID

• Avoid relying only on:

  • Hostname

  • IP address

Source precedence

• Discovery > Manual

• Discovery > Imports (unless justified)

Architect rule:

Fix IRE rules before blaming Discovery.

---

6. Control What You Discover

More data ≠ better CMDB.

Best practices

• Use:

  • Discovery schedules by subnet

  • IP ranges by environment

• Exclude:

  • Backup interfaces

  • Virtual adapters

  • Containers (unless required)

Why this matters

• Less noise

• Faster Discovery

• Cleaner CMDB

• Better Service Mapping

---

7. Logging & Troubleshooting (Always Tested)

Know where to look when Discovery fails.

Key locations

• Discovery Status

• ECC Queue

• MID logs:

  • agent.log

  • wrapper.log

• Pattern execution logs

Golden rule

If it’s not in the logs, it didn’t happen.

---

8. Security & Compliance Considerations

Security teams will review Discovery.

Best practices

• No hardcoded passwords

• Rotate SSH keys

• Restrict Discovery users

• Document sudo usage

• Align with security baseline

Exam angle:
ServiceNow favors secure automation, not shortcuts.

---

9. Linux + Cloud Specific Tips

For AWS / Azure / GCP Linux:

• Prefer Cloud Discovery APIs over SSH where possible

• Use Instance ID as primary identifier

• Expect ephemeral IPs and hostnames

• Combine Cloud Discovery + SSH for depth

---

Common Anti-Patterns (Exam Traps)

Using root directly
MFA on SSH for Discovery
Modifying OOTB patterns
Hostname-only identification
One MID for everything
Ignoring IRE conflicts