Build a CentOS7 server for: pxe boot, kickstart, reposync, repotrack, nfs, https (STEP 14)

STEP 14 – Test PXE Boot and Kickstart installation.

Just create a new VM instance, and don’t provide it with any installation media.
Of course it will need a vdisk for the installation to work, use ~6 or 8gb set as NVMe.
For headless servers, there usually isn’t any need for Bluetooth, Sound, 3D Video, or a Printer Port. I remove all of those from VM hardware profile.
The PXE/Kickstart install image the clients will boot utilizes a ramdisk. In current/recent versions of CentOS, Fedora, RedHat, and Oracle linux clients need 1,536 MB of vRAM to load this installation image.  As soon as the installation is completed, and the VM is capable from using it’s own disk, then the VM hardware memory allocation can be reduced… for many of my server VMs, I set it at 512MB.
1 vCPU is adequate.
Of course it will need a virtual network interface configured on the same VMNET as Fusion is providing DHCP with the PXE (“next-server”) option.
That’s it… start the VM.
If it works, there will be a lot of scrolling text… then eventually a prompt to quit/reboot… and you’ll have a working VM.
If something goes wrong, watch the screens, it’ll provide pretty good clues.  There are also methods to access (tail) the installation logs… but I’ll leave you to read up on that.  Most of the problems with relatively simple PXE/Kickstart setups like this are due to typos in the *.ks script or the “default” pxe boot menu.

 

Build a CentOS7 server for: pxe boot, kickstart, reposync, repotrack, nfs, https (STEP 13)

STEP 13 – Provide PXE boot server info to DHCP clients, via VMware Fusion vnet config (not a CentOS DHCP server).

This config is on the VMware host.  In my case, that’s a MacOS Mojave MacBook Pro running VMware Fusion. Any recent VMware hypervisors (Fusion, Workstation ESXi) are capable of providing this. VirtualBox and Parallels can to.  This scope of this guide is staying with VMware Fusion on MacOS.

Fusion doesn’t provide a GUI interface for the DHCP PXE Boot Server option. But it does support a lot of additional features through config files and/or the command line.
For this step, open a MacOS Terminal window, and:
sudo su
nano /Library/Preferences/VMware\ Fusion/vmnet2/dhcpd.conf
Put this after the “DO NOT MODIFY” section of stuff… it’s “reimplementing the subnet”…
note: on the PXE Boot Server, the “pxelinux.0″ file can be put in a subfolder, and then referenced in the DHCP config with this syntax ”  filename “pxelinux/pxelinux.0”;
My PXE server is providing the pxelinux.0 file at the default root of the tftpserver.
           the vnet dhcp config is a little less than obvious…
           the PXE Boot TFTP Server is represented by:  “next-server 10.0.0.11”

subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.128 10.0.0.254;
option broadcast-address 10.0.0.255;
option domain-name-servers 10.0.0.2;
option domain-name localdomain;
default-lease-time 1800;                # default is 30 minutes
max-lease-time 7200;                    # default is 2 hours
option netbios-name-servers 10.0.0.2;
option routers 10.0.0.2;
next-server 10.0.0.11;  
  filename “pxelinux.0”;
}
host vmnet2 {
hardware ethernet 00:55:55:C0:22:22;
fixed-address 10.0.0.1;
option domain-name-servers 0.0.0.0;
option domain-name “”;
option routers 0.0.0.0;
}

* for simplicity, this VMNET config uses an entire class c range (private/non-routable of course), and then allocates the bottom half for static IP and lets the DHCP process serve the top half.


TO RESTART FUSION DHCP SERVICE: without shutting down/restarting VMs/Fusion
(2019-02-22):
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli –stop   
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli –start

Build a CentOS7 server for: pxe boot, kickstart, reposync, repotrack, nfs, https (STEP 12)

STEP 12 – Put the required PXE client boot files in place.

We’re going to make a folder structure that supports two Distro/Release/Arch versions to start with, and can easily be updated with additional versions down the road.
mkdir /var/lib/tftpboot/CentOS7x64/
mkdir /var/lib/tftpboot/CentOS7x32/
Now, to copy the minimum boot files over to the tftpserver… we need to mount an installation media ISO… such as “CentOS-7-x86_64-NetInstall-1810.iso” for CentOS 7 64-bit, and cp the boot files to the tftboot directories.
The exact details of mounting media (ISOs) can vary…
I’m doing this on VMware Fusion, and the vm has open-vm-tools installed and active, so, my method is to use vmware to choose and connect the disc image to the VM, then, within the vm:
mount /dev/cdrom/ /mnt/cdrom/
cd /mnt/cdrom/isolinux/   # purely optional, just to see what’s there.
ls -l /mnt/cdrom/isolinux/    # purely optional, just to see what’s there.
#
cp /mnt/cdrom/isolinux/{vmlinuz,initrd.img,splash.png} /var/lib/tftpboot/CentOS7x64/
If you’re running a GUI Desktop (GNOME) on your VM, it might auto-mount the cd-rom, and this might be your command line option for copying the files:
# cp /run/media/{username}/CentOS\ 7\ x86_64/isolinux/{vmlinuz,initrd.img,splash.png} /var/lib/tftpboot/CentOS7x64/
# cp /run/media/elmer/CentOS\ 7\ x86_64/isolinux/{vmlinuz,initrd.img,splash.png} /var/lib/tftpboot/CentOS7x64/
#
cd /var/lib/tftpboot/CentOS7x64/ # verify cp results.
Now, we also need to copy “LiveOS” from that bootable iso:
mkdir /var/www/html/repos/c7x64/base/LiveOS
mkdir /var/www/html/repos/c7x32/base/LiveOS
NOTE: in the section “Create a PXE BOOT MENU”, the menu provides different versions of vmlinuz + initrd.img,
  • this is how/where those are provided to the PXE/Kickstart clients.
  • Each targeted Distro/Release/Arch requires a matching “LiveOS” be provided.
  • When the client node boots into this image, this is what runs the Anaconda installer (and processes the kickstart script).
  • cp /mnt/cdrom/LiveOS/* /var/www/html/repos/c7x64/base/LiveOS/
  • # OR: cp /run/media/{username}/CentOS\ 7\ x86_64/LiveOS/* /var/www/html/repos/c7x64/base/LiveOS/
  • # cp /run/media/elmer/CentOS\ 7\ x86_64/LiveOS/* /var/www/html/repos/c7x64/base/LiveOS/

Now, switch to the the 32 bit ISO and cp those files as well:

  • umount /dev/cdrom
For VMware Fusion: choose/connect a CentOS 7 32-bit ISO (like CentOS-7-i386-NetInstall-1810.iso)
  • mount /dev/cdrom/ /mnt/cdrom/
  • cp /mnt/cdrom/isolinux/{vmlinuz,initrd.img,splash.png} /var/lib/tftpboot/CentOS7x32/
  • cp /mnt/cdrom/LiveOS/* /var/www/html/repos/c7x32/base/LiveOS/

Build a CentOS7 server for: pxe boot, kickstart, reposync, repotrack, nfs, https (STEP 11)

STEP 11 – create the kickstart files referenced by the PXE Boot menu:
Here is one of my files. Use it as a template. Copy/paste/edit as needed.
# file = lab1x64.ks

# version=DEVEL
# ###############################################
# 2019-03-22: Kickstart script for client “c7lab1.lab.domain.net c7lab1.local c7lab1”.
#             Serve “lab1x64.ks” at ks=http://10.0.0.11/repos/lab1x64.ks
#             Client VM uses DISK TYPE = NVMe.
#             This ks successfully omits “dracut rescue images” from “/boot”.
#             Also omits a lot of other package bloat that a Virtual Server doesn’t need.
#
# If you want a different kickstart config, you’ll need to research the options.
# One way to get a good example config is to manually do an install with the
# options you want.  Then, on the resulting system, look in “/root/anaconda-ks.cfg”
# and use that as your kickstart template.
# ###############################################
firewall –enabled –service=ssh –service=mdns
selinux –permissive
# System authorization information
auth –enableshadow –passalgo=sha512
# ###############################################
repo –name=updates –baseurl=http://10.0.0.11/repos/c7x64/updates/
repo –name=epel –baseurl=http://10.0.0.11/repos/c7x64/epel/
repo –name=extras –baseurl=http://10.0.0.11/repos/c7x64/extras/
# ###############################################
# Use text mode install
text
# Do not configure the X Window System
skipx
# ###############################################
# Run the Setup Agent on first boot
firstboot –enable
# Keyboard layouts
keyboard –vckeymap=us –xlayouts=’us’
# System language
lang en_US.UTF-8
#
# NETWORK information
network  –bootproto=dhcp –device=ens33 –noipv6 –activate –hostname=c7lab1.lab.domain.net
# Root password
rootpw –iscrypted $6$iBFA4yWORTlm1Dnt$zPYZ.ArpJiPQQ8DKrtx8J.kaiIUHpCXxhPBN85smQBHwCtLr8u2tQEa3P.fXrKHiWRZ6qnTseZNDsi78Sk/0H1
# note: the plaintext of this password is “elmer”.
# DONT USE THAT.
# Choose your own password, use this terminal command to hash it, and paste output back here.
# python -c ‘import crypt,getpass;pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass(“Confirm: “)) else exit())’
#
# System services
services –enabled=sshd
#
# System timezone
timezone America/Chicago –isUtc
#
user –groups=wheel –name=elmer –password=$6$iBFA4yWORTlm1Dnt$zPYZ.ArpJiPQQ8DKrtx8J.kaiIUHpCXxhPBN85smQBHwCtLr8u2tQEa3P.fXrKHiWRZ6qnTseZNDsi78Sk/0H1 –iscrypted –gecos=”elmer”
#
# ###############################################
ignoredisk –only-use=nvme0n1   # use this if VM DISK TYPE = NVMe
# System bootloader configuration
bootloader –location=mbr –boot-drive=nvme0n1  # use this if VM DISK TYPE = NVMe
#
# Partition clearing information
clearpart –none –initlabel
#
# I’ve chosen to allocate 512 MiB to “/boot”, and automatically allocate all remaining space to “/”.
# Disk partitioning information:
part /boot –fstype=”xfs” –ondisk=nvme0n1 –size=512 # if VM DISK TYPE = NVMe
part pv.252 –fstype=”lvmpv” –ondisk=nvme0n1 –size 1 –grow # if VM DISK TYPE = NVMe
#
volgroup centos –pesize=4096 pv.252
logvol /  –fstype=”xfs” –name=root –vgname=centos –percent=100      # auto allocate remaining space to “/”
# ###############################################
# Selecting and excluding packages is often a “trial and error” endeavor.
# If you haven’t been down this rabbit hole before, you’ll be surprised by
# some of the unexpected dependencies between packages,
# that usually should not have any interdependencies at all.
#
%packages –instLangs=en_US.utf8 –ignoremissing –excludedocs
@core –nodefaults
# ###############################################
# my list of frequently used packages:
epel-release   # extras#
yum-utils        # base  # installs 337k
deltarpm        # base  # installs 209k
nano               # base # downloads 440k, installs 1.6M
nss-mdns       # EPEL  # installs 131K
htop               # EPEL # installs 281K
rng-tools       # base # downloads 49k, installs 102k
#
# ip address, nmtui, top       # base # included with @core.
# make, gzip, tar, curl           # base # included with @core.
# open-vm-tools                     # base # installed with @core, provides vmware-hgfsclient, vmhgfs-fuse, vmware-toolbox-cmd.
# ###############################################
# firmware packages to exclude:
-aic*-firmware
-alsa*
-atm*-firmware
-b43-openfwwf
-bfa-firmware
-fprintd-pam
-intltool
-ipw*-firmware
-ivtv* # skips a set of big video packages
-iwl*-firmware # skips a lot of unecessary firmware packages (mostly intel wifi).
-libertas* # skips a lot of unecessary firmware packages.
-linux-firmware # note: the installer will ignore this one; so remove it in POST.
-ql2100-firmware
-ql2200-firmware
-ql23xx-firmware
-ql2400-firmware
-ql2500-firmware
-rt61pci-firmware
-rt73usb-firmware
-xorg-x11-drv-ati-firmware
-zd1211-firmware
# ###############################################
# some more exclusions
-centos-logos           # try it… saves 22MB; unfortunately there are a lot of apps (like httpd that pull it in).
-crontabs
-dracut-config-rescue   # This saves a lot of space “/boot/”
# -GeoIP # looking up IP/Country isn’t something I need on these VMs, but “dhclient” requires it.
-iprutils
-kernel-tools
-libteam                # this is for “network interface teaming”, not something I need.
-man-db               # Useful, but I don’t need it on every VM in the fleet.
-mozjs17                # seems weird to have a javascript package on a baseline headless server.
-NetworkManager-team    # this is for “network interface teaming”, not something I need.
-newt-python                       # part of a set of packages that do GUI things.
-openssh-clients                 # these server VM instances do NOT need to make outbound SSH client connections.
-plymouth                            # this is the “pretty” boot screen, serves no purpose on a headless VM.
-plymouth-core-libs           #
-postfix                                # an email server.
-sg3_utils                   # related to SCSI devices, which this VM hardware profile does not have.
-sg3_utils-libs           #
-snappy                      # a compression utility, one of many, and not one of the best.
# -wpa_supplicant       # seems dumb to have this for a system that can’t do wifi; but NetworkManager and NMTUI require it.
# ###############################################
%end
# ###############################################
#
#
# ###############################################
# ADDON section of KICKSTART SCRIPT:
%addon com_redhat_kdump –disable –reserve-mb=’auto’
%end
# ###############################################
# “post” section of KICKSTART SCRIPT:
%post –log=/root/ks-post.log
#
# enable the vmware shared folders (makes them available on 1st boot):
mkdir /mnt/hgfs
echo “” >> /etc/fstab
echo “# enable vmware shared folders: ” >> /etc/fstab
echo “.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other 0 0” >> /etc/fstab
echo ” ” >> /etc/fstab
# setup the c7pxe YUM REPO config:
rm -f /etc/yum.repos.d/*
curl -o /etc/yum.repos.d/c7x64.repo http://10.0.0.11/repos/client-files/c7x64.repo
# copy standard scripts into $HOME:
curl -o /home/elmer/shrink-disk.sh http://10.0.0.11/repos/client-files/shrink-disk.sh
curl -o /home/elmer/yum-clean.sh http://10.0.0.11/repos/client-files/yum-clean.sh
curl -o /home/elmer/backupConfigFiles.sh http://10.0.0.11/repos/client-files/backupConfigFiles.sh
chmod +x /home/elmer/shrink-disk.sh
chmod +x /home/elmer/yum-clean.sh
chmod +x /home/elmer/backupConfigFiles.sh
touch /home/elmer/.vm-installed-by-PXE-lab1x64.sh
# clean out the yum cache, and remove the unecessary “linux-firmare” package (it’s about 175 MB):
yum clean all
yum -y remove linux-firmware
yum clean all
%end
# ###############################################
#
#
# ###############################################
# ANACONDA section of KICKSTART SCRIPT:
%anaconda
pwpolicy root –minlen=6 –minquality=1 –notstrict –nochanges –notempty
pwpolicy user –minlen=6 –minquality=1 –notstrict –nochanges –emptyok
pwpolicy luks –minlen=6 –minquality=1 –notstrict –nochanges –notempty
%end
# ###############################################

Build a CentOS7 server for: pxe boot, kickstart, reposync, repotrack, nfs, https (STEP 9)

STEP 9 – ENABLE and CONFIGURE PXE:
note: This does NOT require CentOS/RHEL to provide NTP, DHCP, DNSMASQ/BIND, vsftd, or xinetd.  The VMware Fusion VMNET2 DHCP scope can provide PXE Server location to clients.

  • enable firewall port for tftp
  • enable the service.
    • systemctl start tftp.socket
    • systemctl enable tftp.socket
  • put some important files into the tftp server location:
    • cd /var/lib/tftpboot                                  # // it starts out empty.
    • cp /usr/share/syslinux/{pxelinux.0,vesamenu.c32} .    # // now it has those two files in it.
  • Create a menu for the PXE Service… (the options a client machine gets):
    • mkdir /var/lib/tftpboot/pxelinux.cfg
    • cd /var/lib/tftpboot/pxelinux.cfg/
    • nano default
* In the next step, I’ll provide a detailed example of a /var/lib/tftpboot/pxelinux.cfg/default PXE BOOT MENU.

Build a CentOS7 server for: pxe boot, kickstart, reposync, repotrack, nfs, https (introduction)

INTRODUCTION:  Overview of the starting point for this install, and reasons why to do it.
I’ve been building/tweaking baseline CentOS installs for quite awhile. For CentOS 7 64-bit, I’ve “standardized” on a config that uses ~550 MB of vdisk and runs in ~ 120 MB of vRAM (512 MB allocated to the VM).
  • CentOS 7.x Linux 64-bit, NO GUI desktop, HTTPD, PXE, Kickstart, RepoSync+RepoTrack, NFS.
  • Begin with by making a full clone from existing VM c7baseline.
  • two vDisks:
    • 20GB for RepoSync at “/var/www/html/repos/” hdd=”c7pxe-repos.vmdk”
    • 6GB for /boot and “/” hdd=”c7baseline-d1.vmdk”
  • entry for “/etc/hosts”: 10.0.0.11 c7pxe.lab.domain.net c7pxe.local c7pxe
  • VM is configured with a static IP using VMware Fusion VMNET2
  • Only user is “elmer”.  Elmer has administrative (sudo) privileges.

This baseline has:
  • SELinux=permissive
  • firewalld is enabled and configured, with only SSH and nss-mdns in from local subnet.
  • repo EPEL is enabled.
  • KDUMP and SWAP were disabled during install.
  • has these packages: ip address, nmtui, gzip, tar, top, curl, epel-release, yum-utils, deltarpm, nano, nss-mdns, htop, rng-tools, rsync.
  • Avahi is running, so I can use *.local name resolution and skip more complicated DNS and/or host file configurations.
  • open-vm-tools is running. I have a couple folders shared into the VM for getting scripts and outputting config backups.
  • SSHD is running.  I do most of my activity via a host MacOS terminal ssh connection.
  • I use nano as editor on CentOS VMs.  If you prefer vi, emacs, or something else… thats ok with me.
  • The VM gets TIME from the host, via hypervisor/open-vm-tools, so it doesn’t need NTP or Chrony.
  • Virtual hardware items Printer, Sound, USB, Camera, and Bluetooth have been removed from the VM config.
  • The VM using NVMe for hard disks and SATA for cdrom.  No IDE or SCSI.
  • The reduced hardware profile enables removing a lot of firmware packages from these VMs.

It’s easy/fast to make a ZIP backup copy of an entire VM, so I’m moderately aggressive with removing things like dracut emergency/rescue packages, old kernels, yum caches, etc.  If I break a VM, I just revert to a previous backup.

With VMs under 20GB in size, making ZIP backups via the host OS filesystem is often faster than managing VMware snapshots.  Also, I like knowing that I have fully contained/atomic backups set to the side and quickly available if needed.

I have some custom scripts that clean up the VM contents and shrink the vdisk (to reduce disk usage on host system).

There are many options to further minimize and harden these VMs, but this current baseline maintains normal CentOS/Fedora/RHEL/Oracle functionality and compatibility.


Using a local RepoSync + RepoTrack enables installs/updates without internet for the target nodes, it speeds up the install/update time for all of the VMs, and it provide much better awareness/control over what packages are getting installed.
Using PXE/Kickstart automates a lot of the tedious/repetitive installation activities.  Doing kickstarts from local repos eliminates the need for maintaining a collection of downloaded ISOs.
An instance installed from ISO immediately needs updates; but kickstart from local repos takes care of that during the initial install.
Additionally, kickstart can run “%POST” activities to perform more setup/config work, even installing and fully configuring software applications.

Build a CentOS7 server for: pxe boot, kickstart, reposync, repotrack, nfs, https (summary of steps)

  • INTRODUCTION:  Overview of the starting point for this install, and reasons why to do it.
  • STEP  1 – clone an existing “minimal” VM (or build one).
  • STEP  2 – prepare to install/config PXE/RepoSync/RepoTrack (load software packages).
  • STEP  3 – add/config a 2nd virtual hard disk for the repo files.
  • STEP  4 – CONFIG RepoSync/RepoTrack to support multiple OS Distros, Releases, and Architectures.
  • STEP  5 – configure an EXCLUDE LINE for YUM CONFIG files
  • STEP  6 – build REPOSYNC commands for SCRIPT “rs-c7x64-update.sh”
  • STEP  7 – CREATE /etc/yum.repos.d/c7x64.repo for the CentOS 7 64-bit REPOSYNC CLIENTS
  • STEP  8 – CREATE /etc/yum.repos.d/c7x32.repo for the CentOS 7 32-bit REPOSYNC CLIENTS
  • STEP  9 – ENABLE and CONFIGURE PXE (uses vmware dhcp; does not require CentOS NTP/DHCP/DNS/vsftd/xinetd)
  • STEP 10 – Create a PXE BOOT MENU
  • STEP 11 – create the kickstart files referenced by the PXE Boot menu:
  • STEP 12 – Put the required PXE client boot files in place.
  • STEP 13 – Provide PXE boot server info to DHCP clients, via VMware Fusion vnet config (not a CentOS DHCP server).
  • STEP 14 – Test PXE Boot and Kickstart installation.
  • SIDEBAR 1 – Alternate ways to provide PXE BOOT IMAGES to clients (a brief summary)
  • SIDEBAR 2 – Optional NFS SHARE: convenient for exploring repo contents from a gui desktop VM.
  • SIDEBAR 3 – PXE client note re memory:  the boot image uses a ramdisk.

OS X, Fusion, command line, VMs as daemons…

somewhat random string of notes created while exploring options to run VMware Fusion VMs on system boot (prior to user login).  ie., looking at ways to start the VMs from a system level daemon… launchd, continuously running, independent of user logins.

* don’t want to leave this as root… need to create a service account for starting/running the VMs… and allow specific users to SU to that service if/when they need to use the Fusion app for gui interaction with the running VM(s).

… resume this later …

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

start & stop VMs with command line (or script)

  • OS X 10.8.2 Mountain Lion
  • VMware Fusion 5.0.2
  • 2012 MacBook Pro Retina 13″, 2.5Ghz i5, 8GB Ram

some command line options for vmrun:

sudo su

  • if vmrun is executed as root, the resulting PID will belong to root.  if a user uses the desktop gui to launch “VMware Fusion.app”, they will not be able to interact with the VM… and attempting to launch it from the GUI Virtual Machine Library will display an error (the executing PID will be unaffected).
  • if vmrum is executed as a user, the resulting PID will belong to that user.  if the same user then used the desktop guy to launch “VMware Fusion.app”, Fusion will immediately create a GUI display for the running VM(s).  Although the VM was launched from the command line as “nogui”, starting Fusion effectively converted the VM to “gui” mode.  Any attempt to quit/close the Fusion GUI will result in the closure/shutdown of the running VM(s).
  • if vmrun is executed as root, and then “/Applications/VMware\ Fusion.app/Contents/MacOS/VMware\ Fusion” is also executed as root… this will result in a desktop GUI instance of Fusion with a connection to the VMs… ie., converts the VM from “nogui” to “gui”.  Closing the Fusion app via it’s menu options will shutdown the VM… however, using the Activity Monitor “Quit Process” function seems to leave the VM running just fine.
  • follow up by testing with a “service account” instead of “sudo su”.
  • and verify the VM remains functional with remote login/tests to the VM(s).

So…

  • to start a VM in “headless” mode… use the command line “nogui” option.
  • to make a “gui” connection to the VM, launch the Fusion app using the same user.
  • to resume “headless” mode, close Fusion gui with Activity Monitor “Quit Process”.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  • /Applications/VMware Fusion.app/Contents/Library/vmrun
  • vmrun -T fusion <path to VM> nogui
  • vmrun -T fusion list

…/vmrun -T fusion start …/[vmname].vmwarevm/[vmname].vmx nogui

/Applications/VMware\ Fusion.app/Contents/Library/vmrun -T fusion start $HOME/VMwareVMs/TestImage.vmwarevm/TestImage.vmx nogui

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

…/vmrun -T fusion list

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

…/vmrun -T fusion stop …/[vmname].vmwarevm/[vmname].vmx soft

 

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To see ALL the daemons currently running, you need to type:

sudo launchctl list

And then you can remove it, for example:

sudo launchctl remove com.sassafras.KeyAccess.daemon

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

GUI utility to view/edit agents & daemons.

Lingon 2.1.1 by Peter Borg.  Displays existing items. Edits plist files.  Creates the plist file when creating a new agent.

note: Newer versions of the app are only available from the Mac App Store and (due to GateKeeper / app rules) no longer have the ability to work on system agents/daemons.  The App Store version is limited to the current log’d in user only.  But the older 2.1.1 (2008-12-18) still works under Mountain Lion OS X 10.8.2 and is able to create or edit new agents and daemons.

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

d

d

Reduce size of guest vmdk disks with VMware Fusion 4.1.3 on OS X 10.8

When running multiple VMs, and keeping backup copies of various configs, a considerable amount of disk space can be used quickly.  The following steps have been confirmed to reduce disk usage for several virtual machine guest operating systems.

  • Oracle Linux R6 U3 64-bit
  • centOS 6.3 64-bit
  • Ubuntu 12.04 LPS 64-bit
  • openSUSE 12.1 64-bit
  • Mac OS X (multiple versions)

Oracle Linux R6 U3 and CentOS 6.3:  *these steps utilize a desktop environment and VMtools.

  1. remove any unneeded apps/packages, files, etc and empty the trash.
  2. clean up the YUM package files with (terminal commands as root):
    1. yum clean packages
    2. yum clean metadata
    3. yum clean dbcache
    4. (or) yum clean all
  3. at the command line, type “vmware-toolbox” to launch the VMware Tools GUI within the guest VM.  This is equivalent to the GUI available within Windows guests.
  4. Select the drive (partition) to Shrink.  1st the utility will prepare the drive for the shrink process and then a final dialog box will be presented to begin the shrink drive operation.

Ubuntu 12.04 LPS:  same as described for centOS and Oracle Linux, except the YUM commands are replaced with:

    1. sudo apt-get autoclean
    2. (or) sudo apt-get clean
    3. (0r) sudo apt-get autoremove

*note: Ubuntu 12.04 utilizes the Ubuntu Software Center for GUI application management (and has the annoying characteristic of only working with one selection at a time); installing the “Synaptic” package manager provides a more traditional Linux package manager.

openSUSE 12.1:  same as described for centOS and Oracle Linux, except YAST handles the package and cache cleanups (instead of yum or apt-get).  Options are available within the YAST GUI.

OS X:  10.6 Snow Leopard, 10.7 Lion, and 10.8 Mountain Lion (including servers).

  1. remove any unneeded apps, files, etc and empty the trash.
  2. using Finder, navigate to the following folders and remove unneeded fonts and dictionary files for languages you’re certain you won’t need for this VM.  Sort the folder contents by size and select the largest.  You can verify font files by opening them in the “font book” app to preview.
    1. /System/Library/Fonts/
    2. /Library/Dictionaries/
    3. /Library/Fonts/
    4. note: sometimes the system will state a font is in use and need a restart before allowing all of the deleted fonts to be emptied from the trash.
  3.  use the utility Monolingualto remove unneeded Architectures, Input Types, and Languages from OS X and installed application packages.
    1. If you know you have an app which needs to be excluded, use the Monolingual “Preference” to add the app’s location to a list of excluded directories.
    2. in the main app, use the “Languages” tab to select which languages to remove (be sure to scroll the entire list and de-select any you wish to keep).  On a fresh install of OS X 10.8 Mountain Lion, selecting all but English, French, and Spanish removed about 1.6GB
    3. use the “Input Menu” tab to select what to remove.
    4. use the “Architectures” tab to select what to remove.
    5. note: Monolingual only removes the items in the visible tab; if you desire to remove items from all three tabs, you’ll need to run it three times.
  4. use the disk utility app (within the VM) to erase free space on the disk.
  5. close the VM and exit VMware Fusion
  6. use the vmware-vdiskmanager utility to shrink the VMDK.
    1. open Finder, browse to the stored VM, right click and show package contents, locate the file “your-vm-name-here.vmdk”.
    2. open Terminal and CD to “/Applications/VMware\ Fusion/Contents/Library/”
    3. type “./vmware-vdiskmanager -k “
    4. drag the VMDK file from Finder to Terminal (this will append the file path and name to the command.
    5. In terminal, enter the command to shrink the vmdk.

VPN on a stick: DoD Lightweight Portable Security

In a previous post, I mentioned the DoD’s Lightweight Portable Security bootable Linux as applicable for some situations.  The current LPS Public 1.3.5 ISOs come in two configurations, the basic and deluxe.

The deluxe version is a 401MB bootable ISO. It includes clients for Citrix, VMware View, and MS Remote Desktop.  Also includes OpenOffice and Firefox.

As a bootable ISO, it also works within a virtual machine.  This makes for a handy way to use the bootable ISO’s included clients for Telework without giving up full use of your physical computer during the remote session.

For government organizations which need additional customizations (pre-loading target URLs, additional client apps/versions, etc), customization is available at no cost to DoD organizations.  Other non-DoD Federal organizations, the customization charge is $10K with an annual $2K maintenance fee.  The Air Force organization providing this is looking into means to offer customized versions for State and Local govt organizations as well.  The public versions are free to everyone.

Additional documentation is available on their website.

For someone just beginning the process of creating a bootable LiveCD for their own organizational needs, this provides a nice clean example to start from.