April 02, 2018 — Team localos

VMWare Workstation is a widely spread type 2 hypervisor. Usually it has a quite good performance, but sometimes it really sucks.

Next to the problem installing/running with the latest kernel versions, where certain modules have to be patched more or less manually, scaling the gui of a hosted Linux VM to fullscreen is not working properly in all cases.

Next to making sure that open-vm-tools and/or open-vm-tools-desktop are installed correctly, it is worth checking:

systemctl status run-vmblock\\x2dfuse.mount

If the service is not running just start it and maybe scaling is working as expected. If this is the reason, than you should dig deeper why the service is failing, since it should be started during system startup.

Tags: vmware, kb

January 13, 2018 — Team localos

Using systemd as init system is a matter of taste, hence we do not want to elaborate this here in more detail.

Systemd-nspawn [1] is a tool which in some kind is like chroot on steroids and provides a lightweight container for, e.g. testing, debugging, development purpose and of course for quick and dirty research stuff.

A tool like mkosi, which "stands for Make Operating System Image, and is a tool for precisely that: generating an OS tree or image that can be booted", can be used to build raw images, for e.g. use with qemu, and some kind of re-usable container based on nspawn.

Situation and Problem

For quite a while there have been several bugs in terms of DNS related problems and nspawn.

After playing around with several configurations of mkosi and porting them to different systems of the same Linux distribution (here: Arch Linux), a strange behavior occurred.

On most systems, everything was working as expected. But on one system, which was on the same patchlevel and has no special configuration, DNS lookups were not possible. The usual networking functionality was fine, but systemd-resolved was crashing all the time without reasonable error and even using an "own" resolv.conf had no effect. Since there was no firewalling in place for this configuration, the problem could only have been somewhere in the DNS part of the system.

Possible more or less Workaround

To cut through the shit and without analyzing why this happened etc., comparing all dns related config files among the different systems/container was not working out, since they were all identical.

A possible "workaround" is adding dns to /etc/nsswitch.conf in order to use an "own" /etc/resolv.conf (the entry resolve can be replaced by this). Disabling systemd-resolved should be done in addition.

[user@blubs ~]$ cat /etc/nsswitch.conf [...] hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname [...] [user@blubs ~]$ sudo systemctl disable systemd-resolved

Since there was no time left for a deep analysis why this was happing on this single system and of course it was only for testing purpose, the shown "workaround" helped to get the research done...even when this is not very satisfying. Maybe something was missed ...


Tags: dns, container, systemd, nspawn, kb, mkosi

January 09, 2018 — Team localos

We know what you are now thinking: "Perl ... oldfashioned and disgusting, not even the author of the code can read his source after two weeks." This might be true, but still Perl is a very powerful scripting language when it comes to quick and dirty (yeah, we know, really dirty) hacks, parsing, administrative task or research.

Perlbrew [1] is a kind of management tool for Perl installations. The power of this nifty tool is, that you can operate different Perl installations in parallel without messing up you system Perl. Thus it makes, e.g. testing a lot easier.

In this post, we'll briefly introduce Perlbrew and how to use it.

Installation and Configuration

Installtion, e.g. arch linux:

[user@blubs ~]$ sudo pacman -S perlbrew [user@blubs ~]$ perlbrew init

For use of, e.g. CPAN [2], installation of some additional stuff is recommended:

[user@blubs ~]$ perlbrew install-patchperl [user@blubs ~]$ perlbrew install-cpanm

Listing all available Perl versions and installing one:

[user@blubs ~]$ perlbrew available perl-5.21.7 perl-5.20.1 perl-5.18.4 perl-5.16.3 perl-5.14.4 perl-5.12.5 perl-5.10.1 perl-5.8.9 perl-5.6.2 perl5.005_04 perl5.004_05 perl5.003_07 [user@blubs ~]$ perlbrew install perl-5.21.7 [...] perl-5.21.7 is successfully installed.

Listing of all already install Perl versions:

The "*" marks the currently used Perl installation by Perlbrew, whereas which is used to find out which Perl is currently used in our environment.

[user@blubs ~]$ which perl /usr/bin/perl [user@blubs ~]$ perlbrew list * perl-5.21.7 [user@blubs ~]$ perlbrew switch perl-5.21.7 [user@blubs ~]$ perlbrew use Currently using perl-5.21.7 [user@blubs ~]$ which perl /home/user/perl5/perlbrew/perls/perl-5.21.7/bin/perl

Using Perlbrew to execute a program with all available (installed) Perl versions:

[user@blubs ~]$ perlbrew exec perl

Revert to system Perl as default:

[user@blubs ~]$ perlbrew switch-off

Using CPANM to update all installed modules:

[user@blubs ~]$ cpanm App::cpanoutdated [user@blubs ~]$ cpan-outdated -p | cpanm

Reinstall Perl modules after changing the Perl version (from 2.22.2 to 2.25.7):

[user@blubs ~]$ perlbrew use perl-2.22.2 [...] [user@blubs ~]$ perlbrew list-modules | perlbrew exec --with perl-5.25.7 cpanm [...]


Need threaded Perl? => NOT recommended !!!

[user@blubs ~]$ perlbrew install perl-5.22.2 -Dusethreads --as threaded-perl-5.22.2

Perlbrew switch is not working permanently?

[user@blubs ~]$ echo 'source ~/perl5/perlbrew/etc/bashrc' >> ~/.bash_profile

Perlbrew installation failed?

Could be some language settings, since some tests are checking against English. One solution might be:

[user@blubs ~]$ sudo echo 'LC_MESSAGES=en_US.UTF-8' >> /etc/locale.conf [user@blubs ~]$ echo 'export LC_MESSAGES=en_US.UTF-8' >> ~/.bashrc


Tags: perl, cpan, kb