When I added the /tmp/twiki as the default for $TWiki::cfg{TempfileDir} I tested many times that running twiki without this directory and looking at a TWiki page made CGI::Session create the twiki dir in tmp
I have seen a report on IRC that this was not the case.
And I have now seen a Fedora Core 5 not accept it when I upgraded my production server.
But on my Centos 4.4 (like RHEL4) the directory was created without any problem.
So we need to do something about this.
For now I will update the documentation for it.
Strange that there is this difference. That comes as a surprise to me. I was sure we could always let Apache create a directory when it was allowed to create files.
--
TWiki:Main/KennethLavrsen
- 05 Feb 2007
Without knowing the details, this could sound a bit like it might be
Wikipedia:SELinux
that is kicking in in the new setup? (
Check for denied accesses
in the logs).
--
TWiki:Main.SteffenPoulsen
- 05 Feb 2007
I do not have SELinux enabled. It is worse to setup than sendmail. Whoever invented this must hate the world.
I looked at the logs and the problem may not be related to which Linux but which state your browser is in.
Does it think it is authenticated or not. This is the error from the apache error log.
[Mon Feb 05 18:43:07 2007] [error] [client 192.168.1.9] [Mon Feb 5 18:43:07 2007] view: Couldn't store 54b3335b104e7592a22d3a1d129433d7 into /tmp/twiki/cgisess_54b3335b104e7592a22d3a1d129433d7: No such file or directory at /usr/local/apache2/twiki/lib/TWiki/Client.pm line 440.
[Mon Feb 05 18:43:07 2007] [error] [client 192.168.1.9] [Mon Feb 5 18:43:07 2007] view: \t(in cleanup) could not flush: Couldn't store 54b3335b104e7592a22d3a1d129433d7 into /tmp/twiki/cgisess_54b3335b104e7592a22d3a1d129433d7: No such file or directory at /usr/local/apache2/twiki/bin/view line 0
[Mon Feb 05 18:43:07 2007] [error] [client 192.168.1.9] [Mon Feb 5 18:43:07 2007] view: Couldn't store 5900c0f44714a3248dd1a371e7aeb2d3 into /tmp/twiki/cgisess_5900c0f44714a3248dd1a371e7aeb2d3: No such file or directory at /usr/local/apache2/twiki/lib/TWiki/Client.pm line 440.
[Mon Feb 05 18:43:07 2007] [error] [client 192.168.1.9] [Mon Feb 5 18:43:07 2007] view: \t(in cleanup) could not flush: Couldn't store 5900c0f44714a3248dd1a371e7aeb2d3 into /tmp/twiki/cgisess_5900c0f44714a3248dd1a371e7aeb2d3: No such file or directory at /usr/local/apache2/twiki/bin/view line 0
[Mon Feb 05 18:43:08 2007] [error] [client 192.168.1.9] [Mon Feb 5 18:43:08 2007] view: Couldn't store 5890c0b5a584d288ff2be6f1a5bf53d2 into /tmp/twiki/cgisess_5890c0b5a584d288ff2be6f1a5bf53d2: No such file or directory at /usr/local/apache2/twiki/lib/TWiki/Client.pm line 440.
[Mon Feb 05 18:43:08 2007] [error] [client 192.168.1.9] [Mon Feb 5 18:43:08 2007] view: \t(in cleanup) could not flush: Couldn't store 5890c0b5a584d288ff2be6f1a5bf53d2 into /tmp/twiki/cgisess_5890c0b5a584d288ff2be6f1a5bf53d2: No such file or directory at /usr/local/apache2/twiki/bin/view line 0
[Mon Feb 05 18:43:08 2007] [error] [client 192.168.1.9] [Mon Feb 5 18:43:08 2007] view: Couldn't store 8a5d41cdb3ff486c57f87a1c19e42f46 into /tmp/twiki/cgisess_8a5d41cdb3ff486c57f87a1c19e42f46: No such file or directory at /usr/local/apache2/twiki/lib/TWiki/Client.pm line 440.
[Mon Feb 05 18:43:08 2007] [error] [client 192.168.1.9] [Mon Feb 5 18:43:08 2007] view: \t(in cleanup) could not flush: Couldn't store 8a5d41cdb3ff486c57f87a1c19e42f46 into /tmp/twiki/cgisess_8a5d41cdb3ff486c57f87a1c19e42f46: No such file or directory at /usr/local/apache2/twiki/bin/view line 0
When you look at the code before line 440 in Client.pm then it seems that TWiki found that my browser claimed to be authenticated and it then skips creating a new session file. In 440 it runs $this->{_cgisession}->flush(); which obviously is not able to create a missing directory or file.
So the solution to this is to find the right place to check for the existence of /tmp/twiki and create it if it is not there.
But we have to be careful not to do this in a way that hits performance so we should take our time to find the best place and best way. We should do it before CGI::Session does it because then we can additionally control the access control to the new directory so only Apache can write to this directory.
--
KennethLavrsen - 06 Feb 2007
The reason I wanted to add the Checker for
{TempfileDir}
was that whenever my desktop reboots is cleans
/tmp
. As a result /tmp/twiki gets killed on every reboot, and
configure
wasn't telling me about it. Further, my CGI::Session (4.03) File::Temp (0.16) does not create the dir. I have since moved my sessions into a 'sessions' dir under the twiki install, but now I have to run the
tick_twiki.pl
cron job. I didn't used to have to do this (apart from testing) because
/tmp
was cleared on every reboot. Nasty.
I do
not agree with creating the {TempfileDir} directory; I think this is a
very bad idea for the same reasons we don't create any other dirs in TWiki (except in data and pub). The dir should be pre-created and checked in
configure
,
not created on the fly. The issues with admin of this dir should be solved in
configure
and the install docs, not hacked around in the code.
CC
The reason I want to create /tmp/twiki is that they are temporary files.
And if you reboot a webserver who says the session files should be kept?
I wanted to create the /tmp/twiki because it give the admin one less thing to think about. We have until now had the session files in /tmp and that meant they got wiped at boot and noone have had anything bad to say about that so why is it suddenly a problem?
There is a similar discussion on the work dir for plugins. Here we are dealing with real data that must be kept in some cases and there I have a different oppinion. Then I think the directory should be inside the twiki tree and per default be valid in configure. The discussion about that file checker was that is gave a false error until you save in configure the first time and there we are on a path to a much better solution that eliminates that problem. My point is that we need different medicin for different things. And for the temporary files that can be wiped out with no problem I prefer that TWiki creates a sub directory in the tmp directory which then gets the right owner and the right access rights.
But I do not agree that Twiki should auto create any other directories.
--
TWiki:Main.KennethLavrsen
- 06 Feb 2007
It's really a combination of things.
- I want to precreate the dir because it's one less thing for the code to do at runtime. File checks, and especially
-d
checks, are expensive at runtime, as we discovered when generating the webs list.
- If I have to write a checker for the dir above the sessions dir, I might as well write a checker for the sessions dir itself - or even pre-create it in configure
- I prefer not to use different medecine just for the sake of it; precreating dirs is a consistent approach, and I don't see why it should apply here as well. Keeping things hidden from the admin is good in some cases, but it often gets us into trouble.
CC
I created
TWiki:Support.CouldntStoreTmpTwikiCgisess
so that people can find the issue and fix.
--
TWiki:Main.PeterThoeny
- 08 Feb 2007
I am working on a fix for this.
It takes time because the CGI::Session CPAN lib has changed a lot over the time and it is especially the error handling that has changed.
- You cannot trust that flush returns false when failing.
- method errstr returns an error string which is never reset later
- method error() was deprecated
- method set_error() was added
- method new() does not create the directory path on older versions
CGI::Session is a mess and has not been maintained to be backwards compatible. A clear example that it is not always good to reuse CPAN code. It depends on who maintains it. We can also learn from this why people hate when we change our API.
But I will eventually solve this. If all comes to worse then I will have to always check for $TWiki::cfg{TempfileDir}. I will not accept that users cannot have this auto created in the /tmp dir.
--
TWiki:Main.KennethLavrsen
- 25 Feb 2007
Newer versions (> 4.0) of CGI::Session does a -d and mkdir if dir is not there. So we already have the "performance hit" of doing -d.
I simply added the same on condition that CGI::Session is older than 4.0.
I also added same fix for passthru. I thought I already had but I never checked that in.
And while I was at it I found some additional fixes for passthru that I sneaked in with this.
--
TWiki:Main.KennethLavrsen
- 26 Feb 2007
Closed with release of 4.1.2
KJL