I'd like to enable a dhcp range on dhcp01. This would allow me to get to the management interface on a new server we added in that network, which will become bvirthost04. I would like to get this sooner rather than later so we can setup a releng03 on it to compose branched on. This will help us get branched out sooner.
dhcp01 does provide dhcp to builders and various things on the build network, so we do need to be careful.
kevin -- diff --git a/modules/dhcp/files/dhcpd.conf.dhcp01 b/modules/dhcp/files/dhcpd.conf.dhcp01 index 302260b..6a179fa 100644 --- a/modules/dhcp/files/dhcpd.conf.dhcp01 +++ b/modules/dhcp/files/dhcpd.conf.dhcp01 @@ -269,7 +269,8 @@ group macs {
}
-# range 10.5.125.170 10.5.125.189; -# next-server 10.5.125.43; -# filename "pxelinux.0"; +range 10.5.125.170 10.5.125.189; +next-server 10.5.125.43; +filename "pxelinux.0"; + }
On Wed, 2011-08-10 at 11:23 -0600, Kevin Fenzi wrote:
I'd like to enable a dhcp range on dhcp01. This would allow me to get to the management interface on a new server we added in that network, which will become bvirthost04. I would like to get this sooner rather than later so we can setup a releng03 on it to compose branched on. This will help us get branched out sooner.
dhcp01 does provide dhcp to builders and various things on the build network, so we do need to be careful.
+1 -sv
+1. Problem is easy to back out if needed
smooge On Aug 10, 2011 11:36 AM, "seth vidal" skvidal@fedoraproject.org wrote:
On Wed, 2011-08-10 at 11:23 -0600, Kevin Fenzi wrote:
I'd like to enable a dhcp range on dhcp01. This would allow me to get to the management interface on a new server we added in that network, which will become bvirthost04. I would like to get this sooner rather than later so we can setup a releng03 on it to compose branched on. This will help us get branched out sooner.
dhcp01 does provide dhcp to builders and various things on the build network, so we do need to be careful.
+1 -sv
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
-1 we have left the range out on pourpose. You can tail the logs work out the Mac and easily add a static IP.
On Wed, 10 Aug 2011 17:32:15 -0500 Dennis Gilmore dennis@ausil.us wrote:
-1 we have left the range out on pourpose. You can tail the logs work out the Mac and easily add a static IP.
Well, the reason I wanted to do it this way was that I only need to get the management up on some ip to configure it with a static ip. Once thats done I just need to boot and install the machine then configure it with a static ip. After thats done, I can remove/disable the range again.
Was just trying to minimize the changes needed.
Should have been also more clear that I want to revert this once the machine is installed.
kevin
On Wed, Aug 10, 2011 at 16:32, Dennis Gilmore dennis@ausil.us wrote:
-1 we have left the range out on pourpose. You can tail the logs work out the Mac and easily add a static IP.
After doing some thinking, I think our original purpose had flawed assumptions. We didn't want systems just appearing on the .125 that we didn't know about. The problem is that for a system to appear on the .125 and to get a DHCP address, there needs to be physical access to the networks. If an intruder has physical access, they can do multiple items that having a DHCP address would be the least of our worries.
Having a range on for short periods of time would alleviate the need for us to have various hardware systems physically unplugged and replugged several times to get the IMM and other cards to ask for a DHCP address while we try to get them configured. If we have the range for a short time, remove the range after it is needed and alert that the range is in existence on the systems via a cron or puppet alert I think we can manage this risk.
Looking at this more, it doesn't look like we actually need it. :)
The management interface for the new machine should be on the regular network, not the builder network. So, we need to get it switched over and can then configure it via dhcp on noc01.
Sorry for the noise.
Although, it makes me wonder if we shouldn't run arpwatch on noc01 and dhcp01. It would tell us when any new device was added to our network, which I wouldn't expect to happen, but would be nice to know if it did.
kevin
On Thu, Aug 11, 2011 at 12:05, Kevin Fenzi kevin@scrye.com wrote:
Looking at this more, it doesn't look like we actually need it. :)
The management interface for the new machine should be on the regular network, not the builder network. So, we need to get it switched over and can then configure it via dhcp on noc01.
Sorry for the noise.
Although, it makes me wonder if we shouldn't run arpwatch on noc01 and dhcp01. It would tell us when any new device was added to our network, which I wouldn't expect to happen, but would be nice to know if it did.
I think we did have arpwatch on for a short time.. there were complaints about the "spam" and it was removed..
On Thursday, August 11, 2011 01:25:44 PM Stephen John Smoogen wrote:
On Thu, Aug 11, 2011 at 12:05, Kevin Fenzi kevin@scrye.com wrote:
Looking at this more, it doesn't look like we actually need it. :)
The management interface for the new machine should be on the regular network, not the builder network. So, we need to get it switched over and can then configure it via dhcp on noc01.
Sorry for the noise.
Although, it makes me wonder if we shouldn't run arpwatch on noc01 and dhcp01. It would tell us when any new device was added to our network, which I wouldn't expect to happen, but would be nice to know if it did.
I think we did have arpwatch on for a short time.. there were complaints about the "spam" and it was removed..
I ran it on dhcp01 at one point when i was trying to work something out. I forget what it was now. but i shut it down when i was done. im happy to have it running on both.once we get over the inital noise we would raely get any email.
Dennis
infrastructure@lists.fedoraproject.org
-
Dennis Gilmore -
Kevin Fenzi -
Seth Vidal -
Stephen John Smoogen