Zimbra has a host of REST API's. These would allow you to access all your Zimbra data via SSH when needed. You could also just set up an SSH tunnel to get to the web UI, unless by SSH you mean command line only.
We currently use iptables to map a few ports from our service ports to privileged ports (80, 443, etc). We've removed most of this now and plan to remove it all together. As the comment mentioned we are still in beta. Due to feedback from the community and lack of default support on some other popular Linux kernels we are moving away from iptables for port mapping.
As for patching we don't make changes to iptables. It's a one-time thing when you first install.
We actually planned to upgrade our hosted demo last night. Just after we took the demo offline the story hit. We stayed up all night trying to figure out why things were so slow; when the CPU on the web servers were 90%+ idle. Turned out to be that the firewall at our ISP was only 10Mbit so it effectively throttled our site. This has been resolved, so we'll put the demo back up soon. You can see the bandwidth usage here: http://downloads.zimbra.com/slashdot_firewall_cap. png/
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.meyerweb.com%2Feric%2Ftools%2Fs5%2Fs5-intro.html
A quick run through the validator shows a couple errors.
I picked it up yesterday when the BT story first posted. Took only about 4hrs to get all the ISO's. At one point I was getting 400k+, I bet it's slower today since BT's speed is directly tied to the number of user's that are currently active. Even after the download finished my upload was sitting at about 60k with 50 or so clients connected for several hours.
Slashdot Mirror
Zimbra has a host of REST API's. These would allow you to access all your Zimbra data via SSH when needed. You could also just set up an SSH tunnel to get to the web UI, unless by SSH you mean command line only.
We currently use iptables to map a few ports from our service ports to privileged ports (80, 443, etc). We've removed most of this now and plan to remove it all together. As the comment mentioned we are still in beta. Due to feedback from the community and lack of default support on some other popular Linux kernels we are moving away from iptables for port mapping. As for patching we don't make changes to iptables. It's a one-time thing when you first install.
We've put the demo back up now that the bulk of the slashdotting is over... http://www.zimbra.com/demo/
We actually planned to upgrade our hosted demo last night. Just after we took the demo offline the story hit. We stayed up all night trying to figure out why things were so slow; when the CPU on the web servers were 90%+ idle. Turned out to be that the firewall at our ISP was only 10Mbit so it effectively throttled our site. This has been resolved, so we'll put the demo back up soon. You can see the bandwidth usage here: http://downloads.zimbra.com/slashdot_firewall_cap. png/
We actually send JSON to the webclient which allows us to quickly convert the responses to Javascript objects.
"Result: Failed validation, 4 errors"w .slashcode.com%2F
http://validator.w3.org/check?uri=http%3A%2F%2Fww
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .meyerweb.com%2Feric%2Ftools%2Fs5%2Fs5-intro.html
A quick run through the validator shows a couple errors.
I picked it up yesterday when the BT story first posted. Took only about 4hrs to get all the ISO's. At one point I was getting 400k+, I bet it's slower today since BT's speed is directly tied to the number of user's that are currently active. Even after the download finished my upload was sitting at about 60k with 50 or so clients connected for several hours.