similar to: Two MACs for one IP

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

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

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.

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

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 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 software, whatever it may be? >> >> If

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

Leon Fauster via CentOS wrote: > >> Am 29.07.2019 um 22:37 schrieb J Martin Rushton via CentOS >> <centos at centos.org>: >> On 29/07/2019 20:58, mark wrote: >> >>> Moved a server from the datacenter to our secure room. I've changed >>> the DNS, and our dhcpd... and yet, every time it boots, it comes up >>> with the IP it had in 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

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

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

Subject: Re: [CentOS] Centos 7 and MAC address munging Date: Thu, 18 May 2017 06:22:21 +0100 From: James Hogarth <james.hogarth at gmail.com> > > On 17 May 2017 8:53 pm, <m.roth at 5-cent.us> wrote: > >> Odd situation: I've mentioned before that I have several users for whom I >< have to spoof the MAC address, due to a software license. Now, I've got

On 30 June 2017 at 18:58, <m.roth at 5-cent.us> wrote: > Got a problem: a user's workstation froze. He wound up rebooting, without > calling me in first, so I dunno. But, and this is a show-stopper, when it > came up, it came up with the firmware MAC, not the spoofed one. In > /etc/sysconfig/network-scripts/ifcg-eth0, I've got the spoofed MAC > address, and a UUID. In

Odd situation: I've mentioned before that I have several users for whom I have to spoof the MAC address, due to a software license. Now, I've got net.ifnames=0 biosdevname=0 on the grub2 command line, and I've got the spoofed MAC address in /etc/sysconfig/network-sctipts/ifcfg-eth0. But he had a serious problem - X froze, and he thought to reboot, rather than call me. It came up with

-----BEGIN PGP SIGNED MESSAGE----- ============================================================================= CERT(sm) Advisory CA-96.21 Original issue date: September 19, 1996 Last revised: -- Topic: TCP SYN Flooding and IP Spoofing Attacks - ----------------------------------------------------------------------------- *** This advisory supersedes CA-95:01. *** Two

I'm trying to have a go at CLI spoofing. My outbound calls may go out over various VoIP providers, using least cost routing to determine which provider for call destination and time of day. No matter which provider I go out over, i'd like the called party to only see only one of my numbers - that number will be the only number i'll want people to call back on. To test, i've

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 >

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