> For the complete documentation index, see [llms.txt](https://jncia-workbook.gitbook.io/workbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jncia-workbook.gitbook.io/workbook/junos-basics/4-candidate-configuration-part-1.md).

# 4) Candidate Configuration (Part 1)

### Pre-Work

If you completed the previous labs, R1 and R2 are now on a factory default configuration. We must fully reset the lab to restore our mgmt access via SSH. This is the only time you should need to do this for the rest of this workbook.

```
containerlab destroy -t three-routers/three-routers.clab.yml
containerlab deploy -t three-routers/three-routers.clab.yml
```

### Lab

Once the routers are back up, connect to R1 and create a new user:

```
configure

[edit]
admin@R1# set system login user new-user authentication plain-text-password   
New password:
Retype new password:

[edit]
admin@R1# set system login user new-user class super-user                      

[edit]
admin@R1# commit 
commit complete
```

Ensure you exit back to operational mode.

```
admin@R1# exit 
Exiting configuration mode

admin@R1> 
```

Open a second window to R1, this time logging in as the **new-user**.

```
clab@clab:~/jncia-junos-labs$ ssh new-user@10.200.255.2
(new-user@10.200.255.2) Password:
--- JUNOS 25.4R1.12 Kernel 64-bit  JNPR-15.0-20251024.861cae5_buil
new-user@R1> 
```

As the **new-user**, make a change to the hostname, but exit without committing the changes.

```
new-user@R1> configure 
Entering configuration mode

[edit]
new-user@R1# set system host-name CHANGED-HOSTNAME 

[edit]
new-user@R1# exit 
The configuration has been changed but not committed
Exit with uncommitted changes? [yes,no] (yes) 

Exiting configuration mode

new-user@R1> 
```

As the **admin** user, make a change to the name-servers:

```
admin@R1> configure 
Entering configuration mode
The configuration has been changed but not committed

[edit]
admin@R1# set system name-server 1.2.3.4 

[edit]
admin@R1# 
```

Before committing the change as the **admin** user, *will the change that **new-user** made be committed as well? Why or why not?*

### Answer

<details>

<summary>Expand to reveal</summary>

The answer is *yes*, the changes that the **new-user** made but didn't commit will be applied when the **admin** user commits.

\
Below, you can see that the hostname that the **new-user** changed takes effect after the commit.

```
admin@R1# commit 
commit complete

[edit]
admin@CHANGED-HOSTNAME# 
```

</details>

### Explanation

<details>

<summary>Expand to reveal</summary>

The candidate configuration is a **shared** configuration file, shared among all users. Therefore, if a user stages a change but does not commit it, that change will still be present in the candidate config file when another user edits the config.

\
Let's take a step back to explain the commit system. Junos uses a two-stage configuration system. The active config is what is loaded at bootup, and is the current running config. When you enter **configuration** mode, the active configuration (also known as configuration #0, which will make more sense in the upcoming rollback lab) is copied into the candidate configuration.

\
Since the candidate configuration is a shared file, when **new-user** and **admin** enter **configuration** mode, they are editing the same candidate configuration file.

\
Also, when you exit **configuration** mode, the changes you made to the candidate configuration are retained. We will see how to prevent this in the next lab.

</details>

### Further Reading

<https://www.juniper.net/documentation/us/en/software/junos/junos-overview/topics/concept/junos-software-candidate-configuration-activating.html>