Some words on this topic from the WebAdmin maintainer:
1. The Version 5 WebAdmin will never be as fast as the Version 4 one. Why? Well, version 4 used flat text files for configuration storage. This has the benefit of very fast read/write access, but once you want to read and write the configuration from more than one place, you start to get locking problems. Thats why we introduced a daemon called 'confd'. It is a managed configuration storage that also validates and cross-checks configuration data. Needless to say, it is much faster to read from a text file than to query confd (via XML-RPC). Since confd stores the basic config definitions like networks and services, it must be accessed on nearly each page of the WebAdmin. Check out /var/log/webadmin.log in the latest versions, there is some output regarding confd communication. We are currently working on making the communication faster.
2. I'm surprised to get so much flak for the pop-up menu. My design goal was to reduce clicks. In V4, you needed one click to open a menu, and another on to open the page. In V5, you only need one click, without a reload. Sure, you could pin the menus open in V4, but if you did that with most of them, you ended up scrolling a lot (mouse wheel syndrome).
3. The amount of configuration options has increased - again. This makes the interface more complex. I tried to pack as much information as possible in the tables, without cluttering things up too much. The filters should help you to navigate through the maze. Displaying less information would increase readability, but reduce usability for "advanced users". I'm seriously thinking about diversification into a "basic" and an "advanced mode". [[[:)]]]
4.Good, finally some tips. I think the concept of the new tables is not clear for everyone [[[:)]]]
Use the filters! They make finding stuff very easy. Also, you'll work on a limited set of entries, which helps with large tables.
You can edit stuff by clicking on it. If you can't click on it, you can't edit it.
You can edit multiple things at once, as many as you like. Clicking ONE of the open "Save" buttons will save all open edited entries. This also works across multiple lines.
When viewing logs (without live log), use the "Download" button on the right of the local log files table, and link .log files to a good text editor on your management machine (NOT notepad!). Logs can get real large, and most browsers handle multi-megabyte text files by crapping out. [[[:)]]]
The problem with the pop-up/flooting menu is major and I for one need a fix before I can use 5. I use an 800x600 display and the machine I test from has IE5. By default I can not see anything below IPSec on the Reporting menu (if I clear everything, URL, menu, etc. I can get down to the HTTP Proxy).
I'm sorry to hear about the speed issues and will have to test that since I administer all of my live ASL systems remotly.
Some explanation about XML-RPC for all that seem to think to know all about it. XML-RPC is a layer ABOVE the storage layer and acts as a Remote Procedure Call layer not as a DBMS system. An application exposing an XML-RPC interface may as well be running an SQL database but that is not (and should not be) important to the caller.
I am still interested in knowing whether the XML-RPC structure will be made available so that remote systems could be written to write and read data from the configuration manager. This could allow third parties to write some very interesting additions to Astaro. The best example I can think of would be to integrate corporate address books (say from an LDAP server) into the Astaro spam whitelist.
one of the reasons for introducing such a mechanism is to be able to connect different config clients to the firewall independantly of platform language or OS. Currently there is no API to do so but it is planned.
one of the reasons for introducing such a mechanism is to be able to connect different config clients to the firewall independantly of platform language or OS. Currently there is no API to do so but it is planned.
