Prolonging periodic e2fsck intervals

So the recent xorg-server (version 1.7.1.901-2 on Arch) update proved disastrous for my system as it started to crash at random intervals, and I fixed it by installing vesa driver instead of the intel driver that I was using originally. Those frequent X crashes caused me to reboot my system, which resulted in file system checks being forced too often as the max-mount-counts was reached rather quickly. That’s where I decided to enable time-based checking instead of mount-counts based checking. Both types of criteria could be used together and a filesystem check would be forced whenever one of the them is true. In my case, I needed time-based checking only so I had to disable the other one, using:

tune2fs -c 0 /dev/sda1

Also, I specified a period of one month as an interval between the checks, using:

tune2fs -i 1m /dev/sda1

These new settings take effect w/o needing a reboot and could be verified by doing:

tune2fs -l /dev/sda1

Filesystem checks could be totally disabled (if we disable both the types), but it’s strongly discouraged. We should know that on journaled filesystems such as ext3, the filesystem is never marked dirty. Instead in case of unclean shutdowns or crashes, the journal is left with “uncommitted/unfinished requests/data”, and on reboot the journal is replayed to take care of the unfinished business. Nevertheless, things could go wrong due to a variety of factors and that’s where these periodic checks could prevent major data loss in case of disk I/O that is erroneous but unnoticeable. A few reasons for these could be failing old storage media, bad cables, undiscovered kernel/filesystem bugs etc.

Hail the victorius dead!! (From LOTR :))

Today I was reading one of Ashfaq Ahmed’s Zavia Series books, Zavia 3rd volume to be specific. I have read some portions from Ghazali’s “The Alchemist of Happiness” as well a while ago (it’s Urdu version actually). And now I can probably assume that I have a little bit of idea of the style of narrative of Ghazali’s work. Now the surprise that hit me today was that when I was reading one of the chapters from Zavia’s 3rd vol. I found the style of its narrative very similar to that of Ghazali’s (To “The Alchemist of Happiness” that is, which he wrote for common people, not like his other works that challenged the long-established schools of thought of the Greeks…).

I guess the reason for their narrative being the same (at least as it occurred to me) is that the Truth is very simple; it could be described as one-liners usually. And there is only one and simple way to describe it, using big and dashing words would only pollute it.

Anyway, that was a pleasant surprise for me.

Screensavers, DPMS & Xorg

Screensavers have long been in use in CRT based consoles/terminals to prevent phosphor burn-in by constantly changing/moving a displayed pattern/text around the screen. Modern displays (both plasma & CRTs) have much better phosphors which are less prone to burn-in.

Energy Star is an EPA program to encourage power-saving in various consumer devices, buildings etc. First DPMS standard was released by VESA in 1993 to support Energy Star like power saving features for computer monitors. VESA (Video Electronics Standards Association) is an international open consortium whose initial goal was to produce a standard for 800×600 SVGA resolution video displays. VESA is very active even today as one can notice it here.

DPMS (Display Power Management Signaling) works on DPMS-compatible video adapters (appropriate device drivers?) and video displays. It uses Hsync and Vert-sync signals to distinguish between four operational modes -  Normal (on), standby, suspend and off. Let’s look at them briefly (a bit more detail could be found here):

Normal: Totally powered on – duh!

Standby: RGB guns off (so totally blank screen). Power supply on, tube-filaments energised.

Suspend: RGB guns and power supply off. Tube-filaments still kept energised.

Off: Total power-off, except for very little power drawn by the monitor LEDs and by a little circuit on the monitor which checks for a power-on DPMS signal.

DPMS in Linux could be enabled by either:

1. Specifying it in xorg.conf
2. Passing a cmd-line configuration argument while launching X; “X dpms” enables DPMS, “X -dpms” disables it
3. Using xset to enable/disable it in a running X; “xset +dpms” enables DPMS, “xset -dpms” disables it

On my system (Xorg 1.6.3.901) DPMS extension is automatically enabled (w/o using any of the above three methods), with default timeouts for various DPMS levels. These and other settings about the current X could be queried by using “xset q”.

As we already know that screensavers do not save any energy (unless one is using a very dark one, with very little patterns), there however is a possibility in X to use a totally blank screensaver. In this case the RGB guns would be off with everything else powered on, which makes it very similar to the “Standby” DPMS mode. This blank screensaver is also enabled by default in X, and it activates in 10 minutes. It should be noted though that this is a timeout value for those fancy screensavers (which do use RGB guns and hence energy), the default setting in X however is to keep it all blank. Default timeouts for Standby and Suspend is 20 & 30 minutes respectively.

[ System Settings > Display > PowerSettings ] provides an  easier way to configure power-saving timeouts in KDE4.

Also vbetool could sometimes be used to change DPMS levels on the fly, but its use is not recommneded while X is running. This link has some interesting information about its working.

Empty Trash on Exit: In Thunderbird

I am using Thunderbird Linux version 2.0.0.22 to handle emails from my local pop3 server. I wanted to keep (hold back) deleted emails that I sent to the Trash folder. I tried to configure this option using Edit > Account Settings > Local Folders, but “Empty Trash on Exit” wasn’t working. Then I started looking for the preferences file, which I found in “~/.thunderbird/ahfpj9uv.default/prefs.js”. Though it is discouraged to edit this manually, but I had no other option. So I searched it up a bit, found the misbehaving line and changed it from:

user_pref(“mail.server.server2.empty_trash_on_exit”, true);

to

user_pref(“mail.server.server2.empty_trash_on_exit”, false);

Restarted the application and it worked perfectly afterwards. Certain advanced options in Firefox could be edited by browsing to the about:config page, but it is discouraged officially.

Shrinking an ext3 Filesystem

So I decided to embark on this LFS project, for which I needed a separate partition. I didn’t have any spare unpartitioned space so I decided to shrink one of my existing ext3 filesystems.
The first thing to do of course was to unmount the partition. Then I ran the following to see if there were any problems with the FS.

fsck -n /dev/sda3

I needed just 2GB of free space so I shrank my FS from 28 to 26 GB. resize2fs (as it’s name suggests) is used for all resize operations on ext2-3-4 filesystems, but before that one has to run fsck.

fsck -f /dev/sda3

resize2fs /dev/sda3 26G

resize2fs prints the new length of the FS, which should be noted alongwith the blocksize information. This would be needed when we resize our partition later.

While resizing my partition, I multiplied the blocksize with the number of blocks as reported by resize2fs, for the size of the new partition. I added a 100MB more to it so that it would successfully house the newly created (shrunk) FS. Then I ran partprobe to update the kernel’s idea of the new partition tables.

Then I moved onto making a new partition in the newly created spare space and an FS on it. And that was pretty much it

A more detailed (but a little outdated) article could be found here. Also there are easy-to-use graphical tools (with the look and feel of PowerQuest’s Partition Magic) like gparted, qtparted and KDE Partition Manager that could be used. They are actually frontends to GNU parted, which in turn is a frontend to e2fsprogs, jfsprogs, xfsprogs, etc.

SNMP, described briefly & informally

Simple Network Management Protocol (SNMP)
SNMP is used in Network Management Systems to monitor & manage devices on the network. It is a component of IP suite (was originally defined in OSI model) and uses UDP as transport protocol. It consists of standards including an application layer protocol (which for instance, has commands such as GET, SET, TRAP, INFORM, etc.), a database schema/layout and data objects.
SNMP exposes variables describing various aspects of a managed system/device, stored on that device as a sort of database. This database can then be queried by a managing application (NMS?) for status information, or sometimes even new/updated values could be ’set’ on that device. The variables are stored in form of certain hierarchy. That hierarchy and associated meta-data (type and description of variables) is defined by MIBs (Management Info. Bases).

Let’s look at a few related terminologies:
Agent: is a daemon/service (a server in case of a Linux node, snmpd) that runs on the device/system to be monitored. It talks over SNMP to NMSes when they need information, or when the agent itself has to send traps(this error/warning reporting through traps is quite heavily employed in Cisco devices) to certain (preconfigured) hosts.
NMS: is Network Management System, runs the apps that interact with the agents over SNMP, and provide easy-to-use interface and help in graphs and report generation e.g. IBM Tivoli, OpenNMS.

SNMP has three versions. Version 1 is the most simple one in terms of its features. It’s also the most heavily used one, in usual practice. One has to install net-snmp package on Linux to get this thing going. One can find a set of mib files in “/usr/share/snmp/mibs/” on most Linux systems. The hierarchical database we talked about isn’t a database in strict terms, rather it’s a virtual database. H/W manufacturers do make their mib files public so that different utilities/NMSes could use them e.g. one could import mibs for a Cisco router into xml data queries for use in cacti.

Configuring an snmp agent is quite simple, one just has to add a string such as “rocommunity pass_string” to snmpd.conf and make sure that the server starts on each bootup. “rocommunity” gives read-only access to the clients, and only those clients/agents that specify “pass_string” as their password (well sort of, as snmp doesn’t call it a password). This much of setting is enough for simple info gathering, though more options could be specified and that too with a very handy perl script that comes with the snmp package. It could be invoked with “snmpconf -g basic_setup”.

a lil rambling into something :)

It is utterly strange to be stuck with something you never expected to be a part of your life. Life that you thought was so pure, precious and not-to-be-wasted in the least sense. That pesky little riddle assumed the shape and character of an enormous question — a question about meaning of life… It became something that couldn’t just be ignored — it had to be given due attention.

People in the olden days usually would retire into the wilderness of mountainous caves and forests to ponder and meditate over the questions they wanted to find a solution for — more like a vantage-point whence they could look over the people below them. That solitude gave them enough time and focus to think over the issues they had in mind. Mere time isn’t enough, one has to have lesser fuss to worry about in such circumstances. It is something unsuitable for the faint of heart, as it requires one to dive into the perilous dark waters whose endless shores may actually end in the Hades itself. One needs to have a beacon of light within oneself that will never cease to glisten and will always be there in the time of dire need. Such an anchor has to be there because sometimes the darkness is so overwhelming that one feels like drowning in it, where ones sense of equilibrium hangs by a thread.

Those adventurers of the wilderness of course had to forgo the company of their loved ones; people who would stand by them in the most frightful of times. They though were always eagerly waiting for their adventure to finish and to be re-united with their family.

As we see in those Hollywood movies where a character in the movie can’t let go off the people whom he/she developed intimate friendship with in certain bad times, the same behaviour is seen in those adventurers. They too end up in an eternal friendship and comradery with each other.

At the end of that perilous journey when one arrives home, a lot of things seem changed, some of them even unintelligible. One seems to have missed out on a lot of things, but then that’s a price one has to pay for the myriad bizarre encounters with those never seen or heard of before creatures and circumstances. It takes some time for that adventurer to adjust himself back to that rather new environment, to feel at home again just as he used to be.

After everything is settled and back to normal one ponders at times, whether it was worth all that pain. Sometimes one can’t come up with a simple solid argument, but then one should realise that it was never in ones power to not have ridden that bolt of lightening, you simply were overpowered and humbled by the sheer charisma of that beast, you had to comply. And then as they say:

If I try to be like him, who will be like me?

Life is too short to be wasted in meaningless errands, one should at least not waste it in living somebody elses life.

File Permissions

There are various other better tutorials about file access permissions over the Internet. So here I would only talk about things that are a bit rarely used or are special.

Sticky Bit or Restricted Deletion Bit: is used on directories and is used in the cases where we want only those files to be delete-able by the users in that directory which they own. This for example is the case with /tmp, where everybody can create files and directories but only their owners can modify them. This is how we enable it:

chmod +t dir_name

SetUID, SetGID Bits: give permissions of the file-owner or group permissions for that file, to the executor of such a file (a file with setuid/setgid bit on). It’s one great example is /etc/passwd & /usr/bin/passwd. /usr/bin/passwd operates on the /etc/passwd file and changes its contents as the user requests through this command. When we examine this file we notice that it’s only write-able by the root. However we know that any user can change his/her password using passwd command. This is made possible due to setUID bit on /usr/bin/passwd. So once a user executes it, he temporarily becomes the root user and is able to modify the /etc/passwd file & change password.

Changing superuser login name

The Linux kernel doesn’t use a user’s login name to distinguish & decide various things about a user, rather it uses UIDs to do so. The superuser has a UID of 0 (zero) and kernel only needs that to take care of everything about him/her. That means that we can use any login name for the superuser; using ‘root’ is not necessary. Also one can do the same in Windows as well; change user-name ‘Administrator’ to any other legal name.
To change login name one has to modify both /etc/passwd and /etc/shadow. /etc/passwd is needed cause that’s where we get information about login-name, UID, GID, home-dir & login shell from. /etc/shadow is needed because we need to read the encrypted password string from it, it should therefore not be readable by normal users.

sulogin

sulogin stands for single user login and it is invoked by the init process when switching to runlevel 1. Runlevel 1 could be entered either from telinit or from the bootloader. This is how it looks when executed:

An additional line for sulogin has to be added to inittab, so that init would be able to execute it when it enters runlevel 1. Following are the two lines from inittab that make it possible:

rs:S1:wait:/etc/rc.single
su:S:wait:/sbin/sulogin -p

The first line makes it possible to execute /etc/rc.single upon entering runlevel 1. The second must also be there otherwise it won’t work.

Following are the two interesting lines from rc.single (on ArchLinux) that actually tell init to switch to runlevel 1:

/bin/kill -HUP 1
exec /sbin/init -t1 S

The first line sends SIGHUP to init which is equivalent to telinit [Qq], which makes init re-examine inittab file. Since init automatically re-examines inittab each time it is told to change runlevel, therefore this line seems totally redundant. The second line instructs init to go to runlevel 1. telinit is actually a symbolic link to init binary. init checks PID of the process to see if it is init PID#1 or has been executed by the user (not PID#1).  /dev/initctl is a fifo special file that is created by the init process when it is first launched by the kernel and is used to send messages to init.

I clearly remember that one could login to the system as root w/o any password in older Linuxes like RedHat 7.3, which isn’t possible anymore in the recent ones due to this sulogin thing.