From 157b630a663b6256b26af1b0eaeee0404058307c Mon Sep 17 00:00:00 2001
From: Daniel Juarez <daniel.juarez.gonzalez@cern.ch>
Date: Thu, 7 Apr 2022 17:57:26 +0200
Subject: [PATCH] More AIMS updating

---
 docs/aims2/addinganewimage.md      |  4 +--
 docs/aims2/aims2.md                |  2 --
 docs/aims2/aims2client.md          | 54 +++++++++++++-----------------
 docs/aims2/syncaimstestwithprod.md |  2 +-
 mkdocs.yml                         |  1 -
 5 files changed, 26 insertions(+), 37 deletions(-)

diff --git a/docs/aims2/addinganewimage.md b/docs/aims2/addinganewimage.md
index 2239b42..d87d8ac 100644
--- a/docs/aims2/addinganewimage.md
+++ b/docs/aims2/addinganewimage.md
@@ -5,7 +5,7 @@ The example described below is adding a new Fedora image, as this may happen mor
 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```
+4. Add a new image to AIMS2 ```aims2client addimg --name FEDORA30_X86_64 --arch x86_64 --vmlinuz vmlinuz --initrd initrd.img --description '[UNSUPPORTED] FEDORA 30 FOR X86_64 ARCH' --uefi```
 5. Update the AIMS2 loaders and menu configurations in [AIMS hostgroup Hiera data](https://gitlab.cern.ch/ai/it-puppet-hostgroup-aims/-/blob/qa/data/hostgroup/aims.yaml).
 6. Test `qa` branch, which should correspond to <http://aimstest.cern.ch>
 7. Test your menu item by booting a VM which is configured to boot from the network. You can ensure that your VM boots from the network by setting the VM metadata 'CERN::cern-waitdns' to 'false' and 'LanDB::landb-os' to 'PXELINTEST'.
@@ -16,7 +16,7 @@ The example described below is adding a new Fedora image, as this may happen mor
 
 If you want to test a new image you can follow this example (adapt when needed):
 
-* `aims2 addimg --name C82_X86_64_TEST --arch x86_64 --vmlinuz vmlinuz --initrd initrd.img --description "CENTOS 8.2 X86_64 TEST" --uefi`
+* `aims2client addimg --name C82_X86_64_TEST --arch x86_64 --vmlinuz vmlinuz --initrd initrd.img --description "CENTOS 8.2 X86_64 TEST" --uefi`
 * Using [ipxe](/cheatsheets/ipxe), create a new VM with `LanDB::Os='LINUX'` (aims) or `LanDB::Os='PXELINTEST'` (aimstest)
 * Wait for it to appear on LANDB
 * Download or write a sample Kickstart file such as <http://linux.web.cern.ch/linux/centos8/default.ks>
diff --git a/docs/aims2/aims2.md b/docs/aims2/aims2.md
index a52f31f..1f3d0fa 100644
--- a/docs/aims2/aims2.md
+++ b/docs/aims2/aims2.md
@@ -4,8 +4,6 @@ AIMS2 is the Linux Automated Installations Management Systems serviced provided
 
 AIMS2 allows the user to perform remote PXE (Preboot eXecution Environment) installations, minimising human intervention. Multiple systems can be installed in parallel and the configuration can be easily tailored for specific settings. The system is based, and extends, the Kickstart software from the RedHat distribution.
 
-The previous incarnation of AIMS failed to meet the new modern requirements of IT/FIO and other Linux users at CERN and has prompted a rethink of what Linux Support is providing as a remote installation service. AIMS2 tries to provide viable and effective solutions to some of the short comings of previous versions of AIMS, as expressed by its users and maintainers, whilst trying to minimise the changes to existing individual or group workflows. Some of the new features of AIMS2 include arbitrary PXE boot media management, removal of AFS dependencies, better host/device install tracking, traceability, device authorisation, Kerberos authentication and more.
-
 ## Documentation
 
 ### AIMS2 Resources
diff --git a/docs/aims2/aims2client.md b/docs/aims2/aims2client.md
index 44923cc..08abac7 100644
--- a/docs/aims2/aims2client.md
+++ b/docs/aims2/aims2client.md
@@ -4,7 +4,7 @@ The AIMS2 client allows users to interact with the Linux Automated Installation
 
 ## Install the client
 
-The client is available through YUM for SLC6 and CC7.
+The client is available through YUM for CC7, CS8 and CS9
 
 ```bash
 yum install aims2client
@@ -12,11 +12,7 @@ yum install aims2client
 
 ## Dependencies
 
- The following dependencies must be satisfied to successfully use the client. Installing through YUM "should" resolve these automatically.
-
-* `perl-SOAP-Lite`
-* `perl-Net-DNS`
-* `perl-Authen-KRB5`
+The [RPM dependencies](https://gitlab.cern.ch/linuxsupport/rpms/aims2/-/blob/master/aims2.spec) must be satisfied to successfully use the client. Installing through YUM "should" resolve these automatically.
 
 ## Help
 
@@ -52,7 +48,6 @@ AIMS2 introduces a new layer of authorisation around hosts/devices and PXE boot
 It is necessary to check if the user has permission to interact with a device to try and prevent accidental/malicious installations. At CERN there is no one global source of device ownership and installation permission so AIMS2 relies on a number of CERN data-sources to make a yes or no decision as to whether to grant installation permissions. These sources currently include:
 
 The Network Database (LanDB)
-CDB (Quattor). **To be reviewed**
 LDAP and e-groups
 
 The following short sections outline how AIMS uses these sources to enable it to give a yes or no decision.
@@ -61,12 +56,6 @@ The following short sections outline how AIMS uses these sources to enable it to
 
 If the user is listed as the device's `MAIN USER` or `RESPONSIBLE`, permission is granted for installation.
 
-#### CDB (**To be reviewed**)
-
-AIMS will check the CDB ACL view to see if the user is defined as having root access to the device.
-
-For more information on how your device should be configured in CDB for this check to be successful, please contact <CDB.Support@CERN.CH>
-
 #### Linux Support
 
 To enable Linux Support to efficiently resolve your support request, Linux Support members (members of e-group configured via `EGROUP_LINUXSUPPORT`) will be have permission to interact with any Linux device.
@@ -75,7 +64,7 @@ Linux Support cannot be used for all interactions with devices. This feature is
 
 #### FIO sysadmins
 
-If the device is defined as being in building in 513 or 613 or 9994 (SafeHost) or 9918 (Wigner) or 773 (Network Hub) and the user is defined as a FIO sysadmin (member of the e-group <aims-admins@cern.ch>, configured via `EGROUP_SYSADMINS`), permission is granted.
+If the device is defined as being in building in 513 or 613 or 9994 (SafeHost) or 773 (Network Hub) and the user is defined as a FIO sysadmin (member of the e-group <aims-admins@cern.ch>, configured via `EGROUP_SYSADMINS`), permission is granted.
 
 `EGROUP_AIMSSUPPORT` egroup members (<aims2-cc-admins@cern.ch>) will also be granted permissions.
 
@@ -85,7 +74,7 @@ This configuration of egroups is stored on the AIM2 database.
 
 Some devices that do not fit into the checks above still need to be 'shared' with multiple users. To enable this feature AIMS supports the use of CERN e-groups.
 
-If the device is shared, AIMS is able to map the registered accounts in the Network Database to one or more e-groups. For example, for device LXPLUS204 the Network Database lists the RESPONSIBLE as fs.administrator@cern.ch. In this example, this maps to a service account so it is unlikely that the user will be the FS Administrator. The entry fs.administrator.cern.ch has been defined in AIMS as mapping to two e-groups, it-fio-dep-fs and it-fio-dep-fd. Should the user requesting the installation be defined in either of these e-groups, permission will be granted.
+If the device is shared, AIMS is able to map the registered accounts in the Network Database to one or more e-groups. For example, for device LXPLUS7111 the Network Database lists the RESPONSIBLE as <plus-expertes@cern.ch> so any member part of this one can interact with the mentioned system.
 
 To define a new e-group relationship, please contact <Linux.Support@CERN.CH> with the RESPONSIBLE/MAIN USER and the name(s) of the e-group(s) to map. Please be aware that due to technical limitations with the e-groups interface this mapping may take between 24-48 hours to fully propagate.
 
@@ -99,7 +88,7 @@ Be warned, this process can take 48 hours (please complain to AIS for the delay)
 
 When an image is uploaded, it is owned by you. This means nobody else can remove your image except you and the Linux administration team.
 
-You can share/limit the user of PXE image and kernel via the use of egroups, using the --egroups options. This is discussed later.
+You can share/limit the user of PXE image and kernel via the use of egroups, using the `--egroups` options. This is discussed later.
 
 ## How to use the client
 
@@ -187,7 +176,7 @@ aims2client addhost HOSTNAME [--kickstart=S] [--kopts=S] [--pxe] [--name=S]
 
 To register your host for installation, you must provide the HOSTNAME of the device as given in the Network Database. AIMS2 will then register each interface (hardware address) that is listed in the network database for that HOSTNAME. Only interfaces that are registered should be able to obtain DHCP leases on the CERN network. Should you provide the name of an INTERFACE ALIAS, only the hardware address(es) for that interface will be registered.
 
-To provide a Kickstart file for your installation you should use the --kickstart PATH option, where PATH is either a http:// source, somewhere readable (by linuxsoft.cern.ch) within /afs/cern.ch/, − (STDIN) or a local file. The following examples are valid PATHs:
+To provide a Kickstart file for your installation you should use the `--kickstart PATH` option, where `PATH` is either a `http://` source, somewhere readable (by `linuxsoft.cern.ch`) within `/afs/cern.ch/`, − (STDIN) or a local file. The following examples are valid PATHs:
 
 *../example.ks
 * ../../example.ks
@@ -210,10 +199,7 @@ console=ttyS0,9600 console=ttyS1,9600 console=tty0
 
 The following links provide more information on the available Anaconda options.
 
-* <http://tinyurl.com/rhel−kopts>
-* <http://tinyurl.com/fedora−kopts>
-
-The magic variable IPAPPEND 2 for use with BOOTIF is set by default.
+* <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/kernel_administration_guide/listing_of_kernel_parameters_and_values>
 
 ### Enable PXE at registration
 
@@ -296,14 +282,14 @@ Options `--initrd=path` and `--vmlinuz=path` refer to the file system locations
 
 If you want to check the uploaded boot media files, please refer to:
 
-* http://aims.cern.ch/aims/boot/IMAGENAME/vmlinuz
-* http://aims.cern.ch/aims/boot/IMAGENAME/initrd 
+* <http://aims.cern.ch/aims/boot/IMAGENAME/vmlinuz>
+* <http://aims.cern.ch/aims/boot/IMAGENAME/initrd>
 
 #### Kernel append options
 
-If you know that your home-brewed image/kernel combo requires certain Kernel append options at boot then you can use provide these using the --kopts option.
+If you know that your home-brewed image/kernel combo requires certain Kernel append options at boot then you can use provide these using the `--kopts` option.
 
-These options will then be used when installing this media. An example is the providing of noipv6 for Scientific Linux 5. It's OK to duplicate options on images and hosts, as AIMS will weed out the duplicate entries for you. AIMS will not however check that your options are syntactically correct. It is presumed you have read the appropriate documentation on your Kernel and know what you are doing to some degree. A common example is:
+These options will then be used when installing this media. An example is the providing of `noipv6`. It's OK to duplicate options on images and hosts, as AIMS will weed out the duplicate entries for you. AIMS will not however check that your options are syntactically correct. It is presumed you have read the appropriate documentation on your Kernel and know what you are doing to some degree. A common example is:
 
 ```bash
 --kopts="ramdisk_size=36000 noipv6 ksdevice=link"
@@ -344,7 +330,7 @@ name, architecture, kernel append options, description
 To display more information about PXE boot media add the -ALL or -FULL options as per the example
 
 ```bash
-aims2client showimage slc4X_i386 -ALL
+aims2client showimage CC7_X86_64 --all
 ```
 
 The additional information displayed, extending the above is:
@@ -356,10 +342,10 @@ source of Kernel, md5sum, size (kb), source of initrd, md5sum, size (kb), e-grou
 `NAME` can also be provided with basic wildcards. Consider the example below.
 
 ```bash
-showimage slc5*
+showimage cc7*
 ```
 
-This will return PXE boot media whose name begings with `slc5`
+This will return PXE boot media whose name begings with `cc7`
 
 !!! warning
     Please note, in some terminals it is necessary to escape * with either \* or "*"
@@ -390,10 +376,10 @@ To display a list of PXE boot targets available for installation please use the
 aims2client showimage \*
 ```
 
-If you just wanted to see what SLC5 targets are available you would execute
+If you just wanted to see what CC7 targets are available you would execute
 
 ```bash
-aims2client showimage slc5*
+aims2client showimage cc7*
 ```
 
 ### Disabling PXE for a device
@@ -415,5 +401,11 @@ Providing the `-v(erbose)` option will instruct the client to provide verbose to
 (Optional) To communicate with a particular server, for example the testing server, the `--server` option is available. For example:
 
 ```bash
-aims2client --server=ISLINKY.CERN.CH addhost SLINKY
+aims2client --server=aimstest01 addhost ELNANO
+```
+
+If you just want to use any of the `aimstest.cern.ch` nodes behind the alias, use:
+
+```bash
+aims2client --testserver addhost ELNANO
 ```
diff --git a/docs/aims2/syncaimstestwithprod.md b/docs/aims2/syncaimstestwithprod.md
index c4a11f9..694a039 100644
--- a/docs/aims2/syncaimstestwithprod.md
+++ b/docs/aims2/syncaimstestwithprod.md
@@ -22,4 +22,4 @@ tbag show aims_psqldb_pwd_admin --hg aims
 
 ## Other methods
 
-Feel free to add your own way to do so, maybe you have a simpler way using just commands.
\ No newline at end of file
+Feel free to add your own way to do so, maybe you have a simpler way using just commands.
diff --git a/mkdocs.yml b/mkdocs.yml
index 655615d..40bd13a 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -66,7 +66,6 @@ nav:
         - 'Sync AIMSTEST and AIMS': aims2/syncaimstestwithprod.md
         - 'AIMS2 server': aims2/aims2server.md
         - 'AIMS2 client': aims2/aims2client.md
-        - 'AIMS2 how to': aims2/aims2how2.md
         - 'Legacy workaround': aims2/aims2legacyworkaround.md
         - 'Troubleshooting': aims2/troubleshooting.md
         - 'Error compilation': aims2/errorcollection.md
-- 
GitLab