There's a possible exploit in MySQL. I had to take down the mysql service and rebuild it today. After it was rebuilt though, PHP stopped working since it was using the old version of the MySQL libraries for it's mysql access. I rebuilt PHP against the new version, and everything should work again. Total downtime was about 2 hours, and only PHP and MySQL were affected (email and such continued to run.) Of course, there's always the chance of new bugs with new software, so let me know if you find any.
EDIT: Retract that... mysql is still borked. Working on it.
Hmm... this is why I hate MySQL. Turns out the new version defaulted to UTF8 character sets, but all the old database files are latin1. As such, it totally freaked. I've changed the default encoding back to latin1, and it seems to be working now. Man, I can't wait to drop MySQL with the server rebuild. Have to find a way to get everyone transitioned over to SQLite though. Lemme know if any of you have ideas on that.
I went over to their website to see if I could understand anything...based on their syntax page, it doesn't seem too bad for me, a basic user. But I don't know how much it would affect people who actually use SQL.
One of the things I'm worried about is that I'm not good at command-line types of interfaces. Would there be anything like phpMyAdmin for SQLite?
That is the question. Since sqlite is not a central/server based solution, it's hard to have a central admin interface for it. I believe it's easily doable in principal, but I haven't seen anything like phpMyAdmin out in practice. One of the many things to sort out before the transition.
Well I did encounter one problem (since I do use MySQL for my blog script). In every one of my posts and pages there are
Xepher, you probably know about this, but I found SQLiteManager (https://sourceforge.net/projects/sqlitemanager/) when poking around Google.
Er... xepher? I think I need UTF 8 for the umlauts and norse characters to work. The titles of my chapters have all gone corrupted. See this episode (http://rocr.net/index.php?p=20000911), for instance.
The good news is that it looks like it's still correct on the database side. PHP is failing to handle the characters correctly though. Seems with this recent rebuild, MySQL defaults to UTF8... unless you have "latin1" set as a use flag. Conversely, PHP defaults to latin1, unless you have "unicode" set. I had neither set, as the previous builds didn't use either of those flags. The comic titles come out just fine (Guðrún) if I set my browser to UTF8 though, so I'm pretty sure it's an easy fix. I'm rebuilding PHP with unicode right now. Hopefully that should fix things.
Hmm... been playing with SQLite Manager, looks quite useful actually. Thanks griever!
Okay, figured out the problem. Your page WAS getting sent with iso-8859-1 as the character encoding. That's the default for PHP, and while you had specified in the HTML content-type that it was UTF-8, many browsers ignore that if encoding is also sent as part of the header. You need a function in the PHP code ot set the header's content encoding. The reason this just now came up, is I used to have UTF-8 set as the default, back when I was tweaking the old forums to support Japanese. Then I found a way to do it locally in scripts and forgot I'd changed the system-wide defaults. So after the PHP rebuild, I forgot to set that back. I've set it back to UTF-8 now though, looks like ROCR works again. We'll see if it breaks anyone else's site. :-)
I've been getting the following errors on some of my PHP pages which used to work fine until just recently, usually when I code an Include tag to a file that has another include tag on it.
Warning: copy() [function.copy]: URL file-access is disabled in the server configuration in /home/cammiluna/public_html/rarebox/gallery/index.php on line 50
I was able to fix some of the errors by making several copies of my header and footer tags for the necessary subdirectories, but now my gallery script is affected when I update the content.
Is this an issue with PHP that could be fixed or will it be permanent due to the SQL upgrade?
It's not actually due to SQL, but rather PHP defaults. URL file access is disabled by default... Meaning that if you have php try to open a file, it has to be a local file, not something on another server. This prevents a lot of script-injection attacks, as most of those rely on substituing a url (e.g. http://hacker.com/thehack.php" in a string where it should be grabbing something like "myfiles/safefile.php" Are you using the newest version of gallery? Because the PHP people really suggest leaving URL file access off for security, and I would think gallery wouldn't require it. If they don't have a newer version, there should be a way to turn it on for just that script using some php_ini stuff. Try looking for an upgrade first though.
Ah! I understand!
The include tags I used would have the whole http-yaddayadda url to avoid directory confusion. I can clean that up real easy. Thanks!
It seems that invision board doesn't work anymore (the posting part at least)
It says "#1016 - Can't open file: 'ibf_posts.MYI' (errno: 145)"
anyone have a solution?
Xepher: Thanks again for all the work you put into keeping the site working.
I didn't actually have the meta: content-type header until the problem started; it was a desperate attempt to make the pages work. However, now that it's there, it's gonna stay:)
Reinder: Yeah, it's good to have in a page... for servers that don't actually pass one in the HTTP header anyway. :-)
Deltha... that's not related to the upgrade actually... it's just a good old fashioned table crash. The good news is I repaired it, and it should be working now. Only you can verify that every bit of data is intact, but considering it's the posts table, even if there is a small amount of lost data, you'll probably never notice. (It would most likely show up as an old post now missing some text or being cut short.)
It works now... thanks... fast as always :D
All's fine here. I was planning on learning...whatever I needed to learn about MySQL (I wanted to implement some different counter codes and whatnot...maybe one day work toward a comment system on my artsite after it's up), and I was going to ask about that and PHPMyAdmin too. But...uh... guess I won't have to bother now. I really would have liked to know about this stuff but I'm fine with this new way if it's better. 0_0
I must sound like a total newb... Probably because as far as these things are concerned I am one.
Senshuu... you can do the same thing with SQLite. Actually, it's easier than with MySQL. PHP supports SQLite directly, and there's a lot of good documentation at www.php.net
I've managed to fix everything within my site except the gallery itself which has errors pointing to the two lines below, and there's apparantly no upgrades for it.
copy("{$mainURL}img.php?dir=".rawurlencode($_GET['dir'])."&file=".rawurlencode($file), $fileT); copy("{$mainURL}img.php?dir=".rawurlencode($_GET['dir'])."&w={$image_size}&file=".rawurlencode($file), $fileN);
I did speak to someone familiar with this stuff and he told me that the way to fix this kind of thing was to "enable 'fopen wrappers' in the PHP configuration"
Would there be a security risk in doing that? I could always look for another image archival script, though it took me three months to find this current one which doesnt make use of MySQL or a ton of confusing files to operate.
Right, that's what I was talking about. "Fopen wrappers" is the method that PHP uses to enable what I was calling "URL File Acess" basically, it puts a wrapper around the file open method, allowing it to use URLs, instead of just files. It is a bit of a security risk, but really only at the user level. That is, to people that actually have scripts with such a function (like you!) It's not something I'd say is a system-wide security issue, so... I'll go ahead and reenable it. See if it works now.