Blog Posts tagged with Supporting Linux

Ask a question

KACE K1000: Can the KBOX Agent be installed on Linux & Macintosh etc

  • Summary: The K1000 Agent can be installed on Linux and Macintosh as of version 5.0
  • Symptoms: Need to know if the K1000 agent can be installed on Linux and Macintosh
  • Cause: Need to know if the K1000 agent can be installed on Lnux and Macintosh
  • Steps to resolve issue:

Linux: Supported OS Versions:

* Red Hat Enterprise Linux (RHEL) 3, 4, and 5 (x86 and x64) 

Mac OS X: Supported OS Versions:

* Mac OS X 10.4 Intel and PowerPC

* Mac OS X 10.5 Intel and PowerPC

* Mac OS X 10.6 Intel and PowerPC


* Solaris clients are not support since 4.2

Be the first to comment

KACE K1000: How to force a client check-in outside the normal run interval 

  • Summary: The K1000 Client normally checks in using the "Run Interval" schedule specified in the K1000 appliance Settings/Client Options tab on the server. For debugging and testing purposes, KACE provides ways that can be used to force a check-in outside this normal schedule.
  • Symptoms: The client isn't inventorying correctly or running a script, managed installation, patch, or replication doesn't provide the desired results
  • Cause: An issue with what's being ran and we need to identify what's the cause
  • Steps to resolve issue:

From the server you can click on the computer in the inventory list and then press the button 'Force Inventory Update'.

To force a checkin on the 5.1 Windows client, either browse using explorer to c:\program files\kace\kbox and double-click on KBScriptRunner.exe or launch the program from the command line:

C:\> C:\program files\kace\kbox\kbscriptrunner.exe
OS X: /Library/KBOXAgent/Home/bin/runallkbots
Linux: /Library/KBOXAgent/Home/bin/runallkbots
Solaris: /KACE/bin/runallkbots

Note that the KBScriptRunner.exe only forces a check-in (bypassing the “Run Interval”) but does not force an inventory if you have a non-zero Inventory Interval set on the server. There is no way to override the Inventory Interval from the client side. You may want to change the inventory interval to zero on the server while debugging/testing package deployments.

On a 5.3 client you will want to open up a command prompt and do the following:

c:> c:\program files\dell\kace\runkbot 4 0

Another way to force an inventory is to manually delete the machine record on the server between tests and then use KBScriptRunner to force a checkin. Since the machine record will be new, an inventory will happen. This approach doesn’t work if you’re manually applying labels to your machines, since you’ll lose the labels on the test machine each time you delete it. But it works nicely with filter labels which are dynamically reapplied.

View comments (2)

Identify Linux Virtual Machines with the K1000

For Windows VMs, those running VMware Tools upload that info as a part of the software inventory process, so it's straightforward to identify and report on which Windows VMs are managed in the K1000 inventory, and the unique versions of VMware Tools used for each.  But for non-Windows platforms, VMware Tools do not register in the operating system's software packages database (for example: Linux rpm or dpkg), so those operating systems don't report that software as being installed to the K1000.

So how can you identify which non-Windows VMs in your vSphere environment have VMware Tools installed?  And what versions? A Custom Inventory Rule can collect this information. VMware Tools includes the executable vmware-toolbox-cmd that can be used in the CI. The approach to this can vary based on the desired specificity:

1. Simple. Track all versions of VMware Tools on non-Windows platforms together as one software inventory item.

  • Create a new Software Inventory item with the Display Name: VMware Tools. Leave the Version field blank.
  • Specify the Supported Operating Systems (as always).
  • Add this Custom Inventory Rule: ShellCommandTextReturn(/usr/bin/vmware-toolbox-cmd -v)

Now any targeted operating system returning a value will include this new software item in its list of Installed Programs.


2. Identify Major/Minor versions only. VMware Tools with differences in build numbers cannot be distinguished.
Determine the exact VMware Tools version you want to track.

  • Create a new Software Inventory item with the Display Name: VMware Tools. Enter the major/minor version of VMware Tools. In this example, enter: 8.6.
  • Specify the Supported Operating Systems (as always).
  • Add this Custom Inventory Rule: ShellCommandTextReturn(/usr/bin/vmware-toolbox-cmd -v | grep 8.6)

Targeted operating systems returning a version beginning with 8.6 will show this software in its list of Installed Programs.

3. Specific. Track each version of VMware Tools separately.

  • Determine the exact VMware Tools version you want to track.
  • Create a new Software Inventory item with the Display Name: VMware Tools. Enter the exact version. In this example, enter:
  • Specify the Supported Operating Systems (as always).
  • Add this Custom Inventory Rule: ShellCommandTextReturn(/usr/bin/vmware-toolbox-cmd -v | grep

Only targeted operating systems returning this exact version will show this software in its list of Installed Programs.

Now you have software items that can be used like any other in Reports, Smart Labels, etc.

Be the first to comment

K2000 KBE Manipulator and Clonezilla

K2000 KBE Manipulator and Clonezilla

I am new to working with Kace environments but I am working in an organization that had established using a K2000 for their deployment of Windows and Mac systems. They recently decided to go with Ubuntu for several systems and wanted to be able to deploy using the K2000 boot environments. I found the KBE manipulator and tested but Clonezilla failed to finish booting. I am also new to Linux but muddled my way to a solution. Might be other more elegant ways but since I did not see any other ways to get it working here so I thought it was worth sharing.

As I said I am new to Linux so forgive any errors in my descriptions.   Clonezilla would begin to boot once in the Kace boot environment, but would fail in the middle looking for drivers. It took investigating how the boot process functioned before it was clear why. The boot process works in 3 steps. First is the Syslinux boot loader which loads the initrd.img that acts kind of like an intermediate filesystem. Initrd.dmg loads the initrmfs filesystem and then scripts run to find all the necessary components before it loads the final linux filesystem from a squashfs file. The problem was when it went looking for the squashfs file. Typically Clonezilla live (and Debian live) will look for available block storage devices for a /live directory (unless another path is specified in the syslinux.cfg file). It will mount the appropriate storage device and away it goes. But since it is only looking for physical storage it checks the CD drive (sr0) or the hard drive (sda) but it does not see the storage it booted from since it is not a storage device accessible once the initrd is loaded to RAM so it had no way to see the squashfs file. Typical linux pxe boot environments suggest you use a tftp server hosting the file and use the fetch command in the syslinux.cfg in order to get it and load it to RAM. This worked, but we are looking forKace to distribute this across multiple locations and it did not make sense to map a static IP for our TFTP server when we want the squashfs to load locally.

So we needed a solution for the entire filesystem to be contained on the ISO we would load into the Kace boot environment. The path I took to accomplish this was to extract the files in from the initrd.img image file and then include the filesystem and necessary changes to recognize it, without changing too much. I wanted to leave the boot processes and scripts intact so as not to affect Clonezilla from working differently as well as to do it simply without diving into changing scripts or areas of Linux with which I am not yet familiar. So I decided to create a disk image that could be mounted and act like it was a physical device that the scripts used in the initrmfs system would recognize. The steps to do this are below.   I believe further modifications of scripts and systems will allow us to run other Linux systems for other tasks as well.   

Extract files from Clonezilla ISO to a folder   We will extract files from the iso and get rid of what we don't need and customize the syslinux.cfg. I used 7-ZIP to extract.

  1. Right click iso file and click '7-zip' and then click 'Extract to "nameofisofile\"
  2. Navigate to the new folder with the name of your iso
  3. For clonezilla the boot information for the iso is the file isolinux\isolinux.bin
  4. Move the isolinux.bin to the syslinux directory
  5. delete the isolinux directory since we won't need it for our config.
  6. move the live\initrd and the live\filesystem.squashfs out to the desktop so we can use them in the next process on a linux computer.
  7. delete all files from the syslinux folder except leave the vmlinuz only
  8. customize the syslinux.cfg to include the parameters bootfrom=/dev/loop0 toram=filesystem.squashfs
  9. Customize any other syslinux options to boot and automate clonezilla

Extract and prepare initrd.img

You will need a linux computer to do the following commands. You may also need some utilities used to compress and extract. I used a Ubuntu 11.10 system and the command line utilities I used were included. We are also assuming you have the initrd.img file and the filesystem.squashfs files extracted from the iso and copied to the /temp directory for the commands.   Now we will extract the initrd.img file. It is compressed and a CPIO archive so I had to do two differenct commands.  

xzcat initrd.img > initrd
mkdir content
cd content
cpio -id < ../initrd

  Now you can add or change any files needed. I am adding an ISO that contains the filesystem.squashfs and some changes to the scripts to add the setup and association of the loop0 device.  

sudo nano /tmp/content/scripts/live-premount/ORDER

  This file tells what scripts to run. We will write a simple script and this will point at ours first. We will add the top two lines and this is what it will look like below.  

[ -e /conf/param.conf ] && . /conf/param.conf
[ -e /conf/param.conf ] && . /conf/param.conf
[ -e /conf/param.conf ] && . /conf/param.conf
[ -e /conf/param.conf ] && . /conf/param.conf

  Now we will exit out (ctrl x and then y and enter to save) and create our script  

sudo nano /tmp/content/scripts/live-premount/create-loop0

  Below is the script content

#script to mount a loop device in place of the physical devices when looking
#for the filesystem
mknod /dev/loop0 b 7 0
losetup /dev/loop0 /fs.iso

  Now we will exit out (ctrl x and then y and enter to save) and make the script executable.  

sudo chmod +x /tmp/content/scripts/live-premount/create-loop0

Unsquashing and squashing

Any changes needed to the final boot environment in clonezilla (imaging, postimaging scripts), must be done to the filesystem.squashfs file. There is a process to "unsquash" make all necessary changes and then "makesquash".  This makes any quick changes to the script a bit tedious but we could script this creation process as well if we are making changes often.

  1. Sudo unsquashfs filesystem.squashfs
  2. make changes to /tmp/squashfs-root/
  3. sudo mksquashfs squashfs-root filesystem.squashfs.new

Now we will create the directories and the ISO to include the filesystem.squashfs  

cd /tmp
mkdir fs
mkdir fs/live
mv /tmp/filesystem.squashfs /tmp/fs/live/filesystem.squashfs
mkisofs -J -r -o fs.iso fs
cp /tmp/fs.iso /tmp/content/fs.iso

  Recreate initrd.img   Now it is time to recreate our CPIO archive and recompress. Make sure you are still in the /tmp/content directory as the paths in the commands are relative.  

find ./ | cpio -H newc -o > /tmp/new-initrd.cpio
cd ..
xz -c --check=crc32 new-initrd.cpio > new-initrd.img

  Add initrd.img file and create new bootable ISO file     Back on the windows 7 computer I used imgburn to complete our iso creation process.

  1. Copy your new-initrd.img file into the folder you have been customizing for your new ISO in the \live directory and rename it initrd.img
  2. Finish any other customizations within the folder and the syslinux.cfg
  3. Open ImgBurn and on the main menu pick 'create image file from files/folders'
  4. Use the folder with the magnifying glass icon to browse and pick your source folder. This is the folder we have been customizing.
  5. Click the 'Advanced' tab and choose 'Bootable Disc'
  6. Check the box for 'Make Image Bootable'
  7. Next to 'Boot Image:' Click the folder with the magnifying glass icon to browse to your boot image file. (This should be isolinux.bin that we moved to the syslinux folder.) and check the box 'Patch Boot Information Table'
  8. Under Destination click the folder icon and pick a destination folder and name
  9. now click the picture that shows folder > disk image and click yes when asking if it is your root folder and yes to accept the default iso labels. Then Click OK and you should get an 'Operation Successfully Completed' message.
  10. Now test your ISO image. And use KBE Manipulator to use this iso to create the custom boot environment.


To make changes to your new initrd.img and filesystem.squashfs

Commands would be like so. (assumes initrd.img is in the /tmp folder)

Commands to uncompress squash and initrd

xzcat /tmp/initrd.img > /tmp/initrd
mkdir /tmp/content
cd /tmp/content
cpio -id < ../initrd
sudo mount /tmp/content/fs.iso /mnt
cp /mnt/live/filesystem.squashfs /tmp/filesystem.squashfs
sudo umount /mnt
cd /tmp
sudo unsquashfs /tmp/filesystem.squashfs

  Make Changes to any scripts or files in /tmp/squashfs-root/   Commands to re compress squash and initrd

cd /tmp
sudo mksquashfs /tmp/squashfs-root /tmp/filesystem.squashfs.new
sudo rm -rf /tmp/squashfs-root
sudo rm -rf /tmp/filesystem.squashfs
sudo mv /tmp/filesystem.squashfs.new /tmp/filesystem.squashfs
mkdir /tmp/fs
mkdir /tmp/fs/live
sudo mv /tmp/filesystem.squashfs /tmp/fs/live/filesystem.squashfs
mkisofs -J -r -o /tmp/fs.iso /tmp/fs
sudo rm -rf /tmp/content/fs.iso
cp /tmp/fs.iso /tmp/content/fs.iso
cd /tmp/content
find ./ | cpio -H newc -o > /tmp/new-initrd.cpio
cd ..
xz -c --check=crc32 /tmp/new-initrd.cpio > /tmp/new-initrd.img
sudo rm -rf /tmp/content /tmp/fs.iso /tmp/filesystem.squashfs /tmp/initrd /tmp/new-initrd.cpio /tmp/fs /tmp/initrd.img
sudo mv /tmp/new-initrd.img /tmp/initrd.img

  Copy initrd.img and replace in the live folder use imgburn to create iso Create your KBE again with KBE Manipulator  

View comments (8)

OS Agnostic Systems Management: Clarity, Compliance and Security for Windows 7& 8, Linux, Macs and More

New devices and OS releases seem to hit the market daily, and IT organizations are charged with incorporating their needed functionality while still ensuring that these endpoints remain identified, secured and well-managed.

Get a grip on your heterogeneous IT environment with a central point of control.

Join the live event to learn how to:

• Manage upcoming Windows 8 (x86), Mac OSX Mountain Lion, Red Hat 6, Ubuntu and SuSE Linux systems, in addition to existing Windows, Mac OSX and Red Hat systems

• Improve visibility of all desktops, laptops and servers on the network

• Utilize a new inventory API to track even non-supported systems

• Lay the foundation for a robust regulatory compliance implementation

• Increase support for the growing BYOD phenomenon

• Improve service desk ticket management and reporting

Register for a live event on Thursday, September 27 at 10 a.m. PT, 12 p.m. CT, to learn more.


Be the first to comment
Showing 1 - 5 of 30 results

Top Contributors

Talk About Windows Installer (MSI)