Bug 510299

Sounds good to me. Static I am sure is still widely used in server environments. 

Cliff

Should be resolved as of http://git.fedorahosted.org/git/?p=spacewalk.git;a=commit;h=26aa7de5d7692f814e9f609d47c004f11a6f82f2


Following changes were made to the workflow
1) The Network Interface  selection was moved from Profile -> System Details to SDC -> Provisioning-> Schedule -> Advanced Configuration page, for the network option is more system specific than profile specific. So if you want to set provision thru static IP go to SDC Provisioning advanced configuration page.
 That being said, if the user wants to use network --bootproto  static for bare metal KS they can still go to Profiles -> Profile -> Advanced Options and add the bootproto line to network command. 

2) This option has been added to SSM provisioning also.

3) Spacewalk koan has been modified to deal with the static device addition and embed the kickstart in the initrd image similar to what was done in 5.2.

Muliple areas to test.
* SSH to your system and get the following details of your system,
Device/Interface Name (usually eth0)-> ifconfig,

IP Address:
ifconfig $DEVICE | perl -lne '/inet addr:([\d.]+)/ and print $1'

Netmask:
ifconfig $DEVICE | perl -lne '/Mask:([\d.]+)/ and print $1'

Hostname:
hostname

Nameservers:
cat /etc/resolv.conf | perl -lne '/^nameserver\s+(\S+)$/ and print $1'

Gateway:
route -n | grep '^0.0.0.0' | awk  '{print $2}'


*  SDC to that system -> Provisioning-> Schedule -> Advanced Configuration page change DHCP to static and select an interface (lets say eth0 for our example)..
*  Click Schedule and Finish
* rhn_check make sure it schedules everything ok
* shutdown -c, 
find the initrd image name from /etc/grub.conf  and look under /boot
cp the image to a tmp location and
gunzip < initrd.img | cpio -i --make-directories
make sure you find a ks.cfg file in the base dir with the following line, 
* network --bootproto static --device <DEVICE> --ip <IP> --gateway <GATEWAY> --nameserver <NAMESERVER> --netmask <NETMASK> --hostname <HOSTNAME>
the variables should be the same as the interface values you computed in the first step

If you are satisfied with this , reboot the machine and after a successful kickstart check -> /etc/sysconfig/network-scripts/ifcfg-<DEVICE>
you should see the correct values  for

DEVICE=<DEVICE>
HWADDR=<HWADDR>
ONBOOT=yes
BOOTPROTO=static
IPADDR=<IP>
NETMASK=<NETMASK>
DNS1=<NAMESERVER>


also check the host name.. "hostname"
It should look ok

also look at
Couple of things I 'd also test 
Select a Kickstart Profile and go to Advanced Options 
Change the network line from 
network: --bootproto dhcp
to
network: --bootproto dhcp TESTFOO
Go to kickstart file 
You should see the line-> 
network --bootproto dhcp TESTFOO

Just noticed that the spacewalkkoan code running this was determining the ip in an incorrect manner. Its using 
ifconfig  | perl -lne '/inet addr:([\d.]+)/ and print $1' 
instead of 
ifconfig <DEVICE NAME> | perl -lne '/inet addr:([\d.]+)/ and print $1' 

the first can potentially be wrong if more than 2 interfaces exist on the system.

Should be fixed as of http://git.fedorahosted.org/git/?p=spacewalk.git;a=commit;h=a507b500abb55acf19655b7df40b62c78dc94988

fails_qa
Satellite-5.3.0-RHEL5-re20090721.0-i386-embedded-oracle.iso

after satitc kickstart
[root@rlx-0-10 network-scripts]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
HWADDR=00:42:52:00:ED:D6
ONBOOT=yes
BOOTPROTO=dhcp

sorry I meant to fails_qa.

Should be fixed as of 
http://git.fedorahosted.org/git/?p=spacewalk.git;a=commit;h=a52696edf5cfb79624328bb92ff2af3349f98016

Satellite-5.3.0-RHEL5-re20090721.0-i386-embedded-oracle.iso
Yum updated to the latest
after static kickstart
[root@fjs-0-20 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
HWADDR=00:C0:9F:AC:62:4B
ONBOOT=yes
BOOTPROTO=static
IPADDR=10.10.76.147
NETMASK=255.255.254.0
DNS1=172.16.52.28
DNS2=172.16.52.27

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1434.html