diff --git a/docs/aims2/addinganewimage.md b/docs/aims2/addinganewimage.md
index 567166856e1529417cbe396a0a2845fa8fddc2c3..2239b42e6f49e894786191b585ef6adb140e61e8 100644
--- a/docs/aims2/addinganewimage.md
+++ b/docs/aims2/addinganewimage.md
@@ -1,8 +1,8 @@
# Adding a new image to the base pxe boot menu
-The example described below is adding a new fedora image, as this will happen more frequently than adding a CC image - though the process will remain largely the same
+The example described below is adding a new Fedora image, as this may happen more frequently than adding a CentOS image - though the process will remain largely the same. As of today we do not do add more images than RHEL/CentOS, but this can help other use cases.
-1. Ensure that the distribution (fedora for example) is mirrored. You may need to update /mnt/data2/bin/new-lxsoft-sync-fedora (please refer to [Architecture](../../distributions/architecture))
+1. Ensure that the distribution (fedora for example) is mirrored. You may need to update `/mnt/data2/bin/new-lxsoft-sync-fedora` (please refer to [Architecture](../../distributions/architecture))
2. Ensure that the rsync process for your distribution is complete (check [http://linuxsoft.cern.ch/fedora/linux/releases/](http://linuxsoft.cern.ch/fedora/linux/releases/))
3. Download a copy of the vmlinuz and initrd for the new release ```wget http://linuxsoft.cern.ch/fedora/linux/releases/30/Server/x86_64/os/isolinux/vmlinuz && wget http://linuxsoft.cern.ch/fedora/linux/releases/30/Server/x86_64/os/isolinux/initrd.img```
4. Add a new image to AIMS2 ```aims2 addimg --name FEDORA30_X86_64 --arch x86_64 --vmlinuz vmlinuz --initrd initrd.img --description '[UNSUPPORTED] FEDORA 30 FOR X86_64 ARCH' --uefi```
@@ -25,5 +25,3 @@ If you want to test a new image you can follow this example (adapt when needed):
aims2client addhost djuarezg-c82-m --kickstart default.ks --kopts "ip=dhcp inst.repo=http://linuxsoft.cern.ch/cern/centos/8.2-testing/BaseOS/x86_64/os inst.addrepo=CERN,http://linuxsoft.cern.ch/cern/centos/8.2-testing/CERN/x86_64/ inst.addrepo=locmap,http://linuxsoft.cern.ch/internal/repos/potd8-stable/x86_64/os/ ks=http://linux.web.cern.ch/linux/centos8/default.ks" --pxe --name C82_X86_64_TEST
```
* Wait for the host config to sync, eventually your VM will PXE boot using your KS file and options
-
-**NOTE: Another option would be to use `aimstest01` for testing new images directly on <https://gitlab.cern.ch/linuxsupport/rpms/aims2-loaders> without having to register your new host**
diff --git a/docs/aims2/aims2.md b/docs/aims2/aims2.md
index f302d328968a5e17a3c2e9eee4ee472ba43ba73a..0c5f6af6ef73476689878e35d3de51fc5f706a41 100644
--- a/docs/aims2/aims2.md
+++ b/docs/aims2/aims2.md
@@ -100,7 +100,8 @@ Please check [the account management for Oracle accounts](https://cern.service-n
* As of July 2021, these are the existing nodes for the hostgroup:
* **prod**: `aims01`, `aims02`, `aims03`
* **test**: `aimstest01`, `aimstest02`, `aimstest03`
-* AIMS2 applications: <https://gitlab.cern.ch/linuxsupport/aims2>
+* AIMS2 applications: <https://gitlab.cern.ch/linuxsupport/rpms/aims2>
+* Other AIMS2 related components: <https://gitlab.cern.ch/linuxsupport/aims>
## Documentation
diff --git a/docs/aims2/aims2architecture.md b/docs/aims2/aims2architecture.md
index 92e6b0006b618da862277f239ace5b51fa1924b2..f9ad16cca0506feb05e8eab7380eae5684e23cc4 100644
--- a/docs/aims2/aims2architecture.md
+++ b/docs/aims2/aims2architecture.md
@@ -2,7 +2,7 @@
All AIMS instances are under the control of the [corresponding hostgroup](https://gitlab.cern.ch/ai/it-puppet-hostgroup-aims) which also takes care of putting the corresponding Teigi secrets in place.
-Uploaded images are stored on an Oracle database, directly as blobs, as a form of getting delegated backups from the Oracle service.
+Uploaded images are stored on a CephFS share to be shared across all nodes, backed up by our Storage colleagues. Ref. <https://linuxops.web.cern.ch/aims2/aims2/#storage>
AIMS2 servers have the following main components:
@@ -12,10 +12,9 @@ AIMS2 servers have the following main components:
* `dnsmasq` component which serves as differentiation for received requests from the client machines. Depending on its architecture, the server provides a different bootloader.
* For unregistered machines, the differentiation is done on [the DHCP configuration](https://gitlab.cern.ch/network/cfmgr/blob/master/cfmgr_modules/hcp/shcp.pm) due to the clients not sending any DHCP option to AIMS servers.
* `httpd` keeps coherence between the database data and the local file system. It acts upon request.
- * It retrieves image blobs and stores them into the local file system under `/tftpboot/aims/boot/`
- * It stores the specific `pxelinux` or `grub` configurations for clients under `/tftpboot/aims/config/`
+ * It stores image blobs in the mounted CephFS share `/aims_share/tftpboot/aims/boot/`
+ * It stores the specific `pxelinux` or `grub` configurations for clients under `/aims_share/tftpboot/aims/config/`
* `aims2client` is the tool used to interact with the system, for new hosts, images or configurations
* `aims2config` is the tool used to interact with the Oracle DB configuration, such as the Authorization Egroups used by the server to validate certain operations.
-* `aims2restoreimages` is the tool used to interact with the Oracle DB image blobs and help you dump them to disk. This helps to recover from a catastrophic scenario where CephFS content was lost.
All nodes within a hostgroup/LB alias are equally balanced to spread the load. The CephFS share helps keeping all content in sync across all nodes and make it scalable.
diff --git a/docs/aims2/aims2workflows.md b/docs/aims2/aims2workflows.md
index 73b656a26fdb2402ec8b43bdc999ccc5b6ec2373..3979bbb7a8a7d2c5ef9507767cbbf51a20f12a05 100644
--- a/docs/aims2/aims2workflows.md
+++ b/docs/aims2/aims2workflows.md
@@ -1,6 +1,6 @@
# AIMS2 PXE-DHCP workflows
-As of today (April 2021) we use two specific workflows depending on whether we are dealing with a registered machine (present on LANDB) or an unregistered machine (no LANDB registry).
+As of today (April 2022) we use two specific workflows depending on whether we are dealing with a registered machine (present on LANDB) or an unregistered machine (no LANDB registry).
## Use case for unregistered machines
@@ -96,3 +96,9 @@ The workflow implies the following:
## Extra references
* [Nice explanation on how the dnsmasq Proxy-DHCP mode works](https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq)
+
+# Future improvements
+
+* [LOS-900: Having a test environment for DHCP](https://its.cern.ch/jira/browse/LOS-900)
+ * This would be great as it would avoid depending on anyone to test change by change and agreeing on dates and times to do so.
+ * Otherwise sorry for the next souls that need to test changes on these workflows
diff --git a/docs/aims2/errorcollection.md b/docs/aims2/errorcollection.md
index 6241cf879ecea4166a1807e9fb7c0373191477a5..5d9e22ade900f8c9aae55e9d9a4c231dd2544fa0 100644
--- a/docs/aims2/errorcollection.md
+++ b/docs/aims2/errorcollection.md
@@ -4,7 +4,7 @@
This section serves as a log of strange things we saw AIMS2 doing, for the record in case it even helps again.
-We welcome any contribution to this page.
+We welcome any contribution to this page. Ironic and Procurement guys are also contributors to this list.
## UEFI world