Puppet users - Jul 2010 - ANNOUNCE: Puppet Dashboard 1.0.3 released

And we''re back fast and furious with another Dashboard release ...
1.0.3
... this one so hot we skipped 1.0.2 altogether.

The 1.0.3 release is another maintenance release that fixes bugs and
issues with the 1.0.1 release.  We''re planning a 1.1 release in the
near
future that will add additional features (you can
see the Roadmap at http://projects.puppetlabs.com/versions/show/48)

http://puppetlabs.com/downloads/dashboard/puppet-dashboard-1.0.3.tgz

New installation instructions for both 0.25.x and 2.6.x are also
available in the README:

http://github.com/reductivelabs/puppet-dashboard/blob/master/README.markdown

You will need to also perform a database migration as part of the
upgrade - Rails applications use database migration to add new tables
and columns to the database.  In the Puppet Dashboard directory, for
example /usr/share/puppet-dashboard, do:

$ sudo RAILS_ENV=production rake db:migrate

You''ll need to restart your webserver/server after this migration to
ensure everything is up-to-date.

Fixed in this release is:

v1.0.3
------
* MIGRATION: Added cache with node''s latest report and success status
to
improve performance.
* Added rake tasks to dump and restore the database, see README for details.
* Added database check to ensure it''s running the latest schema.
* Added support for accepting Puppet 2.6 reports, with limited support
for displaying their contents.
* Fixed and improved the README documentation with much more complete
installation instructions.
* Fixed node categorization, added new categories to "Nodes" sidebar
and
highlighting of errors.
* Fixed node failures causing them to be listed as failed forever.
* Fixed exceptions and messages shown if no items to display on groups,
classes and reports pages.
* Fixed styling of icons, warning sections, autocomplete, etc.
* Fixed chart rendering issues, including it being too wide to fit on
the screen.
* Fixed unintended dependencies on external Puppet and JSON gems.
* Fixed confusing headers for node listings shown as part of other pages.
* Improved reports by displaying logs sorted by severity level and
highlighting these accordingly.
* Improved performance of many pages by eliminating and optimizing
database queries.
* Improved performance by concatenating JavaScript and CSS files together.
* Removed unused checkboxes.
* Fixed exceptions on the node reports page.
* Fixed chart headers so they are shown only once.
* Fixed chart formatting errors.
* Fixed homepage warning message boxes to look like errors.
* Fixed errors in documentation.
* Added userful menu bar.
* Added version number to menu bar and release notes page.
* Added missing "favicon.ico", the lack of which was filling logs with
errors.
* Removed unused "Register" and "Log in" links.

New packages are also available.  We''d welcome reviews and feedback
into
our packaging processes too.

Regards

James Turnbull

-- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

OK, I need some help here.

I updated to 1.0.3 and now all I get from the web interface is the “something
went wrong” message. All I really need to know is where to look for clues.
There’s nothing in `puppet-dashboard/log/production.log` and nothing from Apache
in `/var/log/puppet/dashboard_error.log`.

For those with more time, here’s what I did. Maybe you can spot the error. (It’s
a RHEL5 system with Puppet Dashboard being run by Apache/Passenger.)

    cd /opt/puppet-dashboard
    git pull
    setenv RAILS_ENV production
    rake db:migrate
    cp ext/puppet/puppet_dashboard.rb
/usr/lib/ruby/site_ruby/1.8/puppet/reports/
    service httpd restart

From looking at the database directly, new reports are being stored, which I
suppose is the most important thing, but where can I find error logs for the web
interface?

Thanks.

-- 
Rob McBroom
<http://www.skurfer.com/>


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Rob McBroom wrote:
> OK, I need some help here.
> 
> I updated to 1.0.3 and now all I get from the web interface is the
“something went wrong” message. All I really need to know is where to look for
clues. There’s nothing in `puppet-dashboard/log/production.log` and nothing from
Apache in `/var/log/puppet/dashboard_error.log`.
> 
> For those with more time, here’s what I did. Maybe you can spot the error.
(It’s a RHEL5 system with Puppet Dashboard being run by Apache/Passenger.)
> 
Rob

Is there anything in /var/log/apache/error.log?

James

-- 
Puppet Labs - http://www.puppetlabs.com
C: 503-734-8571

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Aug 2, 2010, at 5:39 PM, James Turnbull wrote:
> Is there anything in /var/log/apache/error.log?
What the…? Yes. Why isn’t it going to the ErrorLog for that virtual host?

Anyway, there were a number of these:

    Rails Error: Unable to access log file. Please ensure that
/opt/puppet-dashboard/log/production.log exists and is chmod 0666. The log level
has been raised to WARN and the output directed to STDERR until the problem is
fixed.

So I chowned that directory and it’s files to the ‘apache’ user and now I’m
seeing:

ActionView::TemplateError (Permission denied -
/opt/puppet-dashboard/public/stylesheets/all.css) on line #14 of
app/views/layouts/application.html.haml:
11:       var relative_url_root =
''#{ActionController::Base.relative_url_root}'';
12:       $.noConflict();
13: 
14:     = stylesheet_link_tag ''reset'',
''layout'', ''forms'',
''tables'', ''jquery.ui.autocomplete.css'',
''typography'', ''links'',
''fcbkcomplete'', ''tipsy'',
''application'', :cache => ''all''
15:     = javascript_include_tag ''prototype'',
''jrails'', ''fcbkcomplete'',
''excanvas.min'', ''raphael-min'',
''grafico.min'', ''jquery.form'',
''jquery.placeholders'',
''jquery.ui.autocomplete'',
''jquery.ui.autocomplete.ext'',
''jquery.tipsy'', ''search'',
''application'', :cache => ‘all’

…followed by a trace through the application. The `production.log`, though it’s
now writable, contains nothing.

So I guess it’s trying to cache all the stylesheets and JavaScript into one
file? I chowned the `stylesheets` directory to apache:apache, but I still see
the error. Is there a list of paths that Passenger expects write-access to
somewhere? Why wasn’t this an issue before?

Thanks.

-- 
Rob McBroom
<http://www.skurfer.com/>

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 08/03/2010 06:01 AM, Rob McBroom wrote:
> On Aug 2, 2010, at 5:39 PM, James Turnbull wrote:
>
>   
>> Is there anything in /var/log/apache/error.log?
>>     
> What the…? Yes. Why isn’t it going to the ErrorLog for that virtual host?
>
> Anyway, there were a number of these:
>
>     Rails Error: Unable to access log file. Please ensure that
/opt/puppet-dashboard/log/production.log exists and is chmod 0666. The log level
has been raised to WARN and the output directed to STDERR until the problem is
fixed.
>
> So I chowned that directory and it’s files to the ‘apache’ user and now I’m
seeing:
>
> ActionView::TemplateError (Permission denied -
/opt/puppet-dashboard/public/stylesheets/all.css) on line #14 of
app/views/layouts/application.html.haml:
> 11:       var relative_url_root =
''#{ActionController::Base.relative_url_root}'';
> 12:       $.noConflict();
> 13: 
> 14:     = stylesheet_link_tag ''reset'',
''layout'', ''forms'',
''tables'', ''jquery.ui.autocomplete.css'',
''typography'', ''links'',
''fcbkcomplete'', ''tipsy'',
''application'', :cache => ''all''
> 15:     = javascript_include_tag ''prototype'',
''jrails'', ''fcbkcomplete'',
''excanvas.min'', ''raphael-min'',
''grafico.min'', ''jquery.form'',
''jquery.placeholders'',
''jquery.ui.autocomplete'',
''jquery.ui.autocomplete.ext'',
''jquery.tipsy'', ''search'',
''application'', :cache => ‘all’
>
> …followed by a trace through the application. The `production.log`, though
it’s now writable, contains nothing.
>
> So I guess it’s trying to cache all the stylesheets and JavaScript into one
file? I chowned the `stylesheets` directory to apache:apache, but I still see
the error. Is there a list of paths that Passenger expects write-access to
somewhere? Why wasn’t this an issue before?
>   
The application was failing at startup because it couldn''t write its
own
log files, and now it''s failing because it can''t write its
caches.

Please give ownership of the "puppet-dashboard" directory and
everything
in it to the same user, and grant this user read and write access to all
of this.

For example:
  chown -R apache:apache /opt/puppet-dashboard
  chmod -R ug+rwX /opt/puppet-dashboard

-igal

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Excerpts from Rob McBroom''s message of Mon Aug 02 12:40:21 -0700
2010:
> I updated to 1.0.3 and now all I get from the web interface is the
> “something went wrong” message. All I really need to know is where to
> look for clues. There’s nothing in
> `puppet-dashboard/log/production.log` and nothing from Apache in
> `/var/log/puppet/dashboard_error.log`.
Hi Rob,

The "something went wrong" message is shown in the Rails production
environment instead of the error message and stack trace you would see
in the development environment. Unfortunately, it tells us nothing about
what''s actually wrong. If the production.log file is empty, it might be
a permissions issue for the user you use to run Apache (can''t write to
the log).

Since the production log doesn''t show anything, you can try running
script/server from the Dashboard''s directory. This will start a Ruby
server (probably Webrick) in development mode. If the problem is during
boot, it''ll dump an error message. Otherwise, if you make a request to
that machine''s host at port 3000, you should see an actual error report
in your browser and in the standard output of the server (and in your
log/development.log). If not, it may be specific to the production
environment (unlikely) or to your Passenger setup (more likely). Let us
know and we can continue to troubleshoot.

Once we get some more information, we should be able to figure out
what''s going on.

Thanks!
-- 
Rein Henrichs
http://puppetlabs.com

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Aug 3, 2010, at 10:40 AM, Igal Koshevoy wrote:
> The application was failing at startup because it couldn''t write
its own
> log files, and now it''s failing because it can''t write
its caches.
> 
> Please give ownership of the "puppet-dashboard" directory and
everything
> in it to the same user, and grant this user read and write access to all
> of this.
> 
> For example:
>  chown -R apache:apache /opt/puppet-dashboard
>  chmod -R ug+rwX /opt/puppet-dashboard
OK, that plus a restart of Apache seems to have brought the web interface back.
Thanks.

Now, some questions:

  1. Is that a good idea; For the web server to have write access to the
application itself?
  2. Why wasn’t this necessary with previous versions?
  3. If it is necessary, should it be mentioned in the installation
instructions?

-- 
Rob McBroom
<http://www.skurfer.com/>

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Rob McBroom wrote:
> Now, some questions:
>   3. If it is necessary, should it be mentioned in the installation
instructions?
This one is my fault - I dropped the ball here - I tested the install
but thought the permissions problem was my fault rather than an issue.

Regards

James Turnbull

-- 
Puppet Labs - http://www.puppetlabs.com
C: 503-734-8571

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 08/03/2010 10:19 AM, Rob McBroom wrote:
> On Aug 3, 2010, at 10:40 AM, Igal Koshevoy wrote:
>
>   
>> The application was failing at startup because it couldn''t
write its own
>> log files, and now it''s failing because it can''t
write its caches.
>>
>> Please give ownership of the "puppet-dashboard" directory and
everything
>> in it to the same user, and grant this user read and write access to
all
>> of this.
>>
>> For example:
>>  chown -R apache:apache /opt/puppet-dashboard
>>  chmod -R ug+rwX /opt/puppet-dashboard
>>     
> OK, that plus a restart of Apache seems to have brought the web interface
back. Thanks.
>   
Great.
> Now, some questions:
>
>   1. Is that a good idea; For the web server to have write access to the
application itself?
>   
This is normal for Ruby on Rails applications like Puppet Dashboard and
those written in some other web frameworks.

This isn''t a big deal for typical Rails deployments because each app is
often run in a separate user account with write access to all its files,
and the apps'' code is managed locally with something like git or
externally with something like Capistrano.

However, this design causes hardship to those trying to distribute such
apps as OS packages and annoys sysadmins because it intermingles
read-only source code with configuration and variable files. Rails
doesn''t provide a straightforward way to separate these, although this
could be addressed with some surgery.
>   2. Why wasn’t this necessary with previous versions?
>   
All previous versions of Dashboard needed write access to the "db",
"log" and "tmp" directories. Writing to the
"public" directory is new to
this version.
>   3. If it is necessary, should it be mentioned in the installation
instructions?
>   
Thanks for the suggestion, I''ve added issue #4455 to address this.

-igal

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Excerpts from Rein Henrichs''s message of Tue Aug 03 10:15:05 -0700
2010:
> Once we get some more information, we should be able to figure out
> what''s going on.
> 
> Thanks!
Rob, looks like you''ve already resolved the issue. I guess I was late
to the party. Glad you got it sorted.
-- 
Rein Henrichs
http://puppetlabs.com

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Aug 3, 2010, at 2:30 PM, Rein Henrichs wrote:
> Rob, looks like you''ve already resolved the issue.
Yes. Thanks everyone for the responses.

-- 
Rob McBroom
<http://www.skurfer.com/>

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi there,
> All previous versions of Dashboard needed write access to the
"db",
> "log" and "tmp" directories. Writing to the
"public" directory is new to
> this version.
>
I can report that it now also needs write access to the "config"
directory.

Our dashboard has just been updated and the database migrated, but I
struggled with this error as well.
I''ve been using the Debian/Ubuntu packages from
http://apt.puppetlabs.com
so I''ve had to set the permissions manually on directories within /usr/
share/puppet-dashboard

Many thanks,
Ben

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.