My First RHEL Experience

Introduction

This article records my errors and difficulties encountered on the first day I came across Red Hat Enterprise Linux 7 in my school’s laboratory, as a normal user without sudo privileges.

The login screen was gdm, and the desktop environment was GNOME. IBus was used as the input engine.

Packages installed

The principal goal is to install tools that I usually use on RHEL without sudo permissions. To do so, I’ve downloaded the executable binaries or source code of these packages. As I wanted to focus on my studies, I prefer downloading executable binaries.

Go

I cloned the repo before a failed compilation. After knowing that Go can be installed by extracting a gzipped tarball, I grabbed one marked Darwin. The decompression took several minutes. After that, bash couldn’t execute the binary file go. It took me fifteen minutes to realize that Darwin is the name for an OS X release.

Then, I downloaded the right archive, issued go version and got “permission denied”. The files in ./bin were not marked as executable. After fixing this, the command finally gave “1.11”.

The first linked article suggested setting GOROOT to /usr/local/go. However, as /usr contains common packages for normal users, dropping a package there requires write access, and the directory is owned by root. Therefore, I’ve chosen ~/bin/go instead. The go binary file is located at bin/go relative to GOROOT, so that expands to ~/bin/go/bin/go.

The official Go installation verification is slightly better than using go version. A simple Hello World reminded me to mark ./pkg as executable. After that, the program succeeded in greeting the world.

I found $HOME/go/Proj/Proj1 a bit strange and too long as GOPATH. The official guide suggested $HOME/go without requiring us to put GOPATH into PATH. Nevertheless, I included it back later during Hugo installation.

References:

1. https://tecadmin.net/install-go-lang-on-centos/
2. https://golang.org/doc/install?download=go1.10.3.linux-amd64.tar.gz#install

GitLab SSH key

SSH connection to the Git service provider is preferred over HTTPS connection. SSH allows pushing commits without typing the user password every time, once the private key has been added to the SSH agent.

Reviewing GitLab’s official guide, I’ve learnt that flag -o in

$ ssh-keygen -o -t rsa -C “user@example.com” -b 4096

provides additional security to the private key by raising the difficulty of a brute-force attack. Under this flag, the newly generated keypairs aren’t compatible with the PEM format.

After

1. ~/.ssh/config
2. evaluating the SSH agent’s PIDstow
3. adding the SSH private key to the SSH agent

I tried cloning the GitLab repo for this blog, but the SSH agent refused that operation, despite my matching keypairs. I double checked the public key in my GitLab account to ensure that it matched exactly with my local copy.

I searched using phrases from the error message for an hour. An environmental variable catched my eyes: SSH_AUTH_SOCK. Some post suggested setting this to zero. In my RHEL session, this was set to /run/user/[some-number]/keyring/ssh. It said somewhere that one needed to disconnect from the current network and reconnect to it so that the SSH configurations can take effect. To my surprise, after clicking on the “off” button, the system hanged. I couldn’t switch to TTY. Since the room accommodates over twenty work stations, and there were over ten rooms, I thought that they were virtualized machines: the work station got their power from the LAN. Once it’s cut, it lost its power. I resorted to press the power off button—that’s bad for HDD hard disk.

I wasted time on finding a mistaken step. In fact, I had done nothing wrong. It remained to reboot the machine. I finally managed to use Git over SSH.

Japanese input

The Japanese input was following a French keyboard layout, and there’s no way to change it. Click on the keyboard button didn’t display a popup window with a keyboard layout, unlike other input methods.

Unsuccessful GNU Stow installation

The symlink generator GNU Stow can be utilized to handle dotfiles. The installation dependency includes some test modules of Perl. Omitting them and make && make install after ./configure can get it compiled, but the lack some modules prevents it from running.

I don’t wish to spend time on resolving this dependency problem because

1. I lack knowledge in Perl;
2. I lack time;
3. there’re other ways to handle dotfiles without GNU Stow.

Nonetheless, I’ve learnt to add --prefix=/custom/path after ./configure to specify the installation path for make install.

Zsh

I would like to have a compiled binary archive, but I could only find the source code. Luckily, the compilation was successful, and Zsh was installed in ~/bin/zsh/.

Oh My Zsh

I copied the command for installing the script, which attempted to run chsh. This failed since it’s impossible to register my own compiled shell into /etc/shells. I was told to change the default shell to Zsh, which I would love to. I tried export SHELL=$(which zsh) and exec -l $(which zsh) in either ~/.bashrc and ~/.bash_profile. However, gdm’s login screen automatically logged me out after a successful login. I had to use TTY to undo these changes.

Since then, to use Zsh (with Oh My Zsh), I need to key in zsh under bash.

Sublime Text 3

Among the softwares in the above table, the installation of Sublime Text 3 was the easiest:

1. One click for downloading the compressed binary tarball.
2. Another click to opening it in a GUI archive management tool.
3. Third click to choose a target path for the decompression. (I’ve chosen ~/bin/.)
4. (Optional) Add the installed Sublime Text 3 directory to PATH.