PHP/MySQL Temporarily Offline

[Xepher]

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.

[Xepher]

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.

[griever]

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?

[Xepher]

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.

[Sol_Dynamite]

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

[griever]

Xepher, you probably know about this, but I found SQLiteManager (https://sourceforge.net/projects/sqlitemanager/) when poking around Google.

[reinder]

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, for instance.

[Xepher]

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.

[Xepher]

Hmm... been playing with SQLite Manager, looks quite useful actually. Thanks griever!

[Xepher]

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. :-)

[Cammiluna]

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?

[Xepher]

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.

[Cammiluna]

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!

[deltha]

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?

[reinder]

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:)