Documentation bugs: 1. Wrong location for example passenger configuration file at http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html > Once Passenger is enabled, copy Dashboard’s example vhost from > ext/dashboard-vhost.conf
The file is actually in ext/passenger/dashboard-vhost.conf 2. Rake commands are run as root Absolutely none of the rake commands need to be run as root, however the documentation shows most of them being run as root (hash prompt). In some cases, running the commands as root will cause file permissions to be wrong. And in general, never do anything as root you don't have to. Packaging issues (on EL6): A. The documented rake command to generate certs fails because /usr/share/puppet-dashboard/certs doesn't exist, and /usr/share/puppet-dashboard is owned by root. I would either include the certs directory with the proper ownership, or have puppet-dashboard own the base directory. Or at least update the documentation to mention you need to create these by hand. B. Installation creates a default database.yml file for you, but not a default settings.yml (consistency?) C. The shell is set to /sbin/nologin, but it's favorable to simply become the dashboard user and run the rake commands as that user. I would make this clearer in the docs or provide a default shell. D. dashboard-vhost.conf - the default SSL has no auth, and sets "AllowOverride None", which differs from the settings in the non-SSL version. E. dashboard-vhost.conf -- The security issues for allowing direct access to report and upload are not documented. The comments in the file indicate that /reports/upload comes from the master (ie 127.0.0.1 would work if they are the same host) but this URL is actually called from each client directly, so that option won't work at all. The example should have a network IP and mask, and the comment shouldn't say "master" Documentation improvements: I would suspect a decent number of people will want to run their dashboard on the same server as the puppet master. If so, rather than running the rake tasks to generate certs, it's simpler to copy the certs from $ssldir, or point directly at those files from here. I would document this idea. Second, I believe that the proper apache configuration/security settings are a bit more obtuse than most users are prepared for. I would suggest that you ship a working apache configuration with tight security that only requires that they replace the local network mask, nodename, etc. I know apache configuration quite well, and it was a bit of a struggle to get it working for HTTP submissions of reports, but HTTPS authentication of users accessing the console. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
