Timeline

Notes

G-WAN v4.3.11 accidentally changed the default MIME type of scripts to "text/plain".

Notes

Minor bug fixes.

Notes

Minor bug fixes.

Notes

Workaround for hosts reporting a zero count of CPU Cores (like some Amazon instances) and a bug fix for the machines which have many IP addresses. Server-size CGI environment variables are now re-enabled and RESTful URI parameters are processed correctly, even for mixed modes (like /?argv&lg=en_UK&file=about/company/&user=john).

Notes

Better tuned the asynchronous Lorez Waterwheel to provide more 'air' for heavy works. Logged more information about the local host's disks (total/used/free space levels and File System type).

Notes

Removed the "server started" static string previously stored in the /logs/gwan.log file to indicate the server stage. Other steps (all of which are dynamically generated strings) are still logged: their do not pose any problem.

Notes

This release provides a simplified BASIC authorization example, and more defensive code for diverse platforms as well as bug fixes.

Pointless on prior versions like Ubuntu 10.10/ext3, the Ubuntu 12.04/ext4 workaround is very important as it fixes an issue that made G-WAN return 404 errors for 1/3 of the requests (static and dynamic)... only when the path of the gwan executable had a given 'length modulo x' (hence the problem seen with listeners on port 80, but not seen on port 8080).

Notes

The firewall feature lets you dynamically blacklist all traffic coming from abusers, either on a per IP address basis or from a per CIDR network.

Sure, there are dedicated tools (IDS) that detect and fire IP-based blocking, but there are times when the server and the engineer know better how their apps work than automated tools. Further:

"A chain is only as strong as its weakest link." (Charles A. Lindbergh)

You will have to run a separate ./gwan daemon in root mode to modify the firewall rules (this is a security imposed by Linux). It is recommended to make it listen on 127.0.0.1 ONLY (on the port of your choice). From your running app. server scripts, connect to this ./gwan firewall instance to pass your orders. For an extra security layer, you can use a secret password (or encryption) between the two server instances.

Notes

Updated the stream3.c example and fixed a glitch with long streaming. Also added more defensive code as some hypervisors make pthread_join() fail, creating a recurring G-WAN silent exit, notably visible during the log rotation process.

Notes

The same issue fixed in v4.2.5 for the general case remained for the sendfile() branch. This is now fixed.

Notes

stat() file times are supposed to return nanoseconds when available. Since G-WAN's internal time resolution is the microsecond, G-WAN tested if nanoseconds were non-zero and used them when available. This created problems on those file systems where nanoseconds are reported in micro-seconds. That's why Ubuntu 10.10 ext3 worked fine while Ubuntu 12.04 ext4 sometimes (when copied from an ext3 FS?) reported empty files: dwarfed file times (by a factor 1000x) made G-WAN send misplaced "304 Not Modified" replies and use 1970 log file or directory listing stamps.

Notes

The GCC compiler did not like some parts of the G-WAN v4.24 code. This build reverts to a less sophisticated codebase that works as expected (the failing code works fine with -O0 but fails with -Os), removing the bugs observed in v4.24 (empty files, empty dates) generated by the compiler.

Notes

Some more defensive code for users who use a virtualizer (Xen, VMWare, etc.) configured to confine G-WAN in an environment having (a) many CPU Cores, (b) plenty of scripts, (c) JVM and Mono virtual machines loaded – and less than 1GB RAM.

G-WAN was interrupted at startup with an "out of memory" error (avoiding the less intuitive silent Linux OOM kill-switch).

We now make it clearer what the cause of trouble is by checking this condition before it is met deeper by the running code.

Notes

A minor bug-fix release for the brain-damaged virtualizers who proudly report... zero CPU and one Core in their virtual machine.

By the way, this elucidates the "Floating Point error" mystery as this division by zero was due to the bright mind of those who break an OS what works pretty nicely – without their assistance.

After glibc, virtualizers are the next party-spoilers: that's the only remaining obstacle between G-WAN and the Linux kernel.

Notes

With v3.12, we learned that glibc is better left "as is": its arcane internal structures and complex compatibility versioning rules break with the wrappers we wrote in an attempt to be safer against the major incompatibilities of... glibc with itself.

If you link with an old glibc, newer glibcs can run your apps. But if users haven't the latest glibc, unless you maintain (glibc-compliant!) patches for all past glibc changes then your program will be vulnerable to glibc's security holes, crashes, etc. This is why v3.12 tried to provide alternative calls for some fatal glibc issues.

Having developers use a recent glibc can be done, but things may break at any time on remote servers, either hosted, at customers' Data Centers or even embedded – where online OS updates are not an option. Further, when statically linked, glibc still requires at runtime a copy of the exact shared libraries used during linkage (defeating the purpose of static linking).

To let users (a) run G-WAN on any Linux distribution/version and (b) load libraries to add features to handlers or servlets we have had no choice but to (c) remove glibc from the equation.

We also have had to design two versions of G-WAN, each being linked differently:

• dynamically     (for development, with normal /usr/lib libraries and programming language runtimes)
• statically           (for deployments, where your G-WAN scripts are statically linked to the gwan executable)

The glibc-free dynamically linked G-WAN version works like a charm (smaller and faster). More work is needed to support C++ humongus libraries. As all libraries must use the G-WAN glibc-free runtime, an online service will probably link people's static object code and libraries with the G-WAN runtime (like others, we will also provide our own stable Linux distribution).

The glibc-free statically linked version is even smaller and faster. Some users asked us how to deploy G-WAN applications without prodiving the source code of their scripts to their users – this is possible now. This version also protects applications against accidental (or malicious) tampering of the shared runtime used by all dynamically linked apps (Linux's default).

For both versions of G-WAN, where portability, stability, footprint and performance all matter, that means:

• universal portability on all Linux distributions (probably also on BSD)
• increased security (using different system library will not affect G-WAN)
• better and predictable efficiency (as well as lower memory footprints).

And if you believe that the expected gains of a smaller footprint are marginal then think again:

  gcc -s -Os hello.c -static          883 KiB (glibc)
  gcc -s -Os hello.c -static            5 KiB (g-wan)

The glibc bloat is hidden when you link dynamicaly... but it weights. Especially at startup, on low-end hardware, or under load. This will lead to dramatic improvements on embedded systems (routers, cellphones, etc.) and performance clusters.

That G-WAN evolution will clearly benefit to developers and end-users (no more platform-dependant issues, no more mystery hunts, much lower support costs). The libraries used by G-WAN scripts as well as the scripts will be linked to G-WAN, having one single file: a customized G-WAN executable.

We did not plan to replace the system runtime: this just came out as a dire necessity for our own G-WAN-based applications: how can we market apps which fail to run at the customer's place just because a library was modified by a third-party?