Generally I don’t have to bother about the startup time of any command line tool. For a human eye and normal day to day usage, if a command takes half a second to finish the job, it is not much of a problem. But, the story changes the moment we talk about a command which we have to run multiple times. What about about a command which have to execute multiple times every minute? This is the time when the startup and execution time matters.

A few weeks ago I was looking at a Python script which was executing as part of Nagios run, it was doing an API call to a remote server with JSON data coming in as command line arguments. Now, to make it scale more the first thought was to move the actual API call to a different process and get the original script to load things into a Redis queue. But, the other issue was the startup time for the Python script, having something with lesser startup time would be more help in this case, where nagios may execute the script/command over a few hundred times in every minute.

So, first I rewrote the code in Rust, and that made things multiple times faster. But, just for fun I wanted to see if writing it in golang will help or not. And I am kind of surprised to see the startup/execution time difference. I am using hyperfine for benchmark.

Python script

  Time (mean ± σ):     195.5 ms ±  11.3 ms    [User: 173.6 ms, System: 19.7 ms]
  Range (min … max):   184.5 ms … 228.8 ms    12 runs

Rust code

  Time (mean ± σ):      31.1 ms ±   8.4 ms    [User: 27.3 ms, System: 3.0 ms]
  Range (min … max):    24.6 ms …  79.0 ms    37 runs

View the code.

Golang code

  Time (mean ± σ):       3.2 ms ±   1.6 ms    [User: 1.0 ms, System: 1.7 ms]
  Range (min … max):     2.6 ms …  19.6 ms    140 runs

The code.

For now, we will go with the golang based code to do the work. But, if someone can explain the different ways Rust/Golang code starts up, that would be helpful to learn why such a speed difference.

Oh, here is the result of a quick poll on Fediverse about startup time.

Update

I received a PR for the Rust code from, which removes the async POST requests, and made the whole thing even simpler and faster (30x).

  Time (mean ± σ):       1.0 ms ±   0.6 ms    [User: 0.5 ms, System: 0.3 ms]
  Range (min … max):     0.5 ms …   4.3 ms    489 runs

The year 2022 gave me one of the happiest moments in my life, and I also felt proud as Anwesha joined the Ansible community team as a software engineer in Red Hat. Proud because she became the best example of someone to whom I taught things about computers (she has multiple mentors/friends who helped her during this journey). Though sometimes that created trouble at home, the output is super lovely. From a Masters in Law to a software engineer in Red Hat is a good story.

Also, Red Hat has a special place in our home. I left Red Hat more than 5 years ago, but still, you will notice how Red Hat (the friends there and the culture) changed my life and later the life of our family. Oh, the other special thing is that Anwesha will have her own Red Fedora now :)

In my last blog post I talked about verybad web application. It has multiple major security holes, which allows anyone to do remote code execution or read/write files on a server. Look at the source code to see what all you can do.

I am running one instance in public http://verybad.kushaldas.in:8000/, and then I asked twitter to see if anyone can get access. Only difference is that this service has some of the latest security mitigation from systemd on a Fedora 35 box.

The service is up for a few days now, a few people tried for hours. One person managed to read the verybad.service file after a few hours of different tries. This allowed me to look into other available options from systemd. Rest of the major protections are coming from DynamicUser=yes configuration in systemd. This enables multiple other protections (which can not be turned off). Like:

• SUID/SGID files can not be created or executed
• Temporary filesystem is private to the service
• The entire file system hierarchy is mounted read-only except a few places

systemd can also block exec mapping of shared libraries or executables. This way we can block any random command execution, but still allow the date command to execute.

Please have a look at the man page and learn about many options systemd now provides. I am finding this very useful as it takes such small amount of time to learn and use. The credit goes to Lennart and rest of the maintainers.

Oh, just in case you are wondering, for a real service you should enable this along with other existing mechanisms, like SELinux or AppArmor.

I am planning to add a few chapters on securing services in my Linux Command Line book. But, to make it practical & hands on, I needed one real application which the readers can deploy and secure. I needed something simple, say one single binary so that it becomes easier to convert it into a proper systemd service.

I decided to write one in Rust :) This also helps to showcase that one can write totally insecure code even in Rust (or any other language). Let me introduce Very Bad Web application. The README contains the build instructions. The index page shows the available API.

Issues in the service

The service has the following 3 major issues:

• Directory traversal
• Arbitrary file read
• Remote code execution

I am currently updating the systemd (services) chapter in my book to show how to secure the service using only the features provided by the latest systemd. In future I will also have chapters on SELinux and AppArmor and learn how to secure the service using those two options.

If you think I should add some other nice security holes in this application, please feel free to suggest :)

No summer training 2020 for me. Last year’s batch was beyond my capability to handle. Most of the participants did not follow anything we taught in the course, instead, they kept demanding more things.

I already started receiving mails from a few people who wants to join in the training in 2020. But, there is no positive answer from my side.

All the course materials are public, the logs are also available. We managed to continue this training for 12 years. This is way more than I could ever imagine.

As I was feeling a bit sad about this, the keynote at Railsconf 2019 from DHH actually helped me a lot to feel better.

In 2017, I started working on a new book to teach Linux command line in our online summer training. The goal was to have the basics covered in the book, and the same time not to try to explain things which can be learned better via man pages (yes, we encourage people to read man pages).

Where to practice

This one question always came up, many times, the students managed to destroy their systems by doing random things. rm -rf is always one of the various commands in this regard.

Introducing lymworkbook

Now, the book has a new chapter, LYM Workbook, where the reader can set up VMs in the local machine via Vagrant, and go through a series of problems in those machines. One can then verify if the solution they worked on is correct or not. For example:

sudo lymsetup copypaste
sudo lymverify copypaste

We are starting with only a few problems, but I (and a group of volunteers) will slowly add many more problems. We will also increase the complexity by increasing the number of machines and having setup more difficult systems. This will include the basic system administration related tasks.

How can you help

Have a look at the issues, feel free to pick up any open issue or create issues with various problems which you think are good to learn. Things can be as easy as rsync a directory to another system, or setting up Tor Project and use it as a system proxy.

Just adding one problem as an issue is also a big help, so please spend 5 minutes of your free time, and add any problem you like.

I started my Linux journey with Gnome, as it was the default desktop environment in RHL. I took some time to find out about KDE. I guess I found out accidentally during re-installation. It used to be fun to have a desktop that looks different, behaves differently than the normal. During the earlier years in college while I was trying to find out more about Linux, using KDE marked me as a Linux expert. I was powered with the right syntax of mount command to mount the windows partitions and the xmms-mp3 rpm. I spent most of my time in the terminal.

Initial KDE days for me

I started my FOSS contribution as a KDE translator, and it was also my primary desktop environment. Though I have to admit, I had never heard the word “DE or desktop environment” till 2005. Slowly, I started learning about the various differences, and also the history behind KDE and Gnome. I also felt that the KDE UI looked more polished. But I had one major issue. Sometimes by mistake, I used to change something in the UI, wrong click or wrong drag and drop. I never managed to recover from those stupid mistakes. There was no way for me to go back to the default look and feel without deleting the whole configuration. You may find this really stupid, but my desktop usage knowledge was limited (and still is so), due to the usage of terminal based applications. Not sure about the exact date, but sometime during 2010, I became a full-time Gnome user. Not being able to mess around with my settings actually helped me in this case.

The days of Gnome

There aren’t many things to write about my usage of Gnome. I kept using whatever came through as default Fedora Gnome theme. As I spend a lot of time in terminals, it was never a big deal. I was not sure if I liked Gnome Shell, but I kept using it. Meanwhile, I tried LXDE/XFCE for a few days but went back to the default Fedora UI of Gnome every time. This was the story till the beginning of June 2016.

Introduction of i3wm

After PyCon 2016, I had another two-day meet in Raleigh, Fedora Cloud FAD. Adam Miller was my roommate during the four-day stay there. As he sat beside me in the meeting, I saw his desktop looked different. When asked, Adam gave a small demo on i3wm. Later that night, he pointed me to his dotfiles, and I started my journey with a tiling window manager for the first time. I have made a few minor changes to the configuration over time. I also use a .Xmodmap file to make sure that my configuration stays sane even with my Kinesis Advantage keyboard.

The power of using the keyboard for most of the tasks is what pulled me towards i3wm. It is always faster than moving my hand to the trackball mouse I use. I currently use a few different applications on different workspaces. I kept opening the same application in the same workspace every time. It, hence became muscle memory for me to switch to any application as required. Till now, except a few conference projectors, I never had to move to Gnome for anything else. The RAM usage is also very low as expected.

Though a few of my friends told me i3wm is difficult, I had a complete different reaction when I demoed this to Anwesha. She liked it immediately and started using it as her primary desktop. She finds it much easier for her to move between workspaces while working. I know she already demoed it to many others in conferences. :)

The thing which stayed same over the years is my usage of terminal. Learning about many more command line tools made my terminal having more tabs, and more number of tmux sessions in the servers.

Over the years I met many students who want to start a new Users Group in their college, sometimes it is a Linux Users’ Group, sometimes it is related to any other particular technology. They all have one common question: how to find funding for the group? In this post I am going to talk about what did we do for Durgapur Linux Users Group, and how are we managing currently.

The domain name and the whole back story

Back in 2004 when I started the group, I started a page in Geocities. For the young kids, Geocities was a service from Yahoo! where you can create static HTML pages and was one of the easiest ways to have a website. After a few weeks, I found another service which was providing .cc domains for free. So, we moved to dgplug.cc for few months. Meanwhile, we kept searching for a way to get our own domain name. We found one Indian provider where we could get a domain and some space for around Rs.750 annually. That was the cheapest we managed to find. It may not sound too much money for a year, but in 2004 none of us had that much money. We could not even raise that much money among all the regular participants.

I called my uncle Dr. Abhijit Majumder (Assistant Professor, IIT Bombay), then a Ph.D. student in IIT Kanpur, if he could help me with Rs.1500 (for the first 2 years funding). He generally supported all my crazy ideas before, and he also agreed to help this time. But then the question came how to get the money. Online money transfer was not an option for us. Luckily during the same week, my college senior Dr. Maunendra Sankar De Sarkar (he was an M.Tech student in the same institute as Abhijit) was coming down to Durgapur. He agreed to pass me the money in cash and later collect it from Abhijit after he goes back to Kanpur.

Even after we found the way to fund us for the first time, we got a new problem. To pay the domain register we have to use a credit card or use HDFC’s cheque. I started asking around all of my Computer Science department professors if anyone can help. Finally, with the help of Prof. Baijant we managed to deposit the cheque to the bank.

For the first two years, that was the only point for which we required money. For the meetings, there was no other expenditure. We never provided any food or drinks in the meetings. If anyone wanted to eat anything, they did that after the meetings by paying for themselves. Not having any recurring costs was a huge benefit. I would suggest the same to everyone, try to minimize the costs as much as possible. Though in a big city it is much easier to get sponsorship from different companies or organization for the meetups, remember it is someone’s money. Spend it like it is your own money. Find out what the bare minimum requirements are, and only spend money on those.

How do we currently fund dgplug?

Before we answer this question, we should identify the expenses. Because all of our meetings happen over IRC we don’t have any recurring costs for meetings. The only things we are spending money for are:

• The domain name
• The web hosting (we use Dreamhost for static hosting)
• Various bots (running in containers)

After I started working, I started paying for the first two expenses. The containers run beside my other containers in my personal servers, so no extra cost there. Among dgplug and friends now we have many volunteers who are working professionals. We know that we can manage any extra cost that comes up among ourselves. For example, this year, during PyCon India we gave a scholarship to Trishna so that she can attend the conference. We had a quick call, and the funding was arranged in a few minutes. We also had group dinners at a few previous PyCon(s), and provided lodging for women student participants, that was also handled among the group members.

But all of this never came from the start. It took time to grow the community, to have friends who take dgplug as important as I do. We still try to cut costs wherever possible. If you are starting a new group, and try to spend as little as possible, many members from the existing communities will notice that. The group will be in a much better shape to ask for any required funding when it is really necessary. People will help you out, but first, the volunteers have to earn the trust from the community. That comes from work done at the ground level. Be true to yourselves, and keep doing the good work. Good things will happen.

Saw this few days back. They are really happy with the OS as almost no downtime for them.

From 29th of August to 2nd September we had our ten years meet in Durgapur. NIT Durgapur hosted the meet.

I reached Durgapur in the morning of 28th August and made sure every thing is in place including the hotel rooms. Assistant Prof. Animesh Dutta was incharge from the college and he did an amazing job on the organizing part. In total this was a flawless event as I saw it.

Rest of the speakers arrived in the evening in Durgapur, there was a taxi strike in Kolkata on that day but things worked out well.

Day One

The day started around 9:30am in the auditorium, our team along with the volunteers from the college were the first to reach the place. The students started coming in slowly and the event started on time. Day one was mostly filled with talks, history of dgplug, how different members started their journey in the group. Praveen led the work on introducing the Fedora project to the students. Prasad took the most anticipated talk of the day, on Iptables. The day ended with light discussions related to talks and programming in general and some cloud :)

We found that around 25 students were traveling from UIT Burdwan to Durgapur and they were going back in the evening. Almost same number of students were participating from Dr. B. C. Roy Engineering college, Durgapur. We also met few summer training students from 2014 batch (session is still going on).

The network was kind of slow, but we were prepared for that and asked everyone to install required packaged at their home/hostel.

There was a speakers/volunteers dinner in the night.

Day Two

The room was full, 150+ seats were taken. All of the dgplug members acted as TA during the Python sessions. We introduced the basic of the language and then actually went into basics of Vim editor. Most of students had trouble with typing, so introduced gtypist. As usual the highest numbers of error were from typos. But with time people were in sync with vim.

We saw the features of the language and basic data structures it provides. We were following my book Python for you and me for the same session.

By the end of the day the students managed to write few basic scripts to implement their own ls or free command. Few of the professors also attended the session. We had lot of fun during the session as students' reactions were priceless.

Day Three

I was not present in day three as I had to come back to Kolkata for a family event but the feedbacks for the day three were really good. First the team did a follow up of the day before. Then there were sessions of Flask and testing in Python.

Day Four

I was back in Durgapur in early morning and started the day with a talk, "Document your code". The talk was as usual interactive type, we heard many ideas on documentation from the students.

Then I introduced reStructuredText in the first half and then wrote some basic project documentation using Sphinx project. We also demoed how to create presentations using rst2s5 tool.

At the end we had a members meet for dgplug. The discussions from the meeting are as follows:

• Current drupal and mediawiki systems are too heavy for our needs.
• dgplug.org will have a static landing page.
• We are moving into a simpler wiki system which our members can manage.

We had around 120+ people in this day.

Day Five

We did a session of git and then demoed how to send in patches to the upstream. Then there were lots of discussions on project ideas, general queries etc. It become an informal discussion session where people asked where to start or how to do certain things in their laptops. We also fixed couple of issues in people's laptops in these 5 days. Praveen actually formatted many laptops and install Fedora 20 during the sessions.

Few points for any such future event

• Teach how to close the auditorium door properly :)
• Teach how to type (use gtypist for the same).

These two seems to very much needed action items for any future event. The college authority were surprised to see the attendance in the sessions. We never talked about the event much. Praveen has notes from the feedback session of the event. He will write about it.

The idea is to continue doing things in the local colleges in the same way. Our goal is to build more upstream contributors, which is more difficult than writing code. But we are in it. Next 10 years we will see even more changes, new faces, new friends, new technologies but we will stay as a group of friends, having fun together.

At the end I want specially mention Abhijit, Poulami and Bikash for the all hard work during the event, Red Hat and Sanisoft for helping in many different ways.

You can view the full photoset in flickr.