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