Ticket #419 (closed melhoria: fixed)

Opened 11 years ago

Last modified 9 years ago

Controle de Cotas de usuário e disco

Reported by: diogenesduarte Owned by: diogenesduarte
Priority: alta Milestone: Expresso 2.2
Component: ExpressoAdmin Version: branch 2.2
Severity: média Keywords:
Cc: WorkGroup:

Description

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'.

Attachments

phpgwaccount.schema Download (7.0 KB) - added by rommelcysne 9 years ago.
phpgwaccount.schema

Change History

comment:1 Changed 11 years ago by wmerlotto

  • Version changed from 1.0 to Trunk (trunk)
  • Milestone set to Expresso 2.1

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

comment:2 Changed 11 years ago by wmerlotto

  • Type changed from tarefa to melhoria

comment:3 follow-up: ↓ 4 Changed 11 years ago by niltonneto

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

comment:4 in reply to: ↑ 3 Changed 11 years ago by 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...

comment:5 Changed 10 years ago by diogenesduarte

  • Owner changed from alguem to 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?

comment:6 Changed 10 years ago by 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.

comment:7 Changed 10 years ago by niltonneto

  • Milestone changed from Expresso 2.1 to Expresso 2.2

comment:8 follow-up: ↓ 9 Changed 10 years ago by diogenesduarte

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

comment:9 in reply to: ↑ 8 Changed 10 years ago by 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?

comment:10 Changed 10 years ago by 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.....

comment:11 follow-up: ↓ 12 Changed 10 years ago by 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.

comment:12 in reply to: ↑ 11 ; follow-up: ↓ 15 Changed 10 years ago by 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.

comment:13 follow-up: ↓ 14 Changed 9 years ago by rommelcysne

  • Severity set to média

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.

Changed 9 years ago by rommelcysne

phpgwaccount.schema

comment:14 in reply to: ↑ 13 ; follow-up: ↓ 16 Changed 9 years ago by 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.

comment:15 in reply to: ↑ 12 Changed 9 years ago by 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.

comment:16 in reply to: ↑ 14 ; follow-up: ↓ 17 Changed 9 years ago by 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?

comment:17 in reply to: ↑ 16 ; follow-up: ↓ 20 Changed 9 years ago by 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.

comment:18 Changed 9 years ago by zapa

Anexa ai o novo esquema...

comment:19 Changed 9 years ago by eduardoalex

  • Priority changed from média to alta
  • Version changed from trunk to branch 2.2

Diógenes,

Favor colocar no instalador...

comment:20 in reply to: ↑ 17 Changed 9 years ago by 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é?

comment:21 Changed 9 years ago by 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...

comment:22 follow-up: ↓ 23 Changed 9 years ago by diogenesduarte

  • Status changed from new to closed
  • Resolution set to fixed

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.

comment:23 in reply to: ↑ 22 Changed 9 years ago by 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

comment:24 Changed 9 years ago by joaquim.ferraz

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

comment:25 Changed 9 years ago by alexandrecorreia

  • Status changed from closed to reopened
  • Resolution fixed deleted

comment:26 Changed 9 years ago by alexandrecorreia

  • Status changed from reopened to closed
  • Resolution set to fixed

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

Note: See TracTickets for help on using tickets.