gushi: (Default)

A lot of the people I host are not coders. They don't understand things like php, globally scoped variables, deprecation warnings, database authentication plugins, insecure hash types, or the like.

They know only that they have code that worked fine for a decade, and then Some Jerk Ferrit did something that made their site not work.

Most of this is because PHP, as a language, is a Shit Show. The only reason PHP scripts are not still majorly responsible for most of the botnet activity on the internet is because someone decided to make smart light bulbs with globally routable ipv6 addresses.

Coding in php is like trying to sculpt something in clay, except that people keep dumping ingredients in the clay that change its consistency: sand, water, cement, cheerios.

For an admin, php is a security nightmare: you have 300 users, whose code can all alter each others' files. Oh, and on most webservers? Users can't alter the files PHP created. They're owned by the "www" user.

Shit. Show.

So, because vague reasons, the people who make the PHP language decide that a particular function is not workable in the particular coding style that they feel people should be using at that time. So, somewhere in a README file that nobody actually reads, they say "hey, you should stop using this function, it may go away in the next version".

I hosted several hundred websites at one time -- nobody knew about that README file, which, as far as they knew, were on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard.”

So, a long long time ago, I solved two birds with one stone. I installed a program called "suPHP". What suphp brilliantly does, is sacrifice some of the speed normally present in PHP, by running everyone's PHP scripts as them. It does this by decoupling PHP from the webserver, and winding up a tiny little PHP process to spawn your files.

The unexpected side effect here, is that it can run different versions of PHP for different users.

Now, as far as the operating system is concerned, you can only install packages for one version of PHP at a time, and right now, at the time of this writing, that's PHP56, with a bunch of removed functions and deprecation warnings.

I've been building PHP from scratch for years, tho, and I know how to install a tiny little shadow copy of an older version of PHP where the webserver can get at it.

So, if you were going to go look at: this page, you'll see a php info page that talks about php version 5.5. If you look at this default one, you'll see that it in turn is running php 5.6.

In fact, I even have a separate copy of apache running with the mod_php going on, for my webmail, where I can use the speed.

Best part? You can control it.

If you were to look at this htaccess file, you can see how easy it is to signal to the interperter that you want 5.5. (Normally, apache won't serve .htaccess files out to the world, this one is special). Basically three lines of code:

<FilesMatch "\.php$">
  SetHandler application/x-httpd-php55
</FilesMatch>

In a former life, I let people use this to switch between php4 and php5. RIght now the only handlers are php5 and php55. I could maybe add php54 as well.

That said -- if you possibly can, I advise using upgraded code that supports the latest thing. So if you're running something like Wordpress, please do update. If on the other hand, you have an old copy of Gallery, and it's not being hacked or hammered, and it suddenly broke, the above will fix it.

gushi: (tall no good)

TL;DR: If you have a thing that's broken for you, contact me and we'll figure out a fix. If you have a DB-based thing or a PHP-based thing, this is likely.

If you have a thing that's broken for you, contact me and we'll figure out a fix. If you have a DB-based thing or a PHP-based thing, this is likely.

Upgrades last night went well, but a few things are being weird.

BSD Stupidity

  • For some reason, pkg upgrade didn't reinstall proftpd. Easily enough fixed, but if it missed that, it may have missed other things.

  • Mysql didn't get upgraded from 5.5 to 5.6, but all the php stuff was linked against 5.6, so I manually upgraded mysql-server to 5.6 and ran a bunch of upgrade scripts.

  • Stupidly, the FreeBSD installer removed named.conf because BIND is no longer part of the base tree. DUMB. Like, there's no other reason a person would want that file? (Luckily, I had backed it up).

  • Also stupidly, trying to install bind9.11 tries to uninstall zkt. WTaF?

  • Freebsd-update wanting to overwrite my sendmail.cf (not MC, CF) was just plain dumb. Same with my ntp.conf. I think I'm just going to globally call a /usr/local/etc/ntp.conf in rc.conf, and let it stop complaining about any local changes.

  • Something tickles the password file that causes pkg's user-manipulations to fail, somehow getting the DB and the textfile out of sync.

  • People had warned me about my disk devices changing names, but as this is a VM with scsi-based vdisks this didn't affect me.

PHP Stupidity

  • PHP no longer likes mysql's built-in "old style" passwords. If you have a site that's DB-based and you've been hosted by me for like a LONG time, I'll need to do some tweaking on the backend for you.

  • PHP's session dir got weird again. I may need to define a startup script to fix perms on that. (Come to think of it, I should define a crontab to do cleanup on that anyway).

  • As usual, there's a number of deprecated and "removed" PHP functions. I'm vaguely contemplating building static versions of older versions of PHP from scratch to try and resolve these. Because I use suPHP, it lets me determine the PHP interpeter at a per-site or even per-file level. In a past life, this let me run php4 and php5 at the same time.

(Yes, an unstable version of php5.4 sticking around is arguably bad, but if it's a thing I only turned on for a given site that was otherwise broken and that site runs only as that user, I consider this fairly low risk).

Future Work

  • I've accepted that there's always going to be a couple of packages I need to build myself. That said, I should act like a proper port maintainer, and maintain "diff" files for them that are easily applied. I might even reach out to the official package maintainers on some of this stuff and see if they can be included.

  • Because this system started life using ports and pkg-classic, my packages have no idea which packages are "automatic" (i.e. were not explicitly installed, but merely installed as dependencies), so pkg autoremove may not work so well for me. At some point, I'll manually audit the dependency tree.

  • Squirrelmail's cert is marked as insecure because it's SHA1. I've put in for a reissue, but Geotrust is taking their sweet-ass time on it.

  • Now that I can support current state-of-the-art crypto, I'll likely do some cert tweaking for those things that use SSL. (Webmin, proftpd, Squirrelmail).

  • At some point, I really want to do a proof-of-concept that lets you accept weaker SSL settings, but redirect to a framed warning page. Because the default behavior of this (connection failed) just sucks.

gushi: (Default)

Dear PHP.

Please for the love of god stop being such a monlithic pig.

I'm watching ONE INSTANCE of ONE PHP SCRIPT for ONE USER (that's ONE page hit) eat 107 megs of ram right now. To serve ONE http request.

I mean, seriously, apache has been a multithreaded daemon since april, 2002. And because "PHP is Glue", (and yes, that's literally your excuse), you decided that you'll most likely never be thread safe.

Not that I'll ever run you threaded, of course -- since unix can't do privilege separation on threads. Because you foster the ability for people to write such ugly and insecure, godawful code, I can't even use the techniques most ISP's do to "trick" you into running faster, running you as a module in my webserver.

Of course, PHP regardless of how you run, you could define yourself as a slim application, and dynamically load the modules you need on the fly. Do a quick inventory of which modules are present, and then load when needed. If someone does something like phpinfo(), then sure, load all the modules and show all your stuff. Otherwise, unless someone calls mysql_connect, don't load it. Be cognizant of when the mysql lib is there, maybe via a trusted host cache of modules-to-functions -- but there's no reason for 90 percent of the code in you to be in ram 90 percent of the time. But you don't get it, PHP. Instead, support for everything from TrueType to SSL is compiled, statically, into you.

While we're at this dynamic bit, PHP, security could be handled the same goddamned way. I could run you as a module if you'd have thought AT ALL about the problems you'd cause ISPs everywhere. But you didn't.

This too, could probably be done securely, if you knew what you were doing, PHP. Force all file access through a stub program, like suexec does. For files that merely need to be read, simply check permissions, and if you could read them anyway, just do it. For files in a trusted directory (like modules), just load them. For files that need to be read only by the user (like mysql configs), call your stub program to pipe the data in to you. For files that need to be written, actively...do all your writes through the stub, just like suExec or SuPHP. Because god knows we haven't had enough zero-day postnuke (ever wonder why they called it that?) or phpBB security holes.

But being sensible or logical is beyond you, PHP. I can't stand you, PHP. You continue to anger and frustrate me, and drive prime's load skyward whenever someone decides to run a badly-written gallery app to basically run a for-loop for a directory of images.

But if I disable you, I lose users. And they ostensibly give me money.

So you can stay, but you're sleeping on the fucking couch.

May 2017

S M T W T F S
  123456
78910111213
14151617181920
21222324252627
28293031   

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 26th, 2017 02:45 am
Powered by Dreamwidth Studios