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.
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.
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.
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:
cat /tmp/myfile | while read line; do
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.
I got confused: should I use insserv or chkconfig on SLES? How do they differ?
Apparently, chkconfig is a perl wrapper to insserv, which actually mimics chkconfig very well.
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.
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:
- 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.
- 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..)
A few days ago, I've installed KDE 4 on my Ubuntu laptop, as I wanted to replace GNOME. The GUI and default styles are really beautiful (finally someone realizes that black-based colors are best. like good old console).
One of the first things I always do when customizing a new environment, is assigning a keyboard shortcut for running konsole. After a little struggling & googling, I realized that setting a command shortcut is not available through the keyboard settings, nor through the "properties" menu of the desktop icon, because there's no such menu anymore. I think that it's a bad design, but that's one thing.
The right way for setting a command shortcut is through the menu editor (right click on K menu). After choosing an application from the menu, it's possible to assign it a shortcut key.
... Or so it seems! I've chosen my favorite key combination (ctrl+space), and it didn't work. Some googling revealed that it's a known bug with a normal severity, which will only be fixed on KDE 4.2.
Bottom line: KDE 4.1 (sounds like a mature version to me..) does not support assigning keyboard shortcuts to commands although the option is present with no warnings, and nobody is going to fix that for 4.1. This is, what I call LAME (read: unprofessional).
On my Debian desktop I still have KDE 3.5 (which is a great product), because sid is still in a deep freeze. Maybe it's good, after all.
Since my first XFree86 (v3), I got used to the annoying /etc/X11/XF86Config file (now /etc/X11/xorg.conf), and I didn't notice that editing this file already belongs to the dinosaurs era. Quite silently, new features emerged and gave better ways to configure X, in particular screen resolutions. I'll sum up what I've found out today, in a bullet fasion:
- The modern xorg actually no longer needs the xorg.conf file. xorg simply knows what to do automagically :). xorg.conf file can be used though, for overriding the defaults. Still, only the overrided stuff can be written, and the file is still small and readable.
- xrandr --mode changes the resolution on the fly (not permanently though), from a list of given resolution. Thank you, HP, this time you did something good 🙂
- xrandr --newmode , xrandr --addmode: add new resolutions to that list.
- Still, X may have an upper resolution limit which it won't let you pass. It can be increased by adding a "Virtual" line to xorg.conf (Screen section -> Display subsection). i.e. "Virtual 1280 768" would set a maximum resolution of 1280x768.
- cvt is a cool tool for generating Mode Lines, simply amazing! Needed for xrandr --newmode command.
- Setting a new resolution permanently: this Ubuntu howto suggests to simply add the correct xrandr commands (i.e. xrandr --mode 1280x768) to the ~/.xprofile script. These commands would run right after each X login for that specific user. (There's probably a system-wide equivalent)
- GNOME (and probably KDE as well) has its own resolution settings, which seems to override the xrandr change. So if using GNOME, configuration should be simply changed from within the GNOME tools..
Good stuff. It's always nice to see how things got better in few years. Still, in my opinion xorg has many problems (and slow development cycle), and might be the weakest link on Linux desktops. Goodbye!
There are many ways to fetch the list of currently-mounted-devices: read the files /etc/mtab, /proc/mounts, or exec /bin/mount, /bin/df.
I've been arguing with a colleague (Yaniv), that relying on /etc/mtab is no much worse than relying on /proc/mounts. But after we inspected it on Linux & Solaris (/etc/mnttab), I figured out that I was pretty wrong, and learned some new surprising facts:
- /proc/mounts is a read-only, kernel-generated file.
- /etc/mtab (Linux) is a regular file. It's kept up-to-date because the mount/umount commands modify it. It can be modified by a root user, moved and even deleted!
- df command is using /etc/mtab, thus after rm'ing /etc/mtab, df would stop functioning.
- mount command doesn't care about /etc/mtab, probably uses /proc/mounts or some internal kernel structure.
On Solaris (prepare for some weird stuff now):
- Solaris has got /etc/mnttab, but no /proc/mounts equivalent.
- /etc/mnttab is a mounted filesystem, of the mntfs type. So it's somewhat similar to /proc/mounts on Linux. It cannot be modified.
- /etc/mnttab is actually a directory! (a mount point has to be a directory..)
- /etc/mnttab can be unmounted, renamed, rmdir'd (when unmounted) and mounted anywhere else.
- both df and mount rely on /etc/mnttab, thus not functioning when it's absent
- /etc/mnttab, which is a regular file, is similar to /etc/mtab on Linux.
And on another, non-related subject: looks like Debian Lenny has got only 80 bugs to go (as of 19/01/09)! Go Lenny!