Tag Archives: Linux

Noida Linux User Group Second Meeting

The Noida Linux User Group will host it’s second meeting between 12 noon and 3 pm on 29th January at the third floor Barista at the Great India Place.
Hope to see you all there during the event.

For more information, visit http://www.facebook.com/event.php?eid=188477917835011

cheers,
Dhruwat aka unitedroad

Noida Linux User Group

I have been lazy about it, no I have been like an old-trunk-not moved-since-ages about it, but now I am definitely going to get it rolling. Now I finally have atleast one person who thinks it’s a good thing. He’s someone I know from work, who has a real penchant technology and activism, unlike me who is super lazy.
I am also trying to get in touch with a few people on the the social networking sites, primarily outlook, and possibly the technology forums which people from this area would often visit.
Cheers,
unitedroad aka Dhruwat Bhagat

Edit: Noida Linux User Group now has a landing page at http://www.freeyoursource.org/noidalinuxusergroup and its community page at http://www.facebook.com/group.php?gid=151278131564633.

Mount FreeBSD partition on Linux HOWTO

This is the thread that helped me with this :
http://bbs.archlinux.org/viewtopic.php?pid=285839

I have recently installed FreeBSD alongside OpenSUSE Linux on my computer. Since these two operating systems happen to share the hard disk real estate, I wanted to access the FreeBSD partition from Linux.

I tried many command line options and went through the mount man page, but I got the following error at my every attempt:

mount: wrong fs type, bad option, bad superblock on /dev/sdb3,
missing codepage or helper program, or other error
In some cases useful info is found in syslog – try
dmesg | tail  or so

Searching online I found out that mount expects an arguement named ufstype which as its name suggests, tells it which particular flavour of ufs I want to mount. And the manpage for mount told me that this should 44bsd for FreeBSD and other BSD descendants.

However, this didn’t seem to help. However, the thread I have mentioned above told me that the ufstype parameter should be ufs2 instead and whoa! it worked!

Problem: Log the details of all process ever run in system uptime. Solution: Snoopy

Linux landscape doesn’t seem to provide an out of the box facility that provides you the details of all the processes that have ever been run during the system uptime. Someone at ubuntu irc on freenode told me about Snoopy.

It has a shared library that provides a wrapper about the execv and execve system calls and logs the details using syslog. These details include the process ID, session id, the execution arguements and the id and the name of the user who executed the process.

This is achieved by appending its shared library’s path to /etc/ld.so.preload during the installation so its loaded before the libc objects when a process makes the execv/execve system call.

This tool proved very nifty for me in debugging a problem I was having with dhcp on my linux box running SUSE 10.2.

There have been no new updates to it in last 5 years. And it has a TODO list which includes finding out why logging the execve system call needs a workaround even though it internally calls execv. It also fails to run firefox which seems to have a problem with something between /etc/ld.so.preload and an audio related file in /proc. I’ll edit this blog with its details after finding more.

And actually I would like it to support a few more features . Such as a conf file with the options for what should be logged and to which file. The latter might mean using some other logging facility or adding one of its own to it, but I would find it very useful. For instance, I might want to see the snoopy logs for the past month by the day, letting me know if something odd ran on my computer. Syslog sometimes gets too cluttered with alot of noise for this.  Also, I might want to add the the functionality to get snoopy details through a socket rather than a file, making it easier to get these details from a remote computer.

But, I think there will be some features the snoopy can add which may or many not include the ones I mentioned above. I think we should pick up the thread and continue the work from where snoopy developers stopped.

I think a proc file for the basic snoopy functionality might not be a very bad idea. As clumsy as the procfs is found by many Linux kernel maintainers these days and this treads on the policy-in-the-kernel issue, many people just find it very convenient to use.

If you have used snoopy before, tell me if you think it should be developed furher or you think its just good enough as it is for what its meant for. If you haven’t and feel this would be useful for you, tell me about how you found/liked this tool.