phpwiki-talk

Re: [Phpwiki-talk] IMPORTANT More UpLoad hacks

[Sabri L. <sab...@st...>]

Reini Urban wrote:
>Via the Phpwiki 1.3.x UpLoad feature some hackers from russia upload a
>php3 or php4 file,
>install a backdoor at port 8081 and have access to your whole 
>disc and overtake the server.
>
>See http://ccteam.ru/releases/c99shell

I think that the URL is wrong.

>The uploaded file has a php, php3 or php4 extension and looks 
>like a gif to the mime magic.
>So apache usually accepts it.
>
>To fix this issue at first move the lib/plugin/UpLoad.php file 
>out of this directory.
>
>You can fix it by adding those two lines to your list of 
>disallowed extensions:
>
>php3
>php4
>
>Currently only php is disallowed.

Regards,
-- Sabri.

[Phpwiki-talk] IMPORTANT More UpLoad hacks

[Reini U. <ru...@x-...>]

Via the Phpwiki 1.3.x UpLoad feature some hackers from russia upload a
php3 or php4 file,
install a backdoor at port 8081 and have access to your whole disc and
overtake the server.

See http://ccteam.ru/releases/c99shell

The uploaded file has a php, php3 or php4 extension and looks like a
gif to the mime magic.
So apache usually accepts it.

To fix this issue at first move the lib/plugin/UpLoad.php file out of
this directory.

You can fix it by adding those two lines to your list of disallowed extensions:

php3
php4

Currently only php is disallowed.
-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

Re: [Phpwiki-talk] Problem with SemanticRelations not saving/showing up

[Reini U. <ru...@x-...>]

2007/4/8, Walter Rafelsberger <wal...@gm...>:
> I'm testing phpwiki-1.3.13rc1 on a shared host and I'm having trouble
> getting SemanticRelations to work. I use DISABLE_UNITS = true.
>
> When I use
> <?plugin SemanticRelations page=* ?>
> I get a list with
> "Semantic relations for..."
> and
> "Attributes of ..."
> for every page. However, only the attributes for each page get listed,
>  the relations will not show up.
>
> When I try to save a page containing relations or attributes, the page
>  saves, but I get the following notic:
>
> Notice: "Undefined property: Cached_SemanticLink::$_attribute_base"

I fixed that in CVS.

> When I use the _BackendInfoPlugin on the page I can see that the
> attributes get saved but "get_relations('pagename')" doesn't show up.
> However, it's there in the "San Diego"-page which was set up with the
> virgin wiki.
>
> Any ideas?

No. Strange. Maybe try it with enclosing the definition into []

> PS: I'm playing around with PhpWiki's Semantic Web features and came
> up  with a mashup using MIT's SIMILE timeline, if you're interested,
> have a  look here:
> http://www.metaportaldermedienpolemik.net/blog/Blog/2007-04-07/wiki-SIMILE-timeline-mashup

This sounds like a nice idea for a RecentChange enhancement.
I'm just working on switching over to PageList for time-sorted lists,
such as rss, atom, ...
or RecentChanges, so this could make another nice format= directive.

-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

[Phpwiki-talk] Problem with SemanticRelations not saving/showing up

[Walter R. <wal...@gm...>]

Hi,

I'm testing phpwiki-1.3.13rc1 on a shared host and I'm having trouble
getting SemanticRelations to work. I use DISABLE_UNITS = true.

When I use
<?plugin SemanticRelations page=* ?>
I get a list with
"Semantic relations for..."
and
"Attributes of ..."
for every page. However, only the attributes for each page get listed,
 the relations will not show up.

When I try to save a page containing relations or attributes, the page
 saves, but I get the following notic:

Notice: "Undefined property: Cached_SemanticLink::$_attribute_base"

When I use the _BackendInfoPlugin on the page I can see that the
attributes get saved but "get_relations('pagename')" doesn't show up.
However, it's there in the "San Diego"-page which was set up with the
virgin wiki.

Any ideas?

Walter

PS: I'm playing around with PhpWiki's Semantic Web features and came
up  with a mashup using MIT's SIMILE timeline, if you're interested,
have a  look here:
http://www.metaportaldermedienpolemik.net/blog/Blog/2007-04-07/wiki-SIMILE-timeline-mashup

-- 
http://www.rafelsberger.at

[Phpwiki-talk] Important UpLoad security fix! was [Fwd: [phpwiki - Open Discussion] RE: upload security risk]

[Reini U. <ru...@x-...>]

Please all disable the UpLoad plugin or add the attached patch for an
important security fix.
Somebody is actually breaking in some wiki servers with uploading files
like "deface.php.3" which apache interestingly treats as php.

- if (preg_match("/(\." . join("|\.", $this->disallowed_extensions) .
")\$/",
+ if (preg_match("/(\." . join("|\.", $this->disallowed_extensions) .
")(\.|\$)/",

With this fix it goes:

"ERROR uploading 'passdecrypt.php.3':

Files with extension ad[ep], asd, ba[st], chm, cmd, com, cgi, cpl, crt,
dll, eml, exe, hlp, hta, in[fs], isp, jse?, lnk, md[betw], ms[cipt],
nws, ocx, ops, pcd, p[ir]f, php, pl, py, reg, sc[frt], sh[bsm]?, swf,
url, vb[esx]?, vxd, ws[cfh] are not allowed."


See https://sourceforge.net/forum/message.php?msg_id=4249177 and thanks 
to hhallikainen for reporting this after going through the pain for 
having a hacker abusing this.

Re: [Phpwiki-talk] About removing revisions from page history

[Sabri L. <sab...@st...>]

 

>-----Original Message-----
>From: php...@li... 
>[mailto:php...@li...] On Behalf 
>Of Reini Urban
>Sent: Thursday, April 05, 2007 3:17 PM
>To: Discussion on PhpWiki features, bugs, development.
>Subject: Re: [Phpwiki-talk] About removing revisions from page history
>
>Sabri LABBENE schrieb:
>> Hi,
>> 
>> After some tests, I think that changing expire params from 
>config.ini has no
>> effect. New values are not taken into consideration.
>> 
>> If this is true, expiring params are hard coded somewhere in 
>the code and I
>> can't figure out how to tune them so that phpwiki will store 
>all revisions.
>> 
>> I desasctivated the Archive cleanning from 'savePage()' function in
>> 'editpage.php' and Phpwiki continue to remove revisions 
>after each save.
>> 
>> I think that it is not a normal behaviour.
>> 
>> Any help/idea ? 
>> 
>> Cheers,
>> -- Sabri.
>> 
>> Sabri LABBENE (March 26, 2007 3:56 PM) wrote:
>>> Hi all,
>>> I noticed that phpwiki removes some revisions from a page 
>>> history. It removes either major and minor revisions.
>>> I want phpwiki to save all the revisions in the database. In 
>>> config.ini I commented these lines:
>>>
>>> ; Keep up to 8 major edits, but keep them no longer than a month.
>>> ;MAJOR_MAX_AGE = 32
>>> ;MAJOR_KEEP = 8
>>>
>>> ; Keep up to 4 minor edits, but keep them no longer than a week.
>>> ;MINOR_MAX_AGE = 7
>>> ;MINOR_KEEP = 4
>>>
>>> And uncomment these ones :
>>>
>>> ; Let all revisions be stored. Default since 1.3.11 
>>> MAJOR_MIN_KEEP = 2147483647 MINOR_MIN_KEEP = 2147483647
>
>Just to ensure: These should be in a seperate line. Like
>MAJOR_MIN_KEEP = 2147483647
>MINOR_MIN_KEEP = 2147483647

Yes. The layout and line breaks of my email were broken.

>>>
>>> That was not sufficient to make wiki store all revisions. It 
>>> kept the same behaviour and still removes some of the old revisions.
>>>
>

I finally found out how to tune these params.
It is from 'config-default.ini', thing I didn't expect.

Thanks,
-- Sabri.

Re: [Phpwiki-talk] About removing revisions from page history

[Reini U. <ru...@x-...>]

Sabri LABBENE schrieb:
> Hi,
> 
> After some tests, I think that changing expire params from config.ini has no
> effect. New values are not taken into consideration.
> 
> If this is true, expiring params are hard coded somewhere in the code and I
> can't figure out how to tune them so that phpwiki will store all revisions.
> 
> I desasctivated the Archive cleanning from 'savePage()' function in
> 'editpage.php' and Phpwiki continue to remove revisions after each save.
> 
> I think that it is not a normal behaviour.
> 
> Any help/idea ? 
> 
> Cheers,
> -- Sabri.
> 
> Sabri LABBENE (March 26, 2007 3:56 PM) wrote:
>> Hi all,
>> I noticed that phpwiki removes some revisions from a page 
>> history. It removes either major and minor revisions.
>> I want phpwiki to save all the revisions in the database. In 
>> config.ini I commented these lines:
>>
>> ; Keep up to 8 major edits, but keep them no longer than a month.
>> ;MAJOR_MAX_AGE = 32
>> ;MAJOR_KEEP = 8
>>
>> ; Keep up to 4 minor edits, but keep them no longer than a week.
>> ;MINOR_MAX_AGE = 7
>> ;MINOR_KEEP = 4
>>
>> And uncomment these ones :
>>
>> ; Let all revisions be stored. Default since 1.3.11 
>> MAJOR_MIN_KEEP = 2147483647 MINOR_MIN_KEEP = 2147483647

Just to ensure: These should be in a seperate line. Like
MAJOR_MIN_KEEP = 2147483647
MINOR_MIN_KEEP = 2147483647

>>
>> That was not sufficient to make wiki store all revisions. It 
>> kept the same behaviour and still removes some of the old revisions.
>>

Re: [Phpwiki-talk] About removing revisions from page history

[Sabri L. <sab...@st...>]

Hi,

After some tests, I think that changing expire params from config.ini has no
effect. New values are not taken into consideration.

If this is true, expiring params are hard coded somewhere in the code and I
can't figure out how to tune them so that phpwiki will store all revisions.

I desasctivated the Archive cleanning from 'savePage()' function in
'editpage.php' and Phpwiki continue to remove revisions after each save.

I think that it is not a normal behaviour.

Any help/idea ? 

Cheers,
-- Sabri.

Sabri LABBENE (March 26, 2007 3:56 PM) wrote:
>Hi all,
>I noticed that phpwiki removes some revisions from a page 
>history. It removes either major and minor revisions.
>I want phpwiki to save all the revisions in the database. In 
>config.ini I commented these lines:
>
>; Keep up to 8 major edits, but keep them no longer than a month.
>;MAJOR_MAX_AGE = 32
>;MAJOR_KEEP = 8
>
>; Keep up to 4 minor edits, but keep them no longer than a week.
>;MINOR_MAX_AGE = 7
>;MINOR_KEEP = 4
>
>And uncomment these ones :
>
>; Let all revisions be stored. Default since 1.3.11 
>MAJOR_MIN_KEEP = 2147483647 MINOR_MIN_KEEP = 2147483647
>
>That was not sufficient to make wiki store all revisions. It 
>kept the same behaviour and still removes some of the old revisions.
>
>Is there something else I should do ?
>
>Thanks,
>-- Sabri.
> 
>
>
>---------------------------------------------------------------
>----------
>Take Surveys. Earn Cash. Influence the Future of IT Join 
>SourceForge.net's Techsay panel and you'll get the chance to 
>share your opinions on IT & business topics through brief 
>surveys-and earn cash 
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&
>CID=DEVDEV
>_______________________________________________
>Phpwiki-talk mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

[Phpwiki-talk] Page caching problem, supposedly

[Tom E. <ro...@te...>]

Hi again,

I have always had the problem, that maybe 4 out of 5 requests
return ok, while one takes >20 seconds to complete, then
comes back without styles (i.e. plain HTML look).
(no other errors on the page, or in the apache log)

Since I re-did my whole install from SuSE 10.0 to 10.2
recently (new php, new apache, ...) - and I had this on the
old machine and have it on the new machine - this must be a
phpwiki or phpwiki config issue.
This is 1.3.12p3, but I've also had this on 1.3.11rc3 (maybe
also before that, can't remember). db=file.

While fixing the CalendarList, I made the observation
that in such cases, the page does not get execute (i.e. changes
to CalendarList.php not visible). Since I was reloading,
reloading, reloading the start page, it got worse and worse
until I got 5 subsequent failures on reload.

Now, when I added "?debug=1", it worked. Reload failed.
Changing "1" to "2" worked, but reload failed again, and so on.
Basically, by always increasing the debug level, I got no errors.
So this must have to do with page caching, right ?

Adding "nocache=1" or "nocache=purge" only seemed to
help once (each) !?

Setting "WIKIDB_NOCACHE_MARKUP = true" had no effect at all.
Is this setting still supported ?

I'd be happy to test out your debugging ideas, if you have
some.

Any ideas anyone ?

Cheers & Thanks,
Tom.

-- 
teicher.net - Guaranteed to be free of any useable content.

[Phpwiki-talk] CalendarList fixed

[Tom E. <ro...@te...>]

Hello,

I have now fixed the problems with CalendarList that I complained
about some weeks ago.
I am a Java Programmer and did this by "emulating php skills" though
copy/paste and google, so please review what I did. (Looks right
to me, though ;-)

Cheers, Tom.

-- 
teicher.net - Guaranteed to be free of any useable content.

Re: [Phpwiki-talk] upgrading: some problems

[Reini U. <ru...@x-...>]

Frank Van Damme schrieb:
> On 3/15/07, Matt Brown <ma...@ma...> wrote:
>> Hi Frank,
>>
>> I'm the Debian Maintainer for PHPwiki, so I'll see if I can help you out.
>>
>> On 3/15/07, Frank Van Damme < fra...@gm...> wrote:
>>> I have a phpwiki running. It's on version 1.3.4 and when I upgraded my
>>> distribution to Debian Etch lately, phpwiki stopped serving me wiki
>>> pages but opted for error messages instead. They probably have
>>> something to do with php being upgraded, but I'm not too concerned
>>> about *that*.
>> That's not very good. What version of the package were you upgrading from?
>> If you can send me some details about teh upgrade process, versions,
>> database backend, error messages, etc. I'll be happy to look into it and
>> make sure it's not a bug in the package. I have not had any other failed
>> upgrade reports recently.
> 
> Well, maybe I haven't been entirely clear about this, but my previous
> installation was not installed with a package. It was installed by
> extracting the projects zipfile/tarbal into /var/www/wiki and
> configuring a virtual host for it in Apache. The backend has always
> been MySQL. This is a home server I upgraded to Etch, and I just
> decided to install by package from now on. I admit it's probably quit
> a version jump.
> 
>>> That doesn't work for me. I get asked to sign in. I enter the values of
>>> ADMIN_USER and ADMIN_PASSWD in /etc/phpwiki/config.ini respectively.
>>> The result:
>>>
>>> Fatal Error:
>>> lib/WikiDB/backend/PearDB.php:1032: Error:
>>> WikiDB_backend_PearDB_mysql: fatal database error
>>> DB Error: no such table
>>> (SELECT prefs FROM pref WHERE userid='phpwiki' [nativecode=1146 **
>>> Table 'phpwiki.pref' doesn't exist])
>> Is this while trying to load upgrade.php?
>>  Cheers
> 
> This is what I get when loading /?action=upgrade .well, there is a
> sign-in page in between, where I get a similar error at the bottom.
> I'll include that one too:
> 
> lib/WikiDB/backend/PearDB.php:1032: Error:
> WikiDB_backend_PearDB_mysql: fatal database error
>  DB Error: no such table
>  (INSERT INTO accesslog
> (time_stamp,remote_host,remote_user,request_method,request_line,request_uri,request_args,request_time,status,bytes_sent,referer,agent,request_duration)
> VALUES(1174335080,'192.168.0.72','-','GET','GET /?action=upgrade
> HTTP/1.1','/?action=upgrade','action=upgrade','19/Mar/2007:21:11:20
> 0100',200,0,'','Mozilla/5.0 (compatible; Konqueror/3.5) KHTML/3.5.5
> (like Gecko)','8.97388792038') [nativecode=1146 ** Table
> 'phpwiki.accesslog' doesn't exist])
> 
> if I request /lib/upgrade.php the error is pretty similar:
> 
> Fatal Error:
> lib/WikiDB/backend/PearDB.php:1032: Error:
> WikiDB_backend_PearDB_mysql: fatal database error
>  DB Error: no such field
>  (SELECT cached_html FROM page WHERE pagename='lib/upgrade.php'
> [nativecode=1054 ** Unknown column 'cached_html' in 'field list'])
> 
> Fatal PhpWiki Error
> lib/WikiDB/backend/PearDB.php:1032: Error:
> WikiDB_backend_PearDB_mysql: fatal database error
>  DB Error: no such field
>  (SELECT cached_html FROM page WHERE pagename='lib/upgrade.php'
> [nativecode=1054 ** Unknown column 'cached_html' in 'field list'])
> DB Error: no such fieldDB Error: no such field

You have to upgrade your database structure.
Best done by exporting all your pages, running 
schemas/mysql-initialize.sql and importing all your pages again.

[Phpwiki-talk] About removing revisions from page history

[Sabri L. <sab...@st...>]

Hi all,
I noticed that phpwiki removes some revisions from a page history. It =
removes either major and minor revisions.
I want phpwiki to save all the revisions in the database. In config.ini =
I commented these lines:

; Keep up to 8 major edits, but keep them no longer than a month.
;MAJOR_MAX_AGE =3D 32
;MAJOR_KEEP =3D 8

; Keep up to 4 minor edits, but keep them no longer than a week.
;MINOR_MAX_AGE =3D 7
;MINOR_KEEP =3D 4

And uncomment these ones :

; Let all revisions be stored. Default since 1.3.11
MAJOR_MIN_KEEP =3D 2147483647
MINOR_MIN_KEEP =3D 2147483647

That was not sufficient to make wiki store all revisions. It kept the =
same behaviour and still removes some of the old revisions.

Is there something else I should do ?

Thanks,
-- Sabri.
=20

Re: [Phpwiki-talk] Problems with db4 files

[John S. <jst...@gm...>]

Thanks Reini,
That helped.
Cheers

Re: [Phpwiki-talk] Problems with db4 files

[Reini U. <ru...@x-...>]

2007/3/22, John Stevens <jst...@gm...>:
> Hi All,
> I have set up a nightly build using db4 files so I can test out Wysiwiki.  I
> am getting a whole lot of page spam that begins with:
>
> Fatal Error:
>
>
> lib/DbaDatabase.php:54 Error:
> dba_open(phpwikidb/session.db4): failed to open stream: No
> such file or directory
> file: phpwikidb/session.db4

try an absolute path for the DATABSE_DIRECTORY

> mode: c
> handler: db4 This is when opening a page in Wysiwiki and when trying to
> insert a table in wysiwyg mode.  The file is owned and rw by the httpd user,
> and contains data, so I am not so sure this is a permissions problem.  Has
> anyone seen this before?  I may have to make an oracle database for testing
> if thre are issues with DB4 (not allowed to use mysql).
> Cheers
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>
>


-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

[Phpwiki-talk] Problems with db4 files

[John S. <jst...@gm...>]

Hi All,
I have set up a nightly build using db4 files so I can test out Wysiwiki.  I
am getting a whole lot of page spam that begins with:

Fatal Error:

lib/DbaDatabase.php:54 Error: dba_open(phpwikidb/session.db4): failed to
open stream: No such file or directory

   - file: phpwikidb/session.db4
   - mode: c
   - handler: db4

 This is when opening a page in Wysiwiki and when trying to insert a table
in wysiwyg mode.  The file is owned and rw by the httpd user, and contains
data, so I am not so sure this is a permissions problem.  Has anyone seen
this before?  I may have to make an oracle database for testing if thre are
issues with DB4 (not allowed to use mysql).
Cheers

[Phpwiki-talk] Wiki page history shorten !

[Sabri L. <sab...@st...>]

Hi all,

For some pages, Phpwiki has truncated the page history. There are some =
revisions missing. Sometimes, even the first revision is not shown in =
the page history. I'll be pleased if someone have answers for these =
questions:

- Are the revision numbers incremental and consecutive for a given page =
?
- Could a major revision be based on a minor edit ?
- When accessing a page history, is there a possibility to have some =
revisions truncated ?

Thanks in advance,

-- Sabri.

Re: [Phpwiki-talk] upgrading: some problems

[Frank V. D. <fra...@gm...>]

On 3/15/07, Matt Brown <ma...@ma...> wrote:
> Hi Frank,
>
> I'm the Debian Maintainer for PHPwiki, so I'll see if I can help you out.
>
> On 3/15/07, Frank Van Damme < fra...@gm...> wrote:
> > I have a phpwiki running. It's on version 1.3.4 and when I upgraded my
> > distribution to Debian Etch lately, phpwiki stopped serving me wiki
> > pages but opted for error messages instead. They probably have
> > something to do with php being upgraded, but I'm not too concerned
> > about *that*.
>
> That's not very good. What version of the package were you upgrading from?
> If you can send me some details about teh upgrade process, versions,
> database backend, error messages, etc. I'll be happy to look into it and
> make sure it's not a bug in the package. I have not had any other failed
> upgrade reports recently.

Well, maybe I haven't been entirely clear about this, but my previous
installation was not installed with a package. It was installed by
extracting the projects zipfile/tarbal into /var/www/wiki and
configuring a virtual host for it in Apache. The backend has always
been MySQL. This is a home server I upgraded to Etch, and I just
decided to install by package from now on. I admit it's probably quit
a version jump.

> > That doesn't work for me. I get asked to sign in. I enter the values of
> > ADMIN_USER and ADMIN_PASSWD in /etc/phpwiki/config.ini respectively.
> > The result:
> >
> > Fatal Error:
> > lib/WikiDB/backend/PearDB.php:1032: Error:
> > WikiDB_backend_PearDB_mysql: fatal database error
> > DB Error: no such table
> > (SELECT prefs FROM pref WHERE userid='phpwiki' [nativecode=1146 **
> > Table 'phpwiki.pref' doesn't exist])
>
> Is this while trying to load upgrade.php?
>  Cheers

This is what I get when loading /?action=upgrade .well, there is a
sign-in page in between, where I get a similar error at the bottom.
I'll include that one too:

lib/WikiDB/backend/PearDB.php:1032: Error:
WikiDB_backend_PearDB_mysql: fatal database error
 DB Error: no such table
 (INSERT INTO accesslog
(time_stamp,remote_host,remote_user,request_method,request_line,request_uri,request_args,request_time,status,bytes_sent,referer,agent,request_duration)
VALUES(1174335080,'192.168.0.72','-','GET','GET /?action=upgrade
HTTP/1.1','/?action=upgrade','action=upgrade','19/Mar/2007:21:11:20
0100',200,0,'','Mozilla/5.0 (compatible; Konqueror/3.5) KHTML/3.5.5
(like Gecko)','8.97388792038') [nativecode=1146 ** Table
'phpwiki.accesslog' doesn't exist])

if I request /lib/upgrade.php the error is pretty similar:

Fatal Error:
lib/WikiDB/backend/PearDB.php:1032: Error:
WikiDB_backend_PearDB_mysql: fatal database error
 DB Error: no such field
 (SELECT cached_html FROM page WHERE pagename='lib/upgrade.php'
[nativecode=1054 ** Unknown column 'cached_html' in 'field list'])

Fatal PhpWiki Error
lib/WikiDB/backend/PearDB.php:1032: Error:
WikiDB_backend_PearDB_mysql: fatal database error
 DB Error: no such field
 (SELECT cached_html FROM page WHERE pagename='lib/upgrade.php'
[nativecode=1054 ** Unknown column 'cached_html' in 'field list'])
DB Error: no such fieldDB Error: no such field

> --
> Matt Brown
> ma...@ma...
> Mob +64 21 611 544 www.mattb.net.nz

Thanks for wanting to help me out.

-- 
Frank Van Damme

This weekend, I've been mostly wearing geeky T-shirts.

Re: [Phpwiki-talk] lib/FileFinder.php:191 Error: /tmp: file not found

[Reini U. <ru...@x-...>]

2007/3/18, Morten Sickel <ab...@si...>:
> Thanks for the quick reply. :-)
>
> Reini Urban skrev:
> >
> > /tmp is used in:
> > DATABASE_DIRECTORY (mandatory)
>
> DATABASE_DIRECTORY = pages

much better is to use absolute pathnames. in one stage we do chdir
(into the locale)
and I forgot what else does a chdir implicitly.

> > PLUGIN_CACHED_CACHE_DIR (mandatory) and
>
> so you say that I need to adjust
> ;PLUGIN_CACHED_CACHE_DIR = /tmp/cache
>
> out of /tmp even if I am not having database set to file?
>
> To quote from config.ini:
> "; This is only used if database is set to file.
> ; The webserver must have write access to this dir!"

This is wrong. CACHE_DIR is used for editing and some plugins.
I'll fix that.

> Ok, I'll have a look at that and see if it works then
>
>
> > TEMP_DIR (optional)
> TEMP_DIR =tmp
> > ACCESS_LOG (optional)
> ;ACCESS_LOG = /var/tmp/wiki_access_log
> which as far as I understood means that no access log will be created?
>
> I have also set
>
> DEFAULT_DUMP_DIR = tmp/wikidump
> HTML_DUMP_DIR    = tmp/wikidumphtml
>
> even though I have not tried to do any dumps (yet).-
>
> >
> > This is is just the default if you didn't set DATABASE_DIRECTORY
> >
> Ok, that was what it looked like.
>
>
> M.
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>


-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

Re: [Phpwiki-talk] lib/FileFinder.php:191 Error: /tmp: file not found

[Morten S. <ab...@si...>]

Thanks for the quick reply. :-)

Reini Urban skrev:
>
> /tmp is used in:
> DATABASE_DIRECTORY (mandatory)

DATABASE_DIRECTORY = pages

> PLUGIN_CACHED_CACHE_DIR (mandatory) and

so you say that I need to adjust
;PLUGIN_CACHED_CACHE_DIR = /tmp/cache

out of /tmp even if I am not having database set to file?

To quote from config.ini:
"; This is only used if database is set to file.
; The webserver must have write access to this dir!"

Ok, I'll have a look at that and see if it works then


> TEMP_DIR (optional)
TEMP_DIR =tmp
> ACCESS_LOG (optional)
;ACCESS_LOG = /var/tmp/wiki_access_log
which as far as I understood means that no access log will be created?

I have also set

DEFAULT_DUMP_DIR = tmp/wikidump
HTML_DUMP_DIR    = tmp/wikidumphtml

even though I have not tried to do any dumps (yet).-

>
> This is is just the default if you didn't set DATABASE_DIRECTORY
>
Ok, that was what it looked like.


M.

Re: [Phpwiki-talk] lib/FileFinder.php:191 Error: /tmp: file not found

[Reini U. <ru...@x-...>]

2007/3/18, Morten Sickel <ab...@si...>:
> I just have tried to upgrade a phpwiki installation from 1.2.10 to the latest.
> I am trying to set it up at an isp where I have no access whatsoever outside
> my own directory and no possibility to do anything on the set up of the
> server.
>
> I am then only greeted with
>
> Fatal Error:
> lib/FileFinder.php:191 Error: /tmp: file not found
>
> lib/FileFinder.php:191 Error: /tmp: file not found
>
> This happens both when (trying to) using dba and mysql.

/tmp is used in:
DATABASE_DIRECTORY (mandatory)
PLUGIN_CACHED_CACHE_DIR (mandatory) and

TEMP_DIR (optional)
ACCESS_LOG (optional)

> I have been looking into config.ini, and changed all occurences of /tmp there
> to tmp and made a directory tmp under my phpwiki installation that is
> writeable for the server. No help. When grepping for /tmp in the source, I
> find quite a few occurances where that is hard coded, so it seems to me that
> even if I am telling it through config.ini to stay away from /tmp, it cannot
> be avoided (without going deep diving into the code) e.g. in l
> lib/WikiDB/backend/dba.php I find:

This is is just the default if you didn't set DATABASE_DIRECTORY

> class WikiDB_backend_dba
> extends WikiDB_backend_dbaBase
> {
>     function WikiDB_backend_dba ($dbparams) {
>         $directory = '/tmp';
>         $prefix = 'wiki_';
> ...
>
> of cource, it might be that the $directory is set to something else further
> down the road through the extract($dbparams) call, but it is obious that it
> is presently no simple way for an end user  (even one with quite a bit of php
> experience) to tell phpwiki to stay away from /tmp
-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

[Phpwiki-talk] lib/FileFinder.php:191 Error: /tmp: file not found

[Morten S. <ab...@si...>]

I just have tried to upgrade a phpwiki installation from 1.2.10 to the latest. 
I am trying to set it up at an isp where I have no access whatsoever outside 
my own directory and no possibility to do anything on the set up of the 
server.

I am then only greeted with

Fatal Error:
lib/FileFinder.php:191 Error: /tmp: file not found 

lib/FileFinder.php:191 Error: /tmp: file not found 

This happens both when (trying to) using dba and mysql. 

I have been looking into config.ini, and changed all occurences of /tmp there 
to tmp and made a directory tmp under my phpwiki installation that is 
writeable for the server. No help. When grepping for /tmp in the source, I 
find quite a few occurances where that is hard coded, so it seems to me that 
even if I am telling it through config.ini to stay away from /tmp, it cannot 
be avoided (without going deep diving into the code) e.g. in l
lib/WikiDB/backend/dba.php I find:

class WikiDB_backend_dba
extends WikiDB_backend_dbaBase
{
    function WikiDB_backend_dba ($dbparams) {
        $directory = '/tmp';
        $prefix = 'wiki_';
...

of cource, it might be that the $directory is set to something else further 
down the road through the extract($dbparams) call, but it is obious that it 
is presently no simple way for an end user  (even one with quite a bit of php 
experience) to tell phpwiki to stay away from /tmp

Morten

Re: [Phpwiki-talk] A few comments

[Oliver B. <li...@gm...>]

Morten Sickel wrote:

> Hi, I have just started to use phpwiki, and have installed version

just out of curiosity: what were your reasons to select PhpWiki?

I'm in the process to switch from PhpWiki to PmWiki. Maybe I 
shouldn't do so.

> 1.2.10 which as far as I could understand was the current stable a
> couple of weeks ago. I have two wishlist items and two possible bugs.

it's _very_ old and lacks many interesting improvements of 1.3.*

> I have been looking around a bit, but have so far not been able to see
> if any work is been done on these issues.
> 
> Would you recommend using any newer version than 1.2.10?

It depends on what you need. Authentication, ACL, many new plugins?

1.3.13 would be my choice (if I used PhpWiki again) but 
http://phpwiki.org/ states since nearly one year "The current 1.3.x 
phpwiki on sf.net is currently down, due to yet unknown 
circumstances" so there is a risk you get in trouble, too. I'm 
running 1.3.12p3 without larger problems, but I once had a problem 
with PhpWiki 1.3.4 when my ISP updated to PHP 4.4.4 (database 
corrupted, had to restore from plain text backup).

[...]

> WL 2: table prefix. I wanted to run two separate wikis on a domain
> that is run by a ISP I have access to one mysql database there, so to

Any special reason why you want to use MySQL?

Oliver
-- 
Oliver Betz, Muenchen

Re: [Phpwiki-talk] regarding a message sent to phpwiki-talk

[Reini U. <ru...@x-...>]

da...@an... schrieb:
> First off, I'd like to say thanks for all the exceptional work that you have
> done in phpwiki. The design and architecture is elegant, and I have learnt very
> much in the understanding of the system. I greatly appreciate the style and
> flow of the coding.
> 
> I sent a message to the phpwiki talk mailing list a few days ago with a phpwiki
> issue (Subject: Authentication not persisting). THIS email is not intended as
> attempting to get a private answer, or to speed up an answer, or to hassle you
> at all.
> 
> Rather, I would like to know if there is something in my asking, or something in
> my problem that I could have asked more wisely (more information, or anything
> else) or in a better way to receive some help on this issue. Or perhaps
> something in the nature of the problem that makes it non answerable.
> 
> If not, then please take this communique as an expression of gratitude and
> nothing more.

Sorry for not answering that fast as it used to happen here.

1. I was the whole week on a business trip and my UMTS modem didn't work 
in germany and england.

2. Your question is a FAQ. Loosing session information is very common. 
Unusual is that you debugged the code very far. But a solution is still 
pending.
We should really switch to a more light weight session handling with 
simple hashes instead of objects.
But this will not happen until summer.

The most common error is within your php installation.

[Phpwiki-talk] Unknown modifier 'N' error message

[Sabri L. <sab...@st...>]

Hi all,

Sometimes after saving a wiki page I have the following warning:

PHP Warning
Lib/stdlib.php:1511:Warning: Unknown modifier 'N'

Can this be dangerous ?
Any ideas?

Cheers,
Sabri.

Re: [Phpwiki-talk] CalendarList

[Tom E. <ro...@te...>]

Hi folks, no more thought on this anyone ? :-(
I guess the problems were introduced in file rev. 1.9, so
could banjo please get in touch with me ?
Thanks, Tom.

> > Try the latest CalendarList version from CVS or the latest release.
> > This error was fixed recently.
>
> Thanks, but the Calendar List in "Browse CVS" on the SF site is
>   CalendarList.php,v 1.9 2006/05/14 17:40:31 rurban
>   Sun May 14 17:40:31 2006 UTC (9 months, 3 weeks ago) by rurban
> and that is what I have on disk.
> 
> I also replaced Calendar.php (now I have weeknums, cool ;-)
> but that also didn't help with the list problem.
> 
> Any other file I need to replace ?
> 
> If the file is not yet in CVS, could you please mail it to me?
> 
> Thanks, Cheers,
> Tom.
>