Hello, 🙂

Last weekend I participated in a workshop organised to mark the 10 years anniversary of the Durgapur Linux user’s group – dgplug. Dgplug which Kushal started to spread the word & awareness about GNU/Linux(Fedora) in his locality, is now spearheading a social change through its flagship Summer Training program.

    see -> http://wiki.dgplug.org/index.php/SummerTraining

The Dgplug summer training, through its unique methodology, addresses one of the most pressing and severe problem faced by the employment sector in India, that is the dearth of skilled employees -> Less than 20 percent engineers are employable... There is no one way to contain this issue. Greater efforts and more programs are required to arrest the demon of ‘un-employability’.

The workshop was organised by Kushal in association with the National Institute of Technology(NIT), Durgapur, India. We reached the steel city of Durgapur on Thursday evening after a bland flight to Kolkata and a fast bus to Durgapur; the ride was beautiful. Durgapur gives an inviting impression of a charming small town.

Friday began with an English breakfast. We reached NIT campus by 09:00AM and were introduced to Prof Animesh Dutta. The topic of discussion was the same, how do we inspire students to learn and acquire new skills. He said the first two years of college, students show growing interest in doing projects and learning things. But as they reach the 5-6’th semester, their focus entirely shifts towards getting a job by 8’th semester. We had to leave it there and proceed for the workshop. Workshop began with an introductory talk by Kushal about the dgplug and the agenda(‘why’ & ‘how’) of the workshop. He introduced each speaker and we took turns to share bits of our experiences from the FOSS world to convey its importance & value in our career. In the second half of the day, many of the Summer Training participants shared their experiences with other students. It was followed by Praveen with an ‘Introduction to Fedora’. He covered the four ‘f’ of Fedora and various ways in which they can contribute to it. After Praveen I covered the basics of networking and firewall in my ‘Introduction to iptables(8)‘ talk. Though it was relatively technical, they seemed interested in knowing how a packet travels from their non routable IP to a facebook.com server and back to them. The day concluded with Kushal explaining the agenda for Saturday and prerequisites for the same. It was followed by open discussions and conversations in and around the auditorium. I helped a few to configure an iptables(8) rule to block access to facebook.com. 😉

Saturday again began with an English breakfast. We walked to NIT and reached little past 9:30AM. Auditorium was already bustling with students. Saturday brought many lessons and observations for me. The day began with an ‘Introduction to Python’ session by Kushal. Students were required to bring laptops and try out hands-on exercises. As they did exercises, we toured the aisles. First thing I realised was, Linux was an alien system to them. They had heard about it, maybe had seen it too, but never used it. Quite a few had installed Linux 2-3 days before the workshop. And majority was some obscure Ubuntu Mint distribution, which did not even have a good Vim editor. As result, they were struggling to edit files in the older ‘Vi’ editor, completely distracted from learning Python. First session should have been an introduction to Linux, primarily to the mighty shell. As the day progressed, Kushal proceeded from Python shell to python data structures, indentation, through conditionals and loops to writing small programs. All the while 100+ students diligently struggling to keep up with the pace. The day concluded with most of them looking overwhelmed yet energised from the exercise. There was time for open discussions and free interaction. Many enquired about how they could become contributors, how they could learn Linux and install Fedora.

Fedora mirror: during this interaction we met with the local NIT LUG coordinators who used to maintain the Fedora mirror there. The reason for not having an updated Fedora mirror was that they did not have dedicated hardware. Each time they set-up the mirror, during their vacations or when they are occupied with exams or after they leave college, invariably someone would shutdown the server or reuse it for something else. As temporary solution, Praveen has made the F20 ISOs available over http in their LAN. As an alumnus, he would follow-up with the students to ensure that the latest ISOs are always available. We are exploring if we could have dedicated hardware hosting Fedora mirror at NIT. That would help with lot of the issues we faced during the workshop. Ex. instead of catering to different obscure flavours of Linux, each student could be given a small(<= 32MB) shell account on a remote machine, wherein they could practice programming exercises. That way they'll automatically use shell commands too.

Sunday started without an English breakfast. Early before sunrise I started back for Kolkata, while others(Praveen, Samikshan, Chandan, Ratnadeep and Sayan) stayed for subsequent sessions about application development and documentation using Python. A pleasant ride to Kolkata was followed by a filling lunch at Kushal’s and by evening I was back at the airport waiting for another bland flight back home. Throughout the journey I kept going back to the first unfinished conversation about how could we inspire students to learn, advance their skills and acquire new ones. In the midst of those thoughts I stumbled up on

     Fedora classrooms -> http://blog.hammad.co/2014/08/google-summer-of-code-final-update.html

Overall a great trip! Many thanks to Red Hat Inc for helping me with the travel budget.

FAD Pune Aug 2014

Hello, 🙂

    -> https://fedoraproject.org/wiki/FAD_Pune_Aug_2014

After long time we hosted a Fedora Activity Day(FAD) at Red Hat office in Pune, India. While we fared well in Fedora activities; much was left wanting for more in terms of organising the day. This post is an attempt to do a retrospective review, so that we could avoid the same mistakes in future. As for the test day activities that we did, they are logged

    here -> https://lists.fedoraproject.org/pipermail/india/2014-August/005571.html

Few days ago, bunch of us over lunch table discussed about reviving local Fedora community interaction and the idea for a FAD came to the fore. Now looking back, I think we immediately agreed to the idea because all of us at the table had seen & participated in FADs. We knew the drill. We knew how it works and how to participate. But little did we know about organising the day. Once it was decided that we’ll host a FAD, question was what do we do there? We held a quick stand-up discussion and decided we’ll do a Fedora test day. Participants would come and test different parts of Fedora as per their taste and file bugs for any observed failures. Implicit assumption here is participants would know the drill, what to test, how to test, how to file bugs and add karma etc. We created a wiki page with details about time & venue of the FAD, section for attendees to register their names and another one to list planned activities. But these were individual plans rather than planned activities for all.

On Saturday when I reached office, participants were already installing F21. Room was abuzz with comments & discussion about whether something was a bug or a feature. I planned to test the local DNSSEC resolver configuration, which is due to become default in F22.

    -> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver

I briefly spoke about DNSSEC, the default DNSSEC resolver feature and helped participants to configure & test the local resolver with dnssec-trigger + unbound servers.

At lunch I spoke with the new participants about what they were doing and in general how they contributed to Fedora. It turned out to be the most revealing conversation of the day, which also set the tone of this post. After lunch I could easily divide the FAD participants in two groups. One bunch was the experienced Fedora veterans who knew the drill. And the second was the new contributors eager to know the drill. They were absolutely new to Fedora. Some knew programming, others not so much. Of course all had FAS accounts, but they did not do anything with it. Some had created the FAS account to attend this FAD. So, when the veterans were doing their pre-planned tests, the new contributors were mostly left clueless about what they were suppose to do. One of the participant even asked me – What should I do?

I think we failed to set a clear agenda for the Fedora Activity Day. An agenda which was not individual but one that involved all the participants. It is not enough to just define the agenda, nope. General direction to execute that agenda is also imperative. It was essential for us to define how we were going to run the test day. Which bugs were we going to triage? How were we going to triage those bugs and what action was required at the end of the triage? Ex. another participant enquired about how to add karma via Bodhi web interface and the answer was sourced from #fedora-qa channel. All these instructions should have been listed on the FAD wiki page.

After FAD, I was browsing through the Fedora project wiki to see if there were any guidelines to help organise an activity day. And sure enough, I came across

     -> https://fedoraproject.org/wiki/How_to_organize_a_FAD

It lists the similar suggestions as above. Other minor glitch was to not solicit food preferences in advance. Along with the Attendees’ registration, a column could have specified their food preferences. Since it is a one day event, it does not make sense to go to a restaurant for lunch. That would be a distraction from the planned event.

So a FAD wiki page should at least have:

  • Clear agenda for the day that’ll involve all participants. If participants want to form small groups and execute separate tasks, that is fine, but nobody should feel clueless.
  • Detailed instructions about how to execute the set agenda.
  • List of attendees along with their food preferences.
  • Section to document activity’s status & review comments.
  • Links to the resource pages and/or blogs etc.
  • Miscellaneous section.
  • See -> https://fedoraproject.org/wiki/Template:FAD

Hope it helps!

Local DNS resolver in Fedora


This post is a call for action. It is to spread the word about a newly proposed system wide change in Fedora, to install a trusted local DNS resolver listening on Please
     -> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
     -> https://www.piratepad.ca/p/dnssec-requisites-configurations

Domain Name System(DNS) is the ‘core’ internet infrastructure. It is an integral part of each computer system. Without it, we can not use the Internet as we do today. Yet in its current form, it is a fairly weak system. It can be exploited to disrupt services and compromise user’s privacy; Which makes it an easy target for the malicious mind. Especially with the backdrop of the increasingly snooping governments and service providers world wide. To mitigate this risk and to improve user experience, it is proposed to install a trusted DNS resolver in Fedora.

Being an integral part of each system, the proposed system wide change is bound to break existing work-flows and applications. For ex:

    This is gonna conflict a bit with docker, and other users of network namespaces,
      like systemd-nspawn. When docker runs, it picks up the current ‘/etc/resolv.conf’
      and puts it in the container, but the container itself runs in a network namespace,
      so it gets its own loopback device. This will mean points to the container,
      and not the host, so dns resolving in the container will not work.  [1]

We want to avoid any such breakage caused by the proposed local DNS resolver. Towards that end, we are collecting all the possible information about these use cases; So that we can duly fix the ensuing bugs well before time when the proposed system wide change goes live(Ie. F22). Aim is to build a robust, reliable and secure DNS solution. One which works out of the box without any user intervention.

The etherpad & wiki page above document the requisites and the new work-flow. If you think that the proposed change would break any application on Fedora or if you’ve feature requests for the new default DNS resolver(including NetworkManager), please edit the etherpad page or let me know about it. Alternatively, you could enable the local DNS resolver in your set-up, as described in the wiki page and submit bug reports if you encounter any.

    See -> https://tinyurl.com/fedora-dnssec-trigger-bugs

Your comments, suggestions, opinions about this topic are welcome too. Please help us by spreading this message to more and more users.

Thank you! 🙂

[1] https://lists.fedoraproject.org/pipermail/devel/2014-April/198706.html

New-DJBDNS 1.06


I’m extremely happy to announce, the release 1.06 of the New-DJBDNS is now available for general usage. New updates are pushed to Fedora repositories and shall soon be available via stable channels. It’s a landmark 10’th release of the project. 🙂

        See -> http://pjp.dgplug.org/ndjbdns/

A major highlight of this release is the couple of security fixes for potential Denial of Service (DoS) flaws. One happens by a subtle hash collision attack, while the other is a result of excessive read(2) calls. It is highly recommended to upgrade your set-up to use 1.06 release. Nevertheless, CVE requests for these vulnerabilities were rejected on non-technical grounds.
        -> http://www.openwall.com/lists/oss-security/2014/02/10/4
        -> http://www.openwall.com/lists/oss-security/2014/02/17/3

Apart from these issues, 1.06 release fixes an important time zone bug(discussed -> here) to account for the Daylight Savings Time(DST) and introduces new command line options to read from non-default configuration file. This will help to run multiple instances of servers with different configuration parameters. Thanks to Francisco M Biete for writing a patch to introduce new options and to Don Ky for reporting the time zone issue.

Another major highlight of this release is an excellent documentation contributed by Satya K. It was the last pending packaging goal set in the early days, now met! 🙂

        See -> http://pjp.dgplug.org/ndjbdns/document.html

If you find a bug or spot anything amiss, please let me know, I’ll fix it. With last of the initial goals met, this release truly marks an important milestone in the evolution of the New-DJBDNS. Many people have contributed, in various ways, to this progress & the growth of New-DJBDNS. I sincerely thank them all for the constant support and encouragement they have offered me. It’s bliss!

Now, it’s time to set new achievable goals. It’s time to define the new possibilities. One of the long-standing inherent drawback of the New-DJDBNS is its inability to communicate over IPv6. In the second spell of its development, I plan to rid New-DJBDNS of this very inability. Apart from this super goal, if you have suggestions, feature requests or patches that you’d like to see merged in New-DJBDNS, I’m all ears, please feel free to write to me.

Thank you! 🙂

Of chroot, time zone and glibc

A N-DJBDNS user reported an issue saying, “Timestamps logged by the DNS servers are off by one hour. Doesn’t N-DJBDNS account for Daylight Savings Time(DST)? Our time changed this week.”

I was puzzled. Because N-DJBDNS servers use system time zone by initialising the TZ environment variable with it. System time zone is identified by a file ‘/etc/localtime’. Often it is a symbolic link pointing to one of the binary data file under ‘/usr/share/zoneinfo/’. Standard <time.h> functions read from this file to perform their operation. Since N-DJBDNS servers are confined to the chroot(2) jail, they can not access ‘/etc/localtime’ and thus have to rely on the
POSIX TZ environment variable for the time zone definition.
        vsftpd: vsf_sysutil_tzset(void) -> ../vsftpd-3.0.2/sysutil.c
        postfix: -> http://www.postfix.org/postconf.5.html (search for “TZ”)

How does one set this TZ variable? The closest I could get was the tzset(3) standard API. Going by its name, one would expect it to set the time zone appropriately, so that applications continue to see correct times. But far from it, the API actually reads TZ variable if it is set or reads ‘/etc/localtime’ when TZ is not set and initialises three public variables:

        extern char *tzname[2];
        extern long timezone;
        extern int daylight;

Of these, ‘tzname’ array stores standard & dst time zone names(ex: EST/EDT), ‘timezone’ stores the standard time offset from UTC(ex: +5:30/-12:00) and ‘daylight’ acts as a boolean variable indicating whether current time zone follows DST rules during any time of the year or not at all. tzset(3) manual says ‘daylight’ has been obsolete for many years. Thus is not useful. A saving grace for the tzset(3) API is that its manual is quite elaborate about 3 formats of the TZ variable.

N-DJBDNS was using the standard time zone name from ‘tzname[2]’ array and standard time offset from ‘timezone’ variable to define the TZ environment variable in its “std offset” format as IST+5:30 OR NZST-12:00 etc. This is where the bug lies, TZ definition does not account for DST time changes.

But there is no standard method to appropriately define the TZ variable so that it accounts for Daylight Savings Time, as and when it is applicable. I discussed this issue with the upstream glibc developers. They also agreed that it’ll help to have an API to query system time zone definition. As per the discussion, three bugs have been filed against glibc, including an RFE for a new time zone API.

        BZ#1077902 -> [RFE] A new API to query time zone data from the tzdata files.
        BZ#1077377 -> tzset(3) incorrectly sets the ‘int daylight’ variable.
        BZ#1076794 -> tzset(3) incorrectly sets tzname[1] DST time zone name.

A basic patch too has been submitted for the new time zone API. If you are interested in contributing to glibc, please join the discussion at #glibc on irc.freenode.net and libc-help mailing list. These bugs are classic low hanging fruits for someone to start with. 🙂

Btw, the N-DJBDNS issue is fixed here -> d77a7d6dd1a2.

New-DJBDNS: User comments


+-- On Thursday, 30 January 2014 6:10 PM, Timbo wrote --+
|First of all, can I say THANK YOU for making DJBDNS useful.
|I've always had to fight with it and seeing it pop up on EPEL
|in a useful rpm format that used service and chkconfig, etc
|really made my day.
|I'm basically converting all my servers from using my home-brew
|compiled djbdns to yours.
|Anyway, thanks again for all your great work.

Best email of the week! Thank you Tim!! 🙂

New-DJBDNS 1.05.9


I feel extremely happy to announce that a new release, version 1.05.9, of the N-DJBDNS is out and available for download

    at -> http://pjp.dgplug.org/ndjbdns/

(For the uninitiated) N-DJBDNS is the brand new, totally revamped and renovated version of the djbdns. It has lots of great features which make it all worth it to give it a try. 🙂

This release includes three major features along with the numerous enhancements to the code base, which significantly improve the quality of the software. The three major features are

* Human readable logging support in the root server: continuing the changes which began in the last release, this release concludes the logging changes by unifying the two loggers, one of root servers’ & another of dnscache(8) resolver’s into one. Thus enabling consistent, human readable log structure and format across all servers. It greatly helps to remove redundant code base. It significantly eases the task of maintenance.

* Xinetd(8) and Systemd(1) support for axfrdns(8): The DNS zone transfer server axfrdns(8) was broken[#3], because it used to depend on the ‘tcpserver’ for listening on its behalf. This issue is fixed with the new configurations which enable the axfrdns(8) server to work with Xinetd(8) & Systemd(1) services. Thanks to Jason Clark & Edwin Eefting for helping with the comprehensive reviews and testing.

* DNS(or domain) Block List in dnscache(8): This I think is the most important feature of this release. DNS Block List is a list of domain names which are to be blocked by the resolver. Client requests querying for such domains are dropped by the server. This would add an additional layer of security for DNS clients and also help to reduce malicious traffic.

DNS block list is a ‘cdb’ database created using tinydns-data(1) tool. tinydns-data(1) creates the ‘cdb’ database from a ‘data’ file. List the malicious domain names in this ‘data’ file as generic domain records, one on each line, as:


Number ‘284’ is not used, it can be any integer between 256..65535. tinydns-data(1) would create a ‘data.cdb’ database from this ‘data’ file. Rename ‘data.cdb’ to ‘dnsbl.cdb’, for that is the file read by dnscache(8) resolver.

    $ mv data.cdb dnsbl.cdb

dnscache(8) reads ‘dnsbl.cdb’ from its working($ROOT) directory defined in its configuration file. For starters, I created a domain list from the www.phishtank.com data set. Being a set of phishing URLs, the list has few false positives though.

    $ python -m json.tool online-valid.json | grep -i ‘”url”: “http’ –    \
         | cut -d’/’ -f3 | sort | uniq | awk -e ‘{ print “:”$0″:284::::”; }’ | tee data

Hope you find it helpful. 🙂



I’m pleased to announce a yet another release of the New-DJBDNS. The latest version 1.05.8 is now available in source and RPM package format from its home page:

    at -> http://pjp.dgplug.org/ndjbdns/.

Both Fedora and EPEL updates have been pushed and shall be soon available via the stable repositories using Yum(8).

    # yum install ndjbdns

The major and rather important change has been made to the caching server dnscache’s logs. Now these logs are arranged in chronological order with timestamps and readily comprehensible information. Earlier, most of it was cryptic hexadecimal values and numbers.

It is extremely important to have meaningful logs in place along with the secure logging mechanisms. Especially in the light of the recent events like the SEA DNS attack on nytimes.com or little earlier Distributed DoS attack against Spamhaus.org DNS servers etc. When responding to such events, having meaningful logs in place is but instrumental. Because the logs can tell you about the origins of these requests, quantities and distribution patterns of such requests across multiple sources and continents. A lot many conclusive findings can be derived from carefully crafted logs. But the lack of them could just make the matters equally worse for the defenders.

I planned to include similar updates to the root server tinydns’s logs too, but that got delayed a little because of some travel and work. Other major changes include addition of a new root server to the global list, and a bug fix update to the logrotate(8) configuration file.

I hope you find it helpful. 🙂

LKML & Netiquettes


    Today I spent considerable time reading the now epic email thread “How to act on LKML“. It makes for an interesting read. Both, Sarah and the other kernel community members offer reasonable arguments for & against restricting use of abrasive language on LKML. Though the general consensus amongst the community members seems to be that, it is okay to use abrasive language because sometimes that is what conveys the message effectively and brings about the change you wish to see.

I disagree. In my view there is no justifiable reason to be abrasive, rude and demeaning to your co-workers and fellow developers. One can always convey their disappointment and disagreement in respectful manner. Respecting a person is imperative and disrespect is never acceptable. It is just not the right way to handle conflicts or express personal anger. It might get the job done but still not the right way. For the same reasons as why threat and intimidation are wrong methods to get the job done(banks in India employ recovery agents who use such means to recover loan amounts). Besides, we are dealing with diligent and thoughtful engineers; Not some kind of psychopathic criminals who’ve raped 30 children and 50 women.

In India, (I feel embarrassed to say) women and children are raped, abused every day. Every single day. Sometimes they are killed after the rape, sometimes burned alive, sometimes left to die or live a slow death. People protest, raise concerns, discuss and debate. Once there was a national eruption of anger and cry for action. But nothing changes. Life goes on, rapes go on. Every time these discussions and debate happen, the talking heads argue that people(men) in India must change their mentality and mindset towards women. They must respect women and treat them justly.

But how did this mentality came to be in the first place? Did it happen over-night? In last 10-20-30 years?? I think it’s a baggage from ages. If you grow-up watching your father abuse and beat your mother, you are more than likely to resort to the same measures when in a similar situation. Because that is what you know and that is what is normal for you. At some point in time, somebody in a powerful position failed to establish the norm or just wrongly defined what is acceptable. For generations people did not, perhaps could not oppose and it became a standard practice. An accepted behaviour. It is ingrained so deep in our psyche that we don’t even notice when something inappropriate is said. You use the ‘F’ word and it just flows unnoticed. It is no longer inappropriate. There is a new norm.

It sets a bad precedent when people in powerful positions use disrespectful and demeaning language to convey their anger, disappointment and disagreement. Even if they have all the reasons to do so. Because it spoils the environment and sets a bad mood. It thwarts genuine useful dialogue and discourse. Plus others who look up to these people and hero worship them are likely to follow their suit.

It is really funny to see so many developers projecting the fact that Linus rebuked them as some kind of badge of honour. And justify him saying he can do that because he is Linus; He is not rude to new comers but only to his trusted folks from whom he expects better. May be Linus is thoughtful enough to do that. Who is to say tomorrow these same followers and fan boys would be thoughtful too. I also wonder if they would put up with someone else using the same language with them. I have seen numerous verbal abuses and insults. Managers insult subordinates, senior engineers yell at their peers and junior ones imitate. It is always an unpleasant experience. Not just for the person who is at the receiving end of the flak, but the entire surrounding.

Today Linus has a unique opportunity to set the precedent right. Even if he believes that it is okay to curse when you are angry. It is justified to vent out venom when it is called for. Even if his maintainers don’t object to him doing so. If he decides to refrain from disrespecting other developers; If he makes a choice to be respectful to others even when he is angry, he could establish the new norm. His choice will have far reaching effects not only on the kernel community but even wider groups on the internet as well as off it. We might witness the history shift its gears, turn around the corner and accelerate in a bright new sunshine direction.

…let’s see! 🙂