i have installed the the ACS 5.1 on our VMware Server 2. After the basic configuration, i should be able to connect to the web interface.
if i enter the correct address i get an 404 HTML status error code.
So I'm trying to solve the problem.
i call the "show application status acs" commandoan the console displays
ACS role: PRIMARY
Process ' database ' running
Process ' management ' initializing
Process ' runtime ' running
Process ' view-database ' running
Process ' view-jobmanager ' running
Process ' view-alertmanager ' running
Process ' view-collector ' running
Process ' view-logprocessor ' running
So the reason is, that i cant log in into the web interface because the management process is not running and the apache tomcat server is a component of this process.
I followed the instructions of the document "Installation and Upgrade Guide for the Cisco Secure Access Control System 5.1", so all processes should run.
I tried to increase the log level, to get more information, but this doesnt work, because there is no valid license, which has to be installed with the web interface.
so does anyone know, why the management process doesnt start to run?
just 5 minutes ago I got a phone call from a customer reporting exactly the same issues.
He installed ACS with a Disk >=512 GB.
I would bet the web server / tomcat is not statrting because of a missing license file.
Is there a way to enter License information on the CLI ?
I already installed 5.1 as eval ( using a 80GB Harddisk so Auto-Installation of Evaluation License)
and did not have any problems.
This is not a license issue. The application server will start without a license. This allows a user to login to the GUI and get reidrected to the license installation page to instal a valid license.
No solid ideas but you can issue the following command at the CLI to get the last 80 lines of output to the management debug log:
show acs-logs filename ACSManagement.log | last 80
turned out, its the same test installation ;-)
Well, here is the error message Rocco sees every minute:
Jul 29 2010 15:50:40
FATAL pool-1-thread-1 Acs.MGMT.CONFIGRECOVERY configuration state reply failed to execute:null
at java.lang.ClassLoader.getResources(Unknown Source)
at sun.reflect.GeneratedMethodAccessor181.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at $Proxy1.getObjects(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I've been running 5.1 since May 2010 and have noticed this issue each time I reboot the VM.
It's always the management process that's hung at initializing.
Both with the eval license and our permanent license.
VM is spec'd above the minimum requirements.
I haven't contacted the TAC on this yet, but it's always worked for me to 'application stop acs' and 'application start acs'.
Not an adequate solution, but since it rarely gets reboot now, it works.
sorry for the double post, but i finally fins out why the gui doesnt start.
it seems to be a rounding error.
because the virtual machine, i installed, has an capacity 500 GB
and when i'm checking the storage with the "show inventory" command via the CLI, there is a capacity of 536.8 GB.
So the real capacity of the HDD is over 512 GB and the evaluationslicense is not installed.
So how did you manage to make it work?
I have exactly the same issue in a VM environment. Like described in the installation guide, I configured a 500Go HDD. My first install worked perfectly but now it's been the third time in a row where this problem appears.
What about a real purchased licence for a production environment? Do you think it should work the same way? In the installation guide, it's clearly mentionned that the virtual machine must have the same specifications (processor, RAM, HDD) than the appliance. Is this behavior a bug or something?
I've had the same problem on two different situations.
Found out that shut/no shut the ethernet interface on the ACS console would do the trick, via vSphere.(which will imply restarting acs service)
Obviously this not a satisfactory solution, because in case of rebooting a server the least you expect is to be able to re-access its management interface...
Haven't yet had the opportunity to open TAC case about it, mostly because the requirements for the VM's are so big, that I'm always running into an unsupported scenario... and I just don't what TAC to tell me - run the supported scenatio.
Actually I'm trying out ACS5.2 -- let us see if the problems persists...