Main menu:

Sponsoring

Please consider a small donation:

 

 

Or you can donate bitcoin:

 

Thanks to TekLinks in Birmingham, AL, for providing colocation and bandwidth.

Page Rank

Fame

FOSS Force Best Blog--2013 Award

Recent posts

Recent comments

About this blog

I am Eric Hameleers, and this is where I think out loud.
More about me.

Search

My Favourites

Slackware

Calendar

May 2015
M T W T F S S
« Apr    
 123
45678910
11121314151617
18192021222324
25262728293031

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages

Meta

Running Slackware 14.1 in an OpenVZ VPS

Last year I rented a OpenVZ based Virtual Private Server (VPS) for a discount price. I needed a new host to experiment with. My other Internet machine, the taper server (a QEMU virtual machine donated to me by a Slackware fan) is not meant for tinkering. It is running the Slackware Documentation Project, and I like to keep that online 24/7.

OpenVZ is a container-based virtualization service for Linux which has widespread use among hosting providers, because it is easy to setup and manage. I did not have prior experience with it, but the pricetag was compelling and I thought, I would find a way to install Slackware on it eventually.

OpenVZ works with an OS “template” which is basically a tarball of a directory tree that holds a complete working OS installation. When renting such a VPS, the usual default choices for your OpenVZ template are Ubuntu, CentOS or Debian. There is a repository of community-supplied templates, but the most recent Slackware template is a very bare-bones Slackware 13.37. So I settled for CentOS 6 in order to see how an OpenVZ based VPS was different from a fully virtualized solution like a QEMU VM and use that experience to create a working Slackware template.

I meant to create a new template based on Slackware 14.1 and the hosting provider was willing to co-operate once I had a tarball ready. However, I had a few doubts which I expressed in a Google+ post. The reactions to that post did not help feeling more confident, and I was convinced that I needed access to the local console of the VPS to be able to debug any boot-up issues that would prevent the SSH daemon from starting (thus preventing remote access). In an unfortunate chain of events, the hosting provider switched from SolusVM to an inhouse developed control panel exactly at that time, and providing (serial) console access was not a first priority for them. So I decided to wait patiently until a serial console was added. Actually, their Control Panel is a nice piece of work, and some months ago they finally made a local console available as well. But at that time I was consumed with getting Plasma 5 packages production ready. And time slipped away silently.

Last week, I decided to pick up my old initiative, dusted off the template creation script that I half-finished last year and using that script I created a first version of a 64bit Slackware 14.1 template. HostUS, my provider, set me up with a VPS for free based on that tarball I gave them so that I could test and debug the template without harming my paid-for VPS. I was very grateful for that, because it turned out the VPS was not booting. An OpenVZ container is limited in certain ways that the Slackware boot scripts do not expect. For instance, the VPS is running on the host kernel (“uname -a” returns: Linux brin 2.6.32-042stab094.7 #1 SMP Wed Oct 22 12:43:21 MSK 2014 x86_64 Intel(R) Xeon(R) CPU L5639 @ 2.13GHz GenuineIntel GNU/Linux). The filesystem is writable on boot; there is no hardware clock; there is no eth0; etcetera.

It took me a little while to get rid of the boot-up bugs and I definitely needed the access to the VPS console to stop it from dropping to the emergency shell, but then I ended with a Slackware VPS that booted out of the box.

I created a template for 32bit Slackware 14.1 as well, provided HostUS with both template tarballs and a Slackware logo bitmap, and then they added Slackware 14.1 (32bit and 64bit) as choices for VPS installation:

Slackware_OpenVZ_2

Hooray! Support was amazing, no silly questions asked, these guys are friendly and cooperative. Minutes after adding Slackware as an option in their VPS control panel, they tweeted:

Slackware_OpenVZ

I guess they were as excited as I am about the new offering :-) I told them last year that I wanted to run Slackware on their VPS and that I intended to host a new Slackware mirror there but was a bit afraid of exceeding my monthly bandwidth quota; taper serves more than 5 TB per month to you guys, which equals to my monthly quota limit at HostUS. They immediately responded and (without me having asked) increased my monthly bandwidth TEN-fold. For free. That shows the level of their support I guess.

Some technicalities: the script that created these templates is available on slackware.com. It builds a minimal installation of Slackware 14.1 (89 packages in total). That includes gcc because I do not take a Linux installation seriously which does not ship with a C compiler. This will occupy some 365 MB on your VPS disk once it is running. You could trim this down quite a bit more I guess, but there is a difference between minimal and barebones. My definition of minimal is that you should get a lot of useful tools on a console-based Slackware out of the box, not something that will boot and not much more.

This OpenVZ template comes with slackpkg pre-configured, using the generic URL “mirrors.slackware.com” so that your packages will always be downloaded from a mirror near you. OpenVZ is a bit peculiar in the sense that it knows a little bit about how Linux distros are being configured. So the OpenVZ control panel is the place where you configure the hostname, IP address and root password of your VPS. In order to make the Slackware installation internet-aware out of the box, I added two Google DNS IP addresses to its “/etc/resolv.conf” file. The result? Once provisioned, the VPS starts fast and mere seconds after booting I was able to login as root to my new machine.

I will use the long Pentecost weekend to setup some initial services and seed a Slackware mirror. And you can consider the option of renting a Slackware 14.1 VPS for yourself 😉 No, I am not getting paid when you do that.

Have fun! Eric

Stable channel for Chromium hits 43

chromium_iconBuilding on my experiences with chromium-dev (the development channel of the Chromium browser which is currently at version 44), I have made similar changes to my latest package for the chromium browser and its widevine and pepperflash plugins.

This means that I have said goodbye to the single configuration file (/etc/default/chromium) and switched to a configuration directory, which is “/etc/chromium/” for the chromium package. Each package (Chromium as well as any plugin or extension) can add its own configuration file to that directory. The new packages for chromium, chromium-pepperflash-plugin and chromium-widevine-plugin are now using this new setup.

I made one other change: I have applied a patch taken from an Ubuntu PPA. That patch is based on a blog post which explains how to enable VAAPI (aka hardware video decoding) on Linux. The chromium sources disable this functionality by default if you are not compiling for ChromeOS. Tell me your experiences with playback of H.264 video!

The new chromium packages have the version number 43.0.2357.65. The first release of the “43” series brings a total of 37 published security fixes, and here are the CVE’s:

  • [$16337][474029] High CVE-2015-1252: Sandbox escape in Chrome. Credit to anonymous.
  • [$7500][464552] High CVE-2015-1253: Cross-origin bypass in DOM. Credit to anonymous.
  • [$3000][444927] High CVE-2015-1254: Cross-origin bypass in Editing. Credit to Armin Razmdjou.
  • [$3000][473253] High CVE-2015-1255: Use-after-free in WebAudio. Credit to Khalil Zhani.
  • [$2000][478549] High CVE-2015-1256: Use-after-free in SVG. Credit to Atte Kettunen of OUSPG.
  • [481015] High CVE-2015-1251: Use-after-free in Speech. Credit to SkyLined working with HP’s Zero Day Initiative
  • [$1500][468519] Medium CVE-2015-1257: Container-overflow in SVG. Credit to miaubiz.
  • [$1000][450939] Medium CVE-2015-1258: Negative-size parameter in Libvpx. Credit to cloudfuzzer
  • [$1000][468167] Medium CVE-2015-1259: Uninitialized value in PDFium. Credit to Atte Kettunen of OUSPG
  • [$1000][474370] Medium CVE-2015-1260: Use-after-free in WebRTC. Credit to Khalil Zhani.
  • [$500][466351] Medium CVE-2015-1261: URL bar spoofing. Credit to Juho Nurminen.
  • [$500][476647] Medium CVE-2015-1262: Uninitialized value in Blink. Credit to miaubiz.
  • [$500][479162] Low CVE-2015-1263: Insecure download of spellcheck dictionary. Credit to Mike Ruddy.
  • [$500][481015] Low CVE-2015-1264: Cross-site scripting in bookmarks. Credit to K0r3Ph1L.

Get my chromium packages in one of the usual locations:

Change the URL a bit to get the widevine-plugin and pepperflash-plugin packages.

Have fun! Eric

Sourdough Kaiser rolls

I am enjoying a long weekend at home – Ascension day is a national holiday and both my employer (IBM) and my customer (ASML) closed their offices on the friday following it.

So I decided to experiment a bit with the bread I bake. The usual routine is that I bake three breads (two sourdough and one with commercial yeast) to get us through the week without having to rely on factory bread from the supermarket. This weekend, I wanted to have a go at Kaiser rolls, also known in Austria as Kaisersemmel or Handsemmel. A piece of traditional artisanal baking skill in Austria, but here you only get the factory made stuff.

I wanted to hand-make these traditional rolls according to the old ways. Traditionally, the leaven (natural yeast) would be provided to the baker by the local brewery, but that is not a viable solution nowadays. But we have sourdough, which should have some semblance to the old sour mash from the brewery.

So I set out to compare recipes and shaping techniques. There’s lots of recipes to be found actually, and the conclusion with all these white bun recipes is – you just add what you like. In my case, I wanted to go easy on the butter and sugar so that my wife would not have any reservations in sampling the finished product. But afterwards she admitted she would have eaten them whatever the content, they were that tasty.

Here is the recipe I ended up with. It was enough to create 11 rolls of roughly 75g each.

The evening preceding the day you want to eat the rolls, you mix the following ingredients into a rough mass:

  • 100g sourdough starter (100% hydration meaning it’s 50g flour, 50g water)
  • 450g AP flour (of which 200g was Type 00 strong flour)
  • 5g sugar
  • 60g full-fat milk
  • 200g water (cold)

Leave the rough dough to rest for 25 minutes (the flour is allowed to absorb the moisture, this is called “autolyse”) and then add:

  • 20g butter (soft, hand-warm)
  • 7g salt

Knead the dough by hand during 6 minutes until it is silky smooth. Then return the dough ball to a container and cover with clingfilm.
Leave the container on the kitchen counter for a bulk fermentation during the night. Do not place the container in the fridge. In 8 hours, the dough will double or almost triple in size.

Next morning, dump the dough onto your work area and gently push the air out with your flattened hands.
Using a dough cutter divide the mass into pieces of 75 – 80 grams and shape them into balls, creating surface tension. Leave these to rest for 15 minutes.
Gently flatten the balls of dough, creating circular disks. Dip them into some rye flour so that they are coated with a thin layer. This will prevent them sticking together. Leave to rest for another 15 minutes.

Now, shape the Kaiser rolls. There are several techniques for doing this, but I used what I assume is the traditional way. Here is a nice video of shaping a Kaiser roll. No rubber stamp, no knots in the dough. The real stuff!
Place the shaped rolls face-down on an oven tray which has been dusted with rye flour. This is needed so that the folds do not disappear while the dough is proofing. Cover them with a linen cloth or clingfilm. Leave them there for a second proofing, until doubled in size (will take something like 2 hours).
Heat up your oven in time, set the temperature to 200C. Place a low metal baking tray on the oven floor.
Bake the rolls for 20-25 minutes. Introduce steam during the first 10 minutes by pouring a cup of cold water into the tray on the oven floor and quickly closing the oven door, and vent the oven after 10 minutes.
They are ready when the edges are golden brown. When you tap the bottom of a roll with your fingers it should give a “hollow” sound. Leave them to cool for a bit before you cut into them. If you started early in the morning, the rolls will be ready for lunch.

This is how mine came out of the oven:

Kaiserrolls_small

There’s no doubt to it: these sourdough rolls are the best I ever tasted. They have a nice crispy crust and the folds opened up nicely while baking.

You’ll also note that there is one roll that does not look like a Kaiser roll. I also tried my luck at a braiding a knot and that was easier than shaping a Kaiser roll. I need to practice the shaping process. It was a lot of fun, but 9 rolls does not give you a lot of experience. Definitely something I will do again shortly!

 

New chromium-dev package and plugins

chromium_iconI have been working on some changes for the chromium package, and what’s better than to first test those changes on a Chromium Development release?

I have not really been happy with the choice I made to have a single configuration file (/etc/default/chromium) which would then have to be re-written by any plugins that you would install. For instance, the PepperFlash plugin modifies that file so that Chromium learns of the pathname and version of that plugin when it starts. Unfortunately, some people would accidentally wipe those modifications with every update to the Chromium main package (the “/etc/default/chromium.new” file would overwrite the “/etc/default/chromium” file if you were not paying attention).

So what I did was change the single configuration file into a configuration directory, which is “/etc/chromium-dev/” for the Chromium Dev package. Each package (Chromium as well as any plugin or extension) can add its own configuration file to that directory. As an example of how that works, I have created packages for chromium-dev, chromium-dev-pepperflash-plugin and chromium-dev-widevine-plugin that use this new setup. Those are Slackware packages  for -current only by the way – when a new version of Chromium Stable is released  I will also add this new configuration setup and then the packages will be released for Slackware 14.1 as well.

What else is there to say about my chromium-dev packages? Chromium-dev is the development release of the browser (there’s also a “beta” channel but I don’t care about that too much). Testing the development release from time to time is preparing me well in advance for major (or subtle) changes in the compilation process and functionality, so that when the stable channel jumps to a higher major release it won’t take me long to come up with a set of packages.

The new chromium-dev packages have the version number 44.0.2398.0. So what changed with this new major release 44 compared to the previous 43 (or even the stable 42)? One important change is that it is no longer necessary to extract the Widevine CDM library from an official Google Chrome RPM in order to compile the Open Source Widevine adapter library which is the piece of code that interfaces between the browser and the closed-source Content Decryption Module. Therefore even the Open Source purists should be at peace now with the new process. If you do want to use Widevine CDM, for instance when you want to stream Netflix in your Chromium browser, you simply install my widevine-plugin package (the version it reports will be 1.4.8.823). The browser itself will not be tainted.

The PepperFlash plugin package which I added as well (first time for my Chromium Dev releases) has a change as well, compared to the package for Chromium Stable. The PepperFlash directory is installed to “/usr/lib64/chromium-dev/” instead of “/usr/lib64/” (it’s “lib” for 32bit Slackware of course) so that the pepperflash-plugin package’s files will not clash with the pepperflash-plugin for Chromium Stable. The plugin for Chromium Dev reports itself as version 18.0.0.114 by the way. This version is not even listed yet on Adobe’s Flash test page. I assume that this too, is a development version.

Get my Chromium Development packages in one of the usual locations:

Change the URL a bit to get the widevine-plugin and pepperflash-plugin packages.

Eric

May ’15 security updates for Adobe Flash

adobe_flash_8s600x600_2Just before going to bed with a belly full of good red wine and lamb roast, I noticed the new Adobe Flash security bulletin: apsb15-09.

I could not ignore that, so I prepared Slackware packages for you to address this new bulletin. As usual, the packages offer a Flash plugin for the chromium browser (PPAPI) and mozilla-compatible browsers (NPAPI).

If you have pipelight installed, you should run “pipelight-plugin –update” as root to get the latest MS Windows-based Flash installed automatically the next time the browser loads the pipelight plugin (at the time of writing, there is no pipelight update available but that should change in the coming days).

The updated Slackware package for chromium-pepperflash-plugin has version 17.0.0.188. The updated flashplayer-plugin has version 11.2.202.460.

Download locations:

Eric