ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Main Area and Open Discussion > General Software Discussion

Email Server Frustration -- Looking for Advice

<< < (5/6) > >>

40hz:
When I see cheap stuff, it just scares me.
-Renegade (November 23, 2010, 01:34 PM)
--- End quote ---

Scares me too. That's why I didn't day cheap. I said from a reasonable host. And I named a good one.

Note: I also do it conjunction with a server package. Most will give you at least 100 mailboxes as part of the deal. It's still sub $350 per year for something decent. And at a buck or less per day, it's worth it to me. And this also gives me another webserver to play with! Perfect as a test bed if it's not needed for production.

From my perspective, running a mailserver is no longer a fun or interesting or educational activity. The blush has long since gone off the rose on that for me.

But again, that's just me.  ;D
 :)


Renegade:
From my perspective, running a mailserver is no longer a fun or interesting or educational activity. The blush has long since gone off the rose on that for me.
-40hz (November 23, 2010, 02:08 PM)
--- End quote ---

Amen to that!

But honestly, I'm still pretty much terrified of relying on hosted services.

Things get really, really scary when they want to control your DNS... Sheesh...

I suppose I'm somewhat paranoid.

40hz:
^Not at all. It's a legitimate concern now that the big players are trying to eliminate "open" from the formula. But I think it will still be a few years before that becomes a problem.

 :)


Stoic Joker:
At the moment I'm running the new PHP installation under FastCGI with the php-cgi.exe instead of the ISAPI DLL. On my other server I use the ISAPI. Both are the ZIP file and not the installer. FastCGI is supposed to give far better performance (20x?), so that's why I'm running with that.-Renegade (November 23, 2010, 01:34 PM)
--- End quote ---

20x?!? (Damn) ...I'll have to investigate that one myself. I actually don't recall why I went the ISAPI route originally, but it was several years ago when I first set up an IIS5 (Win2k) web server and I've just been replicating that config ever since.

I must confess though, I prefer to keep C:\PHP as my install location and configure paths instead. It makes for an easier upgrade, and I don't need to "remember" every path and file then. God knows my records are non-existent.
--- End quote ---


There's a few things driving this and not all are completely technical... It has also been awhile (years) since I had to do any research so things may have (finally) changed regarding install behavior (but I'm not holding my breath).

   1. Most of the install tutorials (rather flippantly) advised kicking the permissions wide open for the C:\PHP folder for "testing purposes" ... But never followed up with what they really should be restricted to. The Windows System32 folder is already by design heavily "defended" so things are much less likely to get out of control in there.

   2. With all of the PHP extension files in the C:\PHP folder the fact that they are "disabled" doesn't really guarantee that they can't be used/leveraged against you/the server...It just makes it less likely. If on the other hand the required binary for extension X is nowhere to be found in the systems executable path...then the chances of it being used maliciously are 100% guarantee-ably friggin zero.

   3. Every time you add something to the system Path variable it takes the system that much longer to find out item X doesn't exist. So I've always made a point of keeping the Path down to the barest of minimums. Any time something "requires" adding yet another string to the Path variable ... I immediately start looking for why/a better way (as it's almost never actually required).

   4. The default Web Service Extensions are already stored in C:\Windows\System32\inetserv. So the most logical place to put more of them (at least to me) is in the same place as the rest. Mind you I do (to keep things clean) keep the active PHP extension files in their own sub folder so that what's "live" now checks are a snap.

   5. I really just hate having stuff scattered around on the C: drive. It should be kept as clean as possible so if something odd shows up it can be spotted quickly (Yes this is the non-technical part... ;)).


But I've had no real problems other than uncommenting some extensions like php_whatever.dll breaks PHP. They're so horribly documented that it just makes it a nightmare to figure out. A good number of extensions break. And I'm too busy to look into things further for anything but critical extensions, which all seem to work fine.
--- End quote ---


You'll get no argument from me there. That's why I started the cheat-sheet I posted above 10+ years ago when I first researched how to get it working on my then new Windows 2000 Server. Christ it took weeks to find anything vaguely resembling a straight answer on how the hell to get the thing lite.

I only enable PHP for sites that use it though.
--- End quote ---

Wise man. :)


Anyways, this is way off topic. :) Still enjoyable though. :)
--- End quote ---
Last time I checked it was legal to sidetrack your-own topic, and yes indeed it is.

Any reasons why you like PHP in the Windows folder? It just seems somewhat dirty to me and hard to maintain. I've not really seen any practical upshot for it, so I'd love to hear more.
--- End quote ---
I kinda covered part of this above, but... The key is closely controlling the files (documentation). There are really only two locations and very few files required to get PHP running and the phpext sub folder in inetsrv keep the variable items easily accessible at all times. If a new PHP exploit shows up I only need to know which extension it targets, and at a quick glance in the extensions folder know if it applies to me.

Sure, the php.ini file can be used in a similar fashion, but... It's huge and if all the extensions are in the target folder there is always the possibility that something can get "bump-started" into action against the server.

Renegade:
I actually don't recall why I went the ISAPI route originally
--- End quote ---

I do. Because the CGI extension just didn't work reliably! :D

Seems ok now though. Microsoft is recommending FastCGI and the php-cgi.exe binary. They've got a whole truckload of open source stuff available at the MS site. Have for a while now actually.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version