Re: [VOTE] Kitty to Enter the Incubator
+1. Matthew, by the way, I'd like to contribute to this project. Thanks, Senaka. On Wed, Sep 15, 2010 at 12:50 PM, msacks ntw...@gmail.com wrote: At the advisement of the list, we have created a brand-new thread here for voting on the kitty proposal. The wiki page is located at: http://wiki.apache.org/incubator/KittyProposal Thanks. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] ALOIS to enter the incubator
All, this vote will fail in three hours because nobody responds to it. Are there any objections against this proposal? Or why is this vote ignored? Best regards, Christian On Wed, Sep 15, 2010 at 4:06 PM, Urs Lerch m...@ulerch.net wrote: Hi everybody out there The vote for ALOIS ends in about 24 hours. Are there any more comments or votes? We would appreciate it to get to know your opinion. Best Urs Am Montag, den 13.09.2010, 11:33 -0400 schrieb Urs Lerch: Hi Since the first call a few weeks ago didn't suceed (more mentors were asked), I would like to call a second vote for accepting the security information and event management tool ALOIS for incubation in the Apache Incubator. Thanks Christian Grobmeier we now have two mentors at least. But any additional mentors are still warmly welcome. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and, at least that's the way I understood, only votes from the Incubator PMC are binding. Thanks, Urs --- = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for interactive browsing through the collected data, exclusion/inclusion/selection of data, data sorting, data filtering, creation of views, ad-hoc textual and graphical reporting. Reptor allows for automatic activation of views and comparison of these views' results to a predefined result (pattern matching). In case of mismatch, Reptor sends the result to predefined e-mail addresses. Its modular design guarantees ALOIS to scale from little to large organizations. Since there exists a Debian package, it's easy to build a test system or even a productive system for small environments. Although the software has been in
Re: [VOTE] ALOIS to enter the incubator
On Thu, Sep 16, 2010 at 1:16 PM, Christian Grobmeier grobme...@gmail.com wrote: ...this vote will fail in three hours because nobody responds to it. Are there any objections against this proposal? Or why is this vote ignored?... 72 hours is a minimum, not a maximum, so no real problem. I'll have a look until tomorrow afternoon CET. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] ALOIS to enter the incubator
On Thu, Sep 16, 2010 at 7:16 AM, Christian Grobmeier grobme...@gmail.com wrote: All, this vote will fail in three hours because nobody responds to it. Are there any objections against this proposal? Or why is this vote ignored? Hi Christian, I ignored it because it was odd to me that there's essentially no further info about the project. I'm wondering why they don't/haven't begun open development (e.g. via Google Code or somesuch) on their own initiative since the code's already GPL. I dunno, they don't have licensing problems and, so, if they believe in open source it's not clear what was stopping them from open development already. Well, that's part of the story anyway... I had those thoughts and, upon reflecting on those thoughts, I began to realize that I have no clue what the objective criteria is for entering incubation. I am unsure what would cause us to say no. My vote here is now binding so I thought it better to watch and learn how more experienced folk rationalize this. Anyway, that's bordering on too much information but that's why *I* ignored it:) --tim On Wed, Sep 15, 2010 at 4:06 PM, Urs Lerch m...@ulerch.net wrote: Hi everybody out there The vote for ALOIS ends in about 24 hours. Are there any more comments or votes? We would appreciate it to get to know your opinion. Best Urs Am Montag, den 13.09.2010, 11:33 -0400 schrieb Urs Lerch: Hi Since the first call a few weeks ago didn't suceed (more mentors were asked), I would like to call a second vote for accepting the security information and event management tool ALOIS for incubation in the Apache Incubator. Thanks Christian Grobmeier we now have two mentors at least. But any additional mentors are still warmly welcome. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and, at least that's the way I understood, only votes from the Incubator PMC are binding. Thanks, Urs --- = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the
Re: Accepting patches in a podling
On Thu, Sep 16, 2010 at 1:41 AM, Benson Margulies bimargul...@gmail.com wrote: ...It takes about two minutes to make a JIRA. If the contributor can't spare those two minutes, how are they having time to make a patch at all?... ...Perhaps this is because I'm accustomed, at both my day job and on several Apache projects, to seeing JIRA as the central organizing tool of everything that gets done. If there isn't a JIRA, it doesn't exist... I think that's the key in this discussion: if a project considers JIRA their central organizing tool, it's fine to require patches to go there. If another project prefers patches on the dev list, that also works, though JIRA helps make the intentional contribution bit more explicit. In both cases, authors of substantial contributions (whatever that means) need to have an iCLA on file. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] ALOIS to enter the incubator
+1 On Thu, Sep 16, 2010 at 7:16 AM, Christian Grobmeier grobme...@gmail.comwrote: All, this vote will fail in three hours because nobody responds to it. Are there any objections against this proposal? Or why is this vote ignored? Best regards, Christian On Wed, Sep 15, 2010 at 4:06 PM, Urs Lerch m...@ulerch.net wrote: Hi everybody out there The vote for ALOIS ends in about 24 hours. Are there any more comments or votes? We would appreciate it to get to know your opinion. Best Urs Am Montag, den 13.09.2010, 11:33 -0400 schrieb Urs Lerch: Hi Since the first call a few weeks ago didn't suceed (more mentors were asked), I would like to call a second vote for accepting the security information and event management tool ALOIS for incubation in the Apache Incubator. Thanks Christian Grobmeier we now have two mentors at least. But any additional mentors are still warmly welcome. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and, at least that's the way I understood, only votes from the Incubator PMC are binding. Thanks, Urs --- = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for interactive browsing through the collected data, exclusion/inclusion/selection of data, data sorting, data filtering, creation of views, ad-hoc textual and graphical reporting. Reptor allows for automatic activation of views and comparison of these views' results to a predefined result (pattern matching). In case of mismatch, Reptor sends the result to predefined e-mail addresses. Its modular design guarantees ALOIS to
Re: [PROPOSAL] Gora to enter Incubator
Thanks to everyone who have shown interest in the project. I think Chris added all, who has indicated their support as committers. On behalf of the initial comitters, welcome on board : ) Just FYI in case you want to start contributing right away, we use github as the collaboration tool until we can establish the infrastructure at Apache. Cheers, Enis On Tue, Sep 14, 2010 at 11:51 PM, Tom White tomwh...@apache.org wrote: +1 Sounds very interesting. I'd be happy to help out as a mentor. Cheers, Tom On Mon, Sep 13, 2010 at 6:10 AM, Enis Soztutar enis.soz.nu...@gmail.com wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == === Meritocracy === Current commit rights belong to the initial list of committers four of who are also ASF members. All the developers have extensive experience with Apache projects. We honor the meritocracy policy of ASF foundation. === Community === Gora’s community mostly overlap with that of Nutch, Hadoop, HBase, Avro and Cassandra. We have a small community for now (5 initial committers, 18 people tracking the project at Github), but have been piggybacking the Nutch
Re: [PROPOSAL] Gora to enter Incubator
Hi Enis, Thanks. Let’s leave the VOTE open until Friday evening Pacific time to give folks time to look at the proposal. Technically we didn’t do a VOTE thread on this yet though and I saw that some folks just asked Kitty to explicitly post a [VOTE] thread, so we may want to do that here. What do folks think? If so, then I’ll call a VOTE thread around Friday evening, and leave it open for 72 hours. Cheers, Chris On 9/16/10 5:57 AM, Enis Soztutar enis.soz.nu...@gmail.com wrote: Thanks to everyone who have shown interest in the project. I think Chris added all, who has indicated their support as committers. On behalf of the initial comitters, welcome on board : ) Just FYI in case you want to start contributing right away, we use github as the collaboration tool until we can establish the infrastructure at Apache. Cheers, Enis On Tue, Sep 14, 2010 at 11:51 PM, Tom White tomwh...@apache.org wrote: +1 Sounds very interesting. I'd be happy to help out as a mentor. Cheers, Tom On Mon, Sep 13, 2010 at 6:10 AM, Enis Soztutar enis.soz.nu...@gmail.com wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of committers are all ASF members. Therefore, we think that Apache will be an excellent home for Gora. == Initial Goals == Initial goals for Gora can be summarized as: * Iron out the remaining issues with HBase, Cassandra and SQL support. * Make the first release before the end of the year. * Improve documentation * Support for Cascading == Current Status == ===
Re: [PROPOSAL] Gora to enter Incubator
Hi On Thu, Sep 16, 2010 at 4:43 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Enis, Thanks. Let’s leave the VOTE open until Friday evening Pacific time to give folks time to look at the proposal. Technically we didn’t do a VOTE thread on this yet though and I saw that some folks just asked Kitty to explicitly post a [VOTE] thread, so we may want to do that here. Sorry, I wasn't implying that the vote is over, just a friendly welcome to new comers. I agree that a [VOTE] thread might be necessary if that is the concensus. What do folks think? If so, then I’ll call a VOTE thread around Friday evening, and leave it open for 72 hours. Cheers, Chris On 9/16/10 5:57 AM, Enis Soztutar enis.soz.nu...@gmail.com wrote: Thanks to everyone who have shown interest in the project. I think Chris added all, who has indicated their support as committers. On behalf of the initial comitters, welcome on board : ) Just FYI in case you want to start contributing right away, we use github as the collaboration tool until we can establish the infrastructure at Apache. Cheers, Enis On Tue, Sep 14, 2010 at 11:51 PM, Tom White tomwh...@apache.org wrote: +1 Sounds very interesting. I'd be happy to help out as a mentor. Cheers, Tom On Mon, Sep 13, 2010 at 6:10 AM, Enis Soztutar enis.soz.nu...@gmail.com wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and mapreduce), HBase, Cassandra, Avro, Lucene, Solr, Pig, and Hive. Gora already uses Hadoop, HBase, Cassandra and Avro. Moreover, Gora started its life inside Apache Nutch project, and now Nutch trunk uses Gora as a library. Even more, the initial set of
Re: [PROPOSAL] Gora to enter Incubator
Hey Enis, No worries, I just thought of this myself, so just thinking out loud here. Welcome to everyone, indeed! Hopefully we can use this critical mass to really springboard Gora! Cheers, Chris On 9/16/10 6:55 AM, Enis Soztutar enis.soz.nu...@gmail.com wrote: Hi On Thu, Sep 16, 2010 at 4:43 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Enis, Thanks. Let’s leave the VOTE open until Friday evening Pacific time to give folks time to look at the proposal. Technically we didn’t do a VOTE thread on this yet though and I saw that some folks just asked Kitty to explicitly post a [VOTE] thread, so we may want to do that here. Sorry, I wasn't implying that the vote is over, just a friendly welcome to new comers. I agree that a [VOTE] thread might be necessary if that is the concensus. What do folks think? If so, then I’ll call a VOTE thread around Friday evening, and leave it open for 72 hours. Cheers, Chris On 9/16/10 5:57 AM, Enis Soztutar enis.soz.nu...@gmail.com wrote: Thanks to everyone who have shown interest in the project. I think Chris added all, who has indicated their support as committers. On behalf of the initial comitters, welcome on board : ) Just FYI in case you want to start contributing right away, we use github as the collaboration tool until we can establish the infrastructure at Apache. Cheers, Enis On Tue, Sep 14, 2010 at 11:51 PM, Tom White tomwh...@apache.org wrote: +1 Sounds very interesting. I'd be happy to help out as a mentor. Cheers, Tom On Mon, Sep 13, 2010 at 6:10 AM, Enis Soztutar enis.soz.nu...@gmail.com wrote: Hi all, We would like to announce the Proposal for Gora, an ORM for Colum Stores, for the Apache Incubation. We believe that Gora can find a nice home at Apache. Wiki of the proposal can be found at http://wiki.apache.org/incubator/GoraProposal The proposal is as below. = Gora Proposal for Apache Incubation = == Abstract == Gora is an ORM framework for column stores such as Apache HBase and Apache Cassandra with a specific focus on Hadoop. == Proposal == Although there are various excellent ORM frameworks for relational databases, data modeling in NoSQL data stores differ profoundly from their relational cousins. Moreover, data-model agnostic frameworks such as JDO are not sufficient for use cases, where one needs to use the full power of the data models in column stores. Gora fills this gap by giving the user an easy-to-use ORM framework with data store specific mappings and built in Apache Hadoop support. The overall goal for Gora is to become the standard data representation and persistence framework for big data. The roadmap of Gora can be grouped as follows. * Data Persistence : Persisting objects to Column stores such as HBase, Cassandra, Hypertable; key-value stores such as Voldermort, Redis, etc; SQL databases, such as MySQL, HSQLDB, flat files in local file system of Hadoop HDFS. * Data Access : An easy to use Java-friendly common API for accessing the data regardless of its location. * Indexing : Persisting objects to Lucene and Solr indexes, accessing/querying the data with Gora API. * Analysis : Accesing the data and making analysis through adapters for Apache Pig, Apache Hive and Cascading * MapReduce support : Out-of-the-box and extensive MapReduce (Apache Hadoop) support for data in the data store. == Background == ORM stands for Object Relation Mapping. It is a technology which abstacts the persistency layer (mostly Relational Databases) so that plain domain level objects can be used, without the cumbersome effort to save/load the data to and from the database. Gora differs from current solutions in that: * Gora is specially focussed at NoSQL data stores, but also has limited support for SQL databases * The main use case for Gora is to access/analyze big data using Hadoop. * Gora uses Avro for bean definition, not byte code enhancement or annotations * Object-to-data store mappings are backend specific, so that full data model can be utilized. * Gora is simple since it ignores complex SQL mappings * Gora will support persistence, indexing and anaysis of data, using Pig, Lucene, Hive, etc == Rationale == ORM frameworks are nothing new. But with the explosion of data generated in Terabytes and even Petabytes, NoSQL data stores are gaining ever-increasing popularity. Coupled with limited support to already-proven Apache Hadoop support in current ORM frameworks, there was a need for a new project. Gora is currently hosted at Github. However, Gora has ties to ASF in many ways. As detailed in the proposal section, Gora will be a high level client for many Apache projects and subprojects including Hadoop(common, hdfs, and
Re: Accepting patches in a podling
- Original Message From: Bertrand Delacretaz bdelacre...@apache.org To: general@incubator.apache.org Sent: Thu, September 16, 2010 7:40:22 AM Subject: Re: Accepting patches in a podling On Thu, Sep 16, 2010 at 1:41 AM, Benson Margulies bimargul...@gmail.com wrote: ...It takes about two minutes to make a JIRA. If the contributor can't spare those two minutes, how are they having time to make a patch at all?... ...Perhaps this is because I'm accustomed, at both my day job and on several Apache projects, to seeing JIRA as the central organizing tool of everything that gets done. If there isn't a JIRA, it doesn't exist... I think that's the key in this discussion: if a project considers JIRA their central organizing tool, it's fine to require patches to go there. If another project prefers patches on the dev list, that also works, though JIRA helps make the intentional contribution bit more explicit. In both cases, authors of substantial contributions (whatever that means) need to have an iCLA on file. It means independently copyrightable. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] ALOIS to enter the incubator
Hi Tim Thanks for your interest and thanks to Christian for his effort. So far the project and therefore the code had only be used in two organizations. Therefore, the project is like closed, although licenced under the GPL. There is really almost no usable documentation (at least in English, because the organizations are located in the German speaking part of Switzerland) and the developers would like to go over the code before it is widely published. If I understand the incubator process right, these two tasks should or could be done during the podling phase (which in this case might take a little big longer than with other projects). Having no real project side so far wasn't a real problem for me, because I thought entering the Incubator is more about a good (matching) idea than about working code. Furthermore, I can imagine, that with a bigger community of developers, a good part of the now existing code will be replaced anyway. Since we are not in a hurry, and if it is common sense that there should be more available before entering the incubator, we could do this extra effort. I wonder, what others think of this issue. Best Urs Am Donnerstag, den 16.09.2010, 07:38 -0400 schrieb Tim Williams: On Thu, Sep 16, 2010 at 7:16 AM, Christian Grobmeier grobme...@gmail.com wrote: All, this vote will fail in three hours because nobody responds to it. Are there any objections against this proposal? Or why is this vote ignored? Hi Christian, I ignored it because it was odd to me that there's essentially no further info about the project. I'm wondering why they don't/haven't begun open development (e.g. via Google Code or somesuch) on their own initiative since the code's already GPL. I dunno, they don't have licensing problems and, so, if they believe in open source it's not clear what was stopping them from open development already. Well, that's part of the story anyway... I had those thoughts and, upon reflecting on those thoughts, I began to realize that I have no clue what the objective criteria is for entering incubation. I am unsure what would cause us to say no. My vote here is now binding so I thought it better to watch and learn how more experienced folk rationalize this. Anyway, that's bordering on too much information but that's why *I* ignored it:) --tim On Wed, Sep 15, 2010 at 4:06 PM, Urs Lerch m...@ulerch.net wrote: Hi everybody out there The vote for ALOIS ends in about 24 hours. Are there any more comments or votes? We would appreciate it to get to know your opinion. Best Urs Am Montag, den 13.09.2010, 11:33 -0400 schrieb Urs Lerch: Hi Since the first call a few weeks ago didn't suceed (more mentors were asked), I would like to call a second vote for accepting the security information and event management tool ALOIS for incubation in the Apache Incubator. Thanks Christian Grobmeier we now have two mentors at least. But any additional mentors are still warmly welcome. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and, at least that's the way I understood, only votes from the Incubator PMC are binding. Thanks, Urs --- = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure
Re: [VOTE] ALOIS to enter the incubator
I think it is often a sign of I don't care either way, when no one responds. At least this is my take on projects; If I don't care, I won't stop others from embracing, and silently say nothing. Cheers Niclas On Thu, Sep 16, 2010 at 7:16 PM, Christian Grobmeier grobme...@gmail.com wrote: All, this vote will fail in three hours because nobody responds to it. Are there any objections against this proposal? Or why is this vote ignored? Best regards, Christian On Wed, Sep 15, 2010 at 4:06 PM, Urs Lerch m...@ulerch.net wrote: Hi everybody out there The vote for ALOIS ends in about 24 hours. Are there any more comments or votes? We would appreciate it to get to know your opinion. Best Urs Am Montag, den 13.09.2010, 11:33 -0400 schrieb Urs Lerch: Hi Since the first call a few weeks ago didn't suceed (more mentors were asked), I would like to call a second vote for accepting the security information and event management tool ALOIS for incubation in the Apache Incubator. Thanks Christian Grobmeier we now have two mentors at least. But any additional mentors are still warmly welcome. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and, at least that's the way I understood, only votes from the Incubator PMC are binding. Thanks, Urs --- = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for interactive browsing through the collected data, exclusion/inclusion/selection of data, data sorting, data filtering, creation of views, ad-hoc textual and graphical reporting. Reptor allows for automatic activation of views and comparison of these views' results to a predefined result (pattern matching). In case of mismatch,
Re: [VOTE] ALOIS to enter the incubator
Hi Urs, My only concern is the request to have a chat channel. There's wide use of chat channels in Apache (the periodic board and members' meetings make use of them, and infrastructure uses channels to advantage). But for an incubating project, I'd strongly discourage use of chat as a communication channel. +1 Craig On Aug 26, 2010, at 9:09 AM, Urs Lerch wrote: Hi, I would like to call a vote for accepting ALOIS for incubation in the Apache Incubator. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/ AloisProposal). We ask the Incubator PMC to sponsor it, with Scott Deboy volunteering as Champion and Mentor. Additional mentors are warmly welcome. Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and only votes from the Incubator PMC are binding. Thanks, Urs = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for interactive browsing through the collected data, exclusion/inclusion/selection of data, data sorting, data filtering, creation of views, ad-hoc textual and graphical reporting. Reptor allows for automatic activation of views and comparison of these views' results to a predefined result (pattern matching). In case of mismatch, Reptor sends the result to predefined e-mail addresses. Its modular design guarantees ALOIS to scale from little to large organizations. Since there exists a Debian package, it's easy to build a test system or even a productive system for small environments. Although the software has been in productive use for a few years, there is still a lot of desired functionality missing. The plugability of new connected systems is given, but needs some revision. It is a given goal of the project to allow modules in other programming language. Furthermore, it has been discussed if parts of the existing implementation may be
Real-time communication (was [VOTE] ALOIS to enter the incubator)
I understand the concern raised by the use of real-time communication for Apache projects - that decisions may be made off-list, and that folks who aren't a party to the real-time communication do not have the opportunity to benefit from or impact the decisions that result from the real-time communication. The proposal does offer what seems to be a reasonable compromise: 'we would send the logs daily to the mailing list.' Daily chat logs posted to the dev list, coupled with good mentoring and guidance that decisions need to be made on the mailing list, would seem to minimize the risk. I'm interested in what others think of their proposal for supporting real-time communication, and curious what others are doing, if anything, to support the growing interest in real-time communication between project participants. Scott On Thu, Sep 16, 2010 at 10:49 AM, Craig L Russell craig.russ...@oracle.comwrote: Hi Urs, My only concern is the request to have a chat channel. There's wide use of chat channels in Apache (the periodic board and members' meetings make use of them, and infrastructure uses channels to advantage). But for an incubating project, I'd strongly discourage use of chat as a communication channel. +1 Craig On Aug 26, 2010, at 9:09 AM, Urs Lerch wrote: Hi, I would like to call a vote for accepting ALOIS for incubation in the Apache Incubator. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). We ask the Incubator PMC to sponsor it, with Scott Deboy volunteering as Champion and Mentor. Additional mentors are warmly welcome. Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and only votes from the Incubator PMC are binding. Thanks, Urs = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for
Re: Real-time communication (was [VOTE] ALOIS to enter the incubator)
On Thu, Sep 16, 2010 at 9:27 PM, Scott Deboy scott.de...@gmail.com wrote: ...I'm interested in what others think of their proposal for supporting real-time communication, and curious what others are doing, if anything, to support the growing interest in real-time communication between project participants IMO the key point is if it didn't happen on the dev list it didn't happen. Coffee machine conversations, private emails and chat, phone calls and IRC all happen. What's important is that for any type of out-of-band discussion to be summarized on the dev list as soon as they have impact on the project, code or community [1]. And all decisions must happen on the dev list. Sending daily IRC logs to the dev list is fine, but if decisions happen on IRC that's wrong - the dev list has to be the central channel where all the important information is found, and all decisions happen. -Bertrand [1] https://blogs.apache.org/comdev/entry/what_makes_apache_projects_different - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Kitty to Enter the Incubator
Thanks Senaka, we always appreciate the help. On Wed, Sep 15, 2010 at 11:03 PM, Senaka Fernando sen...@apache.org wrote: +1. Matthew, by the way, I'd like to contribute to this project. Thanks, Senaka. On Wed, Sep 15, 2010 at 12:50 PM, msacks ntw...@gmail.com wrote: At the advisement of the list, we have created a brand-new thread here for voting on the kitty proposal. The wiki page is located at: http://wiki.apache.org/incubator/KittyProposal Thanks. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Real-time communication (was [VOTE] ALOIS to enter the incubator)
On Thu, 2010-09-16 at 21:32 +0200, Bertrand Delacretaz wrote: On Thu, Sep 16, 2010 at 9:27 PM, Scott Deboy scott.de...@gmail.com wrote: ...I'm interested in what others think of their proposal for supporting real-time communication, and curious what others are doing, if anything, to support the growing interest in real-time communication between project participants IMO the key point is if it didn't happen on the dev list it didn't happen. Coffee machine conversations, private emails and chat, phone calls and IRC all happen. What's important is that for any type of out-of-band discussion to be summarized on the dev list as soon as they have impact on the project, code or community [1]. And all decisions must happen on the dev list. Sending daily IRC logs to the dev list is fine, but if decisions happen on IRC that's wrong - the dev list has to be the central channel where all the important information is found, and all decisions happen. Sending IRC logs to the dev list is okay, as a reference, but please don't expect folks to actually read them as they come in. Reading IRC logs is incredibly tedious for people who are not a part of the conversation as it is happening. Therefore, posting IRC logs to a dev list is not, IMO, sufficient as a means of informing the dev list of what was discussed there. It needs summarising separately - that is, assuming anything relevant to the dev list was actually discussed. Upayavira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Chemistry OpenCMIS 0.1.0-incubating (RC2)
Hi, On Tue, Sep 14, 2010 at 3:02 PM, Gabriele Columbro gabri...@apache.org wrote: The vote is open for 72 hours. The window closes tomorrow. We're still one IPMC vote short and I believe Gianugo (our third mentor) is understandably pretty busy with other stuff right now. It would be great if someone else from the IPMC could take a quick look at this release so we can push it out (or fix any issues we missed). TIA! BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Chemistry OpenCMIS 0.1.0-incubating (RC2)
On 16 September 2010 23:55, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Sep 14, 2010 at 3:02 PM, Gabriele Columbro gabri...@apache.org wrote: The vote is open for 72 hours. The window closes tomorrow. AFAIK the 72 hours is a minimum, not a maximum. We're still one IPMC vote short and I believe Gianugo (our third mentor) is understandably pretty busy with other stuff right now. It would be great if someone else from the IPMC could take a quick look at this release so we can push it out (or fix any issues we missed). TIA! BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] ALOIS to enter the incubator
Hi Craig Thanks for you input and your vote. In my view, the chat is not a must, but a proposition. I understand your concern and I certainly will keep it in mind. But since ALOIS should become a community project, I still think the followers of it should decide which communication channell they prefer. (By the way, I myself sure am no fan of chats.) I hope you can live with this. Best Urs Am Donnerstag, den 16.09.2010, 10:49 -0700 schrieb Craig L Russell: Hi Urs, My only concern is the request to have a chat channel. There's wide use of chat channels in Apache (the periodic board and members' meetings make use of them, and infrastructure uses channels to advantage). But for an incubating project, I'd strongly discourage use of chat as a communication channel. +1 Craig On Aug 26, 2010, at 9:09 AM, Urs Lerch wrote: Hi, I would like to call a vote for accepting ALOIS for incubation in the Apache Incubator. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/ AloisProposal). We ask the Incubator PMC to sponsor it, with Scott Deboy volunteering as Champion and Mentor. Additional mentors are warmly welcome. Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and only votes from the Incubator PMC are binding. Thanks, Urs = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for interactive browsing through the collected data, exclusion/inclusion/selection of data, data sorting, data filtering, creation of views, ad-hoc textual and graphical reporting. Reptor allows for automatic activation of views and comparison of these views' results to a predefined result (pattern matching). In case
