Powered By Blogger
Showing posts with label RHEL7. Show all posts
Showing posts with label RHEL7. Show all posts

2015/09/02

HP ILO VSP: CentOS 7/RHEL 7 Installation through Serial Console

Though it's feared or considered as outdated by some, command line tools (CLI) remain the right ones for many System Administration tasks. Among its countless advantages, there's tasks' automation through its Script-ability.
In this post, I'm willing to describe the Usage of HP ILO CLI utility for the Complete Installation of CentOS 7/RHEL 7 Distribution. Through this mean, one can complete a full System Installation from CLI. Such Installation are quite useful for many cases, like Remote Installation with low bandwidth, No need for  Advanced ILO license...
The Installation described below is a CentOS 7.1 System on Proliant G8 (using ILO4) and I'm leveraging on KickStart to automate its Install process. But, the same procedure can be easily adapted for other Linux Distributions.

Let's start by reviewing what is needed to complete that Installation:

1. Prerequisites:

  • ILO Configured with Valid IP Addressing parameters and reachable through SSH
  • Linux System (any distribution) with mkisofs installed
That Linux System will be used to build Custom CentOS/RHEL Image, in this case I'm using the System the same system to share the ISO mentioned below (Hostname: stivinstall; IP: 192.168.1.11)
  • OS Distribution Media (ISO) available on the network and reachable from the ILO
As said above, I'm installing CentOS 7.1, so I shared the ISO on an http server (installed and configured on my Linux System) and checked that it's well available (http://192.168.1.11/mnt/CentOS-7-x86_64-DVD-1503-01-text.iso)
  • (Optional) KickStart File for automated Installation
I'm leveraging on Kickstart to fully automate this Installation. But that is obviously optional. In this case, I made Kickstart file available on the same System where I hosted the OS ISO (http://192.168.1.11/dladc2-infpup01.ks)

2.  Modify CentOS 7 boot image to get output on Serial Console

By default, the boot ISO of RHEL 7/CentOS 7 will redirect its output to Graphical Console, so that needs to be modified to have Output directed to the Serial Console (VSP).

Mount the CentOS ISO on my elected Installation System (stivinstall)



The main directory we'll be modifying in this ISO is Isolinux, so Copy this directory under a temporarily writable directory.



As we're aiming to have everything in Text (console) mode, we should first get rid of graphical feature, like image. So, in the boot.msg, remove the ^Xsplash.lss line and delete the boot.cat (will be re-created later)



Now, the main and most important modifications are to add/edit two main configuration in the isolinux.cfg:

  1. A new line with "serial 1 9600" which indicates to IsoLinux to redirect the output to the Serial Console
  2. Append "console=ttyS1" to the Kernel Option (append initrd...). This is a kernel option that specifies what device to use as the primary console and its implies text as the Installation Mode.

Below, I've made use of diff between the modified and an unmodified isolinux.cfg to highlight that modifications. We can see that around Line 54 (this can obviously added as option in other place in the file), I added (the line starting with "#"is just a comment):

# Output to Serial Console ttyS1 - Stivesso
serial 1 9600


And for most of the append Kernel options (did this for Linux, Troubleshoot and Rescue Entries), I appended this at the end:
console=ttyS1



With that modification on isolinux.cfg completed, we can recreate the ISO. but first, we mount (with the --bind option) our modified directory under the isolinux directory of the mounted Image. Then, we can create the ISO using mkisofs.

Note that the volume ID (-V) of the ISO image must be the same as the inst.stage2= parameter in isolinux.cfg and replacing \x20 by a space (described in BZ#915563), Otherwise we'll be facing an Issue during the Installation and will be redirected to Dracut Emergency mode (... Warning: /dev/root does not exist, Entering emergency mode. Exit the shell to continue.)



The following is just a way to check that the created ISO has the needed modification in isolinux.cfg.



3.  Use ILO CLI to insert a virtual media

Once we've met the prerequisites listed above and created our modified ISO Image, we can go to the ILO (ssh) and insert the OS Distribution ISO in the ILO Virtual Media. This is done using the vm command, to see a full description of vm command options and syntax, one can use "help vm" as seen below



Get the Status of the CDROM Virtual Media,



Insert our OS Distribution ISO Image,



Connect the Inserted OS Image,



Set the system to boot on this image during the next reboot, for that we can either use boot_once to have it mounted and set as boot drive just during the next boot or boot_always to have it permanently mounted and set as boot drive.



4.  OS Installation:

Now that we have the media Inserted, we can proceed to the OS Installation by powering on the Server (or resetting if it was already running) and getting to VSP (Virtual Serial Port) to complete OS Installation.
I strongly advise to have the ILO SSH Console opened in max window size to make sure that the console output fit the size of the SSH console.



We'll get to the following nice screen,




Press Up (to make sure it’s at “Install CentOS 7” entry) and Tab,



From here, you can either just press enter to proceed to an Interactive Install, or if you prefer to use KickStart (as I do :-) ), then just enter the appropriate options. In this case, I’m entering the following inst.ks=http://192.168.1.10/stix-1.ks ip=192.168.1.11::192.168.1.1:255.255.255.0::ens2f0:none (more details about RHEL7/CentOS7 Kickstart Install in this post)
My suggestion for entering the option, "don't copy-paste, better write..."




References:

2015/07/29

Packstack Installation with Existing External Network / kickstart RHEL7 (CentOS7)

Interested in getting OpenStack up and running within few hours in the easiest possible way? Then Packstack is most probably your friend. Indeed, Packstack is a utility which leverages on Puppet modules to deploy various parts of OpenStack on multiple pre-installed servers over SSH automatically. I've been through a cycle of building/destroying my OpenStack Labs by using this tool and I'm willing to share below a Kickstart File which fully automate such type of Installation (OpenStack using PackStack with an Existing External Network). The initial process on which I built this KickStart Installation is well documented here. My main aim here is to be able to reference a Single Kickstart File during my RHEL/CentOS 7 Installation and have OpenStack Installed and partly configured without manual Intervention (except for a reboot that I preferred not to automate :-) ).

The same Kickstart File can also be used as a Template for RHEL7/CentOS7 (or any other Systemd-based's distribution), especially if there's a need to run some script (or any other program) during the first boot (after OS installation) of the System (see the %post section).
In fact, in this Kickstart File I've edited and created a Systemd service that will run only once after the first boot and delete itself.
I was used to do that on previous RHEL/CentOS (RHEL6...) by leveraging on /etc/rc.local. Though there’s still /etc/rc.local  on RHEL7,It is highly advisable to create own systemd services or udev rules to run scripts during boot instead of using that file.

Note that after the initial reboot, Packstack Configuration Progress can be followed using journalctl (journalctl -f -u pacstack_installation.service) 

Few Things that are specific to this Kickstart:
System Hostname: stiv-opsctr01
System IP: 192.168.0.21/24
System GW: 192.168.0.1 
DNS1 IP: 192.168.0.30
DNS2 IP: 192.168.0.31
PROXY and Install Server (I'm using proxy for Internet Access) : 192.168.0.33


My Kickstart File:



References:

2015/04/07

Open Source Puppet Agent Installation / Local Yum Repository for RHEL and derivatives

I've been playing for a while with Open Source Puppet and faced few challenges during its deployment. Among these challenges, there's the installation of the puppet Open Source agent on some RHEL Systems. In fact, The process to install the RHEL Puppet Open Source agent isn’t as straightforward as on CentOS and other community forks because RHEL repositories are divided into many channels and to install Puppet on it, one of this channel (the “optional channel") needs to be enabled (more details here). Meaning that both an Internet Connectivity and a valid RHN subscription are needed to complete Puppet Open Source Agent Installation on RHEL System.
Anyway, the main idea I've to workaround this small challenge is to create a small Internal http-based repository which contains all the required Package for Open Source Puppet Agent (and facter) Installation. That repository will then be used for my RHEL/CentOS node that aren't connected to Internet for Puppet Open Agent Installation.
To achieve that, the very first thing is to download Open Source Puppet Agent RPM, Facter RPM and all their dependencies in the same directory. For that, repotrack is probably one of the best tool. Indeed, this tool helps to download a package and all its dependencies recursively in the same directory. 
Repotrack is using /etc/yum.conf as default Configuration file, meaning that it'll be downloading packages based on the current repository settings. That's why I'm using a CentOS System (instead of RHEL) to create that local repository (CentOS only needs its main repo & PuppetLabs repos to be able to solve all the dependency related to Puppet/Facter).
Although in this post I'm using a CentOS 7 Distribution to download puppet/facter agent RPMS for EL7, the same process applies to lower RHEL/CentOS version (<=6), the only difference being that RHEL7 is only 64-bit, and due to that,no 32 bits repository is needed.
Enough talk, let's move forward with the following steps to complete that Local Repository configuration for CentOS7/RHEL7. 

1. Overview of the environment for this Post

This is just a short description of the System that'll be configured in this post,


System Name
OS
Description
my_repo
CentOS 7
Http-based repository (Connected to Internet)
puppetmaster
CentOS 7
Puppet Server (Connected to Internet)
my_rhel_1
RHEL 7
Puppet Client ( No Internet Connectivity)

2. On the CentOS7 Repository System, add the PuppetLabs Repository




3. Install Apache on this CentOS7 System and configure it accordingly (to make RPMS available using http)


I used my Puppet Master (and foreman) to complete this step, but a simple "yum install httpd" and httpd configuration will also be enough. The following is just for those who are interested in such Puppet configuration. If using a classic yum installation and normal httpd configuration, then you can move forward to Step 3.


On the Puppet Master Server, I'm installing Apache module





Under one of the Module Path, the module directory and the manifest folder are created.



I'm then editing a webconf manifest file to configure the Apache Module (with vhost).



The init.pp for this small module is then created to include the defined webconf




As said above, I'm using Foreman to classify my Puppet Nodes, so all these classes have then been imported under foreman (configure --> Puppet Classes --> Import from...) and the server hosting this web repository (my_repo) have been then edited to include stivrepo Module.

4. Download the CentOS7 puppet/facter Packages with all their dependencies

As discussed above, the tool used for downloading the Packages and their dependencies here is repotrack, it's part of yum-utils Packages (So, if not done, Install yum-utils). Also, if 32 bits OS will use that repository (again, RHEL7 is 64 bits only, so this comment is mostly for version below  7), then create both i686 and x86_64 under the Packages directory and use the option --arch (repotrack --arch=i686) of repotrack to specify the architecture you're downloading Packages for.



5. Create and configure the repository


To create the repo, I'm using the classic createrepo with the appropriate option. It is  a program that creates a repomd (xml-based rpm metadata) repository from a set of rpms. If it isn't already installed, then install the Package.



Create the repository Metadata

Check our new repository data folder and files have been created,



It is important to note that RHEL and CentOS have a different way to interpret the releasever value on yum client configuration. In fact, CentOS interprets the realeasever variable as "OS Major Version (like 7,6,5...)" while RHEL interprets it as "OS Major Version + OS Type (7Server, 6Server, 5Server)". To make sure that our repo will be reachable from both Distribution, we'll add a Symbolic Link to the main folder.
Yum variables can be checked with the following command : "python -c 'import yum, pprint; yb = yum.YumBase(); pprint.pprint(yb.conf.yumvar, width=1)' "



At this stage, our repo is available and reachable using http URL http://stivrepo.stivameroon.net/puppet_os_agent/7/x86_64 (or http://stivrepo.stivameroon.net/puppet_os_agent/7Server/x86_64 for RHEL Server) , so the remaining is to make it available on the target System (the one without Internet Connectivity...)

6. Create a repository release RPM (optional):

The aim of this repository release RPM is just to make easy the configuration of yum on the target Systems. Indeed, we'll just have to run a normal rpm Installation to complete their yum configuration. The step is optional because one can still choose to complete manually that configuration.
To create this repository release RPM , I followed this excellent tutorial. Below is just the output of the whole process




The final thing to do is make this rpm available in the right place



7. Configure Target Systems to use the new repository:

There are 02 ways to configure the target system to use this local repository for Puppet/Facter Installation. 

The first one is automatic and apply only if step 5 of this post wasn't skipped. It consists of just installing the repository release RPM we've created.



The second one is manual and consists of adding the following file under /etc/yum.repos.d of the target System.



8. Install Puppet and Facter on the Target System:

Now, we can easily install Open Source Puppet Agent and facter by simply running the following:




Just a final note, though all the dependencies for Puppet/Facter are well resolved with this method, it might happen that there's some installed packages on the target System which depend on a package that is being upgraded for Puppet/Facter.  For such case, we might have errors similar to the one below: 




In such case, the way to workaround is simply by repotrack the package that need upgrade (libselinux-python for this example) in the right directory and update the repository using createrepo as seen below:




References:
https://www.digitalocean.com/community/tutorials/how-to-set-up-and-use-yum-repositories-on-a-centos-6-vps
http://sbr600blog.blogspot.com/2012/03/how-to-create-repository-release-rpm.html

2014/09/16

HP ILO / RHEL7 Systemd Output to VSP console

During my last post, I described the redirection of Linux Output to Serial on an Upstart Distribution based (using RHEL6). The main aim of this post is to describe the same on Systemd Distribution based (RHEL7). Before I begin with the technical matters, I have to say that I've been quite impressed by how Systemd makes this configuration so easy (no pain at all! So cool!). This isn't to make a comparison between Systemd and Traditional Init or Upstart, but you can check these two previous posts to draw your own Conclusions:  VSP/Traditional Init, VSP/Upstart.
Let's now delve in the interesting matters. The whole procedure is just about setting Kernel Options and reboot, and if the reboot can't be performed right away, just start a systemd service.

1. Set the Kernel Options boot options: 

On RHEL7 with Grub2, add "console=ttyS1" to  GRUB_CMDLINE_LINUX in /etc/default/grub file (You might also remove rhgb quiet as rhgb is for RedHat Graphical Boot and quiet is meant to hide the majority of boot messages before rhgb starts)



Changes to /etc/default/grub require rebuilding the grub.cfg file. This file location's on BIOS based machine is /boot/grub2 and for UEFI based machine, it is /boot/efi/EFI/redhat/.

On BIOS Based Machine:


On UEFI Based Machine:


2. Reboot or start a serial-getty service on ttyS1

Now we can either reboot the System to have the Kernel Loaded with the new parameter during the reboot , or (especially if we can't afford a downtime :-)) run the following to have a getty service started right away on the ttyS1.



That's it! So simple! Go on the console, run vsp and there's a nice prompt...




Reference:
http://0pointer.de/blog/projects/serial-console.html

2014/09/11

Oracle/Redhat Enterprise Linux 7 Kickstart Installation / without DHCP

RHEL7/OEL7 is out for few months now, with a lot of new features (Revamped Anaconda, Systemd...). But before really starting to enjoy all these nice features, let's perform some basic Automated Kickstart Installation. In this short post, I'm willing to describe just that type of Installation without relying on a DHCP Server (using Static Network Parameters). I'm also using an Installation tree and Kickstart file located on httpd servers and reachable from the System I'm installing. Enough talk! let's detailed this Kickstart Installation in the following 4 steps:

1. Make Installation Tree available on an httpd server:

We've RHEL7/OEL7 ISO Files and an httpd server (192.168.0.10) configured (with DocumentRoot being the classic /var/www/html). Mounting the ISO as loop device in the DocumentRoot is enough to have the Installation Tree available over httpd.



2. Create the Kickstart File and make it available on the httpd system:

For that, I used as template an anaconda-ks.cfg  from another installed node and created the following kickstart.



Make this file available on http (copied under httpd DocumentRoot) and test to make sure it's reachable (i.e http://192.168.0.10/olnode.ks )

3. Start the Kickstart Installation

I'm using an UEFI system, so In order to provide the right Kickstart Parameters during the boot process, I'm selecting an installation option in the boot menu and then press either the E key ( For BIOS Systems, that'll be he Tab key). A prompt is displayed which enables to edit the boot options already defined and to add new options.  In this case, I'm adding the following: 

inst.ks=http://192.168.0.10/olnode.ks ip=192.168.0.20::192.168.0.1:255.255.255.0:olnode:eno49:none

inst.ks specifies the location of the kickstart file, and ip sets statics network parameters, it must be in this form: ip=ip::gateway:netmask:hostname:interface:none. Below are some screenshots taken to illustrate this process.
Note that parameters such as hostname and Interface could be empty









4. Enjoy the Automation:

Once that's done, the last step is to Press Ctrl-x (or enter on BIOS System) and enjoy the automation...







References:
http://docs.oracle.com/cd/E52668_01/E54695/html/ol7-install-boot-options.html