Hide Forgot
(4.1) Document default password's location in pulp.conf (4.1) Suggest use of alternate directories besides /etc/pki so rhui-manager can be run as a non-root user. Alternatively, recommend generating certificates from a node distinct from rhua or cds nodes (4.2) request feature to allow customer to specify target template, & then prepopulate repo's to be sync
(In reply to comment #0) > (4.1) Document default password's location in pulp.conf Where should this information go, and what information do you want included? The Important admonition points to Ch11 for instructions on changing the password. Perhaps the location of the password in pulp.conf is better suited for that chapter? Please also keep in mind that we are documenting the UI, not the CLI. > > (4.1) Suggest use of alternate directories besides /etc/pki so > rhui-manager can be run as a non-root user. Alternatively, > recommend generating certificates from a node distinct > from rhua or cds nodes This is an engineering decision, not a documentation one. > > (4.2) request feature to allow customer to specify target template, > & then prepopulate repo's to be sync This is an engineering decision, not a documentation one. LKB
> (4.1) Document default password's location in pulp.conf I can see how this might be confusing. It's an implementation detail in Pulp that I've never agreed with. There is no database initialization step in Pulp. Well, actually there is, but that came after the default user code was in place. So what happens is that at Pulp server startup, Pulp checks to see if there's an admin user. If not, it will create one using the password in pulp.conf. After that, the password entry in pulp.conf isn't used. So while it looks really bad just sitting there, it wasn't mentioned in the docs to change it since it's not used for anything. Elsewhere in the documentation we mention to use rhui-manager to change the password, which IMO is a good enough approach. > (4.1) Suggest use of alternate directories besides /etc/pki so > rhui-manager can be run as a non-root user. Alternatively, > recommend generating certificates from a node distinct > from rhua or cds nodes File a bug against RHUI to entertain this. My gut reaction is that this is the best location since that directory contains some sensitive information and is protected by SELinux. But I can see how a read-only style user that just looks at health would be desired as non-root. I know it was entertained, just not sure how feasible it is in the current code base. > (4.2) request feature to allow customer to specify target template, > & then prepopulate repo's to be sync File it as an RFE against the RHUI project.
Closing as there are documentation changes to make. Karthik, please raise bugs for engineering as requested in Comment 2. LKB
Released in RHUI 2.0.2