kenw writes up these year end thoughts, which I think is a good way of ushering in the New Year instead of New Years resolutions that are unlikely to be met.

This year, due to APDIP closing down, I found myself inreasingly in the role of IOSN project manager. Previously I've always played the role of the grunt, doing everything and anything to get the job done. A fellow colleague once mentioned the task as firefighting. Every day, there is an emergency, and day in and day out, we have to deal with it. When you're in this situation, you don't get the bigger view, and I was often criticised for not being able to prioritise tasks. How the hell do I prioritise when there are fires burning everywhere?

Being on the other side, and seeing the complete picture made me understand all the issues better. If there is any notable personal change in the past year is ability to learn and apply time management skills. It's not an overnight process, and I'm happy with my personal progress so far. Some more points I've learnt, while on the management side:

• Reports matter. Technical reports, summaries etc. Somebody needs to to see what you've done. And they need to see what's been done for a whole lot of projects. Manage time to get them done, or automate them somehow. (tip use wiki's)
• Communications matter. You have to learn to manage your emails and other communications. Sometimes even a short email, SMS will do - "I'm aware of this, but busy with X, will get to it tomorrow.". This helps people above you, also manage their projects. Ok X will be held up for a day, therefore we're not going to get Y and Z until next week, which means they need to inform probably a lot more people than you who are also stressed out about the project. Heck it's important to do this to your peers and personal life too. Think about coming back late, and not informing your significant other beforehand. For all they know, you could be in hospital with an emergency. It's also very stressful when nobody responds from a project for weeks on end. (tip, organise prioritise communications as tasks)
• Follow up on it. I now have payments due from people that are almost half a year late now. I also have people who have been to Europe on exchange grants, who have not submitted anything back. Can you imagine, paying a shop USD50 and not getting anything? You would would feel ripped off right? Well a lot of people seem to think it's ok to take USD2K meant for the FOSS community and share nothing back. Now imagine if you were in charge of USD300K or more, what would you expect in return when giving away that much money? (tip be aware of how much people have invested in you)
• Quality matters. We're not in primary school, where you get bonus points for "trying". Others will be evaluating you with what you give to them, whether it's training, reports, code or other services. (tip polish and presentation matters, it's suprising how easy it is to see the extra effort)
• Even though different things have different priorities, treat everyone equally. If a student is organising an event and has invited you, if you're too busy, still contact them in due time to let them know. The event may have lower priority, but everyone deserves courtesy of a response. If possible try to make it. I'm happy that most in FOSS community are like this. (tip be most excellent to each other)

Looking at myself from the other side, it was not very flattering. I have to thank pusakat for pointing me to Time Management for Sysadmins. This book helped me a lot. As stated before, it's a continous process and I hope to keep improving.

For those that are just starting out, keep this alternative view in mind. My experience has shown, that even if you make a small effort towards addressing some of these issues, you will stand out professionally.

Happy New Year

I often experience with people new to Unix or even people who have been using it for a while, that they tend to brush off vi/emacs editors quickly and then use simpler editors like pico, nano, gedit and the like.

They then never see why a lot of old time Unix system administrators and developers use these tools. vi for example was designed to edit files over a very slow connection (300bps). It's still very useful now, as lag still exists. It's very painful for me to see young developers use the mouse and scroll up, scroll down, when without lifting your hands from the keyboard you can jump to different functions, mark locations and jump back.

If you need to comment out some lines over a laggy ssh connection you can simple type :4,12s/^/#/ instead of type # and using cursor keys over the next 8 lines.

Speaking of comments, here's a common scenario. Sometimes configuration files are huge, because they're well commented with examples. You want to edit it, but sometimes you just want to see your modifications and only comments for the section you're looking at and not scroll through everything. You can hide the # comments with vim's folding feature.

So let's define a function to do this in our ~/.vimrc:

function! FoldShellComments()
    let &foldexpr = 'getline(v:lnum)[0]=="#"'
    g/.*/ if foldlevel(line(".")) > 0 | s/$/ !!!/ | endif
    set foldmethod=expr
endfunction

We then want to call this up easily so we define a user command:

command! -nargs=0 FoldShellComments :call FoldShellComments()

With this whenever we want to fold commented lines, we simple type :FoldShellComments This will tab complete by the way, you just need to type :Fo<tab>

That huge squid.conf file now looks like this:

This afternoon, I finished replacing Apache httpd with Cherokee on Inigo's main server. Now Squid is handling access to all http services first, with Pound handling the management of the backend servers.

There really wasn't much need for Apache httpd, as we don't use most of it's features and without tuning, it takes up a lot of memory just to do rewrites, http proxy for the backends and logging.

Squid uses much less memory, and is very fast. Kagesenshi is working on tighter integration with Cachefu for the Plone sites. Even without that, you will find that sites like http://foss.org.my are now snappy (1.02 seconds total according to firebug). It's improved the speed of http://mirror.inigo-tech.com also which is a slow external USB drive.

The performance bottleneck now is actually memory. While FreeBSD's virtual memory does an awesome job (we're using 1201MB of swap at time of writing), we are now running 4 separate virtual servers, each running it's own self contained services. Not much more we can optimize now. Long idle processes of course, take several seconds to swap back in. So adding another 1GB of memory (total 2GB) will give quite a bit of breathing space and get rid of that lag.

For those that are curious, all this including http://www.apdip.net which used to sit it's own server is running on RM2.5K worth of hardware.

In my last post I forgot about session handling in Pound. You'll need this, so that it can track sessions between multiple backends.

Basic http session add it to your Service section:

Session
           type BASIC
           TTL 300
End

For Zope the session type is cookie and you add the following to your service section:

Session
     Type    COOKIE
     ID      "__ac"
     TTL     300
End

Keeping things simple is important. Keeping things simple however does not necessarily mean things are dumbed down. There is a Unix mantra, which is to do one thing and to do it well. For example take bzip2, does it's job well which is to compress things, it doesn't do anything else. Yes it has a lot of options, but they're related to compressing data.

Sometimes when programs do too many things, they end up being bloated and complicated to set up. So when archiving http://www.apdip.net to a virtual server, it was good opportunity to simplify things, reduce resource usage, but not reduce functionality or performance.

So I've reduced the backend setup to a chain of:

squid -> pound -> zope
               -> cherokee 

• Squid here does what it does best, which is to cache requests
• Pound to load balance between application servers and httpd server
• Cherokee a lightweight httpd server

Except for Squid, the others do their job really well with simple small configuration files. With squid, by keeping it's role to strictly as a caching server, the configuration is also simplified and less prone to errors.

Proper articles later, but hopefully some tips here will help you on your way.

http_port 80 accel vhost

cache_peer 127.0.0.1 parent 81 0 originserver default

acl apdip dstdomain www.apdip.net
http_access allow apdip
acl stats dstdomain stats.apdip.net
http_access allow stats

access_log /var/log/httpd/www.apdip.net/access.log combined apdip
access_log /var/log/httpd/stats.apdip.net/access.log combined stats

User  "www"
Group "www"

Client 300

ListenHTTP
    Address 127.0.0.1
    Port 81
End

Service

    HeadRequire "Host:.*stats.apdip.net.*"

    Backend
        TimeOut 120
        Address 127.0.0.1
        Port 8081
    End
End

Service
    Backend
        TimeOut 120
        Address 127.0.0.1
        Port 8080
    End
End

Cherokee

Love it.. small and simple configuration files. vhosts, cgi etc. snap to set up. The configs are even set up debian style (sites-enabled), brilliant. It's also uses much less memory than Apache and since we don't use any of the modules, php support etc, it makes much more sense. I got introduced to this by Alvaro some time back, since he wrote it, I trust it's as good as he says it is. :)

I won't paste the config files here, you can check them out, but all I can say is that it was simple, just go do the documention on the website to see examples for common uses.