On Tuesday, September 4, 2012 10:26:14 AM UTC-5, Bai Shen wrote:
>
> I've gotten an install of solr working, but it's pretty much a hack job at
> the moment. If y'all could give me your thoughts on how to improve my
> setup, I'd appreciate it. apache-tomcat is an rpm of Tomcat 7 that
> references the oracle jdk instead of openjdk.
>
[...]
class solr {
Since Package['apache-tomcat'] is apparently declared in a different class,
your should 'include' that class here.
service { 'iptables' :
ensure => stopped,
}
It's not a Puppet problem that your class stops iptables, but I sure find
it questionable in a broader sense. If you're turning it off because you
have a different local firewall installed (or because you have no IPv4
configured), then it would be more appropriate to manage that somewhere
else. On the other hand, if you're turning it off because it interferes
with SOLR, then you should address the problem by adding the appropriate
firewall rules, not by shutting down your firewall.
>
> file { '/opt/apache-tomcat/conf/Catalina':
> ensure => directory,
> }
>
> file { '/opt/apache-tomcat/conf/Catalina/localhost':
> ensure => directory,
> }
>
Supposing that directory /opt/apache-tomcat/conf belongs to
Package['apache-tomcat'], File['/opt/apache-tomcat/conf/Catalina'] should
'require' that package or the class that declares it. The */localhost file
will automatically require the File managing its parent directory, however,
so you don't need an explicit relationship there.
Does neither or those directories belong to the RPM, though? If they do,
then you're gaining nothing but complexity and cycle burn by declaring them
as you do above.
>
> file { '/opt/apache-tomcat/conf/Catalina/localhost/solr.xml':
> source => 'puppet:///modules/solr/solr.xml',
> owner => 'tomcat',
> group => 'tomcat',
> mode => '644',
> notify => Service['apache-tomcat'],
> require => Package['apache-tomcat'],
> }
>
>
> file { '/opt/apache-tomcat/conf/server.xml':
> source => 'puppet:///modules/solr/server.xml',
> owner => 'tomcat',
> group => 'tomcat',
> mode => '644',
> notify => Service['apache-tomcat'],
> require => Package['apache-tomcat'],
> }
>
file { '/opt/solr':
> ensure => directory,
> recurse => true,
> purge => true,
> source => 'puppet:///modules/solr/solr',
> owner => 'tomcat',
> group => 'tomcat',
> mode => '644',
> notify => Service['apache-tomcat'],
> require => Package['apache-tomcat'],
> }
>
> file { '/opt/solr/solr.war':
> ensure => 'link',
> target => '/opt/solr/apache-solr-3.6.1.war',
> }
>
I strongly recommend that you build a native package for SOLR, put it in a
local repository, and ensure it installed via a Puppet Package resource.
Recursive directory management will bite you, especially if there are many
files or large ones, plus using packages is in general a major win. You
can package up your custom SOLR configuration files along with, or manage
just those via File resources as you are now doing; either is fine.
>
> file { '/solr':
> ensure => directory,
> owner => 'tomcat',
> group => 'tomcat'
> }
>
No software should require its own subdirectory of the filesystem root.
I'm not sure what that directory is for, but the appropriate place for it
is likely to be under one of /var/lib, /usr/share, or /opt/solr.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/Vgv4PArhw5oJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
