I've always considered the reverse proxy capability of Apache httpd as one of the real (hidden) gems of the web server. Of course, httpd has a lot of gems: multiple MPMs; a plethora of content creation and rewriting capabilities; dynamic loadable modules; performance and concurrency easily matching its peers; in-depth Lua, Perl and PHP support; and, of course, the vast number of external, 3rd party modules out there. But, for me, the reverse proxy has always been one of its crowning achievements.
So even though Apache httpd excels at delivering both static and dynamic content, an extremely common use-case is for httpd to be used as a "simple" reverse proxy (aka: "gateway"). In this scenario, httpd acts basically like a switch, accepting requests but handing those requests off to servers on the backend. Those backend servers ("origin servers") are where the content really lives, or is created, but the outside never sees them; never even knows they exists. As far as the Web is concerned, that front end gateway is sole server.
The advantages of this setup are numerous and obvious; The implementation provides for high-availability, load balancing, failover, reliability, etc... but only if the gateway web server, the reverse proxy itself, has that capability. Fortunately, Apache httpd does. It has all that and more.
Because it is such a common use-case, and because this capability to so vital to the design and architecture of enterprise web infrastructure, including Cloud setups, I've focused a lot of adding features and improvements to httpd's reverse proxy. Along with the other committers on the httpd project, not only has load balancing been added (and has been for quite awhile), but there are various load balancing methods included, with the ability to add your own implementation very easily. With the balancer-manager, the devops admin gets not only a view into the current state of the reverse proxy, but can also dynamically change various reverse proxy parameters on-the-fly, with these changes surviving a server restart. The reverse proxy supports not only HTTP, but also FastCGI, Websockets, AJP and others. And just recently, I finished work on something that has been on my TODO list for awhile, and something people have wanted for awhile as well: Dynamic Health Checking.
In the normal situations, before httpd sends a request to the backend origin server, it checks to see if it is still "alive" and able to handle the request. Now this is great but it would be even better if, in parallel, httpd was also checking if those backend servers were alive or not independent of requests being passed to them. In other words, not only static health checks but also dynamic checks as well.
Well, now Apache httpd can do exactly that.
Right now this capability exists just on the trunk branch of the server, but I anticipate it being fast-tracked backported to the 2.4.x branch. There are also some addition features I'd like to add in, such as better interaction with the balancer-manager before it is backported. But before too long, the Apache httpd reverse proxy will have this capability and be even better than it is now, and continuing to be even better than its peers, whether they are Open Core or commericial or truly Open Source.
Try it out! And if you are interested in helping develop Apache httpd, jump in and join the fun. Unlike other web server projects, contributor and commit privs can obtained by anyone, not just specially picked people, like "employees" or stuff.
Occasionally, I've been called a GPL or Copyleft hater. Nothing could be further from the truth. I like and use all FOSS license types, whether permissive (eg: ALv2), weak copyleft (EPL) or strong copyleft (GPL)... Want to know more? Watch my video entry.
As noted in a previous blog post, I've started working on the 2.0 version of Telaen: a simple but powerful PHP-based Webmail system. Quite a bit has been changed, fixed and added under-the-covers, including baselining PHP 5.4, a more robust installation checker, and some significant performance increases.
Now I know, of course, that there are a number of other PHP webmail offerings out there, so some may be questioning the need for yet another. I can think of a few reasons:
- Telaen is designed to have as few dependencies as possible; the goal is that any typical PHP setup will be able to run Telaen.
- No external database is required.
- Extensive support for both IMAP and POP; to be honest, most webmail systems don't support POP at all, or are extremely limited in their support.
- Consistent functionality, no matter which IMAP/POP server is used; most webmail systems are simple "front ends" for IMAP servers, meaning the capability of the webmail system depends on what IMAP server is being used. Telaen puts that capability within the webmail system for a consistent feature set.
- Fast caching
- Designed to serve as both someone's primary Email client, as well as their supplemental client.
- Lots of what you need/want, and none of what you don't: Telaen is as simple as it can be, but no more so.
- A fast and secure upgrade path for all those people still using UebiMaiu
- Open to ALL contributions!
The last point is important: we really want as many people as possible to use, contribute, drive and develop Telaen. It's a great project for someone just starting out as well as for more experienced developers. Or if your passion is documentation, we could definitely use your help! In fact, however you want to be involved, we want to welcome you to the project.
Our goal is to have a beta available sometime within a month's timeframe. Stay tuned!
After a somewhat long sabbatical, I'm energized about rebooting the Telaen Project.
Partly, this is due to jaguNET migrating to using Dovecot for both POP3 and IMAP, and the realization that an upgraded webmail system would be the perfect compliment. Now for sure, Telaen is a great PHP-based webmail system, and, in fact, has served (from what I can tell) as inspiration and source for numerous other webmail systems as well (such as T-Dah Webmail, for example), but I had let it lay fallow for quite awhile and, well, it's showing its age. And to be honest, except for some of the larger, and more complex and dependency-ridden offerings out there, it seems that no real PHP webmail packages are being actively developed.
So, I've gone ahead and create the telean_1.x branch and master on the git repo will be the source of Telaen 2.0 development. In no particular order, I plan the 2.0 version including the following:
- Removal of PHP4 support and baselining PHP5.3 at a minimum.
- Faster indexing by utilizing sqlite3 instead of PHP arrays
- Better and more complete IMAP interaction
- Better SPAM handling, especially related to auto-population of the Telaen internal SPAM folder (right now, if the user creates a real, IMAP SPAM folder, Telaen gets awfully confused)
In all cases, the design goals of keeping Telaen as simple and streamlined as possible, and avoiding as many dependencies as possible, will be kept and honored. In fact, the only dependency "added", that I can foresee at this time, is sqlite3 capability, which is default for PHP5.x anyway. However, I do plan on adding some hooks so that if people want to use MySQL or Postgres, they will be able to.
If interested, check out the Github page, and help develop the code, add features or wish lists, find and patch bugs, etc...
UPDATED: Sept 29, 2014 with current OSX Bash patch
First of all, when this was first found, we were looking for a cool name... It was found.
Anyway, as noted here [https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/] the shellshock vulnerability is pretty nasty. What's interesting is that, in general, the *BSD variants aren't as vulnerable as *NIX platforms, simply because the default shell on BSD is still the Bourne shell (the "real" sh) and not Bash itself (On Linux and OSX, for example, /bin/sh is either a copy or link to /bin/bash).
Even so, BSD systems are not immune by any stretch of the imagination, since one attack vector is via web-servers and CGI, and it's likely that there are numerous CGI scripts that require/use Bash. So no matter what, patch your systems.
Page 1 of 11, totaling 54 entries