Alien Pastures

My thoughts on Slackware, life and everything

Category: Me (Page 11 of 27)

Running Slackware 14.1 in an OpenVZ VPS

May 20, 2015 / / 27 Comments

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 using this referral link to rent a Slackware 14.1 VPS for yourself 😉

Have fun! Eric

Sourdough Kaiser rolls

May 15, 2015 / / 9 Comments

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!

 

No more cats

May 10, 2015 / / 21 Comments

Peewee_tuin2015_250px

Goodbye dear girl.

She was named “Witje”, Whitey, at birth because her fur was pure white. During her final year, the color went slowly out of her black face-mask. She survived a mysterious illness of which her sister died almost two years ago. She remained fragile after that ordeal. But very cute and adorable still.

She would sleep in my lap in the evening when I was working on your packages, she would eat her morning food on the kitchen counter next to me while I would be preparing my work lunch; she has wanted to be near us all the time. She was a “people” cat until the end. She loved us and we loved her back.

Last week she stopped eating, and three days ago she would no longer drink. She was a strong girl, that she managed to hold on to life for so long. She slowly faded from consciousness to deep sleep until she would no longer respond to our voices and we knew the end was not far off. But while she was awake and still able to walk she wanted to stay with us, never tried to find a quiet spot and wait for the end like her sister.

We let her sleep inbetween us during her final two nights, and now she’s gone and leaves an empty space in this household.

You will be missed.

Using git while working on KDE 5

January 14, 2015 / / 38 Comments

Even though I caught a bad cold (luckily, it was not the flu as I feared at first) I managed to do a lot of prepping for new KDE 5 packages (Frameworks, Plasma, Applications) since last week.

The way I tackled KDE updates in the past, was to update the sources, check the continued need of patches used for prior releases, and then start compiling and checking the build logs for errors – and responding to errors with fixes to the scripts, new patches or even new or updated dependencies. The core of the KDE.SlackBuild framework would remain largely unchanged, and it never took lots of going back and forth to recompile packages and get rid of errors or missing dependencies. KDE 4 has always been very easy to update (well, easy – experience helps a lot, plus the fact that I wrote the KDE.SlackBuild framework and know its ins and outs).

Working with the first test release of KDE 5, last summer, was a bit of a challenge, but I took it like I did with every change to a new release cycle of KDE 4 (4.11 -> 4.12 etc…): finding all available documentation on the available sources, their inter-dependencies as well as their other needs, and reading the comments and patch proposals on the KDE packagers mailing list. Going from KDE 4 to 5 was a heck of a lot more work than I initially anticipated (the hardest part was figuring out the tiering concept of the Frameworks, and of course there was a lot of cursing at the immaturity of the Plasma sources) but I considered that first release for Slackware as nothing more than a play-test. The preview packages were designed not to mess up your existing KDE 4 configuration, and easily un-installable. For me the important thing with this proof of concept was to convince myself that the updates to the KDE.SlackBuild framework were sound and I understood and was able to respond to the new reality of fragmented release cycles.

This last week, I have been targeting a more serious outcome. The upcoming KDE 5 packages for Slackware which I will be releasing sometime later this month, are meant to replace your good old KDE 4 installment, and therefore I need to deliver something that you can work with on a daily basis – a full set of applications in a functional Desktop Environment.

For that reason, I decided to call upon git to guide me through the process of making changes to the build framework. I needed to be able to reproduce my previous build environments in order to back-track after encountering errors or dead ends, and take a fork from there and try again. Putting the whole KDE.SlackBuild tree in a git repository was something I did in advance – see my previous post on KDE 5 – and since then, I have been pushing my changes to the repository continuously.

Definitely, this has saved me from finding myself in a dead end. What sometimes happened was that some application would compile into a package one time, and fail to compile the next iteration. Usually the cause would be an update of a dependency, the introduction of a patch to another package and more of that vague stuff. My git updates enabled me to inspect all updates I had done since a previous compilation attempt, and revert or adapt some of the changes I had made. In some other cases, the changes I could track graphically in the ktown cgit web interface showed cause and effect with more ease than back in the time when I would keep multiple directory trees of past attempts. A time saver!

I am currently compiling the last couple of packages that are part of the Applications. If they succeed, it means that the KDE.SlackBuild is ready and I have a full set of packages. If you ask whether they produce a wonderful Desktop Environment… I do not know yet 🙂 That will be the next step: when all packages are conceptually OK, I will fire up an X session in the virtual machine and see if the stuff I compiled works at all. If I get into a functional KDE 5 environment, that will be cause for celebration. But I expect that I will have issues in the VM (with sddm and/or kwin). If I see failure, I will try installing the packages on a real computer and see how it fares there.

I won’t release any packages until I am fully satisfied, but feel free to tinker with the KDE.SlackBuild in advance.

Eric

Terror does not kill freedom

January 7, 2015 / / 27 Comments

jesuischarlie

Bear with me – I need to make this statement.

The terror attack on a  french satirical magazine, killing 10 of its cartoonists and journalists, is an attack on Freedom of Speech. Only morons are afraid of words and images. Who in his right mind kills journalists unless he is afraid of the truth?

Wars are fought to gain power, for money, for religion. But religious wars are also just a fight for power. The Crusaders in the Western past, and the Jihadists in the Eastern present, there is no difference. Totally convinced of their own beliefs, the beliefs of other people must be repressed at any cost. What else is this but madness?

Terror goes beyond war. Warring factions are both defending their beliefs, however twisted their beliefs are. Terror on the other hand is waged on innocent people. It is meant to put fear in the hearts of the citizen with a long-term goal of establishing some form or repressive regime – even in democratic countries, repression can be achieved. People can be herded like sheep if you keep the truth from them. In Western (Christian) civilization, it was the period of Enlightenment that rid us of the repression of religion. In some islamic countries, this step still needs to be made. The Crusaders are no more (despite the statements of islamic fanatics) – and now Muslims need to raise their voice and fight these people who justify their actions by calling upon Allah but are in fact without faith. Terror does not need a God.

What is the best weapon against terror and false beliefs? The truth! You can live in freedom only if you have access to the truth, and are able to fight falsehoods with proof to the contrary. Do not let yourself be scared away by terror. The terrorist has already lost if you stand up for your freedom and for the truth.

Eric

« Older posts Newer posts »

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑