Cobra's bits (Posts about virtual-machines)

Virtual Arch for the VPN

Cobra — Sun, 05 Nov 2023 14:02:40 GMT

Connecting to a VPN is usually like picking up your device and tossing it into another network, figuratively speaking. All of your network activities – such as browsing, fetching private mails, chatting with a friend on IRC – will take place within this virtual network, or not at all: in its most secure configuration, access to resources on the local area network will not be possible. I thus prefer to separate my real private network activities from those in the virtual private network by using a virtual guest dedicated to nothing but connecting to the latter and doing whatever I need to do within the guest system.

In the present case, I'm fortunate that my employer now uses a gateway whose VPN client (Palo Altos's GlobalProtect) runs even on an up-to-date Arch installation. So my choice for the guest system is an out-of-the-box ArchBang that comes with i3 as (tiling) Window manager. It installs in 10 min, comes with everything I need, and fits in 5 GB of space. I spent another 5 min modifying the wallpaper and the conky instance – my idea was to have a visual indication in form of my IP whether or not I'm connected to the VPN.

After configuring everything to my liking, it turned out that I shouldn't have bothered – our IT guys configured the VPN with split tunneling enabled. This basically means that only traffic destined to the remote location passes through the encrypted tunnel, while everything else uses the standard gateway. Supposedly less secure, but certainly much more convenient. Excellent choice! I'm sure I'll find another use for my virtual Arch – be it for testing or online banking.

Tallyho

Cobra — Sat, 19 Sep 2020 14:41:52 GMT

Recently, I've had a hard time with my virtual machines (VMs). With the update to kernel 5.8, starting any of them caused my entire system to lockup so that even the magic sysrequest didn't help. The problem persisted from August 15th to September 9th when it was finally solved by virtualbox 6.2.14. After the update, I immediately tended to my VMs to update them.

CentOS: 0.012 packages – check.
Debian: 123 packages – check.
Archlinux: 123456 packages – ch... wait a sec, login incorrect after reboot?

My physical installations of Arch didn't exhibit such an attitude, which I thus suspected to be related to the virtualbox-guest addons of Arch (since the virtual CentOS and Debian were also behaving properly). I was wrong.

PAM had been updated to version 1.4, dropping support for the long deprecated tally module. My virtual Arch, however, is from 2009, and my /etc/pam.d/login indeed referenced this module. But there was also a login.pacnew that would have corrected this issue if I only would have bothered to handle 'pacnew' files as advised:

“These files require manual intervention from the user and it is good practice to handle them right after every package upgrade or removal. If left unhandled, improper configurations can result in improper function of the software or the software being unable to run altogether.”

I hate being in the corner with the criminally stupid, but there I am. I'll try the pacman hook in the future.

TCAD station, part I

Cobra — Mon, 01 May 2017 12:00:17 GMT

You certainly know the old tune on the lack of “professional” software for Linux, with “professional“ being usually an implicit synonym for Microsoft Office and the Adobe Creative Suite. For a scientist or engineer, people joining this chorus appear to be misinformed and to be motivated by ideology rather than reality. In technically oriented fields, software is in fact mostly cross-platform or even developed primarily for Linux. That's true in particular for multithreaded software with non-negligible demands for computational resources and five- to six-figures price tags. Examples include Maxwell solvers, multiphysics solutions, and TCAD packages.

Commercial software for Linux is usually certified only for one of the enterprise Linux distributions, namely, Redhat and SUSE Enterprise Linux (RHEL and SLES). Some of this products turn out to be actually distribution-agnostic, meaning that they run without any problems also on, e.g., Debian. But in many other cases, the software only runs and even only installs on systems with the distribution it was developed for. I've learned that the hard way, wasting an entire day trying to get the commercial finite-difference time-domain simulation package FDTD solutions to work under Debian Stretch. In the end, we've used Meep instead.

I've vowed that this wouldn't happen again, and since we are in the process to evaluate some selected TCAD solutions (all of which are certified for RHEL only), it seemed to be wise to set up a test server running CentOS (a binary-compatible clone of RHEL). The TCAD software requires a graphical interface, but I did not intend to perform a standard installation, which results in a complete Gnome desktop suitable for a workstation rather than a compute server. For servers, I prefer the installation to be as lightweight as possible. For example, I usually install the tiling window manager wmii if a graphical interface is required or desirable on a server.

Since I'm not at all familiar with CentOS and the available software, I decided to first set up a virtual machine to look for possible pitfalls. For the base instalIation, I've downloaded and installed the minimal ISO which I've then, upon first boot, updated with:

yum update
grub2-mkconfig -o /boot/grub2/grub.cfg

Why the reconfiguration of grub? Well, the update installed a new kernel, but CentOS did not automatically update the grub configuration file. Weird, but true.

CentOS offers three tiling window manager, two of which I'm familiar with: i3 and xmonad (never even heard about spectrwm). On second thought, however, I realized that it may be a better idea to install a more conventional desktop to give the TCAD testers an environment they feel comfortable with. XFCE seemed to be a reasonable compromise and can be installed with these few steps:

yum install epel-release -y
yum groupinstall "X Window System" -y
yum groupinstall "Xfce" -y
systemctl get-default
systemctl set-default graphical.target
systemctl isolate graphical.target

The last step seamlessly starts the X Window system and thus catapults one into the graphical desktop. Slick! Now we only want a resolution higher than the oldfashioned 1024x768 offered by the default (VESA) driver. In other words, we need to install the Virtualbox guest additions:

yum install dkms
yum groupinstall "Development Tools"

To install the guest additions, I first inserted the 'Guest Additions CD Image' in the 'Devices' menu and then downloaded the image. After the download, I mounted the image and compiled the guest additions:

mkdir /media/vboxadditions
mount /dev/cdrom /media/vboxadditions
cd `/media/vboxadditions <file:///home/cobra/Documents/media/vboxadditions>`_
./VBoxLinuxAdditions.run
reboot

Still no higher display resolutions available? The script in this thread enabled me to activate the 'Auto-resize Guest Display' option in the 'View' menu, which finally allowed me to use the desired full HD resolution (on a WQHD monitor):

#!/bin/bash
Diplay_Name=`xrandr | grep connected | cut -d' ' -f1`
Display_Spec=`cvt 1920 1080 | grep Modeline | cut -d' ' -f2 |cut -d '"' -f2`
Display_Params=`cvt 1920 1080 | grep Modeline | cut -d' ' -f2-18 | sed s/'"'//g`

xrandr --newmode $Display_Params
xrandr --addmode $Diplay_Name $Display_Spec
xrandr --output $Diplay_Name --mode $Display_Spec

In the second part of this post, I will write about the installation of CentOS on the physical server we have reserved for the evaluation stage. From the (largely) pleasant experience with the virtual machine, I expected this task to be entirely straightforward. I thought to be done in an hour, including configuration of user accounts as well as the sshd and vncd daemons for remote access. Well ... it took more than one day. Stay tuned. 😉

Goodbye Windows

Cobra — Sun, 16 Mar 2014 11:11:15 GMT

Because of my depressing experiences when trying to connect to our Cisco-based VPN under Linux, I've so far used a virtual Windows XP and the IPSec 'vpnclient' from Cisco. Since the end of Windows XP is nigh, I had to find an alternative.

In the meantime, we have enabled SSL support on our Cisco ASA to allow users running a 64 bit Windows 7 to connect to the VPN using the Cisco 'AnyConnect' SSL client. Of course, acquiring a Windows license just to connect to the VPN was not an option for me. I would either be able using open-source software or not be able to connect at all.

I've quickly found that 'openconnect' is held in high regard in the interwebs, and decided to give it a try on a virtual Debian Jessie:

su -
wajig install openconnect
openconnect -c certificate_bundle.p12 https://gateway.de

Bang, connected, and all services work.

Unbelievable! Finally!

I've found that the direct use of the PKCS#12 certificate bundle works with Debian Jessie, but not with Arch, for which the certificate bundle has to be split into the x509 certificate and the pk8 private key in pem format using openssl. But that's perfectly ok, since I anyway value the convenience of connecting to the VPN with a virtual machine without the necessity to disrupt my standard connection to the internet via QSC.

No post-MBR gap

Cobra — Sun, 16 Jun 2013 14:38:09 GMT

A recent update of Archlinux moved all binaries to /usr/bin. The update was smooth on my main system, but for my 4 years old virtual Arch, a 'pacman -Qqo /bin /sbin /usr/sbin | pacman -Qm -' revealed that grub 0.97 required a fix.

I could have installed grub-legacy from the AUR, but that idea struck me as a rather backwardish one. Since I learned to really like syslinux from my main system, I installed this modern bootloader instead. Upon a reboot I was greeted with "no operating system found". Hm.

I soon learned that the problem originated from the fact that my /boot partition starts with sector 1. Well, just like fdisk partitioned a few years ago. Now, I could have converted the partition to GPT, but I didn't like that idea too much either. Instead, I tried grub2, only to get rebuffed once more: "no post-MBR gap; embedding won't be possible". Aarghhh!

Finally, it was the Gentoo Wiki which told me what to do: "If you really want blocklists, use --force." A 'grub-install /dev/sda --force' later, my virtual Arch is up-to-date and thus again as new and shiny as in the beginning.

Adiposity

Cobra — Sun, 06 Mar 2011 13:31:03 GMT

A Windows XP I've installed in VirtualBox perhaps two years ago grew so much in size by updates alone that the 5 GB system partition became too small. Since my virtual Windows 7 broke from installing the Cisco 64 bit vpnclient and had to be deleted, I needed to act. No, deleting the files left from updates isn't a good idea. I did that after installing the .Net framework, and now I neither can update the framework, nor can I uninstall or reinstall that crap.

How to expand the disk in VirtualBox? First, create a new harddisk with the desired size (I've chosen three times the size of the old one) in the "Storage" menu of VirtualBox. Next, clone your old disk by the following command:

VBoxManage clonehd –existing old_hard_disk.vdi new_hard_disk.vdi

Select the new disk under "Storage", and resize the partitions. I used gparted to do that since the Windows tools are either not able to do that or too difficult to use (gparted was also my tool of choice prior to installing Windows 7, which is unable to create more than 3 logical partitions).

I know that I'm a complete idiot when it comes to Windows, but how can anybody not be, if one's mind is based on rational grounds? It all seems so horribly twisted and bizarre.

Small and smaller

Cobra — Sat, 19 Dec 2009 17:29:48 GMT

For those of you who are interested in a really slim window manager: try dwm, the small brother of wmii.

90 kB, and thats already with dmenu, which brings dwm very close in functionality to its big brother. 😊

By the way: I've solved these mysterious crashes of Arch when returning from wmii (or dwm) to the console.

Reason: a faulty xorg.conf.
Precise origin: not yet known.
Speculation: Not possible. Insufficient data.

Data are acquired as we speak, Captain. )

Update: after checking all possible combinations of modules, here the final and disappointing result: I haven't got a clue. I'd say that my previous xorg.conf contained a non-printable character, but vim would show me (and a 'ga' over the character would even show the code). Let's say it was an anomaly and nobodys fault. A cosmic particle...or, an X-file case, if you prefer that. 😄

This is the end of Opera

Cobra — Sat, 21 Nov 2009 09:38:33 GMT

I've predicted previously that Javascript perfomance will be a decisive criterion for the acceptance of browsers in the near future. I erred in the time frame for the future, however.

Javascript performance is of relevance here and now. Yesterday, I went shopping for my new gaming rig. Most online shops heavily rely on Javascript for their PC configurators -- as an example, see the configurator of Alternate. When configuring a system, I often switch between the actual configurator, the product overview and the users ratings. Using Opera 10.01 on my Core 2 Duo E6600 with 8 GB of RAM, the resulting browsing experience was unbearably slow.

I then switched to Midori and could hardly believe my eyes ... with or without Javascript seems to make no difference for this browser. See, that's how it's done! Yippie-ka-yay, Opera 😄

Midori 0.2.0	native	586.4 ms +/- 17.2%
Safari 4.0.4 531.21.10	Windows 7, VirtualBox 3.0.12	613.0 ms +/- 57.7%
Iron 3.0.197.0	Windows XP SP3, VirtualBox 3.0.12	819.4 ms +/- 16.3%
Midori 0.2.1	ArchLinux 2.6.31 x86_64, VirtualBox 3.0.12	880.8 ms +/- 4.5%
FF 3.7 alpha	native	1580.4ms +/- 3.5%
Konqueror 4.3	native	2214.2 ms +/- 2.8%
FF 3.5.5	native	2274.8ms +/- 2.9%
FF 3.7 alpha	ArchLinux 2.6.31 x86_64, VirtualBox 3.0.12	3579.2 +/- 5.9%
Opera 10.10 1893	native	4428.8ms +/- 4.3%
Opera 10.01 1844	Windows 7, VirtualBox 3.0.12	4761.4 ms +/- 9.6%
Opera 10.01 1844	Windows NT 4 SP 6, VMWare Player 2.5.3	5015.0 ms +/- 1.4%
FF 3.5.5 (Arch build)	ArchLinux 2.6.31 x86_64, VirtualBox 3.0.12	5828.0 ms +/- 16.1%
FF 3.5.4 (Suse build)	OpenSuse 11.2, VirtualBox 3.0.12	5872.0 ms +/- 7.4%
~~Opera 10.01 4682~~	~~native~~	~~6229.8ms +/- 4.7%~~
FF 3.5.5 (Mandriva build)	native	6238.4ms +/- 1.1%
IE 8.0 6001.18702	Windows XP SP3, VirtualBox 3.0.12	6418.4 ms +/- 6.9%
IE 8.0 7100	Windows 7, VirtualBox 3.0.12	6999.8 ms +/- 14.4%
Seamonkey 1.1.17	native	11945.2 ms +/- 12.0%
IE 6.0	Windows NT 4 SP6, VMWare Player 2.5.3	62990.4 ms +/- 1.8%

Native means: Mandriva 2010.0 x86_64 on a Core 2 Duo E6600 and 8 GB RAM. For comparison: Chromium 4.0.252 on my Mini (Ubuntu Karmic on an Atom N270) needs 2216.8 ms to complete the test. Faster than all non-Webkit browsers on my main machine ...

Webkit-based browsers are by far the fastest, beating Gecko by a factor of three and Presto almost by an order of magnitude. This performance difference is quite perceptible in everyday applications as outlined above. What's more: in comparison to my last browser snapshot, both Webkit and Gecko improved their Javascript performance. Opera, instead, is getting worse.

For years Opera talked about a JIT for Javascript in the 'next' version. Now, Opera is the only browser (besides IE) to not have this feature. "The fastest browser on earth" is a long time ago ...

On a sidenote: Mandriva seems to provide particularly slow builds (see FF 3.5.5, Mandriva build). That, of course, makes me particularly happy. 😞

Update: I forgot to switch off adsweep (wich costs a lot of perfomance, since it is a Javascript 😉 ) in the native Opera test. The new values are consistent with those obtained in the virtual machine, but don't change any of the statements above.

As always

Cobra — Sat, 03 Oct 2009 19:54:37 GMT

What will create trouble when updating to a new system? Non-FOSS. You can take that to the bank.

If it's not the greatest vpn client of all time, its vmware, the greatest virtualization solution on the planet *cough*.

This time, vmplayer 2.5.3 actually starts up despite kernel 2.6.31. But the guest system is unable to grab the mouse.

Turns out that the version of gtk is "wrong", and the solution is to tell the player to use its own (why isn't that the default anyway?):

export VMWARE_USE_SHIPPED_GTK=force

Add that to /usr/bin/vmplayer, and you're done. Until the next kernel update.

Update: Just as I said, till the next kernel update. Just did one, and vmware can't find the kernel headers anymore. The solution is simple: comment the above line, compile the modules, comment it out again.

Consequence

Cobra — Sat, 11 Jul 2009 17:26:28 GMT

Remember the Cisco vpnclient?

urpme vpnclient-4.8.01.0640-3mdv2009.0 dkms-vpnclient-4.8.01.0640-3mdv2009.0

Oh yes.

And on the other hand:

If you think about it, that's the only way to go. Gutter to gutter, trash to trash.

PS: After one day of usage, I actually like it. My main system is unaffected, and runs the "normal" connection. In parallel and a VirtualBox, Windows offers the encrypted connection to my office. Not bad at all.