Okay for anyone still around, I was able to get this sorted, it appears that the initial file I was using was either corrupted or maybe a patch for an existing installation.

I've documented the process, copied below for reference. I won't be sharing IBMs RPM's on this post. You should be able to get these directly from IBM's website free of charge, but your mileage may vary.

Installing IBM Datapower on CentOS 8/9 or Rocky Linux 8/9 to your Hypervisor/Cloud Provider

Minimum System Requirements
• 4 vCPU
• 16 GiB RAM
• 80 GiB Disk Space
• 4 Network Interfaces – with DHCP or Statically Assigned IPs
• 2 Available Loop devices – Documented Below
• Default Partitioning will work, can be configured to meet any security requirements (separate LV for VAR for example)
• Installation without a GUI recommended with these below features
◦ “Server Installation” Option
▪ Guest Agents (Drivers for Hypervisor/Cloud recommended)
▪ Remote Management for Linux recommended – SSH and or Cockpit
• Root only account – User accounts are unnecessary
• Security Policy to adhere to any State/Fed requirements (may effect Installation Destination configuration – not documented here).

Configure Timezone and any other settings as required – no specific documentation needed

Sample User: root
Password: your-password

Upon installation check for updates and install a few required repositories.

sudo dnf update -y sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm sudo dnf update -y sudo dnf search schroot sudo dnf install schroot ipvsadm kmod telnet -y

Post installation of dependencies we need to confirm our loop devices are configured.

Confirm what loop devices exist (likely there is only 1) so we’ll need to create some with the below.

List your loop devices:

ls -l /dev/loop* brw-r----- 1 rootls disk 7, 0 Jul 24 17:49 /dev/loop-control

We only have the loop-control device, so create two more loop devices with the below.

mknod -m660 /dev/loop1 b 7 8 mknod -m660 /dev/loop2 b 7 8

Confirm the devices are listed.

ls -l /dev/loop* brw-rw----. 1 root root 7, 8 Nov 27 08:10 /dev/loop1 brw-rw----. 1 root root 7, 8 Nov 27 08:10 /dev/loop2 crw-rw----. 1 root disk 10, 237 Nov 27 07:51 /dev/loop-control

Now transfer or download the Datapower and LibgCrypt RPMs to this system using something line wget or WinSCP depending on access. You can find libgcrypt here (https://rpmfind.net)

Once transferred, you may have to decompress the installation files.

tar -xf idg_lx10540.cd.ASL.prod.tar

Now we can install the program

sudo yum install idg_lx.10540.image.x86_64.rpm idg_lx10540.common.x86_64.rpm

Once installed, you’ll connect to the system via telnet on the system’s loopback address

telnet 127.0.0.1 2200 Initial login is: admin Initial Password is: admin

Confirm to all prompts with Y and then run/create and confirm a new password

You must restart the DataPower Gateway to make the Common Criteria policies effective.

idg# configure terminal;web-mgmt;admin-state enabled;local-address 0 9090;exit Global mode Modify Web management service configuration

Now you can go to the web console via your computer and using the primary IP address. In our example
https://ip-address:9090

You’ll use the login password you created while connected via SSH. You’ll have to create yet another new password.

Once the password is updated, you’ll be able to login and complete the setup by accepting the license agreement.

After accepting the licensing agreement the system will need to reboot. After logging in via SSH you’ll need to restart the web interface.

telnet 127.0.0.1 2200 admin <password> idg<config> idg <config> configure terminal;web-mgmt;admin-state enabled;local-address 0 9090;exit

That's the complete installation process from start to finish. The last step would be to setup initialization of the datapower service upon restart. I'll be working on this sometime this week probably so that the environment is fault tolerant.

@black3dynamite said in Cannot boot to LUKS encrypted drive on Ubuntu - freezes after unlocking drive:

@travisdh1 Is it possible that AppArmor installed by default on all ubuntu installation? Having AppArmor and SELinux both active can cause problems.

I'd love to hear a bit more about apparmor. I am not familiar with it at all. This should be a new thread.

@stacksofplates said in Encryption FS on the Cloud and Remote SSH:

To play devil's advocate, if you're using LUKS the data is encrypted in transit also. So it's not just at rest.

I can't remember off of the top of my head, but you might need FIPS mode enabled for dm-crypt to encrypt in motion as well. I'm lazy and don't feel like looking it up.

@thwr said in Kickstart with LUKS:

@scottalanmiller said in Kickstart with LUKS:

@thwr said in Kickstart with LUKS:

@thwr said in Kickstart with LUKS:

But if the server walks, the TPM walks with it and the security has been totally bypassed. In fact, IMHO, if you have the key on TPM and it decrypts automatically on start up and you had to state if the system was encrypted or not, at best you could say "sort of." While you might get away with saying that it is encrypted, if asked the other way "is the data wide open", the answer would also be yes because it's not encrypted when someone looks at it.

Ah, sorry, misunderstood your posting in the first place. Well, that's chicken-egg. You can either have it decrypt automatically or not. If going for automatic decryption, we have to make sure the machine can't decrypt e.g. when it gets stolen or sold.

For this, storing the key on the host alone, even with TPM, may not be enough (don't know enough about TPM at this point. Sealing to system state seems quite safe, but...). Thus, we need to bring in another factor. Let's call it "location awareness", e.g. pulling the actual key from the network and TPM stores just something to authenticate against the "key server". Server offsite -> no decryption.

Past boot, it is up to you to secure the server by traditional means. Strong passwords, no or strongly secured RS232 TTY and so on.

Exactly, something externally has to trust that the system is where it is supposed to be physically so that it will release the key. We considered using this but decided that security trumped downtime and kept the system requiring human intervention and just accepted large downtimes in the event of a reboot.

Agree, downtime due to a misconfiguration, some failure on the network or the key server would be an issue. What if we look at some back approach: If some removeable storage with a key is present at boot, LUKS will use this key. Otherwise, it tries to pull it from the key server as described above? Should be pretty solid and a backup is in place (key on USB stick) in case something goes south.

This surely is an approach for environments requiring a very high level of security, but I like the idea.

I've seen places do that, pop in a key and use that, but you have to trust that people will remove it immediately and store it somewhere.