Configuring Fedora 25 as a Hypervisor using Virtual Machine Manager

Introduction

After following the below instructions, you should be able to deploy VMs that:

  1. Can be accessed by IP from the Host
  2. Can communicate with each other
  3. Can communicate to the external network
  4. Are not accessible beyond your Host

While these instructions were performed on a Fedora 25 machine, they should work on other supported versions and few other distros with minimal command modifications.

Package Installation and Services

  1. Make sure your system is up to date and restart if necessary:
    • sudo dnf update -y ; reboot
  2. Install the required packages:
    • sudo dnf install virt-manager qemu-kvm qemu-img libvirt-daemon libvirt-daemon-driver*
  3. Start the Libvirt Daemon:
    • sudo systemctl start libvirtd

Configure the Virtual Network

This network will be accessible within your Host environment only and will be service IP Addresses by DHCP to your VMs.

  1. Open virt-manager by searching for it in the Gnome search bar, by finding it under the KDE applications menu, or by launching it through terminal using sudo virt-manager.
  2. Go to Edit – Connection Details.
  3. Click on the Virtual Networks tab and then click the plus (+) sign at the lower left corner of the window.
    1. For Network Name, choose something simple, such as “virtnet” and click Forward.
    2. Verify that Enable IPv4… and Enable DHCPv4 are both checked.
      • Network: 192.168.100.0/24 (example)
      • Start: 192.168.100.128 (example)
      • End: 192.168.100.254 (example)
    3. Click Forward twice to skip IPv6 DHCP configuration unless you plan on needing it for another reason than deploying more than 4.3 billion VMs.
    4. Select Forward to physical network and leave other settings default.
    5. Click Finish.

You should now be able to deploy new VMs without much difficulty.

Deploying a Fedora 25 Server Guest VM (Exercise #1)

With Fedora, it is easy to deploy a VM using HTTP.  This will ensure you are always deploying with the latest packages available.

  1. Within Virtual Machine Manager, go to File – New Virtual Machine, or click on the Create a new virtual machine icon _below_ File.
  2. Select Network Install and then click Forward.
  3. For URL, paste in the following link and then click Forward four times:

Manually assigning an IP Address from the Host (Exercise #2)

Libvirt uses dnsmasq to manage the DHCP range of newly deployed VMs.  Due to this, you are given some flexibility to have dnsmasq manually assign IP Addresses based off of the VM’s MAC Address.

For this example, I am using the VM I deployed from the first exercise.

  1. From terminal on the Host, grab the MAC address of the fedora25 VM that was deployed:
    • sudo virsh dumpxml fedora25 | grep 'mac address'
  2. Next, use the MAC address shown to give that VM a specific IP Address (192.168.100.21 in this example):
    • sudo virsh net-update virtnet add ip-dhcp-host "<host mac='######' name='fedora25' ip='192.168.100.#'/>" --live --config
  3. Finally, bounce the network adapter on the VM itself to grab the new IP.  Example:
    • sudo ifdown eth0 ; sudo ifup eth0

Example:

====== Fedora 25 Host

striker host ~ $ sudo virsh dumpxml fedora25 | grep ‘mac address’
<mac address=’52:54:00:a9:37:f0’/>

striker host ~ $ sudo virsh net-update virtnet add ip-dhcp-host “”<host mac=’52:54:00:a9:37:f0′ name=’fedora25′ ip=’192.168.100.21’/>” –live –config
Updated network virtnet persistent config and live state

====== Fedora 25 VM

[root@fedora25 ~]# ip a | grep ‘inet 192’
inet 192.168.100.250/24 brd 192.168.100.255 scope global dynamic ens3

[root@fedora25 ~]# ifdown ens3
Device ‘ens3’ successfully disconnected.

[root@fedora25 ~]# ifup ens3
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/1)

[root@fedora25 ~]# ip a | grep ‘inet 192’
inet 192.168.100.21/24 brd 192.168.100.255 scope global dynamic ens3

Adding a new Storage layer to a VM (Exercise #3)

This exercise will walk you through creating a virtual storage drive and attach it to your VM.  For the purpose of the exercise, I will be using the Fedora 25 Server VM deployed above.

  1. Within Virtual Machine Manager, highlight the VM you wish to add a new storage drive to and then click Open.
  2. Within the VM window, click the Lightbulb icon labeled Show virtual hardware details.
  3. In the bottom-left corner, click Add Hardware.
  4. Storage should be selected within the next window.  Choose the size you wish the new storage device to be and click Finish.
  5. Within the VM window, click on the Computer Monitor icon labeled Show the graphical console.
  6. You may need to restart the VM for the new storage device to show up.  Since we are using the Fedora 25 VM deployed above, the device shows up immediately:

[root@fedora25 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vdb 252:16 0 20G 0 disk   #   <———————–
vda 252:0 0 20G 0 disk
├─vda2 252:2 0 19G 0 part
│ ├─fedora-swap 253:1 0 2G 0 lvm [SWAP]
│ └─fedora-root 253:0 0 15G 0 lvm /
└─vda1 252:1 0 1G 0 part /boot

Stay in touch!

You can stay in touch with libvirt specialists by joining the OFTC IRC network and then joining the #virt channel.  Fedora’s IRC channel is #fedora on Freenode‘s IRC network.  You can also join the libvirt mailing list discussion by following the below link:

https://www.redhat.com/mailman/listinfo/libvir-list

Advertisements

Deploy Windows 2016 AD and Fedora 25 IPA with a One-way Trust

Introduction

For the purpose of this post, the two machines I used for these instructions are VMs running atop a Fedora 25 hypervisor which was configured as outlined here:

Configuring Fedora 25 as a Hypervisor using Virtual Machine Manager

Note: Make sure that when deploying IPA and AD that you do so on separate domains.  Otherwise, IPA clients will be querying the AD server directly when they dig the domain for ldap records.

INCORRECT: IPA Server: ipa01.example.com | AD Server: ad01.example.com
CORRECT: IPA Server: ipa01.linux.example.com | AD Server: ad01.example.com
CORRECT: IPA Server: ipa01.example.com | AD Server: ad01.win.example.com
CORRECT: IPA Server: ipa01.linux.example.com | AD Server: ad01.win.example.com
CORRECT: IPA Server: ipa01.somedomain.com | AD Server: ad01.otherdomain.com

Deploying Windows 2016 AD

  1. On my first VM, I booted using a Trial ISO of Windows Server 2016:
  2. Begin the installation with Windows Server 2016 Standard Evaluation (Desktop Experience).
  3. After the machine boots from installation, configure the Hostname:
    1. Server Manager – Local Server.
    2. Click on the machine’s current hostname.
    3. Click Change and change the hostname to your preference.
      • Example: win16ad01
  4. Configure Active Directory and DNS:
    1. Server Manager – Dashboard.
    2. Add Roles and Features.
    3. For Installation Type, choose Role-based or feature-based installation.
    4. For Server Roles, click Active Directory Domain Services and DNS Server.
    5. Within Server Manager, go to AD DS and click on More.
    6. Click on Promote this server to a domain….
    7. In the next window, choose Add a new Forest.
      • Here, set the full DN of your Forest.
        • Example: win.terranforge.com

Deploying Fedora 25 IPA

  1. For the second VM, I booted using the HTTP link to Fedora 25 Server:
  2. During pre-installation:
    1. Choose Minimal at Software Selection.
    2. In Network & Host Name, set the full hostname of the machine.
      • Example: f25ipa01.linux.terranforge.com
    3. Make sure to give /var a large amount of space, as this is where the IPA Database and Logs will be stored.
  3. After installation and reaching a root prompt:
    1. Install the IPA packages and the RNG package:
      • dnf install ipa-server ipa-server-dns ipa-server-trust-ad rng-tools -y
      • The RNG daemon will generate free entropy to be used during the certificate database creation, otherwise that process can take a very long time to complete.
    2. Open the correct ports that IPA will use:
      • firewall-cmd --add-service=freeipa-ldap --add-service=freeipa-ldaps --add-service=freeipa-trust --permanent
      • firewall-cmd --reload
    3. Start the RNG Daemon:
      • systemctl start rngd
    4. Configure the IPA instance:
      • ipa-server-install --setup-dns
        1. For Server host name, press Enter (Hostname was set during pre-install).
        2. For Domain name and Realm name, press Enter.
        3. Press Enter when prompted for DNS forwarders.
        4. For Enter an IP address for a DNS forwarder, enter the IP Address of your Windows 2016 AD.
        5. Type yes and press Enter to finalize the pre-configuration and begin installation.

Configure the One-way Trust

  1. From the Fedora root prompt, prepare IPA for the trust:
    • ipa-adtrust-install
    • All options should be default.
  2. Configure and Verify the trust:
    1. ipa trust-add --type=ad --admin Administrator --password
      • Example: ipa trust-add --type=ad win.terranforge.com --admin Administrator --password
    2. id administrator@win.terranforge.com

Get involved and ask questions

You can get in touch with the IPA community by joining the #freeipa and #sssd channels on Freenode and the freeipa-users and sssd-users mailing lists.

Password Corral on Linux

Password Corral (http://www.cygnusproductions.com/freeware/pc.asp) is one of the most simple, secure and easy to use password safes I have used.  When creating your password file which houses all of your passwords, you can choose between Blowfish or Diamond2 for an encryption method.  Both of which are pretty powerful.  You can read more about them here:

https://www.schneier.com/academic/blowfish/
ftp://www.funet.fi/pub/crypt/cryptography/papers/mpj/diamond.txt

Password Corral is an EXE.  This means that it was meant to be run on Windows-based OSes.  However, it is quite easy to also run this on a Linux machine with the help of Wine.

On my Fedora box, I simply do:

sudo dnf install wine
cd ~/Downloads
wget http://www.cygnusproductions.com/downloads/pc/pcns.zip
unzip pcns.zip

Afterwards, just run:

wine ~/Downloads/password4.exe

Password Corral will store your data within ‘~/Documents/Password Corral Data’ which is easy to backup and restore if needed.

A simple Password-generating Bash Script

Most password safes have a generator for the password field when you are making a new entry.  Password Corral is a good example of this.  However, if you’re like me and like doing most things in a terminal, I wrote a fairly simple bash script which you can place into a $PATH of your choice and execute from anywhere.  Here’s the interesting bits:

https://strikerttd.fedorapeople.org/files/scripts/randompass.sh.txt

#! /bin/bash

# This simple script will generate a password with the following:
# Uppercase Letter, Lowercase Letter, Number, Special Character
#
# Length of password is determined by a provided variable.
# The default password length is 8 characters.

rpassLN=’a-zA-Z0-9′
rpassS=’!-_@#$%^&*()+{}:<>?=’

echo ; echo “Generate random passwords.” ; echo
echo “How many? Default = 4” ; read rpassA
echo “How long? Default = 8” ; read rpassL

if [[ -z $rpassA ]]
then
rpassA=4
fi

if [[ -z $rpassL ]]
then
rpassL=8
fi

echo ; cat /dev/urandom | tr -dc “$rpassS$rpassLN” | fold -w ${rpassL} | head -n ${rpassA}

The best places to put this would be into ~/.local/bin or ~/bin (again, depending on your $PATH).  You can also remove or add to the symbols in ‘rpassS’ depending on your needs.  Just make sure that the dash (-) is not listed as the first symbol……

Generate your own Fandango Ticket QR Codes

Purchasing tickets online is great.  Being able to choose your seat while doing it is even better.  Why someone would request your Phone number in order to “text you your ticket” is beyond me.  Most of us have access to e-mail on our phones these days.

With Fandago, the process is pretty convoluted.  On your computer, you purchase your ticket.  You then have the option for them to “text it to you”.  The only thing they do is text you an HTTP link which contains the ticket.  Why not just give me this link from the get-go instead of wanting my phone number for spam purposes?

Well, stop giving Fandango your phone number.  I have found a better way.  It seems that the QR Code they send you is merely your confirmation purchase number.

CONFIRMATION #11457111*******

You can try it yourself.  The next time you get a QR Code (or use one of the old ones), scan it and see what shows.  So, what does this mean?  Well, this means you can simply copy the confirmation number (11457111*******) from your e-mail on your phone into a QR Code generator and just use that at the ticket booth to get your ticket.

Stop giving Fandango your phone numbers for no reason other than for them to store it for “marketing purposes”.

A simple backup script

It’s been some time since I have needed to do this, but I finally sat down last night and wrote a backup script so that I can keep my system backed up somewhere.  This script is designed to rsync your user’s ~ and root’s ~ to a Luks encrypted device.

I wanted to share the script after I had completed it.  You can find it here:
https://strikerttd.fedorapeople.org/files/scripts/backup-public.sh.txt

Basically, the script opens the Luks device, mounts it, runs rsync, creates a tarball of the fresh rsync data on the same Luks device and then un-mounts it before locking it again.  You will be prompted a few times to continue as it prepares and will be prompted for the Luks password during the un-lock phase.

#!/bin/bash

## Personalized RSYNC and TAR script by Striker Leggette
## Contact: striker@terranforge.com / striker on Freenode

backupUUID=<UUID of device goes here> #Example: backupUUID=f81d4fae-7dec-11d0-a765-00a0c91e6bf6

## See all Luks devices on the system: # blkid | grep crypto_LUKS | awk ‘{print $2}’

normalUser=<Username goes here> #Example: normalUser=bob

echo
echo “Starting your PRaTs..”
echo
echo “Will do the following:”
echo
echo “1. # cryptsetup luksOpen $(blkid | grep $backupUUID | cut -f1 -d”:”) $backupUUID”
echo “2. # mkdir -p /mnt/$backupUUID”
echo “3. # mount /dev/mapper/$backupUUID /mnt/$backupUUID”
echo “4. Two rsync commands to sync /home/$normalUser and /root to /mnt/$backupUUID/$(hostname -s)/”
echo “5. Tar the current backup of /mnt/$backupUUID/$(hostname -s)/ to /mnt/$backupUUID/$(hostname -s)_$(date +%F).tar.gz”
echo “6. # umount /mnt/$backupUUID”
echo “7. # cryptsetup luksClose /dev/mapper/$backupUUID”
echo

read -p “Ready? [y/n] ” answer
if [[ $answer = y ]] ; then
echo
echo “The current Luks devices attached to”
echo “the system have the following UUIDs:”
echo
echo “$(blkid | grep crypto_LUKS | awk ‘{print $2}’)”
echo
echo “We think the UUID of the backup drive is:”
echo “$backupUUID”
echo “…if this is incorrect, please fix the script.”
echo
echo “Attempting to unlock the backup drive now…”
cryptsetup luksOpen $(blkid | grep $backupUUID | cut -f1 -d”:”) $backupUUID
echo
echo “Attempting to mount the backup drive to:”
echo ” /mnt/$backupUUID”
mkdir -p /mnt/$backupUUID
mount /dev/mapper/$backupUUID /mnt/$backupUUID
#if [ ?$ != 0 ] ; then
# echo “Whoops! Check to make sure something not mounted there already…”
# echo
# echo “Locking device back…”
# cryptsetup luksClose /dev/mapper/$backupUUID
# exit
#else
echo
read -p “Everything is in order! Ready? [y/n] ” answer
if [[ $answer = y ]] ; then
######## RSYNC ########
mkdir -p /mnt/$backupUUID/$(hostname -s)/
#### Normal User
rsync -vrupREAXogt –progress –delete \
/home/$normalUser \
–exclude=/home/$normalUser/Downloads/NotBackedUp \
–exclude=/home/$normalUser/.local/share/Steam \
–exclude=/home/$normalUser/.cxoffice \
–exclude=/home/$normalUser/.wine \
/mnt/$backupUUID/$(hostname -s)/ #
#### Root Backup
rsync -vrupREAXogt –progress –delete \
/root \
/mnt/$backupUUID/$(hostname -s)/ #
######## RSYNC ########
echo
echo “###################################”
echo “######## RSYNC Backup Done ########”
echo “###################################”
echo
echo “Archiving backup to daily tarball:”
echo “/mnt/backup/$(hostname -s)_$(date +%F).tar.gz”
echo
######## TAR ########
tar czvpf /mnt/$backupUUID/$(hostname -s)_$(date +%F).tar.gz \
/mnt/$backupUUID/$(hostname -s)/ #
######## TAR ########
echo
echo “################################”
echo “######## Archiving Done ########”
echo “################################”
else
echo “Guess not…”
fi
#fi
echo
echo “Un-mounting /mnt/backup…”
umount /mnt/$backupUUID
echo
echo “Locking the Luks device…”
cryptsetup luksClose /dev/mapper/$backupUUID
echo
echo “All done!”
else
echo “Well, come back when you are!”
fi

You will need to modify the first couple of lines to suit your own needs, giving the script your Luks device’s UUID and then your username, but it should work nonetheless.  There’s a few missing pieces, including pre-existing mount checking and the possible addition of logging the script to a file, but basic functionality is there.

Authenticating to Fedora using Active Directory credentials that lack Unix attributes

This weekend at the SouthEast LinuxFest, I had a talk about how you can authenticate to Fedora using Active Directory credentials that lack Unix attributes.  Since newer deployments of the most recent versions of Active Directory no longer give you the ability by default to configure Unix attributes, it is important to know that this is not a show stopper.

In my talk, I showed how SSSD uses ID Mapping by converting an objectSID value from a user object from binary to a human-readable number and then runs that number through an algorithm to generate a UID.  It will do the same thing for group objects so that you also have GIDs.  Besides the UID and GID, SSSD has the ability to use a ‘fallback’ mode for home directory and shell locations.  This way, you can “fill in the blanks” of missing information.

Here is an example user object we used in the demonstration to show this:

ldapsearch -LLL -h coldharbour.win.terranforge.com -D Administrator@WIN.TERRANFORGE.COM -W -b dc=win,dc=terranforge,dc=com samaccountname=youknownothing

dn: CN=Jon Snow,CN=Users,DC=win,DC=terranforge,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Jon Snow
sn: Snow
givenName: Jon
distinguishedName: CN=Jon Snow,CN=Users,DC=win,DC=terranforge,DC=com
instanceType: 4
whenCreated: 20160610164605.0Z
whenChanged: 20160610164605.0Z
displayName: Jon Snow
uSNCreated: 20499
uSNChanged: 20504
name: Jon Snow
objectGUID:: Y7sOFvVwRkmrKNCJiXYkSw==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 131100507651203267
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAoKzsMxIUlCWCTFRxUQQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: youknownothing
sAMAccountType: 805306368
userPrincipalName: youknownothing@win.terranforge.com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=win,DC=terranforge,DC=
com
dSCorePropagationData: 16010101000000.0Z

# refldap://win.terranforge.com/CN=Configuration,DC=win,DC=terranforge,DC=com

As you can see, Jon Snow (youknownothing) lacks four of the things that POSIX compliant systems require a user to have: UID, GID, Home Directory and Shell.  However, on a Fedora 23 system that has been joined to the same AD domain, we can successfully see that the user DOES have a UID, GID, Home Directory and Shell:

[root@garden ~]# cat /etc/fedora-release
Fedora release 23 (Twenty Three)
[root@garden ~]# id youknownothing
uid=436801105(youknownothing) gid=436800513(domain users) groups=436800513(domain users)
[root@garden ~]# getent passwd youknownothing
youknownothing:*:436801105:436800513:Jon Snow:/home/youknownothing:/bin/bash

And, we can authenticate as that user to the Fedora system:

[root@garden ~]# ssh youknownothing@localhost
youknownothing@localhost’s password:
[youknownothing@garden ~]$ id
uid=436801105(youknownothing) gid=436800513(domain users) groups=436800513(domain users) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[youknownothing@garden ~]$

This happens successfully because SSSD is converting the binary SID value to a number, turning that number into a UID based off of an algorithm and then filling in whatever attributes are necessary for the POSIX-compliant system to accept the user as valid.  The only thing SSSD requires from AD to make this happen is an ‘id’, such as a username and the SID attribute.  In sssd.conf, we specify the Shell and Home Directory attributes:

[domain/win.terranforge.com]
id_provider = ad
ad_server = coldharbour.win.terranforge.com
default_shell=/bin/bash
fallback_homedir=/home/%u

[sssd]
services = nss, pam
config_file_version = 2
domains = win.terranforge.com

[nss]

[pam]

Using the ‘default_shell’ and ‘fallback_homedir’ options means that if SSSD does not find these attributes within AD, it will substitute what you give it.  In this case, /bin/bash and /home/%u.  This allows you to specify the unixHomeDir and unixShell attributes in AD for a user if you still desire to do so, and SSSD will use those.

To generate an UID and GID based off of the object’s SID value, SSSD’s ID Mapping algorithm is very similar to how Winbind’s autorid backend works.  This makes it trivial to move from older Winbind configurations to SSSD and continue to retain original UID and GID values.  Using SSSD in this fashion will make the UIDs and GIDs across all systems joined to AD consistent for each user and group, making things like file-sharing hassle-free.