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" <tmb...@gmail.com> wrote:
> On Sat, Apr 30, 2016 at 9:37 PM, Locane <loc...@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 >
_______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cobbler@lists.fedorahosted.org
