On Sat, Apr 30, 2016 at 9:37 PM, Locane <locane(a)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....