I usually prefer VirtualBox for my non-commercial virtualization needs, but since I already had VMware Player 6.0.2 installed on a Windows 8.1 64-bit host I decided go with it for my Slackware Linux 64-bit guest.
To get any kind of performance and functionality on the guest system, it’s necessary to install VMware Tools. This should in theory be as easy as navigating to “Manage” => “Install VMware Tools…” from the Player menu, but in my case this got me nowhere. The expected result was having the guest operating system mounting the VMware Tools installation CD, but that just didn’t work.
After reading through the vmware.log the problem became pretty obvious.
For some reason my VMware Player installation was missing the linux.iso which contains the actual VMware Tools. I have no idea if this is a bug or just a calculated oversight on VMware’s behalf, but either way it’s rather annoying.
After some digging around I found the packages I needed at vmware.com. Be aware that the packages are organized by Player version and build number, so make sure you pick whatever matches your installation.
Download the file named tools-linux-9.6.2.exe.tar and extract the archive. Subsequently run the tools-linux-9.6.2.exe file. This will create the linux.iso containing the VMware tools in your VMware Player installation folder.
With the linux.iso image in place, the “Install VMware Tools” procedure will now work as expected by auto mounting the CD image.
The following commands are for installing VMware Tools on Slackware Linux 14.1 64-bit. The installation require a working build environment, which you’ll have with a full Slackware installation.
cd /media/VMware\ Tools/
tar zxf VMwareTools-9.6.2-1688356.tar.gz -C /tmp/
# change to root, create the expected pam directory and execute the installer
With a Slackware guest you’ll do fine with the default options as suggested by the installer. When the installation completes, log out and restart X and you’re done.
The screenshots below show Slackware booting with VMware tools installed, and using the unity mode which allow guest applications on the host system desktop.
After installing a new wildcard SSL certificate on a BlueOnyx 5106R server, I performed the mandatory system tasks to spot any potential problems. Unfortunately the system was rapidly throwing the following error messages:
dovecot: Fatal: imap-login: No authentication sockets found
dovecot: Fatal: pop3-login: No authentication sockets found
dovecot: Fatal: pop3-login: No authentication sockets found
dovecot: Fatal: pop3-login: No authentication sockets found
This would imply that no customer on this server would be getting their mail any time soon, which would make for some unpleasant calls.
When querying the dovecot service for its status, it simply returned dovecot is stopped.
Trying to start dovecot returned the message:
Starting Dovecot Imap: Fatal: listen(0.0.0.0, 143) failed: Address already in use
To identify any process already running on port 143 we would use the lsof (list open files) command with the “-i” option to list IP sockets:
lsof -i :143
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
dovecot 26827 root 5u IPv4 15401200 0t0 TCP *:imap (LISTEN)
imap-logi 28964 dovecot 4u IPv4 15401200 0t0 TCP *:imap (LISTEN)
It turned out another dovecot instance was still running. Then it was simply a matter of killing the dovecot process in question and starting up dovecot anew with the following commands:
kill -9 26827
When you install a SSL certificate on a BlueOnyx system, it will automatically copy and configure the certificate for all services (apache, sendmail, dovecot) and restart these services to load the new configuration. It seems the reload of the dovecot server failed even though the configuration and certificate got updated correctly. I’ve never experienced this “bug” on newer versions of BlueOnyx, only with the trusted old 5106R edition. Well, maybe I should not have been renewing SSL certificates during peak business hours.
I’ve not been doing any serious distro hopping since 2008 and figured it was about time to see if there is anything new under the sun. Enter Arch Linux, a highly touted and matured distribution with a development model and philosophy I can appreciate. Honestly though, writing a review of Arch is somewhat daft as each installation will depend upon your own choices and preferences.
What is Arch Linux
The following paragraph from the official Arch Linux site aptly describes the distribution in a few sentences:
Arch Linux is an independently developed, i686/x86-64 general purpose GNU/Linux distribution versatile enough to suit any role. Development focuses on simplicity, minimalism, and code elegance. Arch is installed as a minimal base system, configured by the user upon which their own ideal environment is assembled by installing only what is required or desired for their unique purposes. GUI configuration utilities are not officially provided, and most system configuration is performed from the shell and a text editor.
So you wanna be an Arch Linux user
Are you tired of doing a fresh install every six months?
Are you tired of spending time removing unwanted packages and dependencies?
Do you want the opportunity to assemble your own preferred desktop or server environment?
Do you prefer doing system configuration from the shell instead of being limited by GUI tools?
Do you want fine tuned control of (almost) every aspect of your system?
Do you want to have the latest software available from upstream without distribution specific customization?
If the answer to those questions are “yes please” then by all means, welcome to Arch Linux. Arch might be tailored for the more advanced Linux user by design, but getting a working desktop installation up and running is not that challenging if you take advantage of the Arch wiki.
Arch Linux x86_64 has been installed and reviewed on the following system: Asus G73SW
Intel Core i7 2630QM
8 GB RAM
Geforce GTX 460M 1.5GB GDDR5 VRAM
HD 500GB 7200rpm
Display 17.3″ Full HD (1920×1080)
After booting the installation media you’ll get an immediate feel for what kind of distribution Arch is. There is no graphical installer, nor any ncurses based alternative. However, since there is no predefined Arch system, there really is no reason for having an installer pushing you down a fixed path.
As for issues during installation, my only challenge was encountered while trying to set up wireless networking. When trying to detect my wireless interface which I used to know as wlan0, I was instead introduced to wlp3s0. This was to be my first ever interaction with the “new” systemd/udev (as in predictable network interface names) and after some initial confusion I realized that the naming scheme makes sense. Speaking of systemd, when it comes to assembling the Linux system of your dreams, those dreams must include systemd as your init system.
Anyhow, the actual installation process isn’t that different from other distributions. You’ll recognize the steps involved but you get a few more choices and opportunities to customize or mess up. On the bright side though, when you’re done you might have picked up some new skills and confidence along the way. On the other hand, if you’re left with the feeling that this type of installation process should have been left behind in the 1990s then this is where you should get off the bus. Some installation screens from a test run in VirtualBox are shown below:
Installing Arch took about an hour in my case but if you know what you’re doing you could probably cut that time in half.
I’m also pleased to report that Grub2 was able to pick up my Windows 7 installation without any manual interference.
Finally! welcome to your new and shiny…. shell. This is where you get to assemble your desired system on top of a clean and minimal Arch base. Each user will battle through an epic journey of discovery and…. sorry too many hours of Skyrim.
I decided to go for the KDE desktop and proceeded to install and configure the X Window System among other required tasks before downloading a bulky 715MB of KDE 4.12.3.
Some hours and a few breaks later I had assembled the desktop I always wanted, which in retrospect was more or less identical to the system I wiped out to install Arch.
I also spent some time going through the systemd documentation as it’s a crucial skill to administer your new system. There are some valid arguments and concerns against systemd, but from a practical (Linux user) point of view, it’s probably not as bad as one would think. Given a choice I would still have picked SysV every time, but alas no choice was offered.
Meet pacman, the no nonsense package manager as described by the ArchWiki:
The pacman package manager is one of the major distinguishing features of Arch Linux. It combines a simple binary package format with an easy-to-use build system. The goal of pacman is to make it possible to easily manage packages, whether they are from the official repositories or the user’s own builds.
In my experience pacman is flexible in terms of configuration and fast, and by that I mean really fast. The syntax is short and simple with single letter arguments which might not be a big deal, but it’s a nice touch as you’ll be spending a lot of time with pacman. I’ve had no issues to speak of with pacman and since I’m not really big on automated package management I was keeping a close watch.
Arch can be turned into whatever you want it to be. As a desktop system powering my Asus laptop I have few complaints. The only issue I had to solve was the fact that my GTX 460 GPU quickly overheated and got as high as 90 °C when watching multimedia content. After some probing I headed straight to the ArchWiki which told me the issue was caused by Nvidia’s PowerMizer constantly changing the GPU’s clock frequency (and that was indeed the case). Other than that, no hardware issues whatsoever and laptop functions like suspend and resume just works.
Arch is extremely fast and responsive and I have yet to experience a single application crash. This is highly unusual for me in my KDE endeavors so I’m both surprised and impressed with how well the system has performed. Having access to the latest (mostly) unmodified software releases from upstream is exciting. The new 3.13.7 kernel was being delivered by pacman a day after its announcement at kernel.org.
You’ll also enjoy fine grained control through simple configuration files without any intrusive multifunctional graphical configuration tools, which makes Arch transparent and predictable, qualities I appreciate in an operating system.
I got few complaints against Arch at this point but I’m curious to see if any major updates like an upgraded desktop environment will result in unforeseen breakage. In my experience it’s when the system comes undone you’ll get first hand knowledge as to whether the developers are true to their KISS philosophy or not.
The Arch way, which should be a blueprint for software development in my opinion.
The Arch community. The ArchWiki has become my main resource for everything Linux, no matter what distribution I’m using.
Rolling releases. Never grow old. Never die. It’s fun to be an Arch Linux distro.
Bleeding edge. Get all the new toys before most other distributions. A good way to get familiar with new technology.
Bleeding edge. It’s called bleeding for a reason, some challenges regarding the stability of your system have to be expected.
Not a suitable choice for production servers in my opinion.
The Arch User Repository may contain build scripts of questionable quality.
No choice of init system.
Wrapping it up
By choosing Arch Linux you’ll get a distribution that is all about you. Assemble the system you always wanted on a lightening fast Arch base and enjoy a vast collection of current software. Obviously this approach is not everybody’s cup of tea, but if the Arch way makes sense to you, then get ready for a fun and rewarding learning experience.