a technical IT blog
Archive for the ‘Linux’ Category.
Recently I was setting up DRBD (in short: “block devices designed as a building block to form high availability (HA) clusters”) between two data centers.
DRBD doesn’t apply any form of compression on the data that is replicated; is it a good idea to enable compression in the VPN link if you replicate your data with DRBD over Internet? Here is a quick test.
Do you happen to be running a Linux distribution and have Panasonic Lumix digital camera?
If yes, you may have problems downloading photos from it – depending on your kernel and udev settings, or more generally, on Linux distribution used.
The tips from below may help you.
Have you ever needed to execute a command or to connect to an interactive text console on a remote Windows station?
Probably several times, and usually, you had to log in using either VNC or RDP (Remote Desktop Protocol – Microsoft Terminal Services). If you’re used to SSH, you may wonder why the overhead of a complete desktop is needed just to start a few text commands.
Of course, there are free and commercial SSH servers for Windows, but one problem with them is that they have to be installed separately. Which may be too much work for a one-off task now and then. Are there any other methods of accessing a remote Window text console from your Linux station?
Continue reading ‘Accessing Windows console remotely from Linux’ »
Quite recently, HP announced a new line of thin clients with Debian Etch 4.0 preinstalled. That’s certainly good news for Linux, but why HP’s Linux support is Windows only?
Is using CPU frequency scaling on a server a good idea? After all, some servers don’t do very much at night, so why shouldn’t we scale CPU frequency down when servers are idle?
Unfortunately, simple tests revealed serious performance problems when reading from a drive encrypted with dm-crypt / LUKS – here is why (with a simple solution).
Continue reading ‘CPUfreq and dm-crypt performance problems’ »
Lately, I was playing with logfs, a scalable flash filesystem. It’s interesting because of at least three reasons:
In other words, a perfect filesystem to use for all flash-based devices, like USB-sticks.
Any filesystem should aim for high reliability, no doubt about it. But how to test it? Linux kernel provides a nice feature called “fault injection”. If Documentation/fault-injection/fault-injection.txt isn’t clear for you after the first read, here’s a quick help.
Ever rebooted your NFS server, just to find out that your NFS clients can’t access it any more, with an error message “Stale NFS file handle”? If this happened to you and you have your NFS server’s exports on a LVM volume, this means that you didn’t read a fine exports manual:
fsid=num
This option forces the filesystem identification portion of the file handle and file attributes used on the wire to be num instead of a number derived from the major and minor number of the block device on which the filesystem is mounted. Any 32 bit number can be used, but it must be unique amongst all the exported filesystems.
This can be useful for NFS failover, to ensure that both servers of the failover pair use the same NFS file handles for the shared filesystem thus avoiding stale file handles after failover.
Some Linux filesystems are not mounted on a block device; exporting these via NFS requires the use of the fsid option (although that may still not be enough).
Obvious, and self-explanatory, isn’t it? If you happened to have this “Stale NFS file handle” problem and your exported NFS file systems were on a LVM volume, adding fsid for each exported filesystem should help:
/nfs4exports 192.168.18.129/26(ro,sync,insecure,no_root_squash,no_subtree_check,fsid=0)
/nfs4exports/vmware-data 192.168.18.129/26(rw,nohide,sync,insecure,no_root_squash,no_subtree_check,fsid=1)
/nfs4exports/xen-config 192.168.18.129/26(rw,nohide,sync,insecure,no_root_squash,no_subtree_check,fsid=2)
Note: if this error only happens when accessing certain files, this means that your (non-network) filesystem is broken:
# rm fCVS
rm: cannot remove `fCVS': Stale NFS file handle
In this case, running fsck is recommended.
See Solving reliability and scalability problems with iSCSI, part 1 article.
The latest stable IET release, 0.4.15, suffers yet another misfeature: it will likely break all initiators when the ietd process is restarted (ietd restart, machine restart etc.).
This is because on ietd shutdown, the user space daemon is just killed, but it doesn’t have the corresponding signal handler and the kernel space module doesn’t perform any cleanups for it.
From initiator’s perspective, several things may happen:
Of course, no one wants to have the filesystem remounted read only, or to have the hard drive ripped off from a working system (this is how it looks from the perspective of the kernel if we loose a iSCSI connection).
There is a simple solution to that, although some may say it’s an ugly hack.
Continue reading ‘Solving reliability and scalability problems with iSCSI, part 2’ »
Yesterday, I tried to make a diff of two ~800 MB big files on a machine with 1 GB RAM – unfortunately, it didn’t work:
# diff -u full/2007-09-25-full.sql incr/incr.sql
diff: memory exhausted
After some googling and looking through various blogs and articles, it appeared to me that GNU diff just works like that – wants to load both files in memory. So, perhaps adding some more space would help?
# dd if=/dev/zero of=/swapfile bs=1024 count=5242800
# mkswap /swapfile
# swapon /swapfile
Indeed, it helped – I was able to make a diff of these two ~800 MB files. However, as soon as I tried to make a diff of ~1 GB files, diff again exited with “memory exhausted” message.
I tried a number of tools, but none of them was giving the output I wanted (similar to that of diff -u).
As I needed that diff for backup only, in the end, I use xdelta tool:
# xdelta delta -9 full/2007-09-25-full.sql incr/incr.sql 2007-09-25-sql.delta
It gives a binary delta file, but is able to produce it using much less memory than diff.
Ooh, and if your files are so big that xdelta is failing for you…
# xdelta delta -9 full/2008-06-01-full.sql incr/incr.sql 2008-06-02-incr.delta.temp
xdelta: mmap failed: Cannot allocate memory
…you may consider using xdelta3. The deltas it produces are a big bigger, but it works much better (read: does not fail) with large files. Syntax:
# xdelta3 -9 -f -e -s full/2008-06-01-full.sql incr/incr.sql 2008-06-02-incr.delta.temp
Still, it would be great to have a tool which could produce diff -u -style output for large files.
Today I noticed non-admin users can’t print on a new Samba server. Samba log for a given host would just say: client-error-not-authorized. Turned out, it’s a CUPS configuration problem, so let’s write a short article about it.
Normally one configures Samba to use a CUPS server running on the same host. When a user wants to print anything, Samba uses a username/password to access the CUPS server. After authorization checks are successful, Samba connects to CUPS as root, and thus, bypasses all security checks (they were done just a while ago with username/password).
Continue reading ‘Samba says: client-error-not-authorized’ »