Integração Moodle/Joomla
JFusion – http://www.jfusion.org/
Módulos Moodle:
Authentication Method: Joomla – http://moodle.org/mod/data/view.php?d=13&rid=973&filter=1
Integration: Joomdle – http://moodle.org/mod/data/view.php?d=13&rid=3344&filter=1
JFusion – http://www.jfusion.org/
Módulos Moodle:
Authentication Method: Joomla – http://moodle.org/mod/data/view.php?d=13&rid=973&filter=1
Integration: Joomdle – http://moodle.org/mod/data/view.php?d=13&rid=3344&filter=1
Substituir todas as ocorrências de “CHARSET=latin1” por “CHARSET=utf8”:
:%s/CHARSET=latin1/CHARSET=utf8/g
Pelos vistos o wordpress não funciona com o modsecurity2. A solução passa por desactivar o modsecurity2 para o site através do .htaccess
<IfModule mod_env.c> SetEnv MODSEC_ENABLE Off PassEnv MODSEC_ENABLE </IfModule>-bash-3.2# service httpd start A iniciar o httpd: (98)Address already in use: make_sock: could not bind to address [::]:80 (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down Unable to open logs -bash-3.2# lsof -i :80 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME perl 24082 apache 4u IPv6 77043797 TCP *:http (LISTEN) [init] 24093 apache 4u IPv6 77043797 TCP *:http (LISTEN) -bash-3.2# kill -9 24082 -bash-3.2# kill -9 24093 -bash-3.2# service httpd start A iniciar o httpd: [ OK ]
Quando este tipo de situação ocorre normalmente significa que o servidor foi comprometido. Neste exemplo é possível verificar que existe um processo a correr na porta 80 iniciado como utilizador apache pelo perl. Estava a correr uma aplicação (trojan) para realizar scans a outros servidores.
1. Em todas as secções de HTML independentemente da cor que se utilize (excepto o preto) e tamanho de fonte que se selecione, após fechar o modo de edição aparece tudo a negro e com um tamanho predefinido.
A solução para resolver este problema passa por desactivar o filtro Tidy (Módulos -> Filtros -> Configuração dos filtros).
Tidy - This filter checks whether HTML code is XHTML compliant, tidying where necessary. To make this filter work you need to have PHP compiled with the libtidy option; see http://www.php.net/tidy. The Using Moodle discussion Tidy Filter for Moodle 1.5 contains more details.
2. No modo de visualização as seccções de HTML (etiquetas, secções de tópico, etc.) que contém um titulo igual ao nome de uma actividade ou de um recurso “perdem” a formatação (e assumem uma formatação predefinida) e contém um link para a actividade/recurso.
Para resolver este problema desactivam-se os filtros (Módulos -> Filtros -> Configuração dos filtros) Auto-apontar para actividades e Auto-apontar para recursos.
Se a tab Partilha desapareceu das propriedades das pastas, deve-se verificar se os serviços Servidor e Browser do Computador estão activos.
Se mesmo assim não funcionar, tentar executar (Start -> Run)
"regsvr32 rshx32.dll"
1 – Reparar a base de dados
2 – Alterar configurações das estatísticas e executar o cron
Intervalo de processamento: Todos
Tempo máximo de execução: Até estar completo
Executar em: 1:00
3 – Consultar o último registo das tabelas mdl_stats_daily, mdl_stats_weekly e mdl_stats_monthly e tirar a última data processada. Pegar nessas datas e alterar os campos no mdl_config. Forçar a execução do cron e os dados são processados
SELECT MAX(timeend) FROM `mdl_stats_daily`
SELECT MAX(timeend) FROM `mdl_stats_weekly`
SELECT MAX(timeend) FROM `mdl_stats_monthly`
SELECT MAX(timeend) FROM `mdl_stats_user_daily`
modificar:
– statslastexecution
– statsrunning
Verificar nas configurações da disciplina se a opção “Restringir módulos de actividades?” está como Sim. Deve estar como Não!
Com esta opção como Sim, independentemente do cargo do utilizador ele nunca consegue adicionar uma actividade ou um recurso.
Verificar também se em Segurança -> Segurança de Módulos a opção Restringir módulos para está como No courses. De outra forma qualquer disciplina nova terá todos os módulos bloqueados por defeito.
UPDATE:
Actualizações das regras aqui: http://sourceforge.net/projects/mod-security/files/modsecurity-crs/0-CURRENT/
O mod_security é útil para proteger o Apache contra diversos tipos de ataques a aplicações web, agindo como uma camada de protecção.
Para realizar a instalação do mod_security no CentOS existem duas formas, compilar o código-fonte ou instalar o pacote binário do repositório EPEL (Extra Packages for Enterprise Linux). Neste guia vamos instalar o pacote binário.
Caso não possua o repositório EPEL activado no seu sistema, instale-o com o comando abaixo:
Versão 32 bits
# rpm −Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel−release−5−4.noarch.rpm
Versão 64 bits
# rpm −Uvh http://download.fedora.redhat.com/pub/epel/5/x86_64/epel−release−5−4.noarch.rpm
Antes de instalar o pacote do mod_security no meu ambiente (CentOS 5.4 64 bits) foi necessário instalar o pacote lua, portanto, caso encontre erros de dependência da biblioteca liblua-5.1.so durante a instalação execute o comando abaixo:
# rpm −ivh http://mirrors.kernel.org/fedora−epel/5Server/x86_64/lua−5.1.2−1.el5.x86_64.rpm
Instale o pacote do mod_security com o comando abaixo:
# yum install mod_security
O arquivo de configuração principal do mod_security encontra-se em /etc/httpd/conf.d/mod_security.conf, no directório /etc/httpd/modsecurity.d/ encontram-se todos os outros arquivos de configuração do mod_security incluindo o arquivo /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf que deve ser ajustado de acordo com as suas necessidades.
Os arquivos de log encontram-se em /var/log/httpd/modsec_debug.log e em /var/log/httpd/modsec_audit.log.
Após a instalação verifique no arquivo /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf se a opção SecRuleEngine está On:
# vim /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf SecRuleEngine On
Agora basta reiniciar o serviço com o comando abaixo:
# service httpd restart
Nos logs do Apache pode ser verificado se o módulo foi devidamente carregado:
# tail -f /var/log/httpd/error_log [Tue Dec 15 20:34:35 2009] [notice] caught SIGTERM, shutting down [Tue Dec 15 20:34:44 2009] [notice] SELinux policy enabled; httpd running as context root:system_r:httpd_t [Tue Dec 15 20:34:45 2009] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Dec 15 20:34:46 2009] [notice] ModSecurity for Apache/2.5.9 (http://www.modsecurity.org/) configured. [Tue Dec 15 20:34:46 2009] [notice] Original server signature: Apache/2.2.3 (CentOS) [Tue Dec 15 20:34:46 2009] [notice] Digest: generating secret for digest authentication ... [Tue Dec 15 20:34:46 2009] [notice] Digest: done [Tue Dec 15 20:34:47 2009] [notice] Apache/2.2.0 (Fedora) configured -- resuming normal operations
E após algumas tentativas segue um exemplo do mod_security em ação:
# tail -f /var/log/httpd/error_log [Tue Dec 15 18:29:21 2009] [error] [client XX.XX.XX.XX] ModSecurity: Warning. Match of "rx ModSecurity" against "WEBSERVER_ERROR_LOG" required. [ile "/etc/httpd/modsecurity.d/modsecurity_crs_21_protocol_anomalies.conf"] [line "65"] [id "960913"] [msg "Invalid request"] [severity "CRITICAL"] [hostname "meu.site.com"]
Depois foi necessário definir o SecDataDir na configuração. Isto não estava definido inicialmente e surgiam erros nos logs.
ModSecurity: Unable to retrieve collection (name "", key ""). Use SecDataDir to define data directory first.
Este erro foi corrigido adicionando a directiva SecDataDir e criando um directório para este propósito, dando permissões ao apache para escrita.
# vim /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf ( Added SecDataDir /usr/local/apache/modsec_data ) mkdir /usr/local/apache mkdir /usr/local/apache/modsec_data chown apache:apache /usr/local/apache/modsec_data chown apache:apache /usr/local/apache
Depois de reiniciar o serviço o modsecurity começou a aplicar as regras, mas em vez de bloquear os pedidos, simplesmente registava os avisos. Alterei a SecDefaultAction em
# vim /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf SecDefaultAction "phase:2,pass"
para
SecDefaultAction "phase:2,deny,log,status:403"
Fonte: http://www.cyberciti.biz/faq/rhel-fedora-centos-httpd-mod_security-configuration/
Fonte: http://devinvenable.blogspot.com/2010/04/modsecurity-setup-on-centos-54.html
Ex: Pesquisar ficheiros com mais de 100MB
find . -type f -size +100000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'
Percorre todas as subpastas do /home/teste/moodledata e move todos ficheiros com o nome backup.zip para a pasta /backupdisc/backupdata/teste
find /home/teste/moodledata -iname '*backup-*.zip' -exec /bin/mv '{}' /backupdisc/backupdata/teste \;
find /home/escola-m/moodledata -iname 'backup-*.zip' -exec /bin/mv '{}' /home/escola-m/backupdata \;
This gives you a list of the 25 largest directories
du -xk | sort -n | tail -25 du -dk | sort -n | tail -25
Lista o tamanho de todas as pastas dentro do moodledata
du -h --max-depth=1 /home/site/moodledata
Lista o tamanho de todas as pastas dentro do moodledata ordenadas por tamanho
du -h --max-depth=1 /home/site/moodledata | sort -n -r
Pesquisa útil para encontrar ficheiros corrompidos pela actualização CVS
find /home/xxx/moodle/ -iname '.#*.php*'
Contar o nº de ficheiros num diretório
ls -1 targetdir | wc -l
Pesquisar ficheiros do utilizador apache com a extensão .php
find /home/user/public_html/ -user apache -name "*.php"
Lista todos os ficheiros do diretório atual que tiverem mais de 200MB
find . -type f -size +200M -exec ls -lh {} \;