Out of the box you are not going to be able to run virsh commands on the cli as root. Libvirt, Virsh, and KVM are just not that tightly integrated in RHEV.
You can however, follow the procedure below, and create a user and password to use for authentication.
# saslpasswd2 -a libvirt fatmin
Password:
Again (for verification):
Now enter the credentials you entered above.
# virsh list –all
Please enter your authentication name: fatmin
Please enter your password:
Id Name State
—————————————————-
10 HostedEngine running
Now you can shut down or start a VM. Here I am shutting down my RHEV HostedEngine.
# virsh destroy HostedEngine
Please enter your authentication name: fatmin
Please enter your password:
Domain HostedEngine destroyed
Grub, is the standard boot loader used by each and every Linux type operating system that I can think of. RHEL 6 uses what I guess we are now calling grub 1.o, since grub 2.0 has been released and in use by Fedora for the last few releases. You will also find that grub 2.0 has replaced grub 1.0 in RHEL 7. At some point I plan to explore grub 2 at lenght, but today is not that day (unless something strange happens before I go to bed tonight — you never know).
Anyway – I digress. Below is an excerpt from the current grub.conf that is in use by my EC2 RHEL 6.5 instance. I've made it really tiny to save space.
# grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You do not have a /boot partition. This means that # all kernel and initrd paths are relative to /, eg. # root (hd0) # kernel /boot/vmlinuz-version console=ttyS0 ro root=/dev/vda1 # initrd /boot/initrd-[generic-]version.img #boot=/dev/vda default=0 timeout=1
splashimage=(hd0)/boot/grub/splash.xpm.gz
hiddenmenu title Red Hat Enterprise Linux Server (2.6.32-431.17.1.el6.x86_64) root (hd0) kernel /boot/vmlinuz-2.6.32-431.17.1.el6.x86_64 console=ttyS0 ro root=UUID=05e7b919-2577-40a7-91fb-1ccdede87fc4 rd_NO_LUKS KEYBOARDTYPE=pc KEYTABLE=us LANG=en_US.UTF-8 xen_blkfront.sda_is_xvda=1 console=ttyS0,115200n8 console=tty0 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_NO_LVM rd_NO_DM rhgb quiet initrd /boot/initramfs-2.6.32-431.17.1.el6.x86_64.img
To configure a password to use for grub you need to use the grub-crypt command. as you can see in the example below, grub-crypt prompts you for your password, although you can also pass the password to grub-crypt in the inital command. Grub-crypt spits out your hashed and salted password.
You have a couple of options when inserting the password into the grub.conf. You can either stick this entry near the top of the file, which protects each and every boot image that you might be configured to use, or you can stick the entry directly into a particular stanza to protect a specific boot image. For example, if you are building your servers with the option to pxe-boot from grub, or wipe the disk from grub, you might want to protect these options with a password.
Also note that adding a password to grub does not keep an unauthorized user from being able to boot or reboot a server, rather what it does is protect the grub menu from being edited manually durring a reboot. This keeps nefarious users from being able to break the boot sequence and boot into single-user mode where they can compromise your system.
Plugable Authentication Modules, or PAM, is the standard mechanism that most Unix and Linux Operatng Systems use for user credential authentication. By design, PAM is broken out into a number of files, each with a specific purpose. Before you can get started with PAM you need to understand a bit about how PAM configuration files are formatted. So lets get into that first before we try to bite off anything more.
PAM Config File Standards:
PAM config files follow a standard format as shown below.
Rule Types Control Module [module arguments]
There are 4 Rule Types
auth – used to authenticate users/passwords
account – set properties for a user's account
password – controls password changes
session – sets and controls environmental variables
And there are 5 Control Types
required – a module that a user is required to pass
sufficient – a user is not required to pass a sufficient module
optional – these modules do not have to be passed sucessfully
include – these rules reference other PAM config files
requisite – similar to required, but if failed, no further rules are checked
Configuring pam_cracklib:
Pam_cracklib is used to define password complexity. It has several module arguments that can be used to define password complexity and lenght. Its most common arguments are show below
ucredit – when used in the following format (ucredit=-n) requires the defined number of uppercase characters in a password
dcredit – when used in the following format (dcredit=-n) requires the defined number of digits in a password
ocredit – when used in the following format (ocredit=-n) requires the defined number of other (think symbols) type charaters in a password
lcredit – when used in the following format (lcredit=-n) requires the defined number of lower case letters in a password
minclass – defines the minimum number of different character classes that must be present in a password.
minlen – defines the minimum required lenght of a password.
Here's a usage example of the cracklib module from a /etc/pam.d/system-auth file. In this example try_first_pass tells pam to try to use any cached credentials, while retry allows a user to try their password 3 times before the fail this module.
Pam_tally2 can be used to lock users after a defined number of failed login attempts. The example below, taken from the system-auth file will lock a user after 3 failed login attempts, will automatically unlock the user after 300 seconds, and will do so quietly, without any notification to the user.
The command pam_tally2 can be used to list users with failed logins and can also be used to reset a user's failed login count. See reset example below
pam_tally2 –reset –u testuser
Note that pam_tally2 deprecates the faillock module.
Supplementary PAM Configuration Options:
Want to limit a user to a particular number of concurrent ssh sessions? You can set this up in /etc/security/limits.conf if you are calling the pam_limits.so in your pam configs. Limits.conf provides the example below. Just copy the format and you are off to the races. Remember to remove the #.
Hello again earthlings. The fatmin returns once again to dispense a bit of wisdom. This handy one-liner is a command that for the life of me I cannot remember.
Our story begings when building your kickstart config and post-install config files you are going to need to set the password for at least one user (being root). If you are like me your configs add all sorts of users. As you know you cannot just stick the password for these users into your config files in plain text, rather you need to encrypt them via ssl.
The command to do so is below.
openssl passwd -1
At this point you will be prompted to enter the users password — twice. Then the command will spit out your ssl encrypted password which you can then shove into your config files.
Sure enough, and right as rain I am back with something that is not about networking (yeah!) and not about Solaris (boo!).
This is a short story about how we had a user who was a member of our database team who was attempting to make modifications to the oracle user’s crontab. They kept running into the error below.
Authentication token expired
You (oracle) are not allowed to access to (crontab) because of pam configuration.
Remembering that the oracle account is a special account without a password, or the ability to login, I figured that it had something to do with the fact the lack or password or something related.
I used the chage command to determine that while the password was not expired, rather that the account was considered inactive. Probably due to the fact that we locked down login permissions for service users on this box, but did not take into account that this user needed to login from time to time to keep the account from becoming inactive.
# chage -l oracle
Last password change : Mar 25, 2013
Password expires : Apr 22, 2013
Password inactive : May 06, 2013
Account expires : never
Minimum number of days between password change : 7
Maximum number of days between password change : 28
Number of days of warning before password expires : 7
Now whats funny about this issue is that its pretty much a time bomb waiting to go off. You lock down logins for service accounts and forget to modify the inactive or expiration dates, and some day in the near future your users cron jobs will stop running, which possibly could cause all hell to break loose depending on whats running out of cron.
The fix is as follows.
# chage -I -1 -m 0 -M 99999 -E -1 oracle
Then use chage again to check out the sexy new settings
# chage -l oracle
Last password change : Mar 25, 2013
Password expires : never
Password inactive : never
Account expires : never
Minimum number of days between password change : 0
Maximum number of days between password change : 99999
Number of days of warning before password expires : 7
To understand the chage command if might be best to make sure that you understand the /etc/shadow file, so lets look at a line from mine. Note that “:” is the field separator.
Date of Last Password Change in days since the dawn of Unix Time
Minimum Password Age
Maximum Password Age
Password Warning Period
Password Inactive Period
Account Expiration
The basic options of the chage command are as follows
-M Max Days
-m Min Days
-I inactive
-E Expiry Date
-D 0 Force Password Change
So first lets take a look at the current settings for user “chris”. You will see that the entries below match the options listed above.
# chage -l chris
Last password change : Aug 02, 2011 Password expires : never Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 99999 Number of days of warning before password expires : 7
So lets say that we want to force user chris to update his password on next login
#chage -d 0 chris
and then set a minimum number of days of 10 between password changes
#chage -m 10 chris
or set an expiration date of 10/10/2020
#chage -E 10/10/2020 chris
You get the idea…
Anyway the chage command can be run interactively as well if you do not pass any options to the command other than the username.
