Table of Contents
In your IT environment, making hard disk images, saving files, making software and hardware inventories, or taking control of remote computers are essential features to efficient management. Everyday needs include the ability to deploy new applications, unattended, on one or more computers, in a secure way. That's the purpose of the Linbox Secure Control module (LSC).
The LSC module allows an administrator to:
Manage the files and directories of a computer which has the LSC agent installed;
Transfer files from the LRS to one of more computers;
Launch programs or scripts on one or more target computers;
Display the logs files of your actions; or
Secure the remote access to a computer's screen/keyboard/mouse.
The LSC uses OpenSSH, the Open Source implementation of the SSH "secure shell". The sshd service has to be installed on each computer which needs to be managed. The LSC works with MS Windows (NT, 2000, XP, 2003) with our provided SSH server, Linux, MacOS X or any UNIX system where SSH is available.
SSH allows secure communications between the LRS server and the managed clients with strong cryptography. Public-key cryptography is used so that you do not have to frequently type passwords when you log in managed computers. All the features are available through the easy to use, and powerful LSC Web interface. Transferring files and launching programs can be done on a single client or on a set of clients (group, sub-group, or profile).
Using the LSC together with LRS disk imaging functions allows you to manage your IT environment by creating a few basic disc images, and then automatically deploy needed applications on demand.
SSH allows to launch commands on a remote machine and to download or upload files, using secure communications. SSH provides strong cryptography. Before doing anything on a remote computer using SSH you have to authenticate yourself.
Many authentication methods are available with SSH, like a simple login / password prompt, or public-key cryptography. In this case, a public/private key pair is generated, and the computer account which holds the private key, can connect to any computer account that has installed the public key. This is the authentication method used by the LSC.
You have to create the key pair when you install the LRS server.
To create the key pair, log in as root on the console and type :
ssh-keygen -t dsa
Do not enter a pass phrase. The files /root/.ssh/id_dsa and /root/.ssh/id_dsa.pub are now created. They hold the private key (id_dsa) and the public key (id_dsa.pub). If you take a look at these files, you'll see something similar to this:
-----BEGIN DSA PRIVATE KEY----- HbHHUZ/78gdgqdYugmKK2EYqPGvRx0jox1FhvJSh4r5mR/KgxopzTTearlENMg/7 TL8Bfs0raTNLEjnQjzMag9N8YojEVIkp//l7PCD5FzZ4JzZ+SVdItXAJzp3d+CmT /oXu+msuLUy8Ltg5S8R1cIjr28rddelotAaeaVacaTNUb+4PeYb2Vb8zMdgqkiPp 8ITfeoaeZaI7b4YH74aB4LznAoGAajh9r9QEMaLRMvoHRZ+oBk2sAlAxZIU0j6TZ VxwHMZ9ZNtn8tsN+L6VSD+ZnGeXwetWcpamU07kFI8XKRIghtwQzUnmLO7uc1v3s VreO8wViFZByB5apPWrhYAXKuxIsX69UVriSE5Lgw4AooUESLd1zLXAqb57njBo9 a9cs2b4CgYBCDFJlJjxaKpl+fLWUf0XFuBavEBIMj7zmyzChUaSFC2DtYxlpiFxR cBcjIUY+E2y/oQxmuTg3K1/J/ohR2jRcpitod5DkSnm5g/RWJKOHU0BDxwIVAMDe O+RsAJrlY4VExepy1NH8g3iV17cS7vPLr22/DGc/VPY0q7o5vvzsfQIVALmV5KIn Hbzk4aHvTIIdAIQWmq+O -----END DSA PRIVATE KEY-----
To manually install the key on client hosts, copy the file /root/.ssh/id_dsa.pub to /tftpboot/revoboot/images/data. It will be available in the data share of the LRS Samba server.
![[Warning]](/ucome.rvt/any/en/Produits/LRS/details/doc/img/warning.png) | |
You should never make the private key id_dsa, public on any file server! If the private key is taken, any person with that key will have unrestricted access to your computers which have installed the public key. |
![[Tip]](/ucome.rvt/any/en/Produits/LRS/details/doc/img/tip.png) | |
The LSC module can also use SSH keys protected by a 'passphrase'. In that case, you have to use the 'keychain' program to launch the SSH agent, and add the keys in the agent with a key lifetime large enough to be valid when the task is run by the scheduler. |
To use the LSC you will have to install software (the SSH service) on your client hosts. This installation can be done manually, or using the post-installation feature of the LRS (see Chapter 11, Post-installation Scripts Development Guide).
As MS Windows system do not have a SSH service available, sysadmins can download a ssh agent (Cygwin/SSHd based) from the LRS server.
| |
MS WIndows systems which do not have services (ie. not based on a NT4 or post. NT4 kernel) can no run the agent. The officialy supported systems are:
For now MS Windows Vista platforms are untested. |
The following paragraphs describe howto to deploy this agent.
You have to run setupssh.exe on MS Windows hosts to install the SSH service. You should be connected as Administrator to properly install it.
Setupssh.exe can be found in the LRS download area or directly at the URL http://lrs_ip_address/download/setupssh.exe.
Before running setupssh.exe, you should copy the public key id_dsa.pub (available from the data LRS share) to C:\. Now execute the program, the service and the key will be installed.
In the "system backup" post-installation module, you will find scripts to install the SSH server and the public key, or SSH plus VNC: lscssh and lscsshvnc. These post-installation scripts can be either run after restoring a disk image, or during a stand alone post-installation without installing a new image. To this end, the public key id_dsa.pub must have been copied from /root/.ssh/id_dsa.pub to the /tftpboot/revoboot/images/data directory.
Click on the "magnifying glass" next to your local or shared image, and choose the post-installation script below "Post-installation script used" (see Section 4.7, “Image details”).
To install setupssh.exe without restoration, you should add the "Postinst" shared image to the boot menu. Then in the client's boot menu "Option" tab choose the post-installation script (see Section 4.5, “Boot and back up options”).
A SSHd (OpenSSH based) service is generaly available on this systems family. To ensure system access to the LSC, the root's public SSH key (/root/.ssh/id_dsa.pub) must be added to the autorised keys list of the root account of the client computer (/root/.ssh/authorize_keys):
root@client# ssh root@server "cat /root/.ssh/id_dsa.pub" >> /root/.ssh/authorized_keys
![[Note]](/ucome.rvt/any/en/Produits/LRS/details/doc/img/note.png) | |
If the client do not support DSA keys, a RSA key is also available. Please replace « id_dsa.pub » by « id_rsa.pub » in the previous example to use it. |
| |
For the LSC to connect to the client, this one must:
|
In order to see the Web interface of the "Secure Control", you just have to click on the following icon, in the LRS control center.
The Control Center module has the following tabs:
General: general information;
Repository: file repository;
Explorer: remote file browser;
Command states; and
All commands states.
The general tab shows general information about one client, and also some generic actions that can be launched on this client (like machine shutdown, machine reboot, inventory refresh).
The profile and the group of the selected client are also displayed.
The object of this LRS module is mass management of computer workstations. Linbox recommends managing computers by dozens or hundreds, and not individually.
The files repository is an area of the LRS server, which contains directories and files which can be uploaded and executed on all or part of the clients managed by the LRS. The two tabs "Command states" and "All command states" allows you to make sure that the scheduled tasks went smoothly.
If the connection to a client fails, the module will try once again, to carry out the task (files transfer and execution). The parameters below the directory list, allows setting the time interval between two attempts, the number of retries, the command expiration date.
The files repository can be seen from the Web interface but also, from the SMB/CIFS share \\lrs_server_name\lsc or \\lrs_ip_address\lsc (anonymous access, no password needed). On the server, the files are located in the /tftpboot/revoboot/lsc directory.
The repository interface is divided in four parts:
The directory tree on the left;
The current directory list;
Scheduling options for the command; and
File uploading to the repository.
The goal is to prepare a task that aims to install files or executables on the target clients group.
For each file in the repository, you can see three actions similar to the ones found in the explorer, and two other columns:
The first column contains a checkbox. When checked, the file will be uploaded to the host, when the task will be executed.
The second one contains a radio button, to select which file will be executed for this task.
After having selected all the files to copy and run, set the installation options in the "Task options on host" section. In order to clarify your log files, you should set the task title. For example set the task title to "OpenLook Installation 2018/11/13 on host Winux 20015." Then, you can choose to launch the task A.S.A.P. or at a given date / time in the field "Start date". You can also set an expiry date for the retries in the "expiry date" field.
Some additional arguments can be sent to the program or script which will be run on the target hosts, in the "Execution arguments" field.
After the task is completed, the uploaded files will be deleted if you check the "delete files" checkbox.
You can also ask to update the inventory with the "Run the inventory" option.
With the checkbox "If connection fails, send a WakeOnLan request", a "Wake On Lan" request is sent to the host and two minutes later, the task is run one more time. You can also set the "maximum connection attempts" and the "delay between two connections".
Using the "Action to perform after a successful command" option, you can ask the client to reboot / shutdown / whatever upon deployement success.
Eventually, you have to click on the "Launch the task" button, to launch or schedule the task.
Most of the default values and parameters seen above, as well as the directory where the files are transferred on the targets, can be set by clicking on the "Module Config" link in the top left-hand corner.
The explorer tab is not available when you have selected a group of clients in the control center, as you cannot browse files of multiple clients simultaneously.
For a given client, this tab allows you to see the contents of its hard disk. A standard layout is used, with the directory tree on the left, directory contents in the center, and related actions for each file or directory on the right. At the bottom, you can create or send files in the current directory.
Please note that the directory tree on the left, uses a kind of "UNIX" notation for MS Windows based clients: the /c directory corresponds to the C: drive, /d to the D: drive and so on.
The following information is displayed in the "file list" table :
Type: one icon depicts the file type;
File name: file name with extension;
Size: size in bytes;
Last update date; and
Actions;
See the file's contents
Edit the file, if it's a text file
Remove the file or directory
Run the file
You can also create an empty file or a new directory in the current directory, or upload a file from your workstation.
Once a task has been scheduled you can see the progress and the current task's state. A task goes through three states:
File transfer;
Command execution; and
Files removal.
Each state includes two sub-states: the beginning and the end of the state. So, for each task, its state and log files are available with even more details. Below, you can see the state of all commands launched via the LSC:
To see the commands state for only one client, click on the "commands state" tab:
For each task or command, you will see when the task has been scheduled, when it will start, when it will expire, and its state (upload in progress, upload done, upload failed, execution in progress, execution done, execution failed, delete in progress, delete done, delete failed, inventory execution in progress, inventory execution failed, inventory execution done, connection error, command done, command paused, command stopped, command scheduled).
By clicking on the magnifying glass icon, you will see detailed logs about the task, and a reminder of the task's parameters.
Commands and error codes are written in blue, info output (STDOUT) in green, error output (STDERR) in red, and timestamps in grey.
There are many packaging software and installers to add new software under MS Windows. The Microsoft standard is to use MSI packages. You'll find interesting information, related to MS Windows installers, on the Unattended open source software Web site (a free alternative to Microsoft RIS). That page talks about command line installation: http://unattended.sourceforge.net/installers.php .
For MSI packages, you will find numerous information on www.msdn.com, such as:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/command_line_options.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/standard_installer_command_line_options.asp
Many installation procedures are also available from www.appdeploy.com . You will see below, how to install a few popular packages under Windows with the LSC.
The Firefox install is straightforward. Create a file named "Install_firefox.bat" in the same directory as the Firefox installation file, Firefox_Setup_2.0.0.1.exe and use the options -ms and -ira. Linbox tested the install with or without the option -ira, but some users need this option. If you require -ira, put the following line in 'install_firefox.bat":
Firefox_Setup_2.0.0.1.exe -ms -ira
Now upload this file and the .exe in a sub-directory of the repository (using the 'lsc' share for example), create a new task and select the two files for copy, and the .bat file for execution.
A tutorial and a lengthy discussion about OpenOffice unattended installation can be read here: http://www.oooforum.org/forum/viewtopic.phtml?t=606 .
To sum up, you need to use StarOffice response files. Then the command line is "setup.exe -r <reponse_file>" or "setup.exe -r C:\officeop.txt -D <installation>\<path>\OpenOffice.org\" .
For a properly defined installation, the response file looks like this:
; Basic settings [Environment] InstallationMode=INSTALL_NORMAL DestinationPath=C:\Program Files\OpenOffice.org ; Little hack to disable the QuickStarter [Module_Specify] InstallProcedure = MySelectProc [Procedures] Sub MySelectProc SelectModuleByName ( "OpenOffice" ) DeSelectModuleByName ( "QuickStarter" ) End Sub
OOo 2 uses a MSI setup file, so the installation method looks like MS Office, with the detailed msiexec options below. A MSI file editor can also be used to customize even more the install: ORCA (http://support.microsoft.com/kb/255905/EN-US/).
You will find additional information at http://documentation.openoffice.org/setup_guide2/ and http://documentation.openoffice.org/setup_guide2/2.x/en/SETUP_GUIDE_draft.pdf
The set of files needed for the OpenOffice 2.0 install (French version) is the following:
Set of OpenOffice 2 files in the files repository
The .bat file which needs to be run is ins_silent_OOo2.bat:
@echo off echo Install started chmod ugo+rx * msiexec.exe /i openofficeorg20.msi /qn /lv OOo2.log.txt echo Install done more OOo2.log.txt rm -f OOo2.log.txt
Everything that is displayed to the "standard output" or "standard error" streams will appear in the detailed logs of the Web interface. So, "Install started" will be displayed in the logs. The command «chmod ugo+rx *» is run to make sure that all files executed by msiexec have the "executable" flag set (Cygwin is behind the Linbox SSH server for Windows, so you can use UNIX like commands in your scripts).
The options used here are quite common: /i filename.msi /qn (no GUI) /lv log_file.txt. The full list of msiexec options are:
/i openofficeorg20.msi: /i followed by the name of the MSI package to install
/qn: /q is about the GUI. /qn , ('q' followed by 'n') disable any GUI. This option is mandatory for any unattended installation with the LSC module.
/lv OOo2.log.txt: /l or /L is related to log files. Here the logs are written in the current directory, in the OOo2.log.txt file. Beware, if a full path is specified, all directories must exist. The default options are 'iwearmo' . The other options are:
i: status messages
w: nonfatal warnings
e: all error messages
a: startup of actions
r: action-specific records
u: user requests
c: initial user interface parameters
m: out-of-memory errors
o: disk space errors
p: terminal properties
v: verbose output
x: debugging information (only on Windows server 2003)
+: appends to existing file.
!: flushes each line to the log (can be used in case of memory overflow)
*: logs all information except for the v and x option. To include the v option in a log file using the wildcard flag, type /L*v at the command prompt.
Two installation methods are available:
Simple silent installation: See http://unattended.msfn.org/intermediate/apps/office/officexp_simple.htm . The command is "start /wait <path>\<to>\OfficeXP\PROPLUS.msi /Qn /Lv officexppro.log.txt". Automatic configuration is done, and all default options are installed.
Advanced silent installation: packages to install can be selected (see http://unattended.msfn.org/intermediate/apps/office/officexp_advanced.htm) . To be able to chose the installation parameters, a first install is done and then the preferences are saved in a file named transform.mst. To this end, Microsoft ORCA should be used.
Install and run ORCA by going to "start -> programs -> ms office tools ->ms office resource kit-> custom installation wizard". Then:
In the 1st page: click on next.
2nd page: specify the msi file (i.e. d:\proplus.msi, for Office with Powerpoint, otherwise pro.msi for a 'pro' release).
3rd page: select "create a new mst file."
the following pages will allow you to customize the automatic installation.
After that, a .mst file is generated, which will be used for the installation. There are two ways to use this file:
<path>\<to>\\OfficeXP\setup.exe TRANSFORMS=Transform.MST /qb-
msiexec.exe /i <path>\<to>\openoffice.msi /qn TRANSFORMS=myTransform.mst
N.B.: Miscellaneous links on Office XP deployment: http://www.microsoft.com/technet/itsolutions/cits/dsd/bdd/bddxp03.mspx
IBM WAS can be silently deploy using Response Files. RSP files are used to configure Install with some answers, thus pre-filling the installation wizard questions. As the wizard can be run in silent mode (-silent), using a response file able the LSC to deploy IBM WAS.
To perform a silent install, the following command line must be used:
./install -options "/path/to/the/responsefile.nd.txt" -silent
IBM provides a ready-to-use response file (responsefile.nd.txt), in which a few changes are to be done for the silent install to be performed. Here is an example of a response file (without comments) :
-OPT silentInstallLicenseAcceptance="true" -OPT installType="installNew" -OPT feature="noFeature" -OPT installLocation="/opt/WebSphere/AppServer61" -OPT profileType="none"
The LSC package will contain:
the full WAS tree,
your custom response file (f.e. myresponsefile.nd.txt),
and an installation script:
# perform install ./WAS/install -options ./myresponsefile.nd.txt -silent # gather exit code logFile="$INSTALL_DIRECTORY/logs/install/log.txt" result=`tail -1 $logFile | grep INSTCONFSUCCESS` # gather logs cat $logFile # exits if [[ "$result" = "" ]]; then exit 1 fi exit 0
The LSC can be used to deploy system patches, either security/bugfixes or native packages.
Security and bug-fixing patches are often released by Microsoft for its MS Windows OS customers. Most of theses patches can be deployed using the LSC, for the cost of a few research about the patch to deploy.
To obtain informations about a specific patch, you must first obtain the patch number. This is the ID number under which it appraise on the automatic update screen (which you can reach by clicking on the « Windows Updates » icon in the task bar, then selecting « custom installation »):
patch #329170
Then you have to collect informations about the patch, more specifically how to run on a non-interactive modus. For this part you can go on http://support.microsoft.com/kb/<patch-number> . On the page look for the link which will able you to get the patch which applies to your platform and download it. Also read carefully the installation instruction, more precisely how to install it in a fully automatic manner. For example, for the patch #329170, you will have to use the following command line:
q329048_wxp_sp2_x86_en / u /q
(/u for an automatic installation, and /q for the update window not to be shown).
You have now the patch and the relevant arguments to install it automatically and silently. The next stage is to built the corresponding LSC package:
in the LSC repository, please create the directory which will contain the package (for example /ms_windows/patches/329170),
in this directory create a file named « deploy_patch.bat » which will contain:
./q329048_wxp_sp2_x86_en /u /q
do not forget to also put the patch into the previous directory.
Your LSC package is now ready to be deployed.
The LSC can be used for IBM AIX's BFF packages installation and removal. Here again the principle is to use a command line crafted to enable a fully non-interactive installation. AIX manpage tells that to install a .bff archive in a non-interactive way, one should use installp with the following syntax:
installp -a -c -d <path to a arch repo> -X <package to install>
For example, to install the OCS inventory agent on an AIX 5.3, the command line will be:
installp -a -c -d ./ocsng-client-aix-53.bff -X freeware.ocsng-client.rte
A uninstall command can even added to our LSC package:
installp -u freeware.ocsng-client.rte
Thus the following files will constitute our OCS Agent deployment package:
an installation script (install.sh),
a uninstallation script (uninstall.sh),
a bff archive (ocs-client-aix-53.bff).
Solaris packages can also be installed thanks to the LSC. The principle is the same as under AIX (see upper), only commands differ.
Here the installation command will be (we uses yes to inhibit the questions that pkgadd could ask to the operator):
yes | pkgadd -d ./ocsng-client-solaris10 Mocsng-client
And to remove:
pkgrm -n Mocsng-client
The final package will be:
an installation script (install.sh),
a delete script (uninstall.sh),
a Solaris archive (ocsng-client-solaris10).
In the LSC file repository, under the 'linbox' directory, you'll find a few example .bat files to install some software. To use the provided examples, you will need to copy the directory to another location and add the needed setup.exe files. For example, to try to install Mozilla Firefox, you will have to copy linbox/install-firefox to my-firefox-install in the LSC repository, and download Firefox_Setup_2.0.0.1.exe to the directory.
The following examples are supplied:
install-OOo2: OpenOffice.org 2.x installation.
install-firefox: Mozilla Firefox 2.0.x installation. Firefox_Setup_2.0.0.1.exe is needed.
install-inventory: LRS inventory agent installation. The LRS server name is configured as «LRS». Please edit the .bat file if the server name is different.
install-vnc: Normal TightVNC 1.2.9 server installation
install-vncssh: Secure TightVNC 1.2.9 server installation (VNC over SSH).
update-inventory: Remove old inventory agents, and install the latest release. Can be used to upgrade from v3.x agents to v4.x agents. The LRS server name is configured as «LRS». Please edit the .bat file if the server name is different.
update-ssh: update the SSH server used by the LSC after the next reboot.
run-inventory.bat: force an inventory agent run.
The LSC database uses four tables:
commands
commands_on_host
commands_history
version
The "commands" table contains orders scheduled with the Web interface, for a single client or a group/profile. The "commands_on_host" table contains the commands which need to be sent individually on each client. The "commands_history" table contains the logs for each task like file copy, execution, and file removal. Finally, the "version" table contains the current database version to keep track of updates.
| Field | Type | Other | Comment |
|---|---|---|---|
| id_command | int(11) | auto_increment | Primary index key |
| date_created | datetime | Task creation date | |
| start_file | tinytext | ||
| parameters | text | Task parameters | |
| path_destination | text | Destination path for files | |
| path_source | text | Source path for files | |
| create_directory | enum('enable','disable') | Create or not, the destination directory | |
| start_script | enum('enable','disable') | Execute or not the command | |
| delete_file_after_execute_successful | enum('enable','disable') | Remove or not the files if successful | |
| files | mediumtext | ||
| start_date | datetime | When to start the task | |
| end_date | datetime | When to stop the task or any attempt | |
| target | tinytext | Target clients using profile:/group/subgroup/client . | |
| username | varchar(255) | SSH username | |
| dispatched | enum('YES','NO') | ||
| title | varchar(255) | Task title | |
| start_inventory | enum('enable','disable') | Launch the inventory at the end | |
| wake_on_lan | enum('enable','disable') | Try a "wake-on-lan" if there's a connection problem | |
| next_connection_delay | int(11) | Delay between 2 connection tries | |
| max_connection_attempt | int(11) | Number of tries before giving up |
| Field | Type | Other | Comment |
|---|---|---|---|
| id_command_on_host | int(11) | auto_increment | Primary key |
| id_command | int(11) | Key linked to the 'commands' table | |
| host | tinytext | Client name | |
| start_date | datetime | Task start date | |
| end_date | datetime | Task end date | |
| current_state | enum('upload_in_progress', 'upload_done', 'upload_failed', 'execution_in_progress', 'execution_done', 'execution_failed', 'delete_in_progress', 'delete_done', 'delete_failed', 'inventory_in_progress', 'inventory_failed', 'inventory_done', 'not_reachable', 'done', 'pause', 'stop', 'scheduled') | Current status of the task | |
| uploaded | enum('TODO', 'IGNORED', 'DONE', 'FAILED', 'WORK_IN_PROGRESS') | Status of file uploading | |
| executed | enum('TODO', 'IGNORED', 'DONE', 'FAILED', 'WORK_IN_PROGRESS') | Status of execution | |
| deleted | enum('TODO', 'IGNORED', 'DONE', 'FAILED', 'WORK_IN_PROGRESS') | Status of file removal | |
| next_launch_date | datetime | Next try date | |
| current_pid | int(11) | SSH process PID | |
| number_attempt_connection_remains | int(11) | Number of remaining tries | |
| next_attempt_date_time | bigint(20) | Next attempt date (in Unix seconds) |
| Field | Type | Other | Comment |
|---|---|---|---|
| id_command_history | int(11) | auto_increment | Primary key |
| id_command_on_host | int(11) | Index linked to commands_on_host (1 command_history for many command_on_host) | |
| date | tinytext | Event date | |
| stderr | longtext | Stderr contents | |
| stdout | longtext | Stdout contents | |
| state | enum('upload_in_progress', 'upload_done', 'upload_failed', 'execution_in_progress', 'execution_done', 'execution_failed', 'delete_in_progress', 'delete_done', 'delete_failed', 'inventory_in_progress', 'inventory_failed', 'inventory_done', 'not_reachable', 'done', 'pause', 'stop', 'scheduled') | State related to the event |