search for: clevi

...n 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 software which help here: - Clevis: Installed in the guest, it replaces the normal askpass script with one which goes to the server to get the decryption token. - Tang: This is the server component, ie. it must always be running on the trusted network so your guests can boot unattended. - JOSE: Something something JSON...

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 software, and *very* expensive licenses that are tied to a MAC address, I have to spoof the MAC address since my users got new(er) machines. Clevis is trying to contact its password server,...

...; find the actual problem. The problem is that the initramfs image generated > by dracut -f does not include the /etc/crypttab from the OS (it only > contains the entry for the root device). Once I have manually added the > other volumes in the /etc/crypttab file from the initramfs image, clevis > is able to decrypt all volumes. Now the question is why the generated > iniramfs image has a different /etc/crypttab. How can I specify > /etc/crypttab for the initramfs so that > furhter kernel updates will not replace it with the wrong file? > Sorry, I think you misunderstood....

...;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 software, and *very* >> expensive licenses that are tied to a MAC address, I have to spoof the >> MAC address since my users got new(er) machines. >&g...

...> 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 software, and *very* > expensive licenses that are tied to a MAC address, I have to spoof the MAC > address since my users got new(er) machines. > > Clevis is trying...

...moment I add another volume to /etc/crypttab the system will no longer boot automatically. A tcpdump on the tang server shows no traffic while the system is stuck at the LUKS password prompt. The second encrypted volume is set up in the same way as the root device and I can unlock the volume using clevis-luks-unlock -d /dev/vda3. I've seen in https://rhelblog.redhat.com/2018/04/13/an-easier-way-to-manage-disk-decryption-at-boot-with-red-hat-enterprise-linux-7-5-using-nbde/ that clevis-luks-askpass.path needs to be enabled but it doesn't make a difference. Any ideas on what 's wrong or...

...ng 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 software, and *very* >>>>> expensive licenses that are tied to a MAC address, I have to spoof the >>>>> MAC address sinc...

...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 software, and *very* >>>> expensive licenses that are tied to a MAC address, I have to spoof the >>>> MAC address since my users got n...

...uired 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 software, and *very* >>> expensive licenses that are tied to a MAC address, I have to spoof the >>> MAC address since my users got new(...

...e hint needed to find the actual problem. The problem is that the initramfs image generated by dracut -f does not include the /etc/crypttab from the OS (it only contains the entry for the root device). Once I have manually added the other volumes in the /etc/crypttab file from the initramfs image, clevis is able to decrypt all volumes. Now the question is why the generated iniramfs image has a different /etc/crypttab. How can I specify /etc/crypttab for the initramfs so that furhter kernel updates will not replace it with the wrong file? Radu

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

> > 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

On 06/08/18 15:26, m.roth at 5-cent.us wrote: > 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

The reason I want to assign one IP to two MAC addresses is that I have one (and only one) user for whom I have to spoof the MAC address (it's a case of stupid software licensing). But... his system is encrypted. Now, we're using clevis to allow reboots without someone being at the keyboard to type in the password. Those of you who've looked at clevis see where this is going: clevis uses the *real* firmware MAC address to get the key from the latchset server... while currently, the dhcpd *only* knows the spoofed MAC address....

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/...

...11/26 16:02:01.557376, 3] ../../source3/smbd/dir.c:734(smbd_dirptr_get_entry) smbd_dirptr_get_entry: mask=[*] found zsh.txt fname=zsh.txt (zsh.txt) [2024/11/26 16:02:01.557392, 3] ../../source3/smbd/dir.c:734(smbd_dirptr_get_entry) smbd_dirptr_get_entry: mask=[*] found Fedora Secure Boot With Clevis.txt fname=Fedora Secure Boot With Clevis.txt (Fedora Secure Boot With Clevis.txt) [2024/11/26 16:02:01.557404, 3] ../../source3/smbd/dir.c:734(smbd_dirptr_get_entry) smbd_dirptr_get_entry: mask=[*] found Shells.txt fname=Shells.txt (Shells.txt) [2024/11/26 16:02:01.557416, 3] ../../source3/smb...