Better solution: make both wiki.d and wikilib.d world writable. Upgrade then processed correctly. I needed to make a link on Site.Site point to the new page on Site.Admin. Otherwise the upgrade looks good.
I was able to set the permissions on wiki.d to 775 and wikilib.d to 755, so the site is no longer so wide open. It was only for the upgrade that I had to set each of them to 777. Now I can start looking at some recipes. -- Rich On Sat, Jun 11, 2011 at 11:13 PM, Richard Talley <rich.tal...@gmail.com>wrote: > OK. First a note on permissions. > > I had read the PmWiki page on permissions. > http://www.pmwiki.org/wiki/PmWiki/FilePermissions > > "On a Unix host the webserver typically runs with a userid and groupid that > is different from the account holder." > > So the permission are usually set: > directories except pub/ and uploads/ 755 > files 644 > pub/ and /uploads 777 > > But in our case, the user account I use to administer the site has been > configured to be in the same group that the Apache server is in. > > So I should be able to use: > directories except pub/ and uploads/ 750 > files 640 > pub/ and /uploads 770 > > And in fact that works, on the production site that's running PmWiki > 2.1.27. > > So, I tried a different tack. I copied the working site to the test site, > but set the permissions back to the usual case (755/644/777) and confirmed > that all uses of $FullName in Site.PageActions are changed to *$FullName. > Site works, of course. > > I apply the upgrade. Now I see something I should have seen before, but > didn't. I get an upgrade notice about relocating Site.ApprovedUrls -> > SiteAdmin.ApprovedUrls. When I click on the 'Relocate pages listed above' > button, I get caught in a loop: > > "PmWiki can't process your request > > Cannot write page to SiteAdmin.ApprovedUrls > (wiki.d/SiteAdmin.ApprovedUrls)...changes not saved" > > Which has a link back to the test site, which offers to 'Relocate pages > listed above'. > > So I manually copied Site.ApprovedUrls from the production site to the test > site as SiteAdmini.ApprovedUrls. > > Now PmWiki complains: > > "PmWiki can't process your request > > Cannot acquire lockfile" > > So I deleted the .flock file in directory wiki.d on the test site. > > No change. I continue to be unable to access the site, because PmWiki > complains it cannot acquire lockfile. > > I'm stuck. I have a production site running 2.1.27 which works fine, but I > have a test site which has a copy of the production site which as been > upgraded to 2.2.26. I can't access this site. > > Solution: leave production site running 2.1.27 and forget about upgrading. > > -- Rich > > On Sat, Jun 11, 2011 at 2:59 PM, Richard Talley <rich.tal...@gmail.com>wrote: > >> Hi All, >> >> I recently took over administration of a site using PmWiki 2.1.27, so it's >> long overdue for an upgrade. >> >> I carefully read through the release notes for all the changes from that >> version up to the current version, 2.2.26. >> >> It appears that the major change that would affect this site is >> making $EnableRelativePageVars on by default. >> >> First I copied the entire installation to a test site, changing $ScriptUrl >> and $PubDirUrl appropriately. I double-checked that all file permissions and >> ownerships were identical to the original site. Test site came up and >> functioned correctly. >> >> In looking at the installation, I determined that the only thing that >> would be affected by the change in $EnableRelativePageVars would be >> PageActions, so I edited all the PageActions to use *$FullName instead of >> $FullName. Test site continued to function correctly. >> >> I then applied the upgrade. Now I can't edit any page. I don't get asked >> for the password. >> >> If I go to the Site page, I get asked to give my Site Administration >> password, but I can't edit anything there either. >> >> Any suggestions? >> >> -- Rich >> >> >
_______________________________________________ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users