Showing posts with label centos. Show all posts
Showing posts with label centos. Show all posts

This Week I Learned - 2017 Week 14

Last week post or you can go through the whole series.

Proposal have been presented and submitted. Standard feedback received. Nevertheless, better than nothing regardless the quality of the reactions.

#1 GTCafe Studio. Stumbled upon this site while searching for different covers of Guthrie Govan's Emotive Ballad. It's rare these days to find any blog with original good content. Reading through his journal on learning guitar made me reflect back on my decision on donating all my guitars away few years back. Maybe is time to start all over again? Or maybe not? Learning to play an musical instrument is one of the way to escape from mind-numbing daily routines. However, there is a time and place for everything in life. In hindsight, sometimes you just have to move on.

#2 "CentOS is not stable, it is stale". So true that it hurts. For me, as a whole, Fedora provides a better desktop experience than Ubuntu. Yet, I still revert back to Ubuntu on my daily usage. Why? APT is definitely better than YUM and plenty of software selection. Furthermore, LXD works only in Ubuntu and not Fedora. And yes, finally Canonical realized that and declared Ubuntu Unity will be replaced by Gnome 18.04 LTS. Maybe this Ask HN post on feedback for Ubuntu 17.10 from the community have finally sealed the fate for Unity?

I always wonder what would happen if Red Hat decided to use build a distro based on Debian or DPKG package manager instead of creating their own RPM packaging manager? A unified GNU/Linux desktop will come sooner rather than unnecessary fragmentation and efforts. For example, the competition of next generation display server of Mir and Wayland. Yes, I know having options and competitions is good for progress. But the priority and effort should be on fixing the damn display drivers performance and stability issues. Fragmentation leads to duplication of works.

#3 Five great Perl programming techniques to make your life fun again. An old article, 11 years ago but everything described there is as relevant as today especially iteration using `map` and `grep` and Dispatch Table as illustrated in example below. As Perl does not have `switch` statement, hence using Dispatch Table is a good Perl design patternMark Jason Dominus, in his book, Higher-Order Perl also devoted a whole chapter (PDF) on this matter.
my $dispatch_for = {
   a => \&display_a,
   b => \&display_b,
   q => sub { ReadMode('normal'); exit(0) },
   DEFAULT => sub { print "That key does nothing\n"; },

my $func = $dispatch_for->{$char} || $dispatch_for->{DEFAULT};

#4 Perl 5 Internals (PDF). Interesting reading on the intricacy part of the Perl itself. It was brought to my attention that Perl is a bytecode compiler, not an interpreter or a compiler.

#5 The 'g' key shortcuts in Vim. You will learn something new everyday, there are so many key bindings. Surprisingly, I only knew and regularly use two. Really needs to refresh and relearn this.

EPEL Yum Repository in CentOS

As Ansible, an automation tool, is not included to the default Yum repository in CentOS 6, you've to setup Extra Packages for Enterprise Linux (EPEL) Yum repository. I found this article on setting up EPEL repository and realize that I've been doing it the wrong way all this while. Instead of downloading the EPEL rpm package separately, we can install it directly as it's already located within the CentOS Extra Repository just by running the command below.
$ sudo yum install epel-release

Extra information on the epel-release package.
$ yum show epel-release
Installed Packages
Name        : epel-release
Arch        : noarch
Version     : 6
Release     : 8
Size        : 22 k
Repo        : installed
From repo   : extras
Summary     : Extra Packages for Enterprise Linux repository configuration
URL         :
License     : GPLv2
Description : This package contains the Extra Packages for Enterprise Linux (EPEL) repository
: GPG key as well as configuration for yum and up2date.

Listing the files within the epel-release package.
$ rpm -ql epel-release

Getting the list of RPM packages from EPEL repository.
$ yum list | grep epel

Since this is third-party YUM repository, certain system administrator may prefer to disable it by default and only install certain package from it when necessary.
$ cat /etc/yum.repos.d/epel* | grep enabled
$ sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/epel*
$ cat /etc/yum.repos.d/epel* | grep enabled

If you've installed any packages from this Yum repository. You should clear all the downloaded cache RPM packages..
$ yum clean all

Unfortunately, to perform any yum commands against this repository, we've to explicitly state the repository for every command. Some examples.
$ yum search --enablerepo=epel ansible
$ yum list --enablerepo=epel | grep epel | grep ansible
$ yum install --enablerepo=epel ansible

Indeed a bit hassle to type all these commands. You can create an alias to reduce the needless typing.
$ alias yumepel="yum --enablerepo='epel'"
$ yumepel search ansible

Linux Containers (LXC) in Fedora 22 Rawhide - Part 1

While Docker, an application container is widely popular right now, I've decided to try LXC, a machine container that hold a virtual machine like VirtualBox or WMWare but with near bare-metal performance. As I was running on Fedora Rawhide (F22), let's try to install and setup LXC in this distro.

Installation is pretty much straight forward.
$ sudo dnf install lxc lxc-templates lxc-extra

Checking our installed version against the latest available version. Our installed version on par with the current release.
$ lxc-ls --version

The first thing to do is to check our LXC configuration. As emphasized in red below, the Cgroup memory controller is not enabled by default as it will incur additional memory. This can be enabled through by adding boot parameter cgroup_enable=memory to the Grub boot loader. For now, we will keep that in mind and stick to the default.
$ lxc-checkconfig

Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-4.0.1-300.fc22.x86_64
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: missing
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

Before we can create our container, let's find out the available templates or GNU/Linux distros we can create.
$ ll /usr/share/lxc/templates/
total 348K
-rwxr-xr-x. 1 root root  11K Apr 24 03:22 lxc-alpine*
-rwxr-xr-x. 1 root root  14K Apr 24 03:22 lxc-altlinux*
-rwxr-xr-x. 1 root root  11K Apr 24 03:22 lxc-archlinux*
-rwxr-xr-x. 1 root root 9.5K Apr 24 03:22 lxc-busybox*
-rwxr-xr-x. 1 root root  29K Apr 24 03:22 lxc-centos*
-rwxr-xr-x. 1 root root  11K Apr 24 03:22 lxc-cirros*
-rwxr-xr-x. 1 root root  17K Apr 24 03:22 lxc-debian*
-rwxr-xr-x. 1 root root  18K Apr 24 03:22 lxc-download*
-rwxr-xr-x. 1 root root  48K Apr 24 03:22 lxc-fedora*
-rwxr-xr-x. 1 root root  28K Apr 24 03:22 lxc-gentoo*
-rwxr-xr-x. 1 root root  14K Apr 24 03:22 lxc-openmandriva*
-rwxr-xr-x. 1 root root  15K Apr 24 03:22 lxc-opensuse*
-rwxr-xr-x. 1 root root  40K Apr 24 03:22 lxc-oracle*
-rwxr-xr-x. 1 root root  11K Apr 24 03:22 lxc-plamo*
-rwxr-xr-x. 1 root root 6.7K Apr 24 03:22 lxc-sshd*
-rwxr-xr-x. 1 root root  25K Apr 24 03:22 lxc-ubuntu*
-rwxr-xr-x. 1 root root  13K Apr 24 03:22 lxc-ubuntu-cloud*

Let's proceed ahead by create our first container, a CentOS 6 distro. Unfortunately, as seen below, the creation failed due to deprecation of the Yum command which was redirected to DNF command.
$ sudo lxc-create -t centos -n centos-test

Host CPE ID from /etc/os-release: cpe:/o:fedoraproject:fedora:22
This is not a CentOS or Redhat host and release is missing, defaulting to 6 use -R|--release to specify release
Checking cache download in /var/cache/lxc/centos/x86_64/6/rootfs ... 
Downloading centos minimal ...
Yum command has been deprecated, redirecting to '/usr/bin/dnf -h'.
See 'man dnf' and 'man yum2dnf' for more information.
To transfer transaction metadata from yum to DNF, run:
'dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate'

Yum command has been deprecated, redirecting to '/usr/bin/dnf --installroot /var/cache/lxc/centos/x86_64/6/partial -y --nogpgcheck install yum initscripts passwd rsyslog vim-minimal openssh-server openssh-clients dhclient chkconfig rootfiles policycoreutils'.
See 'man dnf' and 'man yum2dnf' for more information.
To transfer transaction metadata from yum to DNF, run:
'dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate'

Config error: releasever not given and can not be detected from the installroot.
Failed to download the rootfs, aborting.
Failed to download 'centos base'
failed to install centos
lxc-create: lxccontainer.c: create_run_template: 1202 container creation template for centos-test failed
lxc-create: lxc_create.c: main: 274 Error creating container centos-test

The above error is a good example on why the transition from YUM to DNF command was unnecessary and caused breakage. It turned out that /usr/bin/yum is a shell script that display notification message. To resolve this, we need to point /usr/bin/yum to the actual yum program. There are way to bypass this step where we'll discuss about this in Part 2.
$ sudo mv /usr/bin/yum /usr/bin/yum2dnf
$ sudo ln -s /usr/bin/yum-deprecated /usr/bin/yum
$ ll /usr/bin/yum
lrwxrwxrwx. 1 root root 23 May  5 23:40 /usr/bin/yum -> /usr/bin/yum-deprecated*

Let's us try again. Although there is notification, the creation of the container will run smoothly. Since we're creating this for the first time, it will took a while to download all the packages.
$ sudo lxc-create -t centos -n centos-test
Download complete.
Copy /var/cache/lxc/centos/x86_64/6/rootfs to /var/lib/lxc/centos-test/rootfs ... 
Copying rootfs to /var/lib/lxc/centos-test/rootfs ...
Storing root password in '/var/lib/lxc/centos-test/tmp_root_pass'
Expiring password for user root.
passwd: Success

Container rootfs and config have been created.
Edit the config file to check/enable networking setup.

The temporary root password is stored in:


The root password is set up as expired and will require it to be changed
at first login, which you should do as soon as possible.  If you lose the
root password or wish to change it without starting the container, you
can change it from the host by running the following command (which will
also reset the expired flag):

        chroot /var/lib/lxc/centos-test/rootfs passwd

Checking our newly created container.
$ sudo lxc-ls

Checking the container status.
$ sudo lxc-info -n centos-test
Name:           centos-test
State:          STOPPED

Start our newly created container. Yet again, another error.
$ sudo lxc-start -n centos-test
lxc-start: lxc_start.c: main: 344 The container failed to start.
lxc-start: lxc_start.c: main: 346 To get more details, run the container in foreground mode.
lxc-start: lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options.

Let's try again, but with foreground mode (-F).
$ sudo lxc-start -F -n centos-test
lxc-start: conf.c: instantiate_veth: 2672 failed to attach 'vethM9Q6RT' to the bridge 'lxcbr0': Operation not permitted
lxc-start: conf.c: lxc_create_network: 2955 failed to create netdev
lxc-start: start.c: lxc_spawn: 914 failed to create the network
lxc-start: start.c: __lxc_start: 1164 failed to spawn 'centos-test'
lxc-start: lxc_start.c: main: 344 The container failed to start.
lxc-start: lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options.

I was quite surprised that Fedora did not create the lxcbr0 bridge interface automatically. Instead, we will use the existing virbr0 provided by libvirtd.
$ sudo yum install libvirt-daemon
sudo systemctl start libvirtd

Check the bridge network interface.
$ brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.525400c28250       yes             virbr0-nic

Edit our container config file and change the network link from lxcbr0 to virbr0.
$ sudo vim /var/lib/lxc/centos-test/config = virbr0

Try to start the container again, this time, another '819 Permission denied' error.
$ sudo lxc-start -F -n centos-test
lxc-start: conf.c: lxc_mount_auto_mounts: 819 Permission denied - error mounting /usr/lib64/lxc/rootfs/proc/sys/net on /usr/lib64/lxc/rootfs/proc/net flags 4096
lxc-start: conf.c: lxc_setup: 3833 failed to setup the automatic mounts for 'centos-test'
lxc-start: start.c: do_start: 699 failed to setup the container
lxc-start: sync.c: __sync_wait: 51 invalid sequence number 1. expected 2
lxc-start: start.c: __lxc_start: 1164 failed to spawn 'centos-test'
lxc-start: lxc_start.c: main: 344 The container failed to start.
lxc-start: lxc_start.c: main: 348 Additional information can be obtained by setting the --logfile and --logpriority options.

After struggled and googled for answer for the past hours, it actually dawned to me that the '819 Permission denied' error is related to SELinux policy. I did a quick check by disabled SELinux and reboot the machine and was able to start the container.

Also, just to confirm the SELinux error for lxc-start.
$ sudo grep lxc-start /var/log/audit/audit.log | tail -n 1
type=AVC msg=audit(1430849851.869:714): avc:  denied  { mounton } for  pid=3780 comm="lxc-start" path="/usr/lib64/lxc/rootfs/proc/1/net" dev="proc" ino=49148 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=dir permissive=0

Start the SELinux Alert Browser and run the below commands to add the security policy.
$ sealert

$ sudo grep lxc-start /var/log/audit/audit.log | audit2allow -M mypol
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i mypol.pp

$ sudo semodule -i mypol.pp

Start our container again and check it status.
$ sudo lxc-start -n centos-test 
[[email protected] ~]$ sudo lxc-info -n centos-test
Name:           centos-test
State:          RUNNING
PID:            6742
CPU use:        0.44 seconds
BlkIO use:      18.55 MiB
Memory use:     12.14 MiB
KMem use:       0 bytes
Link:           veth4SHUE1
 TX bytes:      578 bytes
 RX bytes:      734 bytes
 Total bytes:   1.28 KiB

Attach to our container. There is no login needed.
$ sudo lxc-attach -n centos-test
[[email protected] /]# uname -a
Linux centos-test 4.0.1-300.fc22.x86_64 #1 SMP Wed Apr 29 15:48:25 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[[email protected] /]# cat /etc/centos-release 
CentOS release 6.6 (Final)

CentOS is officially part of Red Hat

Surprising good news for CentOS as Red Hat had officially acquired the core team of the distro. What took them so long ? They (Red Hat) should have done this sooner. Now we can expect faster updates and security patches for CentOS. Suspect they want to sustain and increase the popularity of the most popular Red Hat variant.

PHP 5.4 and MySQL 5.5 in CentOS 6.4

Due to some shenanigans in office, unfortunate miscommunication, and effing messed up provisioning, have to redo the LAMP installation again in CentOS 6.4. Installation steps as root shown below.

1. Install the Remi third party repository.
$ rpm -ivh

2. Enable the Remi Repository and update.
$ vim /etc/yum.repos.d/remi.repo
$ yum update

3. Install the Apache Web Server, Mysql Database Server, and PHP. Configure and set the MySQL's password as well.
$ yum install httpd php php-mysql mysql-server
$ mysql_secure_installation

4. Enable both web and database server start upon reboot.
$ chkconfig httpd on
$ chkconfig mysql on
$ reboot

CentOS and Red Hat

Red Hat is probably the best and worse possible thing that can happen to CentOS, a community-based GNU/Linux distribution derived from it. The good part is you have the stability and good driver support since Red Hat is popular among the commercial world. The worst part is stability comes with a price. Getting latest greatest software updates (e.g. PHP or Subversion) is quite limited unless is a security fix. So you left with two choices, either you get the updates from third party repositories or you built from source code. Unfortunately, both ways have their own issues.

First, is always tricky to mix third party repositories and base repository. Certain common library packages maybe updated by third party repositories causing unnecessary breakage with existing software. Although Yum priority plugin and packages exclusion can solve that, it is still a hassle.

Second, installation by source code compilation. You can have all the customize options but with all the issues in former way as well. However, you can have the flexibility to isolate your installation into specific directory (/opt) with GNU Stow, a symlink farm manager. But you lost the ability to verify the integrity of your software binaries (check for tampering or planted Trojan) in case there is a security breach. To solve that, some may rebuild the software into RPM packages software from existing RPM's spec file which is what all the third party repositories are doing right now. In the end, you still back the problem of the first method.

How then ? Just migrate and move to a more bleeding edge distro like Ubuntu or Fedora.

Stuck with Consevative GNU/Linux Distros

I stuck with conservative GNU/Linux distros (Centos or Debian stable) which don't let you update to a more current LAMP-stack packages. No, don't want to compile source code. What should I do?
For Debian stable, use Dotdeb. For Centos, use IUSCommunity. IUS stands for Inline with Upstream Stable. This third party RPM repository is "sponsored by internal work at Rackspace (but officially unsupported)"

What if I stuck with hosting panel like cPanel, Plesk, or Direct Admin?
Pray hard. Pray very hard. You're at the mercy of your hosting provider.

RedHat/CentOS vs. Debian/Ubuntu

Interesting discussion on experiences using Centos/Redhat, Ubuntu, and Debian. Funny nobody mentions OpenSuSe, Gentoo, or Arch on any serious server deployment. Summary of the discussion.

1. Centos/Redhat. High-performance computing (HPC), scientific stuff, Oracle databases, or Java-related stuff.

2. Ubuntu. Mostly desktop. Latest and greatest stuff. The (Long Term Support) LTS is crappy for HPC.

3. Debian. Server stuff or a more stable and conservative Ubuntu (LTS).

To be fair, for typical LAMP-stack server, all above mentioned GNU/Linux distros are good enough. But Ubuntu/Debian are far more convenient to get more latest greatest packages. 

Subversion Server Installation and Setup in CentOS 5.x

Is so fricking hard to find latest greatest official packages for CentOS. For example, the latest version of Subversion in CentOS 5.8 is 1.6.11. If you want the 1.7.x version, you have to either download from third party repository like wandisco, upgrade to CentOS 6.x, or just compile own your own. I always wary with unofficial rpm packages especially those that you can’t verify. Unless I need to set up something fast or just plain lazy, I will just go ahead and download these rpms. Direct upgrade from 5.x to 6.x is not supported and it is advisable to do a fresh install. Compile from source, been there, done that, not sure what I am doing. While I understand the CentOS team is severely lacking resources, how I wish there is something similar to Ubuntu PPA for CentOS.

Enough ranting. Let’s proceed with the installation. The installation steps are based on two very helpful guide, the official and unofficial. As I am currently stuck with 5.X and I badly need the centralized metadata storage (just one .svn hidden folder) in 1.7.X.

Download all the necessary packages and install them. Make sure you have remove the existing subversion packages. All command is run as root.
$ yum remove subversion*
$ yum install httpd
$ rpm -ivh subversion-1.7.7-1.x86_64.rpm
$ rpm -ivh mod_dav_svn-1.7.7-1.x86_64.rpm
$ rpm -ivh subversion-perl-1.7.7-1.x86_64.rpm
$ rpm -ivh subversion-tools-1.7.7-1.x86_64.rpm
$ rpm -ivh subversion-python-1.7.7-1.x86_64.rpm

Backup the original Subversion Apache module configuration file.
$ cd /etc/httpd/conf.d
$ cp subversion.conf subversion.conf.orig

Edit the configuration file (subversion.conf) as follows:
LoadModule dav_svn_module     modules/
LoadModule authz_svn_module   modules/

DAV svn
SVNListParentPath on
SVNParentPath /repo

AuthzSVNAccessFile /repo/acl
AuthType Basic
AuthName "Repositories"
AuthUserFile /repo/passwd
Require valid-user

Create the repository folder.
$ cd /
$ mkdir repo
$ cd repo

Create the password (passwd) with a sample user (melanie).
$ htpasswd -m passwd melanie
New password:
Re-type new password:
Adding password for user melanie

Create a sample ACL file with content of
melanie = rw

Create a sample project and change all folder permission to the apache user.
$ svnadmin create sample
$ chown apache.apache -R /repo
$ service httpd restart

Browse to https://localhost/repo/ or https://localhost/repo/sample. The server should prompt you for username and password.