Controle de Cotas de usuário e disco

[diogenesduarte]

Inclusão das seguintes funcionalidades:

1. Cota de usuários por setor;
2. Cota de disco por setor;

---

Para habilitar o controle de cotas de usuários e disco, é necessário selecionar a opção "sim" de "Usar controle de quotas por ou:" em configurações globais no módulo admin.

Após habilitado, ao criar uma nova 'OU' deverá ser informado a cota para usuário e a cota para disco, sendo que se nenhum valor for informado o expresso tomará como valor default '0';

Ao criar um usuário será verificado o limite das cotas tanto para usuário por setor quanto para o espaço em disco que já está utilizado, para que estes não exceda o limite das cotas.

Na tela de Organizações do expressoAdmin poderá ser verificado a quantidade de usuários e disco usado para cada 'OU' e suas respectivas cotas, sendo que as mesmas poderão ser alteradas clicando no link 'editar' referente a cada 'OU'.

[wmerlotto]

Esta funcionalidade não foi incluída, correto?

[niltonneto]

Correto. A Prodeb implementou, mas acredito que a unificação do ExpressoAdmin deles tenha ficado pra uma próxima etapa.

[wmerlotto]

Replying to niltonneto:

Correto. A Prodeb implementou, mas acredito que a unificação do ExpressoAdmin deles tenha ficado pra uma próxima etapa.

Então vamos aguardar a unificação para a próxima versão do Expresso...

[diogenesduarte]

Comitado a parte principal na revisão [1516]. Falta adicionar atributos no ldap. Como eu faria a adição desses atributos como parte da atualização do setup no expresso?

[niltonneto]

O schema LDAP utilizado pelo Expresso é raramente alterado. Normalmente apenas incluimos as alterações no doc-expressolivre, para o instalador. Seria interessante avisar o administrador, caso os atributos não existam no LDAP do Expresso dele, no momento que habilitar essa feature. O mesmo deveria ser feito em relação ao termo de aceite.

[diogenesduarte]

Falta alguma coisa para fechar esse ticket? Ao meu ver está tudo funcionando, o único problema são esses atributos novos no ldap.

[wmerlotto]

Replying to diogenesduarte:

Falta alguma coisa para fechar esse ticket? Ao meu ver está tudo funcionando, o único problema são esses atributos novos no ldap.

Estes novos atributos estão contidos nos schemas disponíveis na pasta doc-expressolivre, essencial para instalação?

[niltonneto]

É preciso atualizar o core.schema do pacote de instalação. Não esqueça de validar dentro dessa funcionalidade se tal atributo existe no ldap. Ou descreva aqui o que o administrador precisa fazer no ldap dele para que essa funcionalidade funcione corretamente.....

[joaquim.ferraz]

Bom pessoal estamos testando essa funcionalidade após Zapa ter nos enviado os esquemas. Bom gostaria de sugerir a seguinte mudança.

Na função "get_num_users" ao invés de usar o filtro "$filter = "(objectClass=inetOrgPerson)";" usar "$filter = "(|(phpgwAccountType=u)(phpgwAccountType=s));".

Por que sugiro isso pois ao meu entender é controle de quota e pelo meu conhecimento de contas de Expresso que virá a partir da versão 2.2 existirá 2 tipos de contas que utilizam cotas que é a de usuário(u) e a compartilhada que Valmir criou que é do tipo "s" pois bem sendo assim acho que devemos apenas contabilizar esses dois tipos de contas e não todas que tenham o objectClass "inetOrgPerson" definidos em seus objetos.

Esse recurso estamos ansiosos pois temos sérios problemas com storage pois como temos em nosso ambiente todos os órgão do Estado os gestores de contas não se preocupam muito em controlar esses recursos e com esse controle acho que irão passar a se preocupar.

Bom não sei o que pensam e por favor ignorem se falei alguma besteira.

[joaquim.ferraz]

Replying to joaquim.ferraz:

Bom pessoal estamos testando essa funcionalidade após Zapa ter nos enviado os esquemas. Bom gostaria de sugerir a seguinte mudança.

Na função "get_num_users" ao invés de usar o filtro "$filter = "(objectClass=inetOrgPerson)";" usar "$filter = "(|(phpgwAccountType=u)(phpgwAccountType=s));".

Por que sugiro isso pois ao meu entender é controle de quota e pelo meu conhecimento de contas de Expresso que virá a partir da versão 2.2 existirá 2 tipos de contas que utilizam cotas que é a de usuário(u) e a compartilhada que Valmir criou que é do tipo "s" pois bem sendo assim acho que devemos apenas contabilizar esses dois tipos de contas e não todas que tenham o objectClass "inetOrgPerson" definidos em seus objetos.

Esse recurso estamos ansiosos pois temos sérios problemas com storage pois como temos em nosso ambiente todos os órgão do Estado os gestores de contas não se preocupam muito em controlar esses recursos e com esse controle acho que irão passar a se preocupar.

Bom não sei o que pensam e por favor ignorem se falei alguma besteira.

Outra coisa que percebi é deveríamos usar na "function get_actual_disk_usage($context)" ao invés de "$this->get_list('accounts', , $contexts);" usar uma variação delaa pois a atual só pesquisa apenas contas do tipo "u" e deveria também pesquisar do tipo "s" pois ambas usam cota de disco.

[rommelcysne]

Nós definimos os atributos no phpgwaccount.schema, afinal este schema já é usado pelo Expresso, é o arquivo que pode, e deve, ser alterado para suportar as peculiaridades por nós implementadas sem alterar schemas padrão do OpenLDAP, como o core.schema.

Em anexo está o arquivo que utilizamos para nossos testes e que será usado quando a funcionalidade for para produção. Essas alterações podem ser feitas no phpgwaccount.schema lá do doc-expressolivre e quando o Expresso for instalado, ficarão disponíveis para uso.

Uma mudança que fizemos foi tirar a linha

$sector_infoobjectClass?[2] = 'phpgwAccount';

de dentro do if($_POSTsector_visible?), e colocamos junto com o bloco de criação do array a ser incluído no LDAP, uma vez que, da forma que estava, o setor precisaria ser visível para ter controle de cotas.

[rommelcysne]

phpgwaccount.schema

[diogenesduarte]

Replying to rommelcysne:

Nós definimos os atributos no phpgwaccount.schema, afinal este schema já é usado pelo Expresso, é o arquivo que pode, e deve, ser alterado para suportar as peculiaridades por nós implementadas sem alterar schemas padrão do OpenLDAP, como o core.schema.

Semanticamente falando, eu acho meio estranho colocar atributos referente às OUs em phpgwaccount.schema. Aqui na PRODEB nós criamos um esquema novo sobre quotas e o adicionamos. Sem dúvida é muito mais simples jogar os atributos em um esquema já existente, mas acho que fica estranho. Se eu tivesse que dar manutenção por exemplo, o último esquema em que eu procuraria esses atributos seria no account.

[diogenesduarte]

Replying to joaquim.ferraz:

Outra coisa que percebi é deveríamos usar na "function get_actual_disk_usage($context)" ao invés de "$this->get_list('accounts', , $contexts);" usar uma variação delaa pois a atual só pesquisa apenas contas do tipo "u" e deveria também pesquisar do tipo "s" pois ambas usam cota de disco.

Essa funcionalidade que cria contas com o phpgwaccounttype=s já está implantada? Concordo que com ela implantada temos que rever as regras da funcionalidade de quotas, pois hoje ela só considera contas do tipo u.

[rommelcysne]

Replying to diogenesduarte:

Replying to rommelcysne:

Nós definimos os atributos no phpgwaccount.schema, afinal este schema já é usado pelo Expresso, é o arquivo que pode, e deve, ser alterado para suportar as peculiaridades por nós implementadas sem alterar schemas padrão do OpenLDAP, como o core.schema.

Semanticamente falando, eu acho meio estranho colocar atributos referente às OUs em phpgwaccount.schema. Aqui na PRODEB nós criamos um esquema novo sobre quotas e o adicionamos. Sem dúvida é muito mais simples jogar os atributos em um esquema já existente, mas acho que fica estranho. Se eu tivesse que dar manutenção por exemplo, o último esquema em que eu procuraria esses atributos seria no account.

Perfeito, então mudemos o enfoque e, ao invés de um schema com atributos de usuários, pensemos em um schema com atributos do Expresso, em que seriam elencados os atributos que nós precisamos e que não possuem similar nos schemas padrão do LDAP, seja para usuários, grupos, OU, etc, para esses casos, os schemas existentes (inetOrgPerson, Core, etc) já cobrem a grande maioria das necessidades, o que acha?

[diogenesduarte]

Replying to rommelcysne:

Replying to diogenesduarte:

Replying to rommelcysne:

Nós definimos os atributos no phpgwaccount.schema, afinal este schema já é usado pelo Expresso, é o arquivo que pode, e deve, ser alterado para suportar as peculiaridades por nós implementadas sem alterar schemas padrão do OpenLDAP, como o core.schema.

Semanticamente falando, eu acho meio estranho colocar atributos referente às OUs em phpgwaccount.schema. Aqui na PRODEB nós criamos um esquema novo sobre quotas e o adicionamos. Sem dúvida é muito mais simples jogar os atributos em um esquema já existente, mas acho que fica estranho. Se eu tivesse que dar manutenção por exemplo, o último esquema em que eu procuraria esses atributos seria no account.

Perfeito, então mudemos o enfoque e, ao invés de um schema com atributos de usuários, pensemos em um schema com atributos do Expresso, em que seriam elencados os atributos que nós precisamos e que não possuem similar nos schemas padrão do LDAP, seja para usuários, grupos, OU, etc, para esses casos, os schemas existentes (inetOrgPerson, Core, etc) já cobrem a grande maioria das necessidades, o que acha?

Hum... Ficaria legal sim, mas acho que eu pensei em algo que modifica menos a estrutura. O que você acha de criar um esquema novo, com um objectClass tipo quotacontrolled(ou algo do gênero) aonde os objetos que seriam controlados por quota(as OU's) herdassem essa classe de objetos, mantendo o phpgwaccount apenas para contas e retirando ele das OU's? Assim não nos preocuparíamos com o phpgwaccount e aproveitamos para tirar isso das ous, que alias, não consegui ver o motivo de OUs herdarem esse objectClass.

[zapa]

Anexa ai o novo esquema...

[eduardoalex]

Diógenes,

Favor colocar no instalador...

[rommelcysne]

Replying to diogenesduarte:

Replying to rommelcysne:

Replying to diogenesduarte:

Replying to rommelcysne:

Nós definimos os atributos no phpgwaccount.schema, afinal este schema já é usado pelo Expresso, é o arquivo que pode, e deve, ser alterado para suportar as peculiaridades por nós implementadas sem alterar schemas padrão do OpenLDAP, como o core.schema.

Semanticamente falando, eu acho meio estranho colocar atributos referente às OUs em phpgwaccount.schema. Aqui na PRODEB nós criamos um esquema novo sobre quotas e o adicionamos. Sem dúvida é muito mais simples jogar os atributos em um esquema já existente, mas acho que fica estranho. Se eu tivesse que dar manutenção por exemplo, o último esquema em que eu procuraria esses atributos seria no account.

Perfeito, então mudemos o enfoque e, ao invés de um schema com atributos de usuários, pensemos em um schema com atributos do Expresso, em que seriam elencados os atributos que nós precisamos e que não possuem similar nos schemas padrão do LDAP, seja para usuários, grupos, OU, etc, para esses casos, os schemas existentes (inetOrgPerson, Core, etc) já cobrem a grande maioria das necessidades, o que acha?

Hum... Ficaria legal sim, mas acho que eu pensei em algo que modifica menos a estrutura. O que você acha de criar um esquema novo, com um objectClass tipo quotacontrolled(ou algo do gênero) aonde os objetos que seriam controlados por quota(as OU's) herdassem essa classe de objetos, mantendo o phpgwaccount apenas para contas e retirando ele das OU's? Assim não nos preocuparíamos com o phpgwaccount e aproveitamos para tirar isso das ous, que alias, não consegui ver o motivo de OUs herdarem esse objectClass.

É verdade, phpgwaccount deveria ser para contas de usuários... O único senão é que teríamos mais uma objectClass "pendurada" no LDAP; abstraindo-se esse senão, essa opção é uma boa, já que os atributos ficam separados em suas classes, em termos de organização fica melhor mesmo.

É isso aí, acho que assim tá bom. Ainda não tá no instalador, né?

[diogenesduarte]

Não, ainda estou vendo como fazer uma OU herdar obrigadoriamente um objectClass, alguém tem uma dica de como se faz isso? Tava pensando também se essa mudança não influenciaria os expressos já instalados...

[diogenesduarte]

Resolvido em [3850] e [3851]. Agora existe um novo esquema chamado phpgwquotacontrolled para classes que possuem controle de quotas. Adicionado o esquema no instalador, e modificado a classe de salvar ous, para adicionar o objectClass caso ele não exista e seja necessário.

Para quem já tinha o expresso instalado e já utilizava o controle de quotas, basta mudar o código e não será necessário mudança no ldap. Quem tinha instalado e nunca configurou o ldap para aceitar os dois atributos necessários para o controle de quotas, basta adicionar o esquema phpgwquotacontrolled.schema em seu ldap. Esse arquivo encontra-se na pasta do instalador.

[eduardoalex]

Replying to diogenesduarte:

Resolvido em [3850] e [3851]. Agora existe um novo esquema chamado phpgwquotacontrolled para classes que possuem controle de quotas. Adicionado o esquema no instalador, e modificado a classe de salvar ous, para adicionar o objectClass caso ele não exista e seja necessário.

Para quem já tinha o expresso instalado e já utilizava o controle de quotas, basta mudar o código e não será necessário mudança no ldap. Quem tinha instalado e nunca configurou o ldap para aceitar os dois atributos necessários para o controle de quotas, basta adicionar o esquema phpgwquotacontrolled.schema em seu ldap. Esse arquivo encontra-se na pasta do instalador.

É interessante que essas informações estejam disponíveis no wiki referente a atualização para a versão 2.2.0

[joaquim.ferraz]

Que maravilha. Iremos iniciar testes com essa "feature".

[alexandrecorreia]

Revisão [3933] - Inserido o schema de controle de quotas no instalador do Debian Squezee.