Home› General support

Keep getting told to re-run setup because mySQL is a new version

Ipstenu Member
in General support
Except it's not
Zenphoto has detected a change in your installation.

Your database software has changed from MySQL 5.1.66 to MySQL 5.1.66.

The change detected may not be critical but you should run setup at your earliest convenience.

You can see there the math is gone teh silly.

I re-ran the setup, twice, before posting. PHP error log is empty of relevant zenphoto errors (just has one where it says it can't install the .htaccess for me, which yes, I know).

The only thing I see in my debug log is this:
`
{25979:Mon, 04 Feb 2013 01:31:48 GMT} Zenphoto v1.4.4.1[596740f6519a92b55e371274624e4a922ff60676]
NOTICE: Constant DATABASE_SOFTWARE already defined in /home/public_html/gallery/zp-core/functions-db-MySQL.php on line 13
define called from require_once (functions-db-MySQL.php [13])
from require_once (functions-basic.php [151])
from require_once (functions.php [18])
from require_once (admin-functions.php [9])
from index.php [274]
{25979:Mon, 04 Feb 2013 01:31:48 GMT}
NOTICE: Constant DATABASE_MIN_VERSION already defined in /home/public_html/gallery/zp-core/functions-db-MySQL.php on line 14
define called from require_once (functions-db-MySQL.php [14])
from require_once (functions-basic.php [151])
from require_once (functions.php [18])
from require_once (admin-functions.php [9])
from index.php [274]
{25979:Mon, 04 Feb 2013 01:31:48 GMT}
NOTICE: Constant DATABASE_DESIRED_VERSION already defined in /home/public_html/gallery/zp-core/functions-db-MySQL.php on line 15
define called from require_once (functions-db-MySQL.php [15])
from require_once (functions-basic.php [151])
from require_once (functions.php [18])
from require_once (admin-functions.php [9])
from index.php [274]
{25979:Mon, 04 Feb 2013 01:32:19 GMT}
`

Comments

  • sbillard Member
    What does your zenphoto.cfg file have for the `$conf['db_software']`?
  • Ipstenu Member
    Nothing.

    Sorry, I missed this reply for ... no reason other than I suck.
  • sbillard Member
    Install the support release.
  • Ipstenu Member
    My notes say I'm on 1.4.4.1b but admin says: 1.4.4.1 [596740f651]

    Reinstalled the files anyway though, cause it's not like it hurts anything.

    (zp-core/version.php says 1.4.4.1 on my server and a fresh download)
  • sbillard Member
    If you install from the GitHub master branch (the support build) the overview will say 1.4.4.1s. The only release that will show as 1.4.4.1 with no letters is the original 1.4.4.1 release, so I would have to presume your download link is not to the correct place.
  • Ipstenu Member
    Ah, the link is to https://github.com/zenphoto/zenphoto/archive/master.zip

    Tried that and got caught in an endless loop of upgrades and it said I HAD to make my folders 777 (they're set to 755, dunno why that's a problem). Eventually I flushed caches all over the damn place, including APC, and it ran through an upgrade successfully. I'm willing to chalk the cache crap to my server (note to self to turn pagespeed caching OFF for zp-admin) but that it refused to accept 755 as a valid folder permission is annoying. I set 'em right back of course.

    And yes, `$conf['CHMOD'] = 0755;` is set in my .cfg file, which I actually just rebuilt off the sample, so I could be sure I had the latest settings :)

    Bah, you guys switching to Git ruined my old deployment scripts ;) I used to use svn switch, and I just can't get git archive to work the same way as I used to. (Not your fault! I've been meaning to work out new deployment scripts. You and MediaWIki are 2/3rds of what I use!)
  • sbillard Member
    Maybe you still are not on the current master build. If you have set CHMOD in your config file there would be nothing saying you HAD to change the value. And any suggested value would have been 0666 if you started with 0755 in the config file. All the suggested values are file access values, so do not include the "execute" bits and therefore will never have "7" as a digit.

    If you had not got CHMOD set in the config file then you do get a warning message to set the permissions. That message (as well as the notice if there is already a vale set) do explain what the values are all about.
  • Ipstenu Member
    Current Master Build... Sorry, I'm not sure what you mean when you say that.

    I only have one install of ZenPhoto, and I was in the right file (when I changed settings in it for DB stuff, it broke as expected).

    Files were 666, no problem. FOLDERS were 755 on the sevrer, but the upgrader yelled at me saying I had to make the 777. I did that, ran the upgrade, changed 'em back. It wasn't an option or warning, it was an outright ERROR, full stop, you cannot proceed.

    http://cl.ly/image/3o2J0r1e0L3y

    I re-ran that just for you :)

    I am 100% certain I have the right .cfg file (/zp-data/zenphoto.cfg) and I am 100% sure it says `$conf['CHMOD'] = 0755;`
  • sbillard Member
    That means that the 0755 security does not work on your server installation. The error messages are saying that Zenphoto cannot write to those folders.
  • Ipstenu Member
    It's never thrown that error before (been using since '09 ;) ). However odd that is, though, it does explain it.

    DSO PHP is locked so php generated files are owned by 'nobody' - my cache and cache_html folders are owned by nobody:nobody, with 755, and work fine.

    What's new is that it wants the same permissions on albums and zp-data, though. Previously it would check on the log files, and I can undertand why this is better, though frustrating for me ;) I upload all the images via FTP anyway since I'm usually doing 100 at a go, and it's far more practical, so I don't need albums or uploads (or plugins?) to be writable in the long run.

    Well consider this resolved, in so far as it's not you, it's me, and I'll adjust. I haven't see the erroneous upgrade notice since.

    It would be nice if it warned instead of failed, like "Cache is not writable. You will not be able to use caching unless you correct this..." and "albums is not writable, you will not be able to upload albums from zp-admin..." but again :) I'll adjust. it's still way less weird than how I have to upgrade PHP and mod_pagespeed ;)

    ETA: I feel like the spacebar guy! http://xkcd.com/1172/
  • sbillard Member
    I guess if the cache was really writeable then the error was wrong. But if Zenphoto really could not write to the cache then it would be pointless to continue as Zenphoto would crash upon execution.

    We use the PHP function `is_writable($path)` to see if the folder is writeable. I suppose that must be reporting that it is not in your case. I guess we could try to write anyway and see what happens.
  • Ipstenu Member
    I think your is_writable... is working fine, on reflection. The cache_html folder worked (cache didn't because I had it set one more folder deep - cache is NOT writable, but cache/folder/ was, I changed that, it's happier now).

    The only annoyance is that zenphoto wants /albums, /plugins and /zp-data as writable and I ... don't :) Which makes me weird (and the spacebar guy). I'm a little tinfoil hat wearing lady, though, and I know it.
  • sbillard Member
    The data folder needs to be writeable for much the same reasons as the cache file. The other two are possibly exceptions. But, Zenphoto does write to both folders on occasions. The album folder if you create a dynamic album or crop an image and the plugins folder when certain plugins initialize themselves.
  • Ipstenu Member
    Amazingly enough? I never crop images in ZenPhoto and I'm not using any plugins :) That the data folder needs to be writable is interesting. I have the log files writable, and everything works fine.

    Like I said, it's probably just me, and that's totally okay.

    (Original problem of MySQL being upgraded has gone away! Yay!)
  • sbillard Member
    That the data folder needs to be writable is interesting. I have the log files writable, and everything works fine
    There is also a configuration file there. Maybe some others depending. So how did those files get there in the first place? And what if you delete one? How does it get back?
  • Ipstenu Member
    Just to loop back to this: WHY does the Data folder need to be writable?

    Previously I made a data file for the various logs, chmod'd them 777, and let the logs run. Since now ZP creates them parsed on the fly and needs to delete them when you press delete, that methodology no longer works.

    For ModPHP (DSO), the fix is (alas) to make the folder 777. I could switch to FastCGI, but there are reasons :)

    (Sidenote: WordPress lets you do this with a very odd set of defines like FS_CHMOD_DIR and FS_CHMOD_FILE. No idea if that's anything to consider in the long run, as my upgrade process is now

    1) Upgrade files via Git
    2) chmod 777 albums plugins uploads
    3) Visit page, run upgrade
    4) chmod 755 albums plugins uploads

    Not perfect, but it satisfies me :)
  • acrylian Administrator, Developer
    The zp-data folder needs to be writable by the server because there the config file is created and also the logs are stored there. By any means nothing should be 777. 775 or 750 should work but of course as often discussed if the server does not run under the same user as zenphoto (see the user guide) there may be conflicts. How strict works is also server dependent.
  • Ipstenu Member
    It's the installer/upgrader that demands 777. I tried 755, but y'know modPHp is a moron.

    It would be nice if those folders gave warnings and not "You Shall Not Pass!" type failures, since ZP will work, just some things won't. It's a 99% thing ;) it'd be nice if it trusted me on that one.
  • Ipstenu Member
    Update. SOLVED.

    Keeping modPHP/DSO, I installed mpm-itk: http://mpm-itk.sesse.net/

    This lets me run everything as the user, which let me change permissions back down to something sane and sensible.

    Re-ran the installer, since PHP permissions had changed and it 'broke' my files in zp-data (which were owned by nobody) and ... I'll be posting the messy details on http://halfelf.org

    But I now have my cake, and Edith too!
  • acrylian Administrator, Developer
    So I understand correctly that you solve it then? :-) If you post anything that might be helpful to others let us know and we put a link on one of the user guide article where it seems fitting.
  • Ipstenu Member
    Yep, it's been 10 hours and everything is owned by the user, cache is running perfectly, and it's magic. The catch is you need root access to fix DSO/mod_php, but it's pretty rare on shared, so I think only a VPS/dedi would use it ;)
  • acrylian Administrator, Developer
    Since most will use ZP on normal shared hosts they also mostly won't be able to do anything like that. All shared hosts I know do work fine, with the one or other quibble at times ;-)
  • Ipstenu Member
    Irony?

    When this site was originally built (and I'm about to date myself...) all most people used WAS mod_php on shared. We didn't have a lot of sustainable options. Which is why this is not something I'm horribly concerned over. I mean, for most people, even on shared, the solution is "move to a different PHP processor." The only reason I didn't was that it would require a MASSIVE amount of work to rebuild apache with the right add-ons.
Sign In or Register to comment.