Skip to content
rauto Docs

Device Profiles

Device profiles are one of the most important abstractions in rauto. They determine how prompts, modes, and command execution behave for a target platform.

What a device profile does

Section titled “What a device profile does”

A device profile tells the execution engine how to work with a target type.

It affects things such as:

  • prompt recognition
  • mode transitions
  • execution state handling
  • Linux shell exit-code capture behavior
  • compatibility between raw command execution and higher-level workflows

This is why the same CLI can drive both:

  • network devices such as Cisco, Huawei, Juniper, or Fortinet
  • Linux servers and jump hosts

Built-in profiles

Section titled “Built-in profiles”

Current built-in profiles come from rneter.

The README and current source-backed catalog include:

  • cisco
  • huawei
  • h3c
  • hillstone
  • juniper
  • array
  • arista
  • fortinet
  • paloalto
  • topsec
  • venustech
  • dptech
  • chaitin
  • qianxin
  • maipu
  • checkpoint
  • linux

List them with:

Terminal window
rauto device list

Default profile behavior

Section titled “Default profile behavior”

rauto now defaults to linux.

This is helpful when:

  • your first target is a Linux host
  • you are testing from a workstation or jump box
  • you want shell-style command execution immediately

It is dangerous when:

  • you connect to a network device and forget to set --device-profile
  • the device needs a specific prompt / mode model for stable execution

For network devices, make --device-profile explicit early.

Terminal window
rauto exec "show version" \
  --host 192.168.1.1 \
  --username admin \
  --password secret \
  --device-profile cisco

Inspecting a profile

Section titled “Inspecting a profile”

Use these commands to inspect or clone profiles:

Terminal window
rauto device show cisco
rauto device show linux
rauto device copy-builtin cisco my_cisco
rauto device delete-custom my_cisco

From the CLI source, profile management currently exposes:

  • list
  • show
  • delete-custom
  • copy-builtin
  • diagnose

Diagnosing profile quality

Section titled “Diagnosing profile quality”

The current CLI supports:

Terminal window
rauto device diagnose cisco
rauto device diagnose cisco --json

This is especially useful when:

  • prompt transitions are unstable
  • a custom profile fails in one mode but not another
  • you need a structured output for profile review or troubleshooting

The Web console also exposes prompt/profile diagnostics visually.

Custom profile lifecycle

Section titled “Custom profile lifecycle”

Custom profiles are no longer loose files in a template folder. They are stored in SQLite and shared by CLI and Web.

Recommended lifecycle:

  1. inspect a built-in profile
  2. copy it to a custom profile
  3. adjust behavior for your platform or prompt variant
  4. validate with diagnostics and connection tests
  5. standardize the custom profile name across saved connections

Example:

Terminal window
rauto device copy-builtin cisco my_cisco
rauto exec "show ver" \
  --host 192.168.1.1 \
  --username admin \
  --password secret \
  --device-profile my_cisco

Linux shell flavor

Section titled “Linux shell flavor”

The Linux profile adds another important dimension: shell exit-code parsing strategy.

Current options from source:

  • posix
  • fish

The README also notes that posix accepts the bash alias.

Use --linux-shell-flavor when Linux targets do not behave as expected under the default parsing strategy.

Profile influence on execution modes

Section titled “Profile influence on execution modes”

Profile selection matters to commands such as:

  • exec
  • template
  • flow
  • tx
  • tx-workflow
  • orchestrate

Why:

  • exec --mode depends on named profile modes such as Enable or Config
  • flow falls back to the first mode defined by the selected profile when a step omits mode
  • transaction and workflow steps need predictable mode behavior to keep rollback and compensation logic safe

Enterprise guidance

Section titled “Enterprise guidance”

Standardize profile names

Section titled “Standardize profile names”

In larger environments, do not let each operator invent profile naming independently.

Good pattern:

  • use built-in profiles whenever possible
  • create a small set of approved custom profiles
  • bind those profile names into saved connections and import templates

Diagnose before rollout

Section titled “Diagnose before rollout”

Before using a new profile in:

  • transaction blocks
  • workflows
  • orchestration

validate it with:

  • rauto connection test
  • rauto device diagnose
  • one or two exec commands in the expected modes

Treat Linux separately from network OSes

Section titled “Treat Linux separately from network OSes”

Even though rauto can handle both, they should usually be documented with different operational guardrails.

  • Linux targets focus more on shell semantics, file transfer, and restart workflows
  • network targets focus more on prompt states, config mode, and rollback confidence
Section titled “Related pages”