So I'm running into some issues and I'm sure it's a minor brain fart on my part. But the documentation has not squared me away.
I have a cobbler server running DHCP for 3 networks, my cobbler server has 3 interfaces and I have 3 dhcp stanzas (whatever).
I can set a different next server, which is the interface IP on that subnet/vlan. No issue. I can build a system from the 10.13.4 network just fine. But if I try to build from the 10.13.200 net, I can get a dhcp address, load the kernel, but the issue is the Distro has the IP address from the 10.13.4.x network in it so the pxelinux.cfg/default has the wrong subnet/vlan hardcoded; and thus tries to load the kickstart
LABEL CentOS7-x86_64_Standard kernel /images/CentOS7-x86_64/vmlinuz MENU LABEL CentOS7-x86_64_Standard append initrd=/images/CentOS7-x86_64/initrd.img ksdevice lang= kssendmac text ks=http://10.13.4.101/cblr/svc/op/ks/profile/CentOS7-x86_64_Standard ipappend 2
So obviously if a host is on the 10.13.200 net, receives a 10.13.200.x address, and starts booting, cobbler is sending it that kickstart line and it should not be going to 10.13.4.101 when the local network is ready to receive at 10.13.200.101.
The metadata tree has the 10.13.4.101 address, and I thought about setting it to $next_server, but it seems if I do it in the profile via cobbler_web, it over writes the default file with 10.13.4.101 (the cobbler host server IP)
I've removed $next-server from the cobbler settings file
#next_server: 10.13.4.101
But server is still configured.
server: 10.13.4.101
So the issue is really the server configuration inside settings. it mentions --server-override, but I don't want to have a handful of profiles for the same image.. I would like to just boot up a server and say use Profile-CentOS-standard and ignore which network it's coming from., want wildcards or other to figure things out.
Any ideas? really i've been searching and "nothing" I've found has made me understand where I'm falling short. -dhcp-tags, --server-override
Thanks tory
################## DHCP ############ ddns-update-style interim;
allow booting; allow bootp;
ignore client-updates; set vendorclass = option vendor-class-identifier;
subnet 10.13.4.0 netmask 255.255.255.0 { option routers 10.13.4.6; option domain-name-servers 10.13.4.220, 10.13.7.101, 10.13.7.102; option domain-name "eng.domain.net"; option subnet-mask 255.255.255.0; range dynamic-bootp 10.13.4.75 10.13.4.99; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server 10.13.4.101; }
subnet 10.13.5.0 netmask 255.255.255.0 { option routers 10.13.5.6; option domain-name-servers 10.13.4.220, 10.13.7.101, 10.13.7.102; option domain-name "eng.domain.net"; option subnet-mask 255.255.255.0; range dynamic-bootp 10.13.5.220 10.13.5.239; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server 10.13.5.100; }
subnet 10.13.200.0 netmask 255.255.255.0 { option routers 10.13.200.6; option domain-name-servers 216.249.24.15, 10.13.6.56; option domain-name "gc.sv.domain.net"; option subnet-mask 255.255.255.0; range dynamic-bootp 10.13.200.75 10.13.200.85; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server 10.13.200.101; }
So, I'm still kinda new to sys-admining (I've been doing devops stuff in CentOS for about a year and a half at my company), but we have a setup at my work that I think you might find relevant to your issue.
At work, we have a Production network that is served by the PXE menu. It exists in a different subnet than the rest of the computers on other networks, and getting the other machines to talk to that PXE server requires setting up routes between the different subnets. We haven't actually done this yet (people are lazy), but I know that's what we'll have to do to make it accessible.
I don't think there's a way to do what you're trying to do - if I understand correctly (and correct me if I'm wrong), your PXE menus are not being generated with the proper IP for your 10.13.200.XXX subnet systems to reach the files they need.
If that's the case, the way I see it you have two options: - Make a set of sub-menus for your "gc.sv.domain.net" network and hard code it in to your pxelinux.default template with the correct IP, 10.13.200.101 - Find some way for your systems in the 10.13.200.XXX subnet to route to 10.13.5.100
If there's a cobbler wizard out there who knows how to manage PXE menus better than I do, I'd love to hear about it - at my work, I have to keep all the PXE menus in a git repo and deploy them every time I make a change because Cobbler is not very good at PXE sub-menu management. Or at least I couldn't figure out how to use it very effectively. I can provide more details about that setup if someone would like to know them.
On Sat, Apr 30, 2016 at 8:21 PM, Tory M Blue tmblue@gmail.com wrote:
So I'm running into some issues and I'm sure it's a minor brain fart on my part. But the documentation has not squared me away.
I have a cobbler server running DHCP for 3 networks, my cobbler server has 3 interfaces and I have 3 dhcp stanzas (whatever).
I can set a different next server, which is the interface IP on that subnet/vlan. No issue. I can build a system from the 10.13.4 network just fine. But if I try to build from the 10.13.200 net, I can get a dhcp address, load the kernel, but the issue is the Distro has the IP address from the 10.13.4.x network in it so the pxelinux.cfg/default has the wrong subnet/vlan hardcoded; and thus tries to load the kickstart
LABEL CentOS7-x86_64_Standard kernel /images/CentOS7-x86_64/vmlinuz MENU LABEL CentOS7-x86_64_Standard append initrd=/images/CentOS7-x86_64/initrd.img ksdevice lang= kssendmac text ks=http://10.13.4.101/cblr/svc/op/ks/profile/CentOS7-x86_64_Standard ipappend 2
So obviously if a host is on the 10.13.200 net, receives a 10.13.200.x address, and starts booting, cobbler is sending it that kickstart line and it should not be going to 10.13.4.101 when the local network is ready to receive at 10.13.200.101.
The metadata tree has the 10.13.4.101 address, and I thought about setting it to $next_server, but it seems if I do it in the profile via cobbler_web, it over writes the default file with 10.13.4.101 (the cobbler host server IP)
I've removed $next-server from the cobbler settings file
#next_server: 10.13.4.101
But server is still configured.
server: 10.13.4.101
So the issue is really the server configuration inside settings. it mentions --server-override, but I don't want to have a handful of profiles for the same image.. I would like to just boot up a server and say use Profile-CentOS-standard and ignore which network it's coming from., want wildcards or other to figure things out.
Any ideas? really i've been searching and "nothing" I've found has made me understand where I'm falling short. -dhcp-tags, --server-override
Thanks tory
################## DHCP ############ ddns-update-style interim;
allow booting; allow bootp;
ignore client-updates; set vendorclass = option vendor-class-identifier;
subnet 10.13.4.0 netmask 255.255.255.0 { option routers 10.13.4.6; option domain-name-servers 10.13.4.220, 10.13.7.101, 10.13.7.102; option domain-name "eng.domain.net"; option subnet-mask 255.255.255.0; range dynamic-bootp 10.13.4.75 10.13.4.99; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server 10.13.4.101; }
subnet 10.13.5.0 netmask 255.255.255.0 { option routers 10.13.5.6; option domain-name-servers 10.13.4.220, 10.13.7.101, 10.13.7.102; option domain-name "eng.domain.net"; option subnet-mask 255.255.255.0; range dynamic-bootp 10.13.5.220 10.13.5.239; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server 10.13.5.100; }
subnet 10.13.200.0 netmask 255.255.255.0 { option routers 10.13.200.6; option domain-name-servers 216.249.24.15, 10.13.6.56; option domain-name "gc.sv.domain.net"; option subnet-mask 255.255.255.0; range dynamic-bootp 10.13.200.75 10.13.200.85; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server 10.13.200.101; } _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cobbler@lists.fedorahosted.org
On Sat, Apr 30, 2016 at 9:37 PM, Locane locane@gmail.com wrote:
So, I'm still kinda new to sys-admining (I've been doing devops stuff in CentOS for about a year and a half at my company), but we have a setup at my work that I think you might find relevant to your issue.
At work, we have a Production network that is served by the PXE menu. It exists in a different subnet than the rest of the computers on other networks, and getting the other machines to talk to that PXE server requires setting up routes between the different subnets. We haven't actually done this yet (people are lazy), but I know that's what we'll have to do to make it accessible.
I don't think there's a way to do what you're trying to do - if I understand correctly (and correct me if I'm wrong), your PXE menus are not being generated with the proper IP for your 10.13.200.XXX subnet systems to reach the files they need.
If that's the case, the way I see it you have two options:
- Make a set of sub-menus for your "gc.sv.domain.net" network and hard code
it in to your pxelinux.default template with the correct IP, 10.13.200.101
- Find some way for your systems in the 10.13.200.XXX subnet to route to
10.13.5.100
If there's a cobbler wizard out there who knows how to manage PXE menus better than I do, I'd love to hear about it - at my work, I have to keep all the PXE menus in a git repo and deploy them every time I make a change because Cobbler is not very good at PXE sub-menu management. Or at least I couldn't figure out how to use it very effectively. I can provide more details about that setup if someone would like to know them.
Thanks locane
Realistically this is possible, the short coming is the single server address in the cobbler config and there has to be a way around it.
Yes I can create different profiles that will put the right ks IP for the local interface etc. But I don't think that's necessary nor do I want to do that. My server listens and can respond on each of the 3 networks. DHCP responds as it's suppose to and I can DHCP a host on all 3 subnets with no issues.
Apr 30 22:37:51 boot-CentOS in.tftpd[19376]: RRQ from 10.13.200.77 filename /pxelinux.cfg/default Apr 30 22:37:58 boot-CentOS in.tftpd[19381]: RRQ from 10.13.200.77 filename //images/CentOS7-x86_64/vmlinuz Apr 30 22:38:01 boot-CentOS in.tftpd[19384]: RRQ from 10.13.200.77 filename //images/CentOS7-x86_64/initrd.img
Apr 30 03:12:09 boot-CentOS in.tftpd[11149]: RRQ from 10.13.4.79 filename /pxelinux.cfg/default Apr 30 03:12:15 boot-CentOS in.tftpd[11150]: RRQ from 10.13.4.79 filename //images/CentOS7-x86_64/vmlinuz Apr 30 03:12:18 boot-CentOS in.tftpd[11151]: RRQ from 10.13.4.79 filename //images/CentOS7-x86_64/initrd.img
Apr 28 05:27:44 boot-CentOS in.tftpd[1933]: RRQ from 10.13.5.220 filename /pxelinux.cfg/default Apr 28 05:27:49 boot-CentOS in.tftpd[1937]: RRQ from 10.13.5.220 filename //images/CentOS7-x86_64/vmlinuz Apr 28 05:27:52 boot-CentOS in.tftpd[1940]: RRQ from 10.13.5.220 filename //images/CentOS7-x86_64/initrd.img
The issue is when cobbler comes into play, how it manipulates the configuration and I don't believe it's only in /var/lib/tftpboot/pxelinux.cfg/default either, I think it's else where, but not finding it.
Kickstart Metadata tree=http://@@http_server@@/cblr/links/CentOS6-x86_64 is the issue.. Probably would fix everything if someone could add $next-server in there..
If my host can talk directly to the 3 subnets, there is no reason for a host to route to another subnet (Sure I could make this happen, add some SNATs ,translations but that should not be a requirement)
I'm missing something inside Cobbler that once it's pointed out, will be a face palm moment.But I'm about at the end of my rope making it work as "I" want it..
Most would be fine with multiple profiles, but I don't think it's necessary and looking for the glue that I'm missing to hold all this together.
The dhcp stanza/profile/<shrug> has next-server set, so dhcp and the corresponding host knows how to hit the cobbler server for it's kernel stuff, there is no reason that something in that stanza can't be used to identify the network and thus have the kickstart requests be modified for the right network
like the system calls this: wget http://10.13.200.101/cblr/svc/op/ks/profile/CentOS7-x86_64_KVM
That should only contain 10.13.200.101 information, not 10.13.4.101 etc.
like so.
# Use network installation url --url=http://10.13.200.101/cblr/links/CentOS6-x86_64
wget "http://10.13.200.101/cblr/svc/op/trig/mode/pre/profile/CentOS7-x86_64_KVM" -O /dev/null
# Start koan environment setup echo "export COBBLER_SERVER=10.13.200.101" > /etc/profile.d/cobbler.sh echo "setenv COBBLER_SERVER 10.13.200.101" > /etc/profile.d/cobbler.csh
# Begin cobbler registration if [ -f "/usr/bin/cobbler-register" ]; then cobbler-register --server=10.13.200.101 --fqdn '*AUTO*' --profile=CentOS7-x86_64_KVM --batch fi
wget "http://10.13.200.101/cblr/svc/op/ks/profile/CentOS7-x86_64_KVM" -O /root/cobbler.ks wget "http://10.13.200.101/cblr/svc/op/trig/mode/post/profile/CentOS7-x86_64_KVM" -O /dev/null
but if the server line in settings is server=10.13.4.101, all the 200.101's above will reflect 10.13.4.101 which should not be the case. There is no reason to force routing in this system :))
Thanks Tory
btw there are other threads on this, and each seem to be left unanswered. This is not a new conundrum, but I've not found a solid document or solution.. Look up --dhcp-tags in the man pages.. Look up --dhcp-tags in the wiki.. None of these have the answer. No reason I need to use tags if next-server is being defined t via dhcp....
Just checking, but are you not aware of /etc/cobbler/pxelinux.default? /etc/cobbler/* contains all your template files which Cobbler uses to generate the files for your system, as well as the ones in /var/lib/tftpboot/, I skimmed through your message and didn't see it mentioned - maybe you're looking for that? On Apr 30, 2016 11:16 PM, "Tory M Blue" tmblue@gmail.com wrote:
On Sat, Apr 30, 2016 at 9:37 PM, Locane locane@gmail.com wrote:
So, I'm still kinda new to sys-admining (I've been doing devops stuff in CentOS for about a year and a half at my company), but we have a setup
at my
work that I think you might find relevant to your issue.
At work, we have a Production network that is served by the PXE menu. It exists in a different subnet than the rest of the computers on other networks, and getting the other machines to talk to that PXE server
requires
setting up routes between the different subnets. We haven't actually
done
this yet (people are lazy), but I know that's what we'll have to do to
make
it accessible.
I don't think there's a way to do what you're trying to do - if I
understand
correctly (and correct me if I'm wrong), your PXE menus are not being generated with the proper IP for your 10.13.200.XXX subnet systems to
reach
the files they need.
If that's the case, the way I see it you have two options:
- Make a set of sub-menus for your "gc.sv.domain.net" network and hard
code
it in to your pxelinux.default template with the correct IP,
10.13.200.101
- Find some way for your systems in the 10.13.200.XXX subnet to route to
10.13.5.100
If there's a cobbler wizard out there who knows how to manage PXE menus better than I do, I'd love to hear about it - at my work, I have to keep
all
the PXE menus in a git repo and deploy them every time I make a change because Cobbler is not very good at PXE sub-menu management. Or at
least I
couldn't figure out how to use it very effectively. I can provide more details about that setup if someone would like to know them.
Thanks locane
Realistically this is possible, the short coming is the single server address in the cobbler config and there has to be a way around it.
Yes I can create different profiles that will put the right ks IP for the local interface etc. But I don't think that's necessary nor do I want to do that. My server listens and can respond on each of the 3 networks. DHCP responds as it's suppose to and I can DHCP a host on all 3 subnets with no issues.
Apr 30 22:37:51 boot-CentOS in.tftpd[19376]: RRQ from 10.13.200.77 filename /pxelinux.cfg/default Apr 30 22:37:58 boot-CentOS in.tftpd[19381]: RRQ from 10.13.200.77 filename //images/CentOS7-x86_64/vmlinuz Apr 30 22:38:01 boot-CentOS in.tftpd[19384]: RRQ from 10.13.200.77 filename //images/CentOS7-x86_64/initrd.img
Apr 30 03:12:09 boot-CentOS in.tftpd[11149]: RRQ from 10.13.4.79 filename /pxelinux.cfg/default Apr 30 03:12:15 boot-CentOS in.tftpd[11150]: RRQ from 10.13.4.79 filename //images/CentOS7-x86_64/vmlinuz Apr 30 03:12:18 boot-CentOS in.tftpd[11151]: RRQ from 10.13.4.79 filename //images/CentOS7-x86_64/initrd.img
Apr 28 05:27:44 boot-CentOS in.tftpd[1933]: RRQ from 10.13.5.220 filename /pxelinux.cfg/default Apr 28 05:27:49 boot-CentOS in.tftpd[1937]: RRQ from 10.13.5.220 filename //images/CentOS7-x86_64/vmlinuz Apr 28 05:27:52 boot-CentOS in.tftpd[1940]: RRQ from 10.13.5.220 filename //images/CentOS7-x86_64/initrd.img
The issue is when cobbler comes into play, how it manipulates the configuration and I don't believe it's only in /var/lib/tftpboot/pxelinux.cfg/default either, I think it's else where, but not finding it.
Kickstart Metadata tree=http://@@http_server@@/cblr/links/CentOS6-x86_64 is the issue.. Probably would fix everything if someone could add $next-server in there..
If my host can talk directly to the 3 subnets, there is no reason for a host to route to another subnet (Sure I could make this happen, add some SNATs ,translations but that should not be a requirement)
I'm missing something inside Cobbler that once it's pointed out, will be a face palm moment.But I'm about at the end of my rope making it work as "I" want it..
Most would be fine with multiple profiles, but I don't think it's necessary and looking for the glue that I'm missing to hold all this together.
The dhcp stanza/profile/<shrug> has next-server set, so dhcp and the corresponding host knows how to hit the cobbler server for it's kernel stuff, there is no reason that something in that stanza can't be used to identify the network and thus have the kickstart requests be modified for the right network
like the system calls this: wget http://10.13.200.101/cblr/svc/op/ks/profile/CentOS7-x86_64_KVM
That should only contain 10.13.200.101 information, not 10.13.4.101 etc.
like so.
# Use network installation url --url=http://10.13.200.101/cblr/links/CentOS6-x86_64
wget " http://10.13.200.101/cblr/svc/op/trig/mode/pre/profile/CentOS7-x86_64_KVM" -O /dev/null
# Start koan environment setup echo "export COBBLER_SERVER=10.13.200.101" > /etc/profile.d/cobbler.sh echo "setenv COBBLER_SERVER 10.13.200.101" > /etc/profile.d/cobbler.csh
# Begin cobbler registration if [ -f "/usr/bin/cobbler-register" ]; then cobbler-register --server=10.13.200.101 --fqdn '*AUTO*' --profile=CentOS7-x86_64_KVM --batch fi
wget "http://10.13.200.101/cblr/svc/op/ks/profile/CentOS7-x86_64_KVM" -O /root/cobbler.ks wget " http://10.13.200.101/cblr/svc/op/trig/mode/post/profile/CentOS7-x86_64_KVM " -O /dev/null
but if the server line in settings is server=10.13.4.101, all the 200.101's above will reflect 10.13.4.101 which should not be the case. There is no reason to force routing in this system :))
Thanks Tory
btw there are other threads on this, and each seem to be left unanswered. This is not a new conundrum, but I've not found a solid document or solution.. Look up --dhcp-tags in the man pages.. Look up --dhcp-tags in the wiki.. None of these have the answer. No reason I need to use tags if next-server is being defined t via dhcp.... _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cobbler@lists.fedorahosted.org
Hi
We have multiple networks that we pxe boot off and have no problem with fixed ip addresses being passed throught. Cobbler works on the server override ip for each of the networks we pxe boot off, and this is passed through as http_server, next server, etc. i can only conclude your cobbler config is not setup correctly. basically you add a system, set ip settings AND ip for the server override, and cobbler passes the server override ip through to wherever its needed.
-- Alastair Munro
-----Original Message----- From: Tory M Blue tmblue@gmail.com To: cobbler mailing list cobbler@lists.fedorahosted.org Sent: Sun, 01 May 2016 4:22 Subject: [cobbler] Multiple subnets, multiple dhcp --dhcp-tag, profiles, distro
So I'm running into some issues and I'm sure it's a minor brain fart on my part. But the documentation has not squared me away.
I have a cobbler server running DHCP for 3 networks, my cobbler server has 3 interfaces and I have 3 dhcp stanzas (whatever).
I can set a different next server, which is the interface IP on that subnet/vlan. No issue. I can build a system from the 10.13.4 network just fine. But if I try to build from the 10.13.200 net, I can get a dhcp address, load the kernel, but the issue is the Distro has the IP address from the 10.13.4.x network in it so the pxelinux.cfg/default has the wrong subnet/vlan hardcoded; and thus tries to load the kickstart
LABEL CentOS7-x86_64_Standard kernel /images/CentOS7-x86_64/vmlinuz MENU LABEL CentOS7-x86_64_Standard append initrd=/images/CentOS7-x86_64/initrd.img ksdevice lang= kssendmac text ks=http://10.13.4.101/cblr/svc/op/ks/profile/CentOS7-x86_64_Standard ipappend 2
So obviously if a host is on the 10.13.200 net, receives a 10.13.200.x address, and starts booting, cobbler is sending it that kickstart line and it should not be going to 10.13.4.101 when the local network is ready to receive at 10.13.200.101.
The metadata tree has the 10.13.4.101 address, and I thought about setting it to $next_server, but it seems if I do it in the profile via cobbler_web, it over writes the default file with 10.13.4.101 (the cobbler host server IP)
I've removed $next-server from the cobbler settings file
#next_server: 10.13.4.101
But server is still configured.
server: 10.13.4.101
So the issue is really the server configuration inside settings. it mentions --server-override, but I don't want to have a handful of profiles for the same image.. I would like to just boot up a server and say use Profile-CentOS-standard and ignore which network it's coming from., want wildcards or other to figure things out.
Any ideas? really i've been searching and "nothing" I've found has made me understand where I'm falling short. -dhcp-tags, --server-override
Thanks tory
################## DHCP ############ ddns-update-style interim;
allow booting; allow bootp;
ignore client-updates; set vendorclass = option vendor-class-identifier;
subnet 10.13.4.0 netmask 255.255.255.0 { option routers 10.13.4.6; option domain-name-servers 10.13.4.220, 10.13.7.101, 10.13.7.102; option domain-name "eng.domain.net"; option subnet-mask 255.255.255.0; range dynamic-bootp 10.13.4.75 10.13.4.99; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server 10.13.4.101; }
subnet 10.13.5.0 netmask 255.255.255.0 { option routers 10.13.5.6; option domain-name-servers 10.13.4.220, 10.13.7.101, 10.13.7.102; option domain-name "eng.domain.net"; option subnet-mask 255.255.255.0; range dynamic-bootp 10.13.5.220 10.13.5.239; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server 10.13.5.100; }
subnet 10.13.200.0 netmask 255.255.255.0 { option routers 10.13.200.6; option domain-name-servers 216.249.24.15, 10.13.6.56; option domain-name "gc.sv.domain.net"; option subnet-mask 255.255.255.0; range dynamic-bootp 10.13.200.75 10.13.200.85; filename "/pxelinux.0"; default-lease-time 21600; max-lease-time 43200; next-server 10.13.200.101; } _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cobbler@lists.fedorahosted.org
On Sun, May 1, 2016 at 11:53 AM, alastair@alastair-munro.com wrote:
Hi
We have multiple networks that we pxe boot off and have no problem with fixed ip addresses being passed throught. Cobbler works on the server override ip for each of the networks we pxe boot off, and this is passed through as http_server, next server, etc. i can only conclude your cobbler config is not setup correctly. basically you add a system, set ip settings AND ip for the server override, and cobbler passes the server override ip through to wherever its needed.
-- Alastair Munro
Thanks Alastair.
I'll repeat myself, I'm not really wanting to muck with the profiles. I want a single profile (for each server class) that can be used from X networks. Sure I can add server overrides and have x*3 profiles, vs a single. This makes no sense. The DHCP has the right address in next-server already, why cobbler can't use that value vs inserting it's own and utilizing the "server" switch inside cobbler, is exactly why you are creating multiple profiles, when in reality, I don't see why you have to..
Yes it works but having to add these to duplicated profiles for each attached network just doesn't seem like the right answer.
If it's the only answer then I guess it's not going to be a face palm.
But it seems simple enough that I just don't think anyone has ever gotten the correct answer (many incomplete web posts, questions around this). That's either because there really is no answer, you work around the issue. But if DHCP has the information, why can't Cobbler use it?
Also I'm not adding systems, so it's not a necessary step for me, a server is unboxed and imaged.
Thanks for the response. Tory
Tory (and everyone else):
I think this is the code you want to mod, if my python's not laughable:
/usr/lib/python2.4/site-packages/cobbler/pxegen.py
214: try: 215: ipaddress = socket.gethostbyname_ex(blended["http_server"])[2][0] 216: except socket.gaierror: 217: ipaddress = blended["http_server"] 218: kickstart_path = "http://%s/cblr/svc/op/ks/system/%s" % (ipaddress, system.name)
I say cut that out or mod it, and the string will be preserved. Fix the DNS to match, and you're golden.
- ..
Tory M Blue wrote:
But it seems simple enough that I just don't think anyone has ever gotten the correct answer (many incomplete web posts, questions around this). That's either because there really is no answer, you work around the issue. But if DHCP has the information, why can't Cobbler use it?
Also I'm not adding systems, so it's not a necessary step for me, a server is unboxed and imaged.
Thanks for the response. Tory _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cobbler@lists.fedorahosted.org
On Sun, May 1, 2016 at 7:48 PM, bishop bishop@platypus.bc.ca wrote:
Tory (and everyone else):
I think this is the code you want to mod, if my python's not laughable:
/usr/lib/python2.4/site-packages/cobbler/pxegen.py
214: try: 215: ipaddress = socket.gethostbyname_ex(blended["http_server"])[2][0] 216: except socket.gaierror: 217: ipaddress = blended["http_server"] 218: kickstart_path = "http://%s/cblr/svc/op/ks/system/%s" % (ipaddress, system.name)
I say cut that out or mod it, and the string will be preserved. Fix the DNS to match, and you're golden.
Thanks will take a look. I think the big deal is how to get the Next-server from the dhcp server. Cobbler and dhcp don't seem to talk to each other :) So the initial pxe boot, has next-server, which the server users to grab it's kernel files, and then there is another dhcp call, which is ultimately used to call the ks file. We really need to be able to capture the next-server variable between dhcp and cobbler, but I'm not versed enough to see how that would be made possible. I'm wondering if we don't use next-server (since both cobbler and dhcp use it) and we create a different variable inside the dhcp stanza, would that would allow us to grab it from cobbler (the above code).
Thanks again Bishop
Tory
Hi
'cobbler sync' should regenerate dhcp/tftp configs, if you have them enabled in /etc/cobbler/settings:
# set to 1 to enable Cobbler's DHCP management features. # the choice of DHCP management engine is in /etc/cobbler/modules.conf manage_dhcp: 1
# set to 1 to enable Cobbler's TFTP management features. # the choice of TFTP mangement engine is in /etc/cobbler/modules.conf manage_tftpd: 1
your dhcp config uses the dhcp.template in /etc/cobbler. Adapt this to your needs. Here is our one that copes with all the different subnets. I seem to remember I had to tweak this, but don't remember the exact details!
# ****************************************************************** # Cobbler managed dhcpd.conf file # # generated from cobbler dhcp.conf template ($date) # Do NOT make changes to /etc/dhcpd.conf. Instead, make your changes # in /etc/cobbler/dhcp.template, as /etc/dhcpd.conf will be # overwritten. # # ****************************************************************** #
ddns-update-style interim;
allow booting; allow bootp;
ignore client-updates; set vendorclass = option vendor-class-identifier;
option pxe-system-type code 93 = unsigned integer 16;
subnet 10.128.17.0 netmask 255.255.255.0 { option routers 10.128.17.1; option domain-name-servers 10.96.16.111,10.128.24.12,10.96.16.112; option subnet-mask 255.255.255.0; ## range dynamic-bootp 10.128.17.2 10.128.17.254; range dynamic-bootp 10.128.17.9 10.128.17.9; default-lease-time 21600; max-lease-time 43200; ## next-server $next_server; next-server 10.128.17.122; class "pxeclients" { match if substring (option vendor-class-identifier, 0, 9) = "PXEClient"; if option pxe-system-type = 00:02 { filename "ia64/elilo.efi"; } else if option pxe-system-type = 00:06 { filename "grub/grub-x86.efi"; } else if option pxe-system-type = 00:07 { filename "grub/grub-x86_64.efi"; } else { filename "pxelinux.0"; } } }
#for dhcp_tag in $dhcp_tags.keys(): ## group could be subnet if your dhcp tags line up with your subnets ## or really any valid dhcpd.conf construct ... if you only use the ## default dhcp tag in cobbler, the group block can be deleted for a ## flat configuration # group for Cobbler DHCP tag: $dhcp_tag group { #for mac in $dhcp_tags[$dhcp_tag].keys(): #set iface = $dhcp_tags[$dhcp_tag][$mac] host $iface.name { hardware ethernet $mac; #if $iface.ip_address: fixed-address $iface.ip_address; #end if #if $iface.hostname: option host-name "$iface.hostname"; #end if #if $iface.netmask: option subnet-mask $iface.netmask; #end if #if $iface.gateway: option routers $iface.gateway; #end if #if $iface.enable_gpxe: if exists user-class and option user-class = "gPXE" { filename "http://$cobbler_server/cblr/svc/op/gpxe/system/$iface.owner"; } else if exists user-class and option user-class = "iPXE" { filename "http://$cobbler_server/cblr/svc/op/gpxe/system/$iface.owner"; } else { filename "undionly.kpxe"; } #else filename "$iface.filename"; #end if ## Cobbler defaults to $next_server, but some users ## may like to use $iface.system.server for proxied setups ## next-server $next_server; next-server $iface.next_server; } #end for } #end for
You can use 'cobbler system getks --name=foo' to see the kickstart that will be generate. You can use 'cobbler system dumpvars --name=foo' to dump all the variables for a system. for example http_server and next_server are normally the same thing.
Alastair
On 2016-05-02 17:44, Tory M Blue wrote:
On Sun, May 1, 2016 at 7:48 PM, bishop bishop@platypus.bc.ca wrote:
Tory (and everyone else):
I think this is the code you want to mod, if my python's not laughable:
/usr/lib/python2.4/site-packages/cobbler/pxegen.py
214: try: 215: ipaddress = socket.gethostbyname_ex(blended["http_server"])[2][0] 216: except socket.gaierror: 217: ipaddress = blended["http_server"] 218: kickstart_path = "http://%s/cblr/svc/op/ks/system/%s" % (ipaddress, system.name)
I say cut that out or mod it, and the string will be preserved. Fix the DNS to match, and you're golden.
Thanks will take a look. I think the big deal is how to get the Next-server from the dhcp server. Cobbler and dhcp don't seem to talk to each other :) So the initial pxe boot, has next-server, which the server users to grab it's kernel files, and then there is another dhcp call, which is ultimately used to call the ks file. We really need to be able to capture the next-server variable between dhcp and cobbler, but I'm not versed enough to see how that would be made possible. I'm wondering if we don't use next-server (since both cobbler and dhcp use it) and we create a different variable inside the dhcp stanza, would that would allow us to grab it from cobbler (the above code).
Thanks again Bishop
Tory _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cobbler@lists.fedorahosted.org
On Mon, May 2, 2016 at 2:42 PM, Alastair Munro alastair@alastair-munro.com wrote:
Hi
'cobbler sync' should regenerate dhcp/tftp configs, if you have them enabled in /etc/cobbler/settings:
<SNIPPED>
You can use 'cobbler system getks --name=foo' to see the kickstart that will be generate. You can use 'cobbler system dumpvars --name=foo' to dump all the variables for a system. for example http_server and next_server are normally the same thing.
Alastair
Thanks Alastair, the extended portion of the dhcp.template file that you posted, is also on the serve and is a bit confusing. There is really no clear illustration of dhcp-tags anywhere.
What does this even mean?!
"#for dhcp_tag in $dhcp_tags.keys(): ## group could be subnet if your dhcp tags line up with your subnets ## or really any valid dhcpd.conf construct ... if you only use the ## default dhcp tag in cobbler, the group block can be deleted for a ## flat configuration"
And I "think", that again I'm in a situation where I need to have different profiles. so either setting a dhcp-tag (whatever), or set a server override. But either way I'm duplicating profiles which I don't believe I should have to do :)
I may well be missing something here, but I think getting into the code is the answer, because something is missing.
Thanks again for your continued assistance and ideas.
Tory
Hi
i didnt say we use different profiles. we use the same profile across all subnets. we actually have 4 cobbler servers and all the slaves replicate from one master. our cobbler servers are in different data centers. each dc has one or more subnets we pxe boot on. you set the server override at the system item level and cobbler takes care of the rest. so if a host is on netA it must have server override IP x.
btw, are you using an old version of cobbler? best to get up to date if u can. appreciate this can be tricky if your cobbler is integrated into a product like satelite or katello.
regarding profiles: we only have one per major release of the os. eg el5, el6, el7, ub1404. so thats 4 profiles that are used across rhel, centos, oracle linux and ubuntu 1404, plus all the point releases, and loads of different configs. furthermore we dont differentiate between vms and real servers. one profile works across them all. also you can use the meta ks variables to pass your requirements to the builds. so we have build=vm, build=bda, build=hadoop, build=sas94vm. these then setup different disk layouts. we also implemented the ability to turn off or on functionality using enable= or disable=. eg enable=proxy,nimsoft,uek disable=swap, vas4. these are not cobbler builtins, its just coding the templating engine. cobbler used the cheetah templating engine which allows you embed bits of python code.
its much better to have a simple build system and then have a cfg mgmt tool like puppet do all the post build config.
-- Alastair Munro
-----Original Message----- From: Tory M Blue tmblue@gmail.com To: cobbler mailing list cobbler@lists.fedorahosted.org Sent: Mon, 02 May 2016 2:53 Subject: [cobbler] Re: Multiple subnets, multiple dhcp --dhcp-tag, profiles, distro
On Sun, May 1, 2016 at 11:53 AM, alastair@alastair-munro.com wrote:
Hi
We have multiple networks that we pxe boot off and have no problem with fixed ip addresses being passed throught. Cobbler works on the server override ip for each of the networks we pxe boot off, and this is passed through as http_server, next server, etc. i can only conclude your cobbler config is not setup correctly. basically you add a system, set ip settings AND ip for the server override, and cobbler passes the server override ip through to wherever its needed.
-- Alastair Munro
Thanks Alastair.
I'll repeat myself, I'm not really wanting to muck with the profiles. I want a single profile (for each server class) that can be used from X networks. Sure I can add server overrides and have x*3 profiles, vs a single. This makes no sense. The DHCP has the right address in next-server already, why cobbler can't use that value vs inserting it's own and utilizing the "server" switch inside cobbler, is exactly why you are creating multiple profiles, when in reality, I don't see why you have to..
Yes it works but having to add these to duplicated profiles for each attached network just doesn't seem like the right answer.
If it's the only answer then I guess it's not going to be a face palm.
But it seems simple enough that I just don't think anyone has ever gotten the correct answer (many incomplete web posts, questions around this). That's either because there really is no answer, you work around the issue. But if DHCP has the information, why can't Cobbler use it?
Also I'm not adding systems, so it's not a necessary step for me, a server is unboxed and imaged.
Thanks for the response. Tory _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cobbler@lists.fedorahosted.org
On Mon, May 2, 2016 at 3:26 AM, alastair@alastair-munro.com wrote:
Hi
i didnt say we use different profiles. we use the same profile across all subnets. we actually have 4 cobbler servers and all the slaves replicate from one master. our cobbler servers are in different data centers. each dc has one or more subnets we pxe boot on. you set the server override at the system item level and cobbler takes care of the rest. so if a host is on netA it must have server override IP x.
btw, are you using an old version of cobbler? best to get up to date if u can. appreciate this can be tricky if your cobbler is integrated into a product like satelite or katello.
regarding profiles: we only have one per major release of the os. eg el5, el6, el7, ub1404. so thats 4 profiles that are used across rhel, centos, oracle linux and ubuntu 1404, plus all the point releases, and loads of different configs. furthermore we dont differentiate between vms and real servers. one profile works across them all. also you can use the meta ks variables to pass your requirements to the builds. so we have build=vm, build=bda, build=hadoop, build=sas94vm. these then setup different disk layouts. we also implemented the ability to turn off or on functionality using enable= or disable=. eg enable=proxy,nimsoft,uek disable=swap, vas4. these are not cobbler builtins, its just coding the templating engine. cobbler used the cheetah templating engine which allows you embed bits of python code.
its much better to have a simple build system and then have a cfg mgmt tool like puppet do all the post build config.
I missed this one, thanks again Alastair.
I'm using the latest and greatest cobbler, I rebuilt the system so it's all new shiny. Okay single profile, thanks. But you are using server setups, which can take the various switches. If I'm purely using a single Profile, no systems configured, I think I'm still in a situation where things are not working as "I think, I should be able to get them tooooo"
Ya I've started looking inside the KS and using some of the cheetah stuff but failing miserable. I figured i could do something like
#if $next_server == "10.13.200" #set $server="10.13.200.101" #else set $server = "10.13.5.100" #end if
For example, using the right cheetah # syntax, Figure this would be way to achieve what I want. I should be able to overwrite dynamically what the next_server or in fact what $server is.
Thanks again, still looking.
Tory
Hi Tory
We now use vrealize in vmware to automate the build of vm's. However behind the scenes it uses cobbler and creates a system in cobbler to build each vm, even though pxe is used to build the vm. Once the vm is built the system definition is removed from cobbler. The vm always has a static ip even though they are pxe built.
In my 25 years or so of being a sysadmin i have not come across anyone using dhcp for servers to get their ip (exception being cloud environments such as Azure where the infrastructure controls ip allocation). Thus it makes sense for servers to use static ip's even if the build uses pxe (dhcp/tftp). For example if the server cannot get its ip then its not available.
Just my tuppence worth. You dont need to follow my advice, but a wise man once said dont make the mistakes yourself but learn from others mistakes.
-- Alastair Munro
-----Original Message----- From: Tory M Blue tmblue@gmail.com To: cobbler mailing list cobbler@lists.fedorahosted.org Sent: Thu, 05 May 2016 21:28 Subject: [cobbler] Re: Multiple subnets, multiple dhcp --dhcp-tag, profiles, distro
On Mon, May 2, 2016 at 3:26 AM, alastair@alastair-munro.com wrote:
Hi
i didnt say we use different profiles. we use the same profile across all subnets. we actually have 4 cobbler servers and all the slaves replicate from one master. our cobbler servers are in different data centers. each dc has one or more subnets we pxe boot on. you set the server override at the system item level and cobbler takes care of the rest. so if a host is on netA it must have server override IP x.
btw, are you using an old version of cobbler? best to get up to date if u can. appreciate this can be tricky if your cobbler is integrated into a product like satelite or katello.
regarding profiles: we only have one per major release of the os. eg el5, el6, el7, ub1404. so thats 4 profiles that are used across rhel, centos, oracle linux and ubuntu 1404, plus all the point releases, and loads of different configs. furthermore we dont differentiate between vms and real servers. one profile works across them all. also you can use the meta ks variables to pass your requirements to the builds. so we have build=vm, build=bda, build=hadoop, build=sas94vm. these then setup different disk layouts. we also implemented the ability to turn off or on functionality using enable= or disable=. eg enable=proxy,nimsoft,uek disable=swap, vas4. these are not cobbler builtins, its just coding the templating engine. cobbler used the cheetah templating engine which allows you embed bits of python code.
its much better to have a simple build system and then have a cfg mgmt tool like puppet do all the post build config.
I missed this one, thanks again Alastair.
I'm using the latest and greatest cobbler, I rebuilt the system so it's all new shiny. Okay single profile, thanks. But you are using server setups, which can take the various switches. If I'm purely using a single Profile, no systems configured, I think I'm still in a situation where things are not working as "I think, I should be able to get them tooooo"
Ya I've started looking inside the KS and using some of the cheetah stuff but failing miserable. I figured i could do something like
#if $next_server == "10.13.200" #set $server="10.13.200.101" #else set $server = "10.13.5.100" #end if
For example, using the right cheetah # syntax, Figure this would be way to achieve what I want. I should be able to overwrite dynamically what the next_server or in fact what $server is.
Thanks again, still looking.
Tory _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cobbler@lists.fedorahosted.org
On Thu, May 5, 2016 at 2:15 PM, alastair@alastair-munro.com wrote:
Hi Tory
We now use vrealize in vmware to automate the build of vm's. However behind the scenes it uses cobbler and creates a system in cobbler to build each vm, even though pxe is used to build the vm. Once the vm is built the system definition is removed from cobbler. The vm always has a static ip even though they are pxe built.
In my 25 years or so of being a sysadmin i have not come across anyone using dhcp for servers to get their ip (exception being cloud environments such as Azure where the infrastructure controls ip allocation). Thus it makes sense for servers to use static ip's even if the build uses pxe (dhcp/tftp). For example if the server cannot get its ip then its not available.
Just my tuppence worth. You dont need to follow my advice, but a wise man once said dont make the mistakes yourself but learn from others mistakes.
-- Alastair Munro
Yes sir, currently I'm rebuilding systems, migrating from CentOS6 to CentOS7 in a production environment. So instead of playing with DNS, I'm building the system as the replacement system in place. I then shut down the current system and bring up the new one, so the DHCP makes sense in this regard. Obviously I could use a throw away static but really that seems like an unnecessary hurdle.
And remember my issue is not with an IP, it's with cobbler using a hardcoded http_server and next_server, when it could easily take the next_server from the DHCP profile (for my use anyways).
Again I appreciate the continued support and ideas.
I'm not discounting anything. I have it working, but it's not how I see it working. I still think there is something I fundamentally am not wrapping my head around, or a fundamental flaw in how cobbler approaches multi network environments. Because I'm stubborn, I'm not happy that it's working, since I had to do some network tricks to allow it to work. (everything talking to 13.5 interface for the kickstart process).
I really thought I was on to something using the if/else clauses in the kickstart file, but Cheetah/Python are now giving me the big finger :) But there is a way, I am just floundering at this point!!
Thanks again Tory
Hi Tory
Just a thought: have you tried cobbler web? Nice thing about the gui is it gives you an idea of the options are available for systems/profiles/distros.
I think you would need to define systems in cobbler, even if they had dhcp assigned ip addresses. Then you could define the server override that way. So at a minimum you define hostname, interface, mac address and server override. Then see what cobbler sync generates for dhcpd.conf and the tftpconfig?
-- Alastair Munro
-----Original Message----- From: Tory M Blue tmblue@gmail.com To: cobbler mailing list cobbler@lists.fedorahosted.org Sent: Thu, 05 May 2016 22:39 Subject: [cobbler] Re: Multiple subnets, multiple dhcp --dhcp-tag, profiles, distro
On Thu, May 5, 2016 at 2:15 PM, alastair@alastair-munro.com wrote:
Hi Tory
We now use vrealize in vmware to automate the build of vm's. However behind the scenes it uses cobbler and creates a system in cobbler to build each vm, even though pxe is used to build the vm. Once the vm is built the system definition is removed from cobbler. The vm always has a static ip even though they are pxe built.
In my 25 years or so of being a sysadmin i have not come across anyone using dhcp for servers to get their ip (exception being cloud environments such as Azure where the infrastructure controls ip allocation). Thus it makes sense for servers to use static ip's even if the build uses pxe (dhcp/tftp). For example if the server cannot get its ip then its not available.
Just my tuppence worth. You dont need to follow my advice, but a wise man once said dont make the mistakes yourself but learn from others mistakes.
-- Alastair Munro
Yes sir, currently I'm rebuilding systems, migrating from CentOS6 to CentOS7 in a production environment. So instead of playing with DNS, I'm building the system as the replacement system in place. I then shut down the current system and bring up the new one, so the DHCP makes sense in this regard. Obviously I could use a throw away static but really that seems like an unnecessary hurdle.
And remember my issue is not with an IP, it's with cobbler using a hardcoded http_server and next_server, when it could easily take the next_server from the DHCP profile (for my use anyways).
Again I appreciate the continued support and ideas.
I'm not discounting anything. I have it working, but it's not how I see it working. I still think there is something I fundamentally am not wrapping my head around, or a fundamental flaw in how cobbler approaches multi network environments. Because I'm stubborn, I'm not happy that it's working, since I had to do some network tricks to allow it to work. (everything talking to 13.5 interface for the kickstart process).
I really thought I was on to something using the if/else clauses in the kickstart file, but Cheetah/Python are now giving me the big finger :) But there is a way, I am just floundering at this point!!
Thanks again Tory _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cobbler@lists.fedorahosted.org
Okay just circling back.
So some of this was my misunderstanding and my days of trying to modify the "template" (it's not the actual kickstart file), as well as mis understanding what Cobbler's role in this whole thing was. So what I was after was not really even possible, thanks to NACC on the #cobbler irc channel, he was able to straighten out my terminology.
So ya Cobbler has no idea and never will (unless you go static!) what my clients IP is. This is really an anaconda/pxe issue and not Cobbler, Cobbler is creating the kickstart files and stuff out of my template, so really I need to attack this from a different angle.. So this was much more of me not understanding Cobbler's role in my pxebooting process.
NACC found me some cool stuff via the pxelinux and some stuff I can do there to get the right information (prevent PXE from traversing the network)..
May not get me 100%, but I'm a much better person now that my misconceptions have been cleared up.
Sorry Cobbler this was on me, not you!!
Thanks for everyones assistance!
Tory
Hi Tory,
This is a little bit late, but I've been handling the issue of multiple next-servers by using Cheetah templating code in dhcp.template. I started with 3 data centers -- A, B, and C -- which all had a cobbler instance repliacted from a master cobbler server (the only one with cobbler-web).
On each cobbler server, I defined a unique $tag_pattern to be matched against each system object's dhcp_tag.
If CobblerA recognized that a system object's dhcp_tag matched its $tag_pattern, it created a dhcpd host definition with the appropriate next-server (pulled from CobblerA 's /etc/cobbler/settings).
Systems that were not set with netboot-enable=True or did not match the $tag_pattern were skipped. This resulted in a clean dhcpd.conf, containing only the host definitions relevant for that network.
It would be a simple matter to update my template for multi-homed Cobbler servers with a Cheetah if statement that examined the system object's gateway and assigned a different next-server value.
Here's my dhcp.template. If you're still struggling with too much complexity and/or uncertainty, I hope this helps.
# Cobbler managed dhcpd.conf file # # generated from cobbler dhcp.conf template ($date) # Do NOT make changes to /etc/dhcpd.conf. Instead, make your changes # in /etc/cobbler/dhcp.template, as /etc/dhcpd.conf will be # overwritten. # # ****************************************************************** authoritative; allow booting; allow bootp;
option domain-name "example.com"; option domain-name-servers 10.10.148.12; option ntp-servers 10.10.148.12; option routers 10.10.148.1;
ddns-update-style interim; default-lease-time 10800; max-lease-time 10800;
log-facility local4;
key ddns_key { algorithm hmac-md5; secret "XXXXXXXXXXXXXXXXXXXXXX"; }
subnet 10.10.148.0 netmask 255.255.252.0 { option routers 10.10.148.1; option domain-name-servers 10.10.148.12; option domain-name "example.com"; option subnet-mask 255.255.252.0; filename "/pxelinux.0"; next-server $next_server; }
# For kicking OpenStack Compute nodes subnet 192.168.241.0 netmask 255.255.255.0 { option routers 192.168.241.1; option domain-name-servers 192.168.241.10; option domain-name "example.com"; option subnet-mask 255.255.255.0; filename "/pxelinux.0"; next-server 192.168.241.10; }
#import re #set $tag_pattern = $re.compile("^cobbler_A") #for dhcp_tag in $dhcp_tags.keys(): #unless $tag_pattern.match($dhcp_tag) # <-- add the if statement #continue # after this line to #end unless # determine next_server # group for Cobbler DHCP tag: $dhcp_tag group { #for mac in $dhcp_tags[$dhcp_tag].keys(): #set iface = $dhcp_tags[$dhcp_tag][$mac] host $iface.name { hardware ethernet $mac; #if $iface.ip_address: fixed-address $iface.ip_address; #end if #if $iface.hostname: option host-name "$iface.hostname"; #end if #if $iface.subnet: option subnet-mask $iface.netmask; #end if #if $iface.gateway: option routers $iface.gateway; #end if filename "$iface.filename"; ## Cobbler defaults to $next_server, but some users ## may like to use $iface.system.server for proxied setups next-server $iface.next_server; } #end for } #end for
On Thu, May 5, 2016 at 9:50 PM, Tory M Blue tmblue@gmail.com wrote:
Okay just circling back.
So some of this was my misunderstanding and my days of trying to modify the "template" (it's not the actual kickstart file), as well as mis understanding what Cobbler's role in this whole thing was. So what I was after was not really even possible, thanks to NACC on the #cobbler irc channel, he was able to straighten out my terminology.
So ya Cobbler has no idea and never will (unless you go static!) what my clients IP is. This is really an anaconda/pxe issue and not Cobbler, Cobbler is creating the kickstart files and stuff out of my template, so really I need to attack this from a different angle.. So this was much more of me not understanding Cobbler's role in my pxebooting process.
NACC found me some cool stuff via the pxelinux and some stuff I can do there to get the right information (prevent PXE from traversing the network)..
May not get me 100%, but I'm a much better person now that my misconceptions have been cleared up.
Sorry Cobbler this was on me, not you!!
Thanks for everyones assistance!
Tory _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cobbler@lists.fedorahosted.org
cobbler@lists.fedorahosted.org
-
Alastair Munro -
bishop -
Greg Chavez -
Locane -
Tory M Blue