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

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 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