The full <directory> configuration for those files that cobblerd
serves up via apache should be provided in *it's* config file,
/etc/httpd/conf.d/cobbler.conf. No?
Or are you suggesting that we need to otherwise configure the
stock/vanilla install of apache -- outside of the cobbler.conf?
And, is that behind the new/latest:
"Could not communicate with http://server3.internal.net:25151"
issue as well?
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
02-04-2008, 07:10 PM
Michael DeHaan
"invalid kernel" -- found the problem!
Or are you suggesting that we need to otherwise configure the
stock/vanilla install of apache -- outside of the cobbler.conf?
I'm thinking your main Apache config isn't actually stock, yes.
And, is that behind the new/latest:
"Could not communicate with http://server3.internal.net:25151"
issue as well?
You had it working before when it tried to download the kernel/initrd.
What did you change?
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
02-04-2008, 07:27 PM
"JimmyT _"
"invalid kernel" -- found the problem!
I told you what we changed .... a new box, with a fresh download, and
a vanilla install.
Based on your reposnse, it's clear the perception is that "it's us".
Fair enough. We'll stick to supported products.
Thanks.
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
02-04-2008, 08:00 PM
Michael DeHaan
"invalid kernel" -- found the problem!
Rainer Duffner wrote:
Am 04.02.2008 um 21:27 schrieb JimmyT _:
I told you what we changed .... a new box, with a fresh download, and
a vanilla install.
Based on your reposnse, it's clear the perception is that "it's us".
Fair enough. We'll stick to supported products.
Do physical installs work?
It works here, basically out-of-the-box.
Sometimes, though, the RPC-XML interface can get "cobbled" and I've
got to restart httpd+cobblerd.
Haven't figured out why, though.
Development cobbler from git (0.7.X, 0.8 candidate) has some logging
updates that also include much better remote exception handling, so stay
tuned for that, I suspect that should go away. I haven't seen any issues
with cobblerd from the development build which I've been running in a
/long/ time. I do recall some issues with cobblerd in previous releases.
I really wish I had something like cobbler for my FreeBSD-installations.
I'm not sure I've mentioned that to you yet or not (I know I have some
other folks) --
Cobbler already has support in there to do SuSE/Debian type installs
(they take an answer file, even if it's not technically a kickstart). If
there's an easy enough way to adapt
the code (mainly action_sync.py and item_distro.py) to grok the BSD
differences, I'd be willing to take incorporate it. Honestly I'm not all
that familiar with what it takes to
There's a lot I don't like about Linux - but RHELs kickstart + cobbler
works _very_ well.
And I really get better "support" from Michael et.al. via IRC/ML than
I get from other, wanna-be vendors via a paid contract.
Glad to hear that. Thanks!
cheers,
Rainer
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
02-04-2008, 08:01 PM
Rainer Duffner
"invalid kernel" -- found the problem!
Am 04.02.2008 um 21:27 schrieb JimmyT _:
I told you what we changed .... a new box, with a fresh download, and
a vanilla install.
Based on your reposnse, it's clear the perception is that "it's us".
Fair enough. We'll stick to supported products.
Do physical installs work?
It works here, basically out-of-the-box.
Sometimes, though, the RPC-XML interface can get "cobbled" and I've
got to restart httpd+cobblerd.
Haven't figured out why, though.
But I don't do any kind of Xen-installations. And I use RHEL5 as
base. Fedora is too much a moving target for us.
I really wish I had something like cobbler for my FreeBSD-installations.
There's a lot I don't like about Linux - but RHELs kickstart +
cobbler works _very_ well.
And I really get better "support" from Michael et.al. via IRC/ML than
I get from other, wanna-be vendors via a paid contract.
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
02-04-2008, 08:31 PM
Michael DeHaan
"invalid kernel" -- found the problem!
The problem is, that FreeBSD doesn't use pxelinux to boot - it has its
own PXE-bootloader.
Then, the equivalent of the ks.cfg file goes into the compressed
msfroot filesystem image, which would be a major pain to adapt.
The seperately bootloader itself would not be a show stopper -- there is
already some code there to supply elilo and alternate config files as
opposed to syslinux.
The ks.cfg problem, however would be annoying... however that doesn't
sound that far off from what koan does with initrd's to get around DHCP
timeouts. One potential solution would be to
try to make a ks.cfg equivalent that includes the rest of the
"kickstart" contents based on the result of a CGI script, so you only
have to generate the initrd once. That's
ugly though.
The problem with generating all variances server side (which is why
cobbler doesn't do it server side) for PXE setups (as opposed to
reinstalls) is that you end up generating an initrd for every profile/system
and that takes up a lot of space ... more importantly, it's just a slow
thing to do.
It also likes to work via FTP only (all the example scripts have NFS
commented out and setup FTP instead - as if everybody had tried and
then settled for the obvious.
I must look at that at some point - there's a howto about converting a
FreeBSD-ISO for PXE-booting with pxelinux here:
http://phaq.phunsites.net/?s=pxe
Fun...
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
02-04-2008, 08:33 PM
Rainer Duffner
"invalid kernel" -- found the problem!
Am 04.02.2008 um 22:00 schrieb Michael DeHaan:
Rainer Duffner wrote:
Am 04.02.2008 um 21:27 schrieb JimmyT _:
I told you what we changed .... a new box, with a fresh download,
and
a vanilla install.
Based on your reposnse, it's clear the perception is that "it's us".
Fair enough. We'll stick to supported products.
Do physical installs work?
It works here, basically out-of-the-box.
Sometimes, though, the RPC-XML interface can get "cobbled" and
I've got to restart httpd+cobblerd.
Haven't figured out why, though.
Development cobbler from git (0.7.X, 0.8 candidate) has some
logging updates that also include much better remote exception
handling, so stay tuned for that, I suspect that should go away. I
haven't seen any issues with cobblerd from the development build
which I've been running in a /long/ time. I do recall some issues
with cobblerd in previous releases.
It's not very often.
Maybe also was only in the vmware-image I tested this all with...
I really wish I had something like cobbler for my FreeBSD-
installations.
I'm not sure I've mentioned that to you yet or not (I know I have
some other folks) --
Cobbler already has support in there to do SuSE/Debian type
installs (they take an answer file, even if it's not technically a
kickstart). If there's an easy enough way to adapt
the code (mainly action_sync.py and item_distro.py) to grok the BSD
differences, I'd be willing to take incorporate it. Honestly I'm
not all that familiar with what it takes to
The problem is, that FreeBSD doesn't use pxelinux to boot - it has
its own PXE-bootloader.
Then, the equivalent of the ks.cfg file goes into the compressed
msfroot filesystem image, which would be a major pain to adapt.
It also likes to work via FTP only (all the example scripts have NFS
commented out and setup FTP instead - as if everybody had tried and
then settled for the obvious.
I must look at that at some point - there's a howto about converting
a FreeBSD-ISO for PXE-booting with pxelinux here: http://
phaq.phunsites.net/?s=pxe
There's a lot I don't like about Linux - but RHELs kickstart +
cobbler works _very_ well.
And I really get better "support" from Michael et.al. via IRC/ML
than I get from other, wanna-be vendors via a paid contract.
Reg. Adresse: Red Hat GmbH, Hauptstaetter Strasse 58, 70178 Stuttgart
Handelsregister: Amtsgericht Stuttgart HRB 153243
Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham,
Werner Knoblich
__________________________________________________ ___________________
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
02-04-2008, 09:51 PM
Chris Lalancette
"invalid kernel" -- found the problem!
Michael DeHaan wrote:
>>
>> Please do a netstat -alp | grep 25 when the xmlrpc gets b0rked. In my
>> case it *seems* that 25151 has been switched from python to dhcpd ?!?
>>
>> I am guessing that cobbler sync somehow mixes the ports sometimes, but I
>> also didn't have time to investigate.
>>
>
> That does not seem possible. I can believe it flipping out due to
> connection problems though (again, should be much happier in 0.7.X due
> to the new exception handling code).
(Disclaimer: I know nothing about cobbler internals in particular, this is just
a general piece of information)
Actually, it is possible, but it's not due to "mixed up ports". If cobbler has
port 25151 open -> accept, and then it forks/execs dhcpd, then dhcpd can inherit
that. I'm not sure if that is the case here, but that is one way it can happen.
Chris Lalancette
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools