Tag Archives: Linux/Unix

Init script dependency

"Behind my back", a new feature was added to LSB specification and to Debian Lenny accordingly: Init scripts dependency.

The new LSB defines new fields for init script headers: Required, Should (like Required but only if installed) and Provides. This means that the init system should take care of ordering the init scripts according to their dependencies (i.e. "NFS" service requires "portmap" service which requires network and thus order should be Network -> Portmap -> NFS). This eliminates the need to give funny "K01/S99"-style numbers manually to each service.

Cool. But is it enough? The init system is several decades old. Maybe we need something revolutionary such as Upstart or Solaris SMF. Features like starting/stopping independent services in parallel, service monitoring (watchdog/keepalive), or other crazy ideas that Upstart & SMF implement.

Ubuntu's Upstart was adopted also by Fedora 9; this means that RHEL6 might use Upstart as well. In that case, the revolution is over.. Debian, SuSE (and Windows maybe? 🙂 ) would probably follow.

Per directory quota: not just a dream

Ext3 and many other popular filesystems allow per-user and per-group quota. In some cases, a "per directory tree quota" is needed: doesn't matter who writes the files, limit a directory tree from growing to a size of more than X bytes.

As I see it, it can be good for many cases, either limiting a directory from exploding (Lior wrote about a similar problem a few weeks ago), or simply allocating space per team-projects on a file server.

As far as I knew, the only UNIX FS that implemented this feature was Sun's unpopular SAMFS/QFS. However, I've just stumbled upon this man page and was surprised to find out that the good old (well, at least old 🙂 ) XFS does that already!

A quick "howto use project quota" cookbook:

1. Make the filesystem and mount it:

> mkfs.xfs /dev/loop0
> mount /dev/loop0 /mnt/tmp -o pquota

2. Create a project named "project1", which is the "/mnt/tmp/tree1" tree:

> echo "11:/mnt/tmp/tree1" >> /etc/projects
> echo "project1:11" >> /etc/projid
> xfs_quota -x -c 'project -s project1' /mnt/tmp

3. Set the tree quota to 2 MB:

> xfs_quota -x -c 'limit -p bhard=2m project1' /mnt/tmp

4. That's it.. Now let's make some tests:

> dd if=/dev/zero of=/mnt/tmp/tree1/aaa count=10 bs=1024k
dd: writing `aaa': No space left on device
2+0 records in
1+0 records out

2093056 bytes (2.1 MB) copied, 1.51164 s, 1.4 MB/s

> touch fdsa
touch: cannot touch `fdsa': Disk quota exceeded

5. And there's also a nice report! (looks nicer with a fixed-width console font)

> xfs_quota -x -c 'report /mnt/tmp'
Project quota on /mnt/tmp (/dev/loop0)
Blocks
Project ID       Used       Soft       Hard    Warn/Grace
---------- --------------------------------------------------
project1         2044          0       2048     00 [--------]
project2            0          0          0     00 [--------]

PAE – what’s that, and how bad for performance?

Err, what's PAE?

PAE (Physical Address Extension) is a "workaround" for letting x86-32bit(!) OS see more than 4GB of RAM. 4GB is the limit for 32bit memory addresses. PAE is not needed and not implemented on x86-64 processors when 64 bit ("long mode") is enabled.

How does it work?

In short, it simply adds 4 bits to the memory addresses (32bit -> 36bit) and one more level of memory-lookup-hierarchy, and: voila, OS can access up to 64GB ram (which is not science fiction these crazy days..). Of course, a single 32bit process is not aware, and would still only have a 4GB of virtual address space, even with PAE.

Performance penalty: yes or no, and how much?

I was given a task to research the PAE technology for recommending my company whether we should use it or not, especially performance-wise.

Continue reading

VMware modifier keys bugs: update

Some updates since the last post:

The "GTK dies on a keypress" bug

Good news: it was fixed by Matthias Clasen. It was solved in the SVN version, I guess that we'll have to wait a while till it gets into the next version, Unless package maintainers would manually add it.


Doing a good QA in the FOSS community

I've learned a quick lesson about good QA in the open source community, which I find very rare.

In this case the bug was reported for ~2 months with no activity ("it sometimes crashes" type of report). Until I've added my description, which, probably helped it to get closed.

I'll try to sum up what I've learned:

Continue reading

Configuring sendmail as an MSA

[Disclaimer: sendmail is very complicated, and I lack some knowledge. The following solution might be even bad, although it works (tm). Please post comments if you know better ways, and I'll update the post]

I was looking for a quick n' simple SMTP solution for sending mails only. Requirements:

  • A service that'll simply accept mails submitted locally and maintain a queue of mails-for-sending.
  • It'll then send the mails by SMTP directly to the target servers (i.e. gmail.com).
  • It should retry for a few days, if failed sending due to a local (dead connection) or remote problem.
  • A bizarre one: it should be listening on a port other than 25, because another daemon uses it already. I know it's nonstandard and doesn't make sense, but should be possible..

Apparently what I was looking for is an Mail Submission Agent (MSA), which also takes care of delivering the mail. Also there's a standard port for mail submission: 587 (submission).

Continue reading

glibc 2.7 on CentOS / RHEL 5

Update: Note! The issue was fixed in CentOS/RHEL 5.2 !

glibc 2.7 introduces a new flag to open() syscall, called O_CLOEXEC.

The official redhat 2.6.18 kernel (even of version 5.1) doesn't support it, and returns errors (in strace it looks like open() returns unknown error 530).

So.. just try not to use glibc 2.7 on RedHat, until they support it. If you want an adventure, this kernel seems to do the job..

How did I encounter this uncommon problem, you ask? I'm running Debian unstable VM inside a CentOS5 host (the VM's kernel is actually a CentOS5 kernel). Debian upgraded glibc to 2.7, and later the VM couldn't function (open /etc/passwd gave error 530). Not too smart of me, I guess. But dzickus kernel seems to solve it.

Switch to another UID/GID, with Perl

Originally I wanted to start by describing Linux' setuid()-like functions, which change the user-id of a running process (and more). Some reading made me realize that this area is too big (but interesting!) for a simple post, and also that I still don't master it..

So I'll focus only a single, simple task: switching from root to regular user permissions: when a daemon is being run by root (i.e. init scripts), for security reasons we want them to "transform" to a regular user right asap. In the kernel level we want to do something like setuid or setresuid (set all the user identifiers: Real, Effective and Saved) to a specific, different UID.

However, we don't talk about the kernel, but about a much higher scripting language.. So let's begin with basics: according to perlvar manpage, $> (or $EUID if using 'use English') represents the Effective User ID (Effective is the User ID which matters permission-wise). "print $>" perl command would simply print the EUID.

Now for the surprise.. "$>=44" perl command simply sets the EUID! Oh, the simplicity 🙂

GID can be set in a similar manner, but can't be set after the the uid is switched (we need the initial root permission for the GID switch).

Enough talking, let the code begin:

#!/usr/bin/perl -w
use strict;
ues English;
$EGID=22;
$EUID=22;
sleep 50; # Sleep so we can have time to run "ps axo pid,uid,euid,gid,egid" :)