Category Archives: Linux/Unix

KDE: a call for a change (or: why I moved to GNOME)

5 Replies

[Disclaimer: I'm merely a KDE user, hardly involved with the KDE development processes; my criticism is based on what I see as a user, I'll be glad to be corrected in the comments]

Back when I started my way with Linux with the brand new RedHat 6.0 (which as always, preferred GNOME). KDE always went forward: KDE1 was pretty.. basic, KDE2 was a big step, and same goes from KDE3. I've been using KDE 3.5.x for quite a long while (RHEL/CentOS5 and Debian sid until recently). 3.5.x symbolizes, in my opinion, the last "winning' era of KDE:  It had the right features, but more important: it was mature and stable.

KDE 4 introduced important improvements:

  • User interface continued the tradition of being much nicer than its predecessors. Compare for yourselves: KDE 1 2 3 4
  • Very nice OpenGL effects were added with two important advantages over GNOME+ Compiz: the OpenGL features are fully integrated inside KDE, configuration is way easier (Compiz configuration tool is scary), and the attitude is more towards productivity and less toward eye-candiness. For example, instead of the useless wobbling windows and water effects of Compiz, KDE provides the useful feature that displays all open windows and allows search-as-you-type for choosing the right application by its name, by simply putting the mouse pointer  on the top-left corner.
  • Simplified user interface: the developers had the courage to do some rewrites and strip complicated GUIs, even lose some features, and make the new KDE 4 apps more simple. This is mostly notable in konsole and amarok.

But, it also got worse than its predecessors on some areas:

Continue reading →

udev debugging toolbox

5 Replies

Ever wondered why a certain rule doesn't get run? Ever got confused (or disgusted) by udev rules format?

Well, despite all the udev clutter, there are many useful tools in the udev package, which help to understand udev's behavior and decision making. I'm still far from knowing all the tricks, but here are some things that I've learned recently:

Note: the udev tools got changed several times during the last 5 years. I'll cover here the latest version (149), and the older, RHEL/CENTOS5 version.

1. udevadm info: get all info available to udev about a certain device (or all devices):

# udevadm info -e (RHEL5: udevinfo -e)

Try it.. amazing, eh? You can use each detail to write udev rules to match these devices.

Continue reading →

Sudo make me a sandwich

Leave a reply

Sudo

Q: How come "which ifconfig" (runing as a user) finds nothing, yet "sudo ifconfig" does work?

A: sudo has a compile-time parameter called with-secure-path, which sets a different PATH for the sudo environment. Debuntu secure path contains /sbin:/usr/sbin, and that's how it works. This feature gets two goals: convenience (no full path required for common root cmds) and security (ignoring potentially bad user PATH).

NOTE that RHEL doesn't use this option, and running "sudo ifconfig" there simply fails.

Q: How come sudo requests a password only on the first run?

A: Sudo has a nice mechanism for creating these "sudo session" things. After authentication, sudo creates a 'timestamp dir' (in /var/run/sudo on my Debian), then uses its date to check when the last successful authentication took place.

  • Session timeout is configurable, defaults to 15mins.
  • sudo -k kills this session by simply removing the timestamp dir.

All info is found in the sudo(8) and sudoers(5) manpages

Setuid and LD_LIBRARY_PATH

Just a quick insight from my workplace: to my surprise, a setuid binary deliberately ignores many environment variables such as LD_LIBRARY_PATH and LD_PRELOAD.

Security Shmecurity..

RIP sysvinit, welcome upstart

1 Reply

After Ubuntu and Fedora, Debian also migrates to upstart.

To summarize the article in the previous link, the main reason for the change is that the kernel is now no more blocking on some hardware scans, and this might make some init scripts (e.g. fsck, network) start before the device is initialized. We now need an event-based init system, so the kernel could "tell" it when the device is ready. This is something that upstart is capable of.

Now I wonder if RHEL6 would inherit upstart from Fedora, this will mean a complete victory for upstart.

Accessing a LVM volumes from a foreign OS

Leave a reply

A lesson learned: in order to mount an LVM device on another machine or simply another OS (e.g., from within a live cd os, mount the local machine's volumes), the LVM volume group must be exported and then imported. This is done using the vgexport / vgimport commands.

Another requirement, is to have lvm2 package installed (so lvs command actually sees the volumes), and device mapper module should be loaded (dm-mod) or builtin the kernel.

Thanks for Amir who found that out.

By the way, I've recently found the dmsetup command very useful.

bash evilness

Leave a reply

I've been trying to read a file in bash, and keep all the lines in a single variable, printing it at once after the loop:


all="EVIL_BASH"
cat /tmp/myfile | while read line; do
all="$all $line"
done
echo $all

However the output was only: EVIL_BASH, instead of having the lines of the /tmp/myfile appended.

WHAT THE HELL?

Because of the PIPE, the whole 'while' loop runs in another subshell. This means that $all outside the loop  is not the same $all from within the loop!

Sounds simply like scoping (as in perl), but a really awkward one. Beware.

Advantures of CentOS 5.3 upgrade

Leave a reply

I've upgraded my home server (which is also a router and an access point) from 5.2 to 5.3. All in all it was pretty flawless. Kudos to the CentOS team! Still, I'll update about few issues I've encountered:

1. Atheros wifi driver: I've been using the madwifi driver until now, which is not a part of the kernel because of licensing issues (contains proprietry firmware I guess). CentOS 5.3 introduced the ath5k driver, which is a free implementation. However, ath5k still doesn't implement "access point" mode, so I had to disable it (renamed  ath5k.ko and ran depmod -a), and reinstall madwifi 0.9.4 instead (simply running make; make install).

2. udev.rules were overwritten, which cleared the changes I've made, in particular the /dev/snd permissions were reverted to CentOS default (no "audio" group, only the device owner can access audio), so I had to re-change the /dev/snd/* file permissions.

Long live Debian!

8 Replies

After the Lenny release, nobody can say that Lenny is not a rock-solid OS. Furthermore, nobody can say that sid(unstable) is not bleeding edge enough. Especially after kde4.2 made it into sid. The kde4.2 upgrade process succeeded smoothly on my place. I've also "upgraded" my Lenovo X61 laptop from Ubuntu to Debian sid with a surprising success. I really feel better now, with Debian.

Still, when trying to convince people why Debian is superior than Ubuntu, it's hard to find the rational reasons. After all, Ubuntu is a Debian with more money and a larger community. After some thought, I've caught two possible reasons:

  1. Expert community: the average debian bug report is much more professional than an ubuntu bug, which is sometimes just a mess made of dozens of people saying "ohh it also happens to me!! please fixxx!". In other words, Debian users seem to be more tech savvis.
  2. KDE is quite a stranger in ubuntu. Kubuntu is quite uncommon, which makes it a little less intensively developed. In Debian there's no such partition. Debian is KDE as much as it's GNOME. I like KDE, so it feels more native to use Debian.

What do you think, why is Debian superior in your opinion? (or is it not..)

/dev permissions hell

2 Replies

[... This post got too long for no good reason, feel free to jump to the conclusions ...]

The problem
On my CentOS 5 server, the default sound device (/dev/snd/*) permission was root:root 0600.
This means that other users simply cannot play music. Annoying.

The solution ought to be simple...
So, I've ran groupadd sound and added all the relevant users to the new group.

Then, I went to /etc/udev/rules.d/90-alsa.rules, and added this line, to tell that anything that is sound related, should be fully accessible to "sound" group:

SUBSYSTEM=="sound", GROUP="sound", MODE="0660"

Fanatic problem solving mode: ON
But.. not working. Then I've switched into "fanatic problem solving" mode. This means: trying everything without too much thought, modifying every possible file with any possible way.. But no luck. /dev/snd/* files are still root-only-accessible.

A-HA!
Then I've tried to really think.. Running the following command and really inspect its output:

udevtest /devices/audio/subsystem/timer

(udevtest needs the /sys path and not /dev path, quite annoying)

The output shows the list of rules that udev would run for this device. Then I've noticed the last line

main: run: '/sbin/pam_console_apply /dev/snd/timer '

PAM! Of course it's guilty. Then a quick grep revealed the following in /etc/security/console.perms.d/50-default.perms:

<console> 0600 <sound> 0600 root

I commented it out, and ... viola! All works.


In short...

Linux, or at least RedHat 5, has two conflicting mechanisms for setting /dev file permissions:
1. udev: the service responsible for /dev directory content.
2. pam: the service (well, not quite a service but something similar) responsible for system's security.

Udev actually calls the pam service on new device (on rules.d/95-pam-console.rules), so in effect, pam might actually override Udev permission settings. The relevant PAM config files are in /etc/security/console.perms.d).

Great, 1.5hrs got wasted. at least I've learned something.