1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
---
title: netplan-try
section: 8
author:
- Daniel Axtens (<daniel.axtens@canonical.com>)
...
## NAME
netplan-try - try a configuration, optionally rolling it back
## SYNOPSIS
**netplan** [--debug] **try** -h | --help
**netplan** [--debug] **try** [--config-file _CONFIG_FILE_] [--timeout _TIMEOUT_]
## DESCRIPTION
**netplan try** takes a **netplan**(5) configuration, applies it, and
automatically rolls it back if the user does not confirm the
configuration within a time limit.
A configuration can be confirmed or rejected interactively or by sending the
SIGUSR1 or SIGINT signals.
This may be especially useful on remote systems, to prevent an
administrator being permanently locked out of systems in the case of a
network configuration error.
## OPTIONS
-h, --help
: Print basic help.
--debug
: Print debugging output during the process.
--config-file _CONFIG_FILE_
: In addition to the usual configuration, apply _CONFIG_FILE_. It must
be a YAML file in the **netplan**(5) format.
--timeout _TIMEOUT_
: Wait for _TIMEOUT_ seconds before reverting. Defaults to 120
seconds. Note that some network configurations (such as STP) may take
over a minute to settle.
## KNOWN ISSUES
**netplan try** uses similar procedures to **netplan apply**, so some
of the same caveats apply around virtual devices.
There are also some known bugs: if **netplan try** times out or is
cancelled, make sure to verify if the network configuration has in
fact been reverted.
As with **netplan apply**, a reboot should fix any issues. However, be
sure to verify that the config on disk is in the state you expect
before rebooting!
## SEE ALSO
**netplan**(5), **netplan-generate**(8), **netplan-apply**(8)
|
