rauto
  • English

      • 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

      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

      Current built-in profiles come from rneter.

      The README and current source-backed catalog include:

      • autodetect
      • cisco_ios
      • cisco_xe
      • huawei
      • h3c_comware
      • hp_comware
      • hillstone_stoneos
      • juniper_junos
      • array
      • arista_eos
      • aruba_aoscx
      • cisco_asa
      • cisco_nxos
      • dell_os10
      • fortinet
      • paloalto_panos
      • topsec
      • venustech
      • dptech
      • chaitin
      • qianxin
      • maipu
      • ruijie_os
      • zte_zxros
      • checkpoint_gaia
      • linux

      List them with:

      rauto profile list

      Default profile behavior

      rauto now defaults to autodetect.

      This is helpful when:

      • the same workflow may touch different network platforms
      • you want show, TextFSM parsing, and mode validation to use the resolved profile
      • you are onboarding saved connections before standardizing explicit profiles

      Autodetect resolves the actual built-in profile before execution. It does not infer command mode from the command text, so use --mode when a command must run in a specific state such as Enable, Config, or Shell.

      Successful autodetect results are cached locally by host:port in the runtime database. Later connections to the same target can reuse the detected profile instead of probing again.

      Force a fresh probe when the target changed or the cache looks wrong:

      rauto exec "show version" \
  --host 192.168.1.1 \
  --credential network-admin \
  --force-autodetect

      Use an explicit profile when you want deterministic behavior or know the platform:

      rauto exec "show version" \
  --host 192.168.1.1 \
  --credential network-admin \
  --device-profile cisco_ios

      Inspecting a profile

      Use these commands to inspect or clone profiles:

      rauto profile show cisco_ios
rauto profile show linux
rauto profile copy-builtin cisco_ios my_cisco
rauto profile delete-custom my_cisco

      From the CLI source, profile management currently exposes:

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

      Diagnosing profile quality

      The current CLI supports:

      rauto profile diagnose cisco_ios
rauto profile diagnose cisco_ios --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.

      Profile Management workspace

      The latest Web console presents built-in and custom Profiles in one searchable, collapsible catalog. Select a Profile to inspect its identity, command execution policy, autodetect rules, prompt patterns, interactions, transitions, and lifecycle Hooks without leaving the workspace.

      Built-in Profiles remain read-only. Use Copy To Custom Form when you need to adapt one, then edit and save the copied state machine. Diagnostics are attached to the selected Profile and check for unreachable states, transition gaps, duplicate prompt patterns, and potentially ambiguous prompts before rollout.

      Lifecycle Hook authoring supports:

      • after_connect, before_disconnect, after_enter_state, and before_exit_state triggers
      • a single command or an ordered command flow
      • per-command mode and timeout settings
      • stop-on-error and maximum-step controls for command flows
      • interactive prompt match patterns, predefined responses, and optional matched-input recording

      This makes connection initialization and state transitions reusable Profile behavior rather than logic duplicated across individual tasks.

      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:

      rauto profile copy-builtin cisco_ios my_cisco
rauto exec "show ver" \
  --host 192.168.1.1 \
  --credential network-admin \
  --device-profile my_cisco

      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

      Profile selection matters to commands such as:

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

      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
      • show maps profile/platform objects to device commands and TextFSM platforms
      • transaction and workflow steps need predictable mode behavior to keep rollback and compensation logic safe

      Enterprise guidance

      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

      Before using a new profile in:

      • transaction blocks
      • workflows
      • orchestration

      validate it with:

      • rauto connection test
      • rauto profile autodetect -v
      • rauto profile diagnose
      • one or two exec commands in the expected modes
      • one or two show objects that should parse cleanly

      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