The new FreeBSD Core Team

After persuing a position in the FreeBSD Core Team, we received the results of the election last night, here are the results:

New Core Team
Robert Watson (172)
Peter Wemm (160)
Kris Kennaway (157)
Murray Stokely (134)
George V. Neville-Neil (126)
Brooks Davis (116)
Wilko Bulte (114)
Hiroki Sato (111)
Giorgos Keramidas (91)

Runners Up
Julian Elischer (80)
Marcel Moolenaar (77)
Doug Rabson (75)
Remko Lodder (62)
David E. O’Brien (57)
Alfred Perlstein (48)
Jack F Vogel (18)
Juli Mallett (12)

As one can see, I didn’t make it, but (!) I am proud to see that we have such a strong team for the core-team. Congratulations all current members and thanks Warner and Wes for their efforts in the past time.


Today I did the CCSE exam in Zoetermeer, this is the second exam you can do for checkpoint. After preparing it for around two months (in which time I went on holiday to Tunesia, been on business trip to Canada, had a weekend-holiday with Snow in Texel, searching for and arranging side-paths for a house which we are looking for, so basically study time was ~2 weeks) and spending a weekend and yesterday mainly to learn for the exam, it was time to do it.

I passed with a score of 85% (70% was required); so I didn’t do that bad. I got all kind of enthoustic responses from Snow, and I got a lot of text messages from my current assignment. Thanks folks! It’s appreciated!

Onward to CISSP (the materials seem boring so far) and Juniper (Which I am preparing already as next candidate) (also a dual track, the initial one, and the second level one), and then Cisco (if possible) and if then still possible, the BSDP (second level BSD certification) so that I have broad knowledge in multiple regions of the activities that Snow is offering :-).

[lang_en]The guide to a succesfull migration[/lang_en] [lang_nl]De handleiding voor een succesvolle migratie[/lang_nl]


Today at work I did a very succesfull migration from one machine to another pair of machines. I cannot say the details (ofcourse); but it went very well. All we had to do is pull out the old cables, unshut some network interfaces and plugin 2 detached cables (Additional security measure from us). So what lead to this succesfull migration?

Actually, it’s very simple. We planned the things properly. Ofcourse the company wanted to have it sooner, but hardware materials were not shipped on time, and we needed to do some additional testing before we could deploy this.

Because of that, I had more time then anticipated, so I did a “major” inventory, cleaned up old machines, network cables and stuff like that. That was the first big bullet that you should do. Before migrating anything, cleanup the old environment, so that it’s easier to get an overview.

Next thing I did was do an inventory on the switches that were used to connect the “old” facilities. After getting clear what all was running where and how, it was a simple step to reproduce a couple of networks on the new switches, connect up the old switches and the new ones, and have working switching connectivity. (First time I properly did a stack btw).

So, now we created space (overview by removing old unused stuff), and we did an inventory on the network to learn how that works and what was available and what not.

Next thing we did is bring in all the new goodies. While we put them in the racks, we made sure we had space left to glide cables were needed and things like that. So this is a next item, after cleaning up and knowing what lies in front of you, insert the machines, but keep cabling etc in mind, do not stick machines together, but leave a bit of space, it’s for cooling and cables!

So, after bringing in the goodies and powering them up, we had a couple of switches and some other material hanging around. OK next on this list, decide how we are going to cable the machines on the new switches and how we are going to cope with the cables. It’s important that you know upfront how you are going to do it. I had a basic idea in my head, and was very sure on how to approach the cabling thing (Robert from Snow learned me a couple of things on how cables should flow when binding them together). We placed the cables, and nicely made a couple of bundles (one going down, one returning back up, bundling the binding in the cables so that it had a nice half-round shape instead of being smashed together) and supported them on the side of the rack. Afterwards we put in some more cable gliders, now it’s really neath!

So the machines hang, ofcourse I configured them to be on the management network, and I cabled everything. Lets see whether we can reach them. Jip we could (ofcourse, we knew upfront what we were about to do!).

The next step I cheated myself and already did this with the machines in the test-lab, but in case you didn’t have that luxury, now is the time to easily configure the device and copy over the old settings from the old machine(s) where needed and improving them or doing them better (within the bounds of your project).

One or two days prior to the change, you should familiarize yourself with the goals, try to get someone else involved and look at the steps together. You have them in your head, but that’s not enough. Discuss the points with a collegue and write them down. Make sure you generate a worksheet from it. That way you know exactly what to do during migration and what is left and what not.

We did that today, (the final part) and we might have even broken a record with it. We were very quickly and had good grip on the cases. We didn’t see any problems afterwards so far, so I think the migration had succeeded very well.

One other thing I did throughout the migration is invite different people to help. The current team I am in, has 5 working people. I used them all to help me carry the machines, cables, attach them etc. Everyone now has feelings with the machines. They know which machines we are talking about, they all did something to help making this migration go smoothly. Ofcourse it could have been done without them, but it’s an team effort to make it happen, so use the people from the team to get a platform to build upon. (yes I realise that it’s not always possible to do it like this in the various environments).

Hopefully this helps you to do magic like we did today :-)



Vandaag op het werk heb ik een erg succesvolle migratie gedaan van één machine naar een cluster machine. Ik kan de details uiteraard niet vertellen maar het ging erg soepeltjes. Het enige wat er echt gedaan moest worden is de oude kabels uit de machine halen, wat netwerkpoorten inschakelen en 2 losgekoppelde kabels (Voor extra beveiliging) insteken. Dus, wat heeft geleid tot deze succesvolle migratie?

  • Eigenlijk is dat heel simpel, we hadden alles van te voren goed geplanned. Natuurlijk wilde het bedrijf het eerder hebben, maar de hardware werd domweg niet eerder geleverd, en er moesten wat extra testen worden gedaan voordat we alles konden aansluiten.
  • Hierdoor had ik meer tijd dan verwacht, dus heb ik een grote inventarisatie gedaan, oude machines opgeschoond netwerk kabels opgeruimd etc. Dit is het eerste belangrijke wat je zou moeten doen, voordat je gaat migreren de oude omgeving netjes opschonen.
  • Daarna heb ik een inventarisatie gedaan op de switches die gebruikt werden om de oude faciliteiten aan te sturen. Nadat ik op orde had wat er waar draaide, en hoe, was het een simepele stap om een aantal netwerken te reproduceren op de nieuwe switches, en daarmee de oude en nieuwe switches met elkaar te verbinden zodat er een werkende switchstack gemaakt kon worden (de allereerste keer dat ik een stack gemaakt had overigens).
  • Nu hebben we ruimte gecreeerd (overzicht door het verwijderen van de oude ongebruikte dingen), en hebben we een inventarisatie gedaan op het netwerk om te zien hoe het werkt en wat er beschikbaar is en wat niet.
  • Nu brengen we alle nieuwe speeltjes binnen, terwijl we deze speeltjes ophingen in de racks moesten we ervoor zorg dragen dat er genoeg ruimte was om kabeltjes netjes weg te werken, en meer van dat soort dingen. Dit is dus het volgende item, nadat je hebt opgeruimd en wetende wat er voor je ligt, breng de machine’s naar de eindbestemming maar houd rekening ruimte voor bekabeling, warmte geleiding etc, dit is voor de kabels en de koeling!
  • Dus, nu hebben we de speeltjes naar binnen gebracht, we hebben de machines aangezet, we hebben een aantal switches en wat ander materiaal opgehangen. Het volgende op de lijst; hoe gaan we de kabels met de machines en de nieuwe siwtches doen en hoe gaan we in het algemeen met bekabeling om. Het is belangrijk dat je weet hoe je het wilt gaan aanpakken. Ik had een basis idee in mijn hoofd en ik wist vrij zeker hoe ik het wilde gaan aanpakken (Robert van Snow heeft me een aantal dingen geleerd over hoe kabels moeten lopen wanneer ze samengebonden worden). We hebben de kabels uiteindelijk geplaatst en hebben een paar nette kabelbundels gemaakt (een bundel die omlaag liep en een bundel die weer terug omhoog kwam en het bundelen van de cirkel maakte dat we een net gebundelde kabel hadden ipv wat loshangende kabeltjes) die ondersteund worden door de zijkant van het rack. Nadat we nog een aantal extra kabel geleiders hebben geplaatst ziet het er nu erg stoer uit!
  • Alles hangt nu, maar nu is de vraag uiteraard of we er nog bij kunnen, in het testlab hadden we voorbereid dat we overal bij konden, maar controleer dat ook altijd even!
  • Voor de volgende stap heb ik een beetje vals gespeeld en heb ik de onderdelen reeds uitgevoerd in het test-lab, maar voor het geval je die luxe niet hebt is het nu de tijd om de oude settings van de oude machine(s) over te kopieren en waar nodig om deze te verbeteren, of om ze beter te doen (binnen de kaders van het project!).
  • Één of twee dagen voor de change, moet je je voorbereiden op de uiteindelijke doelen. Probeer iemand anders erbij te betrekken, en kijk samen naar de te nemen stappen. Ze zitten in je hoofd, maar dat is niet genoeg! Discussieer de punten met de collega en beschrijf ze op papier! Zorg ervoor dat het resultaat een duidelijk stappenplan. Zo weet je precies wat er gedaan moet worden tijdens de change, wat er nog gedaan moet worden, en wat niet.

Het laatste gedeelte hebben we vandaag uitgevoerd, en we hebben daar misschien wel een record gebruiken. We hebben het snel uitgevoerd en hadden een hele goede grip op de case, we hebben geen problemen achteraf gezien, dus ik denk dat de migratie goed gelukt is.

Een ander iets wat ik tijdens de migratie heb gedaan, is het uitnodigen van diverse mensen om te helpen. Het huidige team waar ik inzit, bestaat uit 5 man. Ik heb deze mensen “gebruikt” om te helpen dragen van de machines, de bekabeling rond te krijgen etc. Iedereen heeft daardoor enig gevoel bij de machines. Ze weten waar je het over hebt, ze hebben immers allemaal geholpen met het opbouwen van de omgeving waardoor alles heel goed verliep. Het had uiteraard zonder ze gekund, maar dit soort dingen doe je als team, en als team moet je het dan ook uitvoeren! (Ik weet dat dat niet altijd mogelijk is in verschillende omgevingen).

Hopelijk helpt dit je enigzins om dezelfde magie uit te voeren zoals wij vandaag gedaan hebben ;-)


[lang_en]Securing your DNS Server[/lang_en] [lang_nl]Het beveiligen van je DNS Server[/lang_nl]


While most people think that Securing your DNS server is practically impossible, I want to give a few hints and tricks to make sure that it’s possible to mitigate problems from DNS to your local server.

This setup should actually be followed by everyone that cares about his DNS Server!

There are a few options to protect your DNS server as much as possible.

  • Split your DNS servers. The internal networks is most likely to do remote queries, the external network probably only serves your internet zone’s. Why have them in one instance? Split the machines where possible, or create different views, so that the internal people can only recurse and the external people can only lookup the domains you host. (SPLIT-DNS)
  • Add ACL’s and limit recursion; if you cannot do the above, you should try the best as possible to limit the amount of people that can use your DNS server to do remote lookups. Is it really necessary that joe-next-door uses your dns server to visit ? ISP’s are here to service these DNS queries for him :-)

    an Example of an ACL in named:

    acl your-acl-name {; };

    This matches any host in the 10/8 network.

    Limiting recursion through the ACL

    Add the following to the options {}; statement in named.conf:

    recursion yes;
    allow-recursion { your-acl-name; };

    Do note the semicolons and the brackets!

  • Use random query ports. Whilst in the past people had been using static ports for doing remote DNS queries, to make it easily go through firewalls, that’s no longer an option. Recently ISC and CERT announced advisory’s to address static-query-ports. It makes you very vulnerable to be spoofed, and could mean that suddenly points to my so that I can trick your users into submitting their data on my machine, which I can then use to do very nasty things (like having a free holiday to the bahama’s, I like it already!).

    In this case one should point out a DNS server, and tell that it can do queries from port 53 and >1024, I have been using this setup for ages, and I do know that a lot of larger companies also have similiar rules in their external firewalls. This allows the DNS server to pick a lot of random ports to do queries from.

    If you use a recursive DNS (because you are an ISP); then consider using only SSH and BIND on the machine (or whatever product you use). The machine does not need to be firewalled at all then , as long as you disable any unused applications. One could ofcourse filter away the SSH login, but having a stateful filter before a large DNS is just asking for problems (thanks Bjoern and Doug for this information!).

  • Use DNS-SEC where possible. Currently not many TLD’s support this, but if there is the possibility, you can add a security layer by using it. Ofcourse this does not prevent it forever, but it makes it again harder to do. And security is all about making the barrier too high to try (if the barrier is low, one will try, if it requires too much time or money, people will not do it that easily, though there is always someone that is willing to put in the required resources, keep that in mind).
  • Always use the latest available version from your vendor where possible. It’s sometimes a pain in your royal behind’s to update the services you host. But do realise that mostly by running the latest (stable) release from your vendor, you can close many known holes. Yet it leaves you open for things not yet found ofcourse (but isn’t that always the case): do plan these kind of actions and make sure you test such a setup first, or keeping the “old” machine alive till you are confident that everything works. You do not want to explain to some high-ranking boss that you didn’t test, or that you cannot return to the old situation. (Something I learned to do is; install a new machine, and it’s applications. Test whether the basic things that you expect it to do; still work. Unplug (yes do not power off!) the old machine and plugin the new one. If you worked through it for XX days, then you can backup the old machine (make sure you test the backup before really turning off the machine!) and turn it off.
  • Ofcourse managers and people around you will complain that it will require a lot of resources; properly planning things will demand tme and money etc. But you can easily counter that by telling your boss or manager that in case something does go wrong, the damage is most likely higher. Point at your risk-index numbers that you periodically create (right!?) to show what kind of risk is involved.

The above are ofcourse a couple of open-doors, though we (Security People) see enough in the real world to know that the above isn’t followed most of the time. Most bigger companies have the resources etc to properly do this, and some indeed use this to do the new setup, but many many many smaller companies are not using these kind of things at all, because it costs too much money. Please try to openly discuss these things with your company if you hit this. You are better off in the end if you properly discussed this, got a “no” anyway, and then things go wrong.

Hopefully the above helps a bit. I wrote this information stream based upon the latest CERT advisory for BIND, and having a few discussions here and there on the FreeBSD-Security Lists. Thanks Doug Barton, Bjoern A Zeeb to give me some thoughts about this (they might not be aware of this yet).



Terwijl de meeste mensen denken dat het beveiligen van je DNS server nagenoeg onmogelijk is, wil ik toch enkele hints en truckjes geven die het mogelijk maken om zoveel mogelijk problemen te voorkomen voor de DNS server.

Deze instellingen zouden eigenlijk gevolgd moeten worden door iedereen die ook maar een beetje geeft om zijn/haar DNS server!

Er zijn een aantal mogelijkheden om de DNS server zo veilig mogelijk te maken:

  • Split de DNS servers, de interne netwerken doen waarschijnlijk queries naar buiten toe, en het externe netwerk serveert waarschijnlijk alleen internet zone’s. Waarom zouden deze faciliteiten in één instance moeten zitten? Of in dezelfde ‘view’? Verdeel de machines waar mogelijk, of in ieder geval verdeel ze over meerdere views, zodat de interne mensen externe domeinen kunnen bereiken en zodat externe mensen jouw eigen domein kunnen opvragen (SPLIT-DNS).
  • Voeg ACL’s toe en stel in dat recursieve queries niet zomaar mogen voorkomen. Als dat niet mogelijk is moet je zo goed als mogelijk je best doen om zoveel mogelijk mensen uit te sluiten (uiteraard wel toegang geven tot de mensen die het wel nodig hebben). Is het echt noodzakelijk dat jan de buurman jouw dns server gebruikt om op te zoeken? Internet Service Providers leveren de faciliteiten om deze queries alsnog te doen :-)

    Een voorbeeld van een ACL in named:

    acl de-naam-van-de-acl {; };

    Dit verwijst naar alle machines in het netwerk.

    Het limiteren van recursieve queries door de ACL:

    Voeg het volgende toe aan het options {}; statement van named.conf:

    recursion yes;
    allow-recursion { de-naam-van-de-acl; };

    Let op de punt-comma en de accolade’s!

  • Maak gebruik van willekeurige query poorten. Alhoewel men in het verleden statische poorten gebruikte om queries naar externe servers te kunnen doen, zodat het makkelijk door firewalls heen kon gaan, is dat geen optie meer. Recentelijk hebben ISC en CERT
    een beveiligingswaarschuwing eruit gestuurd om statische-query-poorten te addresseren. Dit betekende in het kort dat er heel simpel gespoofed kan worden wat kan betekenen dat ineens verwijst naar zodat ik bijvoorbeeld onwetende mensen belangrijke gegevens afhandig kan maken. Dit is is op dit moment heel simpel te doen. Ik kan daarmee bv een vakantie naar de Bahama’s betalen, niet zo’n slecht idee… toch?

    In dit geval moet de beveiligings policy dusdanig ingesteld staan dat een server queries kan doen vanaf poort 53 en alles hoger dan 1024 (>1024). Deze setup gebruik ik zelf al jaren, en ik weet ook dat een aantal grotere bedrijven deze mogelijkheden ook bieden voor de eigen servers.
    Dit zorgt ervoor dat de DNS server een berg willekeurige poorten kan gebruiken voor externe queries.

    Als er een recursieve DNS Server gehost wordt (omdat je misschien een ISP bent); overweeg dan om alleen SSH en BIND (of welke DNS applicatie er ook gebruikt wordt) te gebruiken op de machine. In dat geval hoeft de machine helemaal niet extra beveiligd te worden met complexe firewall regels, zolang niet gebruikte applicaties maar verwijderd of uitgeschakeld worden. Uiteraard zouden de SSH login mogelijkheden beperkt kunnen worden, maar een stateful filter voor een recursieve dns server is vragen om problemen. (Bedankt Bjoern en Doug voor deze info!).

  • Maak gebruik van DNS-Sec(urity) waar mogelijk. Op dit moment ondersteunen niet veel Top-Level-Domains(TLDs) dit, maar zodra mogelijk kan er een extra beveiligings laag toegepast worden door dit te gebruiken. Uiteraard stelt dit het probleem voorlopig uit, maar het maakt het op dit moment te complex/lastig om foutieve informatie te versturen. Immers, beveiliging is er alleen maar om de barriere zo hoog mogelijk te maken zodat het teveel tijd en geld kost om het bedrijf in kwestie aan te vallen, maar houd altijd in het achterhoofd dat er altijd wel iemand bereid is om deze kosten te betalen.
  • Maak altijd gebruik van de laatst beschikbare software versies van de leverancier. Soms is het een enorme pijn om de diensten die geleverd worden up to date te houden, maar realiseer je dat het draaien van de laatste software de meeste bekende gaten sluit. Uiteraard houd dit je kwestsbaar voor problemen die tot heden nog niet gevonden zijn. Plan echter de acties en zorg ervoor dat de nieuwe opstelling getest kan worden, of door het instand houden van de machine tot je zeker weet dat alles 100% werkt. Je wilt namelijk niet aan de directie moeten uitleggen dat je niet meer terugkunt naar de oude situatie. Iets waarvan ik geleerd heb om een nieuwe machine op te zetten, met alle benodigde applicaties, testen of alles werkt, zoja haal de oude machine van het netwerk (niet uitzetten!) en koppel de nieuwe. Als dit werkt voor een vooraf bepaalde tijd, kan de oude machine gebackupped worden (altijd doen voor je hem uitzet) en kan hij daarna worden uitgeschakeld.
  • Mensen, managers zullen altijd klagen dat dit een enorme berg geld en resources kost, het plannen en dingen kosten nu eenmaal geldt. Maar dit kan je makkelijk kaatsen door de baas en manager te vertellen dat in het geval er iets misgaat, de schade vele malen hoger is dan de kosten die hij nu maakt. Verwijs eventueel naar de index-cijfers die gemaakt zijn (Toch?!) om aan te geven wat de risico’s zijn.

Bovenstaande zijn natuurlijk een aantal open deuren, maar wij (beveiligings mensen) zien nog dagelijks dat de meeste mensen deze aanbevelingen niet volgen. Grotere bedrijven hebben meer mogelijkheden om dit goed te doen, en inderdaad sommige kunnen het zich permiteren om een nieuwe infrastructuur op te bouwen, maar vele kleinere bedrijven doen deze dingen niet omdat het teveel geld kost. Probeer openlijke discussies te houden met het bedrijf waar je zit, als je hier tegen aanloopt. Je bent in een betere positie als dit eenmaal bediscussieerd is en toch een nee hebt gekregen, vooral als het daarna inderdaad misgaat.

Hopelijk helpt bovenstaande enigzins, ik heb bovenstaande informatie gebaseerd op de laatste CERT advisory voor BIND en door een X aantal discussies hier en daar op de FreeBSD-security mailinglijsten. Bedankt aan Doug Barton en Bjoern A. Zeeb voor het geven van enige informatie hierover, ook al zal dat onbewust geweest zijn.



Here I am again, studying. I am sitting in the garden while writing this. I just texted Denise and Luca that learning goes very well today (having a mini-break at the moment), I think the sun and being outside does miracles.

I vacuumcleaned the upperfloor, and entirely cleaned up my room, or at least wrt. dust and stuff like that. I also found some lost cables (in the shed, so dreaded easy to find, I wonder why my dad overlooked them) and I did a whole lot of studying so far.

What am I actually studying? I am actively studying Checkpoint NGX at the moment to make sure that I can pass my CCSE. I have a good understanding of how things practically work, but I also need to know the theoretic style (I’d prefer cisco alike stuff where you need to demonstrate your knowledge) :-). That is going fine so far! I downloaded the smartconsole, which I have access to, so that I can play in demo mode, without needing to have any resources available. I downloaded the documentation bundles, which I have access to as well, so that I can review them as well.

And beyond that, I am sitting in the sun, with a nice glass of cold Hoegaarden whitebeer, studying for my upcoming exams. What more does a techy want? (Well, ofcourse that his girlfriend and their kid are here, but we will sort that out as soon as possible ;-))…

Back to the studyboard!

Volunteer projects – FreeBSD

As people most likely already found out, there is a problem with DNS, and there was already a problem for some extensive time with DNS. There is the possibility to spoof the reply’s returning from a DNS server.

Beyond that, some discussion was raised last night with regard to the responsiveness of the FreeBSD Security Team.

The FreeBSD Security Team is a team of people, that were picked from a volunteer pool out of the FreeBSD Development Community. These volunteers, analyse, patch and create an advisory for incoming security problems. The latter is only done ofcourse after verifying that it is really a security problem.

The moment the FreeBSD Security Team enters an advisory stage, a lot of time investment is required. Which we ofcourse do not mind but it’s something that should be emphasized. For example, patches need to be generated, tested etc. Then after that the FreeBSD-Update builds have to be started and in parallel we also write the advisory.

The advisory is proof-read by multiple people, and the FreeBSD-Update process takes time to deliver the required patches. Because of that we need a little time to do the job right.

We also want to take the time, the moment something comes in, we properly need to evaluate the incoming items, and see whether it would harm the -RELEASE branches or not. Our -RELEASE branches are not something we would like to mess with if it generates a regression. We try to prevent that or emphasize that this will be the case after a required update.

Now, for my official blog entry subject: what does that have to do with a volunteer job?

I hope that it’s easy to guess at this stage. We are all volunteers, that we do the job in our spare time, outside of our regular working hours and social life. We only have a few hours per day in which we can do things. We are geographically spread, so in case of an issue there is a small timeframe we can work together, but that could take a little to get aligned properly. We also have to feed our kids, make sure we generate money to keep on living. And we need to be socially active, not only for FreeBSD, but also for our wives and kids. That all just takes tremendous amounts of time. A part of that is put into the FreeBSD Project by us, the volunteers.

Sometimes, people start crying out loud that they need something NOW because THEY want it NOW. That is a bit unfair; they do not realise that we need to invest our precious spare-time in it, and a
re happy to do so, but that sometimes things can take some time. They start ranting that everyone else has already the fixes in place, that they did it very quick etc. That’s all fine, but most of those vendors have paid people working on these things. No wonder they can quickly respond to such a thing. We do not have that.

Instead of ranting around and demanding OUR -FREE- Time, it could be beneficial to have a couple of people around that are payed to keep an eye out for these things, on a structural basis. That will cost a lot of money, because people are not for free. They also need to be on guard all the time, so it’s a full time job. Costing a lot of money. The moment thigs comes in play, most people hook-off the challenge and remain quiet, only to start ranting again the next time when something (insert your favorite ‘requirement’ here) occurs.

When you counter those people and ask them to paint your entire hous in their freetime, they get angry and tell you that they are not idiots and that you are not entitled to demand this time from that. But it’s exactly the same thing as they demand from us, the volunteers.

The above hopefully makes clear that we try to do our best whenever possible but that it’s not always possible to respond as quickly as possible to anything that comes in. We feel responsible for the tree that we maintain and are willing to do our best for that. But every now and then, people are on holiday, not in, sick, busy with other things, and we have to respect that as long as we do not have a paid staff that can work on these items.

Please, try to understand that this is just common life for a volunteer. It’s OK to disagree on something, but it’s very selfish to demand something from a volunteer if you are not willing to put something in yourself as well.

If you have a suggestion on how we can improve this, with YOUR support included. Give me or the FreeBSD Foundation a poke, I am sure there are ways to get things done, as long as it’s feasible to spend our precious time on, or when paid to do the things people want the payed person to do.

But do remember that in case you are not willing to put something in, your demands are shouts in the space and are likely to be ignored. Just a fact of life.

Thanks for taking the time to read this!

BTW: I’ll be giving a talk about my life as a volunteer in December in Utrecht. The NLUUG/NLGG is doing a Linux/BSD day then, if you are able to visit this. Please do so.

nginx logformat (awstats readable)

I converted my nginx logformat to make sure I could keep using awstats to record my datatraffic etc. Since I needed to parse half a day of logging through Apache and then later through nginx, I needed to make sure the same formats where used. In Apache I configured the common logformat; which results in the following for nginx:

log_format main ‘$remote_addr – $remote_user [$time_local] “$request” ‘
‘$status $body_bytes_sent “$http_referer” ‘
‘”$http_user_agent” “$http_x_forwarded_for”‘;

I also created a couple of include files so that standard stuff is included for every vhost, without it requiring me to denote everything (which is quite a lot if you do it properly).

Mail chapter complete

Rene Ladan just finished the last part of the mail chapter. It’s ready for Reviewal. Rink Springer offered to have a look where possible in the near future, so with a bit of luck we can add the chapter to the official FreeBSD build soon. Thanks Rene for doing such a great job all the time (Where others did much and left, you are still here!).

Ofcourse, I am trying to keep the documentation as up to date as possible, which goes by flows. If you have more time then me and think you can contribute, please contact me, we can really use the help to get a full blown handbook translation, and possibly even translated webpages at some point.

I am doing all the work in perforce, which is publically reachable through:

Cheers to Rene!

Additional Taxes / Extra belastingen

This when you think you had it all, you read the following in the news.

The netherlands is considering on reducing taxes for car-drivers, by letting them pay by driven kilometer instead of a global tax. (Ofcourse we are getting screwed with that, just like with water-meters, you will pay more in a year then before the taxes, another hidden way to empty the pockets o the people); So far a lot of political teams agree with this and that it should be necessary (yes, the same ones that earn to darned much to even care about this); but it has impacts. The provinces will loose income because people are no longer paying the tax, and a part of that was for the province. The provinces are now considering a brand new tax, which should compensate this. ALL IN ALL, you will pay both, and thus EXTRA .. AGAIN!. It’s just too frustrating to even keep listening to it. Someone, STAND UP. please?

— Dutch

Net als je denkt dat je alles gehad hebt, lees je het volgende in het nieuws;

Zoals de meesten wel weten, wil Nederland beginnen met een kilometerheffing voor automobilisten. Hierbij wordt de wegenbelasting dan afgeschaft. (uiteraard een andere manier om je het geld uit je portomonnee te kloppen, want net als met de watermeter zullen we uiteindelijk veel meer gaan betalen, maargoed dat is onzichtbaar he?). Echter, een deel van de wegenbelasting wordt gegeven aan de provincies, deze zien nu de inkomsten verdwijnen, en zijn een nieuwe belasting aan het verzinnen (ja, ze verzinnen ze waar je bijstaat, nederland belastingland!); waardoor je uiteindelijk dubbel zoveel gaat betalen. Zo gaat dat in Nederland. AUB Iemand. STA OP!