Last night I was feeling good about how well the 2.0.12-to-2.0.15 upgrade went on my sandbox system, then this morning I got pinged by a user who couldn't logon there. Now neither can I. Here's what I've done...
- Brought us up from PHP 5.3 to 5.6 a week ago, everything still ran fine.
- Restored a copy of our live database over the sandbox database
- Logged onto the sandbox system. Had to use my current password instead of the old one, which confirmed that the restore had worked.
- Upgraded the sandbox from 2.0.12 to 2.0.13, to 2.0.14, to 2.0.15
- Successful install for 2.0.13
- At the 2.0.14 upload, the test review indicated failure for three Themes: Sunset, Graystyle and Splat
- I went to the Themes Settings page and deleted those three Themes
- Went back to the Patch Install page and made sure I'd UNchecked to install for those themes but TO install for the others
- Got successful installs for 2.0.14 and 2.0.15
- Logged off and logged back on again to confirm the Admin page said 2.0.15, look at old msgs, write a new one, etc. Everything looked fine so I logged off.
- Got pinged this morning, like I said, and sure enough I can't logon there, either.
- Tried clearing browser cache, no joy.
- Ran repair_settings.php with all recommendations
- changed the cookie name from SMFCookie12 to SMFCookie446
- turned off Queryless URLs
- set SMF Default Theme as global default
- Cleared the browser cache again, still no joy.
- Same result when I try logging in there from Safari on my iPad
I noticed that the three Themes I'd deleted still reside in the file system.
I've seen several posts here relating to fixing up custom Themes, but all the ones we have are vanilla downloads from the SMF site.
Not being able to logon as Admin means I can't check or fix anything from inside SMF, and I'm basically PHP-illiterate. What can I do to address this from what cPanel utilities will allow me to do? Would deleting the "not there" subdirectories from the Themes directory clear the problem?
Thanks.
does clearing the cookies in the browser at least help for the initial login ?
Just cleared cookies in Edge, no change. I don't see either the old nor the new sandbox cookie in FireFox's cookie stack, and my iPad had never seen that site before. So that doesn't seem to be where the problem is.
So, you can log in to the forum generally but not into the admin area?
Sorry, no, can't log in anywhere. No can anyone else.
Link to site?
http://agm2m.org/sandbox/public_html/ (http://agm2m.org/sandbox/public_html/).
Hmm, the obvious symptom is not showing up. What if you turned off JavaScript before trying to log in?
Can't find a way to turn it off in Edge. In FireFox I set NoScript to mark agm2m.org as non-trusted -- no change in behavior.
Explicitly turned off JavaScript in Chrome -- still the same.
Removing a theme in theme settings does not delete the files, they're ignored and not causing your problem. You were able to login after upgrade, so upgrade was successful. Looks like a clean install, have you tried uploading 2.0.15 upgrade package to replace all files with clean package?
can we see the contents of your htaccess (alongside main SMF if it isn't the root directory) posted here?
Quote from: drewactual on January 10, 2018, 11:35:36 PM
can we see the contents of your htaccess (alongside main SMF if it isn't the root directory) posted here?
I don't see "htaccess" in cPanel's File Manager display, probably because as a dot-file it's "hidden" and I don't know how to show those. Sorry.
Quote from: Sir Osis of Liver on January 10, 2018, 09:40:51 PM
Removing a theme in theme settings does not delete the files, they're ignored and not causing your problem. You were able to login after upgrade, so upgrade was successful. Looks like a clean install, have you tried uploading 2.0.15 upgrade package to replace all files with clean package?
You're talking the big-file complete replacement package? That would be my next step if nothing less drastic presents itself. Does that lay down on top of what I've got or would I need to create a new directory tree?
What error do you get when you try to logon?
if it were a cookie issue then would disabling cookie support in your browser help ?
or copy cookie data from a functioning environment to your sandbox ?
or if you run auto-approve then you could register a new user and try to login.
it could be something else so yeah, get all the error info that you have.
as you can tell, this is not my area of expertise but i'm really curious about this problem.
The only message we get is this one
ask your host to set the sessions path to file... i wager apache is set up to use memcached and clients to store the sessions. IF memcached is available on whatever build they implemented as a 'stock' build, then it is likely set in php.ini to actually use it.
i use memcached as opposed to files, though practicing through using 'files' seems quicker on a smaller forum (like mine), but the settings have to be absolutely right to use them. the big ones are:
sessions_save_handler: files (IF memcahed is available, the value is memcached instead of files)
sessions_save_path: (link to file on server sessions are saved; IF memcached is available, the value is 10.1.1.1:11211)
session_name: PHPSESSID < you gotta have that set with this value, we're talking sessions for the server, NOT for SMF, and it's teh same if you use memcached too...
even if this isn't your issue, it's a good plan to have your host comb through your php.ini with you and set things to cater best to your function/purpose.
Interesting info to follow up on, but keep in mind that our failing system is the sandbox we use to check out new stuff. The live system, operating out of the same virtual machine, has been and is running just fine <sound of fingers crossing>.
Quote from: MensaMod on January 11, 2018, 10:45:11 AM
Interesting info to follow up on, but keep in mind that our failing system is the sandbox we use to check out new stuff. The live system, operating out of the same virtual machine, has been and is running just fine <sound of fingers crossing>.
then take a peek at your php.ini or <virtualmachine> tags in both sites... make sure they match? make sure they match in every aspect
EXCEPT where they store sessions (if using files).
edited to add: it's a very good idea to have the two instances using different cookie names, too... SMF named cookies,
NOT the phpsessions that
all users set when they approach.
Where do I find them? (Damn, I wish cPanel offered a filename search function.)
your php.ini should be in your http (public facing) folder...
and i wager we're on to something here with your server config... if you don't have a php.ini in that directory, it's falling back to the global php.ini or httpd config, which means if it implicitly set a cookie name or session file location, both forums are trying to use the same names/directories for the same phpsession cookie...
MAKE a file in your root directory of the sandbox named php.ini... in that file type in:
session.auto_start = 1
that by itself may remedy your situation... if not, we may have to go back and enter session parameters for it such as what i offered previously..
Er, what?
First up, don't use session.auto_start. SMF deals with that itself, as it should. If anything this is more likely to be a problem if it is forced on.
Secondly, Apache has nothing to do with sessions whatsoever, that's all PHP and specifically SMF and it certainly isn't configured by default to use memcache, especially as you'd need to know where the memcache server was and what port it ran on. This is why it's off by default.
Are they using the same database or not? I'd make sure there is no reuse of the sessions table.
No, they're two separate databases, m2madmin_ipb and m2madmin_sandbox_ipb, as confirmed by repair_settings.php.
Is there a log somewhere that records more information on a "verification failure?"
This a forum error, SMF will sometimes display an error that isn't what's actually happening, especially if there's a server glitch. Have you tried overwriting the files with upgrade package? That would at least eliminate a script error.
I'm boggling at that, because of not being able to log in and use good ol' Package Manager. I've downloaded the upgrade_2-0-15.zip file and will try it out on Sunday if no-one comes up with something better before then.
This is not going well. I used Win10 to extract everything from
upgrade_2-0-15.zip to a fresh folder, then used cPanel's File Manager facility to upload the entire file structure to a fresh directory at
/public_html/sandbox/public_html, which is where the sandbox SMF is rooted. Double-checked each folder to be sure that the uploaded structure matches what's in the .zip file.
Next issue is how to get
upgrade.php to execute. File Manager doesn't have a Run option, although I can View it just fine. Of course, double-clicking the file in File Manager presents me with options at my PC, not at the server. I've tried invoking the code through FireFox, Edge and Chrome with the following variations
- https://agm2m.org/public_html/sandbox/public_html/smf_2-0-15_upgrade/upgrade.php
- http://agm2m.org/public_html/sandbox/public_html/smf_2-0-15_upgrade/upgrade.php
- https://agm2m.org/sandbox/public_html/smf_2-0-15_upgrade/upgrade.php
- http://agm2m.org/sandbox/public_html/smf_2-0-15_upgrade/upgrade.php
to no avail. The https versions were generally blocked by the browser on security grounds. #2 got me a blank white screen. #4 on FireFox gives me a blank white screen; on Edge and Chrome I get Error 500 (first image). The other two images show the top and bottom of the upgrade.php file.
How should I be doing this?
<edited to add... Just saw this (https://www.simplemachines.org/community/index.php?topic=558299.msg3957340#msg3957340) for resetting the Admin pswd ... Is this worth a try or would I just get myself deeper into a mess?>
You do not extract it to a separate directory. You OVERWRITE your existing smf installation.... and you do not need to run upgrade.pho to go from one 2.0.x version to another. There have been no database changes in 2.0.x
If you uploaded the 2.0.15 upgrade package to a new directory, you need to copy Settings.php and Settings_bak.php from old install to new, then run repair_settings to reset paths to new directory. That should get you running with the existing database.
Ah. Thanks for the clarification. I'll try that in the morning.
I really recommend not doing it the way Sir Osis suggests.
Take a backup of the files and the database
then overwrite the existing files with the upgrade archive/extract
putting it in a different directory and then resetting the URLs, etc just adds one more thing that COULD cause complications.
But it also leaves the production install untouched, which can be a good thing based on some of the awful things I've seen done to forums. Besides, OP has already done a new install in different directory, may as well give it a go.
To clarify -- I'm playing with the sandbox, which is only for pre-prod testing. Basically, the production system is my backup because if the sandbox becomes totally unusable my recovery would be to recreate it by laying down prod system backups over what's in /public_html/sandbox/public_html and the .sandbox mySQL database.
Question -- I've finally figured out what the Attachments directory is for. When I overlaid the sandbox database with a copy of the prod database, I didn't do anything to sync the respective Attachments directories. Or any of the other directories in the sandbox file system. Could that contribute to my problem?
No. That will cause issues with attachments but has nothing at all to do with sessions.
Bad advice deleted...
Still no joy. In public_html/sandbox/public_html/Themes I deleted the subdirectories for Graystyle, Splat and Sunset (the three that had failed the upgrade's test). Then I copied all the files from the following directories of smf_2-0-15_upgrade.zip onto the corresponding subdirectory of /public_html/sandbox/public_html
- avatars
- Smileys
- Sources
- Themes
- plus the top-level files (agreement.txt, index.php, etc) onto /public_html/sandbox/public_html
I didn't copy the attachments, cache or Packages contents, all of which contained only the "protecting your directory" index.php files.
I checked the target directories and in each case there's a slew of files bearing today's date, plus (in many but not all cases) another file with the same name plus a trailing tilde (for instance, both index.php and index.php~ but only agreement.txt). So I'm pretty sure that the copy operations worked.
But when I browse to http://agm2m.org/sandbox/public_html/ (and get a proper-looking logon panel), I still get the "Session verification failure" display (and no more informative error message).
Is there a log somewhere that provides more clues about what's going awry?
Could be a problem with server config confusing forum by having two /public_html directories. If you want to work with test install, why not just set it up in a different directory in main /public_html?
This setup has worked fine for us for several prior upgrade cycles. Going over my notes, I see that the only new wrinkles were
- restoring a cPanel "partial backup" of the live database on top of the old sandbox database (the prior sandbox database was a restore of a phpAdmin Export into a brand new declare -- our Messages table is now over the 50-MB limit for that process)
- the code upgrade from 2.0.12 to 2.0.15
Just a note, but I think cPanel allows you to duplicate a database without having to do the export/import routine yourself.
For a sandbox install that might be easier to do as well. Could be something to consider.
Also, I agree with Sir Osis on the path issue in part, it's probably not a good idea to have public_html/sandbox/public_html if you don't really have to. Makes it easier for you as well to spot wrong paths and urls. You could just run SMF in public_html/sandbox directly, or create another easy to remember folder like public_html/test :)
What is a "partial backup"? What kind of host setup are you using?
What I'm working with is what cPanel exposes -- no command line interface that I'm aware of. There's a "Backups" panel, which offers either a "Full backup"
QuoteA full backup creates an archive of all of your website's files and configuration. You can use this file to move your account to another server or to keep a local copy of your files.
or a selection of "Partial backup" operations
- Download a Home Directory Backup
- Download a mySQL Database Backup, with the option to select a database
- Download Email Forwarders
- Download Email Filters
- Restore a Home Directory Backup
- Restore a mySQL Database Backup, no selection option*
- Restore Email Forwarders
- Restore Email Filters
Documentation is
here (https://documentation.cpanel.net/display/68Docs/Backup+for+cPanel). We're hosted by CyberLynk.
* Their T/S person I spoke to is "pretty sure" that the cPanel Restore operation for a database is drop-and-replace of the source database, no option to lay it down somewhere else. On my request they restored our production database on top of the sandbox one, but they did it outside of cPanel and I don't know the details.
Ok, am familiar with that. If you select the second option, it downloads a sql dump to your computer, and I believe it will only restore it to the original location. You would have to import the dump using phpmyadmin or a third party utility like MySQLDumper. If you're on a shared host, phpmyadmin will probably choke on a 50mb+ dump. The usual route is to have host support import the db, but that apparently didn't work for you. I'm not entirely convinced that your session verification fail is a database problem.
So, is this still an issue?
Sorry, yes it is but other projects have gotten in the way of my following up on y'all's suggestions. I plan to
- remove a level of indirection by re-rooting the sandbox filesystem to our /home directory
- try using that myPHPadmin copy function to refresh the sandbox database
Won't be able to get to that until this weekend. Will report when I have some results.
Alright, let us know when you get to it, and of course if you hit further issues along the way :)