Mason_data and session_data, cache or lib?

I’m working on packaging RT3 so that it fits the FHS spec, by adding a FHS
section to config.layout, and I’m wondering if masonstatedir and
sessionstatedir are variable state information or cached data.

The difference between the two is that the “variable state” should be
preserved after a reboot, whilst “cached data” is pruned by the application,
or can be purged by the administrator, and the application will continue
working.

I’m guessing that they should go into the “variable state” directory, but I
just wanted to check if the data in them is actually just cache.

jaq@spacepants.org http://spacepants.org/jaq.gpg

Both of those should be nuked after a reboot. one is mason’s cache.
another is a session cache. I don’t think I’d trust either after a
reboot.On Wed, Jun 04, 2003 at 03:17:50PM +1000, Jamie Wilkinson wrote:

I’m working on packaging RT3 so that it fits the FHS spec, by adding a FHS
section to config.layout, and I’m wondering if masonstatedir and
sessionstatedir are variable state information or cached data.

The difference between the two is that the “variable state” should be
preserved after a reboot, whilst “cached data” is pruned by the application,
or can be purged by the administrator, and the application will continue
working.

I’m guessing that they should go into the “variable state” directory, but I
just wanted to check if the data in them is actually just cache.


jaq@spacepants.org http://spacepants.org/jaq.gpg


rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

http://www.bestpractical.com/rt – Trouble Ticketing. Free.

This one time, at band camp, Jesse Vincent wrote:

Both of those should be nuked after a reboot. one is mason’s cache.
another is a session cache. I don’t think I’d trust either after a
reboot.

Ok, /var/cache it is, then.

jaq@spacepants.org http://spacepants.org/jaq.gpg

At Wed, 4 Jun 2003 15:17:50 +1000,
Jamie Wilkinson wrote:

I’m working on packaging RT3 so that it fits the FHS spec, by adding a FHS
section to config.layout, and I’m wondering if masonstatedir and
sessionstatedir are variable state information or cached data.
I’m guessing that they should go into the “variable state” directory, but I
just wanted to check if the data in them is actually just cache.

masonstatedir is cached data.

sessionstatedir is probably variable state - but there are reasons to
preserve session states across server resets and such.

-R

This one time, at band camp, Robert Spier wrote:

At Wed, 4 Jun 2003 15:17:50 +1000,
Jamie Wilkinson wrote:

I’m working on packaging RT3 so that it fits the FHS spec, by adding a FHS
section to config.layout, and I’m wondering if masonstatedir and
sessionstatedir are variable state information or cached data.
I’m guessing that they should go into the “variable state” directory, but I
just wanted to check if the data in them is actually just cache.

masonstatedir is cached data.

sessionstatedir is probably variable state - but there are reasons to
preserve session states across server resets and such.

Care to elaborate? If that’s the case then masonstatedir can be
/var/cache/rt and sessionstatedir can be /var/lib/rt. At the moment I’ve
used /var/cache/rt/{session_data,mason_data}.

jaq@spacepants.org http://spacepants.org/jaq.gpg

Care to elaborate? If that’s the case then masonstatedir can be
/var/cache/rt and sessionstatedir can be /var/lib/rt. At the moment I’ve
used /var/cache/rt/{session_data,mason_data}.

It is probably safer (and clearer) to just keep the /var/cache/rt/
setup.

Going by “example”, /var/lib seems to be for things with "inifinite"
life, like MySQL databases. All of the RT data we’re talking about in
this thread could go away, and it would happily get regenerated.
(Although if it went away at the wrong time…)

MasonStateDir holds Mason compiled object files and stuff.

(From mason documentation)

The data directory is a writable directory that Mason uses for
various features and optimizations: for example, component object
files and data cache files. Mason will create the directory on
startup, if necessary, and set its permissions according to the
web server User/Group.

For the component files - it’s probably good to rebuild them when the
server restarts, assuming the server doesn’t restart often. But it’s
not strictly necessary, unless something has changed.

I’m not actually sure what session_data is in RT3. It may just be a
holdover in the config files from RT2. RT3 uses Apache::Session to
store session data in the database. RT2 used a directory.

(That was a lot of words to say, stick with /var/cache/rt)

-R

I’m not actually sure what session_data is in RT3. It may just be a
holdover in the config files from RT2. RT3 uses Apache::Session to
store session data in the database. RT2 used a directory.

By default yet, but it’s possible to configure RT to store on the
filesystem…which can be useful if you use a database apache::session
doesn’t support.

(That was a lot of words to say, stick with /var/cache/rt)

-R


rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel

http://www.bestpractical.com/rt – Trouble Ticketing. Free.

I’m working on packaging RT3 so that it fits the FHS spec, by adding a FHS
section to config.layout, and I’m wondering if masonstatedir and
sessionstatedir are variable state information or cached data.

We thought about this for the Debian package of RT3 and came up with
something that we felt matched the FHS fairly well.

Here is our config.layout:

prefix: /usr/share/request-tracker3 exec_prefix: /usr bindir: ${exec_prefix}/bin sbindir: ${exec_prefix}/sbin sysconfdir: /etc/request-tracker3 mandir: /usr/share/man libdir: /usr/share/perl5 datadir: ${prefix} htmldir: ${datadir}/html manualdir: /usr/share/doc/request-tracker3 logfiledir: /var/log/request-tracker3 localstatedir: /var/run/request-tracker3 masonstatedir: ${localstatedir}/mason_data sessionstatedir: ${localstatedir}/session_data customdir: /usr/local/share/request-tracker3 custometcdir: ${customdir}/etc customhtmldir: ${customdir}/html customlexdir: ${customdir}/po customlibdir: ${customdir}/lib

Any suggestions for improvements would be very welcome.

Stephen Quinney

Stephen> We thought about this for the Debian package of RT3 and came
Stephen> up with something that we felt matched the FHS fairly well.

Stephen> Here is our config.layout:

Stephen>
Stephen> prefix: /usr/share/request-tracker3
Stephen> exec_prefix: /usr
Stephen> bindir: ${exec_prefix}/bin
Stephen> sbindir: ${exec_prefix}/sbin
Stephen> sysconfdir: /etc/request-tracker3
Stephen> mandir: /usr/share/man
Stephen> libdir: /usr/share/perl5
Stephen> datadir: ${prefix}
Stephen> htmldir: ${datadir}/html
Stephen> manualdir: /usr/share/doc/request-tracker3
Stephen> logfiledir: /var/log/request-tracker3
Stephen> localstatedir: /var/run/request-tracker3
Stephen> masonstatedir: ${localstatedir}/mason_data
Stephen> sessionstatedir: ${localstatedir}/session_data
Stephen> customdir: /usr/local/share/request-tracker3
Stephen> custometcdir: ${customdir}/etc
Stephen> customhtmldir: ${customdir}/html
Stephen> customlexdir: ${customdir}/po
Stephen> customlibdir: ${customdir}/lib
Stephen>

Stephen> Any suggestions for improvements would be very welcome.

I’d prefer myself to see someway of having RT package all it’s needed
Perl modules and such into it’s own area, so that when you upgrade RT,
you don’t a) nuke your working instance and b) you can keep upgrades
seperate from the main perl area in case there are conflicts, etc.

For example, I don’t see much need for SearchBuilder to live in the
system wide perl lib dir at this time, especially with the amount of
churn it’s going through.

It’s nice to use CPAN to pull down the needed modules and have them
installed for you, but with all the issues people have reported on
this in the past, and the need for the ‘make testdeps’ target, it
would be nice to just get away from all this.

And I think it will simplify Jesse’s life as well, since people would
just download the one bundle, drop it into $prefix and run from there.

So in this case, I’d make $libdir above point to ${prefix}/lib to keep
it seperate from other apps in the system.

John
John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
stoffel@lucent.com - http://www.lucent.com - 978-399-0479

This one time, at band camp, Stephen Quinney wrote:

prefix: /usr/share/request-tracker3
exec_prefix: /usr

I disagree with this distinction, it doesn’t make sense given the usual
defaults that packages take. Since RT is an architecture neutral app, you
don’t need to make prefix and exec_prefix separate. In fact I’d be
surprised to see any recent Debian package with prefix and exec_prefix not the
same.

sysconfdir: /etc/request-tracker3

erk. So much typing!

libdir: /usr/share/perl5

As John Stoffel pointed out, RT isn’t actually a generic perl library, so
it’s probably better to put the backend of it into /usr/lib/rt

logfiledir: /var/log/request-tracker3

I chose /var/log/rt

localstatedir: /var/run/request-tracker3
masonstatedir: ${localstatedir}/mason_data
sessionstatedir: ${localstatedir}/session_data

This I really disagree with. I re-read the FHS specification, and given the
descriptions for /var/run, /var/cache, and /var/lib, /var/cache is
certainly the best location for masonstatedir and probably sessionstatedir,
and maybe /var/lib for sessionstatedir. /var/run’s description seems to
indicate that it is for files related to the actual running of a process,
such as pid files; and if session data is supposed to survive a reboot then
this directory is certainly not the place for it.

jaq@spacepants.org http://spacepants.org/jaq.gpg

This one time, at band camp, Stephen Quinney wrote:

prefix: /usr/share/request-tracker3
exec_prefix: /usr

I disagree with this distinction, it doesn’t make sense given the usual
defaults that packages take. Since RT is an architecture neutral app, you
don’t need to make prefix and exec_prefix separate. In fact I’d be
surprised to see any recent Debian package with prefix and exec_prefix not
the same.

Not sure what differences this makes to the actually layout of the
package in the FHS in the case of RT. I’ll investigate some more.

sysconfdir: /etc/request-tracker3
erk. So much typing!

We chose the request-tracker3 name as there is already a package
called request-tracker (version 2 of RT) and we needed to make the
distinction clear. We also chose to use the long name in the directory
names so that it’s clear to sysadmins what the directory is for and
which package it is associated with.

libdir: /usr/share/perl5

As John Stoffel pointed out, RT isn’t actually a generic perl library, so
it’s probably better to put the backend of it into /usr/lib/rt

As the RT libraries are architecture independent /usr/share/rt would
be better than /usr/lib/rt, certainly in Debian we would use
/usr/share for them.

logfiledir: /var/log/request-tracker3

I chose /var/log/rt

See my notes about /etc/request-tracker3

localstatedir: /var/run/request-tracker3
masonstatedir: ${localstatedir}/mason_data
sessionstatedir: ${localstatedir}/session_data

This I really disagree with. I re-read the FHS specification, and given the
descriptions for /var/run, /var/cache, and /var/lib, /var/cache is
certainly the best location for masonstatedir and probably sessionstatedir,
and maybe /var/lib for sessionstatedir. /var/run’s description seems to
indicate that it is for files related to the actual running of a process,
such as pid files; and if session data is supposed to survive a reboot then
this directory is certainly not the place for it.

I will take a look at those bits again, I find it a bit unclear as to
what the differences in /var/run, /var/cache and /var/lib really are
in situations like this.

Thanks for the comments,

Stephen Quinney

This one time, at band camp, Stephen Quinney wrote:

This one time, at band camp, Stephen Quinney wrote:

prefix: /usr/share/request-tracker3
exec_prefix: /usr

I disagree with this distinction, it doesn’t make sense given the usual
defaults that packages take. Since RT is an architecture neutral app, you
don’t need to make prefix and exec_prefix separate. In fact I’d be
surprised to see any recent Debian package with prefix and exec_prefix not
the same.

Not sure what differences this makes to the actually layout of the
package in the FHS in the case of RT. I’ll investigate some more.

Well, none specifically. But it looks weird :slight_smile:

sysconfdir: /etc/request-tracker3
erk. So much typing!

We chose the request-tracker3 name as there is already a package
called request-tracker (version 2 of RT) and we needed to make the
distinction clear. We also chose to use the long name in the directory
names so that it’s clear to sysadmins what the directory is for and
which package it is associated with.

That’s what I figured, so I shouldn’t complain.

libdir: /usr/share/perl5

As John Stoffel pointed out, RT isn’t actually a generic perl library, so
it’s probably better to put the backend of it into /usr/lib/rt

As the RT libraries are architecture independent /usr/share/rt would
be better than /usr/lib/rt, certainly in Debian we would use
/usr/share for them.

That’s a good point, I’ll check it out.

logfiledir: /var/log/request-tracker3

I chose /var/log/rt

See my notes about /etc/request-tracker3

Yep. But since I’m going for OS agnostic FHS with my layout, I think
/var/log/rt and /etc/rt are more appropriate for the upstream source.

I will take a look at those bits again, I find it a bit unclear as to
what the differences in /var/run, /var/cache and /var/lib really are
in situations like this.

/var/run seems to be for state files specifically related to the running of
processes.

/var/cache contains dynamically generated data (as seen in mason) that the
admin can nuke at their whim, and it’s expected that the program itself will
clean up after itself when it no longer needs the cache.

/var/lib is for state files that need to be preserved between reboots, but
otherwise behaves much the same way as /var/cache – the main difference
being that of availability.

jaq@spacepants.org http://spacepants.org/jaq.gpg

Stephen> We chose the request-tracker3 name as there is already a
Stephen> package called request-tracker (version 2 of RT) and we
Stephen> needed to make the distinction clear. We also chose to use
Stephen> the long name in the directory names so that it’s clear to
Stephen> sysadmins what the directory is for and which package it is
Stephen> associated with.

I’d still rather see rt3 instead. Or better yet, rt-, since
you might want to have multiple versions installed at the same time.

Stephen> As the RT libraries are architecture independent
Stephen> /usr/share/rt would be better than /usr/lib/rt, certainly in
Stephen> Debian we would use /usr/share for them.

I think /usr/lib/rt- is the best place, since I’m not really
sure that all the various perl libs are arch independent, esp the
DBI::, Digest::, etc. Take a look at tools/testdeps and see what I
mean.

In any case, I think you need to put the VERSION of RT into the
$prefix.

Stephen> Thanks for the comments,

No problems.

sysconfdir: /etc/request-tracker3
erk. So much typing!

I also believe Jesse would prefer ‘rt3’ or rt-3.

-R

Stephen Quinney wrote:

We chose the request-tracker3 name as there is already a package
called request-tracker (version 2 of RT) and we needed to make the
distinction clear. We also chose to use the long name in the directory
names so that it’s clear to sysadmins what the directory is for and
which package it is associated with.

The package is called “RT”, not “Request Tracker”.