Proc: Intel Xeon E5520

1. compile nginx on centos using passenger-install-nginx-module
2. nginx’s init script – ripped from EPEL
3. nginx.conf with gzip compression enhanced

Please, note we’ve installed upstream-fair module. This module sends an incoming request to the least-busy backend server, rather than distributing requests round-robin.

Ao utilizar o bash, todos os comandos digitados são salvos no arquivo ~/.bash_history, por ser o arquivo carregado na variável de ambiente HISTFILE. Da mesma forma que esta variável está declarada, nós podemos não declará-la utilizando unset, como em

[root@mx2 ~]# history | tail -n 5
  188  chmod 0600 .ssh/authorized_keys
  189  history
  190  history | wc -l
  191  history | tail
  192  history | tail -n 5
[root@mx2 ~]# unset HISTFILE
[root@mx2 ~]# echo '' > z
[root@mx2 ~]#

A partir do echo todos os comandos não serão salvos no history, e ficarão perdidos em algum universo paralelo.

Ainda poderemos limpar o history, como em

[root@mx2 ~]# history | wc -l
189
[root@mx2 ~]# history -c
[root@mx2 ~]#
[root@mx2 ~]# history | wc -l
1

Ou também deletar o arquivo que guarda o histórico, perdendo já completamente a noção:

[root@mx2 ~]# rm -f .bash_history

Na manha? Não quero perder o histórico. Não quero que limpem ou apaguem ele também. Bem, vamos lá!

O primeiro passo é colocar a variável HISTFILE em modo readonly, desta forma não sendo possível unsetá-la. Para isto, editaremos o arquivo informado a seguir e atribuiremos permissão de execução:

[root@mx2 ~]# cat /etc/profile.d/bash_variables.sh
readonly HISTFILE
readonly HISTFILESIZE
readonly HISTIGNORE
readonly HISTSIZE
[root@mx2 ~]# chmod +x /etc/profile.d/bash_variables.sh

Ao re-logar na máquin, receberemos este aviso ao tentar unsetar a variável:

[root@mx2 ~]# unset HISTFILE
-bash: unset: HISTFILE: cannot unset: readonly variable

Perfeito! Agora temos um começo. No entanto isto apenas coloca a variável em modo de leitura, e não previne que limpem ou removam o arquivo de histórico.

Para que não removam o arquivo, precisaremos mudar os atributos do arquivo, colocando-o em modo para só receber informações, e nada mais, como em

[root@mx2 ~]# chattr +a .bash_history

Não teremos sucesso se tentarmos apagar o arquivo:

[root@mx2 ~]# rm -f .bash_history
rm: cannot remove `.bash_history': Operation not permitted

É outro passo, mas não impede de limparmos o histórico ainda:

[root@mx2 ~]# history
    1  rm -f .bash_history
    2  vim /etc/profile/bash_variables.sh
    3  vim /etc/profile.d/bash_variables.sh
    4  cat /etc/profile.d/bash_variables.sh
    5  chmod +x /etc/profile.d/bash_variables.sh
    6  unset HISTFILE
    7  chattr +a .bash_history
    8  rm -f .bash_history
    9  history
[root@mx2 ~]# history -c
[root@mx2 ~]# history
    1  history
[root@mx2 ~]#

E agora? Precisamos de outro arquivo de history, contendo as reais informações. Para isto, iremos alterar a variável PROMPT_COMMAND, que será carregada no bash_profile local, informando um arquivo alternativo – o ~/.real_bash_history. O arquivo ~/.bash_profile receberá a flag imutável, para não ser alterado:

[root@mx2 ~]# touch .real_bash_history
[root@mx2 ~]# chattr +a .real_bash_history
[root@mx2 ~]# vim .bash_profile
[root@mx2 ~]# chattr +i .bash_profile
[root@mx2 ~]# cat .bash_profile
# .bash_profile
 
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
	. ~/.bashrc
fi
 
# User specific environment and startup programs
export PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ; }"'echo $$ $USER "$(history 1)" >> ~/.real_bash_history'
readonly PROMPT_COMMAND
 
PATH=$PATH:$HOME/bin
 
export PATH
unset USERNAME

Ao logar novamente na máquina, por mais que o arquivo de histórico seja limpo, as informações ficarão guardadas no real_bash_history, como em:

[root@mx2 ~]# cat .real_bash_history
1951 root     5  chmod +x /etc/profile.d/bash_variables.sh
1951 root     6  history
1951 root     7  usnet HISTFILE
1951 root     8  unset HISTFILE
1951 root     9  rm -rf .bash_history
1951 root    10  history
1951 root
1951 root     1  history
[root@mx2 ~]# rm -rf .bash_profile
rm: cannot remove `.bash_profile': Operation not permitted
[root@mx2 ~]# rm -rf .real_bash_history
rm: cannot remove `.real_bash_history': Operation not permitted

E agora, zézão?

Depois do yum -y install pen (disponível no EPEL), basta um

[root@m ~]# pen -l /var/log/pen.log -p /var/run/pen.pid -r 25001 x.x.x.x:25 y.y.y.y:25 w.w.w.w:25 z.z.z.z:25

E pronto! O suporte a arquivos de configuração (man penctl) ajuda bastante para iniciar. Guardar o pid do daemon pra verificar com o monit ajuda demais também.

Mais aqui.

Numa boa? Sem o debconf-get-selections demoraria para escrever na unha o arquivo usado na instalação.

Ah, Kickstart…

O find (man find) tem algumas coisas bem úteis. Por exemplo, você pode buscar por arquivos, por diretórios, por links simbólicos, pelo nome do arquivo sem diferenciar maiúsculas e minúsculas – lembrando que sistemas *NIX são case sensitive, etc.

A sintaxe do find é:

find caminho expressao

O caminho é onde você quer procurar, sendo relativo ou absoluto. Agora, com a expressão, podemos fazer as coisas legais. A expressão -type no diz de que tipo é o arquivos, veja:

find ./ -type f
find ./ -type d
find ./ -type l

Os três comandos acima buscariam, a partir do diretório em que você está, por arquivos, diretórios e links simbólicos, respectivamente.

Agora, para casar o tipo do arquivo com o nome, são usadas os parâmetros -name ou -iname (ignore case):

find ./ -name "nome" -type f
find ./ -iname "*nom?.backup" -type d

E aquele asterisco? E a interrogação? É possível utilizar os metacaractéres do shell. Isto, os wildcards, os coringas. Os mesmos que você usaria num ls da vida.

Suponhamos que você tem a seguinte estrutura de diretórios:

./a/d1
./a/d2
./a/d3
./b/d
./c/d1
./c/d2
./c/d3
./c/d4
./d/d
./e/

Os diretórios representados por letras são grupos, e dentro temos as categorias de cada grupo. O que eu preciso saber é quantas categorias (diretórios) de grupo existem, sem contar os diretórios dentro das categorias . E agora? Temos os parâmetros -mindepth e -maxdepth. Eles especificam o nível mínimo e máximo para realizar a busca. Neste caso:

find ./ -mindepth 2 -maxdepth 2 -type d

Explicando melhor:

• o nível 0 casa com a linha de comando, ou seja, o ./
• o nível 1 casa os nomes de grupo, como ./a e ./b
• o nível 2 casa o que eu quero, que são as categorias, como ./a/1 e ./a/2
• se usasse apenas o -mindepth 2, a busca continuaria dentro dos diretórios, porque eu disse apenas de onde queria começar a busca, e por isso o -maxdepth é necessário

Outras iterações virão em breve. Até