Sathyan Catari wrote:
>> For the silent install file, the names of the properties are, how shall I
>> say, bizarre! Are these names completely arbitrary, or are they derived
>> from something else, say from Java class names?
> OpenInstaller derives them from the <Panel Name>.<Attribute Name>.
> Yes, they are bizarre and not user friendly. I have changed them and
> updated the spec.
It looks like you forgot to update the date of the document when you
updated the spec.
>> Does the GlassFish installer depend directly on zlib? Isn't all the zlib
>> functionality available through the JDK in java.util.zip? Or
>> shouldn't zlib
>> be used by OpenInstaller instead of the GlassFish installer?
> zlib is used by native wrapper(or the launcher program on windows), that
> extracts the self-extracting archive
> and then launches the installer. zlib in this case is used to
> open/extract the zip file. It is linked statically,
> so this is a build time dependency for installer.
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?
>> 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?
>> 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.
> If the password needs to be changed, then they have to be provided in
> the statefile(i,e change encrypted
> password with plain text new password) OR regenerate the statefile with
> modified/encrypted password.
I don't understand. How do I do either of those?
How do I specify that the passwords in the answer file are in plain text
and not encrypted?
How do I regenerate the answer file using a password of my choosing to
encrypt the passwords in the answer file?
> Silent installation is never interactive. It would just read all the
> entries in the statefile and perform installation without user
> intervention.
So if I use a different password to encrypt the passwords in the file,
how does it know what password I used?