From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040301 Description of problem: We have an activation key on RHN Sat 3.2 for RHEL3 clients with associated list of packages to be installed upon system registration: python-optik rhncfg rhncfg-actions rhncfg-client rhncfg-management rhns-config-libs This activation key subscribes system to RHEL3 and RHN Tools software channels and some config channels. The key has property "Schedule deployment of all configuration files upon system registration" turned on. When we use this key for system registration we can register system but two actions reported to Satellite as failed. The first is "Activation Key Config Packages Auto-Install": This action will be executed after 2004-04-29 18:17:08 (EST). This action's status is: Failed. The client picked up this action on 2004-04-29 18:17:41 (EST). The client completed this action on 2004-04-29 18:17:43 (EST). Client execution returned "Failed: Some of the packages specified were on a skip list" (code 30) Packages Scheduled: * rhncfg-client * rhncfg-actions * rhncfg -- File /etc/sysconfig/rhn/up2date has pkgSkipList=kernel*; So rhncfg packages are not in the skip list. All packages listed in activation key package list are installed during registration but Satellite gets error code 30 and logs actions as failed. The second action "Activation Key Config Auto-Deploy" depends from the first and also fails: This action will be executed after 2004-04-30 15:23:16 (EST). This action's status is: Failed. The client picked up this action on 2004-05-01 04:38:41 (EST). The client completed this action on 2004-05-01 08:38:43 (EST). Client execution returned "This action has been picked up multiple times without a successful transaction; this action is now failed for this system." (code ) Config Files: /etc/hosts.equiv (rev. 1) /etc/issue (rev. 1) /etc/login.defs (rev. 1) /etc/logrotate.d/syslog (rev. 1) /etc/motd (rev. 1) /etc/nsswitch.conf (rev. 1) /etc/ntp.conf (rev. 1) /etc/pam.d/system-auth (rev. 1) /etc/rc.d/rc.local (rev. 1) /etc/resolv.conf (rev. 1) /etc/securetty (rev. 1) /etc/shells (rev. 1) /etc/sysctl.conf (rev. 1) /etc/syslog.conf (rev. 1) /root/.bashrc (rev. 1) /root/.cshrc (rev. 1) /root/.k5login (rev. 1) /root/.profile (rev. 1) /root/.rhosts (rev. 1) -- The config files have not been deployed upon system registration but can be deployed later using "rhncfg-client get" command. This issue is specific for RHEL3 clients. The activation key with the same properties works fine for RHEL2.1 clients. Version-Release number of selected component (if applicable): up2date-4.2.5-1 libxml2-python-2.5.10-6 How reproducible: Always Steps to Reproduce: 1. Create activation key with package list python-optik rhncfg rhncfg-actions rhncfg-client rhncfg-management rhns-config-libs 2. Mark checkbox "Schedule deployment of all configuration files upon system registration" on Details page for activation key. 3. Assosiate RHEL 3 and RHN Tools channels with the activation key. 4. Create config channel, populate it with configuration files and assiciate with the activation key. 5. Subscribe RHEL 3 system with RHN Satellite using rhnreg_ks --force --activationkey ACTIVATION_KEY Actual Results: System is subscribed, all packages specified in activation key package list are installed, none of configuration files from config channel is deployed. RHN Satellite logs two actions as failed. Expected Results: RHN Satellite should log all actions as completed successfully. All config files from the channel should be deployed. Additional info:
> RHN Satellite logs two actions as failed. Can I get the output of the logs associated with those actions? The details as too what is on the skip list should be there (its sent to the server as well, but offhand not sure if the website actually displays that anywhere)
okay, reproduced this... At least in the way I reproduced it, there are two components, one is a bit of bad ui/user error (the former contributing greatly to the latter no doubt) and the other being vague/incorrect return code in up2date. the only way I was able to reproduce it to to schedule packages to be installed on registration that are not in a channel the box is subscribed to. In this case, the key probabaly doesn't auto suscribed the system to the Red Hat Network tools channel. What happens is up2date sees that it got scheduled a package that isnt in a channel it's subscribed to (arguably a web bug, since this isnt supposed to happen). When it tries to find the package, it's not available, and the client side fall though in that case is to decide the package is on the skip list, so thats the error message it returns. We probabaly need to fix the website ui to make this impossible to do, since it can't ever work. We also need to fix the client to not be so dumb in light of this, just in case it happens.
Please, look at the bug description again. You will see that ALL packages were installed upon registration. They are all available in RHN tools child channel. The log files are also submitted in the first post.
the only way I could get this to fail was to remove the /etc/sysconfig/rhn/allowed-actions/configfiles/all file. without this file, no config files will be installed. it looks like we need to discuss this file and activation keys. it's implemented in kickstarts, but it doesn't look like it's implemented for activation keys. maybe it should be.
The "Failed: Some of the packages specified were on a skip list" error message is a bug in up2date that I was able to reproduce on a very outdated RHEL3 box. But not on an updated client.
brezhnev, if you touch /etc/sysconfig/rhn/allowed-actions/configfiles/all on the client then run rhnreg_ks again with the activation key, do you still have the same problem? looking or an update.
I touched /etc/sysconfig/rhn/allowed-actions/all in bootstrap script before running rhnreg_ks and it did not install configuration files during system registration. I did not try to touch /etc/sysconfig/rhn/allow-actions/configfiles/all and I am not on-site with this customer anymore. I will forward your request to the customer. I saw the problem with up2date-4.2.5-1 Mihai, what version of up2date does not have this problem?
Still investigating - it may be an actual bug even in the latest up2date.
The customer tried to touch /etc/sysconfig/rhn/allowed-actions/configfiles/all. It did not help.
OK, the workaround is to run up2date -l Look at the section 'packages skipped' Install all of those rpms (either kernel packages or packages with a locally modified configuration)
Reproduced this bug by following the steps to create an activation key outlined in the initial comment. On a freshly installed rhel3-u2 system, I encountered the same errors that are discussed above. However, after upgrading to up2date-4.2.38, I was able to register with rhnreg_ks --key ACTIVATIONKEY and the packages were installed and config file successfully deployed. Furthermore, in RHN, 4 scheduled actions are listed as having successfully completed: Package update to enable configuration deployment Activation Key Config Auto-Deploy Activation Key Package Auto-Install Activation Key Config File Deployment So, up2date-4.2.38 provides a solution to this problem.
Ugh... so most current up2date solves this. CLOSING - CURRENTRELEASE breshnev: let us know if something crops up again.
I don't know how you managed to get rid of this problem in QA but I reproduced it once again with a different customer using the latest RHN Satellite 3.4 and RHEL 3u2 with up2date updated to 4.2.38. up2date-4.2.38 DOES NOT fix the problem. I am attaching the kickstart file used to reproduce this. As you can see in the post-install section, up2date package is updated to 4.2.38 but the result of the system installation is the same - Satellite logs 2 failed actions: 1. Action "Package update to enable configuration deployment" failed with a misleading error message: "Failed: Some of the packages specified were on a skip list". The details: This action will be executed after 2004-09-23 12:10:15 (EST). This action's status is: Failed. The client picked up this action on 2004-09-23 12:10:15 (EST). The client completed this action on 2004-09-23 12:10:17 (EST). Client execution returned "Failed: Some of the packages specified were on a skip list" (code 30) Packages Scheduled: * rhncfg-client-3.1.6-15 * rhncfg-actions-3.1.6-15 * rhncfg-3.1.6-15 2. Action "Activation key config auto-deploy" failed because it depends from rhncfg-* packages that were not installed before.
Created attachment 104211 [details] Kickstart to reproduce the problem
I cannot reproduce this -- I am attaching as descriptive a log as I could generate of the steps I took to reproduce, and I am able to use the activation key to update those packages, and also to create the configuration file. This is with Sat340, and a client box that is rhel3-u2 with up2date 4.2.38. brezhnev -- please review and advise. thanks.
Created attachment 104461 [details] reproduction attempt log here is the log of my repro attempt (in which the actions succeeded, ie: unable to repro)
You could not reproduce the bug because you did not configure the system to allow config file deployment before the first attempt to register your system with RHN. You should first, touch /etc/sysconfig/rhn/allowed-actions/configfiles/all and then rhnreg_ks --activationkey xxx... (Just look at the kickstart file in attachment #104461 [details].) As I wrote in my original post on 2004/05/06, RHN will log two failed actions but only one of them is actual failure. The first is about failed installations of rhncfg-* packages. But the packages WILL be installed (as they were installed in your attempt). Only RHN will think the action has failed. The config files will not be deployed during registration. This is the second failed action. But if you try to run "rhncfg-client get", all files will be deployed because rhncfg-* packages are here and ready. It is similar to what happened in your attempt when you tried to register your system second time when rhncfg-* packages had been installed to your system during the first registration.
Sorry, the kickstart is in attachment #104211 [details], not in 104461.
Ok, I second the details that you wrote two posts ago. 1. Packages were installed, but RHN says they failed (due to the "skip list"). 2. Config file therefore was not installed as well (RHN says "prerequisite failed") 3. "rhncfg-client get" will install the config files on the system. We were essentially on the same page yesterday, and I have confirmed your issues today. Sending this off to Adrian for him to look at a fix.
re #19, what client versions are you reproducing with?
Created attachment 104603 [details] output with "rhncheck -v -v -v" specified This is the output from the activation key run with verbose turned way up. It shows the skiplist error at the bottom, etc.
Well, this bug definitely is a sneaky little guy. Once more, we are seeing that with up2date-latest, the configfiles directory in place, and rhel3-u2, the package installs proceed and the config file is deployed correctly. Has the customer tried again with the above scenario? Is the problem still being reported? [root@vmware4 configfiles]# ls /etc/sysconfig/rhn/allowed-actions/configfiles all [root@vmware4 rhn]# rpm -q up2date up2date-4.2.38-1 [root@vmware4 rhn]# cat /etc/redhat-release Red Hat Enterprise Linux AS release 3 (Taroon Update 2) [root@vmware4 rhn]# rhnreg_ks --force --activationkey 7b6d79ed69639224f0d34ade23b9800b packages.update ([['python-optik', '', '', ''], ['rhncfg', '', '', ''], ['rhncfg-actions', '', '', ''], ['rhncfg-client', '', '', ''], ['rhncfg-management', '', '', ''], ['rhns-config-libs', '', '', '']],) Name Version Rel ---------------------------------------------------------- rhncfg 3.1.6 15 noarch rhncfg-actions 3.1.6 15 noarch rhncfg-client 3.1.6 15 noarch rhncfg-management 3.1.6 15 noarch rhns-config-libs 2.8 4 noarch rhncfg-3.1.6-15.noarch.rpm: ########################## Done. rhncfg-actions-3.1.6-15.noa ########################## Done. rhncfg-client-3.1.6-15.noar ########################## Done. rhncfg-management-3.1.6-15. ########################## Done. rhns-config-libs-2.8-4.noar ########################## Done. Preparing ########################################### [100%] Installing... 1:rhncfg ########################################### [100%] 2:rhncfg-client ########################################### [100%] 3:rhncfg-actions ########################################### [100%] 4:rhncfg-management ########################################### [100%] 5:rhns-config-libs ########################################### [100%] packages.update ([['rhncfg', '3.1.6', '15', ''], ['rhncfg-actions', '3.1.6', '15', ''], ['rhncfg-client', '3.1.6', '15', '']],) Name Version Rel ---------------------------------------------------------- The following packages you requested are already updated: rhncfg rhncfg-actions rhncfg-client configfiles.deploy ({'files': [{'username': 'root', 'config_channel': 'rhel3-config', 'delim_start': '{@', 'encoding': 'base64', 'md5sum': 'ee14abb8d4f34fabef57b2e2cec64019', 'delim_end': '@}', 'groupname': 'root', 'file_contents': 'dGVzdGluZyAxMjM0NQpqYXIgamFyIHN1Y2tz\n', 'filemode': 600, 'path': '/etc/xxx', 'revision': 1}]},) [root@vmware4 configfiles]# ls /etc/xxx /etc/xxx
Status? Do you NEEDINFO from someone Max?
My reproduction efforts have led me to the following conclusion today: The "installation failed because packages were on the skip list" message is misleading, because it does not refer to the rhncfg packages, but rather the fact that the kernel package is on the skipList -- in short, it is complaining if *any* files appear on the skip list. By modifying /etc/sysconfig/rhn/up2date and removing all packages from the skip list, the activation key runs successfully, installs the packages, and deploys the config files. This is on a rhel-as-3-u3 box with up2date-4.2.38-1 registered against PROD (361hosted)
I'm confused... comments #22 and #24 seem to contradict each other. #22 looks correct, but #24 says it produces an error not shown in #22?
Last investigated in 2005 and unable to reproduce, no activity since so closing this as CURRENTRELEASE. Please comment here if anyone is still struggling with this or able to reproduce against a recent version of Satellite.