KVM Virsh Console Access to Linux VM – CentOS 6

This document will show you how to get virsh console access to guest virtual machines.

The console command within virsh is an excellent feature to have working for your virtual environments. For example, it can be really handy to watch a machine boot without launching a GUI tool ie. virt-manager. I personally find virsh console access a quicker way to configure networking settings which may not be able to be achieved via SSH, other than using virt-manager.

[box type="info"] Just note that this document assumes CentOS 6 for all example code and references. Syntax, file locations and codes may vary based on your distribution.[/box]

Typically out of the box, when you install a new CentOS 6 virtual machine, the “virsh console” command will not work…

Step 1: Configure Serial Terminal

On your new CentOS 6 virtual machine, you’ll need to configure ttyS0. This serial interface is how “virsh console” gains access to your virtual machine.

Log into your virtual machine…

Create new ttyS0 config file

Copy/Paste the following config

Step 2: Allow login into ttyS0

By default CentOS will not allow a user to login via ttyS0 unless we modify securetty.

Add the following to the end of the file and save it.

Step 3: Start ttyS0

Make ttyS0 available, from your terminal execute the following command

Step 3: Test Virsh Console

From your KVM server, connect to the console of your virtual machine

Step 4: Configure Access to Boot Output

To watch your virtual machines boot/shutdown messages we need to make a couple of changes to your boot process.

Edit your grub config

Your kernel entry may look something like this

You’ll want to remove the “rhgb” option, this is the boot splash screen. The “quiet” entry hides a lot of boot messages, I remove so more detail is outputted.

Finally you’ll want to add “console=ttyS0″ to send the boot messages to your virsh console. Your kernel line may now look like this

[author] [author_image timthumb='on']http://mcdee.com.au/wp-content/uploads/2012/11/photo.jpg[/author_image] [author_info]Andrew McDonald is an IT Systems Admin and all round technology junkie. Absolutely a jack-of-all-trades and not one to shy away from a challenge.


[/author_info] [/author]

Tutorial – Cisco Router Port Forwarding (PNAT)

This is a short tutorial of basic port forwarding (PNAT) on a Cisco router without a device reboot/reload.

Performing a simple PNAT on a Cisco requires very little configuration. Firstly the PNAT entry needs to be created and then a quick check on the access control lists (ACL) to confirm the protocol and port is permitted.

[box type="info"] Just note that this documents steps were performed on a Cisco 877 router, it “should” still be valid configuration for most Cisco routers.[/box]

Step 1: Adding the Port Forward (PNAT) Entry

This step will give you example syntax to create a port forwarding entry. You will need to refer to step 2 to ensure you have the correct ACL’s setup. Also note that you don’t need to reboot/reload after adding this entry.

Connect to your router

Switch to configure mode

Enter the port forwarding (PNAT) command, for example I want to forward SSH connections from the Internet into a local server with the IP address of 192.168.0.10

…and that’s the command, obviously you would change the IP address and ports as desired. You can even map completely different ports to obfuscate your services. For example lets map our internal SSH server (192.168.0.10) to the outside using port 2233.

Another thing to note is Dialer0. You would obviously change the interface “Dialer0″ with your interface name (FastEthernet0/1 for example), or alternatively if you are using a static public IP address you could enter it as

Step 2: Configure Access Control List (ACL’s)

Even though a map has been created the ACL’s may still prevent the traffic. We’ll need to get the access-list number for the Dialer0 interface and then modify it.

View the running configuration. Note you do not run this while in configure mode, if your prompt has “(config)#” then type “exit”.

Scroll through the output, you’ll be looking for the section titled “interface Dialer0″. Here is a trimmed down output of Dialer0 interface

Notice the line “ip access-group 101 in”, this tells us that we need to modify access-list 101 to enable port 22 inbound.

Lets get the current configuration of the access-list 101

Now lets insert a rule at the top of the ACL list to allow inbound SSH connections.

…and that’s it, you’ll now be able to SSH into your internal server on port 22. No reboot/reload required either!

If you went down the obfuscation path and you used port 2233, then rule would like

Lets have a quick look at what our access-list looks like now

Step 3: Save your config

If you are happy with your changes, save it to the startup-config

[author] [author_image timthumb='on']http://mcdee.com.au/wp-content/uploads/2012/11/photo.jpg[/author_image] [author_info]Andrew McDonald is an IT Systems Admin and all round technology junkie. Absolutely a jack-of-all-trades and not one to shy away from a challenge.


 [/author_info] [/author]

Tutorial – Install SSL Certificate in Apache Virtual Host on CentOS 6

In this tutorial I’ll take you through installing a SSL certificate and intermediate certificate in an Apache virtual host running on CentOS 6.

You’ll need to generate your servers private key which is used to create your certificate signing request (CSR) and also matched to your public SSL certificate. The CSR contains the details about the domain name, your organisation and server details. The CSR is passed onto the company you wish to purchase your certificate from. They use your CSR to create the public SSL certificate that your users need to access your web services securely.

The public SSL certificate that you get created must then be copied onto your server. You’ll then configure Apache to load that SSL Certificate, along with an intermediate certificate if required, to provide secure access to your web services (typically a website).

[box type="info"] Just note that this document assumes CentOS 6 for all example code and references. Syntax, file locations and codes may vary based on your distribution.[/box]

Step 1: Setup Simple Directory Structure

I like to maintain a simple directory structure for my SSL certificates, you may skip this step however just make sure you substitute my directory paths with yours.

Step 2: Generate Servers Private Key

You may already have a private key created for your server, however I’d suggest creating a new one. This due to the fact that most CSR’s require 2048bit encoding.

[box type="warning"] Note, you can set a pass phrase on your certificate to make it more secure, however the downside to doing this is that you will be prompted for the password everytime Apache starts up. Securing the key via file system permissions and general server security is my recommendation.[/box]
Check the file was generated where you wanted it

Change the file permissions so that only the root user can read the file

Step 3: Generate the CSR

Now we can generate our CSR, the entry fields are self explanatory.

[box type="info"] If you are wanting to generate a wildcard certificate ie. secure all subdomains, then all you need to is enter *.website.com for the Common Name prompt[/box]
Lets have a look at what a CSR looks like.

Step 4: Generate your Public SSL Certificate

This step will vary depending on the vendor you use. However you will be required to provide a copy of your CSR (as seen above). You’ll need to copy/paste all lines including the BEGIN/END certificate request lines into your vendors request system. I’d suggest reading their examples of this process.

Once you’ve successfully submitted your CSR, your vendor will then provide you a SSL certificate. It may be attached to an email as a .crt file, or could just be text in the body of an email. If they have provided you with just text, then copy/paste the text (including the BEGIN/END lines) into file on your server. If it’s a file then copy it onto your server.

I’d suggest naming and placing the SSL certificate file into

If you received instructions to install an intermediate certificate, then copy it as

Step 5: Configure Apache to use SSL

In this example I’ll show you how to install the SSL certificate into an virtual host. So firstly we need to make sure Apache is configured to support port 443 for name-based virtual hosting.

You’ll need to make sure that the line “NameVirtualHost *:443″ exists in your Apache configuration file.

If the above command doesn’t return any result, then you’ll need to add “NameVirtualHost *:443″ into httpd.conf. Just search for NameVirtualHost and add it on the next line.

Now you’ll need to add a new entry that contains your virtual host configuration for SSL. I would suggest you simply copy/paste your existing VirtualHost configuration and simply modify the directive to be . Then within the context of your newly created directive add the additional SSL settings. See below for an example:

…Restart Apache and you’re done!!

[author] [author_image timthumb='on']http://mcdee.com.au/wp-content/uploads/2012/11/photo.jpg[/author_image] [author_info]Andrew McDonald is an IT Systems Admin and all round technology junkie. Absolutely a jack-of-all-trades and not one to shy away from a challenge.


 [/author_info] [/author]

Solution – Oracle 11g Password Expiry ORA-28002

ERROR: ORA-28002: the password will expire within 6 days. Lets see what we can do about resolving this issue.

You could simply just change the users password. In an ideal and secure world, this is exactly what you would do. Though this may not be practical, there may be a whole host of reasons for postponing the change.

In Oracle 11g, users are assigned to a profile, the default profile is named “DEFAULT”. This default profile comes configured with a maximum password lifetime of a 180 days.

[box type="info"] Just note that this document’s steps have been performed on Oracle 11g Release 11.2.0.3.0 running on Red Hat Enterprise Linux 6.3. The SQL syntax provided “should” work on all Oracle 11g platforms.[/box]

Step 1: Identify the Users Profile

Log into Oracle 11g using SQL*Plus tool as sysdba

Lets confirm that the user is running the default profile. Note you must capitalize the username.

As you can see, the user has the profile of “DEFAULT” configured.

Step 2: View the Profile settings

Lets examine the settings of the profile

As you can see the PASSWORD_LIFE_TIME is to 180 days, you may configure this however you want.

Step 3: Set PASSWORD_LIFE_TIME

In this example, we’re going to make the password life unlimited so that it never expires. This may not be the wisest thing to do in a production environment. However there may be circumstances that require a password change at a later date.

To make this change we simply need to run the following command:

Step 4: Re-Enter the Password

You may notice that even after setting the password expiry to unlimited you are still getting the “ERROR: ORA-28002: the password will expire” message. I’m guessing this is due to additional processes that Oracle does in the background for checking password age etc. So this forces us to “reset” the password to it’s current value to remove the error.

This is done via the following SQL

Just note that the password must be double quoted and not single quoted.

…and that’s it, you should no longer receive the “ORA-28002: the password will expire” message for USER1 when logging in.

[box type="warning"] Just note that having never expiring passwords probably isn’t the best password policy to maintain. Oracle’s password expiration setting is a great way to remind users and admin’s to change their passwords regularly.[/box]

[author] [author_image timthumb='on']http://mcdee.com.au/wp-content/uploads/2012/11/photo.jpg[/author_image] [author_info]Andrew McDonald is an IT Systems Admin and all round technology junkie. Absolutely a jack-of-all-trades and not one to shy away from a challenge.


 [/author_info] [/author]

Tutorial – Passwordless SSH Using Private Keys with CentOS 6

This document we’ll go through the process of configuring SSH client to login without a password using a private key. This can be a convenient, fast and potentially more secure way to access a remote system… Best thing, it’s actually very simple to achieve!

Step 1: Generate Your Key

Start by being logged into your local system and generate your private key using the command “/usr/bin/ssh-keygen”:

We now have a generated private and public key set, the key’s are typically created as /home/user/.ssh/id_rsa & /home/user/.ssh/id_rsa.pub.

[box type="warning"] Beware that your private key is an extremely valuable file. It’s like storing your password in a file. If obtained, could be used by another person to access your systems. Back it up and keep it safe!![/box]

Step 2: Share Your Key

To use your private key, you must share your public key with a remote server. Simply put, the remote server keeps a copy of your public key, which it uses to match against your private when you attempt to login.

There is a utility which automatically installs our public key onto a remote host; ssh-copy-id. Obviously it won’t work unless you already know the password of the account on the remote host.

…and that’s it. The ssh-copy-id program automatically copied our shared key into /home/user/.ssh/authroized_keys file on server2.

Step 3: Login with no Password

Assuming you’ve followed the above steps, all you simply have to do now is login to the system as per normal.

..boom and you’re in, no password entry required!
[box type="info"] Just note that this document assumes CentOS 6 for all example code and references. Syntax, file locations and codes may vary based on your distribution.[/box]

[author] [author_image timthumb='on']http://mcdee.com.au/wp-content/uploads/2012/11/photo.jpg[/author_image] [author_info]Andrew McDonald is an IT Systems Admin and all round technology junkie. Absolutely a jack-of-all-trades and not one to shy away from a challenge.


 [/author_info] [/author]

Apache PHP-CGI SuExec Session Issues

After enabling php-cgi and suexec to handle your site in Apache, you may discover issues with your web applications working incorrectly. This could simply be a session issue which is result of the suexec user being unable to write into /var/lib/php/session directory.

[box type="info"] Just note that this document assumes CentOS 6 for all example code and references. Syntax, file locations and codes may vary based on your distribution.[/box]

You can verify this problem simply by looking websites error log.

First, lets identify the SuExec user configured for your site. Simply open your Apache configuration file and identify value set for “SuexecUserGroup”.

As you can see the value “user1″ has been set as the SuExec user. Now we need allow user1 access to the /var/lib/php/session directory. The simplest way to do this is to add user1 into the apache group. This is done by editing your /etc/group file and appending the line for the Apache group with your user.

Look for the apache group and append your user, save and close the file (:wq)

….and you’re done, you don’t even have to restart Apache.

[author] [author_image timthumb='on']http://mcdee.com.au/wp-content/uploads/2012/11/photo.jpg[/author_image] [author_info]Andrew McDonald is an IT Systems Admin and all round technology junkie. Absolutely a jack-of-all-trades and not one to shy away from a challenge.


 [/author_info] [/author]