It produces 10 graphs, + subgraphs.

Graph-gallery:

VDISK:

Disk bandwidth and iops (rootgraphs provides enclosures, subgraphs provides disks):

Controller bandwidth and iops:

Controller Cache:

Controller CPU-load:

A sawtooth-graph to indicate uptime statistics for the controllers:

Use Munin? Got a HP P2000 StorageWorks SAN? Why don’t you give it a try?

It was about writing modules for nginx. It contains a lot of source code. I believe it’s an OK primer.

The example code can be found on github.

https://github.com/kvisle/nginx_module_samples

It produces 8 graphs, + subgraphs for some of the backends, where it presents the same graphs, but with server-specific metrics.

Some of the root-graphs:

Do you use HAProxy and Munin? Check it out!

Those people who invented the term “grownup” were weird. There’s no such thing.

A built version for Windows can be downloaded here: http://dl.dropbox.com/u/1287557/bumptest.zip … The source code is included, and it builds fine on Linux. It also works just fine in wine if you don’t want to bother building it. The code is fairly minimal.

A couple of screenshots with light illumination from different sides; (NOTE: This looks better in motion)

The design was fairly simple:

1. Clients connect to a terminal server (being Citrix or RDP, it doesn’t really matter).
2. The Internet connected session can’t access the secure network, but is able to store files on a temporary home directory in the DMZ.
3. The files in the DMZ are picked up and transmitted by email to a special account.
4. On the MS Exchange server, a trigger reacts on incoming emails to this particular account, and then writes the attachment to the user’s home directory.
5. The user can access the downloaded files inside the secure network.

If we say that it’s acceptable for the user to deal with untrusted files downloaded from the Internet, this is a fair design. It does the job. However, this is not what I wanted to present to you. I think it’s more interesting to look at how the file-transfer is performed.

When the user saves his file at his temporary home directory in the DMZ, a scheduled job runs and picks up the file. The same job constructs an email formatted like this:

FROM: filelockaccount@acme.org
TO: filelockaccount@acme.org
SUBJECT: \\fileserver\home$\username\filelock\iloveyou.exe
ATTACHMENT: iloveyou.exe


On the Exchange server, the trigger picks up the email, and writes the attachment to the path defined in the subject. The Exchange server ran this job with administrative privileges.

To see whether this could be exploited, I used an Internet connected computer outside the network – just connected via ordinary ADSL. I made Outlook Express use the ISP’s SMTP-server, and made an email formatted like this:

FROM: filelockaccount@acme.org
TO: filelockaccount@acme.org
SUBJECT: \\somewebserver\c$\OMGLOLZ.txt
ATTACHMENT: OMGLOLZ.txt


A couple of minutes later, I could see OMGLOLZ.txt in the root of C:\ on somewebserver. We also tested whether we had access to potentially execute malicious code… and since the magic process on the Exchange server ran with administrative privileges, we definitely could.

Turns out the secure way of downloading files from the Internet could be used to compromise server security in the entire network.

The hole were patched shortly after, and I got my attaboy.

I drew a guy, he has weird proportions, but I’m happy with him. I didn’t attempt to create Cody from Final Fight, but I was thinking about his colors. I didn’t put a lot of work in it.

(Looking at the ambitious-level of my own goals, it’s easy to understand why I’m usually not happy with my own effort.)

The wall can be broken down into 3 parts, + the floor-edge, since it’s not technically a part of the wall. It always sticks next to the wall. The wainscot, the wallpaper and the crown-molding. I’m not 100% sure that this is what it’s supposed to be – 16 bit graphics often leave some room to interpretation.

With the exception of the corner-area, the wall is built up by these 7 tiles (not 8, because the two tiles for the border are identical). Looking up close, the tiles are fairly simple. The detail here, is the combination of the tiles.

The floor-edge

Closest to the wall, it starts off with two pixels of dark color. This gives us the impression of being in a corner next to the wall.
Most of it is filled with a solid color fitting to the rest of the rooms palette.

The wainscot

Consisting of two tiles – together they could create a simple brick-wall pattern. The reason it looks like wood, is because it’s brownish of color. Fairly simple dithering; Not too much, not too little. The corner-tile is just a few pixels marking the corner itself – without any additional dithering/shading in the area.

The wallpaper

When I look this closely at it, I get the feeling it’s stained. These two tiles alone, proves how much detail a tiny amount of randomness can add to a scene. The corner tile got extra “stains” added around the corner for shadowy effect. This also adds to the illusion of perspective, as this tile is higher up than the wainscot.

The crown-molding

This is the most detailed of the four parts – yet, still fairly simple. If you alternate the two tiles, you get perfect tiling.

So, the walls in Zelda are fairly detailed – yet, also fairly simple. If one break down the wall into individual components, one can see what kind of tricks has gone into making of the wall.

All walls are equally visible. As if we were looking directly downwards.

You're not looking directly down anymore. We're clearly looking at the scene from an angle.

One could have treated the entire game as if it was located outdoors. However, Zelda without dungeons wouldn’t have been Zelda. Adding the top-down view for just the walls, is most importantly done for navigational purposes – you will enter and exit doors on all four edges of the screen. This is not a problem when we’re roaming around outdoors, as the screen will pan entirely when we touch the edges of it. Entrances can be limited to be located pointing south.

To add to the illusion of depth, one technique that you’ll see all over the place on Zelda is this; The tallest part of an object is brighter than its foot. It will also appear larger than its foot. The change in light and size gives us the illusion of distance. The bricks on the entrance next to the floor is only 1×2 large, while the topmost brick is clearly 2×4 large. Making the door wider on the top than its bottom also adds to this illusion. The same concept is applied to three other items attached to the wall. Note; I did flip the door upside-down from what it appears in the room for comparing purposes.

The corner is doing the “large on top”-technique, too – just not entirely as visible as on the other objects. The corner-line has a thicker shadow on top, than on the bottom. It is also fairly dark at the bottom of the entire wall – as it’s got a two pixel thick line close to it.

The plugin creates 22 (!) new graphs. A detail level of this magnitude is for most people too verbose, but if you have a large rig that pushes a lot of traffic – frontend nodes perhaps – you may want to learn more about what goes on.

This is a Multigraph plugin, it requires Munin 1.4, and it’s easy to extend. It does not suggest to be enabled by default, because it’s so verbose.

I just committed it to the project – and it’s available here; Trunk

I expect that it’s included in Munin 2.0, but I don’t know for sure.

The samples below shows one frontend node pushing a lot of traffic – the huge spike is a soccer-match (Norway and Denmark).