11:48 a.m.
Here's my patch for preliminary ESXi pxe boot support. There's still a lot
that needs to be cleaned up/added to this (for instance, the append line
stuff in pxegen is kind of messy, and possibly incomplete), but overall
it's good to go. One major thing, the copying of all the extra .vgz files
that ESXi uses, needs to be done as a post-sync trigger - or if someone can
confirm the fetch-files stuff works (I may have missed a response to the
earlier email I sent regarding that) it could be built in there when the
distro is generated.
I don't have access to github from work, so it's a text patch for now.
When I get home later, I can upload this to my github account so it'll be
easier to merge and test.
Thoughts, comments, and critiques are welcome as always!
Thanks,
James Cammarata.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
11:51 a.m.
On Tue, 07 Sep 2010 11:48:30 -0500, James Cammarata <jimi(a)sngx.net> wrote:
Here's my patch for preliminary ESXi pxe boot support.
There's still a
lot
that needs to be cleaned up/added to this (for instance, the append
line
stuff in pxegen is kind of messy, and possibly incomplete), but overall
it's good to go. One major thing, the copying of all the extra .vgz
files
that ESXi uses, needs to be done as a post-sync trigger - or if
someone
can
confirm the fetch-files stuff works (I may have missed a response to
the
earlier email I sent regarding that) it could be built in there when the
distro is generated.
I don't have access to github from work, so it's a text patch for now.
When I get home later, I can upload this to my github account so it'll be
easier to merge and test.
Oh yeah, forgot to add that this is for 2.0 only right now, though I am
considering back-porting it to the 1.6 tree if there's any interest. We're
actually running 1.6 at my job still, though we're considering upgrading to
the 2.0 branch.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
10:03 a.m.
On Tue, 07 Sep 2010 11:51:02 -0500, James Cammarata <jimi(a)sngx.net> wrote:
On Tue, 07 Sep 2010 11:48:30 -0500, James Cammarata
<jimi(a)sngx.net>
wrote:
> Here's my patch for preliminary ESXi pxe boot support.
There's still a
lot
> that needs to be cleaned up/added to this (for instance, the append line
> stuff in pxegen is kind of messy, and possibly incomplete), but overall
> it's good to go. One major thing, the copying of all the extra .vgz
files
> that ESXi uses, needs to be done as a post-sync trigger - or if someone
can
> confirm the fetch-files stuff works (I may have missed a response to the
> earlier email I sent regarding that) it could be built in there when the
> distro is generated.
>
> I don't have access to github from work, so it's a text patch for now.
> When I get home later, I can upload this to my github account so it'll
be
> easier to merge and test.
Oh yeah, forgot to add that this is for 2.0 only right now, though I am
considering back-porting it to the 1.6 tree if there's any interest.
We're
actually running 1.6 at my job still, though we're considering
upgrading
to
the 2.0 branch.
Anyone had a chance to look at this? Is there any interest in it at all?
I know we've had people ask on the list before for ESXi support, so just
curious and following up.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
10:51 a.m.
I'm interested and I would like to test it out. I haven't had a
chance to check it out yet. I've found that ESX doesn't support ip
append 2 and that makes it difficult to do the scripted installs if
the first interface isn't the one being used to do the install. I
think VMware is moving away from ESX and the service console. I've
heard that I'm not 100% sure... I'm also interested in seeing how
this might integrate with the python tftp daemon and fetchable files
rather than using triggers. I haven't looked at this yet though but I
will shortly.
Have you spent any time looking at using koan to create the vmware
guests or if it makes sense to add additional fields to Cobbler for
VMware specific data?
On Wed, Sep 22, 2010 at 11:03 AM, James Cammarata <jimi(a)sngx.net> wrote:
On Tue, 07 Sep 2010 11:51:02 -0500, James Cammarata <jimi(a)sngx.net> wrote:
> On Tue, 07 Sep 2010 11:48:30 -0500, James Cammarata <jimi(a)sngx.net>
wrote:
>> Here's my patch for preliminary ESXi pxe boot support. There's still a
> lot
>> that needs to be cleaned up/added to this (for instance, the append line
>> stuff in pxegen is kind of messy, and possibly incomplete), but overall
>> it's good to go. One major thing, the copying of all the extra .vgz
> files
>> that ESXi uses, needs to be done as a post-sync trigger - or if someone
> can
>> confirm the fetch-files stuff works (I may have missed a response to the
>> earlier email I sent regarding that) it could be built in there when the
>> distro is generated.
>>
>> I don't have access to github from work, so it's a text patch for now.
>> When I get home later, I can upload this to my github account so it'll
be
>> easier to merge and test.
>
> Oh yeah, forgot to add that this is for 2.0 only right now, though I am
> considering back-porting it to the 1.6 tree if there's any interest.
We're
> actually running 1.6 at my job still, though we're considering upgrading
to
> the 2.0 branch.
Anyone had a chance to look at this? Is there any interest in it at all?
I know we've had people ask on the list before for ESXi support, so just
curious and following up.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
cobbler-devel mailing list
cobbler-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler-devel
11:08 a.m.
On Wed, 22 Sep 2010 11:51:53 -0400, Jonathan Sabo <jsabo(a)criminal.org>
wrote:
I'm interested and I would like to test it out. I haven't
had a
chance to check it out yet. I've found that ESX doesn't support ip
append 2 and that makes it difficult to do the scripted installs if
the first interface isn't the one being used to do the install. I
think VMware is moving away from ESX and the service console. I've
heard that I'm not 100% sure... I'm also interested in seeing how
this might integrate with the python tftp daemon and fetchable files
rather than using triggers. I haven't looked at this yet though but I
will shortly.
Have you spent any time looking at using koan to create the vmware
guests or if it makes sense to add additional fields to Cobbler for
VMware specific data?
I would like to, yes, but haven't yet. That's another discussion that has
come up many times in the past. I'm assuming it's a royal pain to get
working, as no one's done it yet :)
I also noticed ESXi is really, REALLY, picky about the append line - to the
point where order of arguments matters. I'm not sure if it even supports
the ksdevice=IF option correctly or setting the static IP info - I had the
most luck just letting it DHCP and letting the MAC search sort things out.
Thankfully the pre/post work like normal (as long as your shell commands
are compatible with the version of busybox ESXi uses).
I'd also like to look at the fetchable files stuff to avoid the triggers,
just not sure what the status on it is - I couldn't find any documentation
and it didn't appear to be working quite right from my attempts to use it
like template files.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
11:27 a.m.
I have recently configured cobbler for ESX/ESXi 4.x installs. Yes, it was a real pain in
the arse since vmware has done away with anaconda and now uses its own installer weasel.
The main issue I had with PXE installs is that after PXE and during the initialization of
the VMware boot kernel the second DHCP request will fail because the install is using
vswif0, which has a dynamically generated MAC, hence DHCP is impossible. The simple
solution was to append the IP/NETMASK/GATEWAY with PXE config to by-pass the second DHCP
and having to play with IPEND crap as well.
Here is what my pxe config looks like
default linux
prompt 0
timeout 1
label linux
kernel /images/vmware4_64_402/vmlinuz-esx402
append ksdevice=F4:CE:46:B3:1E:B0 noipv6 netmask=255.255.255.0
syslog=10.0.254.169:25150 ip=10.0.254.3 mem=800M text kssendmac gateway=10.0.254.1
initrd=/images/vmware4_64_402/initrd-esx402.img
ks=http://10.0.254.169/cblr/svc/op/ks/system/ny0eesx01
This works beautifully, I have VMware admins adding the ip/gateway/network to the kernel
options for the system.
Joseph Boyer Jr.
-----Original Message-----
From: cobbler-devel-bounces(a)lists.fedorahosted.org
[mailto:cobbler-devel-bounces@lists.fedorahosted.org] On Behalf Of Jonathan Sabo
Sent: Wednesday, September 22, 2010 11:52 AM
To: jimi(a)sngx.net; cobbler development list
Subject: Re: Preliminary ESXi support
I'm interested and I would like to test it out. I haven't had a
chance to check it out yet. I've found that ESX doesn't support ip
append 2 and that makes it difficult to do the scripted installs if
the first interface isn't the one being used to do the install. I
think VMware is moving away from ESX and the service console. I've
heard that I'm not 100% sure... I'm also interested in seeing how
this might integrate with the python tftp daemon and fetchable files
rather than using triggers. I haven't looked at this yet though but I
will shortly.
Have you spent any time looking at using koan to create the vmware
guests or if it makes sense to add additional fields to Cobbler for
VMware specific data?
On Wed, Sep 22, 2010 at 11:03 AM, James Cammarata <jimi(a)sngx.net> wrote:
On Tue, 07 Sep 2010 11:51:02 -0500, James Cammarata <jimi(a)sngx.net> wrote:
> On Tue, 07 Sep 2010 11:48:30 -0500, James Cammarata <jimi(a)sngx.net>
wrote:
>> Here's my patch for preliminary ESXi pxe boot support. There's still a
> lot
>> that needs to be cleaned up/added to this (for instance, the append line
>> stuff in pxegen is kind of messy, and possibly incomplete), but overall
>> it's good to go. One major thing, the copying of all the extra .vgz
> files
>> that ESXi uses, needs to be done as a post-sync trigger - or if someone
> can
>> confirm the fetch-files stuff works (I may have missed a response to the
>> earlier email I sent regarding that) it could be built in there when the
>> distro is generated.
>>
>> I don't have access to github from work, so it's a text patch for now.
>> When I get home later, I can upload this to my github account so it'll
be
>> easier to merge and test.
>
> Oh yeah, forgot to add that this is for 2.0 only right now, though I am
> considering back-porting it to the 1.6 tree if there's any interest.
We're
> actually running 1.6 at my job still, though we're considering upgrading
to
> the 2.0 branch.
Anyone had a chance to look at this? Is there any interest in it at all?
I know we've had people ask on the list before for ESXi support, so just
curious and following up.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
cobbler-devel mailing list
cobbler-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler-devel
_______________________________________________
cobbler-devel mailing list
cobbler-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler-devel
11:31 a.m.
On Wed, 22 Sep 2010 12:27:50 -0400, Joseph Boyer Jr. <jboyer(a)liquidnet.com>
wrote:
I have recently configured cobbler for ESX/ESXi 4.x installs. Yes, it
was
a
real pain in the arse since vmware has done away with anaconda and
now
uses
its own installer weasel. The main issue I had with PXE installs is
that
after PXE and during the initialization of the VMware boot kernel the
second DHCP request will fail because the install is using vswif0, which
has a dynamically generated MAC, hence DHCP is impossible. The simple
solution was to append the IP/NETMASK/GATEWAY with PXE config to by-pass
the second DHCP and having to play with IPEND crap as well.
Here is what my pxe config looks like
default linux
prompt 0
timeout 1
label linux
kernel /images/vmware4_64_402/vmlinuz-esx402
append ksdevice=F4:CE:46:B3:1E:B0 noipv6 netmask=255.255.255.0
syslog=10.0.254.169:25150 ip=10.0.254.3 mem=800M text kssendmac
gateway=10.0.254.1
initrd=/images/vmware4_64_402/initrd-esx402.img
ks=http://10.0.254.169/cblr/svc/op/ks/system/ny0eesx01
This works beautifully, I have VMware admins adding the
ip/gateway/network
to the kernel options for the system.
ESXi is actually it's own beast, you're just doing a straight up ESX 4.x
install (we do that as well here, and ran into the random MAC issue
ourselves). The solution to the random mac problem is, don't use vswif0 :)
Use vmnic0 instead, which is what we do and it works great with the static
IP config.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
3:05 p.m.
On Wed, Sep 22, 2010 at 12:31 PM, James Cammarata <jimi(a)sngx.net> wrote:
On Wed, 22 Sep 2010 12:27:50 -0400, Joseph Boyer Jr. <jboyer(a)liquidnet.com>
wrote:
> I have recently configured cobbler for ESX/ESXi 4.x installs. Yes, it was
a
> real pain in the arse since vmware has done away with anaconda and now
uses
> its own installer weasel. The main issue I had with PXE installs is that
> after PXE and during the initialization of the VMware boot kernel the
> second DHCP request will fail because the install is using vswif0, which
> has a dynamically generated MAC, hence DHCP is impossible. The simple
> solution was to append the IP/NETMASK/GATEWAY with PXE config to by-pass
> the second DHCP and having to play with IPEND crap as well.
>
> Here is what my pxe config looks like
>
> default linux
> prompt 0
> timeout 1
> label linux
> kernel /images/vmware4_64_402/vmlinuz-esx402
> append ksdevice=F4:CE:46:B3:1E:B0 noipv6 netmask=255.255.255.0
> syslog=10.0.254.169:25150 ip=10.0.254.3 mem=800M text kssendmac
> gateway=10.0.254.1
> initrd=/images/vmware4_64_402/initrd-esx402.img
> ks=http://10.0.254.169/cblr/svc/op/ks/system/ny0eesx01
>
>
> This works beautifully, I have VMware admins adding the
ip/gateway/network
> to the kernel options for the system.
ESXi is actually it's own beast, you're just doing a straight up ESX 4.x
install (we do that as well here, and ran into the random MAC issue
ourselves). The solution to the random mac problem is, don't use vswif0 :)
Use vmnic0 instead, which is what we do and it works great with the static
IP config.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
cobbler-devel mailing list
cobbler-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler-devel
How are you setting that on install and making it not create the
vswif0 interface? You can actually get it to work if you use ip
append 1 but that sucks. Do you mind sharing your template or
whatever settings you're doing to allow you to just assign the ip to a
vmnic and not vswif0? How do you get the service console not to use
vswif0...
3:26 p.m.
How are you setting that on install and making it not create the
vswif0 interface? You can actually get it to work if you use ip
append 1 but that sucks. Do you mind sharing your template or
whatever settings you're doing to allow you to just assign the ip to a
vmnic and not vswif0? How do you get the service console not to use
vswif0...
vswif0 still gets created, VMware creates it and assigns the random mac,
but all our kickstart traffic goes across vmnic0 still which we setup to
use the static IP normally just like any kickstart.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
3:39 p.m.
On Wed, Sep 22, 2010 at 4:26 PM, James Cammarata <jimi(a)sngx.net> wrote:
> How are you setting that on install and making it not create the
> vswif0 interface? You can actually get it to work if you use ip
> append 1 but that sucks. Do you mind sharing your template or
> whatever settings you're doing to allow you to just assign the ip to a
> vmnic and not vswif0? How do you get the service console not to use
> vswif0...
vswif0 still gets created, VMware creates it and assigns the random mac,
but all our kickstart traffic goes across vmnic0 still which we setup to
use the static IP normally just like any kickstart.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
I was trying that for awhile and wasn't having any luck with getting
it to work. I was using ESX 4.0... were you using 4.1 or something?
Maybe I was just messing it up. I'll have to retest.
So for automatically creating vmware guests... I see a few ways to
make that happen. You could template out the VMX files, you could use
one of the vmware api's, or you could use libvirtd. Libvirtd vmware
support isn't included in earlier RHEL versions and maybe none of
them... I haven't found the support in anything but the download from
the libvirt web page. Templating VMX files will work but it seems
like a hack... We could just use the koan vmcreate.py and just
update the vmx code or template it out and pull it from cobbler. I
wrote some code to remote control vmware vm's and create them using
the vijava api. It's an open source java api that's now a vmware
"fling". I basically ported one of the examples from Steve Jin's book
to jython from java and I made a little command line tool.
http://github.com/jsabo/vmware_misc/blob/master/manage-vms.py
Please forgive my lack of programming skill :)
I want to have a way to pull the information from Cobbler's virtual
section and create the virtual hardware for the guests and then have a
way to install them from Cobbler...
8:09 a.m.
On Wed, Sep 22, 2010 at 4:39 PM, Jonathan Sabo <jsabo(a)criminal.org> wrote:
On Wed, Sep 22, 2010 at 4:26 PM, James Cammarata
<jimi(a)sngx.net> wrote:
>
>> How are you setting that on install and making it not create the
>> vswif0 interface? You can actually get it to work if you use ip
>> append 1 but that sucks. Do you mind sharing your template or
>> whatever settings you're doing to allow you to just assign the ip to a
>> vmnic and not vswif0? How do you get the service console not to use
>> vswif0...
>
> vswif0 still gets created, VMware creates it and assigns the random mac,
> but all our kickstart traffic goes across vmnic0 still which we setup to
> use the static IP normally just like any kickstart.
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
I was trying that for awhile and wasn't having any luck with getting
it to work. I was using ESX 4.0... were you using 4.1 or something?
Maybe I was just messing it up. I'll have to retest.
So for automatically creating vmware guests... I see a few ways to
make that happen. You could template out the VMX files, you could use
one of the vmware api's, or you could use libvirtd. Libvirtd vmware
support isn't included in earlier RHEL versions and maybe none of
them... I haven't found the support in anything but the download from
the libvirt web page. Templating VMX files will work but it seems
like a hack... We could just use the koan vmcreate.py and just
update the vmx code or template it out and pull it from cobbler. I
wrote some code to remote control vmware vm's and create them using
the vijava api. It's an open source java api that's now a vmware
"fling". I basically ported one of the examples from Steve Jin's book
to jython from java and I made a little command line tool.
http://github.com/jsabo/vmware_misc/blob/master/manage-vms.py
Please forgive my lack of programming skill :)
I want to have a way to pull the information from Cobbler's virtual
section and create the virtual hardware for the guests and then have a
way to install them from Cobbler...
I'm finally testing... and I'm getting an exception. Still looking
for why. The action_import code looks like it should set it to esxi4.
scanning /var/www/cobbler/ks_mirror/vmware-esxi4.1-x86_64 for distro signature
found content (breed=vmware) at /var/www/cobbler/ks_mirror/vmware-esxi4.1-x86_64
creating new distro: vmware-esxi4.1-x86_64
Exception occured: exceptions.AttributeError
Exception value: 'NoneType' object has no attribute 'os_version'
Exception Info:
File "/usr/lib/python2.4/site-packages/cobbler/remote.py", line 89, in run
rc = self._run(self)
File "/usr/lib/python2.4/site-packages/cobbler/remote.py", line
219, in runner
self.logger
File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 664,
in import_tree
return importer.run()
File "/usr/lib/python2.4/site-packages/cobbler/action_import.py",
line 217, in run
os.path.walk(self.path, self.distro_adder, distros_added)
File "/usr/lib64/python2.4/posixpath.py", line 290, in walk
func(arg, top, names)
File "/usr/lib/python2.4/site-packages/cobbler/action_import.py",
line 553, in distro_adder
adtls.append(self.add_entry(dirname,kernel,initrd))
File "/usr/lib/python2.4/site-packages/cobbler/action_import.py",
line 641, in add_entry
self.distros.add(distro,save=True)
File "/usr/lib/python2.4/site-packages/cobbler/collection.py", line
288, in add
self.lite_sync.add_single_distro(ref.name)
File "/usr/lib/python2.4/site-packages/cobbler/action_litesync.py",
line 76, in add_single_distro
self.sync.pxegen.make_pxe_menu()
File "/usr/lib/python2.4/site-packages/cobbler/pxegen.py", line
266, in make_pxe_menu
self.make_actual_pxe_menu()
File "/usr/lib/python2.4/site-packages/cobbler/pxegen.py", line
343, in make_actual_pxe_menu
contents = self.write_pxe_file(None,None,None,None,image.arch,image=image)
File "/usr/lib/python2.4/site-packages/cobbler/pxegen.py", line
513, in write_pxe_file
elif distro.os_version.startswith("esxi"):
9:56 a.m.
343, in make_actual_pxe_menu
contents =
self.write_pxe_file(None,None,None,None,image.arch,image=image)
File "/usr/lib/python2.4/site-packages/cobbler/pxegen.py", line
513, in write_pxe_file
elif distro.os_version.startswith("esxi"):
Interesting, at that point the distro is None. During a lite sync on an
import, it must not be getting the distro object (or it can't find it yet,
for whatever reason). I think I tested that part of code post-import, so I
missed it.
I'll delete my ESXi distros and retest import, to see if I can reproduce
this.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
10 a.m.
On Wed, Oct 6, 2010 at 10:56 AM, James Cammarata <jimi(a)sngx.net> wrote:
> 343, in make_actual_pxe_menu
> contents =
> self.write_pxe_file(None,None,None,None,image.arch,image=image)
> File "/usr/lib/python2.4/site-packages/cobbler/pxegen.py", line
> 513, in write_pxe_file
> elif distro.os_version.startswith("esxi"):
Interesting, at that point the distro is None. During a lite sync on an
import, it must not be getting the distro object (or it can't find it yet,
for whatever reason). I think I tested that part of code post-import, so I
missed it.
I'll delete my ESXi distros and retest import, to see if I can reproduce
this.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
I have another person testing too and he was unable to reproduce it.
I rm'd my cobbler clone and pulled down a new clone and applied the
patch and then made rpms and upgraded. I get the same results. Its
looking like it's something to do with my setup but I'm not sure
what....
10:02 a.m.
I have another person testing too and he was unable to reproduce it.
I rm'd my cobbler clone and pulled down a new clone and applied the
patch and then made rpms and upgraded. I get the same results. Its
looking like it's something to do with my setup but I'm not sure
what....
Ok, if you can find a way to reproduce it reliably, let me know and I'll
troubleshoot it.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
9:52 a.m.
On Wed, Oct 6, 2010 at 11:02 AM, James Cammarata <jimi(a)sngx.net> wrote:
>
> I have another person testing too and he was unable to reproduce it.
> I rm'd my cobbler clone and pulled down a new clone and applied the
> patch and then made rpms and upgraded. I get the same results. Its
> looking like it's something to do with my setup but I'm not sure
> what....
Ok, if you can find a way to reproduce it reliably, let me know and I'll
troubleshoot it.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Something must have been corrupt on my previous test setup. After
creating a new one I was able to get the import to work immediately.
Following import from /var/www/cobbler/$profile_name/ you just cp
{menu.c32,vmkernel.gz,sys.vgz,cim.vgz,ienviron.vgz,install.vgz}
/tftpboot/images/$profile_name/ and then ESXi4 boots up and starts to
install.
It fails though because the pxe template has this:
append $img_path/vmkboot.gz $append_line --- $img_path/vmkernel.gz ---
$img_path/sys.vgz --- $img_path/cim.vgz --- $img_path/ienviron.vgz ---
$img_path/install.vgz ---
That last --- needs to go away.
ESXi4 uses busybox so you have wget... so I had to update the
$kickstart_start and $kickstart_done snippets...
## PXE JUST ONCE
#if $pxe_just_once in [ "1", "true", "yes",
"y" ]
#if $breed == 'redhat'
#set nopxe = "\nwget
\"http://%s/cblr/svc/op/nopxe/system/%s\" -O /dev/null" % (srv,
system_name)
#else if $breed == 'vmware' and $os_version == 'esx4'
#set nopxe = "\ncurl
\"http://%s/cblr/svc/op/nopxe/system/%s\" -o /dev/null" % (srv,
system_name)
#else if $breed == 'vmware' and $os_version == 'esxi4'
#set nopxe = "\nwget
\"http://%s/cblr/svc/op/nopxe/system/%s\" -o /dev/null" % (srv,
system_name)
#end if
#end if
I'm still working through some of this but the patches look good
except for that append line in the template.
4971
days inactive
5002
days old
cobbler-devel@lists.fedorahosted.org
14 comments
3 participants
participants (3)
-
James Cammarata -
Jonathan Sabo -
Joseph Boyer Jr.