LANDesk Management Suite 8.8 SP3 Best Known Method for Managing Linux Agents
Contents Introduction... 4 Scope... 4 Assumptions... 4 Supported Linux Platforms... 4 Prerequisite Software... 4 The Linux Agent vs. the Linux Server Agent...5 Manually Installing the Linux Agent...5 Deploying the Linux Agent Using LANDesk Management Suite... 6 Configuring the LANDesk Scheduler Server Credentials... 6 Creating the Linux Agent Configuration...7 Linux Agent...7 Linux Server Agent...7 Adding an Unmanaged Linux Server or Workstation to the Console.. 8 Manually Adding a Linux Server or Workstation to All Devices. 8 Discovering Unmanaged Linux Servers and Workstations... 8 Scheduling a Task to Deploy the Linux Agent... 9 Linux Agent Post-installation Configuration... 9 Configuring the Linux Firewall... 9 Configuring SELinux to Allow RPM Distributions... 11 Scheduled Agent-Side Tasks with cron... 12 Scheduling Inventory and/or Vulnerability Scans with cron... 12 Deploying a cron Configuration as a Scheduled Task... 14 Configuring the LANDesk Inventory Scanner for Linux... 16 Enabling Inventory Scanning of BIOS Information for Linux Workstations... 19 Using Patch Manager with Linux Agents... 19 Downloading Linux Patch Vulnerability Content... 20 Downloading the Linux Patch Software... 20 Scheduling Daily Vulnerability Downloads... 21 Filtering Patch Content... 21 Creating a Custom Vulnerability... 23 Uninstalling the Linux Agent...27
Software Distribution... 28 Deploying RPMs... 28 Step 1 Place the RPM on a Web Share... 28 Step 2 Create a Distribution Package... 28 Step 3 Create a Scheduled Task... 29 Running Custom Scripts... 29 Deploying a Shell Script as a Custom Script... 30 Imaging Linux Agents... 30 Windows PE or Linux PE?... 31 Preparing a Base Image... 31 Software on the Base Image... 31 IP Address Configuration... 31 Host Name... 32 Patching... 32 Capturing the Base Image... 32 Deployment... 32 Appendix A - Troubleshooting the Linux Agent Install... 33 The Core Server Never Connects to the Linux Device... 33 Missing Dependencies... 34 Unsupported Platforms... 35 Appendix B Sample Custom Definition... 35 Appendix C OS Deployment Script Examples...37 Windows PE Capture Script... 37 Linux PE Capture Script... 38 Windows PE Deploy Script... 39 Linux PE Deploy Script... 40 About LANDesk Software... 42
Introduction The LANDesk Management Suite workstation management has extended into management of Linux* workstation and servers for some time. The Linux Agent can run on almost any Linux platform. LANDesk Software has chosen to officially support only a few of these, such as Red Hat 3, 4, and 5, SUSE 10, and Ubuntu 6 and 7. The Linux Agent provides the ability to do the following: Send inventory scans to the Core Server Remotely install RPMs with a scheduled task from the Core Server. Check for vulnerabilities (supported Linux version only). Run remote execute commands in Custom Scripts. The Linux Agent can be pushed from the Core Server to Red Hat 3, 4, 5 and SUSE 10. Ubuntu currently requires a manual installation. Scope This document will be a comprehensive discussion about Linux desktop management. Assumptions This white paper assumes that the reader is a LANDesk administrator and familiar with Desktop Management principles as well as a Linux administrator and familiar with the Linux operating system. Supported Linux Platforms The following Linux platforms are officially supported: Red Hat 3, 4, 5 (32 bit and 64 bit) Both desktop and server platforms are supported. SUSE 10 (32 bit and 64 bit) Both desktop and server platforms are supported. SUSE has released version 11 for which we intend to add support, though we have not done so as of yet. Ubuntu 6.x, 7.x (32 bit) Ubuntu is a Debian based Linux distribution that is now has a version 8 and 9 which we are working to support officially. Unofficially the agent can install on those versions and send in scans as of 8.8 SP3. Note: The Linux agent can run on other platforms, however, LANDesk Software only guarantees the above platforms and only allows for support on the above platforms. Any assistance, support, or functionality desired for additional platforms is not covered through a support contract but should be purchased from LANDesk Professional Services or a valued LANDesk Partner. Prerequisite Software
The Linux agent installation indicates when software that is required and is not installed. Software is required to run the agent, and the following list is the software that must be installed. xinetd compat-libstdc++ (Red Hat 3, 4) sysstat (Linux Server agent only) For more information on other requirements, such as what is required to push a LANDesk agent, refer to the following section of the LANDesk help file: LANDesk Management Suite Configuring device agents Configuring Linux and UNIX device agents The Linux Agent vs. the Linux Server Agent The Linux Agent and the Linux Server Agent are similar. The difference is everything the Linux Agent installs, the Server Agent also installs; however, the Linux Server Agent installs much more than the Linux Agent installs. Particularly the functionality around Monitoring is not installed by the Linux Agent and is installed with the Server Manager agent. Monitoring allows for the ability to scan the BIOS, work with some IPMI settings, etc. The Linux Agent (at least as of 8.8 SP2A) by default cannot scan important BIOS information that is usually desired, such as Serial Number and Asset Tag. These two pieces of data are highly desired, which makes it appear that the Linux Server Agent should always be used, even for Linux workstations. However, installing the Linux Server Agent is not recommended on Linux workstations. There is a simple workaround to get BIOS scans to occur on the Linux Agent, and deploying the Linux Agent to Linux workstations is still best. The workaround is to extract and deploy two RPMs to the Linux Agents. This is discussed later in the How to Scan the BIOS Information section. Manually Installing the Linux Agent 1. Open a shell on the Linux Server or Workstation. This can be done either directly on the Linux Server or Workstation or by connecting via SSH. 2. As root, or using sudo, run the following commands from the shell: a. Mount a drive to the ldlogon share on the Core Server. # mkdir /mnt/ldlogon # mount t cifs o username=user,workgroup=domain \ //Core/ldlogon /mnt/ldogon Note: On older Linux platforms cifs may need to be replaced with smbfs. b. Change to the mounted drive and run the installer. # cd /mnt/ldlogon #./linuxpull.sh "Default Linux Configuration.ini"
The Linux agent will install. c. Run an inventory scan. The installer does not run an inventory scan by default. # /usr/landesk/common/ldiscan.sh Alternatively, a shell script is included in the /usr/landesk/common that can be called that automatically uses the Core Server name from the /etc/ldiscnux.conf file. A copy of this shell script is placed in /etc/cron.daily that runs the inventory scan every day. Deploying the Linux Agent Using LANDesk Management Suite The Linux agent install must be done using the following process: 1. Configure the LANDesk Scheduler Server Addition. 2. Create a Linux Agent. 3. Add the Linux device to the Console. a. Add an Unmanaged Linux Server or Workstation to the Console. b. Discover Unmanaged Linux Servers and Workstations with Unmanaged Device Discovery. 4. Schedule the Linux Agent Deployment. Configuring the LANDesk Scheduler Server Credentials Use the Configure Services Scheduler Change login window to enter the SSH credentials you want the scheduler service to use as alternate credentials. The scheduler service uses these credentials to install the agents on your servers. You should be prompted to restart the scheduler service. If you aren't, click Stop and then Start on the Scheduler tab to restart the service. This activates your changes. Do the following from the Core Server (it cannot be done on an additional Remote Console): 1. On the Core Server, in the Management Suite Console, go to Configure Services Scheduler Change login. 2. Change the Scheduler Service to use an account other than Local System. This cannot be the root account used for Linux servers or workstations. The scheduler Service itself should be running as an Active Directory service account that you would have to create in Active Directory for LANDesk use. If Active Directory is not in use, another domain or local account will suffice.
3. Under Alternate Credentials, click Add. a. For the User name, type in root. b. Leave the Domain field blank. c. For the Password type in the password. d. Retype the password for Confirm Password. e. Click Ok to add the alternate credentials. 4. Click Ok again to exit the Change Login screen. 5. When prompted, choose to restart the Scheduler Service. Creating the Linux Agent Configuration After you've configured your Linux servers and added Linux credentials to the core server, you must create a Linux agent configuration. Linux Agent To create a Linux Agent configuration: 1. In Tools Configuration Agent configuration, click the New Linux button. 2. Enter a Configuration name. 3. On the Start page, the Standard LANDesk agent and software distribution agents are required and the LANDesk Vulnerability Scanner is optional but installed by default. 4. Check other screens and read the help documentation where needed to see if you need to change any other option. Otherwise keep all other default options. 5. Click Save. Linux Server Agent To create a Linux Server Agent configuration: 1. In Tools Configuration Agent configuration, click the New Server Configuration button. 2. Enter a Configuration name. 3. Select Linux Server Edition from the Configuration Type. 4. On the Start page, the Default LANDesk agent is required and the other features are optional but installed by default. 5. Check other screens and read the help documentation where needed to see if you need to change any other option. Otherwise keep all other default options.
Note: LANDesk Software tries to gray out any options not specific to the Linux Server Agent, but unfortunately many options are not grayed out that do not work with the Linux Server Agent. 6. Click Save. Adding an Unmanaged Linux Server or Workstation to the Console Management Suite can only push a Device in All Devices or in Unmanaged Devices. To push the Linux Agent to a Linux Server or Workstation, the device must either be added to the All Devices manually or discovered using Unmanaged Device Discovery. If you are only testing with a single Linux device, manually add the device to All Devices. If you are working with many Linux devices, Unmanaged Device Discovery is a more efficient solution. Manually Adding a Linux Server or Workstation to All Devices To add a device to All devices in the console: 1. In the Management Suite Console, in the Network View, right-click All devices and click Insert New Computer. 2. Enter the Name, IP Name (FQDN), and IP Address. 3. Click OK. The device is now added to All devices. Note: Adding a device to All devices does not install the agent or make the device managed. The agent must still be deployed to this device. Discovering Unmanaged Linux Servers and Workstations To discover your Linux servers and deploy a configuration to them: 1. From the Management Suite Console, click Tools Configuration Unmanaged Device discovery. 2. Click the Scan Network icon. 3. In the Scanner Configuration window, click New. 4. Type a name for the new configuration.
Note: By default only a standard network scan is done. If more scan options are desired, click the More >> button. Read the help file to understand the options. 5. Enter an IP range. If you have many Linux servers, enter a subnet or list of subnets. If you are only working with one machine, enter the Linux server's IP address for the starting and ending IP ranges. 6. Click Scan now once you've added your discovery IP ranges. Scheduling a Task to Deploy the Linux Agent To create a scheduled task to deploy the Linux Agent: 1. In the Management Suite Console, click Tools Configuration Agent configuration. 2. Right-click the agent configuration and click Schedule agent deployment. The agent is scheduled and the scheduled tasks pane is automatically opened. 3. Either from the All devices in the Network View or from Unmanaged Device Discovery, drag the Linux device(s) and drop them over the scheduled task. 4. Right-click the task and choose Start now. Linux Agent Post-installation Configuration That LANDesk agent does not configure the Linux firewall. It does add a shell script to cron.daily so an inventory scan is run daily, but no vulnerability scan is configured. The cron.daily may not suit your needs and a more complex cron job may be desired. Configuring the Linux Firewall The following ports must be enabled for the Core Server to remotely manage the Linux device: Agent Function TCP UDP Agent Deployment 22 (SSH) n/a Management Agent (cba8) 9595 (Ping Discovery Service) 9595 (Ping Discovery Service) Messaging System (msgsys) 9594 (Messaging System) n/a LANDesk Management Agent LANDesk Gateway 9593 (cba8) n/a 9592 (LDGateway - Exists but is not currently in use) n/a
The following is a screen shot of a working Red Hat 5 firewall configuration. SUSE and Ubuntu have difference interfaces to the firewall but have some similarities. You can find more information on their Web sites.
Configuring SELinux to Allow RPM Distributions If SELinux is enabled, and it is enabled if you select the defaults during an installation of Red Hat, then when the Core Server attempts to deploy an RPM as a distribution package, SELinux will block this action. SUSE and Ubuntu do not come with SELinux by default. SUSE comes with AppArmor instead of SELinux and while AppArmor could prevent agent functionality, it does not appear to do so by default. To configure SELinux to allow RPM distributions, perform the following: 1. Create the following file on a Linux device using a Linux editor. LANDesk.te module LANDesk 8.80.2.1; require { type inetd_t; type rpm_script_t; class process transition; } #============= inetd_t ============== allow inetd_t rpm_script_t:process transition; 2. Copy the file to a web share. 3. Create a shell script using a Linux editor that will compile and install this SELinux configuration. ConfigureSELinuxForLANDesk.sh #!/bin/sh cd /tmp /usr/bin/checkmodule -M -m -o LANDesk.mod LANDesk.te /usr/bin/semodule_package -o LANDesk.pp -m LANDesk.mod /usr/sbin/semodule -i LANDesk.pp #cleanup rm f /tmp/landesk.te /tmp/landesk.mod /tmp/landesk.pp exit 0 4. In the Management Suite Console, click Tools Distribution Manage Scripts. 5. Create a New Custom Script.
This opens a LANDesk Custom Script in the default editor for.ini files. Write a new custom script that (1) transfers both the ConfigureSELinuxForLANDesk.sh and the LANDesk.te files to the Linux agent s /tmp directory, and (2) runs the shell script to compile and install the SELinux configuration for LANDesk, and (3) cleans up after itself. The following is an example of such a Custom Script. Your web paths will be different. [MACHINES_LINUX] ; Download the files REMEXEC0=/usr/bin/wget http://172.16.27.9/software/shell/configselinuxforlandesk.sh -O /tmp/configselinuxforlandesk.sh, STATUS SYNC REMEXEC1=/usr/bin/wget http://172.16.27.9/software/shell/landesk.te -O /tmp/landesk.te, STATUS SYNC ; Make the shell script executable REMEXEC2=/bin/chmod +x /tmp/configselinuxforlandesk.sh, STATUS SYNC ; Execute the shell script REMEXEC3=/tmp/ConfigSELinuxForLANDesk.sh, STATUS SYNC ; Clean up after ourselves by deleting the shell script REMEXEC4=rm -f /tmp/configselinuxforlandesk.sh, STATUS SYNC 6. Save the file with an appropriate name and make sure the extension is.ini. 7. Verify that it does not save with the.txt extension. The script now appears in the Manage Scripts window. 8. Right-click the new Managed Script and click Schedule. 9. Drag the Linux devices and schedule the task. 10. Right-click the task and click Start now. Once successful this task should build and install a configuration module to all RPMs to be deployed by the Core Server. Scheduled Agent-Side Tasks with cron By default Management Suite adds a shell script to /etc/cron.daily, which runs the inventory scanner shell script daily. You can customize this script if desired. A manual page or man page exists for cron and crontab. These man pages can usually be found by running the following commands on a Linux device from a shell: $ man cron $ man crontab
$ man 5 crontab These man pages can also be found online. Scheduling Inventory and/or Vulnerability Scans with cron For inventory scans, by default a Windows agent is configured to send a small hardware scan immediately after booting up. The Windows agent will also perform an inventory scan that includes a software scan daily. However, windows devices support delta scans (delta scans are scans where only the changes are sent to the Core Server), while Linux devices currently do not perform a delta scan and always send full scans. So if the default cron.daily task does not work in your environment, the following is an example design that may better suit your needs. For vulnerability scans, by default a Windows agent is configured to perform a vulnerability scan each day. While one could argue whether or not Linux Operating Systems and their installed software have more or less vulnerabilities vs. windows, the important factor here is that when you are vulnerable you get patched no matter what the Operating System is. Different corporations have chosen to scan at different intervals, every four hours, daily, every three days, once a week. Look at your environment and determine the best interval for your Linux workstations and Core Servers. There will probably be different settings for both. If using the default of placing a shell script to run an inventory scan in cron.daily does not meet your needs, and/or you are certain that you need to schedule a vulnerability scan, the following is an example of three alternate cron jobs: Send a hardware scan on boot Linux Workstations usually use DHCP over static IP addressing. The workstations may not get the same IP address every time. So to manage Linux Workstations, a scan containing their new IP address immediately should be sent after boot up. Otherwise, inventory will have the old IP address and connection attempts may fail. For Linux Servers, or any device with Static IP addressing, this cron job is unnecessary. Send a full scan every two days - Because the scanner does not do delta scans, you should do a full scan every other day instead of daily. For Linux Servers, a scan once a week may be enough. Run a vulnerability scan Mon Wed Fri Vulnerability scans only need to happen when you are vulnerable. If you have a good baseline image scanning from the Core Server only when new vulnerabilities are downloaded could be fine. However, some devices may be off when such a scan is pushed. So every other week day, a vulnerability scan could run. For Linux Servers, you may want to change this to once a week.
The following is a procedure to configure the above settings: Note: For large numbers of nodes, you would want to stagger you clients so they don t all send inventory scans to the Core Server at the exact same time. 1. From the Linux shell, as root or using sudo, run the following command: # crontab e Note: By default this opens the vi editor. The vi editor can seem complex at first and you may need to do a web search to find information on using it. A reference sheet for vi can be found by doing a web search for vi cheat sheet. Such a reference sheet can be found here: http://www.viemu.com/vi-vim-cheat-sheet.gif 2. Add the following lines to the crontab file: #Min Hour DayOfMon Month DayOfWeek Command 30 11 * * */2 /usr/landesk/common/ldiscan.sh 30 16 * * 1,3,5 /usr/landesk/ldms/vulscan @reboot /usr/landesk/ldms/ldiscan ntt f- For Linux Servers, you may choose to use different settings that run these tasks less often: #Min Hour DayOfMon Month DayOfWeek Command 30 23 * * 0 /usr/landesk/common/ldiscan.sh 30 1 * * 1 /usr/landesk/ldms/vulscan 3. Close and save the file. To close, press ESC. Then hold down Shift and press :. Now type wq! and hit enter. This command sequence should close the file. Deploying a cron Configuration as a Scheduled Task Deploying a cron configuration involves the following processes: Creating the crontab file on a Linux device Placing the crontab file on a web share Create a Custom Script to do the following o Transferring the crontab file to the Linux agents o Installing the crontab file
The following example demonstrates this: 11. On a Linux device, create a crontab file by opening vi or another editor and writing the file. For this example the file will be assumed to have the following name: LANDeskCrontab Note: It is best to write the file using an editor on a Linux platform instead of a windows editor because the new line characters are different on Linux than on Windows and this could potentially cause problems. 1. Copy the LANDeskCrontab file to a web share. 2. In the Management Suite Console, click Tools Distribution Manage Scripts. 3. Create a New Custom Script. This opens a LANDesk Custom Script in notepad. 4. Delete all the default lines and add the following lines: [MACHINES_LINUX] ; Download the crontab file REMEXEC0=/usr/bin/wget http://d88/software/linux/landeskcrontab -O /tmp/landeskcrontab, STATUS SYNC ; Install the crontab file REMEXEC1=/usr/bin/crontab /tmp/landeskcrontab, STATUS SYNC ; Clean up by deleting the crontab file REMEXEC2=rm -f /tmp/landeskcrontab, STATUS SYNC 4. Save the file with an appropriate name such as Install Linux Workstation crontab and make sure the extension is.ini. Make sure it does not save with the.txt extension. If it does, remove the.txt extension. The script now appears in the Manage Scripts window. 12. Right-click on the new Managed Script and choose Schedule. 13. Drag the Linux devices and schedule the task. 14. Right-click on the task and choose start now. The crontab should now be installed.
Configuring the LANDesk Inventory Scanner for Linux Inventory scans use a configuration file. On Linux, this file is stored at: /etc/ldadppl.conf The following is an example of this default file without the comments, to show how it has not been configured. It is completely up to the LANDesk administrator to deploy a separate ldappl.conf if desired. Currently the default ldappl.conf cannot be changed. You must change it after the agent is installed. [LANDesk Inventory] Version=2.0 Revision=8.10a Duplicate=ON Mode=Listed [Applications] [Excluded Applications] [Ignore] [Excluded Ignore] It is up to you to determine what you want to scan and what you don t want to scan on your Linux Agents. No assumptions whatsoever are made by default. This following is a copy of the default file with the comments. As it standard with Linux configuration files, the comments are included so that the configuration file is self documenting: [LANDesk Inventory] ; Revision is the revision number of the ldappl file. Version=2.0 Revision=8.10a ; Duplicate can be ON or OFF. If ON any applications that are found more ; than once by the scanners will be entered into the database. If set to ; OFF, the scanners will only find the application once. Duplicate=ON ; Here indicate the configuration text files to scan for. Start with ; ConfFile1 and increment by one for each conf file. Don't skip any ; numbers. Note that full file paths need to be specified. ;ConfFile1=/etc/smb.conf ;ConfFile2=/etc/foo.conf ;ConfFile3=/etc/bar.conf ; Directory exclusion directives. There can be only 1 item per line. ; Enumeration of "ExcludeDir" must start at 1 and be continuous. ; Don't skip any numbers. Ending "/" is required. ;ExcludeDir1=/var/ ;ExcludeDir2=/net/ ; Directory inclusion directives. There can be only 1 item per line. ; Enumeration of "IncludeDir" must start at 1 and be continuous. ; Don't skip any numbers. Ending /" is required. ;IncludeDir1=/opt/
;IncludeDir2=/tmp/ ; Special directive to support binary lookups on files only. ; Normally, the scanner will only check to see if the ; executable flag is set for the file. The FileMode flag ; changes this behavior. With the FileMode flag set to ; Binary, the scanner will run the file command on each ; file it encounters to determine if the file is binary. ; This WILL slow down the software scan. If the FileMode ; is not set, or does not exist, the scanner will operate ; normally and just check for the executable bit. ;FileMode=binary ; There are three modes supported. Listed, Unlisted, and All. A brief ; description of each mode: : ; Listed - In this mode, only executable files that are listed in the ; ldappl.conf file will be collected. This means that if there is an executable ; that is not listed in this file, the inventory will not have any data ; pertaining to that executable. ; ; Unlisted - In this mode, only executables with an unknown file name will be ; collected. This mode can be used to send all unknown executable names to a ; text file (using the -o command line option) that can then be used to add ; entries to the ldappl.conf file. If the data is sent to the inventory server, ; the application name will be the file name. The version number will be the ; file size. ; ; All - This mode is a combination of Listed and Unlisted as detailed above. ; ;Mode=Unlisted ;Mode=All Mode=Listed ;Format for describing software is: ;<I>,BinaryName,FileSize,English Name,Version ;Currently <I> is the only option supported with Linux and Unix scanners. The ;<p> and <f> options are reserved for the Win32 scanner. [Applications] ;USERADD above, BASE below ;Here are some examples. The size must be at least three digits long. For example, ;a 10 byte file would be entered as: ;<I>,foo,010,foo application,version 123 ;<I>,arch,2864,arch application,redhat 5.2 ;<I>,ash,62660,ash application,redhat 5.2 ;<I>,ash.static,153752,ash.static application,redhat 5.2 ;<I>,userd,35603,Intel Remote Control Agent for Linux (libc5),6.3 ;<I>,userd,39553,Intel Remote Control Agent for Linux (libc6),6.3 ;<I>,ldiscnlx,70897,Intel Inventory Scanner for Linux (libc5),6.3 ;<I>,ldiscnlx,71239,Intel Inventory Scanner for Linux (libc5),6.3 ;<I>,ldiscnux,136108,Intel Inventory Scanner for Linux,6.6 [Excluded Applications] ;Use this section to temporarily move a file out of the Applications section
;USERADD above, BASE below [Ignore] ;USERADD above, BASE below ;Following is a example of how to exclude a file ;<I>,vi [Excluded Ignore] ;Use this section to temporarily move a file out of the Ignore section ;USERADD above, BASE below The following is an example of a customized ldappl.conf file: [LANDesk Inventory] Version=2.1 Revision=8.80.2.1 Duplicate=ON ConfFile1=/etc/resolv.conf ConfFile2=/etc/cdrecord.conf ConfFile3=/etc/dhclient-eth0.conf ConfFile4=/etc/dhcp6c.conf ConfFile5=/etc/grub.conf ConfFile6=/etc/host.conf ConfFile7=/etc/nsswitch.conf ConfFile8=/etc/ntp.conf ConfFile9=/etc/resolv.conf ConfFile10=/etc/sysctl.conf ConfFile11=/etc/syslog.conf ConfFile12=/etc/xinetd.conf ConfFile13=/etc/yum.conf ConfFile14=/etc/X11/xorg.conf ConfFile15=/etc/cups/cupsd.conf ConfFile16=/etc/cups/printers.conf ConfFile17=/etc/samba/smb.conf ConfFile18=/etc/wpa_supplicant/wpa_supplicant.conf ConfFile19=/etc/httpd/conf/httpd.conf ExcludeDir1=/var/db ExcludeDir2=/var/log ExcludeDir3=/tmp/ ExcludeDir4=/root/ Mode=Listed [Applications] [Excluded Applications] [Ignore] [Excluded Ignore]
Enabling Inventory Scanning of BIOS Information for Linux Workstations By default the Linux Agent for workstations does not include the files necessary to scan the BIOS. However, the Linux Server Agent does include those files, so the following steps are not necessary on Linux Servers. It is better to not install the Linux Server Agent to workstations. Instead, it is better to install the Linux Agent and add the needed software for BIOS scanning post installation. Two additional RPMs are needed to scan BIOS information. They are: ldsmbios smbase These two RPMs can be extracted from the monitoring.tar.gz file and deployed as an RPM distribution package. These steps are described below: 1. Browse to \\CoreServer\ldlogon\unix\linux. 2. Using a zip utility, extract the monitoring.tar.gz file. Note: Some zip utilities can unzip and extract the tar file in one step, but some utilities will require two steps where you have to first unzip the file and then you have to extract the tar file. Once extracted, both the ldsmbios and the smbase RPMs should be visible. 3. Copy these RPMs to a Web share. 4. From the Management Suite Console, click Tools Distribution Distribution Packages. 5. Right-click Public packages and click New Linux Package (it must be a public package). 6. Type a name and a description for the package. 7. For the primary file, enter the Web share path to the smbase RPM. 8. Save the Distribution Package. 9. Repeat the steps to create an RPM distribution package for ldsmbios, however, before saving it, also configure the ldsmbios package to have a dependency of the smbase package. 10. Deploy the ldsmbios RPM distribution package (which will install both RPMs since smbase was configured as a dependency). 11. Run an Inventory scan. BIOS information is now obtained by the Inventory scan. Using Patch Manager with Linux Agents Patch Manager can be used with both Linux workstations and Linux servers. There are two parts to a patch and each part is downloaded separately and differently. The two parts are:
The vulnerability content This is the information needed to detect if a machine is vulnerable, such as the detection rules. The software patch This is the actual software installer (usually and RPM for Linux) that repairs the vulnerability found by a detection rule. Downloading vulnerability content does not necessarily download the software patch. These are two different downloads and are both handled differently. Sometimes the ability to repair a detection rule is included in the detection rule. For example, if a detection rule can be repaired with a shell script and no binary files need to be replaced, then the shell script is usually included as part of the detection rule and no software patch is needed. Downloading Linux Patch Vulnerability Content To download Security and Patch information for Linux, perform the following: 1. In the Management Suite Console, click Tools Security Security and Patch Manager. 2. Click the Download updates icon (first icon) in the Security and Patch Manager tool bar to bring up the Download updates window. 3. Under the Updates tab, under Definition types, check the boxes for each Red Hat and SUSE definition type options. 4. Uncheck all other Definition type options. 5. Under the Languages field, check the appropriate languages. 6. Click the appropriate server from the Select update source site drop-down menu. 7. Leave the other settings as defaults. 8. Click the Update Now button. The vulnerability content will now be downloaded. Downloading the Linux Patch Software If you go back to the Download updates window, and look at the Download patches option, you will see that by default it is checked and the download option for detected definitions only is the default option selected. This will download any patch as long as the patch is autodownloadable. The problem with Linux patches is that most are NOT autodownloadable. Because of the Red Hat and SUSE license agreements, and the fact that a login is required to download their patches, the Linux patch software is not auto-downloadable. For Linux patches, you must manually download the patches and place them in your Patch Location. For example, for Red Hat, you would have to have a service contract and a user name and password to log into http://rhn.redhat.com. Alternately if you have a repository, you can copy these patches from a local repository. Note: In the future LANDesk Software intends on integrating with the Linux operating system s default software update technology such as YUM for Red Hat.
Scheduling Daily Vulnerability Downloads You may want to check for new vulnerability content daily without having to manually perform the task. You can schedule the Download updates process. To schedule the Download updates process, follow the steps in the Download Linux Patch Vulnerability Content procedure and click Schedule Update in step 8. A window appears showing you the options you have chosen and allows you to give the task a descriptive name. Provide a very descriptive name and click OK. Note: It is a good idea to screen shot this window. Once the task is created, there is currently no way to see what settings the task was originally configured with. A Scheduled task Properties window opens with two different pages in a tree view. The Overview Page and the Scheduled task page. The Overview page allows you to choose the owner of the task and whether to show the task in common tasks. The Schedule task page allows you to schedule when this task will run. It is common to configure this task to Start later, sometime between 10:00 pm and 5:00 am and repeat every day. Filtering Patch Content Often Windows, Macintosh, and Linux devices are all being managed by the same Core Server. If looking at Patch content, and patches for all these device types are showing, it can be difficult to sort through and find the Linux patches. LANDesk Software has provided the filter feature to allow you to configure a filter to only show the patches for a specific platform at a time. When in the Console and looking at the Security and Patch Manager pane, there is a filter dropdown menu on the right of the menu bar. To configure a filter, perform the following: 1. In the Management Suite Console, click Tools Security Security and Patch Manager. 2. Click Manage Filters from the Filter drop-down menu ( right of the Security and Patch Manager pane s menu bar). 3. On the Manage Filters, click New to open the Filter Properties window. 4. Type a name. For this example, Red Hat 5 will be used. 5. Check the Filter operating systems checkbox.
6. Check the checkboxes only for the regular non-64 bit Red Hat 5 platforms. There are only two items as shown below: 7. Click OK to save and close the Filter Properties window. 8. On the Manage Filters windows, verify that the new Red Hat 5 filter is highlighted. 9. Click Use Filter to close and use the newly created filter. The patches are now filters to only show Red Hat 5 patches. 10. Repeat the above steps to make any filters for your company. Creating a Custom Vulnerability You may want to create your own custom vulnerability and have Management Suite see who is vulnerable and allow you to run a shell script to fix it.
Note: This feature is available by default in any versions starting with 8.8 SP3 and 9.0. If on 8.8 SP2 or SP2a, apply this patch: PAT-1654888.2 - Provide the ability to run shell scripts in place of VBScripts when using Linux Platforms. Earlier versions do not have this feature. This patch will be included in any future versions, such as 8.8 and 9.0. To demonstrate this feature, imagine you have an update you need to make to your hosts file and you want to create a custom vulnerability that will look for a line in the hosts file and if it is not there, add it. Follow thi procedure to make this happen: 1. On a Linux computer write and test a shell script that returns an exit code of 0 if the hosts file has the new line, and an exit code of 1 if the hosts file does not have the new line. The following is an example script: DetectHostsEntry.sh #!/bin/sh if cat /etc/hosts grep 10.1.1.1 /etc/hosts grep MyServer then # Device is NOT vulnerable. The hosts file is correct. exit 0; else # Device is vulnerable. The hosts file is not correct. exit 1; fi Note: Do not be confused by the return codes. The shell script must be written with the following information about the return codes in mind: exit 0 = Not vulnerable exit 1 = Vulnerable 2. On a Linux computer write and test a shell script that adds the new line to /etc/hosts. The following is an example script.
AddHostEntry.sh #!/bin/sh echo e 10.1.1.1\\tServerName exit 0 3. In the Management Suite console, click Tools Security Security and Patch Manager. 4. Before starting the Custom definition, under Type choose Custom Definitions and under Filter, click All items. 5. Click the Create custom definition icon (fourth from the left on the menu bar). A sample ID is generated. This can be changed to a value that more clearly defines the patch, such as Fix_hosts_file. 6. Enter a title such as the following: This makes sure the /etc/hosts file is up to date. 7. Configure the Severity as desired or leave the defaults. 8. Verify that the Status is set to Scan. 9. Create a rule by clicking the Add button at the bottom left of the window. 10. In the Properties for Rule 1 window, change the name to be something more descriptive, such as Check hosts for MyServer. 11. Add any comments if desired or leave the Comments field blank. 12. On the left tree list, click Affected Platforms. 13. CLick the desired Linux platform checkboxes. For this example, click the Red Hat platform checkbox. 14. On the left tree list, click Custom Script. 15. Enter a description if desired, or leave this field blank. 16. In the Script Content field, paste in the text from the DetectHostsEntry.sh script.
17. On the left tree list, click Patch Information. 18. Click This issue can be repaired without downloading a patch from the drop down menu. 19. For Requires reboot, click No. 20. For Silent install, click Yes. 21. On the left tree list, click Patch Install Commands. 22. Add a command by clicking the Add button. 23. CLick Run script from the drop down menu and click Ok. 24. A text field now appears. Paste the text from the AddHostEntry.sh file. Note: The text field will prompt for a VBScript, but do not be confused, even though it is prompting for a VBScript, this is the proper location to enter shell scripts for Linux custom vulnerabilities. 25. Click OK to save and close the rule. 26. Click OK again to save and close the custom vulnerability. 27. Right-click the vulnerability and click Repair. 28. Check only the Repair as a scheduled task option, leave all other options as defaults. 29. Click OK. 30. Drag your Linux device to the Scheduled task. 31. Right-click the task and click Start now. 32. Wait for the task to finish.
Note: The task should come back as successful, however, this does not mean the fix was applied. Linux vulscan does not scan and fix in one task. If the vulnerability was already detected prior to running this task, the fix will be applied. However, if the vulnerability was not already detected when successful the first time, the target device has only scanned for the vulnerability and has not applied the vulnerability. If you find the device in All devices, right-click it, and click Security and Patch Information, if the machine is vulnerable and did not repair, you will see this vulnerability under Detected Custom Definitions. The task must be launched as second time to repair the vulnerability. 33. Right-click the task and click Properties. 34. On the tree view on the left, click Schedule task. 35. Click the Start now radio button. 36. Click All from the Schedule these devices drop down menu. 37. Click Save to close the Scheduled tasks. Properties window and to start the task on all devices, including those that already show successful. 38. Wait for the task to finish. Note: The task should come back successful, and for this second deployment of this task, it should have repaired the vulnerability because the If you find the device in All devices, right-click it, and click Security and Patch Information, if the machine has repaired, you will no longer see this vulnerability under Detected Custom Definitions. However, you should see the patch under Clean/Repair History. However, if you clear your history, this information will not be available. If you want to enhance the custom definition, you could configure it to detect Installed Patches, that way, even if you clear your history, it will be possible to verify that this patch was installed by looking at Installed Patches. Your device should now be patched.
Uninstalling the Linux Agent Open a shell on the Linux Server or Workstation. This can be done either directly on the Linux Server or Workstation or by connecting via SSH. As root, or using sudo, run the following commands from the shell: 1. From the Core Server, mount a drive to the ldmain share. # mkdir /mnt/ldmain # mount t cifs o username=user,workgroup=domain \ //Core/ldmain /mnt/ldmain Note: On older Linux platforms cifs may need to be replaced with smbfs. 2. Copy the Linux uninstaller locally. # cp /mnt/ldmain/linuxuninstall.tar.gz /tmp 3. Extract linuxuninstall.tar.gz. # cd /tmp # tar -xzf linuxuninstall.tar.gz 4. Run the extracted uninstaller (the command is case sensitive). #./linuxuninstall.sh f ALL Note: For more uninstall options, run linuxuninstall.sh with the following parameter: #./linuxuninstall.sh -? Software Distribution Management Suite supports deploying RPMs to Linux agents. Currently only RPM deployment is supported. However, you can configure dependent packages if required. Other package types, such as.deb are not yet supported as a Distribution Package. Deploying RPMs Deploying an RPM with Management Suite can be done following this process:
Place the RPM on a Web share. Create a Distribution Package Create a Scheduled Task To Deploy an RPM, perform the following steps: Step 1 Place the RPM on a Web Share 1. Obtain a copy of the RPM. RPMs can come a CD, such as the Red Hat installation media or it can come from many different online sites. 2. Place the RPM on a Web share in the Core Server s ldlogon directory Note: If you do not have a Web share you know of, don t worry. The Core Server has a Web share by default. There is a folder in ldlogon called RPMS. Place you RPM files in that folder. Be aware that while you can use your Core Server as a package server, it is recommended that you have a separate package server so your Core Server doesn t suffer additional load. Step 2 Create a Distribution Package 1. From the Management Suite Console, click Tools Distribution Distribution Packages. 2. Right-click Public packages and click New Linux Package (it must be a public package). 3. Give the package a name and a description. 4. For the primary file, enter the Web share path to the RPM file. This would be something like the following: http://coreserver/ldlogon/rpms/somefile.rpm 5. Click Save. At this point the RPM is parsed and its dependencies are displayed in a window. Some of these dependencies are going to already exist on all you workstation. 6. Check the checkbox next to any dependencies that all of your Linux systems are sure to have. 7. Click Ok to finish. The Distribution Package is now created. Step 3 Create a Scheduled Task 1. From the Management Suite Console, click Tools Distribution Scheduled Tasks.
2. Right-click My Tasks and click Create Software Distribution Task. 3. Click the desired Distribution Package. 4. Click the desired Delivery Method. 5. Click Save. 6. Add the target devices to the task either by dragging devices or a by dragging a query to the task. 7. Right-click the task and click Start Now. Running Custom Scripts Custom Script functionality is available for Linux Agents and a lot of functionality can be obtained through these as they are very customizable. A good example of a Custom Script that works with Linux can be found be looking at the bottom of an Inventory Scanner script. You can see that the following script ran an inventory scan regardless of the platform, but for each platform, it does this a different way. [MACHINES_LINUX] REMEXEC1=/usr/LANDesk/ldms/ldiscan -ntt=%server%:5007 Deploying a Shell Script as a Custom Script A shell script can be deployed with LANDesk Management Suite. The process is to download the shell script, run the shell script, and then clean up by deleting the shell script. To deploy a Shell Script as a Custom Script do the following: 1. Place the shell script on a Web share. 2. In the Management Suite Console, click Tools Distribution Manage Scripts. 3. Create a New Custom Script. This opens a LANDesk Custom Script in the default editor for.ini files. 4. Delete all of the default lines and add the following lines:
[MACHINES_LINUX] ; Download thefile REMEXEC0=/usr/bin/wget http://172.16.27.9/software/shell/testfile.sh -O /tmp/testfile.sh, STATUS SYNC ; Make the file executable REMEXEC1=/bin/chmod +x /tmp/testfile.sh, STATUS SYNC ; Execute the shell script REMEXEC2=/tmp/testfile.sh, STATUS SYNC ; Clean up after ourselves by deleting the shell script REMEXEC3=rm -f /tmp/testfile.sh, STATUS SYNC 5. Save the file with an appropriate name and make sure the extension is.ini. 6. Verify that it does not save with the.txt extension. The script now appears in the Manage Scripts window. 7. Right-click the new Managed Script and click Schedule. 8. Drag the Linux devices and schedule the task. 9. Right-click the task and click Start now. The custom script is now scheduled and running. Imaging Linux Agents Imaging a Linux system could take hundreds of pages on its own, however, the attempt here is to highlight some key points that can help you take your imaging process model and implement it with LANDesk Management Suite. Provisioning or OS Deployment can be used, but this document will only cover OS Deployment. Windows PE or Linux PE? Linux PE and Windows PE can both be used to image Linux. Just because you are imaging Linux does not mean you have to use Linux PE. In fact, Windows PE may actually work better. A lot of production hardware requires very new drivers for network cards and drive controllers. Linux PE is a stripped down Linux build and is very difficult to alter. Adding drivers cannot be done in any easy manner. However, it can read EXT3 file systems without a problem. However, in Windows PE it is really easy to manage drivers, but by default, it is not going to be able to read your EXT2/3 file systems. There are Windows drivers to read EXT2/3, ReiserFS that you may be able to find and add yourself.
Preparing a Base Image A lot of thought should go into a base image. There are many items to consider. Some will be discussed in the following subsections. Software on the Base Image When creating a base image it is important to list all possible software that could be used in your environment and decide which software should be included on the image and which software should be left off the image and installed post-imaging. It is also important to determine any software (such as the LANDesk agent) that has data that must be unique on each agent. This software should be installed post-imaging. Some software allows you to delete the unique data and it will regenerate. It is not supported to put the agent on an image. LANDesk Software recommends installing the agent configuration after imaging. This avoids issues that may occur with our unique Device ID, as well as prevents any issues upgrading the agent that may make the image unusable. There also may be unexpected results using older agents with newer Core Servers. If the agent is not on your base image, then when you upgrade the Core Server, you do not have to upgrade your base image. If you must add the agent to the base image, even though it is not supported, you must remove the Device ID value from the /etc/ldiscnux.conf before creating the image. IP Address Configuration Multiple machines cannot exist on the same network with the same IP address. Any static IP address should be removed and the image should be configured for DHCP. This way the name and IP address will not be identical between imaged devices. If static IP addressing is desired, more work is involved. Somehow, you will have to create a process to map each Linux device to an IP address and change the IP address post-imaging. Host Name Multiple machines cannot exist on the same network with the same hostname. That means that if you image multiple devices at the same time, they should not have the same hostname. In Linux, the hostname can be managed via DHCP, which can make imaging much easier because the image process does not have to name the computers. Patching It is a good idea to decide what patches you plan to have on your base image. The more patches on your base image now, the less you will have to deploy later. It is also easier to manage future patches if the base image is up to date. Capturing the Base Image To capture a base image, perform the following: 1. Use Provisioning or OS Deployment to create an image capture process.
2. PXE boot the Linux device or create a Windows PE or Linux PE ISO or USB drive and boot from it. 3. Run the Capture Script or manually map a drive and run the imaging tool to capture the drive to the mapped drive. Tip: Create a capture script in OS Deployment using the GUI. The GUI designs the script for windows, but for a capture script, there is little difference between capturing an image of a windows drive or a Linux drive. Deployment Whether you use OS Deployment or Provisioning, you are going to have to do some advanced customization for the image deployment as there is not a wizard to create a Linux specific imaging process for you. To deploy a base image, perform the following 1. Use Provisioning or OS Deployment to create an image deployment process. 2. PXE boot the Linux device or create a Windows PE or Linux PE ISO or USB drive and boot from it. 3. Run the Deploy Script or manually map a drive and run the imaging tool to deploy the image. Tip: Create a deployment script in OS Deployment using the GUI. The GUI designs the script for windows, but once created, the windows commands can be easily removed or replaced with tasks needed for your Linux imaging process.
Appendix A - Troubleshooting the Linux Agent Install The first step of troubleshooting the Linux Agent install is to look at the output of the installation process. If manually installing the Linux agent, the output is immediately in front of you as it is output to standard out. If deploying the Linux agent, the scheduled task will be marked as failed. Expand the scheduled task and click to highlight Failed. Right-click the device and click View log file. The Core Server Never Connects to the Linux Device If you do not see much of a log, and it looks like the Core Server never connected to the Linux machine and never even logged in to install the software, verify that SSH is available on port 22 and that you can log into the Linux device using the root account that was added to the Additional logins for the scheduler service. If SSH is not enabled, you will realize this right away by trying to SSH to the Linux device. If you are a Linux administrator enabling SSH and providing the root account permission to log in using ssh is routine. Verify that the sshd daemon is running, that the sshd.conf file is properly configured, and that port 22 is open on the local firewall as well as any network firewalls. If you are not a Linux administrator, it may take some time to study and many internet searches. If you have a support contract, such as Red Hat and/or SUSE, they may be able to help you make this configuration. Otherwise, it is up to you to spend some time learning this. Linux is a community based platform and there are hundreds of Linux forums and there is plenty of online documentation that can be found with an internet search. If the Additional logins was not configured, you will see a log similar to the following:
[refusing authorization to store unknown host-key] The server's host key is not cached in the registry. You have no guarantee that the server is the computer you think it is. The server's rsa2 key fingerprint is: ssh-rsa 1024 64:39:f2:d4:5d:d3:40:6b:b5:f7:14:6f:1b:ca:1f:e4 If you trust this host, enter "y" to add the key to PuTTY's cache and carry on connecting. If you want to carry on connecting just once, without adding the key to the cache, enter "n". If you do not trust this host, press Return to abandon the connection. Store key in cache? (y/n) Access denied FATAL ERROR: Unable to authenticate CBA 8 X509 operation : -2147481845 (8000070b8u) : Unable to contact the remote agent. NT File Sharing : 1222 (4c68u) : The network is not present or not started. NT File Sharing : 1203 (4b38u) : No network provider accepted the given network path. Remote execute using TCP failed, result 0x0000057a (1402) Error: [last attempted operation] RemoteExecute, /bin/mkdir -p /tmp/.ldcfg-36-2356 Missing Dependencies Look for common errors, such as a missing dependency. It is common to find that xinetd, libstdc++, or sysstat RPMs might be missing. The following are examples of failures due to missing dependenies. The following is a clip from a log where the Linux Server Manager agent failed because the sysstat RPM was missing: ERROR:RC=-21:The package sysstat version 4.0.7 needs to be installed. INFO:Removing ldsmbios. INFO:Removing smbase. Finished with monitoring... ERROR: directory /usr/landesk/ldsm/ldclient missing Exiting with return code 20
Unsupported Platforms You cannot deploy the Linux agent to unsupported platforms. Attempts to do this usually fail. Currently we only deploy to Red Hat and SUSE. Clones of either platform usually do not work. Appendix B Sample Custom Definition The following is a sample of an exported Custom Definition: <?xml version="1.0"?> <Vulnerability xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema" Lang="INTL" Vul_ID="Fix hosts file" CVE_ID="" T="4" Revision="7"> <Status>Enabled</Status> <Title>This makes sure the hosts file is up to date.</title> <Description>This makes sure the hosts file is up to date. Our company needs the following to exist in the hosts file: 10.1.1.1 MyServer</Description> <Patches> <Patch Download="DManual" Silent="CRSYes" Reboot="RNo" UniqueFilename="*Fix hosts file_check for MyServer in hosts file" Hash="" Size="0"> <Name>Check for MyServer in hosts file</name> <Advanced> <DetectScript>#!/bin/sh if cat /etc/hosts grep 10.1.1.1 grep MyServer then exit 0; else exit 1; fi</detectscript> <DetectScriptDescription /> </Advanced> <Comments /> <URL /> <State>Enabled</State> <Files /> <RegKeys /> <Products /> <Platforms> <ID>rhas3</ID> <ID>rhes3</ID> <ID>rhws3</ID> <ID>rhas4</ID>
<ID>rhes4</ID> <ID>rhws4</ID> <ID>rhas4_x86_64</ID> <ID>rhws4_x86_64</ID> <ID>rhes4_x86_64</ID> <ID>rhas3_x86_64</ID> <ID>rhes3_x86_64</ID> <ID>rhel5</ID> <ID>rhel5_x86_64</ID> <ID>rhel5client</ID> <ID>rhel5client_x86_64</ID> <ID>openSUSE102</ID> <ID>openSUSE102_x86_64</ID> </Platforms> <UninstallInfo> <canbeuninstalled>false</canbeuninstalled> <requiresoriginalpatch>false</requiresoriginalpatch> <Files /> <RegKeys /> <Cmds /> </UninstallInfo> <CustVars /> <Cmds> <Cmd Type="ShellScript"> <Args> <Arg N="ScriptCode" V="#!/bin/sh echo - e 10.1.1.1\\tMyServer >> /etc/hosts exit 0" /> </Args> </Cmd> </Cmds> </Patch> </Patches> <DependsOn /> <PublishDate>2009-03-23T00:00:00</PublishDate> <Summary /> <Severity>3</Severity> <Vendor>custom</Vendor> <MoreInfoURL /> <FAQURL /> <Type>Custom</Type> <Category /> <AssociatedProducts /> <Groups /> </Vulnerability>
Appendix C OS Deployment Script Examples As stated before, the boot environment does NOT have to be Linux PE just because you are imaging with Linux. Both Windows PE and Linux PE can be used. Windows PE Capture Script [VALUES] Task=7 ScriptName=WinpE ImageW2 Capture Drive 0 ScriptDescription=WinpE ImageW2 Capture Drive 0 FallBackNIC= UseFallBackNIC=FALSE ImageUserName=YourUser ImageDomain=YourDomain ImagePassword=102F12858EEB77577E04F627A3B ImageToolType=11 ImageUNC=\\ShareServer\images\Ubuntu ToolUNC=\\CoreServer\ldmain\osd\imaging\2.0\imagew.exe ImageToolCmd=H:\osd\imaging\2.0\imagew.exe /b /uy /d:0 /rb:0 /max:2gb /f:"i:\ubuntu\%computer - Device Name%" [OWNER] GUID=e3f8aee5-e03e-46f9-a28d-7019d0a73d2f OSDPLUG=TRUE DESCRIPTION=WinpE ImageW2 Capture Drive 0 NAME=WinpE ImageW2 Capture Drive 0 TYPE=WinPE [JOBPARAM] ABORT_ON_CMD_FAILURE=1 TASK_COMPLETION_ENABLED=FALSE [MACHINES] BEGINWINPE=TRUE REMPING16=WINPE, TIMEOUT=1800 REMEXEC17=diskpart /s X:\LDClient\rmvol.txt REMEXEC18=drvmap.exe YourDomain\YourUser 102F12858EEB77577E04F627A3B I: <qt/>\\shareserver.yourdomain.lab\images<qt/>, STATUS FACILITY=3513 REMEXEC19=drvmap.exe YourDomain\YourUser 102F12858EEB77577E04F627A3B H: <qt/>\\coreserver.yourdomain.lab\ldmain<qt/>, STATUS FACILITY=3513 REMEXEC22=H:\osd\imaging\2.0\imagew.exe /b /uy /d:0 /rb:0 /max:2gb /f:"i:\ubuntu\%computer - Device Name%" REMEXEC23=reboot, timeout=2
Linux PE Capture Script [VALUES] Task=9 ScriptName=LinuxPE Capture Linux drive ScriptDescription=LinuxPE Capture Linux drive FallBackNIC= UseFallBackNIC=FALSE ImageUserName=YourUser ImageDomain=YourDomain ImagePassword=102F12858EEB77577E04F627A3B ImageToolType=6 ImageUNC=\\ShareServer\images\Ubuntu ToolUNC=\\CoreServer\ldmain\osd\imaging\imagel.elf ImageToolCmd=/usr/sbin/vterm cd /mnt/h/osd/imaging;/mnt/h/osd/imaging/backall.sh 0 /mnt/i/ubuntu/%computer - Device Name{6}%, STATUS FACILITY=3510 [OWNER] GUID=0b00a56a-5884-484e-a38b-6905853a10be OSDPLUG=TRUE DESCRIPTION=LinuxPE Capture Linux drive NAME=LinuxPE Capture Linux drive TYPE=LINUX [JOBPARAM] ABORT_ON_CMD_FAILURE=1 TASK_COMPLETION_ENABLED=FALSE [MACHINES] BEGINLINUXPE=TRUE REMPING0=LINUXPE, TIMEOUT=1800 REMEXEC1=mkdir /mnt/i REMEXEC2=mkdir /mnt/h REMEXEC3=/usr/LANDesk/osd/drvmap //ShareServer/images /mnt/i -u YourUser/YourDomain -p 102F12858EEB77577E04F627A3B, STATUS FACILITY=3513 REMEXEC4=/usr/LANDesk/osd/drvmap //CoreServer/ldmain /mnt/h -u YourUser/YourDomain -p 102F12858EEB77577E04F627A3B, STATUS FACILITY=3513 REMEXEC5=/usr/sbin/vterm cd /mnt/h/osd/imaging;/mnt/h/osd/imaging/backall.sh 0 /mnt/i/ubuntu/%computer - Device Name{6}%, STATUS FACILITY=3510 REMEXEC6=/sbin/reboot
Windows PE Deploy Script [VALUES] Task=8 ScriptName=WinPE Deploy Ubuntu 8 ScriptDescription=Deploy Ubuntu 8 MCast=0 FallBackNIC= UseFallBackNIC=FALSE ImageUserName=YourUser ImageDomain=YourDomain ImagePassword=102F12858EEB77577E04F627A3B ImageToolType=11 ImageUNC=\\ShareServer\images\Ubuntu\UD804.TBI ToolUNC=\\CoreServer\ldmain\osd\imaging\2.0\imagew.exe Partition=1 ImageToolCmd=h:\osd\imaging\2.0\imagew.exe /r /o /d:0 /f:"i:\ubuntu\ud804.tbi" /rb:0 ImageToolCmdsFile=\\CoreServer\LDMAIN\LANDESK\FILES\WinPE Deploy Ubuntu 8.txt IsSysPrepImage=0 ConfigAdvancedMCast=0 UseWOL=FALSE WOLSeconds=120 DiscoveryType=0 MaxTMCThreads=5 MinTMCSleep=1 MaxTMCSleep=200 SubrepTTL=14 TargetTTL=2 [OWNER] GUID=e51782e5-b807-4bd3-b222-8d0423642166 OSDPLUG=TRUE DESCRIPTION=Deploy Ubuntu 8 NAME=WinPE Deploy Ubuntu 8 TYPE=WinPE [JOBPARAM] ABORT_ON_CMD_FAILURE=1 TASK_COMPLETION_ENABLED=FALSE [MACHINES] BEGINWINPE=TRUE REMPING16=WINPE, TIMEOUT=1800 REMEXEC17=diskpart /s X:\LDClient\rmvol.txt
REMEXEC18=drvmap.exe YourDomain\YourUser 102F12858EEB77577E04F627A3B I: <qt/>\\shareserver.yourdomain.lab\images<qt/>, STATUS FACILITY=3513 REMEXEC19=drvmap.exe YourDomain\YourUser 102F12858EEB77577E04F627A3B H: <qt/>\\coreserver.yourdomain.lab\ldmain<qt/>, STATUS FACILITY=3513 REMEXEC22=h:\osd\imaging\2.0\imagew.exe /r /o /d:0 /f:"i:\ubuntu\ud804.tbi" /rb:0 REMEXEC35=reboot, timeout=2 Linux PE Deploy Script [VALUES] Task=10 ScriptName=Linux PE Deploy Ubuntu 8 ScriptDescription=Linux PE Deploy Ubuntu 8 MCast=0 FallBackNIC= UseFallBackNIC=FALSE ImageUserName=YourUser ImageDomain=YourDomain ImagePassword=102F12858EEB77577E04F627A3B ImageToolType=6 ImageUNC=\\ShareServer\images\Ubuntu\fake ubuntu image.img ToolUNC=\\CoreServer\ldmain\osd\imaging\imagel.elf Partition=1 ImageToolCmd=/usr/sbin/vterm cd /mnt/h/osd/imaging;/mnt/h/osd/imaging/imagel.elf /RN /O /mnt/i/ubuntu/fakeub~1.img, STATUS FACILITY=3510 ImageToolCmdsFile=\\CoreServer\LDMAIN\LANDESK\FILES\Linux PE Deploy Ubuntu 8.txt IsSysPrepImage=0 ConfigAdvancedMCast=0 UseWOL=FALSE WOLSeconds=120 DiscoveryType=0 MaxTMCThreads=5 MinTMCSleep=1 MaxTMCSleep=200 SubrepTTL=14 TargetTTL=2 [OWNER] GUID=004dbc12-b44d-4724-9b95-106b1819e9f3 OSDPLUG=TRUE DESCRIPTION=Linux PE Deploy Ubuntu 8 NAME=Linux PE Deploy Ubuntu 8
TYPE=LINUX [JOBPARAM] ABORT_ON_CMD_FAILURE=1 TASK_COMPLETION_ENABLED=FALSE [MACHINES] BEGINLINUXPE=TRUE REMPING0=LINUXPE, TIMEOUT=1800 REMEXEC1=mkdir /mnt/i REMEXEC2=mkdir /mnt/h REMEXEC3=/usr/LANDesk/osd/drvmap //ShareServer/images /mnt/i -u YourUser/YourDomain -p 102F12858EEB77577E04F627A3B, STATUS FACILITY=3513 REMEXEC4=/usr/LANDesk/osd/drvmap //CoreServer/ldmain /mnt/h -u YourUser/YourDomain -p 102F12858EEB77577E04F627A3B, STATUS FACILITY=3513 REMEXEC5=/usr/LANDesk/osd/wipepart auto remove REMEXEC6=/etc/init.d/edd start REMEXEC7=/usr/sbin/vterm cd /mnt/h/osd/imaging;/mnt/h/osd/imaging/imagel.elf /RN /O /mnt/i/ubuntu/fakeub~1.img, STATUS FACILITY=3510 REMEXEC19=/bin/sync REMEXEC21=/sbin/reboot
About LANDesk Software The foundation for LANDesk Software s leading IT management solutions was laid more than 20 years ago. And LANDesk Software has been growing and innovating the systems, security, service, and process management spaces ever since. Our singular focus and our commitment to understanding customers real business needs and to delivering easy-to-use solutions for those needs are just a few of the reasons we continue to grow and expand. LANDesk Software pioneered the desktop management category back in 1993. That same year, IDC named LANDesk Software the category leader. And LANDesk Software has continued to lead the systems configuration space: pioneering virtual IT technology in 1999, revolutionizing large-packet distribution with LANDesk Targeted Multicast technology and LANDesk Peer Download technology in 2001, and delivering secure systems management over the Internet and hardware-independent network access control capabilities with LANDesk Management Gateway and LANDesk Trusted Access Technology in 2005. In 2006, LANDesk Software added process management technologies to its product line and began integrating the systems, security, and process management markets. LANDesk Software also extended into the consolidated service desk market with LANDesk Service Desk, and was acquired by Avocent to operate as an independent division. Today, LANDesk Software continues to lead the convergence of the systems, security, process and service management markets. And our executives, engineers and other professionals work tirelessly to deliver leading solutions to markets around the globe.