MSN-Proxy

O msn-proxy é um proxy transparente para clientes MSN Mensenger que permite que você controle e monitore o uso do Messenger em sua rede. Possui as seguintes características:

• Suporte ao novo protocolo P2P
• Suporte a acls: “*mycompany@hotma*”
• Suporte a listas de permissões através de ACLs
• Suporte a envio de mensagens de controle
• Suporte a remover/adicionar usuários
• Suporte a procura por logs de usuários
• Suporte a remoção de logs de usuários
• Sistema de visualização de logs de usuários
• Suporte Messenger 9
• Monitor em tempo real

Link com how to para instalação: AQUI

GLPI

Software opensource para gerenciamento de serviços de TI com sistema helpdesk.

Site: http://www.glpi-project.org/

Roda em Linux. Usa Mysql e php5.

Buscando e apagando arquivos e diretórios vazios

Buscar arquivos e diretórios vazios e apagar:

$find . -empty -exec rm -ri {} \;

Buscar arquivos vazios e apagar:

$find . -empty -type f -exec rm -ri {} \;

Buscar diretórios vazios e apagar:

$find . -empty -type d -exec rm -ri {} \;

histórico do bash entre múltiplas sessões

Para fazer com que a shell bash acrescente imediatamente, ao arquivo do histórico, os comandos executados em todas as sessões especificamos no arquivo .bashrc, a seguinte diretiva:

history -a

Histórico de comandos - OpenBSD

O OpenBSD vem com o histórico de comandos desabilitado por padrão, para habilitar é só fazer o seguinte:

Editar o arquivo ~/.profile e adicionar:

export HISTFILE=~/.history

Fazer logoff e logar novamente.

Identificando o SO através do PING

Com o comando ping podemos identificar o Sistema Operacional utilizado.

O comando ping trabalha com o protocolo ICMP enviando mensagens. Quando uma maquina de destino recebe um Echo Request ela retorna um Echo Reply.

Para descobrir qual Sistema Operacional está sendo utilizado vamos usar o TTL (Time to Live). Este valor indica quanto tempo o pacote vai ficar circulando antes de ser descartado.

Cada Sistema Operacional trabalha com um TTL padrão e desta forma podemos identificar o tipo de sistema.

Exemplo1.

$ ping 127.0.0.1

PING 127.0.0.1 bytes of data.

64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.028 ms

64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.030 ms

64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.029 ms

Exemplo2.

$ ping 127.0.0.1

PING 127.0.0.1 bytes of data.

64 bytes from 127.0.0.1: icmp_seq=1 ttl=128 time=0.176 ms

64 bytes from 127.0.0.1: icmp_seq=2 ttl=128 time=0.183 ms

64 bytes from 127.0.0.1: icmp_seq=3 ttl=128 time=0.189 ms

Representamos na tabela abaixo o valor padrão do TTL para alguns sistemas operacionais:

Sistema TTL

UNIX 255

Linux 64

Windows 128

Com estes números já podemos determinar o Sistema Operacional dos exemplos acima. No caso do Exemplo1 o ttl=64 nos diz que o sistema utilizado é Linux, e para o Exemplo2 podemos dizer que o sistema usado é Windows.

Os roteadores estão programados para decrementar o TTL a cada pacote que passa por ele. Se uma maquina Windows for "pingada" e o valor TTL for 126 significa que antes de chegar ao destino existem 2 roteadores.

DNS Forward

Como fazer com que seu servidor de DNS faça forward para outro servidor através de uma VPN:

A situação foi baseada numa VPN entre links da VIVO 3G e da NET Cabo, onde a resolução de nomes foi repassada para o servidor de DNS do outro lado da VPN, ou seja, o tráfego de DNS passaria pela VPN como se fosse tráfego de rede local.

1 - A VPN era entre as seguintes redes 10.2.129.0/24 e 10.2.132.0/24, o servidor de nomes fica na primeira rede, e o seu IP é 10.2.129.252. O servidor DNS da rede 10.2.132.0/24 é o 10.2.132.254 e ele fará forward para o servidor 10.2.129.252;

2 - Configuração do servidor 10.2.129.252:

acl clients {

localnets;

::1;

10.2.131.0/24;

10.2.132.0/24;

};

3 - Configuração do servidor 10.2.132.254:

options {

version ""; // remove this to allow version queries

listen-on { any; };

listen-on-v6 { any; };

empty-zones-enable yes;

allow-recursion { clients; };

query-source address 10.2.132.254;

forward only;

forwarders { 10.2.129.252; 10.2.129.253; };

};

Os comandos pgrep e pkill

Quem é usuário antigo de sistemas Unix e derivados, provavelmente já gastou os dedos digitando coisas como:

  ps -ef | grep rubens 

Mas como tudo no mundo do software livre, em que a ordem é simplificar e economizar tempo, veio alguém e criou os comandospgrep e pkill.

Como o nome mesmo indica, pgrep significa process grep, que na verdade é o comando anterior aglutinado em apenas um. Por exemplo, eu quero descobrir os PID (process id) de todos os programas do usuário rubens associados ao Firefox:

  pgrep -u rubens  firefox   9397 

Se eu quiser matar algum processo, eu posso fazê-lo de forma genérica, eliminando todos os processos, de todos os usuários, ou posso também atuar de forma seletiva:

  pkill firefox 

ou

  pkill -u rubens firefox 

Além de terminar processos, eu posso usar o comando pgrep em combinação com outros. A documentação do programa dá um exemplo interessante, em que o comando pgrep é usado para redefinir a prioridade de um programa:

  renice +4 `pgrep netscape` 

O programa netscape irá rodar exigindo menos recursos da máquina, sendo mais nice :-)

Existem diversas possibilidades, mas as mais comuns e úteis são mesmo as que foram apresentadas. Uma outra diretiva bastante útil, é a diretiva "-l", que faz com que o nome completo do processo seja listado juntamente com sua identificação:

  $ pgrep -l ssh   1407 ssh-agent   2204 sshd   8162 ssh 

Os programas pgrep e pkill fazem parte do pacote procps e podem ser instalados, em sistemas Debian e derivados, com o comando:

  apt-get install procps

Migrar Controlador de Dominio para outro Servidor

iniciar >> executar >> cmd >> ntdsutil

roles

connections

connect to server servidor.dominio.xxx - servidor que receberá as funções

q

transfer RID master

transfer PDC

transfer infrastructure master

transfer schema master

transfer domain naming master

Twitter

Follow me

Lançamento: OpenBSD 4.6

Nova versão do OpenBSD:

Site OpenBSD

Anti-virus gratuito da Microsoft

Microsoft Security Essentials

Clique Aqui

Atualização OpenBSD 4.4 para 4.5 remotamente

Guia para atualização do OpenBSD 4.4 para o 4.5 remotamente:

The upgrade process

Upgrading without install kernel

Place install files in a "good" location

/openbsd/4.5

Stop any appropriate applications:

Verificar o MD5

Install new kernel(s)

export RELEASEPATH=/openbsd/4.5

cd ${RELEASEPATH}

rm /obsd ; ln /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd

cp bsd.rd bsd.mp /

Remove old X modules: These will be replaced with new ones shortly:

rm -rf /usr/X11R6/lib/modules/*

Save yourself a copy of the old reboot(1) command: You are still running the old kernel, it

is possible the new reboot command will not run on the old kernel.

cp /sbin/reboot /sbin/oreboot

Install new userland applications. Do NOT install etc45.tgz and xetc45.tgz now, because that

will overwrite your current configuration files! Note that we are installing base45.tgz LAS

T, because it will include a new tar(1) utility, which may or may not run on the old kernel.

We reboot immediately, as the system is probably barely runnable now.

tar -C / -xzphf comp45.tgz

tar -C / -xzphf game45.tgz

tar -C / -xzphf man45.tgz

tar -C / -xzphf misc45.tgz

tar -C / -xzphf xbase45.tgz

tar -C / -xzphf xfont45.tgz

tar -C / -xzphf xserv45.tgz

tar -C / -xzphf xshare45.tgz

tar -C / -xzphf base45.tgz

/sbin/oreboot

Again, the files in /etc are handled separately below, so etc45.tgz and xetc45.tgz are NOT u

npacked here.

After reboot completes, upgrade /dev. The new MAKEDEV file was copied to /dev by the install

ation of base45.tgz, so you simply need to do the following:

cd /dev

./MAKEDEV all

sysmerge -as $RELEASEPATH/etc45.tgz -x $RELEASEPATH/xetc45.tgz

newaliases

mtree -qdef /etc/mtree/4.4BSD.dist -p / -u

Lançamento: OpenBSD 4.5

Nova versão do Sistema Operacional OpenBSD.

http://www.openbsd.org/45.html

LDAP: Excluindo atributos

Para excluir um atributo de uma entrada no diretório LDAP é so fazer o seguinte:

1 - Fazer um ldapsearch para pegar o DN da entrada que se quer deletar o atributo:

ldapsearch -D 'cn=Manager,o=DOMINIO,c=BR' -w xxxxx -x -b 'ou=hosting,o=DOMINIO,c=BR' uid=mail@dominio.com.br

dn: uid=mail@dominio.com.br,ou=hosting,o=DOMINIO,c=BR

2 - Usar  o comando ldapmodify para excluir o atributo desejado: nesse  caso iremos excluir o atributo deliveryMode:

ldapmodify -D 'cn=Manager,o=DOMINIO,c=BR' -w xxxxx -x

dn: uid=mail@dominio.com.br,ou=hosting,o=DOMINIO,c=BR

delete: deliveryMode

Pronto, atributo excluido.

access.log Squid

O que significa as informações do access.log do squid:

Seu formato é:

time elapsed remotehost code/status bytes method URL rfc931 peerstatus/peerhost type

Therefore, an access.log entry usually consists of (at least) 10 columns separated by one ore more spaces:

1. time A Unix timestamp as UTC seconds with a millisecond resolution. You can convert Unix timestamps into something more human readable using this short perl script:

   • s/^\d+\.\d+/localtime $&/e;

2. duration The elapsed time considers how many milliseconds the transaction busied the cache. It differs in interpretation between TCP and UDP:

   • For HTTP this is basically the time from having received the request to when Squid finishes sending the last byte of the response.
   • For ICP, this is the time between scheduling a reply and actually sending it.
     

     • Please note that the entries are logged after the reply finished being sent, not during the lifetime of the transaction.

3. client address The IP address of the requesting instance, the client IP address. The client_netmask configuration option can distort the clients for data protection reasons, but it makes analysis more difficult. Often it is better to use one of the log file anonymizers. Also, the log_fqdnconfiguration option may log the fully qualified domain name of the client instead of the dotted quad. The use of that option is discouraged due to its performance impact.

4. result codes This column is made up of two entries separated by a slash. This column encodes the transaction result:

   • The cache result of the request contains information on the kind of request, how it was satisfied, or in what way it failed. Please refer toSquid result codes for valid symbolic result codes. Several codes from older versions are no longer available, were renamed, or split. Especially the ERR_ codes do not seem to appear in the log file any more. Also refer to Squid result codes for details on the codes no longer available. The status part contains the HTTP result codes with some Squid specific extensions. Squid uses a subset of the RFC defined error codes for HTTP. Refer to section status codes for details of the status codes recognized.

5. bytes The size is the amount of data delivered to the client. Mind that this does not constitute the net object size, as headers are also counted. Also, failed requests may deliver an error page, the size of which is also logged here.

6. request method The request method to obtain an object. Please refer to section request-methods for available methods. If you turned offlog_icp_queries in your configuration, you will not see (and thus unable to analyze) ICP exchanges. The PURGE method is only available, if you have an ACL for "method purge" enabled in your configuration file.

7. URL This column contains the URL requested. Please note that the log file may contain whitespace for the URI. The default configuration foruri_whitespace denies or truncates whitespace, though.

8. rfc931 The eighth column may contain the ident lookups for the requesting client. Since ident lookups have performance impact, the default configuration turns ident_loookups off. If turned off, or no ident information is available, a "-" will be logged.

9. hierarchy code The hierarchy information consists of three items:

   • Any hierarchy tag may be prefixed with TIMEOUT_, if the timeout occurs waiting for all ICP replies to return from the neighbours. The timeout is either dynamic, if the icp_query_timeout was not set, or the time configured there has run up.

   • A code that explains how the request was handled, e.g. by forwarding it to a peer, or going straight to the source. Refer to Hierarchy Codesfor details on hierarchy codes and removed hierarchy codes.

   • The IP address or hostname where the request (if a miss) was forwarded. For requests sent to origin servers, this is the origin server's IP address. For requests sent to a neighbor cache, this is the neighbor's hostname. NOTE: older versions of Squid would put the origin server hostname here.

10. type The content type of the object as seen in the HTTP reply header. Please note that ICP exchanges usually don't have any content type, and thus are logged "-". Also, some weird replies have content types ":" or even empty ones.

Verificando Hosts ativos na rede

Com os softwares nmap e awk, com apenas uma linha de código, eu consigo gerar um relatório sobre os computadores que estão ativos em uma rede:


 nmap -sP 192.168.0.1-254 | awk '/up/ {print $2 " ativo"}'


O mais interessante da solução acima é o fato de ser em uma linha ao contrário de algo como:


 for((i=1; i <= 255; i++)); do
  if ! ping -c 2 192.168.0.$i ; then
     echo "192.168.1.$i não respondeu $1 " >> falhou.txt
  else
     echo "192.168.1.$i respondeu $1 " >> respondeu.txt
  fi
 done

Oracle: Backup com RMAN

Primeiro verificamos a consistência dos archivelogs com o seguinte comando:

RMAN>crosscheck archivelog all;

Podemos até apagar alguns que estejam espirados:

RMAN>delete expired archivelog all;

Ou até mesmo forçar a exclusão de a partir de alguma data:

RMAN>delete force archivelog until time 'sysdate - 5';

Dessa forma estemos pronto pra fazer o backup do banco:

RMAN>backup database plus archivelog;

Para visualizar os backups:

RMAN>list backup;

RMAN>list backup summary;

RMAN>list backup by file;

Guia p/ Atualização do OpenBSD 4.3 p/ 4.4

Bem, eu uso esse guia a mais de 4 anos, para atualização em firewalls remotos, e nunca me deixou na mão...

Install new kernel:

export RELEASEPATH=/openbsd/4.4

cd ${RELEASEPATH}

rm /obsd ; ln /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd

cp bsd.rd bsd.mp /

Install new /etc/firmware files and /sbin/ifconfig utility:

tar -C / -xzphf ${RELEASEPATH}/base44.tgz ./etc/firmware ./sbin/ifconfig

Reboot on the new kernel:

Install new userland applications. 

export RELEASEPATH=/openbsd/4.4

cd ${RELEASEPATH}

tar -C / -xzphf base44.tgz

tar -C / -xzphf comp44.tgz

tar -C / -xzphf game44.tgz

tar -C / -xzphf man44.tgz

tar -C / -xzphf misc44.tgz

tar -C / -xzphf xbase44.tgz

tar -C / -xzphf xfont44.tgz

tar -C / -xzphf xserv44.tgz

tar -C / -xzphf xshare44.tgz

Upgrade /dev.

cd /dev

./MAKEDEV all

Upgrade /etc as below:

cd ${RELEASEPATH}

[ -d /tmp/newroot ] && rm -rf /tmp/newroot

mkdir /tmp/newroot

tar -C /tmp/newroot -xzpf etc44.tgz

tar -C /tmp/newroot -xzpf xetc44.tgz

mergemaster -r -t /tmp/newroot

newaliases

mtree -qdef /etc/mtree/4.4BSD.dist -p / -u

reboot

Colocar o link favorito abaixo:

export PKG_PATH=

pkg_add -ui -F update -F updatedepends

Lançamento: OpenBSD 4.4

Hoje foi lançanda a mais nova versão do OpenBSD, a versão 4.4, confira no site: www.openbsd.org