similar to: NBDE, clevis and tang for non-root disk

Radu Radutiu wrote: > On Tue, Nov 27, 2018 at 3:14 PM mark <m.roth at 5-cent.us> wrote: > >> What we do is to have the encryption key of the secondary filesystem in >> /etc/crypttab, which is, of course, 600. As it boots, it decrypts from >> that as it mounts the rest of the system. >> > Thanks, this is working as expected and it gave me the hint needed to

On Tue, Nov 27, 2018 at 3:14 PM mark <m.roth at 5-cent.us> wrote: > What we do is to have the encryption key of the secondary filesystem in > /etc/crypttab, which is, of course, 600. As it boots, it decrypts from > that as > it mounts the rest of the system. > > mark > Thanks, this is working as expected and it gave me the hint needed to find the actual

This is about Network-Bound Disk Encryption (NBDE) not to be confused of course with NBD! NBDE is where you use disk encryption in your virtual machines. But instead of having to type a passphrase when the guest boots, there is a network server which gives out tokens, so as long as the guest is booted from the trusted network it is able to boot unattended. In RHEL[1] we have three pieces of

We've been required to encrypt h/ds, and so have been rolling that out over the last year or so. Thing is, you need to put in a password, of course, to boot the system. My manager found a way to allow us to reboot without being at the system's keyboard, a package called clevis. Works fine... except in a couple of very special cases. Those systems, the problem is that, due to older

On Fri, 8 Jun 2018, m.roth at 5-cent.us wrote: > We've been required to encrypt h/ds, and so have been rolling that out > over the last year or so. Thing is, you need to put in a password, of > course, to boot the system. My manager found a way to allow us to reboot > without being at the system's keyboard, a package called clevis. Works > fine... except in a couple of very

On 06/08/18 12:01, m.roth at 5-cent.us wrote: > Valeri Galtsev wrote: >> >> >> On 06/08/18 10:27, m.roth at 5-cent.us wrote: >>> John Hodrien wrote: >>>> On Fri, 8 Jun 2018, m.roth at 5-cent.us wrote: >>>> >>>>> We've been required to encrypt h/ds, and so have been rolling that out >>>>> over the last year or

On 06/08/18 10:27, m.roth at 5-cent.us wrote: > John Hodrien wrote: >> On Fri, 8 Jun 2018, m.roth at 5-cent.us wrote: >> >>> We've been required to encrypt h/ds, and so have been rolling that out >>> over the last year or so. Thing is, you need to put in a password, of >>> course, to boot the system. My manager found a way to allow us to reboot

Valeri Galtsev wrote: > > > On 06/08/18 10:27, m.roth at 5-cent.us wrote: >> John Hodrien wrote: >>> On Fri, 8 Jun 2018, m.roth at 5-cent.us wrote: >>> >>>> We've been required to encrypt h/ds, and so have been rolling that out >>>> over the last year or so. Thing is, you need to put in a password, of >>>> course, to boot the

John Hodrien wrote: > On Fri, 8 Jun 2018, m.roth at 5-cent.us wrote: > >> We've been required to encrypt h/ds, and so have been rolling that out >> over the last year or so. Thing is, you need to put in a password, of >> course, to boot the system. My manager found a way to allow us to reboot >> without being at the system's keyboard, a package called clevis.

hi, we have successfully implemented at tang/clevis environment for automatically entering luks keys and booting hosts without operator intervention. Now we would like to use this as well on ipv6 networks, but I do not seem to get it to work. I have already posted this issue to the dracut devs github issue tracker ( https://github.com/dracutdevs/dracut/issues/554) but no response so far. Maybe

Hello all, I am having an issue with guestmount in respect to live instances and I was hoping someone might have an idea where I've gone wrong. The following output is from my shell session, if there's any more information needed please let me know and I'll happily provide it. [root at longitude ~]# virt-filesystems -d F16-rawhide/dev/sda2 /dev/sda3 [root at longitude ~]#

Running this: $ virt-builder fedora-23 -o vm1.qcow2 --format qcow2 \ --root-password password:123456 --selinux-relabel --size 100G And, importing vm1.qcow2 into libvirt results in these "corrupted metadata buffer" errors, in a continuous loop, on the serial console: [...] [ 51.687988] XFS (vda3): First 64 bytes of corrupted metadata buffer: [ 51.688938]

Frank Cox wrote: >> > so if it would work, replace shortname with short and short1? > > With all of this hokey-pokey surrounding licensing and mac addresses, I > wonder if this outfit is actually still in compliance with the terms of > their license for this software, whatever it may be? > > If the software licensed to run only on Machine X and Machine X has now >

Valeri Galtsev wrote: > On 06/08/18 15:26, m.roth at 5-cent.us wrote: <SNIP> >>> On a similar note: one of the companies whose software scientists here >>> were using a lot (IDL is a product) changed hand several times, and >>> last owner changed licensing terms and stopped signing perpetual licenses. >>> With perpetual license you were able to keep

On 2018-06-08, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote: > > Frank, I 100% agree with you. The only case with spoofed MAC address and > license that may have chance to stand in court will be if all below are > true: > > 1. the company issued perpetual license. > 2. the company does not exist Based on what's written below, it seems like the company does

Valeri Galtsev wrote: > On 06/08/18 13:48, m.roth at 5-cent.us wrote: >> Frank Cox wrote: >>>>> so if it would work, replace shortname with short and short1? >>> >>> With all of this hokey-pokey surrounding licensing and mac addresses, I >>> wonder if this outfit is actually still in compliance with the terms of >>> their license for this

On 06/08/18 15:45, m.roth at 5-cent.us wrote: > Valeri Galtsev wrote: >> On 06/08/18 15:26, m.roth at 5-cent.us wrote: > <SNIP> >>>> On a similar note: one of the companies whose software scientists here >>>> were using a lot (IDL is a product) changed hand several times, and >>>> last owner changed licensing terms and stopped signing perpetual

(depends on Advance Storage Configuration patch) This patch adds the option of requesting, at install time, that swap LVs be encrypted. The modifications include: * Introduction of the ovirt_swap_encrypt install parameter * Inclusion of all required packages * Inclusion of required kernel modules * Introduction of /etc/ovirt-crypttab to hold encrypted swap configuration (Couldn't use

> > so if it would work, replace shortname with short and short1? With all of this hokey-pokey surrounding licensing and mac addresses, I wonder if this outfit is actually still in compliance with the terms of their license for this software, whatever it may be? If the software licensed to run only on Machine X and Machine X has now been junked and replace by Machine Y, then isn't the

I have successfully used the swap option of crypttab (# man crypttab) to encrypt the swap partition dynamically. rc.sysinit enables that swap partition successfully at the right point (after encryption). The same doesn't work for the tmp option of crypttab (# man crypttab). The encrypted partition is present after booting the system. Manually mounting it works but adding