On Thursday, September 6, 2012 12:08:56 PM UTC-5, Bai Shen wrote:
>
>
> 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.
>>
>>
> When I tried it with just the second entry, it gave me an error saying
> that the parent didn't exist. According to some of the people on the irc,
> you have to declare the directories like this in order to have them created.
>
You misunderstood me. I was speaking there not about whether the parent
directory's File resource was needed, but rather about whether a
relationship was needed between the subdirectory and the parent directory
(it isn't, so you're fine in that respect).
>
>
>> 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.
>>
>
> I'm not sure what you mean by this.
>
I mean that the apache-tomcat package probably ought to be responsible at
least for directory /opt/apache-tomcat/conf/Catalina, and maybe for both of
those directories. If it provides them, then you should rely on the
package to get it right instead of managing those directories via Puppet as
well.
>
>
>> 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.
>>
>
> SOLR is a search engine. It requires a data directory to store it's index
> files. Since they can grow quite big, I was putting them on / and making
> it the largest partition. What would be the reasoning behind putting it in
> each of the locations you mentioned? I'm still learning the whys of how
> things are laid out on the filesystem.
>
The reasoning is basically to place programs, data, configuration, etc. in
consistent places so that people know where to look for them, so that
people can make intelligent choices about partitioning and filesystems, and
also to permit certain kinds of configuration (such as /usr being a shared,
read-only filesystem).
Garrett pointed you to the FHS, which goes into it in far more detail.
Basically, though, you have it exactly backwards when you say you put the
directory under / because its contents may get big. Instead, you should
ensure from the beginning that whatever filesystem contains /var (which may
be the root filesystem) is big, because that is the designated place for
applications' variable runtime files, some of which can grow very large.
Then when your applications are set up to put such files there, everything
works out as it should.
The proper place for a search engine's index files would probably be under
/var/lib (e.g. /var/lib/solr), or with solr installed in /opt, rigorous
compliance with the FHS would require use of /var/opt/solr instead. The
FHS docs for the various top-level directories are not very complicated,
though you can get bogged down reading all the options and details.
They're worth reading at least once.
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/-/ipxFwi7p0J0J.
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.
