Hi all,
This post attempts to share some of the interesting news which has been making rounds the last few weeks and a command called debsums which is used to know system integrity and changed configuation files.
I have to admit I had been feeling extremly lazy while at the same time extremly interested in the events and happenings which have been happening over the last couple of weeks so this will be kinda some of the interesting finds I found over the last couple of weeks.
The first interesting mail/post which I saw few days ago was from Piotr Ożarowski . On weekends sometimes I try to see some of the more interesting mails from the various debian mailing lists. One of those mails was about debian-python being deprecated in favor of dh_python2 .
Long time ago, far far away (over Atlantic Ocean), lord Matthias and lord Josselin decided to fight a dragon that was eating virgin packages every time new Python version was born in Debian kingdom. They created two different machineries to fight the dragon and after a while the dragon ran away. All lived happily ever after… except they didn’t! These machineries scared
some people even more than the dragon and were dangerous sometimes as well. The kingdom divided into two camps and when everyone almost lost hope that the kingdom will be united again, Python kingdom’s friendly governor king created Jaskółka sword (AKA PEP3147) and at the same time a peasant created yet another two headed machinery to make sure dragon will not come back (with Jaskółka on board). Even royal council was involved (in a topic related to dragon) but it couldn’t take a decision for a very long time and thus Prince of Darkness^WDebian (AKA “barefoot prince”) convinced both lords to use this new machinery.Will they live happily now? dh_pysupport is hereby deprecated. I uploaded 1.0.14 to unstable which is raising a deprecation warning and points to migration guide¹. Please switch to dh_python2 while preparing new upstream release (don’t worry about next python-all transition – I will NMU all arch:all packages that will need an upload, send me a mail if you prefer to do it yourself). I will file (whishlist) deprecation bugs (against all packages that build depend on python-support) *after* Python 2.6 removal from list of supported Python versions in unstable.
[¹] http://deb.li/dhs2p
—
Piotr Ożarowski Debian GNU/Linux Developer
http://www.ozarowski.pl http://www.griffith.cc http://www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62
I loved the mail quite a bit as while it was talking about a technical change within the Debian ecosystem/Universe the change itself was shared in a role-playing story kinda way. It shows/shared that the developers have a sense of drama, of story telling rather than just being robots (the common idea).
While I was reading that mail in some remote corner of the brain, I was reminded both of Tolkein’s worlds as well as the lore of an upcoming game that is dungeonhack/god’s head . I was reading a thread in dungeonhack/god’s head last week which shows the depth the guys are thinking of. Alas, the development is not keeping a pace with such a rich story/lore. It would be interesting to play and experience the game when it develops. It is one of the very few games where I wished I had some programming or designing skills to help the team make the game. But that is a story for another day. Sigh!
Anyways, around the same time i.e. on last week-end I also was looking at the lwn.net bigpage and was curious about the hullabaloo surrounding systemd . For those who came in late, systemd is another contender for systemv init scripts. The best way to know about the init scripts would perhaps be the wikipedia article about Init.
Disclosure :- I just have knowledge/know-how of the init systems at a very peripheral/surfacial level. So hence please take the below content with a bag of salt.
While I was reading that lwn article, it was unknown to me that a huge thread was happening simultaneously on Debian-devel mailing list about systemd itself with a few forks of the discussion itself. The first e-mail on the subject was written by Juliusz Chroboczek and it quickly generated into a heated discussion with something around 80-100 messages. Some of the interesting mails which I thought were interesting are being linked below :-
a. The different binaries of systemd :- Tollef Fog Heen shares some of the different binaries being generated/part of by systemd.
b. Popcon results of various system architectures by Ben Hutchings :- Ben Hutchings gave an idea as to how many users use the various flavors of the Debian distribution .
Note:- As things look/stand, it seems that the i386 flavor would perhaps be more and more used for netbooks, laptops having lower memory and heat constraints while desktops will slowly but surely move to the amd64 version to take advantage of the 4GB+ memory and benefits of multi-core and 64-bit computing. Just to share, a 4 GB DDR3 memory stick retails for around Rs. 2000/- to Rs. 2500/- (around $50) and going down. So on new desktops for sure, it is given to go the amd64 route.
c. Making daemons compatible with systemd by Juliusz Chroboczek :- Julius Chroboczek gives examples of how some of the simple daemons could be easily changed to using systemd
There were couple of other interesting links too which were shared during the discussion. An lwn.net article which shares the ‘portability and platform issue’ and a somewhat dated but still useful post which showcases the vastness/universalness of the Debian project.
While reading some of the mails and some of the discussions on Debian, some things became clear :-
a. Basically what systemd is trying to do is what SystemV scripts have been doing. SystemV scripts are of a time when it made sense to have linear startup meaning one step or one command at a time. This is what it did and it did a commendable job for its time. Cut to today, where both the hardware and software have become pretty complex. Multi-core processors, all sorts of sensors on motherboards and multitude of daemons.
b. Now one problem is Lennart Pottering is the author of systemd. He is the same developer who developed ‘Pulseaudio’ and lots of people both in Debian as well as Ubuntu got bitten off more than ever by problems due to Pulseaudio. The problems of not being able to play an audio file (which is taken for granted) was a pain for many a users around a year, year and a half back. I remember staying up many a nights on IRC to try to figure out the issue. Lennart does give some insight into this in an interview in LinuxFR. Frankly Lennart did less than a stellar job in communicating the changes that were happening in the audio stack at that time. That experience by developers and users does work against him.
c. Debian has something like 14 odd architectures which you can use, one in particular ‘Debian GNU/kFreeBSD’ would need a lot of work if systemd becomes the mainstay event-based init system. The overall portability of the code is also a concern. A related generic article throws some light on the issue as can be seen in this lwn.net article. Who would do that porting work as well as carrying the patches is one of the open questions?
Also it would require quite a few softwares which are in GNU/Linux to be ported to GNU/kFreeBSD as well which is further work. Technically the only good thing I see in it is the ZFS support other than that dunno why I would be swayed by it. Also if one were to compare then the GNU/Hurd seems to be more in a release state than the Debian/kFreeBSD port.
d. One of the big wins of systemd which I personally like is the ability that once a parent process is killed, all the child processes will be killed as well. For instance when I am running boinc (a distributed computing client) it spawns two or three threads for the different projects it is computing. If I kill boinc-client or/and the manager it may or may not kill the child processes as of today. The promise is this will become a thing of the past so when I do kill a process, it will surely kill all the associated child processes/threads and things will be that much smoother.
If you are coming from Windows, this should be equivalent to Kill process tree in Task Manager.
e. Many of the Debian Developers and Maintainers are conservative in nature. As it is a volunteer-led project so time is an issue. Also lack of test-driven development tools perhaps makes it more problematic.
f. Part of the Debian-team wants to adopt systemd today so they can have a say in systemd development otherwise they would use/look at it 2 years or more down the road when arguably every other distribution would have picked it up. This might sway some potential Debian users.
g. The other contender upstart has not had much of a success of it being used apart from Ubuntu.
h. The real and most interesting is if all the other distributions do get onto it, Debian sooner or later would have to go for it. If all the distributions do go that way then upstreams for various daemons would have to do the changes to use the new init system and there is possibility of standardization and perhaps predictability as well in most of the GNU/Linux systems. It is also possible then when distributions are tested head-to-head as far as booting is concerned, it could be found what tweaks and optimizations were done by x distribution which would be useful to everybody else.
i. One of the more flamy articles/blog post has been written by Lennart himself quite sometime ago where he tries to give a head-to-head comparison to other potential init systems. Since then Lennart has been making quite a few blog posts to inform others how to work with systemd .
j. Last but not the least, more and more of the boot process has to move to some sort of event-based model as can be seen from this couple of years old Debian article.
At the end, while I am cautiously optimistic and hope to see systemd integrated within Debian, it would be interesting to see which way ahead do things go. Some of the reasonings above also explain perhaps some of the reasons why there are a number of growing attempts/replacements of SystemV init scripts.
As some of the regular readers of the blog might know, I have a severe laziness and memory problem. So there are times when I want to copy/image some apps and configuration from one machine to the other. While there are many image and backup apps which do that, I am interested to know which configuration files I have changed in a system. For a long time it was a hit and miss thing as there was no easy way out. Then I found out about debsums. The stated usefulness of the utility is to check the system integrity of the system by comparing the md5sums of packages against md5sums in its database.
One can run debsums either against the whole system or against a single package to verify that the package has not been tampered. Giving an example below
$ debsums debian-bts-applet
/usr/share/debian-bts-applet/debian-bts-applet.glade OK
/usr/share/debian-bts-applet/debian-bts-applet.schema OK
/usr/share/debian-bts-applet/debian-bts-applet.svg OK
/usr/share/doc/debian-bts-applet/changelog.gz OK
/usr/share/doc/debian-bts-applet/copyright OK
/usr/lib/bonobo/servers/DebianBTSApplet.server OK
/usr/lib/gnome-panel/notify OK
/usr/lib/gnome-panel/debian-bts-applet OK
/usr/lib/gnome-panel/BtsApplet/download_queue.py OK
/usr/lib/gnome-panel/BtsApplet/__init__.py OK
/usr/lib/gnome-panel/BtsApplet/bug_number_parser.py OK
/usr/lib/gnome-panel/BtsApplet/controller.py OK
/usr/lib/gnome-panel/BtsApplet/view.py OK
/usr/lib/gnome-panel/BtsApplet/model.py OK
The Ok part confirms that the package, in this case debian-bts-applet has not been tampered. The more interesting part for me is that just by using couple of switches of the utility, it is easily known which configuration files have been touched. This is great either when trying to figure out what went wrong where or making similar changes in other systems and you forget the changes. A partial snapshot of the changed configuration files in my system.
$ sudo debsums -ec
[sudo] password for shirish:
/etc/boinc-client/cc_config.xml
/etc/boinc-client/global_prefs_override.xml
/etc/console-setup/remap.inc
/etc/crontab
D000001: cmpversions a=`0:1.16.0.3' b=`0:1.15.0' r=1
D000001: cmpversions a=`0:1.16.0.3' b=`0:1.15.8' r=1
/etc/dpkg/dpkg.cfg
/etc/gdm3/greeter.gconf-defaults
/etc/gdm3/daemon.conf
/etc/default/bootlogd
/etc/dhcp/dhclient.conf
/etc/security/limits.conf
/etc/NetworkManager/NetworkManager.conf
D000001: cmpversions a=`1:3.2.8-11' b=`1:1.2' r=2
/etc/sysctl.conf
D000001: cmpversions a=`0:2.31-1' b=`0:1.50-1' r=1
/etc/transmission-daemon/settings.json
So at one shot I am able to know what .conf files I had touched. This is great from a system-administration view. It might also be useful for forensics. The only downer for the package is it still uses md5sums when sha1sums and better checksums are available.
That’s about it for now .
Experiences in the community 