Managing Apstra Server

Monitoring Apstra Server via CLI

The Apstra server CLI command sudo service aos status can be used for simple status check.

admin@aos-server:~$ sudo service aos status
* aos.service - LSB: Start AOS management system
   Loaded: loaded (/etc/init.d/aos; generated)
   Active: active (exited) since Tue 2020-07-28 00:35:38 UTC; 2h 13min ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 0 (limit: 4915)
   CGroup: /aos.service

Jul 28 00:35:35 aos-server systemd[1]: Starting LSB: Start AOS management system...
Jul 28 00:35:36 aos-server aos[1040]: net.core.wmem_max = 33554432
Jul 28 00:35:37 aos-server aos[1040]: Creating aos_sysdb_1 ...
Jul 28 00:35:37 aos-server aos[1040]: Creating aos_nginx_1 ...
Jul 28 00:35:37 aos-server aos[1040]: Creating aos_auth_1  ...
Jul 28 00:35:37 aos-server aos[1040]: Creating aos_controller_1 ...
Jul 28 00:35:37 aos-server aos[1040]: Creating aos_metadb_1     ...
Jul 28 00:35:38 aos-server aos[1040]: [240B blob data]
Jul 28 00:35:38 aos-server systemd[1]: Started LSB: Start AOS management system.
admin@aos-server:~$

The Apstra server script aos_Apstra server_health_check is available for further error collection. The command runs a search for known error signatures in the Apstra server logs, such as agent crashes, and returns the output. The information can be used for troubleshooting.

Usage:

admin@aos-server:~$ docker exec aos_controller_1 aos_controller_health_check
admin@aos-server:~$

The script outputs errors it finds. If no errors are found, it returns no output.

Restarting Apstra Server

Telemetry Alarm

Device agents may temporarily log a “liveness” telemetry alarm if the Apstra server is down, but this clears in a minute or two after services are restored.

To restart the Apstra server, you can simply reboot the VM, or use the service command sudo service aos stop.

admin@aos-server:~$ sudo service aos stop
admin@aos-server:~$ sudo service aos start
admin@aos-server:~$

Reinstalling Apstra Server

This is a nuclear option that wipes and reinstalls the software on the existing server. This is mostly helpful when doing a proof of concept or demo install. If you have problems that require you to reinstall the software, please contact the Juniper JTAC Apstra Support group at https://support.juniper.net/.

Warning

The below procedure removes ALL Apstra data from the Apstra server VM. Use with care.

  1. Download the “Installer” .run file from the support portal, https://support.juniper.net/support/downloads/?p=afc.

    _images/run_file_portal.png

  2. Stop AOS service, if possible.

    admin@aos-server:~$ sudo service aos stop
admin@aos-server:~$

  3. Delete the Apstra server database.

    admin@aos-server:~$ sudo rm -rf /var/lib/aos/db/*
admin@aos-server:~$

  4. Remove the aos-compose package.

    admin@aos-server:~$ sudo dpkg -r aos-compose
(Reading database ... 110457 files and directories currently installed.)
Removing aos-compose (3.3.0-660) ...
Processing triggers for ureadahead (0.100.0-21) ...
Processing triggers for systemd (237-3ubuntu10.41) ...
admin@aos-server:~$

  5. Reinstall the software from the .run file.

    admin@aos-server:~$ sudo bash aos_3.3.0-662.run
Verifying archive integrity... All good.
Uncompressing AOS installer  100%
610bd1ae69b7: Loading layer [==================================================>]  52.44MB/52.44MB
87db235c4ff8: Loading layer [==================================================>]  211.3MB/211.3MB
668b88b6cd3d: Loading layer [==================================================>]  117.3MB/117.3MB
b1dd55ca7fd9: Loading layer [==================================================>]  20.63MB/20.63MB
3f8ebc7f1fae: Loading layer [==================================================>]  4.608kB/4.608kB
Loaded image: aos:3.3.0-662
AOS[2020-07-28_02:58:36]: Installing AOS 3.3.0-662 package
admin@aos-server:~$

    You can now restore an aos_backup or build a new blueprint.

Apstra Server Database Management

The database is stored in a single folder in the Apstra server at /var/lib/aos/db. The database can be easily copied between Apstra servers. The Apstra server container and related database containers are run under Docker.

Requirements

  • Source and Target database versions must be the same version. If versions are different, before proceeding please contact the Juniper JTAC Apstra Support group at https://support.juniper.net/ to obtain assistance with the procedure.
  • Source and Target must have the same IP address after starting the Apstra server to ensure that device agents can ‘call home’ properly after database restoration. The software can be restored to a different IP address, but then each device agent must be reconfigured (/mnt/flash/aos-config, /etc/aos/aos.conf) to point to the new Apstra server IP.

Warning

Any changes you make within the Apstra server are not stored in the backup.

Backing up Database

Backups can be performed while the software is running. They are saved in the Apstra server as a dated snapshot: /var/lib/aos/snapshot/.

If the Apstra server needs to be restored or if its disk image becomes corrupt, the Apstra server is lost, including any backups. We recommend that you periodically move backups from the Apstra server to a secure location.

If you’ve scheduled cron jobs to periodically backup the database, make sure to rotate those files off of the Apstra server to keep the Apstra server VM disk from becoming full.

Back up the Apstra server with the aos_backup command.

If all IBA probes have been disabled, the following message appears.

admin@aos-server:~$ sudo aos_backup
====================================================================
  Backup operation completed successfully.
====================================================================
New AOS snapshot: 2020-07-28_20-56-26
admin@aos-server:~$

Note

If many IBA probes are enabled or if any other DB “write” tasks are in progress, they may not be included in the backup, and the following message appears.

admin@aos-server:~$ sudo aos_backup
=====================================================================
Warning:
 Backup operation has been completed successfully. However AOS state
has been changed while this script was running, which means some
changes might not have been captured in the snapshot created in this
backup. You may choose to invoke aos_backup script again if you wish
to capture these changes right now instead of waiting for the next
backup operation.
=====================================================================
New AOS snapshot: 2019-12-06_16-15-57
admin@aos-server:~$

In this case, disable IBA probes and run the aos_backup command again.

Note

Backup/restore currently does not support Devices/OS Images information. Devices/OS Images information will be lost after the restore operation.

Validating Backup

The backup is stored in /var/lib/aos/snapshot/<date>/aos.data.tar.gz

Copy the contents of the snapshot directory to your backup infrastructure. This also includes the aos_restore script.

admin@aos-server:~$ sudo ls -lah /var/lib/aos/snapshot/
total 20K
drwx------ 5 root root 4.0K Jul 28 20:58 .
drwxr-xr-x 7 root root 4.0K Jul 28 02:43 ..
drwx------ 2 root root 4.0K Jul 28 02:43 2020-07-28_02-43-12
drwx------ 2 root root 4.0K Jul 28 20:56 2020-07-28_20-56-26
drwx------ 2 root root 4.0K Jul 28 20:58 2020-07-28_20-58-54
admin@aos-server:~$

Restoring Database

Note

If restoring a backup to a new Apstra server that uses a different network interface for access (e.g. eth1 vs eth0), the metadb variable in the [controller] section of the /etc/aos/aos.conf configuration file must be updated and the Apstra server must be restarted.

  1. Confirm the contents of the snapshot folder exists somewhere on the filesystem. For example, we have copied the restoration data to /tmp/aos_test_restore.

    admin@aos-server:~$ sudo ls -lah /var/lib/aos/snapshot/2020-07-28_20-56-26/
total 21M
drwx------ 2 root root 4.0K Jul 28 20:56 .
drwx------ 5 root root 4.0K Jul 28 20:58 ..
-rw------- 1 root root  21M Jul 28 20:56 aos.data.tar.gz
-rwxr-xr-x 1 root root 1.3K Jul 28 20:56 aos_restore
-rw------- 1 root root    1 Jul 28 20:56 comment.txt
admin@aos-server:~$

  2. Run the restore command from the snapshotted restoration file. The restore process first backs up the current database.

    admin@aos-server:~$ sudo bash /var/lib/aos/snapshot/2020-07-28_20-56-26/aos_restore
====================================================================
  Backup operation completed successfully.
====================================================================
New AOS snapshot: 2020-07-28_20-58-54
(Reading database ... 110457 files and directories currently installed.)
Removing aos-compose (3.3.0-660) ...
Processing triggers for ureadahead (0.100.0-21) ...
Processing triggers for systemd (237-3ubuntu10.41) ...
tar: Removing leading `/' from member names
/etc/aos/aos.conf
/etc/aos-credential/secret_key
/var/lib/aos/db/
/var/lib/aos/db/_Main-000000005f1f7314-000dd7b1-checkpoint
/var/lib/aos/db/_AosController-000000005f1f7314-00035dd2-checkpoint-valid
/var/lib/aos/db/_Central-000000005f1f7313-000ab5f7-checkpoint-valid
/var/lib/aos/db/_Metadb-000000005f1f7312-000a27e1-checkpoint
/var/lib/aos/db/_AosSysdb-000000005f1f7312-000a31be-checkpoint-valid
/var/lib/aos/db/_Credential-000000005f1f7312-000ea6ba-log
/var/lib/aos/db/_Central-000000005f1f7313-000ab5f7-log
/var/lib/aos/db/_Auth-000000005f1f7313-0001e8cf-log-valid
/var/lib/aos/db/_Metadb-000000005f1f7312-000a27e1-log-valid
/var/lib/aos/db/_Auth-000000005f1f7313-0001e8cf-checkpoint-valid
/var/lib/aos/db/_Metadb-000000005f1f7312-000a27e1-checkpoint-valid
/var/lib/aos/db/_Main-000000005f1f7314-000dd7b1-log
/var/lib/aos/db/_Auth-000000005f1f7313-0001e8cf-log
/var/lib/aos/db/_Metadb-000000005f1f7312-000a27e1-log
/var/lib/aos/db/_AosSysdb-000000005f1f7312-000a31be-log-valid
/var/lib/aos/db/_AosAuth-000000005f1f7312-000a0e46-log-valid
/var/lib/aos/db/_AosSysdb-000000005f1f7312-000a31be-log
/var/lib/aos/db/blueprint_backups/
/var/lib/aos/db/blueprint_backups/37321b9c-25b1-4111-849b-522a3852949d/
/var/lib/aos/db/blueprint_backups/37321b9c-25b1-4111-849b-522a3852949d/48/
/var/lib/aos/db/blueprint_backups/37321b9c-25b1-4111-849b-522a3852949d/48/graph.json.zip
/var/lib/aos/db/blueprint_backups/37321b9c-25b1-4111-849b-522a3852949d/48/graph.md5sum
/var/lib/aos/db/_Credential-000000005f1f7312-000ea6ba-log-valid
/var/lib/aos/db/_Credential-000000005f1f7312-000ea6ba-checkpoint
/var/lib/aos/db/_Main-000000005f1f7314-000dd7b1-checkpoint-valid
/var/lib/aos/db/_Central-000000005f1f7313-000ab5f7-log-valid
/var/lib/aos/db/_AosController-000000005f1f7314-00035dd2-log-valid
/var/lib/aos/db/_AosAuth-000000005f1f7312-000a0e46-checkpoint-valid
/var/lib/aos/db/_AosSysdb-000000005f1f7312-000a31be-checkpoint
/var/lib/aos/db/_AosController-000000005f1f7314-00035dd2-checkpoint
/var/lib/aos/db/_AosAuth-000000005f1f7312-000a0e46-checkpoint
/var/lib/aos/db/.devpi/
/var/lib/aos/db/.devpi/server/
/var/lib/aos/db/.devpi/server/.nodeinfo
/var/lib/aos/db/.devpi/server/.secret
/var/lib/aos/db/.devpi/server/.sqlite
/var/lib/aos/db/.devpi/server/.serverversion
/var/lib/aos/db/.devpi/server/.event_serial
/var/lib/aos/db/_AosController-000000005f1f7314-00035dd2-log
/var/lib/aos/db/_Main-000000005f1f7314-000dd7b1-log-valid
/var/lib/aos/db/_Central-000000005f1f7313-000ab5f7-checkpoint
/var/lib/aos/db/_Auth-000000005f1f7313-0001e8cf-checkpoint
/var/lib/aos/db/_Credential-000000005f1f7312-000ea6ba-checkpoint-valid
/var/lib/aos/db/_AosAuth-000000005f1f7312-000a0e46-log
/var/lib/aos/anomaly/
/var/lib/aos/anomaly/_Anomaly-000000005f1f7313-00060aba-log
/var/lib/aos/anomaly/_Anomaly-000000005f1f7313-00060aba-checkpoint-valid
/var/lib/aos/anomaly/_Anomaly-000000005f1f7313-00060aba-log-valid
/var/lib/aos/anomaly/_Anomaly-000000005f1f7313-00060aba-checkpoint
/opt/aos/aos-compose.deb
/opt/aos/frontend_images/
/opt/aos/frontend_images/aos-web-ui.zip
Selecting previously unselected package aos-compose.
(Reading database ... 110440 files and directories currently installed.)
Preparing to unpack /opt/aos/aos-compose.deb ...
Unpacking aos-compose (3.3.0-660) ...
Setting up aos-compose (3.3.0-660) ...
Processing triggers for ureadahead (0.100.0-21) ...
Processing triggers for systemd (237-3ubuntu10.41) ...
Starting aos_sysdb_1      ... done
Starting aos_controller_1 ... done
Starting aos_nginx_1      ... done
Starting aos_auth_1       ... done
Starting aos_metadb_1     ... done
admin@aos-server:~$

Validating Restore

The database has been restored and migrated to a new server. The entire system state has been copied over from the backed up installation to the new target.

admin@aos-server:~$ sudo service aos status
* aos.service - LSB: Start AOS management system
   Loaded: loaded (/etc/init.d/aos; generated)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)

Jul 28 00:36:32 aos-server aos[1078]: [240B blob data]
Jul 28 00:36:32 aos-server systemd[1]: Started LSB: Start AOS management system.
Jul 28 02:45:45 aos-server systemd[1]: Stopping LSB: Start AOS management system...
Jul 28 02:45:46 aos-server aos[4968]: Stopping aos_controller_1 ...
Jul 28 02:45:46 aos-server aos[4968]: Stopping aos_metadb_1     ...
Jul 28 02:45:46 aos-server aos[4968]: Stopping aos_auth_1       ...
Jul 28 02:45:46 aos-server aos[4968]: Stopping aos_sysdb_1      ...
Jul 28 02:45:46 aos-server aos[4968]: Stopping aos_nginx_1      ...
Jul 28 02:45:58 aos-server aos[4968]: [240B blob data]
Jul 28 02:45:58 aos-server systemd[1]: Stopped LSB: Start AOS management system.
admin@aos-server:~$ docker ps -a
CONTAINER ID        IMAGE                      COMMAND                  CREATED              STATUS              PORTS               NAMES
8bc9c1dd7a3a        aos:3.3.0-660              "/usr/bin/aos_launch…"   About a minute ago   Up About a minute                       iba141638ea
b0191320d2bd        aos:3.3.0-660              "/usr/sbin/aos_launc…"   About a minute ago   Up About a minute                       aos-offbox-172_20_34_8-f
136736759f45        aos:3.3.0-660              "/usr/sbin/aos_launc…"   About a minute ago   Up About a minute                       aos-offbox-172_20_34_10-f
00a12eb03ae5        aos:3.3.0-660              "/usr/sbin/aos_launc…"   About a minute ago   Up About a minute                       aos-offbox-172_20_34_11-f
c9b18cd4f55a        aos:3.3.0-660              "/usr/sbin/aos_launc…"   About a minute ago   Up About a minute                       aos-offbox-172_20_34_7-f
90f35781d2a0        aos:3.3.0-660              "/usr/sbin/aos_launc…"   About a minute ago   Up About a minute                       aos-offbox-172_20_34_12-f
f5c2d249176b        aos:3.3.0-660              "/usr/sbin/aos_launc…"   About a minute ago   Up About a minute                       aos-offbox-172_20_34_9-f
ab6c532a37ad        aos:3.3.0-660              "/usr/bin/aos_launch…"   20 hours ago         Up 2 minutes                            aos_controller_1
8e6fd8ae8f08        aos:3.3.0-660              "/usr/bin/aos_launch…"   20 hours ago         Up 2 minutes                            aos_metadb_1
5b6359e21386        aos:3.3.0-660              "/usr/bin/aos_launch…"   20 hours ago         Up 2 minutes                            aos_auth_1
f665ce206f46        aos:3.3.0-660              "/usr/bin/aos_launch…"   20 hours ago         Up 2 minutes                            aos_sysdb_1
335dec5fba44        nginx:1.14.2-upload-echo   "nginx -g 'daemon of…"   20 hours ago         Up 2 minutes                            aos_nginx_1
admin@aos-server:~$

Resetting Database

This procedure deletes all data on the Apstra server to a fresh state.

admin@aos-server:~$ sudo service aos stop
admin@aos-server:~$ sudo rm -rf /var/lib/aos/db/*
admin@aos-server:~$ sudo service aos start
admin@aos-server:~$

Migrating Database

Warning

If you bring up a new Apstra server with the same IP address as your old Apstra server without any configuration, when the device agents re-register with the new Apstra server they will revert to an unconfigured “Quarantined” state. You must isolate the new Apstra server from the network while you change its IP address, restore the database and restart the Apstra server.

If you want to maintain the same IP address for the new Apstra server, then bring up a new Apstra server VM with the same version as the original Apstra server, with a temporary IP address. After migrating an aos_backup to the new Apstra server, the original Apstra server will be shut down and the IP address will be changed to the original IP on the new server. This process is recommended for users using on-box device system agents.

If you want to use a new Apstra server with a new IP address, for the on-box device system agents, you must manually reconfigure the aos.conf file for each on-box device system agent. This is not required for off-box device system agents.

To migrate an active instance from one server to another:

  1. Backup the original Apstra server using the sudo aos_backup command and copy the snapshot to the new server using a temporary IP on the new Apstra server.

    admin@aos-server:~$ sudo aos_backup
====================================================================
  Backup operation completed successfully.
====================================================================
New AOS snapshot: 2020-07-27_22-49-34
admin@aos-server:~$

  2. Compress and move the snapshot directory to the new Apstra server. This example uses the scp command to copy the file to the new Apstra server using a different IP address.

    admin@aos-server:~$ sudo tar zcvf aos_backup.tar.gz -C /var/lib/aos/snapshot/ 2020-07-27_22-49-34
2020-07-27_22-49-34/
2020-07-27_22-49-34/comment.txt
2020-07-27_22-49-34/aos_restore
2020-07-27_22-49-34/aos.data.tar.gz
admin@aos-server:~$ sudo chown admin:admin aos_backup.tar.gz
admin@aos-server:~$ scp aos_backup.tar.gz admin@172.20.203.4:
Apstra Operating System (AOS) Virtual Appliance

Password:
aos_backup.tar.gz                                   100%   20MB 140.9MB/s   00:00
admin@aos-server:~$

  3. After the snapshot has been removed from the old Apstra server, disconnect the old Apstra server by stopping service or completely shutting down the Apstra server VM.

    admin@aos-server:~$ sudo service aos stop
admin@aos-server:~$

  4. If you want to use the same IP address, you must manually reconfigure the eth0 interface on the new Apstra server to the IP address of the old Apstra server. See Configuring Static Management IP Address for more information.

  5. On the new Apstra server, uncompress the tar.gz file.

    admin@aos-server:~$ tar zxvf aos_backup.tar.gz
2020-07-27_22-49-34/
2020-07-27_22-49-34/comment.txt
2020-07-27_22-49-34/aos_restore
2020-07-27_22-49-34/aos.data.tar.gz
admin@aos-server:~$

  6. Restore the database on the new Apstra server with the snapshot aos_restore command.

    admin@aos-server:~$ cd 2020-07-27_22-49-34
admin@aos-server:~/2020-07-27_22-49-34$ sudo bash aos_restore
[sudo] password for admin:
====================================================================
  Backup operation completed successfully.
====================================================================
New AOS snapshot: 2020-07-27_23-07-13
Stopping aos_sysdb_1      ... done
Stopping aos_auth_1       ... done
Stopping aos_controller_1 ... done
Stopping aos_nginx_1      ... done
Stopping aos_metadb_1     ... done
(Reading database ... 110457 files and directories currently installed.)
Removing aos-compose (3.3.0-658) ...
Processing triggers for ureadahead (0.100.0-21) ...
Processing triggers for systemd (237-3ubuntu10.41) ...
tar: Removing leading `/' from member names
/etc/aos/aos.conf
/etc/aos-credential/secret_key
/var/lib/aos/db/
/var/lib/aos/db/_AosController-000000005f1f376f-0003998b-checkpoint
/var/lib/aos/db/_AosSysdb-000000005f1f376d-000a90ba-log-valid
/var/lib/aos/db/_Main-000000005f1f376f-000569a8-checkpoint
/var/lib/aos/db/_Central-000000005f1f376e-000da3de-checkpoint-valid
/var/lib/aos/db/_Central-000000005f1f376e-000da3de-log
/var/lib/aos/db/_Main-000000005f1f376f-000569a8-log-valid
/var/lib/aos/db/_AosAuth-000000005f1f376d-000a40ff-log
/var/lib/aos/db/_Auth-000000005f1f376e-000f2d35-log-valid
/var/lib/aos/db/_Auth-000000005f1f376e-000f2d35-checkpoint-valid
/var/lib/aos/db/_Metadb-000000005f1f376d-000cb9a9-checkpoint-valid
/var/lib/aos/db/_Central-000000005f1f376e-000da3de-checkpoint
/var/lib/aos/db/_Metadb-000000005f1f376d-000cb9a9-log
/var/lib/aos/db/_Credential-000000005f1f376e-000d740e-log-valid
/var/lib/aos/db/_AosAuth-000000005f1f376d-000a40ff-checkpoint-valid
/var/lib/aos/db/_Metadb-000000005f1f376d-000cb9a9-checkpoint
/var/lib/aos/db/_Main-000000005f1f376f-000569a8-log
/var/lib/aos/db/_AosSysdb-000000005f1f376d-000a90ba-checkpoint-valid
/var/lib/aos/db/_AosController-000000005f1f376f-0003998b-log-valid
/var/lib/aos/db/_Auth-000000005f1f376e-000f2d35-checkpoint
/var/lib/aos/db/_AosSysdb-000000005f1f376d-000a90ba-log
/var/lib/aos/db/_AosSysdb-000000005f1f376d-000a90ba-checkpoint
/var/lib/aos/db/_AosAuth-000000005f1f376d-000a40ff-log-valid
/var/lib/aos/db/blueprint_backups/
/var/lib/aos/db/blueprint_backups/6b90ccfd-a1e0-4473-83e7-d62bce24635f/
/var/lib/aos/db/blueprint_backups/6b90ccfd-a1e0-4473-83e7-d62bce24635f/47/
/var/lib/aos/db/blueprint_backups/6b90ccfd-a1e0-4473-83e7-d62bce24635f/47/graph.json.zip
/var/lib/aos/db/blueprint_backups/6b90ccfd-a1e0-4473-83e7-d62bce24635f/47/graph.md5sum
/var/lib/aos/db/_Central-000000005f1f376e-000da3de-log-valid
/var/lib/aos/db/_Auth-000000005f1f376e-000f2d35-log
/var/lib/aos/db/_Credential-000000005f1f376e-000d740e-log
/var/lib/aos/db/_Credential-000000005f1f376e-000d740e-checkpoint
/var/lib/aos/db/_Credential-000000005f1f376e-000d740e-checkpoint-valid
/var/lib/aos/db/.devpi/
/var/lib/aos/db/.devpi/server/
/var/lib/aos/db/.devpi/server/.nodeinfo
/var/lib/aos/db/.devpi/server/.secret
/var/lib/aos/db/.devpi/server/.sqlite
/var/lib/aos/db/.devpi/server/.serverversion
/var/lib/aos/db/.devpi/server/.event_serial
/var/lib/aos/db/_AosController-000000005f1f376f-0003998b-log
/var/lib/aos/db/_Main-000000005f1f376f-000569a8-checkpoint-valid
/var/lib/aos/db/_Metadb-000000005f1f376d-000cb9a9-log-valid
/var/lib/aos/db/_AosAuth-000000005f1f376d-000a40ff-checkpoint
/var/lib/aos/db/_AosController-000000005f1f376f-0003998b-checkpoint-valid
/var/lib/aos/anomaly/
/var/lib/aos/anomaly/_Anomaly-000000005f1f36a4-000aaa68-checkpoint-valid
/var/lib/aos/anomaly/_Anomaly-000000005f1f331b-0000e8eb-checkpoint
/var/lib/aos/anomaly/_Anomaly-000000005f1f376f-00002176-checkpoint
/var/lib/aos/anomaly/_Anomaly-000000005f1f376f-00002176-log
/var/lib/aos/anomaly/_Anomaly-000000005f1f331b-0000e8eb-log
/var/lib/aos/anomaly/_Anomaly-000000005f1f2abc-0000a867-log
/var/lib/aos/anomaly/_Anomaly-000000005f1f331b-0000e8eb-checkpoint-valid
/var/lib/aos/anomaly/_Anomaly-000000005f1f2abc-0000a867-checkpoint
/var/lib/aos/anomaly/_Anomaly-000000005f1f36a4-000aaa68-checkpoint
/var/lib/aos/anomaly/_Anomaly-000000005f1f376f-00002176-log-valid
/var/lib/aos/anomaly/_Anomaly-000000005f1f36a4-000aaa68-log
/var/lib/aos/anomaly/_Anomaly-000000005f1f331b-0000e8eb-log-valid
/var/lib/aos/anomaly/_Anomaly-000000005f1f2abc-0000a867-checkpoint-valid
/var/lib/aos/anomaly/_Anomaly-000000005f1f2abc-0000a867-log-valid
/var/lib/aos/anomaly/_Anomaly-000000005f1f36a4-000aaa68-log-valid
/var/lib/aos/anomaly/_Anomaly-000000005f1f376f-00002176-checkpoint-valid
/opt/aos/aos-compose.deb
/opt/aos/frontend_images/
/opt/aos/frontend_images/aos-web-ui.zip
Selecting previously unselected package aos-compose.
(Reading database ... 110440 files and directories currently installed.)
Preparing to unpack /opt/aos/aos-compose.deb ...
Unpacking aos-compose (3.3.0-658) ...
Setting up aos-compose (3.3.0-658) ...
Processing triggers for ureadahead (0.100.0-21) ...
Processing triggers for systemd (237-3ubuntu10.41) ...
Starting aos_nginx_1      ... done
Starting aos_sysdb_1      ... done
Starting aos_controller_1 ... done
Starting aos_metadb_1     ... done
Starting aos_auth_1       ... done
admin@aos-server:~/2020-07-27_22-49-34$

  7. The aos_restore command automatically starts the service when it is finished restoring the database. Verify the Apstra server is running.

    admin@aos-server:~/2020-07-27_22-49-34$ service aos status
* aos.service - LSB: Start AOS management system
   Loaded: loaded (/etc/init.d/aos; generated)
   Active: active (exited) since Mon 2020-07-27 20:23:09 UTC; 2h 45min ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 0 (limit: 4915)
   CGroup: /aos.service
admin@aos-server:~/2020-07-27_22-49-34$

  8. Verify that your devices are online in their “Active” state.

    _images/devices_active.png

Resetting Apstra Server VM Password

Your Fabric is safe.

You’ll need to reboot the Apstra server VM, but any deployed Fabric will not be impacted.

If you lose your admin password for the Apstra server VM, and you still have console access to the Apstra server VM, you can reset the password.

  1. Attach to the Apstra server console and send a “reset” signal to the VM. To access the GRUB menu, immediately press the esc or shift key in the console on reboot.

    _images/230_aos-vm-password-recovery1.png

  2. Select Advanced options for Ubuntu. For versions 2.3 and later, use username admin and password apstra.

    _images/230_aos-vm-password-recovery2.png

  1. At the next GRUB menu, select the first (recovery mode) option.

    _images/230_aos-vm-password-recovery3.png

  2. From the Recovery Menu, select root, then press Enter to enter a root shell prompt.

    _images/230_aos-vm-password-recovery5.png

  3. At the root shell prompt enter mount -o rw,remount / then passwd admin to reset the password for the default admin user for the Apstra server VM Linux CLI.

  4. Enter sync then reboot to reboot the VM.

    _images/230_aos-vm-password-recovery4.png

  5. After reboot, you can log into the Apstra server VM Linux CLI as user admin with the new password.