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
Request Tracker... So much more than a help desk — Best Practical Solutions – 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
Request Tracker... So much more than a help desk — Best Practical Solutions – 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 
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”.