Sathyan Catari wrote:
>> Not questioning the dependency, but... Isn't it OpenInstaller that
>> injects zlib into the installer that it builds? Or is it code that's
>> specific to the GlassFish installer that knows about zlib?
> The code that is specific to GlassFish installer depends on zlib.
> OpenInstaller does not need/depend on zlib.
So the installer created by OpenInstaller doesn't normally do any
compression? Weird...
>>>> In asadmin create-service and delete-service, what are the required
>>>> args
>>>> that you're depending on these commands supporting?
>>> We do not depend on anything specific to installer for these commands.
>>
>> So if those commands supported no options at all, the installer would
>> still work? The installer passes no options when calling these commands?
>>
> It is not clear on how this command will be supported in admin-cli. If
> the command can work without specifying
> any of the arguments(which will not be the case), then installer will
> invoke the command in the same way.
> What I meant to write was that there is no special requirement for
> option/args imposed on these commands by
> the installer.
I still don't understand.
"No special requirement" to me means you don't pass any options at all,
because if you *did* pass an option, you would have a "special requirement"
for that option.
>>>> I don't understand 4.11, bullet 4. If the silent file has encrypted
>>>> passwords,
>>>> how do I encrypt a password to store in that file? Won't it need to
>>>> be both
>>>> encrypted and base64 encoded? How is the decryption password
>>>> supplied during
>>>> the silent install? I didn't see a command line argument to supply
>>>> it. Does
>>>> that mean that silent installs always have to be interactive so you
>>>> can read
>>>> the password from the terminal after prompting?
>>> The installer when run with appropriate flags(-n <filename>)
>>> generates the answer-file with encrypted password.
>>> Users can reuse the generated answer-file to perform multiple
>>> installation, without changing the password(this is the
>>> most common use case).
>>
>> So the installer has a well-known and fixed password baked into it,
>> and it uses that password to encrypt the passwords in the answer file?
>> That's no security at all.
> Sorry I should have been more clearer when explaining this. Please
> consider the following use cases.
>
>
> Use Case 1: User would like to generate the answer-file to be used for
> subsequent non-interactive installations.
>
> Solution: Run the installer with -n <answer-file-to-be-generated>.
> Installer will walk the user through
> various screens where user provide all of the needed input. Upon
> capturing the information, the installer
> will not actually perform the binary installation/configuration, but
> would generate the answer-file and
> quit.
> ------------------------------------------------------------------------------------------------------------------------
>
> Use Case 2: User would like to perform a non-interactive installation
> using the answer-file generated in use case 1,
> without changing the password populated in the answer-file(created out
> of use case 1).
>
> Solution: Run the installer with -a
> <answer-file-generated-in-use-case-1> -s.
> ------------------------------------------------------------------------------------------------------------------------
>
> Use Case 3: User would like to change the password(provide clear-text
> values) in the answer-file(created out of use case 1),
> and perform the non-interactive installation.
>
> Solution: Edit the answer-file, change the following entries/values.
> Change "GlassFish.administration.ADMIN_PASSWORD_ENCRYPTED=TRUE" to
> "GlassFish.administration.ADMIN_PASSWORD_ENCRYPTED=FALSE"
> and
> provide clear-text password for the entry
> "GlassFish.administration.ADMIN_PASSWORD=".
> Run the installer with -a <answer-file-generated-in-use-case-1> -s.
>
> BTW, the earlier version of the spec was missing this key
> GlassFish.administration.ADMIN_PASSWORD_ENCRYPTED.
> I just updated the spec to include this.
>
> Thanks again for catching it.
Uh, ya, that makes a big difference, doesn't it? :-)
> ------------------------------------------------------------------------------------------------------------------------
>
> Use Case 4: User would like to change the password in the
> answer-file(created out of use case 1), provide
> encrypted value for password and perform the non-interactive installation.
>
> Solution: Currently not supported.
> Reason: This is not a common use-case and this feature was never
> requested in the earlier versions of the installer also.
> Such a key(ADMIN_PASSWORD_ENCRYPTED) has been in existent since
> Application server 7.0 days.
>
> ------------------------------------------------------------------------------------------------------------------------
In the case where the password is encrypted, I still don't understand
what password (or should I say "secret key") you're using to encrypt
the data. If it's a fixed password wired into the code, don't even
waste your time doing that because it provides no security at all.