Linux - 5

Previously I've studied the init.d replacement systemd.
Update 4th Jun 2017: See the new version

To my surprise, my contraption from the previous article didn't survive a reboot. WTF?! It turned out that in Fedora 19 the /var/run/ is a symlink into /run/ which has been turned into tmpfs. Goddamnit! It literally means, that it is pointless to create /var/run/<the daemon name here>/ with correct permissions in RPM spec-file. Everything will be wiped clean on next reboot anyway.

So, I just had to study the systemd some more.

This is my version 2 (the Unit and Install -parts are unchanged):

[Service]
Type=forking
PrivateTmp=yes
User=nobody
Group=nobody
# Run ExecStartPre with root-permissions
PermissionsStartOnly=true
ExecStartPre=-/usr/bin/mkdir /var/run/dhis
ExecStartPre=/usr/bin/chown -R nobody:nobody /var/run/dhis/
# Run ExecStart with User=nobody / Group=nobody
ExecStart=/usr/sbin/dhid -P /var/run/dhis/dhid.pid
PIDFile=/var/run/dhis/dhid.pid

The solution is two-fold. First an ExecStartPre-directive is required. It allows to run stuff before actually executing the deamon. My first thing to do is create a directory, the minus sign before the command says to ignore any possible errors during creation. The target is mainly to ignore any errors from the fact that creation would fail due to the directory already existing. Anyway, all errors are ignored regardless of the reason.

The second command to run is to make sure that permissions are set correctly for my daemon to create a PID-file into the directory created earlier. That must succeed or there will be no attempt to start the daemon. chowning the directory will fail if the directory does not exist, or any other possible reason.

Sounds nice, huh? Initially I couldn't get that working. It was simply due to reason, that the entire Service-part is run as the user pointed by the User=nobody and Group=nobody -directives. That user was intentionally chosen, because it has very limited permission anywhere or anything. Now it cannot create any new directories into/var/run/. Darn!

This where the solution's 2nd part comes in. Somebody designing the systemd thought about this. Using the PermissionsStartOnly-directive does the security context switch at the last moment before starting the daemon. This effectively changes the default behavior to allow running Service-part as root, except for the daemon. Exactly what I was looking for! Now my daemon starts each and every time. Even during boot.

Another thing which I noticed, is that when I edit a systemd service-file, the changes really don't affect before I do a systemctl --system daemon-reload. It was a big surprise to me, after all in traditional init.d everything was effective immediately.

PS.
Why cronie does not create a PID-file? I had an issue in CentOS where I had not one, but two cron-daemons running at the same time. This is yet another reason to go systemd, it simply works better with ill-behaving deamons like cronie.

I have couple of own daemons running on my Linux-box. Now that all the distros are going systemd, my scripts are becoming obsolete. Sure, the systemd can piggy-back into old init.d-scripts, but ... I'd rather have them converted to the new way.

Lennart Poettering's blog has a helpful article, which got me started on my project. Also the manual pages for systemd (systemd.service and systemd.exec) proved a very valuable reference.

My daemon is pretty much from the trivial end of daemons. It runs as nobody-user to prevent it from disallowing access to number of places in case something/somebody breaks it. It does the classic fork on start and parent process simply exits. Fortunately systemd programmers anticipated that and there is a perfect support for such startup sequence.

Here is my example. I simply placed a file named dhid.service into directory /usr/lib/systemd/system/. Then I could interface with it by systemctl-command. Example:

# systemctl status dhid.service
dhid.service - DHIS client for keeping track of changing dynamic IP addresses in DNS
   Loaded: loaded (/usr/lib/systemd/system/dhid.service; disabled)
   Active: active (running) since Wed 2013-07-03 15:26:03 EEST; 928ms ago
  Process: 32355 ExecStart=/usr/sbin/dhid -P /var/run/dhis/dhid.pid (code=exited, status=0/SUCCESS)
 Main PID: 32356 (dhid)
   CGroup: name=systemd:/system/dhid.service
           └─32356 /usr/sbin/dhid -P /var/run/dhis/dhid.pid

Jul 03 15:26:03 samba dhid[32356]: daemon started

My entire file is here:

[Unit]
Description=DHIS client for keeping track of changing dynamic IP addresses in DNS
After=syslog.target network.target

[Service]
Type=forking
PrivateTmp=yes
User=nobody
Group=nobody
ExecStart=/usr/sbin/dhid -P /var/run/dhis/dhid.pid
PIDFile=/var/run/dhis/dhid.pid

[Install]
WantedBy=multi-user.target

It is really that simple! To make the daemon to start on bootup, just use the systemctl enable dhid.service -command.

Most Linux distros have udev. It has been around a while and is pretty much the way of handling physical devices in your box.

In The Old Age™ making a device to be something was very simple. /dev was in regular filesystem and could have permissions/symlinks/whatever set by admins. During modern era creating a symlink or setting permissions is bit more complex. The steps are:

1. Identify the device
2. Figure out the identifying attributes from udev
3. Choose an operation / operations to be executed when the device is found
• This can be during boot or plug'n'play / USB
  
4. Bring it all together in a configuration file readable by udev
   

An example:

External USB-drive/-stick can have pretty much any drive letter assigned into it by SCSI-subsystem during plugin. It can be /dev/sde today and /dev/sdf tomorrow. Trying to figure out the drive letter each time it is plugged in is both tedious and unnecessary. With (simple?) udev-wrangling you can have a /dev/myownusb to access it every time the drive is plugged in. Steps:

1. Identify
1. lsusb is your friend, from the output it is possible to determine that:
   Bus 001 Device 007: ID 1941:8021 My C00l USB-drive
   
2. Today USB-bus 001 device 007 is the drive. What if you plug it into a different USB-port next time? We need to find identifying attribute/attributes to make configuring possible.
1. If we assume that the drive is /dev/sdf this time, all the udev-attributes can be displayed with a:
   udevadm info --query=all --name=/dev/sdf --attribute-walk
   
2. It will reveal a drive serial number in a format similar to:
   ATTRS{serial}=="0000002CE09310500C1B"
3. The operation we'd like to be done when such a USB-device with a matching serial number is plugged into the computer is a symlink.
4. The final step to get this configured would be to create a file into /etc/udev/rules.d/ with a suitable name.
1. I chose my configuration to be /etc/udev/rules.d/99-mylocalrules.
2. The file will contain a single line with identifying information and the operation. Example:
   SUBSYSTEMS=="usb", ATTRS{serial}=="0000002CE09310500C1B", KERNEL=="sd?1", SYMLINK+="myownusb"
   
3. That literally reads: Whenever a new device is introduced into USB-subsystem with suitable serial number and having a partition, the 1st partition will be symlinked into udev with name "myownusb"
   

To get the rule into effect you need to run:

udevadm trigger 

It is not necessary to unplug an already working drive. Just confirm that it worked:

ls -l /dev/myownusb

... or similar. Then just mount:

mount /dev/myownusb /mnt/myownusb

Another example:

I have a weather station connected into my Linux via USB-cable. There is no point of accessing it as a root, but out-of-the-box that's the only way to go. I need to chgrp the device after every boot for regular users to gain access into it.

With above process my identifying factor is the USB ID of the device and operation is to chgrp the device with a suitable group to allow access for those users belonging into the group. The rule is:

SUBSYSTEMS=="usb", ATTR{idVendor}=="1941", ATTR{idProduct}=="8021", GROUP="110"

Yet again the udev-rule reads: Whenever a new device is introduced into USB-subsystem with vendor ID of 0x1941 and product ID of 0x8021 the newly created udev-device will have a group with id 110. I prepared a group with groupadd and confirmed that it exists:

# getent group 110
WH-1080usb:*:110:itsme

After a udevadm trigger the result can be confirmed:

# ls -l /dev/bus/usb/001/007
crw-rw-r--. 1 root WH-1080usb 189, 6 Jun 19 10:07 /dev/bus/usb/001/007

The long(ish) path into the device comes from the lsusb output, it reads:

Bus 001 Device 007: ID 1941:8021 Dream Link WH1080 Weather Station

... and can be also translated as /dev/bus/usb/001/007. Simple, huh?

Fedora Linux guys replaced the ancient Initd with Systemd in Fedora 16. Bold move. I understand it had to be done. It speeds up booting and does a bunch of other things Initd can't or won't.

The classic story when introducing something new is that it has bugs. This particular time I struggled to get my Magic Sysrq key working on boot. Looks like Fedora people failed (at least) two times with it: Bug 760254 in Fedora 16 and Bug 924433 in Fedora 18 describe these shortcomings.

In short, the trouble with this new thing is that your changes won't take effect on boot. Most Linux admins never touch any of the sysctl(8)-settings and continue living successfully. Then there are rest of us, who tinker&tune their boxes to match their requirements. In Fedora Linux there is a directory of /etc/sysctl.d/ into a sysadmin may create a file with own settings to either override existing settings from /usr/lib/sysctl.d/ or set completely new values, which have only their kernel default set.

An example:
To set the Sysrq-key into "dangerous"-mode allowing all possible operations, the value of file /proc/sys/kernel/sysrq needs to be "1". It can be achieved with a file in /etc/sysctl.d/ containing following:

kernel.sysrq = 1

In Fedora the default value according to /usr/lib/sysctl.d/50-default.conf and manual inspection after boot is "16". So, the big trouble is to get the value of "1" stick. After a couple of reboots I realized that it is possible to test the functionality without booting the computer. As a root, simply run:

systemctl restart systemd-sysctl.service

... and watch what happens. The rather complex name of the service is something I couldn't figure out without Fedora discussion forums.

Anyway, after many many failures I concluded that my own settings need to be executed before the file 50-default.conf. To make things easier, systemd-sysctl.service first gathers a full list of files to be processed, then alphabetizes them and finally executes the settings in order. So I made my file to be /etc/sysctl.d/01-myownsettings.conf, which seemed to do the trick! There is a logic behind that, but it is just tricky to figure out.

Linux-distros are having a race for the most popular one. Part of the setup is to have the latest Linux kernel, and any other part of the software library a distro has. This effect yields into a "nice" effect where running the bleeding edge distros (Fedora, ArchLinux, Debian sid, etc.) every now and then something breaks.

The latest race is with PHP programming language which is nearing the 5.5.0 release. It has an RC3 version already out. Now the problem is that distro-guys start using the latest stuff, but PHP has incompatible changes in it. Plenty of things made with PHP 5.4 or 5.3 or ... won't run.

One of them is phpLDAPadmin. For some incomprehensible reason they are using stuff, which has been flagged as obsoleted years ago. So, it won't work. Luckily somebody at Debian made a fix. That makes my system's LDAP-admin working again. Hopefully somebody does the same with with all of the PEAR packages.

This is what you get when running alpha version of Fedora 19.

This is a cool move! At least Arch Linux and Fedora Linux have done this. A typical root directory listing will look like this:

lrwxrwxrwx.   1 root root     7 May 30 23:17 bin -> usr/bin
lrwxrwxrwx.   1 root root     7 May 30 23:17 lib -> usr/lib
lrwxrwxrwx.   1 root root     9 May 30 23:17 lib64 -> usr/lib64
lrwxrwxrwx.   1 root root     8 May 30 23:17 sbin -> usr/sbin

The /bin, /lib and /sbin have been in the root directory since first Unix was released in 1969. Any modern Linux distro won't have and won't need that many partitions than the legacy *nixes used to have. The reasoning is in this discussion thread.

Arch Linux guys have a pretty complex update process. The classic pacman -Syu won't do it for you this time.

On my previous post about Samba 4, I stumbled on printers.

I had a weird warning in my log:

../source3/param/loadparm.c:3121(lp_do_parameter)
  Ignoring unknown parameter "printer admin"
        printer admin = root

The fix to do is drop:

printer admin = root

from smb.conf. Instead it needs to be done run-time, like this:

smbpasswd -a root
net rpc rights grant root SePrintOperatorPrivilege

First a password is required for root-user. I have one in LDAP, but for some reason a local password is required too. After that permissions for printer administration are granted separately. That pretty much concentrates privilege handling out of any text-files.

The other issue was printer sharing to Windows. It had an easy fix. I deleted the existing printer from Windows and added it again. CUPS had renamed the printer and it was not available with the same name. A basic CUPS / Samba setup with cupsaddsmb does the trick.

My Fedora 19 project continues... An attempt to get Samba working. They upgraded into version 4 and obviously my version 3 smb.conf had issues. See my article about getting Samba to use LDAP as userbase backend.

The obvious problem was, that it didn't work.

A log entry from the failue:

../source3/lib/smbldap.c:575(smbldap_start_tls)
  Failed to issue the StartTLS instruction: Connect error
../source3/passdb/pdb_ldap.c:6531(pdb_ldapsam_init_common)
  pdb_init_ldapsam: WARNING: Could not get domain info, nor add one to the domain. We cannot work reliably without it.
../source3/passdb/pdb_interface.c:177(make_pdb_method_name)
  pdb backend ldapsam:ldap://my.server did not correctly init (error was NT_STATUS_CANT_ACCESS_DOMAIN_INFO)

I confirmed the existing settings:

passdb backend = ldapsam:ldap://my.server
ldap ssl = start tls

After a nice while of reading manual pages, an attempt to fix:

passdb backend = ldapsam:ldaps://my.server
ldap ssl = off

Yielded an improvement:

../source3/lib/smbldap.c:998(smbldap_connect_system)
  failed to bind to server ldaps://my.server with dn="uid=root,ou=People,dc=my,dc=domain" Error: Can't contact LDAP server
        TLS error -8179:Peer's Certificate issuer is not recognized.
../source3/passdb/pdb_ldap.c:6531(pdb_ldapsam_init_common)
  pdb_init_ldapsam: WARNING: Could not get domain info, nor add one to the domain. We cannot work reliably without it.
../source3/passdb/pdb_interface.c:177(make_pdb_method_name)
  pdb backend ldapsam:ldaps://my.server did not correctly init (error was NT_STATUS_CANT_ACCESS_DOMAIN_INFO)

This, however, was an easy fix. It was a simple SElinux issue:

semanage fcontext -a -t cert_t /etc/openldap/cacerts
restorecon -R -v /etc/openldap/cacerts

To my amazement SElinux context does not change on a local unix-socket request. When Samba makes the request to get user information, the LDAPd certificate store needs to have proper SElinux type for the directory. OpenLDAP does not make such checks and works fully.

Also allowing requests to home directories too:

setsebool -P samba_enable_home_dirs 1

After all this, I was happy to get my Samba-shares working again. CUPS-printing does not. But I'll fix that on some day.

I needed to transfer really big files (10+ GiB) between couple of servers. Since I was not in a hurry I decided to go with FTP. It performs very well when doing large file transfers, see File Transfer Protocol Performance Study for EUMETSAT Meteorological Data Distribution by students of Institute of Mathematics and Computer Science University of Latvia. Only Rsync could do better, and that is when the target is to transfer large number of files instead of small number of large files. In reality all the time it took me to set up the servers, I'd done transferring my files with any protocol. Really, any. But since I'm expecting to need this setup sometimes later, I went ahead with it.

Anyway, I chose to go with FTPd and since my Fedora 19 beta has one in built in repo, I went with Proftpd. Initial problems:

• It didn't work well (read: not even the simplest things you'd expect work) with IPv6, it took me 3 hours to figure this out.
  Fix: I used IPv4 addresses instead of FQDNs. Everything started to work.
  
• No anonymous FTP-access
• No anonymous FTP uploads
  

IPv6-issues

There is plenty of code like this:

pr_log_debug(DEBUG0,
  "Unable to handle PASV for IPv6 address '%s', rejecting command",
  pr_netaddr_get_ipstr(session.c->local_addr));
pr_response_add_err(R_501, "%s: %s", cmd->argv[0], strerror(xerrno));

So after I found about that, I just stopped using it.

Anonymous FTP-access

FTP isn't a secure protocol. It was once by 80s standards, but in 2013 Internet... well, no. So the best bet is not to use security at all! I'll place my security on the firewall, use anonymous logins and reduce attack surface by shutting the daemon down when I'm not expecting to need it.

Getting the anonymous FTP to work turned out to be semi-tricky. The daemon needs a -DANONYMOUS_FTP in the sysconfig. Also I needed to re-direct the anonymous FTP root directory into a dedicated partition instead of the out-of-the-box /var/ftp. My enforcing SElinux didn't like that. I had appropriate owner and group setup for the directories and files, but it turned out that my mount-directory had weird SElinux type and I decided to go with pretty generic var_t as directory type, then anonymous user was able to log in. The next thing was to make sure that actual FTP-stuff had SElinux type of public_content_t for access to directories and files to work. The final thing was to convince my SElinux to allow using of appropriate TCP-ports for FTPd:

setsebool -P ftpd_connect_all_unreserved=1 

After that I had somewhat working anonymous FTP box.

Passive FTP from Windows

I didn't have any fancy software for testing the client side. All I had was a trustworthy ftp.exe on a Windows PowerShell. However, it operated only on active-FTP -mode, which in my opinion is completely obsoleted. It simply does not work at all with proper firewall setup, so I'd better using passive-FTP -mode. Well, then... how to lure the ancient FTP-client to use it? It wasn't obvious or easy, but luckily somebody else had the same problem and solved it. The solution is to use QUOTE-command for passing the FTP-protocol required PASV, like this:

Connected to 192.168.0.1.
220 FTP Server ready.
User (192.168.0.1:(none)): ftp
331 Anonymous login ok, send your complete email address as your password
Password:
230-
                *** Welcome to this anonymous ftp server! ***

     You are user 1 out of a maximum of 10 authorized anonymous logins.
     The current time here is Wed Jun 05 15:25:31 2013.
     If you experience any problems here, contact : root@localhost


230 Anonymous login ok, restrictions apply.
ftp> quote pasv
227 Entering Passive Mode (192,168,0,1,236,242).

That made passive mode work ok.

Allowing anonymous uploads

The last bit was trickiest, it was almost impossible to give Proftpd what it wanted. To my surprise it wasn't about directory permissions or SElinux. It was simply about configuration issue with <Limit> acting stupidly. Out-of-the-box, the config file apparently allows anonymous uploads. The problem is that it doesn't work. There is a line like this:

<Directory uploads/*>

But it should be like this:

<Directory /uploads>

I don't know why it must be like that, but after tinkering it for a very long time, that turned to be the key to my success. I also changed a <Limit READ> into <Limit LIST READ> to prevent getting directory listings from uploads-directory.

That concluded my setup. Just opening suitable IP-addressses and TCP-ports 20 and 21 made my files fly.

Earlier I wrote about Linux 3.8 SCSI failing to operate under Hyper-V. Finally Microsoft has done something about it. After all, they are the biggest contributor for Linux kernel when it comes to running as a Hyper-V guest.

There is a patch-set fixing number of issues, for example: "Update the storage protocol to the win8 level." This means that they have seriously investigated the problems and fixed them. Also in the patch-set there are some new features, however, which are directed towards datacenters, not nerds like me running a Linux-box in the corner.

Great work from Mr. Srinivasan from Microsoft! Thank you for that.

Earlier I wrote about Hyper-V crashing with BSOD. The entire project was doomed from the beginning. After I managed get the Windows not to crash, all I managed to do is get the Linux installer to hang whenever it attempted to anything major on the hard drive. I configured Hyper-V to provide the hard drive from a .vhdx-file, so I initially suspected that old .vhd-file might help, but no, nothing helped. Any minor operations succeeded, but any sort of normal usage made the Linux to hang.

Symptoms include:

• Console message: "INFO: task jbd2/sda blocked for more than 120 seconds" and instruction to deactivate the warning with:
  echo 0 > /proc/sys/kernel/hung_task_timeout_secs
  Example:
  • http://helpinlinux.com/tag/echo-0-proc-sys-kernel-hung_task_timeout_secs/
• Repeated "Sense Key" -messages in dmesg, example:
  • http://forums.gentoo.org/viewtopic-t-734696-view-next.html?sid=64f39476a9b96703e2a2c998023729b9
• No change in /sys/block/sda/stat:
  • Kernel documentation about block-device stat says that columns 3 and 6 contain the number of sectors read and written.
  • In my hung box, the values don't increase.

I was puzzled about this for a very long time. It took me several hours to bump into Linux-SCSI mailing list's discussion about the issue. There Mr. Olaf Hering describes an issue "storvsc loops with No Sense messages".

Luckily Mr. Hering realized what's going on and made a patch to fix the problem. Unfortunately the fix is not yet pushed into mainstream Linux kernel.

Since I was about to install ArchLinux, I took the trouble of compiling the necessary kernel module of hv_storvsc.ko into following kernel versions:

• 3.8.4, used in installation ISO-image:
  • SHA-1 sum: 74d2a5de73a4c7d963b649eb34b171eba86a268c
• 3.8.6, the version that got installed when I got my install done:
  • SHA-1 sum: 57a4216fc6749085820703d47cd87dcce47b1739
• 3.8.7, the version that it upgraded into when I did a system update:
  • SHA-1 sum: 3f8757ab69c97a6389c7c83a8ef57f16e9caa85d

All of the packages are available for you to download at http://opensource.hqcodeshop.com/ArchLinux/2013.04.01/. Your only trick is to get them replaced into initial RAM-disk -image. I just replaced the original file at /usr/lib/modules and re-ran the mkinitrd-command.

There was an update to my Fedora 17 Linux and among others, I got a new kernel. I didn't notice it at the time, but the reboot ate one of my Ethernet interfaces. There are two NICs on the motherboard, but on top of those, I have an Intel multi-port NIC. So in the end, there are more than your usual dose of ports.

Traffic to one particular LAN didn't function and I started to investigate:

# ifconfig -a
...
rename5: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether 90:e2:ba:1d:33:f1  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xfe7e0000-fe800000

Well... I don't remember which one of my Ethernet-ports was rename5 after installation. Typically they are something like eth0, eth1 and so forth. Modern Linuxes tend to add more complexity with names like p2p2 or so, but I've never seen rename5-type naming.

From that I concluded that udev goofed up something. Fedora 17 does not create the /etc/udev/rules.d/70-persistent-net.rules-file which would solve my problem. Lot of Googling later, I found this page, it contains very useful Perl-script to dig enough system information and report it in udev-compatible format, in my case it yields:

# perl /root/bin/write_udev
...
# Added by 'write_udev' for detected device 'rename5'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="90:e2:ba:1d:33:f1", NAME="rename5"

I created the persistent rule -file and added above into it. I just edited the NAME-part and renamed the interface properly.

Getting the rules to take effect was bit tricky. None of these worked:

udevadm trigger
udevadm control --reload-rules
udevadm trigger --attr-match=address='90:e2:ba:1d:33:f1'
udevadm trigger --sysname rename5

The trick was to get the full path with udevadm trigger --verbose --sysname rename5 -command and use the test-command with the full path:

udevadm test --action=add /sys/devices/pci0000:00/0000:00:06.0/0000:02:00.1/net/rename5

Then I got my new rule to take effect immediately and my interface up and working.

Since most modern Intel CPUs have VT-x in them and Windows 8 Pro has Hyper-V in it, I had to make use of the combo on my old laptop. It has a i5 mobile CPU which makes it on the less powerful end of CPUs. But the simple existence of a possibility of running a Linux on top of a Windows laptop makes me want to try it.

I added the Hyper-V feature into my Windows. I started the Hyper-V Management Console, added a virtual network switch and created a new virtual machine. It booted into Linux installer and the entire Windows crashed with a blue-screen-of-death. WTF?!

After a number of attempts with tweaking the Hyper-V settings, no avail. Every attempt to actually do anything reasonable in the guest system yielded a BSOD. Couple more futile attempts on command-line indicated that it had to have something to do with networking.

Next day I managed to Google into one discussion thread on Microsoft's social forums. There another unfortunate user is experiencing the same symptoms than me. Unlike his Windows 7, on my Windows 8 BSOD there isn't much of a stack trace or any usable information. But I had to try something, so I took an Ethernet-cable and plugged it into my laptop and reconfigured the Hyper-V virtual switch not to use the Intel Centrino 6200 WLAN, but a 1 Gbit/s Realtek port. That did the trick! Apparently some network drivers are not Hyper-V compatible. I don't know how to tell the difference between functioning or not functioning driver, but it is there.

There seems to be some sort of issue with hard drive, but that's an another story ...

The short version is: it does not work.

Having a SSD is feasible in the long run only if there is possibility of operating system informing the drive that an entire drive block (typically 16 KiB) can be erased. openSUSE wiki has following quote in it: "There are three terms often used to interchangeably describe this same basic functionality: Discard, UNMAP, and TRIM." This discard is possible only when there are no operating system sectors (typically 512 bytes) in the drive block.

Here is what I tried to do: I installed two Intel® Solid-State Drive 520 Series drives into my server and tried to see if RedHat-based CentOS 6.4 has enough backported bits & pieces to support RAID-1 /w TRIM.

The drives are fine and kernel TRIM-support is there:

hdparm -I /dev/sda | fgrep -i trim
           *    Data Set Management TRIM supported
           *    Deterministic read after TRIM

My initial attempt had GPT-partition table with a single RAID-partition on it. The command I used is:

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1

I created EXT-4 on top of md0:

mkfs.ext4 /dev/md0

and mounted it:

mount /dev/md0 /mnt/tmp/ -o discard,noatime,nodiratime

The discard-support is in the kernel ok:

mount | fgrep md0
/dev/md0 on /mnt/tmp type ext4 (rw,noatime,nodiratime,discard)

The next thing I tried to do is confirm if TRIM does work either automatically or as a batch job. I followed instructions from this blog entry and tried to run hdparm --fibmap on a newly created file. It failed with a segfault. Apparently that is a known issue, so I ended up packaging the latest version myself. My own RPM-package is available at http://opensource.hqcodeshop.com/CentOS/6%20x86_64/hdparm-9.43-1.el6.x86_64.rpm.

With latest hdparm 9.43 I could verify that FIEMAP (file extent map)  ioctl() does not return correct results on a soft-RAID-1 device. The LBA-sector given by hdparm does not seem to contain the file's data.

My next attempt was to tear down the existing md0 and re-build it using entire drive as RAID-device.

mdadm --stop /dev/md0
mdadm --zero-superblock /dev/sda1
mdadm --zero-superblock /dev/sdb1
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb
mkfs.ext4 /dev/md0
mount /dev/md0 /mnt/tmp/ -o discard,noatime,nodiratime

I ran the same test, but this time hdparm --fibmap informed it failed to determine the drive geometry correctly. A short peek into the source code revealed that current version of hdparm works only with partitions. It tries to load the RAID-partition start LBA even if it is not located on a partition. I made a quick fix for that, it turned out that /sys/block/md0/md/rd0/block has DEVTYPE=disk or DEVTYPE=partition to indicate the base drive type.

Nevertheless, it did not help. fibmap does not return the correct LBA-sector. I loaded a Bash-script to do the manual TRIMming of a SSD-RAID-1, but it only confirmed what I already knew. The LBA-mapping does not work enough to see if discard works or not.

Currently I don't have anything on my RAID-1, I'll have to see if it is possible to get the discard working somehow. A newer Linux might do the trick.

Couple of weeks ago openSUSE-project released their latest desktop-Linux. That is the distro The Man himself, Linus Torvalds had a dispute about security policy of needing a root access to add a new wireless network. He actually said that openSUSE-people are morons. A year ago, they were very defensive and insisted that Mr. Man had it wrong. In reality: no other operating system requires demi-god permissions to do such a trivial task. In 12.3 the morons finally got it, connecting to a new wireless LAN does not require any special permissions.

My hardware for running a desktop-Linux is a very old Apple MacBook. The Mac OS X system info says, that this is a 1,1 hardware, making it pretty much one of the first ever Intel Macs there exists. It has two gigs of RAM and enough hard disk to run pretty much any modern disto. Being a Mac, it also has enough Intel chips in it to fulfill any requirements that modern distros have for 2D or 3D graphics, sound or display. It definitely lacks the I/O or CPU power that any not-6-years-old laptop might have, but it is very suitable for running a desktop-Linux. Mr. Torvalds prefers Apple Airs, but I didn't want to spend that much money on an used computer.

openSUSE install just keeps on improving. I always back up the old computer and do a fresh install, I sure haven't met a working operating system upgrade ever. During installation, all the settings are there if you need the, but the defaults are very good making the entire process flow smoothly. This time there was a glitch when the Atheros WLAN-chip was not auto-detected during install. I had to manually go configure network devices and add a wireless device. At that point the ath5k driver was detected and I got the box connected to The Net for the rest of the install. No other special things there.

After install the first thing I got was the pommed-package. It makes the Apple-keys work in Linux and is definitely needed. My keyboard layout is Finnish, so I also had to compile keyfuzz to get rid of those useless Apple-keys which are called Meta-keys in Linux. I need my alts, and do the following mappings:

 # Map Alt to Meta
458978 125
# Map Meta to Alt
458979 56
# Map Right Meta to Right Alt
458983 100

The final thing to do is to get the iSight-camera working. All it requires is the Apple-copyrighted firmware and it is ready to go. What I did, was to restore my previous file from a backup, but if you need to get one for yourself, there is ift-package or iSight Firmware Tools. With that you can extract the needed bits from Mac OS X device driver and place the resulting file into your Linux. There already is a Linux kernel-module isight_firmware waiting for the file to appear. As a result a brand new Video4Linux-device should appear and you can test it with MPlayer (that breaks couple of dozen copyrights and you need to get from The Net):

mplayer tv:// -tv driver=v4l2:width=320:height=240:device=/dev/video0 -fps 30

The 12.3 runs clearly much faster than 12.2. I have all the KDE4-desktop effects enabled and 12.2 really couldn't manage the 3D-graphics. 12.3 seems to be able to get more juice out of the Intel's 945 GPU. With all the modern software and latest Linux kernel the open-source -guys are finally getting there (with support from Novell, of course). This is actually a very usable desktop for a geek like me.

openSUSE 12.3 get's my seal-of-approval with a bonus thumbs up.