Thursday, January 28, 2016

Creating a Shared Partition Between Ubuntu and Scientific Linux

Now that I've removed Windows from my desktop computer at work, and installed Scientific Linux in its place (note: it was, Centos 7.2 with LVM partitions, but now it is Scientific Linux 7.1 with standard partitions), I decided I needed a partition that could be shared between the two distros for large user data.

For example, I have 12 Gigabytes in my Music directory, and a number of VirtualBox hard disk images (at 20 to 30 Gigabytes each) that I would like to access from both OS's.  So my plan is to create a new partition which I will mount on /media/share on both Ubuntu and Scientific Linux.  Then I'll make symbolic links from /home/[username]/Music to /media/share/Music from each home directory.

Before I could create a new partition, I needed to shrink one of my existing partitions to free up space.  Here is how the partitions looked when I started:
and here is what they looked like after shrinking /dev/sda3, growing /dev/sda4 and inserting /dev/sda7 into the new space inside it:
I made the change by booting my computer from an Ubuntu 14.04 Live DVD and running GParted. It took about 20 minutes to shrink my home partition, but it worked without incident.

The next step is to add a mount for the new /dev/sda7 partition.  It's been several years since I played around with mounting partitions, but I still remembered that it involved editing the /etc/fstab file and adding the device and the mount point.  So I loaded my /etc/fstab file and noticed something had changed since I last looked at it:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda2 during installation
UUID=4ae26245-fe59-40d2-a380-2c2de57b652b /               ext4    errors=remount-ro 0       1
# /home was on /dev/sda3 during installation
UUID=5c4e86f6-1d94-4eab-9931-5d3aa29e1583 /home           ext4    defaults        0       2
# swap was on /dev/sda1 during installation
UUID=bba8f235-d8b0-4131-9a3e-ec286c3b3837 none            swap    sw              0       0
I was completely unfamiliar with UUID, and had been expecting to see device names (like /dev/sda3 etc.) instead.  I bit of searching led me to several links:
Running $ sudo blkid gave me this:
 /dev/sda1: UUID="b70d7272-e47f-426a-a979-5417bb2f7801" TYPE="swap"
/dev/sda2: UUID="4ae26245-fe59-40d2-a380-2c2de57b652b" TYPE="ext4"
/dev/sda3: UUID="5c4e86f6-1d94-4eab-9931-5d3aa29e1583" TYPE="ext4"
/dev/sda5: UUID="76f8dd02-3671-49ba-b75a-da6d8bb65b19" TYPE="ext4"
/dev/sda6: UUID="e7e58de9-a748-4500-b300-ae1ca10f2056" TYPE="xfs"
/dev/sda7: UUID="44244888-7000-49bf-8ac8-2c32e2f73eb5" TYPE="ext4" 
which I used to add the following line to /etc/fstab:
UUID=44244888-7000-49bf-8ac8-2c32e2f73eb5 /media/share ext4 defaults
and then ran:
$ sudo mkdir /media/share
$ sudo mount -a
which mounted /dev/sda7 on /media/share. Next I moved all my music files to /media/share/Music, deleted the Music directory in my home directory, and replaced it with a symbolic link (note: run from my user's home directory):
$ ln -s /media/share/Music Music
I started Rhythmbox and it worked as if nothing had changed.

Rebooting into Scientific Linux, I added the same line to /etc/fstab and ran the same mkdir and mount commands, then removed my still empty Music directory, made the same sym link, and voila, I had access to all my music from Scientific Linux (after installing Rhythmbox, that is).

For VirtualBox VM sharing, things are a bit more complicated.  Ubuntu makes installing VirtualBox trivial, since it is in the main repository, but on Ubuntu 14.04 version 4.3 is what you get.  On Scientific Linux I installed version 5.0 using the instruction from an earlier post.

Fearing there might be meta-data conflicts between the two versions, but feeling confident the virtual hard disk image files (.vdi) could be shared between them without conflict (since I regularly copy these files back and forth between distros without problems), I did the following:
  1. On the Ubuntu side, I moved my entire VirtualBox VMs directory from my home directory to /media/share and sym linked to it as I had done with the Music directory.
  2. On the Scientific Linux side, I kept VirtualBox VMs in my home directory, using sym links only for the virtual disk image files.  For example, from inside $HOME/VirtualBox VMs/Server1 I ran:
    $ ln -s /media/share/VirtualBox\ VMs/Server1/Server1.vdi Server1.vdi
This worked nicely.  Just for fun, I ran yum update on Server1 launched from VirtualBox 5.0 on Scientific Linux, then rebooted into Ubuntu 14.04 and relaunched Server1 from there, seeing changes I had made.

Finally, after noticing that VirtualBox-4.3 was available for Scientific Linux 7.1, I ran # yum remove VirtualBox-5.0 and then # yum install VirtualBox-4.3, made the VirtualBox VMs directory in my home directory a sym link to /media/share/VirtualBox VMs and quickly added all the VMs back.  Now even the VMs with the VirtualBox extensions installed (for full screen GUI and auto mouse capture) work on both OS's.

Saturday, January 23, 2016

Thonny - A Python IDE for Beginners

I received an email a few days back from Aivar Annamaa about a Python IDE for beginners called Thonny.

The YouTube video introducing the IDE looks promising, so I am jumping at the opportunity to take a look at it.

Thonny is in the Python Package Index, so it can be easily installed (and installed by user without system admin privileges) using pip.  In a previous post I documented installing Python 3.4, which is required to before what follows.

First I want to get pip3.  Since it is not yet in the main Centos repository, I installed it with (note: run $ sudo -i and then # exit before running this command in the same terminal emulator so as not to be prompted for a sudo password):
$ curl https://bootstrap.pypa.io/get-pip.py | sudo python3.4
I want to install Thonny inside the user's local directory, so I installed it with:
$ pip3 install --user thonny
This installs the thonny egg in $HOME/.local/lib/python3.4/site-packages (creating the needed lib/python3.4/site-package directory if it is not already there), and installs a shell script to launch it in $HOME/.local/bin. When I tried running thonny from the command prompt, I got an error message: ImportError: No module named 'tkinter'. So I needed to install tkinter:
$ sudo yum install python34-tkinter
after which thonny launched.  It complained that it couldn't find rope or jedi, however, so I installed those locally as well:
$ pip3 install --user rope
$ pip3 install --user jedi
Since thonny is a GUI IDE, I wanted a GUI launcher for it.  To get one I created a Thonny.desktop file based on the one I found here, with the following contents:
[Desktop Entry]
Type=Application
Name=Thonny
GenericName=Python IDE
Exec=/home/[username]/.local/bin/thonny %F
Comment=Python IDE for beginners
Icon=/home/[username]/.local/lib/python3.4/site-packages/thonny/res/thonny.ico
Terminal=false
Categories=Application;Education;Development;Debugger;IDE;
MimeType=text/x-python;
Actions=Edit;

[Desktop Action Edit]
Exec=/home/[username]/.local/bin/thonny %F
Name=Edit with Thonny
and placed it in my /home/[username]/.local/applications directory (Note: replace [username] with your actual username).

Here is a screenshot of Thonny running hello.py:
My next task will be to go through some beginner Python lessons using Thonny to see how it feels.

Thursday, January 21, 2016

Resizing a Logical Volume on Centos 7.2 with system-storage-manager

My desktop machine at work was setup to dual-boot Ubuntu 14.04 and Windows 10.  Deciding I needed Centos 7.2 much more than Windows 10, I installed Centos into the space that had been occupied by Windows.

Using the Centos 7 installation DVD, I followed the partitioning proceedure that I can now almost do in my sleep, creating the following partitions:
  1. 500 MiB /boot with an xfs file system on an actual partition
  2. 1024 MiB swap
  3. 20 GiB / with an xfs file system on a logical volume
  4. /home with whatever space is left with an ext4 file system on a logical volume
I said I could almost do this in my sleep. I made one huge mistake.  Instead of making the /home partition with GiB, I made it with MiB!  I didn't notice this until I got a warning about the home partition running out of space.  I had spent a lot of time already installing and then updating the system.  I didn't want to go through that again.

So I used this mistake as an opportunity to explore resizing my logical volume.  It took a bit of poking around, but eventually I found this webpage, from which I did the following:
  1. Logged into the GUI as root so that /home would not be in use.
  2. Ran yum install system-storage-manager to install ssm.
  3. Ran ssm list to see my volumes.
  4. Ran ssm resize -s [size] [volume] to make /home larger.
It worked like a charm, and now I'm logged back in with my regular user with a few hundered gigabytes of space in my /home partition.

Wednesday, January 20, 2016

Setting Up a Home Centos 7 Server

I have a little Zotac Zbox server at home that I've been running for several years with Ubuntu server.  It has a 500 GiB hard drive, 2 Gigs of RAM, and a dual-core 1.8 GHz Atom processor.  It is small, quiet (silent, actually) and sits unobtrusively on a shelf. It is truly a wonderful little device, and I've made good use of it for learning server administration in a safe and inexpensive way. DynDNS provides me with a domain name that I can use to access it from the outside world since it is sitting at home on my Comcast connection.

Since I am preparing for the RHCSA this Spring, I figured I should install Centos 7 on it. To do the install, I needed to connect it to a monitor, keyboard, and mouse. I setup the following LVM partitions:
/boot 500 MiB xfs
swap 1 GiB
/ 20 GiB xfs
/var 197 GiB ext4
/home 241 GiB ext4
and did a minimal install, then ran:
# yum update
# yum install net-tools
# yum install vim
The next task was to configure it to have a static IP address, after which I could unplug it from the monitor, keyboard, and mouse and put it back on the shelf. To set a static IP address, I used this and this web pages as guides.  I ran:
# vi /etc/sysconfig/network-scripts/ifcfg-ens32
and changed:
TYPE="Ethernet"
BOOTPROTO="dhcp"
DEFROUTE="yes"
PEERDNS="yes"
PEERROUTES="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_PEERDNS="yes"
IPV6_PEERROUTES="yes"
IPV6_FAILURE_FATAL="no"
NAME="ens32"
UUID="aed7d424-7293-4db7-8a89-c25f77557bf9"
DEVICE="ens32"
ONBOOT="yes"
to:
TYPE="Ethernet"
BOOTPROTO="none"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
NAME="ens32"
UUID="aed7d424-7293-4db7-8a89-c25f77557bf9"
DEVICE="ens32"
ONBOOT="yes"
HWADDR="00:01:2e:bd:15:e3"
IPADDR="10.0.0.254"
PREFIX="24"
GATEWAY="10.0.0.1"
DNS="10.0.0.1"
IPV6_PEERDNS="yes"
IPV6_PEERROUTES="yes"

I tested that I could connect to the new server from outside, and it worked, but it actually took more than 2 minutes to connect.  I'll have to look into why that is.

 

Symlinking python3 to python3.4


Next I installed Python 3.4 (since what use is a computer without Python 3?) using the steps I described in my previous post.

To be able to type python3 instead of python3.4 to launch this version of Python, I made a symbolic link.  First I took a look at the .bash_profile file, which contained the following:
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/.local/bin:$HOME/bin

export PATH
.local/bin is being added to the PATH, but I didn't yet have this directory, so I made it and then changed directories to it:
$ mkdir .local$ mkdir .local/bin
$ cd .local/bin
from here I ran:
$ which python3.4
to find out where it was located, and then made the symlink:
$ ln -s /usr/bin/python3.4 python3
after which I could launch Python 3 they way I wanted, as the following screenshot shows:


Saturday, January 16, 2016

Installing Python 3.4 on Scientific Linux

I  do a lot with Python in my cs program, and as an active member of the python community, I heeded the BDFL's request years ago to make the switch to Python 3.

So it was a bit disconcerting to find that Python 3 was not installed on Centos 7.  Fortunately, after a few false starts, I found that it is now very easy to add it:
# sudo yum install epel-release
# sudo yum install python34
You need to start this with
# python3.4
rather than
# python3
No matter, this will provide a nice opportunity to talk about symlinks with my students (note: I document how to make this symbolic link in my next post).

I decided to install Scientific Linux on the last available machine in our lab, just so we can have a look at it.

Here it is with python 3.4 running:
From a first look it seems to very compatible with Centos 7 / RHEL.  Our textbook mentions that it would be OK to use it to prepare for the RHCSA.  Now we have a box running it to play with.

Thursday, January 14, 2016

Installing VirtualBox on Centos 7

Last post I described how to install VirtualBox Guest Additions on Centos 7.  Since we are now running Centos 7 as the host operating system on several machines in our IT lab, we will also need to install VirtualBox itself on these machines, so that we can run VMs for testing that are hosted on the Centos boxes.

Here is how to do that (Note: be sure you are running the latest kernel before you start, and thanks to this post):
# cd /etc/yum.repos.d/
# wget http://download.virtualbox.org/virtualbox/rpm/rhel/virtualbox.repo
# yum install epel-release
# yum install dkms
# yum install VirtualBox-5.0
VirtualBox will now appear in the Applications -> System Tools menu.

Before individual users can create VMs, they have to be added to the vboxusers group with:
# usermod -a -G vboxusers [user name]
 Users added to the group can now start VirtualBox and install VMs.

Wednesday, January 13, 2016

Adding Virtualbox Guest Additions and Google Chrome to Centos 7

One effective strategy in preparing for the RHCSA certification is to spend as much time in a Centos environment as one can doing the kinds of things one does each day with a computer.  I'm not prepared yet to give up my Ubuntu desktop, but I've found VirtualBox to be a fine way to switch OSs with ease.

We will be using VirtualBox VMs extensively in our Linux System Administration course, and we have installed two by default, one with a Gnome GUI and one without a GUI.  I want to be able to run the VM with a GUI in full screen mode on my 2560 x 1600 resolution monitor instead of the 1024 x 768 resolution that runs in the VM by default.  I would also like to be able to switch mouse control in and out of the VM without having to press the right control key.  Both of these wishes are granted by the VirtualBox Guest Additions.

As this post explains, all you have to do to get your Centos 7.2 VM ready for Guest Additions is to run:
# yum install epel-release
# yum install dkms
After that, select:
Devices -> Insert Guest Additions CD image...
from the menu of the window containing your running VM, and click on the buttons to download and then mount the image.  After doing that, I changed to the directory where the CD image was mounted with:
# cd /run/media/user/VBOXADDITIONS-$.3.34_104062
and ran:
# ./VBoxLinuxAdditions.run
and then:
# shutdown -r now
After that, I had everything I wanted.  I can resize the window, or maximize it (with Right Control & F keys).  When not full screen, mouse control is transfered to the VM whenever the mouse pointer enters its window and back to the host OS whenever the mouse pointer leaves its window.

In fact, beginning with this sentence, I editing this blog entry from my full screen Centos 7.2 desktop:

Installing Chrome


Then next task to setup a fully functioning desktop is to install Google Chrome.  Here is how to do it:
  1. Create a file /etc/yum.repos.d/google-chrome.repo with the following contents:
    [google-chrome]
    name=google-chrome
    baseurl=http://dl.google.com/linux/chrome/rpm/stable/$basearch
    enabled=1
    gpgcheck=1
    gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub
    
  2.  # yum install google-chrome-stable
That's all there is to it.  This has been another fine experience with Centos.  I'm liking it more and more each day ;-)

Sunday, January 10, 2016

Chalk Up One for Centos: Removing Old Kernels

I have committed to memory the commands needed to remove old kernels from the Lubuntu 14.04 workstations in our lab:
# dpkg --purge linux-image-extra-[kernel version]-generic
# dpkg --purge linux-image-[kernel version]-generic
# dpkg --purge linux-headers-[kernel version]-generic
# dpkg --purge linux-headers-[kernel version]
With the frequency with which new kernel versions have been released, this can become a rather tedious process.  I have machines in the lab that have many old kernels, and this collection of 4 dpkg --purge commands has to be run for each old kernel on each machine.  I can hear the skilled sys admins out there groaning that I should just run ... (fill in the correct CLI command here - probably involving xargs or something), or set up proper configuration management using Puppet or something.

Despite my years and years teaching with GNU/Linux systems, however, I am not much of a sys admin, and I don't know how to nor do I feel confident enough to try commands like that.  I'll either end up deleting the current kernel, or spending half the day getting the command to work, and then fail to complete my teacher responsibilities (lesson planning, gradeing, etc.) as a result. In years past I've relied on bright, fast learning students to become the sys admins of our lab, but we are in a rebuilding process at present and I don't have any students with these skills at present.

I'm confident that preparing for the RHCSA certification this Spring will help me become better at this sort of thing, but I am philosophically committed to software freedom, and the idea that you have to be some sort of wizard to use free systems properly runs counter to idea that software freedom should be promoted as widely as possible.

It turns out that Centos 7 has a delightfully simple way to address the old kernel problem (see this for more information).  Just run:
# yum install yum-utils
# package-cleanup --oldkernels --count=1
I searched in vain for anything on the Ubuntu side this simple.  The best I could find was this post, which was not very comforting.

Chalk up a clear win for Centos on this one!

Saturday, January 9, 2016

GUIs, CLIs and Updates on Centos 7

In addition to running Centos 7 in VirtualBox to prepare for the RHCSA exam, I am installing it on several machines in our IT lab at the Arlington Career Center, since the best way to become truly comfortable with an OS is to use it in day to day activity.  After many years (since 2004) using Ubuntu as my desktop OS, I feel very comfortable with its quirks and with navigating my way around Launchpad and Personal Package Archives (PPAs) and such to find and install the software I need.

Centos 7 is new to me, so it will take me awhile to reach that same feeling of comfort.  I had an early experience that is a bit disconcerting, which raises some questions I would like to get answered early on in the process.

Following the instructions in the text we are using to prepare for the RHCSA, I selected "Server with GUI" from the software selection dialog.  When the install finished, I had a Gnome Shell 3 desktop.  The following screenshot shows this desktop with the System Tools menu displayed:

 
I'm in the habit of running system updates obsessive compulsively (as I do most everything), so the first thing I did after completing the install was click on the "Software Update" menu to run updates.  The next screenshot shows the update process underway:


When it finished, I was caught by a surprise.  The menu options under "System Tools" had changed, and options "Software" and "Software Update" weren't there anymore:


I've been telling my young charges that "real sys admins don't use GUIs" since the beginning, so I would be perfectly comfortable if it were the case that the proper way to update Centos 7 is just to run:
# yum update
and that we should simply avoid the GUI update and package tools which have now disappeared anyway. I'll be more comfortable when I can read this as official Centos doctrine, so I'll be looking for statements to that effect as I continue learning.  I also need to find out how to work with RPM repositories, and which ones I should add to our lab workstations that will best provide software I will want without causing conflicts and breaking things.

To see if I could learn more about the disappearing menu items, I did a Google search on "Software Update" disappears from Centos 7 after running it and found this, which was helpful. It seems odd to me that such a big change would be made between what I would assume to be a minor release update (7 to 7.2), but getting a feel for how things work in Centos is what I am after, so this experience will be part of my education.

Tuesday, January 5, 2016

Starting the New Year with RHCSA Study

During the Spring semester, I will be working with four students in a dual-enrolled (high school and college credit) course titled: ITN 170: Linux System Administration. While learning to administer GNU/Linux systems, we will also be preparing for the RedHat Certified System Administrator (RHCSA) exam.

I will document our progress here, and ask that the four students keep blogs of their own.

I first used RedHat software in 1995 with the original RHL 1.0 release in May of that year.  I had been using Slackware prior to that, and RedHat quickly became my distro of choice.  It remained so until the first release of Ubuntu in 2004. So this will be something of a return to my past, and I'm looking forward to seeing how much of what I remember still holds.

As a first task, I wanted to find out how to easily remove old kernels from the Fedora 23 box we setup in the lab.  A quick search revealed this. It couldn't be much simpler:
  • # dnf install yum-utils
  • # package-cleanup --oldkernels --count=1
My next task was to install VirtualBox.  This is a single command on Ubuntu, but is a bit more complicated on Fedora.  Not too bad, however, with the documentation here.  I used the following four step process:
  •  # cd /etc/yum.repos.d/
  •  # wget http://download.virtualbox.org/virtualbox/rpm/fedora/virtualbox.repo
  • # dnf update
  • # dnf install binutils gcc make patch libgomp glibc-headers glibc-devel kernel-headers kernel-devel dkms
So 2016 will be the year I return to my RedHat roots.  Happy New Year!