During installation process user has ability to install number of some service instances (Service1- ServiceN). All the differences between these services - content of configuration files(actually there is only one executable in /Product_Root/run wich is called with different command-line params).Configuration files situated in ProductRoot/ServiceX/conf.
Folders structure looks like :
/Product_Root
----/bin
----/doc
----/Service1
---------/conf
----/Service2
---------/conf
...
----/ServiceN
---------/conf
In ProductRoot/ServiceX/conf is situated, for example, service.properties file with these contents:
#...
ServiceRoot = <%ROOT_DIRECTORY%>
ListenPort = <%PORT%>
#...
Also in /Product_Root/bin scripts for each service startup should be present:
For example :
/Product_Root/bin/Service1.run.cmd
/Product_Root/bin/Service2.run.cmd
...
/Product_Root/bin/ServiceN.run.cmd
...
Script file structure is:
service.exe ../<%SERVICE_NAME%>/conf/service.properties
All values (like <%SERVICE_NAME%>,<%PORT%> etc.) are set by user during setup process for each Service.
Amount of services is also set by user and may vary between 1 (by default) and 20-30.
In case of single service - there is no problem.
Files being copied, directories created using
[Files]
Source: {#FilesPath}\bin\*.*; DestDir: {app}\{#FileLocationPrefix}\bin; Flags: ignoreversion restartreplace
Source: {#АilesPath}\conf\*.*; DestDir: {app}\{#FileLocationPrefix}\{code:GetServiceName}\conf; Flags: ignoreversion recursesubdirs createallsubdirs restartreplace;
[Dirs]
Name: {app}\{#FileLocationPrefix}{code:GetServiceName}\conf
After in ssPostInstall step wildcards replace performed in copied files.
Question.
is it possible using Inno Setup + ISTool to do the same in case of number of services?
E.g. something like that :
[Files]
#for (i = 0; i < ServiceCount(); ++i)
Source: {#АilesPath}\conf\*.*; DestDir: {app}\{#FileLocationPrefix}\{code:GetServiceName| i}\conf; Flags: ignoreversion recursesubdirs createallsubdirs
where i — is actually configuration number.
I.e. is it possible to use information received from user during installation process in [File], [Dirs] etc. sections for multiple copying of the same files in different directories?
For copying single file in number of files with different names set by user during install process?
Or I just going in the wrong direction?
So, currently I've done this in such way. Comments are welcome.
For creating and copying all files:
#define MaxFEInstances 20
...
#sub CreateConf
Source: {#FilesPath}\conf\*.*; DestDir: {app}\{#FileLocationPrefix}{code:GetServiceName|{#counter}}\conf; Flags: ignoreversion recursesubdirs createallsubdirs restartreplace; Check: InstanceSetupRequired({#counter}); Components: main
#endsub
#for {counter = 0; counter < MaxInstances; ++counter} CreateConf
enter code here
...
function InstanceSetupRequired(InstanceNum: Integer): Boolean;
begin
Result := InstanceNum < Instances;
end;
For separate files it looks pretty same.
Related
Currently my batch file is in [Run] section. I need my batch file to execute before the [Files] section. Is there a way to do this in Inno Setup? Currently the [Run] section always execute after [Files] section.
[Run]
Filename: "C:\Users\Scripts\Install\Install.bat"; Parameters: {code:GetDatabaseName}
[Files]
Source: "C:\Users\MyApp\*"; DestDir: "\\MyServer\MyApp"; Flags: recursesubdirs createallsubdirs
If it needs to be done at the beginning of the setup, use Exec() in the PrepareToInstall() or CurStepChanged(ssInstall) event functions.
These are both after the user has said "go ahead, install" but before anything else.
PrepareToInstall() also allows you to cancel the install with a nice warning.
If the file needs to be extracted from the setup first, then you can preceed it with ExtractTemporaryFile()
Continuing Deanna's great answer, code example:
[code]
function PrepareToInstall(var NeedsRestart: Boolean): String;
var
ResultCode: integer;
begin
Exec(ExpandConstant('{app}\serviceDeployment\unInstallService.bat'), '', '', SW_SHOW, ewWaitUntilTerminated, ResultCode)
end;
this code always returns an empty string, which tells the setup to continue.
In case you want to stop setup (in some error cases) you need to return a non empty string and it will be displayed to the user (and setup will be stopped).
In order to return an error string add this line in PrepareToInstall's:
Result := 'Your Error Description';
You can use the InitializeSetup event + some pascal scripting.
See; How to run a file before setup with Inno Setup
Not mentioned in that example; to get the file from the installer you would use ExtractTemporaryFile('your.bat') then Exec(ExpandConstant('{tmp}\your.bat ... to run it.
In an Inno Setup script, I need to copy a number of files to multiple user-defined locations. In order to do this, I'd like to iterate over the sources in the [Files] section, and FileCopy() them multiple times depending on the user-defined settings and properties of the files.
Is it possible to access the sources in the [Files] section using a script?
No, you cannot iterate the [Files] section.
But you can use preprocessor to generate both the [Files] section and the Pascal Script from one list of files.
You are not very specific about your goals, so I'm showing only a rough concept.
; Define array of files to work with
#dim Files[2]
#define Files[0] "MyProg.exe"
#define Files[1] "MyProg.chm"
#define I
; Iterate the file array, generating one entry in Run section for each file
[Files]
#sub FileEntry
Source: "{#Files[I]}"; DestDir: "{app}"
#endsub
#for {I = 0; I < DimOf(Files); I++} FileEntry
[Code]
procedure CopyFiles;
begin
// Iterate the file array, generating two FileCopy calls for each file
#sub FileCopy
FileCopy('{#Files[I]}', 'd:\destination1\{#Files[I]}', True);
FileCopy('{#Files[I]}', 'd:\destination2\{#Files[I]}', True);
#endsub
#for {I = 0; I < DimOf(Files); I++} FileCopy
end;
// Just for debugging purposes, outputs the preprocessed script
// so you can verify if the code generation went right
#expr SaveToFile(AddBackslash(SourcePath) + "Preprocessed.iss")
If you compile the script, you can see in the preprocessed file Preprocessed.iss that it generates this:
[Files]
Source: "MyProg.exe"; DestDir: "{app}"
Source: "MyProg.chm"; DestDir: "{app}"
[Code]
procedure CopyFiles;
begin
FileCopy('MyProg.exe', 'd:\destination1\MyProg.exe', True);
FileCopy('MyProg.exe', 'd:\destination2\MyProg.exe', True);
FileCopy('MyProg.chm', 'd:\destination1\MyProg.chm', True);
FileCopy('MyProg.chm', 'd:\destination2\MyProg.chm', True);
end;
Actually you may not need to use the FileCopy for this specific purpose. You can just have the preprocessor generate multiple [Files] section entries for the same file:
; Iterate the file array, generating one entry in Run section for each file
[Files]
#sub FileEntry
Source: "{#Files[I]}"; DestDir: "{app}"
Source: "{#Files[I]}"; DestDir: "d:\destination1"
Source: "{#Files[I]}"; DestDir: "d:\destination2"
#endsub
Generates:
[Files]
Source: "MyProg.exe"; DestDir: "{app}"
Source: "MyProg.exe"; DestDir: "d:\destination1"
Source: "MyProg.exe"; DestDir: "d:\destination2"
Source: "MyProg.chm"; DestDir: "{app}"
Source: "MyProg.chm"; DestDir: "d:\destination1"
Source: "MyProg.chm"; DestDir: "d:\destination2"
Inno Setup will identify identical source files and will pack them only once.
You can use Check parameter to make some entries conditional.
See also this question, which is actually similar:
Access file list via script in InnoSetup
I have a source tree structure like -
/src
/moduleA
/moduleB
/common
where moduleA and moduleB need packaged separately but share the common code.
Is it possible to create 2 separate binary packages using dpkg-buildpackage?
Thanks!
It is possible. In order to do it, you should modify the control file.
When you use dh_make -s, you have something like :
Source: yourpackage
Section: unknown
Priority: optional
Maintainer: toto <toto#unknown>
Build-Depends: debhelper (>= 8.0.0), autotools-dev
Standards-Version: 3.9.4
Homepage: <insert the upstream URL, if relevant>
#Vcs-Git: git://git.debian.org/collab-maint/libsnow.git
#Vcs-Browser: http://git.debian.org/?p=collab-maint/libsnow.git;a=summary
Package: yourpackage
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: <insert up to 60 chars description>
<insert long description, indented with spaces>
All you have to do is to add a paragraph like that :
Package: yourpackagebis
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: <insert up to 60 chars description>
<insert long description, indented with spaces>
(I should warn you, you can only use lowercase characters for the package's name). Once you've done that, you have to specify which file will go where. You have to create four new files : yourpackage.dirs, yourpackage.install, yourpackagebis.dirs, and yourpackagebis.install. In yourpackage.dirs, you have to specify what are the directories you need to create (one per line). In yourpackage.install, you have to tell dpkg-buildpackage what files should be put in the package yourpackage, and where. It must be in the following format (one per line):
moduleA/foo usr/bin
(assuming your makefile is in src/. It can be something else than usr/bin).
yourpackagebis.dirs and yourpackagebis.install works the same way for the package yourpackagebis.
When getting list of views in IBM Rational ClearTeam Explorer, it reports the error message"CRMAP7007: Error reading local file area registry." So I cannot retrieve my views list after that message shows. Does any one have idea about how to resolve this problem?
Many Thanks for your kind help!
Problem solved. Delete the .ccase_wvreg_lockfile from C:\Users\username\
Note: the thread "CRMAP7007 Error reading local file area registry" gives a bit more details:
It is interesting because it reminds you of the debug options that exist with CTE:
To get a better idea of why the error is thrown you can look in the workspace log file.
This file is by default <user home>\.Rational\workspace\.metadata\.log
You can also launch CTE in debug mode by creating a .options file in the directory that he executable is in. The content of that file should be as below:
# -------------- CCRC Tracing Options File -----------------
# All line preceeded with a # sign are not evaluated.
# ------Server Tracing-------
# subsystems available:
# CCRC - Core general tracing related to CCRC server operations
# CCWEB- CCWeb(CGI operations)
# SUM - UCM specific
com.ibm.rational.clearcase/server_trace=true
com.ibm.rational.clearcase/server_trace/subsys=CCRC:CCWEB:SUM
com.ibm.rational.clearcase/server_trace/level=4
# ------Client Only Tracing-------
# Parameters available:
# HTTP_CLIENT - Tracing specific to HTTP communications
# CTRC_UI - Tracing specific to the user interface
# CTRC_CORE - For client core tracing
com.ibm.rational.clearcase/client_trace=true
com.ibm.rational.clearcase/client_trace/params=HTTP_CLIENT:4 CTRC_UI:3 CTRC_CORE:3
com.ibm.rational.clearcase/client_trace/output=file
com.ibm.rational.clearcase/client_trace/file_name=C:/temp/cte_debug.out
# -------------- END CCRC Tracing Options File -----------------
With that file created, launch CTE from the command line using the -debug option:
C:\Program Files\IBM\RationalSDLC\ClearCase\RemoteClient>ctexplorer.exe -debug
We have two machines (under discussion) running ClearCase - different versions of ClearCase. Otherwise, they are about as identical in setup as can be - same Linux x86/64 kernel etc.
On one machine, SUID root programs in the view work as SUID root programs.
On the other machine, SUID root programs in the view do not work with SUID privileges, leading to unexpected results.
The only difference we've spotted so far is:
Working view: CC 7.0.1
Non-working view: CC 7.1.1.1
I can give the full output of cleartool -version if it matters, but I suspect it won't. These are the first versions listed.
Questions
Is this a known difference between the versions of ClearCase, or is it a configuration item, or something else?
Is it possible to configure the newer version of ClearCase (MVFS) to allow SUID root programs to run 'properly'?
If it is configurable, how do we change the configuration make the new version allow SUID programs?
We have a myriad machines running ClearCase, on a lot of different platforms. There have been rumours that on some machines, our SUID software has to be run 'out of view' to work. Now someone was reporting a bug - and it has taken most of the day to narrow down the differences. The issue addressed in the question seems a plausible explanation. If it is something else, so be it. I still need the hair I lost today back again!
Extra Information
All views are dynamic, not snapshot.
This is the output of cleartool lsview -l -full -pro -cview on the machine where SUID programs do work, running ClearCase 7.0.1:
Tag: idsdb00222108.jleffler.toru
Global path: /net/toru/work4/atria/idsdb00222108.jleffler.toru.vws
Server host: toru
Region: lenexa
Active: YES
View tag uuid:6dac5149.2d7511e0.8c62.00:14:5e:69:25:d0
View on host: toru
View server access path: /work4/atria/idsdb00222108.jleffler.toru.vws
View uuid: 6dac5149.2d7511e0.8c62.00:14:5e:69:25:d0
View owner: lenexa.pd/jleffler
Created 2011-01-31T11:58:11-08:00 by jleffler.rd#toru
Last modified 2011-02-26T22:32:49-08:00 by jleffler.rd#toru.lenexa.ibm.com
Last accessed 2011-02-26T22:44:55-08:00 by jleffler.rd#toru.lenexa.ibm.com
Last read of private data 2011-02-26T22:44:55-08:00 by jleffler.rd#toru.lenexa.ibm.com
Last config spec update 2011-02-26T01:10:36-08:00 by jleffler.rd#toru.lenexa.ibm.com
Last view private object update 2011-02-26T22:32:49-08:00 by jleffler.rd#toru.lenexa.ibm.com
Text mode: unix
Properties: dynamic readwrite shareable_dos
Owner: lenexa.pd/jleffler : rwx (all)
Group: lenexa.pd/rd : rwx (all)
Other: : rwx (all)
Additional groups: lenexa.pd/RAND lenexa.pd/ccusers lenexa.pd/ccids lenexa.pd/ccos
This is the output on the machine where SUID programs do not 'work', running ClearCase 7.1.1.1:
Tag: new.jleffler.zeetes
Global path: /tmp/jl/new.jleffler.zeetes.vws
Server host: zeetes
Region: lenexa
Active: YES
View tag uuid:f62b7c80.414111e0.9cec.00:14:5e:de:1b:44
View on host: zeetes
View server access path: /tmp/jl/new.jleffler.zeetes.vws
View uuid: f62b7c80.414111e0.9cec.00:14:5e:de:1b:44
View owner: lenexa.pd/informix
Created 2011-02-25T18:40:11-06:00 by informix.informix#zeetes
Last modified 2011-02-25T18:49:56-06:00 by informix.informix#zeetes
Last accessed 2011-02-25T18:50:31-06:00 by informix.informix#zeetes
Last read of private data 2011-02-25T18:50:31-06:00 by informix.informix#zeetes
Last config spec update 2011-02-25T18:49:37-06:00 by informix.informix#zeetes
Last view private object update 2011-02-25T18:49:56-06:00 by informix.informix#zeetes
Text mode: unix
Properties: dynamic readwrite shareable_dos
Owner: lenexa.pd/informix : rwx (all)
Group: lenexa.pd/informix : r-x (read)
Other: : r-x (read)
Additional groups: lenexa.pd/RAND lenexa.pd/ccids lenexa.pd/ccos
Detecting that SUID programs are not working
The problem is not that there is an error message from the operating system about running the SUID program. The problem is that even though the program appears to be setuid root, when run, the program is not actually setuid:
Zeetes IX: ls -l asroot
-r-sr-xr-x 1 root informix 24486 Feb 25 18:49 asroot
Zeetes IX: ./asroot id
asroot: not installed SUID root
Zeetes IX:
This is the output from asroot when it is not installed with SUID root privileges. On the other machine:
Toru JL: ls -l asroot
-r-sr-xr-x 1 root informix 26297 2011-02-27 00:11 asroot
Toru JL: ./asroot id
uid=0(root) gid=1240(rd) groups=1240(rd),1360(RAND),8714(ccusers),8803(ccids),8841(ccos)
Toru JL:
This is more or less the output I'd expect if the program is installed with SUID root privileges.
Mount information
The two main VOBs are tristarp and tristarm. On the machine where SUID is OK (wrapping done manually to avoid scrollbars):
aether:/vobs/tristarm.vbs on /vobs/tristarm.vbs type nfs \
(rw,hard,intr,bg,addr=9.25.149.151)
charon:/vobs/tristarp.vbs on /vobs/tristarp.vbs type nfs \
(rw,hard,intr,bg,addr=9.25.149.147)
charon:/vobs/tristarp.vbs on /vobs/tristarp type mvfs \
(uuid=684ef023.2dd111d0.b696.08:00:09:b1:a4:c5)
aether:/vobs/tristarm.vbs on /vobs/tristarm type mvfs \
(uuid=b74900ef.814511cf.afee.08:00:09:b1:54:d5)
On the machine where SUID is not OK:
aether:/vobs/tristarm.vbs on /vobs/tristarm type mvfs \
(uuid=b74900ef.814511cf.afee.08:00:09:b1:54:d5,nosuid)
aether:/vobs/tristarm.vbs on /vobs/tristarm.vbs type nfs \
(rw,hard,intr,bg,addr=9.25.149.151)
charon:/vobs/tristarp.vbs on /vobs/tristarp.vbs type nfs \
(rw,hard,intr,bg,addr=9.25.149.147)
charon:/vobs/tristarp.vbs on /vobs/tristarp type mvfs \
(uuid=684ef023.2dd111d0.b696.08:00:09:b1:a4:c5)
And there's the miscreant! (And I thought I'd looked at mount information. Evidently. I'd not looked accurately enough, or only on one machine - the working one - or something.) It is odd that only one of these two VOBs is mounted with nosuid; very odd.
We have an answer why!
Thanks, VonC.
Explorations
There is provision in the scripts /etc/init.d/clearcase and /etc/clearcase for the scripts and programs under /opt/rational/clearcase to use a file /var/adm/rational/clearcase/suid_mounts_allowed to control whether SUID is allowed or not; it exists on both machines, as an empty file with permissions root:root:000. But there may be some other difference that is crucial lurking here - I have asked the resident ClearCase Guru about this. However, it looks as though the difference is more likely in the configuration on the two machines than it is some version-specific change in functionality. Both versions superficially support the nosuid option, even though neither is self-evidently invoking that option - except that the 7.1.1.1 version is managing to invoke it where the 7.0.1 version is not.
It would be interesting to know:
if both kind of views are snapshots or dynamic views. I suppose dynamic, with an issue related to MVFS.
what a 'cleartool lsview -l -full -pro -cview' returns in both case (when executed within each views, one where SUID works, one where it doesn't)
if the local path within each view is the same when trying the SUID bit (local path being the path within the view as in </path/toView>/vobs/MyVob/.../path/to/a/directory)
And mainly, do you have an exact error message, like in this thread:
We see that VOBs are mounted with different options on Linux and SunOS, especially, Linux adds a "nosuid" mount option, while on SunOS "setuid" is added.
This causes us trouble during distributed builds on the Linux machines, because the remote machine(s) gets an "Operation not permitted" error when trying to execute a suid root binary from one of the VOBs
See the cleartool mount options:
UNIX and Linux: nodev, nosuid, suid.
See also "Setting the sticky bit using the cleartool protect command"
Use the following syntax to properly set the "sticky bit" using the cleartool protect command:
cleartool protect -chmod u=rxs <file>