This article explains how to install Talend products using the silent or unattended installation method, which involves the creation of an options file.
The installation of Talend products is usually performed using the graphical mode installer, or on Linux, the text mode installer. There are, however, situations where an unattended or silent installation is desirable, and this document details this process.
See Installation modes of Talend Installer and Talend Studio Installer for more information about the different modes that the Talend installer can run in.
Just like the graphical installer, the silent installer can only be run on the target server where Talend is installed. There is no concept of a remote installation.
There is no option to accept or decline the license agreement—agreement can only be implicit.
All options in the options file are case sensitive: licensefile is not the same as licenseFile. Some options also have spaces in the name, which must be adhered to. For example, Nexus Host is the actual option, and is not the same as NexusHost, nexusHost, or nexushost, all of which will cause errors.
Should there be any problems in the options file, the installer will notify you on the commandline.
Talend recommends performing a graphical or text installation first, at least to the point where the installer reports it is ready to install Talend. This ensures that, if the installer checks the database settings and finds any problems, they can be corrected before installation.
Run the installer with the --help flag to get a list of the installer options:
The view in Windows:
The view in Linux:
You can find the full list of unattended mode installer options in the Talend Help Center. These options correspond to those that are normally supplied by the installer, and can be entered on the commandline when the installer is invoked. For a complicated installation, this can become unwieldy, which is why it is possible to supply the parameters as key/value pairs in a text file—the options file.
Create the options file
This section explains how to create an options file using screenshots from both a graphical and a text installation. In this example the following modules are installed:
This article shows how the options file is built. The options themselves often have a set of choices and there is always a default option, which will be used if the option is not set in the options file.
The first part of an installation is to accept the license agreement. As explained earlier, this is implicit in an unattended installation.
On the next page are the general settings:
This is specified using the prefix option, as shown below:
This example uses the Advanced install style due to the level of control offered.
This is specified using the installStyle option, the two possibilities are [easy, advanced].
This example uses the Custom installation style due to the level of control offered.
This is specified using the installType option, the three possibilities are [client, server, custom].
This is specified by the licenseFile option. The file must be local to the installer.
The next page is where you specify the required components. For this example, choose the following:
Text mode installation component specifiers:
serv – specifies to install services
In the options file the required components are specified using the enable-components and disable-components options.
Note: For text mode installations, both options must be specified. It is not enough to use one or the other. The component specifiers must be supplied as a comma separated list.
Like the graphical installer, various components cannot be explicitly selected, for example:
They will be installed implicitly when needed, but the options to configure them will be required.
Select which Tomcat to use.
The option is tomcat and the possibilities are [install8, use]. install8 is used to install an embedded Tomcat, use will use an existing Tomcat.
TAC Security User
These options set up the initial TAC user or the SSO connection.
For a text installation, the first option is: tacUserSelection, which specifies whether you want to set up an initial user, or set up an SSO connection (using Okta or SiteMinder). The choices are: [tacStdUser, tacSsoLabel]. For this example, specify tacStdUser.
To supply the user name and password, use the tacAdminUser and tacAdminPwd options.
The admin password must be supplied in clear text, so if this is seen to be a security hazard there are two options:
Do not supply a password in the file – the install will default the password to admin.
Supply an initial password and change it immediately after installation.
Set the log server details for TAC
In a text installation, whether to use a Log Server is specified with tacLogServ, which is a Boolean value and therefore can be set to 0 or 1. The default is 1, that is, to set the values and send TAC messages to the Log Server. If this is 1, the other options are: tacLogServerHost and tacLogServerPort. The default values are localhost and 5044.
Select the type of database to host the TAC Administration Database.
Specify this in a text mode installation using the tacDB option with the allowed values of [H2, MySql, Oracle, MS SQL, PostgreSQL]. For this example, use a local MySQL database.
TAC web application
If installing an embedded Tomcat, set the port using tacPort.
Set the web application name using tacWebAppName (the default is org.talend.administrator)
Specify whether or not to install Nexus using tacInstallNexus (values are 0 or 1). The default is 1, that is, to install.
Specify whether or not to set up email notifications using tacSetupEmailNotification (values are false or true). The default is false.
TAC database configuration
This set of options will vary according to which type of database is being used as will the default values. The options are:
You can also specify the location of the database driver JAR file using tacDBDriver. If this is not set, you will need to upload the driver JAR file using the DBConfig page in the GUI once the TAC has started.
If Nexus is to be installed with a text installation, specify the configuration with the following options:
Nexus Host (yes, with the space) The default is 0.0.0.0.
nexusPort The default is 8081.
Log Cluster Name
Talend recommends that you always change this value, and the best way is to reflect the environment, for example, talend-dev-central. For a text installation, the option is logservClusterName.
Job Server Settings
The associated options are:
jobserverCommandPort The default is 8000.
jobserverFilePort The default is 8001.
jobserverMaxCacheDuration The default is 90.
jobserverMonitorPort The default is 8888.
Process messaging port (yes with the spaces) The default is 8555.
Set up the services
You can specify the serv component within enable-components to set up all modules as services. It is also possible to specify individual services, should it be necessary that not all components be set up as services. The serv option must still be specified in enable-components, but there are extra options to enable the individual components to be set up as services, for example:
Running the installer
Once the options file is created, run the installer with the --optionfile and --unattendedmodeui parameters explicitly set to none, and the --mode parameter explicitly set to unattended.
... View more
What I haven't yet had time to add to this article, is what happens when a library is added using tLibraryLoad or the Modules view. As far as I can tell, it ends up in the <Nexus>\talend-custom-lib-snapshot\org\talend\libraries repository which appears not to be shared to other Studios. As I said I am still researching this.
... View more
I have never created a custom component so I don't know for sure but I don't think so. Quote from my document "
When the Studio starts for the first time it sets up its local Maven repository. This is where it stores libraries delivered by Eclipse plugins which are not transferred to Nexus with the custom libraries.
". I think this refers to the components.
... View more
This document describes the process for working with the third-party libraries (custom libraries) used within Talend.
Custom libraries are needed for Talend components to work properly. These libraries are not delivered by Talend for contractual and licensing reasons, so they must be downloaded by the Studio.
The process is as follows:
Configure TAC with the location of Nexus as an artifact repository and as the custom libraries repository (not localhost).
Set up a user in TAC with appropriate privileges and access credentials to the source repository (SVN/GIT).
Set up a project in TAC, and assign the correct privileges to the user.
Log in to Studio as a user.
[Optional] Publish from Studio – set up artifact repository details in Preferences.
This document also describes what you can do if Talend is installed in an environment without an internet connection.
Among other things, TAC needs the following configuration:
Note: Software Update is not part of the custom library process. It is the mechanism used to download patches and updates.
So you have a configuration for Nexus, the artifact repository, but this configuration is only the place for TAC to look for artifacts for deployment in the Job and ESB conductors. Studio has a separate configuration for the artifact repository to which it publishes, as detailed later.
Set up a user
The user needs to be set up with the appropriate credentials for the source code system.
Set up a project in TAC
Set up a project as shown below:
Assign rights to the appropriate user(s)
Assign rights to users as follows:
Before Studio starts for the first time, the Maven .m2 repository has not been set up:
When Studio starts for the first time, it sets up its local Maven repository. This is where it stores libraries delivered by Eclipse plugins that are not transferred to Nexus with the custom libraries.
At this point, you can see that the custom libraries directory – stored in org.talend.libraries – is still (almost) empty:
and the custom libraries in Nexus are also still empty:
Log in to Studio
This is what happens behind the scenes:
Here you can see why it is a bad idea to leave hostnames as localhost. When the Nexus location is passed to Studio, it would get localhost as the host name, and because Nexus is not local to Studio, Studio is unable to find Nexus to interact with it. As soon as the user has logged on to Studio, you see some libraries appearing in Nexus, but not the third-party libraries:
Now Studio will request that the custom libraries are downloaded, which need to have the licenses accepted. These are the custom libraries:
Clicking Finish starts the download and you must now accept the licenses, which is the crucial part:
Note: the licenses will need to be explicitly accepted whether or not Studio downloads the libraries from the internet or internally from Nexus. Then you see the libraries downloading into the Studio’s Maven repository:
And you see them appearing in the Nexus custom libraries repository:
A note about the command line
Even though the command line is running, the custom libraries do not appear automatically in its Maven repository.
It will only bring these across from Nexus when it needs to build them into an artifact, such as when a Publisher or Job Conductor task is run. As mentioned earlier, try to avoid using these methods to publish or build artifacts and as much as possible, publish artifacts to Nexus and deploy those.
Publish from Studio
Before publishing from Studio, you must configure the Nexus artifact repository in the Preferences.
Installing in an environment without an internet connection
Many companies do not allow software such as Talend to have access to the internet. These are most typically financial institutions, but any company or organization handling sensitive data will probably impose internet access restrictions. This obviously poses a problem for a mechanism that relies on access to the internet to access third-party files. How can you solve this problem?
There are two main ways:
Install at least one Studio into an internet-connected environment.
Upload a backup of the Nexus custom libraries repository.
Install Studio into an internet-connected environment
As you have already seen, once the third-party libraries are uploaded into Nexus, there is no further requirement for access to the internet, even for Studio. So the easiest solution is to install one Studio on a machine and configure it with access to TAC and the Nexus installation. This will enable third-party libraries to be downloaded into Nexus and from there, the libraries are accessible from any Studio that connects to TAC, regardless of whether or not that Studio has internet access.
Upload a backup of the custom libraries
This involves having an “external” installation with access to the internet – often your own laptop - where the third-party libraries have already been downloaded into Nexus. Once the libraries are loaded into Nexus in the “external” installation, a backup of the libraries is made and then restored to the unconnected installation.
The process to make a backup
By default, Nexus is installed with the TAC, in the TAC directory:
Within that, navigate to the storage for the Talend libraries in the custom libs repository:
Make a Zip backup of the entire directory.
The process to “restore” the backup to the target installation
Log in to the Nexus in the target installation as an admin user: the default username is admin, the default password is Talend123.
Click the Repositories menu item on the left:
Right-click the talend-custom-libs-release repository and select Put out of service:
Navigate to the storage for the Talend libraries in the custom libs repository, and unzip the backed up libraries archive:
Right-click the talend-custom-libs-release repository and select Put in service:
Right-click the talend-custom-libs-release repository, select Rebuild Metadata, then right-click and select Repair Index.
The libraries are now available for any Studio that logs in to the TAC.
... View more
Hi Folks, Is there any way to set the SAP RFC Server as a windows service? My customer installed 6.3 with SAP RFC Server and services but no windows service was set up for the SAP RFC Server. Is this normal? If so, how can you set up the windows service? Thanks in advance, Rich.
... View more
Hello kambham There is a component called tContextLoad which allows you to set context variables dynamically. It enable syou to read values from e.g. a file or DB and load them into the context. The schema which you need to give to tContextLoad is simply 2 strings: "key" and "value". It also allows you to add new variables. There is also the tContextDump component which allows you to dump the context for review. Hope this helps.
... View more