Pedro's blog

Varnish has been updated to version 4 in Arch (for a while now, actually…). I use varnish mostly to speed up my wordpress instances. Unfortunately however, I couldn’t find any good VCL sample for wordpress and varnish 4. It’s funny that varnish’s website still has a few samples of VCLs for wordpress and varnish 3. It’s beyond me why a company would not want to help people to use their latest products (although they provide a pretty good guide to update VCL 3.0 to VCL 4.0 for those willing to dig deeper).but in any case. I updated an old VCL file I had to VCL 4.0 and I’m sharing it with you.

By no means I’m a varnish expert and there may be bugs in this VCL, but feel free to use it and please let me know if you find anything wrong with it.

# /etc/varnish/default.vcl
vcl 4.0;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
    .connect_timeout = 600s;
    .first_byte_timeout = 600s;
    .between_bytes_timeout = 600s;
}

acl purge {
        "localhost";
        "192.168.0.0"/16;
}

sub vcl_recv {
        if (req.method == "PURGE") {
                if (!client.ip ~ purge) {
                        return(synth(405,"Not allowed."));
                }
                return (purge);
        }
}

sub vcl_hit {
        if (req.method == "PURGE") {
                if (!client.ip ~ purge) {
                        return(synth(403, "Not allowed."));
                }
                ban("req.http.host == " + req.http.host +
                      " && req.url == " + req.url);
                return(synth(200, "Purged"));        }
}

sub vcl_miss {
        if (req.method == "PURGE") {
                if (!client.ip ~ purge) {
                        return(synth(403, "Not allowed."));
                }
                ban("req.http.host == " + req.http.host +
                      " && req.url == " + req.url);
                return(synth(200, "Purged"));        }
}

Matlab is a wonderful program. It really is pretty neat. You can program really quickly and get results fast. BUT it has a few things that make it annoying to work with sometimes.

One of my beefs is that it preloads some libraries in it. The problem is that those libraries are not actual libraries, but rather pointers to specific libraries. So MATLAB’s libstdc++.so.5 could require libstdc++.so.5.11, in which case you are doomed to keep looking for the problem until you figure your distribution might not even package this particular version of libstdc++.so.5. Thankfully since switching to ArchLinux, I haven’t had much problem finding particular packages (even if I have to use AUR). The reason not to use the system’s libstdc++.so.5 is beyond me.

Anyways, I was having problem with MATLAB giving me:

/usr/lib/libharfbuzz.so.0: undefined symbol: FT_Face_GetCharVariantIndex

I traced the problem to MATLAB linking to and older version of libfreetype. The solution was quite simple. All I had to do was manually tell MATLAB to use the “right” libfreetype with:

LD_PRELOAD=/usr/lib/libfreetype.so.6 matlab

To make this automated, I added an alias to my bashrc:

alias matlab="LD_PRELOAD=/usr/lib/libfreetype.so.6 matlab"

Now, all works properly. GG

After installation, there are a few things that are not necessary, but might improve your experience with your C720. Below, I’ve posted a few that I’m using. Feel free to suggest other in the comments section.

Install yaourt

yaourt is my favourite AUR wrapper. This is not specific to the C720, but I thought it might be useful nonetheless. I’ve tried to make the installation as simple as possible. Before installing yaourt, the package-query package and the base-devel metapackage must be installed. These commands build and install both.

pacman -S --needed base-devel
cd /tmp
mkdir builds
cd builds
wget https://aur.archlinux.org/packages/pa/package-query/PKGBUILD
makepkg -si
wget https://aur.archlinux.org/packages/ya/yaourt/PKGBUILD
makepkg -si

Improve WiFi and Bluetooth performance

/etc/modprobe.d/ath9k.conf
options ath9k btcoex_enable=1 bt_ant_diversity=1

Enable some GPU power/performance settings

/etc/modprobe.d/i915.conf
options i915 enable_fbc=1 lvds_downclock=1 lvds_use_ssc=1
options i915 enable_psr=1 nuclear_pageflip=1 use_mmio_flip=1

UPDATE: Follow archwiki’s instructions for latest/best settings.

Enable energy savings

# pacman -S tlp
# systemctl enable tlp
# systemctl start tlp

Install the linux-chromebook package

Install zramswap

The amount of RAM in the C720 is pretty limited (specially if you are running Firefox and GNOME3, as I am). Zramswap creates a ramdisk and compresses it using a fast (de)compression algorithm and uses it as swap. This is usually faster than reading from a HDD. In the case of the C720, the seek delays of the SSD are much smaller, but this allows you to skip a swap partition all together (preventing writes into the SSD).

yaourt -S zramswap

In kernel 3.15 and later, you can change the default compression algorithm lzo to lz4. While it’s not clear how much faster is lz4 in real life situations, it’s expected to be faster than lzo (at the cost of a slightly lower compression ratio and larger memory usage during compression). I’ve written a patch for the zramctrl script, it’s available here: patch

Reduce Swappiness

Another thing to help reduce the use of swap is reducing the swappiness.

/etc/sysctl.d/99-sysctl.conf
vm.swappiness=1
vm.vfs_cache_pressure=50

gl;hf

Download the ISO

Apparently, only the 2013.10 version is working for 64bit installations. Other versions will reboot instead of boot. This bug was reported here. Since most C720 versions only have 2GB, one might ask why should they use the 64bit version. I’m in no way an expert in this area, but my recollection is that x86_64 enables the use of an extra set of general purpose registers in the CPU. On the flipside, the use of 64bit pointers causes the memory usage to go up a little (which can be remedied with the use of x32-ABI, but it seems like distributors didn’t have much interest in it). I don’t have numbers to compare and don’t want to create any flamewars in my blog. To be fully honest, I think the differences are probably insignificant.

After downloading, you should extract the contents of the ISO to a USB drive. For UEFI boot you’d need to rename the drive to ARCH_201310, but thankfully BIOS boots are a little more forgiving.

Booting into Arch

If you set the boot flags, you should be good to go. If you didn’t, you’ll have to press Ctrl+L to boot (L for “legacy boot”). Once in the menu, press Tab to edit the entry and add mem=1536m to the line, this forces the live-USB to use 1536MiB of RAM, since the autodetection seems not to be working for the C720.

Now, you should be able to boot into Arch. First thing I’ve done was partitioning the SSD using:

cgdisk /dev/sda

I’ve created a bios_grub partition (about 1MiB) in the beginning of the drive, so I could do bios boot on this GPT-partitioned drive (you could potentially create a MBR partition table, but I haven’t tried this possibility). The rest of the SSD was made into my main partition.
I’ve made the btrfs partition using:

mkfs.btrfs -l 16k /dev/sda2

And mounted it with

mount /dev/sda2 /mnt -o rw,noatime,compress=lzo,ssd,discard,space_cache,autodefrag,ssd_spread

I’ve chosen btrfs because of the transparent compression, which increases the space I have available (not by much, since lzo’s compression rate is only about 2 or less) and because it increases the I/O performance (again, only by a little). Some might prefer ext4, and I don’t blame them, it’s very stable and the default filesystem in most distributions for a reason. I also wanted to try something a little bit more cutting-edge.

Connect to your WiFi router with:

wifi-menu

Before you can pacstrap the system, you have to upgrade the keyring (since the 2013-10 iso is pretty old and it’s keys have expired), the command is:

pacman -Sy archlinux-keyring

(I haven’t tested this myself, but was suggested in the bbs here)

Now you can proceed to install the system to the SSD:

pacstrap /mnt base

Generate your filesystem table:

genfstab -U /mnt >> /mnt/etc/fstab

Chroot into the system:

arch-chroot /mnt

Add a hostname to your computer:

echo mynewhostname > /etc/hostname

Adjust the timezone information:

ln -s /usr/share/zoneinfo/America/Detroit /etc/localtime

Create the ramdisk:

mkinitcpio -p linux

Set a root password:

passwd

Install GRUB:

pacman -S grub
grub-install --target=i386-pc /dev/sda
grub-mkconfig -o /boot/grub/grub.cfg

You can should install “dialog” so that you can use wifi-menu next time you boot:

pacman -S dialog

Now you can exit the chroot, unmount the disk and reboot:

exit
umount -R /mnt
reboot

That’s it (sort of), the C720 should reboot into Arch. After this, the configuration will vary greatly between the different purposes you have your machine (DE, services/daemons, users, etc). On the next (and last) post about the C720, I’ll add some tweaks that I’ve used in my install.

GL;HF

As much of this blog, I’m writing this as a way of documenting the process I’ve done to install it, so that if I have to do it again, I can do it easily. Feel free to ask me questions in the comments, but I can’t really guarantee anything. Before we start, I want to clarify that I don’t have much against Chrome OS and that I’ll be voiding the warranty (but you can easily skip this if you want to).

Most of the information I got was from the excellent ArchWiki and the C720 thread on Arch’s bbs. Some other information I might have gotten elsewhere, please forgive if I didn’t credit something. Shoot me an e-mail and I’ll add the credits as soon as possible.

About Chrome OS

First of all, I want to tell everyone. This is not a post about how horrible ChromeOS is or anything like this. I actually LIKE ChromeOS in terms of UI/UX. This comic kinda captures the spirit of it. We use browsers for everything now. Even many “native” applications now have decent (or even good) webpage versions (Skype -> Google Talk, LibreOffice/MS Office -> Google Docs, etc). Although I dislike the idea of Google having access to all my (or anyone’s) files, I think the implementation is actually pretty good.

The OS can be used by both people that are comfortable with a computer (in which case I assume they’ll be using a browser most of the time) and people that don’t really like computers (since it abstracts a lot of “computery” stuff). In many cases, when someone asks me what kind of computer should they give their parents or grandparents, my answer is that maybe the best choice is not a computer.

I am actually pretty sad about the “desktop’s decadence” in the recent years. I really like traditional-mouse-and-keyboard computers, but the fact is that most people are not willing to “learn” how to use Linux (or Windows or anything). Some people I know don’t even like anything that involves “right-clicking”. As much as it pains me to say: tablets have been doing a much better job at this. Anyways, ChromeOS is actually good, but I need some more freedom and power. That was the reason all-along to get the C720, but as far as ChromeOS went, I actually thought it was a delightful OS.

Why might you want to void your warranty

Until you void your warranty (or the warranty expires) the device is covered by a company. This company in a sense is “responsible” for your device and, in a sense, it still “owns” it. Voiding your warranty gives you full ownership of your device. However, don’t be foolish, voiding warranties means you also take full responsibility for whatever happens next. Don’t do it unless you are either capable of fixing your device or aware of the consequences of breaking it (like having to buy a new one etc).

Now that we’ve cleared that, let’s get started.

Upgrade SSD + Removing the write-protect screw

If you are installing Arch on your laptop, you might want to upgrade the SSD. The initial 16GiB were ok for ChromeOS, but if I want to install programs locally and store larger amounts of files, I need a larger storage. Initially, I thought of getting a SDXC card or similar, but the 128GiB SSD only cost me 99USD, which is well under 1$/GiB, which I think is a pretty good price for a SSD, specially given the fact that the form factor is quite new and it is quite comparable in price with a SD card, but safer, more permanent, elegant and offering much higher perfomance than a SD.

Upgrading the SSD has been shown in several different blogs (like here, here, here, here and here), so I won’t be going into too much detail about it. The procedure is quite simple, create a recovery disk, remove the screws in the bottom (this is the bit that voids your warranty), pop the lid open, unscrew the old SSD, install the new SSD and screw it in, put the back lid again and put the screws back.

One small difference in my case is that I removed the write-protect screw (#7 in the image in this wiki). This allows us to set some flags in the C720 ROM to boot in BIOS mode automatically. After setting the flags, you should put the screw back to protect the ROM. (Actually, that’s what should happen in theory. My experience seems to show that writing the ROM with the screw in just corrupts the ROM, instead of preventing writes… Be careful while flashing the ROM, BAD BAD stuff can happen).

Enable developer mode, SeaBIOS and gbb flags

After following the instruction for upgrading the SSD, you should have a fully restored ChromeOS. We’ll have to restore ChromeOS once more. But fear not, it’ll be the last time. In this section we’ll be enabling BIOS boot and setting it as default on ChromeOS:

• Press and hold the Esc+Refresh keys, then press the Power button
• Press Ctrl+D, this will erase your user data and enable developer mode.
• Press Ctrl+D at the white boot splash screen to enter Chrome OS.

As soon as you enter Chrome OS, you’ll now have access to the TTY and some extra functionality.

• First, press Ctrl+Alt+F2 to go into TTY.
• Use chronos as the username, it should not prompt you for a password.
• Become superuser with sudo bash
• In bash, run:

# crossystem dev_boot_usb=1 dev_boot_legacy=1
# set_gbb_flags.sh 0×489

Reinstall the write-protect screw and Install Arch

Now you can reinstall the write-protect screw and proceed to install Arch. Good luck (;

Oh boy, recently a lot has been talked about OpenSSL’s bug known as heartbleed. The issue was caused by the “heartbeat” mechanism not checking bounds. I won’t go too much into the details, but you can read more about it in the previous link. A short explanation is also available on xkcd.

Anyway, while I don’t believe anyone with anything better to do would be trying to break into a server with very little sensitive information, it’s always good to play safe. So I’m regenerating my SSL certificates just in case. Also, I previously used 1024-bit certificates, so I’m using this opportunity to bump my certificates to 2048-bit. First of all, create a folder that only the your server user can read (in my case, the user is “http” and the server nginx):

# mkdir /etc/nginx/ssl
# chown http:http /etc/nginx/ssl
# chmod 0700 /etc/nginx/ssl
# cd /etc/nginx/ssl

Start by generating the key, this will ask you for a passphrase which is necessary to start nginx and to generate the csr:

# openssl genrsa -des3 -out mykey.key 2048

Now generate the CSR (certificate signing request):

# openssl req -new -key mykey.key -out mycert.csr

The passphrase you create will be necessary whenever you want to start the server. This adds security, but might prevent nginx from starting in the case of a power failure or other reboots. If you want to remove the passphrase:

# openssl rsa -in mykey.key -out mykey.key

Sign the certificate and now the certificate will be “good to go”. You can change the number of days the certificate is valid for, I’ve set 365, which seems like a reasonable number:

# openssl x509 -req -days 365 -in mycert.csr -signkey mykey.key -out mycert.crt

Now all you need is to configure your server to use the SSL certificate. In my case, I’m using it to secure an owncloud installation running on nginx:

server {
        listen 443 ssl spdy;
(...)
        ssl_certificate /etc/nginx/ssl/mycert.crt;
        ssl_certificate_key /etc/nginx/ssl/mykey.key;
(...)
}

A self-signed certificate will make the browser complain the first time you visit it, but subsequent visits should work fine. Happy hosting! (;
Sources:
A similar guide for CentOS/RHEL and Apache
Akadia’s guide for self-signed certificates
A similar guide for Ubuntu 12.04 + nginx