## Unattended Installation

Question:

How do I get the installer for Community Edition to run in a silent, unattended mode?

Answer:

See the Installation guide for the product in question.

Documentation on unattended installation is limited in scope because the functionality is limited. There are many outcomes which might be desired that the command line for the exe installer cannot support.

Unattended installation under the Community Edition license is Strongly Discouraged.
A requirement for unattended installations is associated with use cases that meet the definition of Production Use or OEM Redistribution. Commercial entities must have a senior license for Production Use. All cases of Redistribution must have a senior license. Without the opportunity to review the terms of the Community Edition license, an end-user will be liable for complying with the license without being aware of the terms.

For ActivePerl, Business Edition or Enterprise Edition versions can provide an MSI style installer with more extensive support for unattended installations.

## Common OS X problems

Question:

ActivePerl isn't working on OS X. Why?

Answer:

-Are you still getting the system version of Perl instead of ActivePerl?
You likely have not finished the installation. Read the Configuration step in the Installation Guide, which explains how to set $PATH so that ActivePerl is found ahead of the system version. http://docs.activestate.com/activeperl/5.16/install.html#os%20x%20config... If you don't put ActivePerl on$PATH, then you must access ActivePerl and ppm using the full directory path, /usr/local/ActivePerl-5.16/bin/perl (or equivalent for other releases).

-I set $PATH yesterday, and I'm sure I had ActivePerl working, but today it's not working. Changes to$PATH are volatile. You have to make the changes permanent by setting up your $PATH in your .profile shell configuration file. -I can't do that. I don't have a .profile in my home directory. No you don't. Apple designed OS X to use GUI interfaces, and they didn't think a config file for the command line shell would be necessary. You have to manually replicate what every other flavor of Unix does; copy /etc/profile to .profile in your home directory, and make changes to your personal copy. -I did that, but it still isn't working. You have to restart your shell before changes to .profile get read. -Ok, I did all that, and Perl is working every time, but PPM won't add or remove modules. You are a normal user. ActivePerl is installed into a directory which normal users can't write. PPM needs to be run through "sudo ppm" to give it the elevated privilege to manage modules. -Huh? I wanted to replace the Apple Perl with ActivePerl. This process doesn't do that. How can I force ActivePerl to replace the Apple version? Don't. Some of your system tools, and quite a few other vendor products expect to find a specific version of Perl in a specific place on a specific version of OS X. Replacing the Apple Perl will break things, and it is difficult to put things back without re-installing your operating system. Apple Perl will co-exist happily with ActivePerl if the defaults in the ActivePerl installer are used. Both versions will still be usable if you supply full paths to the command. -Can't I just edit the system default /etc/profile to put ActivePerl on$PATH first? Won't that make it the default Perl?
Yes, it will, and so will creating symbolic links in system directories that are already high on the \$PATH. Either of these approaches might still break third party software and system tools if they don't use hard-coded paths to the Apple Perl. On the positive side, making ActivePerl the default Perl in one of these ways is very simple to back out if for some reason things go pear shaped.

-I did everything above, but all I get is weird crashes when I run ActivePerl.
Do you have PERL5LIB set to point at the Apple Perl? Using PERL5LIB can force Perl to load libraries which contain incompatible binaries.

-I've got PPM working, but the module I want isn't available. I tried to build it locally from the CPAN source code, but I just can't seem to set the right compiler options.
ActivePerl binaries are multi-platform. Some releases were PPC/x86, and newer releases are x86/x86_64. When you compile a module locally, the compiler will only build a single architecture binary, and no matter which platform you are on, it won't match the dual architecture of the ActivePerl binaries unless you use the Apple SDK to convert what you build to match. Using the Apple SDK is a topic outside the scope of ActivePerl support.

## Getting started with Stackato MicroCloud

Question:

What do I need to run Stackato?

Answer:

Applies to: Stackato 1.x

You need a server and a client.

On the server side, the Stackato VM is a stand-alone “micro-cloud” virtual machine with all the components necessary for running a test environment in one instance. Server VMs are available for VirtualBox, VMWare, VSphere, and KVM. Some other hypervisors are also capable of using VMs supplied in these formats.

The Stackato Client will run on Windows, Mac OS X or Linux. You can download a stand-alone executable, or if you have ActivePython installed, you can install it with pypm. There’s no Ruby dependency as there is with vmc. Many of the functions available from the command line client are also available in the Stackato Console.

## "Error reading from file" during installation

Question:

When I try to run the MSI installer, I get a dialog with the message:

Error reading from file C:\Path\to\Some-installer.msi. Verify that the file exists and that you can access it.

This prevents me from installing the software. What's wrong?

Answer:

The Windows "System" group needs to have access to the file. This problem often occurs when the msi file is saved to a folder without System group permissions and with "Inherit from parent" set.

To solve this, grant the System group Read & Execute permissions for the installer.

See also:

http://devsac.blogspot.com/2009/02/error-reading-from-file-msi-verify-th...

## Install error - "ActivePerl is not supported by my processor type"

Question:

When I try to install ActivePerl on Windows, it says it is not supported by my processor type. My system meets the ActiveState requirements. Why is it not recognized?

Answer:

This message isn't an ActiveState error message. It comes from within the Microsoft Installation tool, and it's rather misleading. The processor isn't in fact the problem.

What the message really indicates is that you are attempting to install a 64-bit binary on a 32-bit version of Windows. This won't work. A 64-bit processor will run either 32-bit or 64-bit Windows, but MSI installers for 64-bit software will only install on 64-bit Windows.

Most users solve this by using the 32-bit x86 ActivePerl installer with a 32-bit Windows, however in cases where a full 64-bit x86_64 ActivePerl is necessary there is no alternative except to first upgrade to a 64-bit version of Windows.

## I can't install PerlDevKit 7 or 8.

Question:

Case #1 - The PerlNET component is disabled in the installer. PDK installs but I don't get PerlNET.

Case #2 - The PerlDevKit gets past creating shortcuts, but not much further, then it fails silently and starts rolling back.

Case #3 - I keep receiving an error message that says "Error writing to file: Perl510RT.dll. Verify that you have access to that directory." (The exact filename can be one of several Perl5*.dll files)

Answer:

PerlNET in PerlDevKit 7.2+ requires .NET 1.1 and .NET 2.0, with SP1 for both being strongly recommended.

In Case #1 there is no .NET installed. PDK detects this and automatically disables PerlNET.
In Case #2 only .NET 1.0 is installed.
In Case #3 only .NET 1.1 is installed.

You have two options. You can either install .NET 1.1 and .NET 2.0, then proceed with a full installation of PerlDevKit, or you can disable the PerlNET component of PerlDevKit during the PDK installation process (as is done automatically in Case #1). Either should allow you to complete the install.

## Can't create license file on OS X

Question:

Why do I get the message "Can't create '/Users/myusername/Library/Application Support/ActiveState/ActiveState.lic"? What can I do about it?

Answer:

Occasionally when you are installing a new ActiveState license or starting a trial or beta product that installs a temporary license you will get the following message:

Can't create '/Users/myusername/Library/Application Support/ActiveState/ActiveState.lic

This is due to the directory the license is being installed in being owned by another user or not having the appropriate permissions. The easiest way to fix this is from the Terminal, by typing the following two commands:

sudo chown -R myusername /Users/myusername/Library/Application\ Support/ActiveState
chmod 0755 /Users/myusername/Library/Application\ Support/ActiveState

You may have to enter your password after typing the first command. This is normal, and required because you are executing that command as root (which is needed to change the ownership of files not owned by the current user).

## Unattended installation for ActiveTcl

Question:

How do I install ActiveTcl in such a way that a scripted, unattended installation will work?

Answer:

Since 8.4.8, automated installation was included but not published or
documented. The following documentation comes straight out of the comments
in the installer code:

--directory DIR
The installer goes auto and installs the distribution
into the directory DIR. The directory for the demos
is derived from that, it is DIR/demos. This can be
overridden. See below. The runtime directory is DIR as
well. This can be overridden. See below.
--demo-directory DIR
Overrides the location of the demo directory. See above.
The option is ignored if the installer is not in auto-mode.
--runtime-directory DIR
Specify directory to patch in. Optional. Ignored if
automatic mode was not activated with --directory.
Ignored on Windows.
--user-mode
Windows only, ignored on Unix. Install for the current
user. Default is to install for all users, i.e. admin-mode.
The option is ignored if the installer is not in auto-mode.
--no-plugin
Deactivates the installation of the plugin and all related
stuff. Optional. Default for automatic mode is to install
the plugin. The option is ignored if the installer is not in auto-mode.