The necessary groundwork for improved package, repository and namespace signing work is pretty much there now. Packages can be signed by multiple parties, and these are clearly visible when listing packages, repositories and namespaces.
The facility of namespaces supporting a minimum number of signers, optional and mandatory signers is also now in place too.
I've not released the code as a versioned release as yet, though once some more of the 2011 planned features are in place I will.
Wednesday, February 23, 2011
TrueCL work for 0.9.4 nearly complete
The work on what will become TrueCL 0.9.4 is nearing completion. Linux testing of the new configuration and status database work is looking good and soon the relevant documentation changes will be finished too.
Prior to 0.9.4 I'm also changing the handling of the "known net connections" to allow the status of such IP addresses to be returned via the status command "lha_stat".
I also intend to look at improvements to disk heartbeats and testing functionality for stopping applications and nodes using heartbeats only! That is quite ambitious and might slip for later releases, but is a definite aim.
Prior to 0.9.4 I'm also changing the handling of the "known net connections" to allow the status of such IP addresses to be returned via the status command "lha_stat".
I also intend to look at improvements to disk heartbeats and testing functionality for stopping applications and nodes using heartbeats only! That is quite ambitious and might slip for later releases, but is a definite aim.
Sunday, February 13, 2011
TP2 Security Improvements underway
I've recently started a series of changes to improve security and auditing facilities for TP2. First up are changes to implement secure repository management. Essentially the tp2 command set now provides tools to set and manage ACLs (Access Control Lists) on repositories. To support this the daemon process indirectly can be used to copy, remove, sign and un-sign packages in such repositories as well as provide repository index update services as before.
The range of services that the daemon provides will continue to grow as a lot more work on security and auditing is in the roadmap. Because of this the handling of requests by the daemon has also been re-written. In the previous versions it only handled requests in a single threaded manner. Now, however it supports an architecture for requests to be handled in the background - and all long-running requests now use this facility. The result is that the daemon can cope better with multiple requests issued at the same time.
The range of services that the daemon provides will continue to grow as a lot more work on security and auditing is in the roadmap. Because of this the handling of requests by the daemon has also been re-written. In the previous versions it only handled requests in a single threaded manner. Now, however it supports an architecture for requests to be handled in the background - and all long-running requests now use this facility. The result is that the daemon can cope better with multiple requests issued at the same time.
Friday, February 11, 2011
TrueCL work
Now that the latest update for linuxha.net is out of the way I'm turning my attention to TrueCl once again.
TrueCl uses sqlite for two purposes; a status database and a configuration database. One of the most frustrating things is that depending on the platform, perl version and sqlite version I covered through up more subtle locking issues when attempting to read/write at approximately the same time from different programs.
Although still a work in progress I've now re-written the status database to make use of a running service - which seems to defeat the purpose of SQLite in some respects, but at last I have a working solution!
Next couple of days will involve flipping that functionality to the configuration database module too - and then that should be one of the few significant portability issues with the core code resolved.
TrueCl uses sqlite for two purposes; a status database and a configuration database. One of the most frustrating things is that depending on the platform, perl version and sqlite version I covered through up more subtle locking issues when attempting to read/write at approximately the same time from different programs.
Although still a work in progress I've now re-written the status database to make use of a running service - which seems to defeat the purpose of SQLite in some respects, but at last I have a working solution!
Next couple of days will involve flipping that functionality to the configuration database module too - and then that should be one of the few significant portability issues with the core code resolved.
Subscribe to:
Posts (Atom)