system status "offline" - wrong

Hi Andre,

the "offline" status indicates whether the ACC has a properly established connection to the device agents of the respective ASG systems. It does not matter whether ACC is on version 1.301 or 1.400 - the status will remain "offline" - and correctly so - as long as this link is severed due to whatever reason.

You are correct, it does not necessarily mean, that your devices are completely offline, they only appear that way to ACC. This is because there is no other checking method (yet) other than an operational link with the device agent.

You can either disable/re-enable all device-agents on the respective devices by using WebAdmin >> Central Management >> ACC or by command line via /var/mdw/scripts/device-agent restart (unsupported, warranty void) or by just rebooting (ugh!) your devices.

I am more interested in why your device agents do not properly (re-)establish a connection to their chief ACC. The most probable reason is that they still have a pseudo-valid TCP connection:

- maybe because of an intermediate router/firewall
- or because they are using a PPPoE link where you get the same IP address after 24h again
- solar storms
- ...

The device agent will be content with a lingering half-established TCP connection while the ACC does not see it as valid anymore. This is a bad thing, especially because we added keepalive mechanisms to the device agent so that it would notice a failed TCP connection after some minutes. Maybe some more information on your network infrastructure could shed some light here.

Thanks and cheers,
Henning

hi henning,

- solar storms - how can i forget this easy.... ;-)

if i read your comments it looks more difficult than before, because:
- way to re-enable acc via webadmin works, but most times the asg "hung" after trying to reconnect (can't find cert) and ends in http500 - then the minimum is to restart httpd to come back to webadmin...
- way via shell never tried out - and will not do it on friday afternoon ;-)
- reboot sometimes helps, but sometimes NOT !!! - there was systems auto-rebooted after u2d or by customer still appears off

have all types of connections, most are pppoe-dyndns; but effect appears on all - dyndns, stativ dns, and also on leased lines!!
bad thing is, that these was fine over months - strange effect appears since a couple of weeks and rise...

was quite sure that the acc-hw is big enough; any way to find out if there are leaks? because sometimes the acc-web hungs too, have to close and reconn; sometimes have to reboot too...
acc is located on a seperate public ip behind astaro - bw is lower than recommended in hcl, but can't imagine that this will bring off only "some" externals...

let me know if i can give more...

tnx&rgds,
andre

add. info:
tried shell-restart on non-oper sys,
- works fine on a 6.303
- works NOT on a 6.202
- works on a 5.213

rgds, andre

add. info:
tried shell-restart on non-oper sys,
- works fine on a 6.303
- works NOT on a 6.202
- works on a 5.213

rgds, andre

Hi AMRos,

same problem here... I disable/re-enable on WebAdmin >> Central Management >> ACC and after that the webadmin become inaccessible.
Really the ACC ever didn't work very well and I have only 12 Astaros under control!
My ACC is a virtual server with 512MB RAM and a Xeon 2.66GHz CPU.

Hi mdallagi,

sorry to hear that your ACC installation is not behaving properly, but please try to avoid trivialising and exaggerating from a specific problem to a badly working product. Please post your network infrastructure information, whether you use PPPoE and your available bandwidth for ACC.

For all of you experiencing WebAdmin freezes with ASG V5.2/V6.3 when trying to re-enable the device agent via WebAdmin. Before the device agent will try to connect to ACC, there will be a separate SSL connect to the ACC to check the certificate fingerprint of the ACC. This check has been removed in ASG V7. You can avoid the hanging WebAdmin by using the command-line service script on the respective ASGs:

# /var/mdw/scripts/device-agent stop
# ... wait for 10 seconds
# /var/mdw/scripts/device-agent start

This will circumvent the additional SSL check.

Please ensure you have enough bandwidth to support the number of ASGs connected. If you get a lot of disconnect error messages in the agent-manager.log on the ACC, it probably hints out, that most requests do not get answered in time because of network saturation.

Thanks and regards,
Henning

Hi megaposer,

Excuse me if I have been so rude but I'm using ACC since the first release ad now on v1.4 I'm still seeing problems...
Anyway, you are saying to me that there are some issues with ACC and ASL/ASG 6 and 5.
The solution that you suggest to stop and restart the service is unsupported (warranty void).

In my network infrastructure, my ACC machine controls ASG and ASL with LAN or WAN connections. I can see the offline problem also on ASLs/ASGs connected via LAN (100 Mbits) so I think there is not a bandwidth problem.

Probably with v7 all will work better but actually is impossible for me to upgrade the firewalls, I'm waiting for a v7.x version that are able to import the v6 configuration.

Finally, I want say to you that ACC is a very important tool and I believe that the Astaro Team will do the best to make ACC/ASG better

Thanks for your support.

Hi mdallagi,

thanks for using the product since it's first release and again sorry that you are encountering problems with seemingly "offline" device(s). 

I agree that with only 12 devices there shouldn't be a bandwidth problem, especially considering that not all are interconnected via WAN. There may be other reasons, why a device-agent does not re-establish a void connection to the ACC. This is independent of whether you are using ASL/ASG V5/V6 or V7.

The difference between V5/V6 and the new V7 lies only in the skipped certificate fingerprint retrieval when re-enabling the device-agent. It might be prudent to remove this obsolete functionality in V5/V6, so you have a legitimate way of restarting the device-agent in WebAdmin without annoying freezes. I cannot promise this for an upcoming Up2Date though.

Anyway, this would only be fighting the symptom of the root cause. Even though it is quite handy to have a clean restart functionality, it should not be needed every so often. Hence we need to further investigate why and under which circumstances the connection from device-agent to ACC breaks in such a way, that the ACC thinks of the device-agent as "offline", but the device-agent thinks of himself as properly connected and "online".

Thanks for your confidence, we'll keep you posted here.

Cheers,
Henning

Hello Andre,

sorry to come back to you a bit later, I have not forgotten you. Basically the same things I've said to mdallagi apply to your problem as well. 

Although I suspect that you really might have a bandwidth problem in addition to other possible causes. Depends a bit on the number of ASG devices connected via your Internet link (is it 384/2048 DSL?) and whether this link is shared extensively with other services in your office.

As for the ASG 6.202 not reacting to the script-based restart, there may be an issue with ACC not being able to properly decode some aspects of the ASG license, hence not fully initializing the device in the monitoring views. If you can see a device in Device Management >> Registration but not within Device Monitoring (although having the correct roles/rights), this might indicate such a problem.

Thing is, we didn't change the connection handling from ACC 1.300 to 1.301 or then to 1.400, so the problem must have always existed (unnoticed) and became apparent only recently. Maybe you also increased the number of devices since starting with your original ACC installation?

Well, there is an alternative to reading tea leaves or analyzing fish entrails, just send the following logfiles to our support department after trying to reconnect the misbehaving device(s):

ASG : /var/log/device-agent.log
ACC : /var/log/agent-manager.log

Oh, sorry, this also of course applies to you mdallagi. If you can isolate this offline problem to one or more devices, please send those logfiles to our support as well.

Thanks for your input and your assistance.

Cheers,
Henning