From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8 Description of problem: I create a Kickstart Profile with Satellite. I can not find a way to modify the ks file to point to the Proxy IP. The IP used for wget in the ks file is for Satellite Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Via Satellite GUI, Systems -> Kickstart -> Create New Kickstart 2. Answer questions 3. Systems -> Kickstart -> <click on Profile> -> View Kickstart 4. The values at the bottom of the file use satellite IP and can not change to proxy IP Actual Results: Kickstart does not complete because the machine can not register. Expected Results: The machine should be able to download the files, install them and register successfully. Additional info: The network information is changed below. I also changed root hash and removed the certificate. The URLs for the wgets were modified also to use xxxx, aaaa, bbbb, etc. SATELLITE 192.168.5.5 PROXY 192.168.1.5 # Kickstart config file generated by RHN Config Management # # Profile Name: 21 Test # Profile Label: 21Test # install text network --bootproto static -ip 192.168.1.12 --broadcast 192.168.1.255 --netmask 255.255.255.0 --network 192.168.1.0 --gateway 192.168.1.1 --nameserver 192.168.1.31 url --url http://192.168.5.5/kickstart/dist/ks-redhat-advanced-server-i386-qu3 lang en_US.UTF-8 langsupport --default en_US.UTF-8 en_US.UTF-8 keyboard us mouse generic3ps/2 --device psaux zerombr yes clearpart --all --drives=sda partition /boot --fstype ext3 --size=2048 partition swap --size=2048 --grow --maxsize=2048 partition / --fstype ext3 --size=1024 --grow --ondisk=sda bootloader --location mbr timezone America/New_York auth --enablemd5 --enableshadow rootpw --iscrypted xxxxxxxxxxxx firewall --disabled skipx reboot %packages nc telnet kernel-enterprise XFree86 chkfontpath nfs-utils kernel-smp binutils lsof Xaw3d Mesa openssh ethtool XFree86-libs openssh-clients sudo portmap freetype perl perl-CPAN perl-CGI perl-DB_File perl-NDBM_File sharutils up2date gnupg rhnlib python-popt gmp ntp libcap pdksh XFree86-xfs openssh-server tcpdump perl-suidperl pyOpenSSL rpm-python rhn_register python bind-utils @ Base @ Network Support %pre %post --nochroot cp /etc/resolv.conf /mnt/sysimage/etc/resolv.conf %post ( # Log %post errors # --Begin RHN command section-- cat > /tmp/ssl-key-1 <<EOF <REMOVED> -----BEGIN CERTIFICATE----- <REMOVED> -----END CERTIFICATE----- EOF # ssl-key-1 cat /tmp/ssl-key-* > /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT perl -npe 's/RHNS-CA-CERT/RHN-ORG-TRUSTED-SSL-CERT/g' -i /etc/sysconfig/rhn/* mkdir -p /tmp/rhn_rpms/optional wget -P /tmp/rhn_rpms/optional http://192.168.5.5/download/xxxx/aaaa/0/0/redhat/NULL/pyOpenSSL/0.5.1-7.152/i386/pyOpenSSL-0.5.1-7.152.i386.rpm http://192.168.5.5/download/xxxx/bbbb/0/0/redhat/NULL/rhnlib/1.3-11.152/noarch/rhnlib-1.3-11.152.noarch.rpm wget -P /tmp/rhn_rpms http://192.168.5.5/download/xxxx/cccc/0/0/redhat/NULL/rhn_register/2.9.3-1.2.1AS/i386/rhn_register-2.9.3-1.2.1AS.i386.rpm http://192.168.5.5/download/xxxx/dddd/0/0/redhat/NULL/up2date/2.9.3-2.2.1AS/i386/up2date-2.9.3-2.2.1AS.i386.rpm http://192.168.5.5/download/xxxx/eeee/0/0/redhat/NULL/rhn_register-gnome/2.9.3-1.2.1AS/i386/rhn_register-gnome-2.9.3-1.2.1AS.i386.rpm http://192.168.5.5/download/xxxx/ffff/0/0/redhat/NULL/up2date-gnome/2.9.3-2.2.1AS/i386/up2date-gnome-2.9.3-2.2.1AS.i386.rpm rpm -Uvh --replacepkgs --replacefiles /tmp/rhn_rpms/optional/pyOpenSSL* /tmp/rhn_rpms/optional/rhnlib* rpm -Fvh /tmp/rhn_rpms/*rpm gpg $(up2date --gpg-flags) --batch --import /usr/share/rhn/RPM-GPG-KEY gpg $(up2date --gpg-flags) --batch --import /usr/share/rhn/RPM-GPG-KEY perl -npe 's/xmlrpc.rhn.redhat.com/192.168.5.5/' -i /etc/sysconfig/rhn/up2date perl -npe 's/xmlrpc.rhn.redhat.com/192.168.5.5/' -i /etc/sysconfig/rhn/rhn_register mkdir -p /etc/sysconfig/rhn/allowed-actions/configfiles touch /etc/sysconfig/rhn/allowed-actions/configfiles/all rhn_check # --End RHN command section-- /sbin/chkconfig --level 345 lpd off /sbin/chkconfig --level 345 sendmail off /sbin/chkconfig --level 345 ipchains off /sbin/chkconfig --level 345 iptables off /sbin/chkconfig --level 345 cups off # MOTD echo >> /etc/motd echo "RHN kickstart on $(date +'%Y-%m-%d')" >> /etc/motd echo >> /etc/motd ) > /root/ks-post.log 2>&1 # end of generated kickstart file
One can kickstart a system through an RHN Proxy only if the system is previously registered and going through an RHN Proxy. If you try to kickstart a box you should see a checkbox that says: "Preserve RHN Proxy Config". If the box did not previously go through an RHN Proxy you will not see this option. There is a bug/feature opened for a dropdown box to choose/change the hostname/IP a box connects to. So... the question I have is: Did this machine previously go through an RHN Proxy?
Wow... this bug is 3.5 months old. Sorry Greg. I will make a point of abusing someone for you.
Changing this bug to be the bug referred to in comment #1 (a dropdown bug didn't already exist). It appears that the underlying problem is that the user isn't able to choose which proxy to kickstart off of. If the org has RHN proxies, a dropdown list for RHN proxies should come up during the kickstart process for a particular system: Systems-><machine link>->kickstart->Continue (https://rhn.redhat.com/network/systems/details/kickstart/options.pxt) The dropdown should show up regardless of whether or not the system itself was registered through a proxy.
Bear in mind that only newer (>3.2?) proxies report the information required for us to do this.
Fixed in CVS. Test plan: 1) Test this feature with an org that has provisioning and at least two proxies. *Note* It is probably wise to test this with an org with a 'proxy chain' - ie, client -> proxy1 -> proxy2 -> hosted or sat 2) Kickstart a system. You will notice that instead of the 'preserve proxy configuration' checkbox, there will be an 'RHN Proxy' selectbox. It should default to whatever proxy the system is currently using, or 'None' if the system is not currently connecting through a proxy. 3) Check to ensure that the system connects through the specified proxy after kickstartting. 4) Repeat steps 2-3 with various selections to ensure that systems kickstart properly (ie, 'no proxy', a specific proxy, a proxy that is part of a chain, etc) 5) Kickstart several systems via the SSM. Notice that the RHN Proxy Configuration section has a pair of radio buttons: o Preserve RHN Proxy Configuration and o Use RHN Proxy The 'Use RHN Proxy' option has a selectbox next to it, very similar to the single-system case. The 'Preserve' option should keep each system's proxy configuration individually - ie, if a given system connects through a proxy pre-kickstart, it should connect to the same proxy post-kickstart. If it does not connect through a proxy, then it won't post-kickstart. The 'Use RHN Proxy' option works like the one for a single system, except that we default to 'None', since the various systems will probably have different proxy configurations. Doc notes: The single system and SSM cases work as described in the test plan. The key thing to note about the single system option is that the systems current proxy server, if any, should be selected by default. The key thing to note about the SSM case is that since not all systems will necessarily have the same proxy configuration to begin with, we have the 'Preserve existing proxy configuration' option to keep each system configured as it was to begin with. The 'Use RHN Proxy' sets the proxy for *all* the systems being kickstarted. If the user wants to use (for instance) two different proxies specifically for a group of 50 systems, then he should perform two different kickstart actions via the SSM.
Ooops - didn't notice the new documentation process until after I wrote the above - creating bug #147144 to track the docs for this bug.
Created attachment 110649 [details] A view of the SDC with this enhancement, no proxy selected
Created attachment 110651 [details] A view of the SDC, a proxy is selected
Created attachment 110653 [details] A view of the SSM, 'Preserve existing configuration'
Created attachment 110655 [details] A viewof the SSM, with a proxy selected
There is some broken stuff here, which will be filed soon as new bugs that block this one.
the associated docs bug was punted to the next release, RHN 400. bug 147144
Moving this back to 'MODIFIED', because the only outstanding issue is the link to the CA SSL cert docs, and taw was complaining about this bug still being in FAILSQA.
This bug and it's children are all 'ON_QA', *except* for the caveat that the links to the docs page does not yet exist.
Initial setup: rhnblade4 -> rhnblade3 (proxy) -> webqa rlx-2-14 -> webqa Tests performed: 0. Verify that kickstarts through the Proxy require the SSL key to be associated in the kickstart profile -- PASS 1. kickstart rhnblade4, through the proxy -- PASS 2. kickstart rlx-2-14, through the proxy -- PASS 3. verify that the kickstarts are touching the proxy -- PASS 4. make sure both systems have proper upstream connections post-kick -- PASS 5. verify that rlx-2-14 is now going through the proxy for everything -- PASS 5. kickstart both simulatenously through the SSM, through the proxy -- PASS 6. verify upstream connections are correct post-kick -- PASS modify the configuration so that one box goes through the proxy and the other doesn't 8. use SSM to kickstart, testing the Preserve Configuration option -- FAIL 9. schedule the installation of a second proxy -- PASS 10. verify that both RHN-ORG-TRUSTED-SSL-CERTs are in hosted -- PASS Note that test #8 failed -- another bug will be opened on this that blocks this bug.
another item verified working: system registered directly to webqa choose to kickstart, selecting to kick through a proxy system comes back connected to the proxy, able to talk through the proxy to hosted.
Children are all PROD_READY again, all the tests above (in comment #15) now pass, along with a two-level proxy chain to a satellite. PROD_READY
mass move: PROD_READY --> CLOSED:CURRENTRELEASE