So basically i've create an installer with inno setup, it works wonders and all of that. The issue is the fact that i've developed the following [Components]
Name: "LoremIpsum"; Description: "LoremIpsum"; Types: Server User; Flags: fixed
Name: "Java"; Description: "Java Runtime Enviroment"; Types: Server User; Flags: fixed
Name: "banco"; Description: "Database"; Types: Server
Name: "banco\padrao"; Description: "Standard Database"; Flags: exclusive; Types: Server
Name: "banco\manual"; Description: "Manual Database"; Flags: exclusive; Types: Server
Name: "banco\fullrestore"; Description: "Full Restore Database"; Flags: exclusive; Types: Server
Name: "banco\backupdata"; Description: "Database with Backup Data"; Flags: exclusive; Types: Server
Then, in the installer wizard when you're in the part where you choose the type of installation, there are two types, the basic one which doesn't include the "banco" part, and the complete one which is the one that i provided the code.
If you choose the complete one it looks exactly like the full one except for the name of the type of installation. Of course if you're in the basic one and mark one of the 'banco' options you'll be automatically transfered to the full installation, but i wan't it so that if you choose the full option one of the 'banco' options should be marked by defautl, i figured that it should be the father 'banco' and son 'banco/padrao' but i can't figure out how to do it.
I've already looked in the documentation looking for some sort of "Deafult" flag, which i couldn't find. I assume there should be a way to do this built in the app, i'd rather not have to do the changes with actual code since i'm not really good at pascal which is needed for it, but i wouldn't mind if the solution involved it. Mostly what i wan't is some sort of "Default" flag to appoint into one of the exclusive options. Does anyone know of such a function?
The following is the [Type] section
Name: "User"; Description: "Basic install"; Flags:
Name: "Server"; Description: "Full install" ; Flags: iscustom
#MartinPrikryl comments got me thinking, and with some time i realised that he was right, just that his solution didn't do what i want. The problem i had as a design one, i wanted thing to look more "pretty" for the end user. I then had a breaktroguh, i realised that i didn't need 2 types of instalations, just one which is custom, then i did just that.
In the end the [Types] was just
Name: "User"; Description: "Basic install"; Flags: iscustom
and that was it, the installer now looks like i want it to, not what i wanted originally but i think it's better than what i had in mind. I also removed the types from the old "server" install leaving them typeless, and removed the server type also from the fixed ones. In the end it worked out allright. Special thanks to Martin since i wouldn't have tought about it without his input.
Related
I am trying to define virtual user & group data in hiera, and then realize it only on the nodes where it's needed, by defining user lists and group lists on a per-host basis. Note: I am using the accounts module from puppet forge, and it utilizes the accounts:: name space in hiera. For example, just as a baseline for something that works, if I create this:
# snippet from hiera.yaml
hierarchy:
- name: "Users and Groups"
glob: "UsersAndGroups/*.yaml"
and
# snippet from data/UsersAndGroups/webadmins.yaml
accounts::user_list:
alice:
uid: '999'
gid: '999'
comment: 'Alice User'
shell: '/bin/bash'
bob:
uid: '998'
gid: '998'
comment: 'Bob User'
shell: '/bin/bash'
It works, but the problem is, alice and bob get created on all machines. I only want them to be created on some. I would like to instead, define this data in hiera as virtual and then use a different data structure to specify which resources should be realized on each machine, for example:
# snippet from data/UsersAndGroups/webadmins.yaml
accounts::user_list:
#alice:
uid: '999'
gid: '999'
comment: 'Alice User'
shell: '/bin/bash'
#bob:
uid: '998'
gid: '998'
comment: 'Bob User'
shell: '/bin/bash'
and then create another data structure (and corresponding puppet class, not shown), like so:
# snippet from data/users_by_host/hosts.yaml
realize_accounts::by_host:
host1.example.dom:
- alice
- bob
host2.example.dom:
- bob
host3.example.dom:
- alice
I've tried every variation I can think of to make this work, but have failed so far. The first problem is the virtual resource declaration. It doesn't like me using the # symbol. I receive the error message: found character '#' that cannot start any token.
Can anyone suggest how to abstract the user definitions from the selection of which users should be created on which machines?
I am trying to define virtual user & group data in hiera, and then
realize it only on the nodes where it's needed, by defining user lists
and group lists on a per-host basis.
Ok, that's not unreasonable.
Note: I am using the accounts
module from puppet forge, and it utilizes the accounts:: name space in
hiera.
You can use the puppetlabs/accounts module, but you cannot use its accounts class to manage users or groups if you want to stick to your plan, because it does not provide for declaring those virtually. That is a function of the Puppet code of the declarations, not (directly) of any data the class consumes.
You can still use the Accounts::User defined type, the module's various custom data types, and its custom functions. These perhaps provide enough of a value-add relative to Puppet's core User resource type to make the module worth it. You're probably looking at the core Group resource type in any case. You would need to declare Accounts::User (or User) and Group resources virtually, and then realize the wanted ones based on your per-host lists.
But there are other alternatives. You clarified in comments that your objective is to centralize master lists of user and group properties, from which you can select subsets on a per-machine basis. You can do all of that directly in Hiera with the help of Hiera's alias() interpolation function.
You would do this with a two- (at least) level hierarchy. The user and group details would go into an hierarchy level shared by all hosts, and perhaps accounts::user_defaults and accounts::group_defaults would go there too, if you use them. The accounts::user_list and accounts::group_list would go in a per-host or an otherwise more specific hierarchy level, interpolating elements from the central list. Example:
common.yaml
user:
alice:
uid: '999'
gid: '999'
comment: 'Alice User'
shell: '/bin/bash'
bob:
uid: '998'
gid: '998'
comment: 'Bob User'
shell: '/bin/bash'
host1.yaml
accounts::user_list:
alice: "%{alias('user.alice')}"
bob: "%{alias('user.bob')}"
host2.yaml
accounts::user_list:
bob: "%{alias('user.bob')}"
host3.yaml
accounts::user_list:
alice: "%{alias('user.alice')}"
So here is my final issue I have been thinking about.
This is my Tasks window:
Script:
Name: register32; Description: "Meeting Schedule Assistant (32 bit)"; GroupDescription: "{cm:FileAssociations}"; flags: unchecked exclusive;
Name: register64; Description: "Meeting Schedule Assistant (64 bit)"; GroupDescription: "{cm:FileAssociations}"; Check: IsWin64; Flags: exclusive;
I don't know if this is possible (and taking into account the customizations here). If the user is running 32 bit Windows, then we we only have one option to display. If it is just one option, can we turn it into a check box?
Does that make sense? So the two radios for when we can choose 32 / 64 and the single check for when it can oply be 32.
Update
As per the comments, I have adjusted the tasks like this:
Name: register32; Description: "Meeting Schedule Assistant (32 bit)"; GroupDescription: "{cm:FileAssociations}"; Check: IsWin64; flags: unchecked exclusive;
Name: register64; Description: "Meeting Schedule Assistant (64 bit)"; GroupDescription: "{cm:FileAssociations}"; Check: IsWin64; Flags: exclusive;
So now the two radio options are only displays on computers that can run 32 and 64 bit software. This means we must change the following code which is used when creating the registry entries:
[Code]
function GetExecutableToRegister(Param: string): string;
begin
if IsWin64 and WizardIsTaskSelected('register64') then
Result := 'MeetSchedAssist_x64.exe'
else
Result := 'MeetSchedAssist.exe';
end;
It needs changing:
if only 32 bit
return 32 bit name
else if only 64 bit
return 64 bit name
else
return the name from the task that was selected
So what changes are needed to the code for that logic?
The below xaml loosely describes a number of steps that can be re-arranged into many different configurations, and nested levels.
---
sequence:
- manual:
desc: unpack baloons
- electric:
desc: inflate each balloon
- parallel:
- manual:
desc: seal a balloon
- manual:
desc: sign a balloon
- sequence:
- manual:
desc: step 1
- manual:
desc: step 2
There are a number of *resolvers and *converters, however a good advice on which one to use when would be very helpful. How to register custom type factories and in what places?
I'm using swagger-node for REST APIs and I've found an absurd issue here.
Here's my one of GET requests:
GET: /students/{id}/{name}
(id is number)
And now I wrote another request:
GET: /students/routeInfo/{id}
But the 2nd request me following error:
Expected type is number, found type string. Which clearly means 2nd request is trying to "mask" 1st request. Which I think shouldn't be.
Am I doing something wrong or is there any other way to handle this?
In your path definitions, changeChange your 'parameters' type: number for type: string
Your path will look like this:
/students/routeInfo/{id}:
x-swagger-router-controller: yourStudentController
get:
tags:
- Student
description: description
operationId: yourOperation
parameters:
- name: id
in: path
description: description id of routeInfo
required: true
type: string
See more at https://swagger.io/docs/specification/paths-and-operations/
The exact same situation is described in the OpenAPI specification v3.0 document: section Path Templating Matching, 3rd example. It is called ambiguous matching, and "... it's up to the tooling to decide which path to use." The tool, of course, being swagger-node.
It is weird though, isn't it!
What are all the Inno Setup pages that are available by default (no custom screens), how do they look like, what is their order, what is their default setting and how do I change the that?
The Inno Setup online help gives an overview of the available Wizard pages. It lists most information you asked for. However it misses the default state, the section and the screenshot.
You can use this minimum Inno Setup script to see all dialogs yourself:
[Setup]
AppName=Stack Overflow
AppVersion=0.0.0.0
DefaultDirName={pf}\Stack Overflow
DefaultGroupName=Stack Overflow
VersionInfoVersion=0.0.0.0
OutputDir=compiled
WizardImageFile=LargeWizardImage.bmp
WizardSmallImageFile=SmallWizardLogo.bmp
DisableWelcomePage=no
LicenseFile=so.txt
Password=stack
InfoBeforeFile=info.txt
UserInfoPage=yes
[Components]
Name: "StackOverflow"; Description: "Demo component"; Types: full
Name: "TasksDemo"; Description: "Tasks component"; Types: custom
[Files]
Source: "SmallWizardLogo.bmp"; DestDir: "{app}"; DestName: "Icon"
[Icons]
Name: "{group}\DemoIcon"; Filename: "Icon"
[Tasks]
Name: desktopicon; Description: "Create a &desktop icon"; GroupDescription: "Additional icons:"; Components: TasksDemo
Here they are, the ones which are hidden by default are struck through in the top right corner.
Welcome Page
Parameter: [Setup] DisableWelcomePage
Default: yes (which means "not shown")
License Agreement
Parameter: [Setup] LicenseFile
Default: no license file (which means "not shown")
Password
Parameter: [Setup] Password
Default: no password (which means "not shown")
Information
Parameter: [Setup] InfoBeforeFile
Default: no info file (which means "not shown")
User Information
Parameter: [Setup] UserInfoPage
Default: no (which means "not shown")
Destination Location
Parameter: [Setup] DisableDirPage
Default: auto (which means "shown if not installed yet")
Component Selection
Parameter: [Components] is not empty
Default: empty (which means "not shown")
Start Menu Folder
Parameter: [Icons] is not empty and [Setup] DisableProgramGroupPage
Default: no icons (which means "not shown")
Select Tasks
Parameter: [Tasks] is not empty
Default: no tasks (which means "not shown")
Ready To Install
Parameter: [Setup] DisableReadyPage
Default: no (which means "shown")
Preparing To Install
Parameter: none, shown if files to be written are in use
Default: not in use (which means "not shown")