SSHD again… on Lineage OS 17.1

/ alex / 3 Comments

I finally got around to looking into why my rsync automation fails with my new Lineage OS 17.1 device. The old instructions worked like charm. Sshd will start, but the shell user will receive a permission denied after successful authentication.

It turns out that sshd is unhappy with the file ownership or modes for /data. Now I didn’t want to mess with those nor did I want to move the ssh directory to another place so I cheated and told sshd to relax by adding:

StrictModes no

to sshd_config. Probably sshd dislikes that /data is owned by system and not shell nor root – allowing the system user to erase the ssh directory. Seems like one security concept is ruining another…

SSHD on LineageOS 14.1

/ alex / 3 Comments

As I’m currently switching phones I had to revisit the issue of how to get sshd running on a pristine LineageOS install. I decided to collect the steps here as the how-to formerly available on the CM wiki has vanished together with CM itself. Note that some  steps are not incredibly detailed and you really should be aware of the security implications before going ahead with this. Continue reading →

User init.d for CM12.1

/ alex / 40 Comments

For some reason the support for init.d and thereby userinit.d has been removed from CyanogenMod starting with CM12. Unfortunately it is not easy to re-activate the functionality, even more so if you want the change to survive future CM updates.

So I decided to create a trivial app that will simply execute run-parts on the /data/local/userinit.d directory when the phone completes booting to get the good old userinit.d back. To clone the git repository run:

git clone https://lisas.de/~alex/runuserinit.git

Find more details on the repository contents here.

After installation you will have to start RunUserinit once and hit the button.  When asked whether RunUserinit should be allowed to use root privileges accept that and make the setting permanent. Finally sshd will run automatically again, whenever my phone requires a reboot…

RAID Tuning

/ alex / 2 Comments

In order to get maximum performance with the newly setup RAID, I added some udev rules (by placing them in /etc/udev/rules.d/83-md-tune.rules) to increase caching. The file has one entry for each of the involved disks (sdX) to adjust the read-ahead:

ACTION=="add", KERNEL=="sdX", ATTR{bdi/read_ahead_kb}="6144"

And one for the mdX device to adjust the read-ahead as well as the size of the stripe cache:

ACTION=="add", KERNEL=="mdX", ATTR{bdi/read_ahead_kb}="24576", ATTR{md/stripe_cache_size}="8192"

With these settings dd yields the following results when copying a large file:

$ sync; echo 3 > /proc/sys/vm/drop_caches
$ dd if=largefile of=/dev/null bs=16M
20733648232 bytes (21 GB) copied, 60.4592 s, 343 MB/s

Which is nice – and rather pointless as the clients connect with 1G links so they see only one third of that performance at best… Note that the caches will cost extra kernel memory, so if you’re low on RAM you might want to opt for lower cache sizes instead.

Update: I forgot to mention that I also switched from the deadline (which is the default for current Ubuntu systems when installed as servers) to the cfq I/O scheduler as the test results from this article suggest that it is the optimal scheduler for RAID Level 5 no matter whether it is HW or SW controlled.

That time of the decade again – upgrading the RAID

/ alex / Leave a comment

With my Linux SW RAID screaming “grow me!” for quite a while now, I finally brought myself to replace the old 2TB disks with new 6TB ones (RAID 5 with 4 disks). While such a disk-upgrade has to be performed regularly, the frequency is so low that it is hard to remember the details when you finally get to do it again. Unfortunately the “official” method (replace & resync disk-by-disk and then grow the md and the filesystem) as suggested in the Linux RAID Wiki has a few drawbacks:

  • you have no backup in case of failures during the 4 RAID rebuilds
  • you continue to operate on the old filesystem, in my case where the RAID has been full for quite a while you will inherit quite a bit of unnecessary fragmentation – and you cannot switch nor re-tune the filesystem which could make sense for a significantly bigger RAID

Luckily Adrian reminded me of mdadm’s missing parameter, so I could perform this alternate RAID upgrade which I’ll detail below (should come in handy for my next upgrade). Continue reading →

Ruining a perfectly good phone

/ alex / Leave a comment

I had just finished tuning my ownCloud sync setup, when – after years of smooth, unharmed operation despite numerous cement-terminated falls – the better parts of my N9’s gorilla glass finally decide to break apart as the phone left the the bike mount mid-ride. It seems the mount broke due to modifications I made as it kept pressing buttons unintentionally.

glass

Hopefully I will be able to get my hands on a another (retired) N9 next week so I can use  that phone’s display to replace the broken one, which is nice as I wouldn’t know which new phone I would by right now, for some reason the Ubuntu Edge I ordered never shipped.

This way I can continue using SyncEvolution with my little script to sync with ownCloud which uses some MeeGo D-Bus magic to pop-up a short message informing me when the sync is complete. As I failed at ash arithmetic the script feels a little clumsy, but it seems to do what it should.

New scratching device

/ alex / Leave a comment

Today I finally managed to release a new version of terminatorX, which had been broken for quite a while as some changes in either gtk+ or X.org broke the mouse grabbing code. Anyway, just recently I bought a new mouse as the left button of its predecessor was worn out. I decided to go for a high precision device, so I ended up with a Razer laser mouse (Lachesis).

At first I was stunned that the manufacturer actually labels the device as a “weapon of mass destruction”, but hey I use with a piece of software called “terminatorX” – so who am I to judge. Once you get used to the high resolution, the mouse really is a very precise input device – and it does help operating terminatorX quite a bit. The guys from Phoronix gave the mouse (or an earlier version of it) a test and liked it, too, however they were disappointed that Razer does not provide official Linux support. While this still holds true today, I have to say that my experience with the device under Linux has been excellent so far: you plug it in, it works perfectly an you can switch the resolution with the two buttons on top.

Some might be disappointed that there is no fancy user interface allowing you to tune and configure the device – I appreciate the fact that I don’t have to configure anything.

RAID away

/ alex / Leave a comment

During the last week I’ve replaced the disks of my software RAID with larger ones as the capacity was exceeded. While this is theoretically an easy task, I had to learn a few things along the way:

  • Trying to perform such an upgrade on a headless system without console will fail.
  • fdisk silently fails to parse integer values larger than 2147483647.
  • The md superblock is located at the end of the partition/disk that you add to the RAID.
  • If the kernel associates the complete drive to a specific md device instead of the last partition, blocking the use of other partitions for other md devices, resize the last partition to leave some (wasted) space at the end to ensure that the end of the last RAID partition differs from the end of the drive.
  • Some manufactures build ‘green’ disks that constantly unload/load their heads, causing the drive to run out of spec in a very short time. If the manufacturer provides a DOS tool to correct that behavior, a pretty easy solution is to put it onto a bootable CD.
  • This stride calculation script helps to optimize the performance of the filesystem running on a RAID5.
  • Cheap desktop drives might be a bad choice for a RAID, if they break during the first re-sync of the RAID you can try to recover your data by re-creating the RAID – Thanks, Adrian!

Floppies Revisted

/ alex / Leave a comment

Last weekend I upgraded most of my home systems to run Lucid Lynx. From the software point of view everything went pretty smoothly and I am really happy so far. I like the new look which is not surprising as I’ve been using the Dust theme prior to 10.04 and they are not very far apart. The new Ubuntu One integration is an interesting way of trying to make Ubuntu sustainable, I do hope however that it will stay out of my way if I don’t want to use it.

I was close to downloading an album through Ubuntu One until they requested me to register my computer. This is something I do not want to do just to buy an album, so I stopped right there and resorted to the wonderful clamz.

Anyway, during the setup I had to realize that CD-Rs have become the floppies of 2010 – not only capacity-wise but also regarding the reliability. I’ve been having this problem with Ubuntu as well as Fedora setups: When you burn the CD-R just before running the setup on another machine with a different optical drive you will often get read errors at some point in time – typically after being halfway through the setup process. This brings me to my request to the authors of Linux distribution setup procedures: If you cannot read a package from the CD please try downloading it from the Internet after asking the user whether it is OK to do so. I fixed one of the setups with a manual chroot onto the new root fs after modifying the sources.list, on another machine I simply used the mini iso which downloads eveything via the network.