merge dev-2.1 branch into main

.gitignore

@@ -22,13 +22,13 @@ node_modules/
 *.key
 *.csr
 
-
 # image and tftp default paths
 .images/
 igor_images/
 igor_staged_images/
 pxelinux.cfg/
 kickstarts/
+uefi/
 
 .vscode
 *.suo
@@ -59,3 +59,4 @@ build/
 igor2.zip
 igor2.tar.gz
 
+/db-migrate/db-migrate

INSTALL

@@ -0,0 +1,28 @@
+Install/Upgrade Instructions:
+
+- Run build-igor script with appropriate flags to build the executables. Use
+  the -h flag for usage help. You need the tar archive to do an automated
+  install.
+
+- Copy the igor2.tar.gz file and install-igor script to your target system.
+
+- If you are upgrading Igor's main server or web front-end you will need to
+  stop these applications before running the install-igor script in the next
+  step.
+
+- As root, run the install-igor script for both first-time installation or
+  upgrading from an earlier version. If you have installed Igor in custom
+  or non-traditional locations on your system, you may need to edit some of
+  the path variables in the install-igor script.
+
+
+Important Upgrade Notes:
+
+  This following versions requires a database upgrade when migrating to a
+  later version. After running install-igor but before restarting the server,
+  run the db-migrate application in the newly unpacked folder. Use the -h
+  flag for options if you have installed Igor or its configuration files in
+  non-default locations.
+
+  - v2.0.0
+

README.md

@@ -1,43 +1,69 @@
 # IGOR
 
--------
 Igor is a node reservation manager for clusters that host ad-hoc multi-user/multi-project work.
 
-Users can reserve and provision cluster nodes with net-boot or local-boot images of their choice. Users can also create groups that share access to reservation management.
+Users can reserve and provision cluster nodes with OS images of their choice. Users can also
+create groups that share access to reservation management.
 
-Administrators can fine-tune reservation creation and resource access across a wide variety of settings from open and permissive to regulated and tightly controlled.
+Administrators can fine-tune reservation creation and resource access across a wide variety
+of settings from open and permissive to regulated and tightly controlled.
 
-Igor began as part of the [minimega](https://github.com/sandia-minimega/minimega) toolset. Version 2 is now a sibling project and a significant upgrade from the original.
+The first version of Igor began as part of the [minimega](https://github.com/sandia-minimega/minimega) 
+toolset. Version 2 is a sibling project and a significant upgrade from the original.
 
-## Documentation
+## Documentation and Release Notes
 
 Please visit: https://www.sandia.gov/igor
 
 ## Architecture
-Igor has evolved from a simple scheduling app that updated its entries with a cron job and JSON files to a full-blown client-server architecture communicating through a REST API over HTTPS and backed by a database.
+Igor has evolved from a simple scheduling app that updated its entries with a cron job and
+JSON files to a full-blown client-server architecture communicating through a REST API over
+HTTPS and backed by a database.
 
-The most obvious advantage is now an Igor server can be contacted from anywhere by an Igor client (web-app and CLI versions are included), as long as the server's URL can be reached from the calling computer. From a security standpoint this means users don't have to be given login privileges on the cluster head node to run Igor commands.
+An Igor server can be contacted from anywhere by an Igor client (web-app and CLI versions are
+included), as long as the server's URL can be reached from the calling computer. From a
+security standpoint this means users don't have to be given login privileges on the cluster
+head node to run Igor commands.
 
 ## User Accounts and Groups
-Igor now tracks its own registered users. Even if the client is installed on a general node, login credentials are required to verify the user can access Igor.
+Igor tracks its own registered users. Even if the client is installed on a general node, login
+credentials are required to verify the user can access Igor.
 
-The Igor account system can be configured to use a network's LDAP service for authentication. However, Igor can also track and manage its own local passwords if LDAP isn't available or the cluster team wants to stand up Igor without it.
+The Igor account system can be configured to use a network's LDAP service for authentication
+and account management. However, Igor can also track and manage its own local passwords if
+LDAP isn't available or the cluster team wants to stand up Igor without it.
 
-Groups have been enhanced with Igor now internally creating and maintaining its own, providing flexibility for any user to create a group of users with whom they can share resources. The group owner maintains the power of modifying a group, but they can also transfer ownership to another Igor user if needed. Groups are used throughout Igor to provide command and control access to reservations, distros, and other resources needed by multiple users.
+Groups have been enhanced with Igor either internally creating and maintaining its own or
+syncing with LDAP-created groups. This provides flexibility for any user to create a group
+of users with whom they can share resources. The group owner maintains the power of modifying
+a group, but they can also transfer ownership to another Igor user if needed. Groups are used
+throughout Igor to provide command and control access to reservations, distros, and other
+resources needed by multiple users.
 
 ## OS Image Management
-Igor manages all OS images internally without the relying on third-party apps. Users can upload kernel/initrd file pairs to the server for their exclusive use or to share them with the community. Alternatively, an admin team can turn off user uploading and manage OS's themselves if they wish to keep control over which images can be used.
+Igor manages all OS images internally without the relying on third-party apps. Users can upload
+kernel/initrd file pairs to the server for their exclusive use or to share them with the
+community. Alternatively, an admin team can turn off user uploading and manage OS's themselves
+if they wish to control which images are allowed to run on cluster resources.
 
-## No Dependencies for Local Boot
-The old Igor required a third-party application to handle booting an image locally on an assigned node. Igor now handles this case completely on its own. Working with an admin to provide proper pre- and post-boot scripts is required.
+### Net or Local Boot
+Igor's leverages PXE and TFTP to netboot images by default. However, it can also boot an image
+locally on an assigned node. Working with an admin to provide proper pre- and post-boot scripts
+is required. Both BIOS and UEFI hardware boot configurations are supported.
 
 ## Timely Reminders
-Igor v1 sent out a single message to a user when a reservation was nearing expiration, and if Igor was offline and missed the message window, no email would be sent. Igor no longer misses these reminders and sends out a wider variety of notices when current or impending status changes merit getting a user's attention.
+Igor sends out a wide variety of email notices when current or impending status changes merit
+getting a user's attention.
 
 ## Greater Administrative Control
-Igor comes with a plethora of new administrative options for cluster admin teams, both in external configuration and within Igor itself.
+Igor comes with a plethora of administrative options for cluster admin teams, both in
+external configuration and within Igor itself.
 
-On the inside, admins can now get access to many privileged commands that help them manage Igor and cluster scheduling interactively. Chief among these is the introduction of host policies, which allow admins to customize how long a host can run a single reservation, fencing off hosts for exclusive use by select user groups, or shutting off scheduling for particular nodes during planned down time like maintenance or holidays.
-
-On the configuration side there are many settings that set down limits of node usage, reservation scheduling windows, user file upload capabilities and more.
+On the inside, admins get access to many privileged commands that help them manage Igor and
+cluster scheduling interactively. For example, host policies allow admins to customize how
+long a host can run a single reservation, can fence off hosts for exclusive use by select
+user groups, or shut off reservation scheduling for particular nodes during planned downtime
+like routine maintenance periods or holidays.
 
+On the configuration side there are many settings that set down limits of node usage,
+reservation scheduling windows, user file upload capabilities and more.

build.sh → build-igor

@@ -6,14 +6,15 @@ normal=$(tput sgr0)
 
 USAGE="Usage: build.sh [-server] [-cli] [-web] [-n] [-z] [-h|-help]"
 HELP="
-This script will build Igor apps. By default all apps are built, otherwise
-specify ${bold}-server${normal}, ${bold}-cli${normal} and/or ${bold}-web${normal} flags to build the apps of your choice.
+This script builds Igor applications. By default, all applications are built.
+To build specific applications, use the ${bold}-server${normal}, ${bold}-cli${normal}, and/or ${bold}-web${normal} flags.
 
 Use the ${bold}-n${normal} flag to run npm install and update prior to building the web app.
-Note the script will always act as though the -n flag is present if the folder
-web/node_modules or the file web/package-lock.json doesn't exist.
+Note that the script will always act as though the flag is present if the
+web/node_modules folder or the web/package-lock.json file does not exist.
 
-The ${bold}-z${normal} flag can be included to create a tar archive of the resulting build."
+Include the ${bold}-z${normal} flag to create a tar archive of the resulting build.
+The tar archive is required for running the companion ${bold}install-igor${normal} script."
 
 while [[ $# -gt 0 ]]; do
    case $1 in
@@ -147,6 +148,15 @@ if [[ $BUILD_ALL == true || $BUILD_SERVER == true ]]; then
    cp cmd/igor-server/*.yaml build/etc
    cp igor-extra/igor.logrotate build/igor-extra
    cp igor-extra/igor-server.service build/igor-extra
+   echo -n "and database migration tool... "
+   rm -f db-migrate/db-migrate
+   db_migrate=$(go build -ldflags "$LDFLAGS" -o db-migrate ./db-migrate 2>&1 >/dev/null)
+   if [ $? -ne 0 ]; then
+      echo "$db_migrate"
+      echo "Go encountered an error... db-migrate build aborted."
+   fi
+   cp -r db-migrate build
+   rm build/db-migrate/migrate.go
    echo "done."
 fi
 

cmd/igor-server/igor-clusters.yaml

@@ -27,65 +27,78 @@ krypton:
     #   policy:   (requried if not 'default') Name of a host policy that should be applied to this host. Default policy is
     #             used if none specified. It is not required to provide this field when first setting up igor. Subsequent
     #             use of host policies will update your cluster configuration file with the correct policy applied to each node.
+    #   bootMode: (required) options are 'bios'(legacy) or 'uefi'. Select the pxe boot system this host is configured to.
     1:
       mac: 00:00:00:00:00:00
       eth: Et4/1/1
       ip: 192.168.0.1
       policy: default
+      bootMode: bios
     2:
       mac: 00:00:00:00:00:00
       hostname: zod          # notice here we use the optional 'hostname' field. Igor still presents the node as 'kn2' to
                              # users, but any network communication with the node will use this hostname instead.
       eth: Et4/2/1
       ip: 192.168.0.2
       policy: default
+      bootMode: bios
     3:
       mac: 00:00:00:00:00:00
       eth: Et4/3/1
       ip: 192.168.0.3
       policy: default
+      bootMode: bios
     4:
       mac: 00:00:00:00:00:00
       eth: Et4/4/1
       ip: 192.168.0.4
       policy: default
+      bootMode: bios
     5:
       mac: 00:00:00:00:00:00
       eth: Et4/5/1
       ip: 192.168.0.5
       policy: default
+      bootMode: bios
     6:
       mac: 00:00:00:00:00:00
       eth: Et4/6/1
       ip: 192.168.0.6
       policy: default
+      bootMode: bios
     7:
       mac: 00:00:00:00:00:00
       eth: Et4/7/1
       ip: 192.168.0.7
       policy: default
+      bootMode: bios
     8:
       mac: 00:00:00:00:00:00
       eth: Et4/8/1
       ip: 192.168.0.8
       policy: default
+      bootMode: bios
     9:
       mac: 00:00:00:00:00:00
       eth: Et4/9/1
       ip: 192.168.1.9
       policy: default
+      bootMode: bios
     10:
       mac: 00:00:00:00:00:00
       eth: Et4/10/1
       ip: 192.168.0.10
       policy: default
+      bootMode: bios
     11:
       mac: 00:00:00:00:00:00
       eth: Et4/11/1
       ip: 192.168.0.11
       policy: default
+      bootMode: bios
     12:
       mac: 00:00:00:00:00:00
       eth: Et4/12/1
       ip: 192.168.0.12
       policy: default
+      bootMode: bios