Hide Forgot
Description of problem: To archive the PCI DSS we need to schedule the change of the password of the user root each 90 days at this moment we doing via script but would be great if in satellite 6 we can send the change of password via host collections as task and also that the task can give us the option to input a new password for all the servers or make random password for the server in case of random password have the ability to send back from the server a email specify in this task and also get the notification in openscan for the next release of Satellite 6 this must be 1 of the good feature to get the standard in pci dss. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: No option to change root password scheduled in host collections or send this kind of task Expected results: Have some option to change the password or automatic assing new password to the server via schedule task. Additional info:
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
This would be well served if our remote management had the ability to arbitrarily execute scripts against the managed hosts. You can do this currently with Satellite 5 and we need this in Satellite 6.
yes that's correct we can do this at the moment on Satellite 5 but to move forwared to Satellite 6 we need this feature also , thank you mike for you comment
With remote execution plugin one can define job template with optional user input for specifying a password and second one for specifying email address to which the result should be sent. The template would generate random password (on target host) or use the one specified through input (would be saved in clear text in DB though).
That's correct marek with remote-execute command i can send a echo with the ecrypted password for change the root and schedule every 90 day that resolve the issue but redhat is taking so much time to deliver this plugin that is already in katello and now our company is using that instead of satellite because the time of response for a simple solution that is already in your open source take some much time almost a year that's ridiculous, and we know redhat doesn't care of the customer because always is the same history with you products , opensource quick response and quick fix redhat only is quick fix and response when is a security bug but after that any new feature already in opensource taking you 1 or 2 years to have it at that time for the company is no compensate the current cost of license with the current customer service we get i don't blame you but is the true i would like someone from the top make a change and deliver to the customer the expectations that we are paying because you product is no free at all This issue we already fixed , move in to katello instead to use satellite for more that 1 year is funny you write until now because i know you are planing release 6.2 together with 1.11 foreman
I'm sorry you feel it this way. All I can say is that me and all other folks working on remote execution plugin are Red Hatters so therefore I'd say Red Hat came with the open source solution thus I think Red Hat cares about the customer. It's true that the plugin exists for a while, the first instalable version 0.0.1 was released on 14 Aug 2015 ~ 7 months ago. And I'm very happy that Red Hat stabilizes it first because, frankly, first versions of remote execution were simply not production ready. Thanks for the feedback about the release frequency, maybe we can consider making releases more often.
Verified. This will work with remote execution, you need only provide your script to Satellite and schedule it on the time basis you want (e.g. every 90 days). As you can write the script in any language, you can generate the password randomly if you wish. Additionally, remote execution jobs can take inputs, so you can also make the job take an input for the new root password. Thanks for the RFE.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1501