O Segredo Extraordinário do Comando 'cal' no Linux

No dia a dia da administração de sistemas Linux e bancos de dados, vivemos imersos em comandos complexos, scripts de automação e monitoramento de performance. No meio de tanta complexidade, utilitários clássicos e minimalistas acabam sendo subestimados. Um dos maiores exemplos disso é o comando cal.

A maioria dos profissionais digita apenas cal no terminal para dar uma olhada rápida no mês atual. Mas este pequeno utilitário esconde truques de produtividade e um rigor histórico impressionante.

Exemplos Práticos que Poucos Usam

Antes de irmos para o segredo extraordinário deste comando, aqui estão algumas flags que deveriam estar no seu cinto de utilidades:

• cal -3 : Mostra o mês anterior, o atual e o próximo lado a lado. Excelente para planejar janelas de manutenção que viram o mês.
• cal -y : Exibe o calendário do ano inteiro atual na sua tela.
• cal 2026 : Exibe o calendário completo de um ano específico do futuro (ou do passado).
• cal -j : Mostra o calendário no formato "Juliano" (dia do ano de 1 a 365). Muito útil para DBAs que precisam cruzar dados com logs de banco de dados que usam esse formato de data.
• ncal -e 2025 : (Usando a variação ncal) Calcula e mostra exatamente a data da Páscoa de qualquer ano.

O Segredo Extraordinário: O Mês que Perdeu 11 Dias

O Unix é famoso por sua precisão, e o comando cal leva isso ao extremo da precisão histórica. Se você quer ver algo que surpreende até os Sysadmins mais experientes, abra o seu terminal agora e digite exatamente isso:

$ cal 9 1752

Olhe atentamente para o resultado. Você notará que o mês de setembro de 1752 pula do dia 2 diretamente para o dia 14! Faltam 11 dias no calendário.

Isso é um bug? Não! É um recurso de precisão histórica. Em setembro de 1752, o Império Britânico (e suas colônias) finalmente abandonou o Calendário Juliano e adotou o Calendário Gregoriano. Para alinhar as datas com o resto da Europa, o Rei George II ordenou que 11 dias fossem simplesmente apagados da existência. As pessoas foram dormir na noite de 2 de setembro e acordaram na manhã de 14 de setembro.

Os criadores do Unix decidiram que o comando cal deveria refletir a realidade histórica exata, tornando-o não apenas uma ferramenta de TI, mas um pequeno museu digital da história humana.

Conhecimento é a base da infraestrutura

Dominar os fundamentos do sistema operacional é o que diferencia um operador de um verdadeiro Engenheiro de Sistemas. Na AJMSolutions, aplicamos esse mesmo nível de rigor e conhecimento profundo para otimizar e proteger os seus bancos de dados.

Comandos Linux: explorando memória virtual com vmstat

 Uma visão detalhada do comando vmstat, sua sintaxe básica e como usá-lo.

Há muitos comandos, ferramentas e variações dos dois para você colocar em prática quando se trata de estatísticas do sistema no Linux. No entanto, se você precisa de detalhes sobre memória virtual, usar o vmstat é uma ótima opção.

O que é?

O Virtual Memory Statistics Reporter, também conhecido como vmstat, é uma ferramenta de linha de comando do Linux que relata vários bits de informações do sistema. O VMSTAT relata informações sobre processos, memória, paginação, bloco de I/O, traps, discos e atividade da CPU.

Ao executar o vmstat, tenha em mente que as informações são uma média  solicitadas desde o momento da última reinicialização. Relatórios subsequentes usam medições de atraso e contagem. Eu abordo esses especificamente durante a discussão de sintaxe.

Sintaxe do comando

A sintaxe do comando vmstat é bem simples:

$ vmstat [option][delay [count]]

Opções

delay - O delay entre a atualização em segundos. Se o delay não é especificado,  um relatório é impresso com os valores médios desde a última inicialização.

count - Números de atualizações. Na ausência de count, quando o delay é definido, o padrão é infinito.

-a, --active

Exibe a memória ativa ou inativa. 

-f, --forks

O -f exibe o número de foros desde a inicialização. Isso inclui as sytem calls, fork, vfork e é equivalente ao número total de tarefas criadas. Cada processos é representado por uma ou mais tarefas, dependendo do uso do thread. Esta tela não se repete.

-m, --slabs

Exibe o slabinfo.

-n, --one-header

 Exibe o cabeçalho apenas uma vez e não periodicamente.

-s, --stats

Mostra uma tabela de vários contadores de eventos e estatísticas de memória. Esta tela não se repete. 

-d, --disk

Relatório de estatísticas de disco.

-D, --disk-sum

Relata algumas estatísticas resumidas sobre a atividade do disco 

-p, --partition device 

Estatísticas detalhadas sobre as partições.

-s, --unit character 

Altera a saida entre 1000 (k), 1024 (K), 1000000 (m), ou 1048576 (M) bytes. Observe que isso não altera os campos do swap (si/so) ou block (bi/bo).

-t, --timestamp

 Adiciona timestamp para cada linha

-w, --wide

Modo de saída amplo (útil para sistema com maior quantidade de memória, onde o modo de saída padrão sofre de quebra de coluna indesejada). A saída é mais larga que 80 caracteres por linha.

-y, --no-first

 Omite o primeiro relatório com estatísticas desde a inicialização do sistema.

-V, --version

Mostra informação sobre a versão e sai.

-h, --help

 Mostra ajuda e sai.  

Saída básica e como entendê-la:

A forma mais básica deste comando não usa nenhuma opção. Aqui está a saída padrão e como lê-la:

Você vê informações sobre processos, memória, swap, IO, sistema e CPU. A página man para o comando declara o seguinte (man vmstat):

• procs
• r: Número de processos em execução (run queue)
• b: Número de processos em espera (blocked)
• memory (são afetados pela opção --unit)
• swpd: Quantidade de memória virtual usada
• free: Memória livre.
• buff: Memória usada como buffer
• cache: Memória usada como cache
• inact: a quantidade de memória inativa. (opção -a)
• active: a quantidade de memória ativa. (opção -a)
• swap (são afetados pela opção --unit)
• si: Quantidade de memória trocada do disco para a RAM (/s).
• so: Quantidade de memória trocada da RAM para o disco (/s).
• io
• bi: Blocos recebidos do dispositivo de bloco (disco) (KiB/s)
• bo: Blocos enviados para o dispositivo de bloco. (KiB/s)
• system
• in: número de interrupções por segundo, incluindo o clock
• cs: número de alteração de contexto por segundo
• cpu (Essas são porcentagens do tempo total da CPU)
• us: tempo gasto executando código não-kernel. (Tempo do usuário, incluindo tempos bons)
• sy: tempo gasto executando o código do kernel. (tempo do sistema)
• id: tempo gasto ocioso. Antes do Linux 2.5.41, isso inclui o tempo io-wait.
• wa: tempo gasto esperando por I/O. 
• st: tempo roubado de uma máquina virtual. Antes do Linux 2.6.11, desconhecido.
• gu: tempo gasto rodando codigo do KVM guest.

Descrição do campo para o modo disco

• Reads
• total: total de leituras completadas com sucesso
• merged: leituras agrupadas (resultando em um I/O)
• sectors: leituras de setor com sucesso
• ms: milissegundos gasto com leituras
• Writes
• total: total de escritas completadas com sucesso
• merged: escritas agrupadas (resultando em um I/O)
• sectors: leituras de setor com sucesso
• ms: milissegundos gasto com escrita
• IO
• cur: I/O em progresso
• s: segundos gastos com I/O

Descrição de campos para modo de partições de disco

• reads: numero total de leituras para essa partição
• read sectors: total de setor lidos para essa partição
• writes: numero total de escrita para essa partição
• requested writes: numero total de requisição de escrita para a partição

Descrição de campos para o modo SLAB

O modo slab mostra estatísticas por slab, para obter mais informações sobre essas informações, consulte Slabinfo (5)

• cache: nome do cache
• num: numeros concorrentes de objetos ativos
• total: números totais de objetos disponíveis
• size: tamanho de cada objeto
• pages: numero de paginas com pelo menos um objeto ativo

Notas

vmstat requer acesso de leitura para os arquivos abaixo de /proc. O -m requer acesso de leitura a /proc/slabinfo, que pode não estar disponível para usuários padrão. Opções de montagem para /proc, como sub-SET = PID, também podem afetar o que é visível.

Identificação de Gargalos

Para identificar gargalos, observe as seguintes situações:

1. CPU:
1. Se us e sy estão altos, a CPU está sobrecarregada.
2. Se wa está alto, há um gargalo de I/O.
2. Memória:
1. Se free está baixo e si/so estão altos, há falta de memória física, causando troca excessiva (swap).
3. Disco:
1. Se bi e bo estão altos, há muita atividade de disco, indicando um possível gargalo de I/O.

Status e informações sobre o Banco de Dados Oracle

conn sys/oracle as sysdba ou sqlplus sys/oracle as sysdba

Localizar o spfile

SHOW PARAMETER spfile;

no prompt do SO

vi /opt/oracle/product/12cR1/db/dbs/spfileajmsolutions.ora

Diferenciar o tipo de escopo com o SPFILE - SPFILE fica ativo somente em memória

SHOW PARAMETER db_cache_size;

ALTER SYSTEM SET db_cache_size=32m SCOPE=memory;

SHOW PARAMETER db_cache_size;

SHUTDOWN IMMEDIATE;

STARTUP;

SHOW PARAMETER db_cache_size

Diferenciar o tipo de escopo com o SPFILE - SPFILE fica ativo a partir do próximo startup

ALTER SYSTEM SET db_cache_size=32m SCOPE=spile;

SHOW PARAMETER db_cache_size;

SHUDOWN IMMEDIATE;

STARTUP;

SHOW PARAMETER db_cache_size;

Diferenciar o tipo de escopo com o SPFILE - BOTH (fica ativo na memória e a partir do proximo startup

ALTER SYSTEM SET db_cache_size=32m SCOPE=both;

SHOW PARAMETER db_cache_size;

SHUTDOWN IMMEDIATE;

STARTUP;

SHOW PARAMETER db_cache_size;

Alguns parâmetros necessitam de um SHUTDOWN

ALTER SYSTEM SET log_archive_start=true; /*(erro)*/

ALTER SYSTEM SET log_archive_start=true SCOPE=spfile;

ALTER SYSTEM SET sag_max_size=256m SCOPE=spfile;

SHUTDOWN IMMEDIATE;

STARTUP;

SHOW PARAMETER SGA_MAX_SIZE;

SHOW PARAMETER log_archive_start;

Verificar estados do Banco / Mudar os estados do banco

SHUTDOWN IMMEDIATE;

STARTUP NOMOUNT;

SELECT instance_name, host_name
FROM v$instance;

SELECT name, open_mode
FROM v$database; /*(erro)*/

STARTUP MOUNT; /*(erro)*/

ALTER DATABASE MOUNT;

SELECT name, open_mode
FROM v$database;

SELECT owner, table_name
FROM dba_tables
WHERE owner = 'AJMSOLUTIONS'; /*(erro)*/

ALTER DATABASE OPEN;

SELECT owner, table_name
FROM dba_tables
WHERE owner = 'AJMSOLUTIONS';

ALTER DATABASE MOUNT; /*(erro)*/

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

Subir o Banco como somente leitura

ALTER DATABASE OPEN READ ONLY;

CREATE TABLE teste (id number); /*(erro)/

SHUTDOWN IMMEDIATE;

STARTUP;

CREATE TABLE teste (id number);

Subir Banco em modo restrito 

conn sys/oracle as sysdba;

SHUTDOWN IMMEDIATE;

STARTUP RESTRICT;

abrir uma sessão com ajmsolutions /*(erro)*/

sqlplus ajmsolutions/ajmsolutions

SHUTDOWN IMMEDIATE;

STARTUP;

abrir 2 sessões uma com o sys e outra com o ajmsolutions
na sessão do sys

Matar sessão dos usuários

na sessão do sys

SELECT sid, serial#, username
FROM v$session
WHERE username IS NOT NULL;

ALTER SYSTEM KILL SESSION 'sid,serial#';

ir na sessão do ajmsolutions e tentar fazer alguma coisa

Para testar os vários tipos de shutdown

Abrir duas sessões uma com o SYS e outra como AJMSOLUTIONS

na sessão do SYS

SHUTDOWN;

---------------------------------------

na sessão do AJMSOLUTIONS

CREATE TABLE xpto (ID NUMBER);
INSERT INTO xpto (1);

COMMIT;

Observar o que acontece na sessão do SYS.

exit

---------------------------------------

na sessão SYS

STARTUP;

--------------------------------------

Abrir a sessão do AJMSOLUTIONS

--------------------------------------

na sessão do SYS

SHUTDOWN TRANSACTIONAL

---------------------------------------

na sessão do AJMSOLUTIONS

INSERT INTO XPTO VALUES (1);
COMMIT;

---------------------------------------
na sessão do SYS

Observar o que acontece na sessão do SYS

STARTUP;

SHUTDOWN ABORT;

STARTUP FORCE;

Arquivo de alerta / rastreamento

SHOW PARAMETER background_dump_dest   /* (arquivo de alerta/arquivo de rastreamento - processo de segundo plano) */

No Sistema Operacional

#> vi /opt/oracle/diag/rdbms/ajmsolutions/AJMSOLUTIONS/trace/alert_AJMSOLUTIONS.log

#> cd /opt/oracle/diag/rdbms/ajmsolutions/AJMSOLUTIONS/trace

#> ls -a

Listar todas as views de desempenho dinâmico

SELECT name
FROM v$fixed_table
WHERE name LIKE 'V$%'
ORDER BY 1;

Listar todas as views de dicionário de dados DBA_

SELECT object_name
FROM dba_objects
WHERE object_name LIKE 'DBA_%'
ORDER BY 1;

Listar todas views de dicionários de dados ALL_

SELECT object_name
FROM dba_objects
WHERE object_name LIKE 'ALL_%'
ORDER BY 1;

Listar todas as views de dicionário de dados USER_

SELECT object_name
FROM dba_objects
WHERE object_name LIKE 'USER_%'
ORDER BY 1;

Informix Dynamic Server 11.50 Fundamentals Exam 555 certification preparation, Part 1 - 2/2:

Instalação

Após o planejamento do IDS, o próximo passo é instalar o produto. O IDS está disponível no Unix/Linux, Windows e Mac OS X. As opções de instalação disponíveis para você dependem do sistema operacional que você possui.

Unix/Linux

A instalação do IDS geralmente é executado em duas partes:

• Extraia o produto da mídia (CD, fita ou download)
• Rodar o script de instalação

Copiar o produto da mídia normalmente é realizado com o comando tar -xf. O produto deve ser descompactado no local do diretório onde o produto será instalado.

Uma vez que o conjunto de produtos IDS abrange mais do que apenas um produto, o processo de instalação pode ser feito de uma só vez ou em etapas ao nível do produto. Ao executar o comando ids_install, o script de instalação instalará o servidor IDS, bem como quaisquer outros produtos relacionados que estejam no mesmo diretório. O comando installserver apenas instala o servidor IDS e ignora outros produtos.

As permissões de root são necessárias para executar o script de instalação.

Uma vez conectado como root, a instalação pode ser realizada de várias formas:

• Modo console (padrão): Este modo utiliza o terminal texto padrão  e solicita as respostas do instalador sobre aceitação de licença, localização de instalação, modo de instalação, separação de função e inicialização do servidor de demonstração. Uma vez que essas perguntas foram respondidas e o resumo foi aprovado, a instalação ocorrerá. A opção de modo de instalação consiste em uma instalação típica ou personalizada. Alguns dos recursos instaláveis personalizados incluem:
• Recursos de extensibilidade
• GLS
• Utilitários de Backup e Restore
• Enterprise replication
• Utilitarios de Data-loading

A inicialização do servidor de demonstração cria, configura e inicializa uma instância de IDS com base em um arquivo de configuração fornecido ou no arquivo de configuração padrão.

Exemplo do comando de instalação:

install_ids

• Modo GUI: Este modo é usado quando a opção -gui é especificada com o comando de instalação. A instalação GUI é exatamente como a instalação do modo console, mas usa uma interface gráfica Java para interação com o instalador. Exemplo do comando de instalação: installserver -gui   
• Modo Silent: Este modo permite a instalação não interativa. O modo silencioso utiliza um arquivo .ini para as informações de resposta que normalmente viriam do teclado ou mouse nos modos console e GUI. IDS vem com dois arquivos .ini padrão que podem ser usados, ou você, o instalador, pode criar o seu próprio .ini. Um arquivo .ini pode ser criado automaticamente durante uma instalação interativa, especificando a opção -record no comando de instalação. Exemplo: installserver -record minharesposta.ini

Para usar o arquivo .ini personalizado, você deve especificar a opção -options no comando de instalação.
Exemplo:
install_ids -silent -options minharesposta.ini

Se qualquer um dos arquivos .ini padrão for usado (bundle.ini ou server.ini), a opção -acceptlicense = yes deve ser especificada no comando de instalação; Caso contrário, a instalação não terá sucesso.
Exemplo:
install_ids -silent -acceptlicense=yes

Algumas das outras opções que também podem ser especificadas durante a instalação incluem:

• -javahome para utilizar um JRE já instalado
• -P installLocation= para determinar um diretório diferente
• -log para especificar um arquivo de log fora do padrão

É possível ter várias versões do IDS instaladas no mesmo sistema ao mesmo tempo. O único requisito é que eles estejam instalados em diretórios diferentes. A variável de ambiente INFORMIXDIR aponta para o diretório do produto que deve ser usado ao iniciar uma instância IDS.

Windows

A instalação do IDS no Windows é feita no modo gráfico ou no modo silencioso. 

Se a mídia de instalação vier de um arquivo de download, você deve extrair os arquivos em uma estrutura de pastas usando a ferramenta apropriada com base no tipo de arquivo. Se a mídia de instalação for um CD, você pode iniciar a instalação diretamente do CD.

Para iniciar a instalação, execute o Launch.exe ou setup.exe.

Launch.exe iniciará o processo de instalação GUI que irá levá-lo através das seguintes etapas:

• Selecionar os produtos para a instalação
• Aceitar as condições de licença 
• Selecionar o modo de instalação (típica ou customizada)
• Configurar a conta do usuario informix e a senha, se não existir
• Selecionar o diretório de instalação
• Concordar com os resumos da instalação

O modo de instalação típico ou personalizado é semelhante ao descrito na seção Unix/Linux acima, exceto que também permite o seguinte:

• Especificar uma conta de usuário diferente de um usuário local 'informix' 
• Habilitar a role separation
• Criar um server demo com ou sem inicialização do instalador
• Início do Assistente de Configuração de Instância
• Iniciando o utilitário ClusterIT

Para instalar no Windows no modo silencioso, o comando setup.exe é usado em um ambiente de linha de comando. Assim como descrito no ambiente Unix/Linux, o modo silencioso usa um arquivo .ini para as informações de resposta durante a instalação. O arquivo server.ini padrão pode ser usado, ou um arquivo personalizado pode ser criado.

Abaixo segue um exemplo do comando de instalação ao usar o arquivo server.ini padrão:

setup.exe -s -f1"C:\IIF\server.ini"

A maneira de usar um arquivo .ini personalizado durante a instalação é mudar o nome do arquivo na opção -f1 como mostrado no exemplo de comando acima.

Para criar um arquivo .ini personalizado a partir das respostas dadas durante uma instalação GUI, primeiro você deve executar o comando setup.exe -r -fl "C:\temp\mysilent.ini" a partir de um prompt de comando antes de iniciar a instalação GUI.

Claro que você pode mudar o caminho e o nome do arquivo para se adequar ao seu ambiente.

Uma vez concluída a instalação, o novo arquivo .ini está pronto para usar para todas as futuras instalações silenciosas com a mesma configuração.

A instalação do Windows cria o arquivo de log em %INFORMIXDIR%\logs\, que mostra toda a atividade de instalação. A localização do arquivo de log pode ser modificado com a opção -f2"" quando utilizado com a instalação silenciosa.

O Windows permite que várias versões do IDS sejam instaladas em um computador com a opção -multiple.

Mac OS X

A instalação no Mac OS X é similar a instalação do Unix/Linux. Possui instalação GUI e os métodos de instalação silencioso (silent). Os privilégios de root são necessários para fazer uma instalação autônoma.

O método GUI é iniciado abrindo o pacote do informix e inserindo a senha do administrador do sistema quando solicitado. A instalação prossegue com instruções para:

• Informações da conta do usuário informix, se não existir
• Aceite da licença
• Diretório de instalação 
• Instalação do produto
• Modo de instalação (tipico e customizado)
• Role Separation
• Criação do servidor de banco de dados Demo
• Tuning automatico do Kernel
• Aprovação de sumario

O modo de instalação personalizado permite selecionar quais recursos estão instalados, conforme descrito na seção de instalação do Unix/Linux.

A instalação silenciosa é feita de forma semelhante à instalação silenciosa no Unix/Linux. No Mac OS X, o arquivo bundle.ini deve ser usado e personalizado para atender às suas necessidades de instalação.

Nota: Antes da instalação, certifique-se de alterar a opção -G licenseaccepted=false para true no arquivo .ini.

Caminho de instalação seguro

Durante a instalação do IDS 11.50, existe uma opção para proteger automaticamente o caminho de instalação. A proteção do caminho de instalação verifica se os diretórios no caminho de instalação possuem proprietários, grupos e permissões seguras configurados apropriadamente para o servidor de banco de dados.

Se você optar por não proteger o caminho na hora da instalação, você pode fazê-lo manualmente a qualquer momento.

Nota: IDS não será inicializado se o caminho de instalação não for seguro.

Para garantir o caminho em uma data posterior, faça o seguinte:

1. Execute $INFORMIXDIR/bin/onsecurity -r $INFORMIXDIR para criar um shell script.
2. Execute $INFORMIXDIR/tmp/secure.sh para alterar as permissões de segurança do path.

Proteger o path através deste processo manual permite que um administrador do sistema veja quais permissões serão atribuídas a qualquer diretório no caminho de instalação e tomarão as ações apropriadas para quaisquer diretórios extras que possam existir no caminho, mas que não faça parte da instalação IDS .

Configuração

Uma vez que o produto está instalado, é hora do próximo passo, que consiste em configurar o sistema operacional, o ambiente em que o IDS é executado e a instância do servidor IDS.

Aqui estão algumas definições que você deve saber antes de começar:

• Instancia IDS - Um conjunto definido de recursos do sistema operacional disponíveis para uso por um ou mais bancos de dados. Às vezes, uma instância também é conhecida como um servidor de banco de dados ou um mecanismo de banco de dados. Este conjunto de recursos consiste em espaço em disco, processos e memória.
• Banco de Dados Relacional - Uma coleção de dados organizados em tabelas para pesquisas rápidas, recuperação e armazenamento.

OS

Como a configuração do sistema operacional geralmente é uma função de administrador do sistema (SA), você pode precisar da ajuda do SA para completar esta tarefa.

O IDS é fornecido com um arquivo chamado "machine notes". Este arquivo existe no mesmo local que as "Release Notes" foram descritas na seção "Release Notes". O arquivo  "machine notes" consiste em recomendações para os parâmetros de configuração do kernel do sistema operacional apropriados para o tipo de máquina em que o IDS está instalado. Os parâmetros de configuração dependem diretamente do fabricante do sistema operacional.

No Unix/Linux, os parâmetros mais importantes do Kernel são a Shared Memory, semáforos, files, e usuários. I/O especial também podem ser configurados no Kernel.

A Listagem abaixo mostra um exemplo de "Machine Notes" para um sistema operacional HP-UX:

Machine Notes para Sistema Operacional HP-UX

Nota: Os valores indicados no "Machine Notes" são apenas valores recomendados com base no teste do produto. Se os valores diferirem muito dos valores já configurados no seu kernel, certifique-se com o administrador do sistema sobre como as mudanças desses valores podem afetar o sistema.

No Windows, o parâmetro de configuração mais importante é para memória. A capacidade de acessar mais do que a quantidade padrão de espaço de endereço de memória deve ser ativada no arquivo boot.ini. Ao alterar esse valor,  você pode aumentar isso de 2GB para aproximadamente 3GB. Embora não seja um parâmetro ajustável, é importante observar que todos os dados de uma instância IDS do Windows devem ser armazenados em partições NTFS, unidades físicas ou partições de disco lógico.

Ambiente

IDS depende muito do ambiente em que é iniciado. Por isso, as variáveis de ambiente que configuram esse ambiente são muito importantes para entender e definir corretamente. Existem cinco variáveis de ambiente principais para a instância IDS:

• INFORMIXDIR - O caminho completo para a localização do diretório do produto instalado.
• INFORMIXSERVER - O nome da instancia que será iniciada.
• PATH (opcional) - Deve incluir $INFORMIXDIR/bin por conveniência.
• ONCONFIG - (opcional) - Nome do arquivo de configuração "importante".
• INFORMIXSQLHOSTS - Aponta para o arquivo de informações de conectividade.

Como você pode notar, apenas duas das cinco variáveis de ambiente são necessárias; os outros três são opcionais. Este tutorial descreve por que isso é verdadeiro com mais detalhes.

A localização e o comando para definir a variável de ambiente dependem diretamente do SO que está sendo usado.

Um exemplo utilizando Unix e Korn Shell:

export INFORMIXDIR=/usr/informix

Como o Windows tem vários locais onde as variáveis de ambiente podem ser definidas, as seguintes regras de precedência se aplicam:

• Configurar a aplicação Setnet32
• Configurar em linha de comando antes de rodar á aplicação 
• Configurar no Windows como variáveis de usuarios
• Configurar no Windows como variáveis de ambiente
• Valor padrão 

A variável de ambiente INFORMIXDIR aponta para o local onde o produto está instalado. Isso é importante porque este caminho é precedido por alguns dos valores que são usados dentro do executável IDS. Sem este conjunto, o IDS não saberia onde procurar determinados arquivos que são necessários para serem executados com sucesso.

A variável de ambiente INFORMIXSERVER corresponde ao nome da instância IDS em que o ambiente será apontado por padrão. Essa variável de ambiente é importante para cada conexão de cliente que tenta acessar a instância IDS, seja esse cliente interno ou externo. Um cliente interno seria um utilitário que acompanha o software IDS. Um cliente externo seria qualquer aplicativo que use o SQL para conversar com o banco de dados. "Como você nomeia a instância IDS?" você pergunta. Isso é discutido um pouco mais tarde na seção "Arquivo de configuração".

A variável de ambiente PATH deve ser alterada para incluir $INFORMIXDIR/bin. Embora isso seja opcional, pode ser muito conveniente. É muito mais fácil digitar oninit do que ter que digitar /usr/informix/bin/oninit (assumindo /usr/informix é onde o produto IDS está instalado).

A variável de ambiente ONCONFIG é definida com o nome do arquivo de configuração a ser usado pela instância IDS. Cada instância tem apenas um arquivo de configuração que ele usa em qualquer momento. É possível usar um arquivo de configuração diferente, mas isso faz uma parada do software, alterando a variável de ambiente ONCONFIG para apontar para um arquivo diferente e reiniciando o software.

Note: A variável de ambiente ONCONFIG é definida apenas com o nome do arquivo. Não está definido para o caminho do arquivo. Exemplo:
export ONCONFIG=onconfig.prd

O arquivo onconfig esta localizado em $INFORMIXDIR/etc, então você não precisa saber onde o arquivo esta localizado, apenas o nome do arquivo a ser usado nesse diretório. O arquivo onconfig pode ser nomeado para qualquer outro nome que você deseja; no entanto, o padrão tornou-se onconfig.algo, substituindo o "algo" por um nome significativo, como no exemplo acima ("prd"). Também é possível usar um arquivo chamado onconfig, se essa for sua decisão. Em seguida, a variável de ambiente ONCONFIG torna-se opcional. A variável de ambiente ONCONFIG é  importante para o trabalho do DBA (por exemplo, iniciar e parar a instância). A atividade normal do cliente SQL não precisa ter a variável de ambiente ONCONFIG definida.

A variável de ambiente INFORMIXSQLHOSTS é definida com o caminho completo e o nome do arquivo que está sendo usado para informações de conectividade. Exemplo:
export INFORMIXSQLHOSTS=/work/ajm/mysqlhosts

Esse parametro é opcional pois se ele não estiver setado, o IDS procura pelo arquivo $INFORMIXDIR/etc/sqlhosts que possui as informações que ele necessita. "Que informações são essas?" você se pergunta. Esse tutorial descreve isso na seção "SQLHOSTS".

É importante notar que cada conexão de cliente, interna ou externa, requer informações de conectividade. Então, cada cliente quer obter suas informações do arquivo padrão ou do arquivo apontado pela variável de ambiente INFORMIXSQLHOSTS.

As cinco variáveis de ambiente listadas acima não são as únicas disponíveis para uso com IDS. Na verdade, o IDS possui facilmente mais de 100 variáveis de ambiente que podem ser usadas para controlar diferentes aspectos do software. Este tutorial já mostrou algumas variáveis a mais, como o - DB_LOCALE e CLIENT_LOCALE que controlam as configurações do GLS. Basta lembrar que os cinco listados acima são os mais importantes, e dois deles são necessários.

SQLHOSTS

O arquivo SQLHOSTS é necessário para as informações de conectividade. É uma configuração vital para um banco de dados porque é usado por cada cliente, interno ou externo, que se conecta à instância. Se não estiver configurado corretamente, ninguém poderá se conectar ao banco de dados e obter dados.

IDS é desenvolvido para executar localmente ou remotamente (ambiente distribuído) do cliente. Então, para que o cliente se conecte com sucesso ao IDS, ele precisa saber onde a instância do IDS reside e como chegar a ele. Pense no arquivo sqlhosts como a lista telefônica do IDS. É uma listagem de todas as instâncias de IDS disponíveis (por nome), onde residem (nome do host ou IP do computador) e qual a porta de serviço a ser usada ao enviar uma solicitação, assim como a lista telefônica normal lista as pessoas pelo nome, onde elas vivem (endereço), e como entrar em contato com eles (número de telefone).  A porta de serviço do sqlhosts especificam quais portas o IDS respondera as declarações SQL recebidas de seus clientes. Isso é a mesma forma de como o telnet usa a porta 23 ou o http usa a porta 80, por padrão, para aceitar pedidos recebidos. As portas utilizadas pelo IDS não são portas padrão global, mas, em vez disso, é configurado pelo DBA no arquivo sqlhosts.

A forma geral do arquivo sqlhosts é de cinco colunas e se parece com a Tabela abaixo:

Descrição do arquivo SQLHOSTS 

Na seção anterior mencionamos que cada instância IDS tem um nome. Esse nome está na primeira coluna do arquivo sqlhosts. A localização da instância está na terceira coluna, a coluna do nome do host. O número da porta onde o IDS está ouvindo os pedidos de SQL recebidos está na quarta coluna.

Na segunda coluna, a coluna NETTYPE, permite que você especifique se deseja usar um protocolo de rede ou um protocolo local para o cliente falar com a instância do IDS. Isso está diretamente relacionado ao local onde o cliente está sendo executado, em oposição a onde a instância IDS está sendo executada.

Se o cliente e o servidor estiverem sendo executados na mesma máquina física, a comunicação pode ocorrer de várias maneiras:

• Shared memory (conhecido como comunicação interprocesso ou ipc)
• Network interfaces (sockets ou TLI)
• Local pipes (nomeado ou não nomeado)
• DRDA (Distributed Relational Database Architecture)

No entanto, se o cliente e o servidor estão rodando em maquinas diferentes, então as rotas de comunicação são reduzidas porque você precisa confiar na rede. Então, neste caso, você só tem as opções de:

• Network interfaces (sockets ou TLI)
• DRDA

A coluna NETTYPE é como o administrador especifica qual rota de comunicação um cliente deve usar quando se conecta a uma instância pelo nome especificado na coluna um.

A quinta coluna, também conhecida como coluna opções, é uma coluna opcional que pode ser usada para configurar várias coisas. O exemplo acima tem o valor k=0. O "k" significa keep-alive e o "0" desliga este recurso quando se conecta ao servidor usando este DBSERVERNAME. O recurso keep-alive pede ao serviço de rede que verifique periodicamente o fim de da conexão para garantir que ainda existe. Se o destino de recepção não responder em tempo hábil, o serviço de rede assume que algo aconteceu, encerra a conexão e libera seus recursos. por padrão, o recurso keep-alive está ativado e geralmente deve ser deixado ligado.

Abaixo outra ilustração de exemplo:

Exemplo do arquivo SLQHOSTS

Com base na primeira linha no exemplo acima, se a variável de ambiente INFORMIXSERVER do cliente estiver definida como HR_prod, onsoctcp informa ao cliente para usar uma implementação sockets do protocolo TCP para se comunicar na rede. O cliente enviaria quaisquer solicitações SQL para a porta 1543 da máquina com o endereço IP 192.168.12.234. O campo hostname pode usar o endereço IP ou o nome do host da máquina, desde que o nome do host possa ser resolvido para um endereço IP com as chamadas do sistema apropriadas. A opção de b=8192 informa ao cliente para usar um buffersize de 8192 bytes ao se comunicar com o servidor. As conexões padrão usam um buffersize de 4096 bytes.

Se a variável de ambiente INFORMIXSERVER do cliente estiver definida como Acct_devel, onipcshm diz ao cliente que o servidor é local e que usa um mecanismo especial conhecido como Conexões de Memória Compartilhada. O mecanismo especial é definido e mantido pelo IDS para conexões locais para poder se conectar à instância usando um recurso  global de Unix Shared Memory. O cliente irá então utilizar esta parte da memória compartilhada, escrever seus pedidos SQL e leer os resultados dela. Conforme descrito acima, isso só está disponível quando o aplicativo cliente e a instância IDS estão sendo executados na mesma máquina.

A coluna ServiceName pode usar um número de porta ou um nome de serviço. Se um nome de serviço for usado, esse valor deve ser resolvido para um número de porta válido, conforme especificado no arquivo /etc/services em Unix/Linux/Mac ou system32\ drivers\etc\services no Windows.

Arquivo de configuração

Durante a configuração, o arquivo ONCONFIG geralmente vem de mãos dadas com o arquivo sqlhosts por causa dos campos que precisam corresponder. Como mencionado anteriormente, cada instância tem um nome e esse nome é usado na primeira coluna do arquivo sqlhosts. Como uma instância sabe qual é o nome? Esse é apenas um dos muitos parâmetros que estão configurados no arquivo de configuração IDS.

A instalação IDS vem com um arquivo chamado onconfig.std no subdiretório etc do caminho de instalação. Este arquivo deve ser usado como um modelo para o arquivo de configuração real de uma instância. Copie o arquivo onconfig.std para um arquivo de outro nome, (por exemplo, onconfig.prd). Embora a parte onconfig do nome do arquivo não seja necessária, tornou-se padrão. Uma vez que o arquivo foi nomeado, a variável de ambiente ONCONFIG deve ser definida para apontar para esse nome de arquivo.

Nota: A variável de ambiente ONCONFIG é somente o nome do arquivo, não a localização, porque o arquivo de configuração  tem que existir no $INFORMIXDIR/etc (%INFORMIXDIR%/etc no Windows).

Com mais de 180 parâmetros configuráveis e mais de 1100 linhas no total com comentários, o arquivo de configuração pode ser bastante assustador. Mas não se preocupe; as enormes quantidades de comentários, mais uma pequena experiência, trarão tudo em perspectiva. Na verdade, uma das coisas boas a saber é que apenas nove desses 180 parâmetros são necessários para colocar uma instância do IDS em funcionamento. O resto são para performance, extensibilidade, e recurso de suporte.

Então, vamos começar por dar uma olhada nessas nove e, em seguida, talvez um pouco mais, por diversão :-).

A configuração dos nones parâmetros necessários para subir uma instancia incluem:

• ROOTNAME
• ROOTPATH
• ROOTOFFSET
• ROOTSIZE
• MSGPATH
• CONSOLE
• DBSERVERNAME
• DBSERVERALIASES
• SERVERNUM

Do primeiro ao quarto estão ligados a espaço em disco. Não é necessário que todo o espaço em disco que a instância vai utilizar seja configurado no mesmo momento. Mais espaço em disco pode ser adicionado conforme a necessidade; no entanto, No entanto, uma certa quantidade de espaço em disco precisa existir desde o início. Este espaço em disco recebe um nome (ROOTNAME), uma localização (ROOTPATH), uma posição inicial (ROOTOFFSET) e um tamanho (ROOTSIZE). Quando a instância do IDS usando este arquivo de configuração for iniciada pela primeira vez, formatará esse espaço definido e inicializá-lo-á para um aspecto especificado. Por isso, você precisa ter certeza de que nada mais está usando esse mesmo espaço em disco. ROOTPATH pode apontar para um arquivo existente ou um dispositivo raw.

O quinto e sexto parâmetros têm a ver com as mensagens de log. Uma vez que a instância IDS deve ser executado em segundo plano, ele precisa de um local onde pode escrever mensagens de informações, de aviso e de erros. MSGPATH define um caminho e um nome de arquivo do arquivo ao qual você gostaria que as mensagens fossem escritas. CONSOLE pode ser usado para enviar mensagens especiais para uma tela de console se for usada. Por causa da duplicação de mensagens para esses dois lugares, o padrão tornou-se para enviar o CONSOLE para /dev/null.

Agora discutiremos o sétimo e o oitavo parâmetro. Cada instância do IDS tem um nome (DBSERVERNAME), e pode ter mais de um nome se necessário para diferentes tipos de conectividade (DBSERVERALIASES). Pense nisso desta maneira: Você pode ter o nome de nascimento Amilcar, mas você pode ter outros nomes para os quais você também responde (alias), como Ami. Você poderia dizer para as pessoas que não conhecem você, que se chama Amilcar, mas amigos próximos chamam você de Ami. Você responde por ambos os nomes, mas você pode responder de uma maneira diferente, dependendo de qual nome você esta sendo chamado. É semelhante ao IDS: pode ter apenas um nome, mas pode ter muitos alias. O nome e cada um dos alias devem estar listados no arquivo SQLHOSTS em uma linha diferente. Lembre-se que é o arquivo SQLHOSTS que informa ao cliente como se conectar à instância, dependendo do nome ou alias (primeira coluna no arquivo SQLHOSTS) que é usado.

O nono parâmetro é um número inteiro exclusivo entre zero e 255 para cada instância de IDS que está sendo executada na mesma máquina. Sem nos aprofundar muito, este número (SERVERNUM) é usado para ajudar a gerar um valor necessário para a memória compartilhada UNIX. Uma vez que é possível iniciar mais de uma instância de IDS na mesma máquina, o valor especificado pelo SERVERNUM deve ser diferente para cada instância para ajudar o IDS a certificar-se de que ele calcula um número exclusivo para dar ao UNIX.

Alguns outros parâmetros de interesse sem muito detalhe incluem:

• PHYSFILE, ajuda a dimensionar o log físico
• LOGFILES e LOGSIZE, ajuda a configurar o logical logs
• ADMIN_MODE_USERS, especifica os usuários que podem se conectar enquanto a instância estiver em modo administrativo; O usuário informix sempre pode se conectar
• DBCREATE_PERMISSION, especifica um usuário que pode executar instrução SQL CREATE DATABASE
• BUFFERPOOL,  configura o tamanho e os parâmetros de ajuste de um bufferpool

Então, mesmo que o arquivo de configuração seja grande, entende-lo por blocos o ajudará a começar a entender. Lembre-se, você não precisa saber tudo para subir uma instância de IDS.

Nota: Com pequenas exceções, o arquivo onconfig é lido apenas no tempo de inicialização; quaisquer alterações feitas diretamente no arquivo onconfig não terão efeito até que a instância seja interrompida e reiniciada. Alguns dos parâmetros onconfig podem ser alterados dinamicamente com o comando onmode (discutido mais adiante neste tutorial).

Reflexos da configuração

Note: Agora que você aprendeu sobre as três partes das configurações das variáveis de ambiente, arquivo sqlhosts e o arquivo onconfig, revisemos a importância de como essas três partes se juntam para que a conectividade do cliente funcione com sucesso.

Vamos demonstrar um exemplo do trecho de cada parte:

Variáveis de ambiente: 

INFORMIXSERVER=HR_Prod

Exemplo do arquivo SQLHOSTS: 

arquivo onconfig

DBSERVERNAME         HR_Prod

DBSERVERALIASES    HR_Devel

Observe como todos eles têm o mesmo "Nome" (HR_Prod) neles. O arquivo onconfig informa à instância qual é o nome. O arquivo sqlhosts informa onde encontrar a instância por esse nome. O cliente diz em qual instância ele quer conversar, especificando-o na variável de ambiente.

Então, quando o cliente começa a ser executado, ele leva o valor da variável de ambiente INFORMIXSERVER, procura-se no arquivo sqlhosts, descobre para onde enviar seu pedido SQL e, em seguida, o envia.

Por outro lado, o DBA nomeou a instância no arquivo onconfig e, quando a instância foi iniciada, ele pesquisou no arquivo sqlhosts para descobrir qual servidor (número de porta) deve estar configurada para as solicitações recebidas.

Iniciando

Não podemos terminar este tutorial até entender como completar a configuração e acabar com instancia online.

O que fizemos até agora:

• Planejamento da instalação
• Instalação  do produto que você decidiu  de acordo com seu planejamento
• Configurou uma instância do produto, configurando o ambiente, o arquivo sqlhosts e o arquivo onconfig
• Certifique-se de que o espaço em disco para o qual ROOTPATH é apontado existe

Agora é hora da conclusão. Essa ultima sessão vai tratar de como inicializar e parar uma instancia IDS.

oninit

Uma vez que uma instância IDS é apenas um conjunto de recursos de SO utilizado por um banco de dados, você precisa de uma maneira para alocar  e desalocar esses recursos quando necessário. As ferramentas que você tem para fazer isso são conhecidas como os comandos oninit e onmode. Embora seja válido no Windows também, uma vez que uma instância IDS funciona como um serviço,  é melhor iniciar e parar o serviço, ou use o comando para iniciar uma ajuda ao serviço.

Antes de falar sobre como iniciar o software, considere mais uma coisa. Uma instância IDS tem vários estados em que pode estar. A tabela abaixo lista alguns dos diferentes estados e o que eles significam:

Estados IDS

O comando oninit só é válido para iniciar a instância. Pense na instância como um carro. Para ligar um carro, você gira a chave; se o carro estiver em qualquer estado, exceto desligado, girar a chave fará um ruído terrível. Uma instância IDS é a mesma coisa. O comando oninit somente trabalhara se a  instancia estiver parada (offline). Se a instância estiver em qualquer outro estado, executar o comando oninit retornara um aviso. Não vai acontecer nada, mas também não funcionará.

O comando oninit vem com as opções listadas e descritas abaixo: 

opções oninit 

• -i --> inicializa um espaço em disco. Como formatar um disco rígido, ele só deve ser usado a primeira vez que a instância for iniciada.
• -y --> automaticamente responde "Yes"para todas as questões
• -j --> Inicia uma instancia em modo administrativo. Também conhecido como single-user.
• -v --> modo "Verbose". Mostra mensagens adicionais no monitor enquanto inicializa.
• -s --> Inicia uma instancia em modo quiescent mode.

Há mais opções para se utilizar, mas veremos somente essas opções neste tutorial.

onmode

O comando onmode é usado para parar a instância, bem como uma infinidade de outras coisas.

O comando onmode é usado para alterar o estado da instância, para alterar dinamicamente alguns dos parâmetros no arquivo onconfig, adicionar e liberar memória, configurar o scanner B-tree, configurar os recursos HDR e Mach11, forçar um checkpoint, e muito mais.

Este tutorial abrange apenas dois desses tópicos: alteração do estado da instância e alteração dinâmica dos parâmetros do arquivo onconfig.

Ao usar o comando onmode para alterar o estado da instância, ele usa as seguintes opções:

opções onmode

• -m --> Altera a instância do estado do single-user ou quiescent para estado on-line.
• -s ---> Executa um shutdown graceful e altera a instância para o estado quiescent de single-user ou on-line.
• -j ---> Executa um shutdown immediate para usuários non-admin somente, e traz a instância para estado single-user a partir do estado quiescent ou on-line.
• -u ---> Executa um shutdown immediate e altera a instancia para quiescent do estado single-user ou on-line.
• -k ---> Executa um shutdown immediate e altera a instancia para off-line para todos os usuarios.
• -y --> Responde automaticamente as perguntas como "yes"

Como mostrado em itálico acima, o IDS tem duas formas de shutdown: um shutdown graceful e um immediate.

O shutdown graceful não permite novas conexões, mas permite que os usuários conectados continuem até se desconectar. Quando o último usuário se desconectar, a instancia irá mudar para o estado especificado pela opção dada ao comando onmode.

O shutdown immediate para todas as atividades no banco de dados e coloca a instancia imediatamente para o estado especificado pela opção dada ao comando onmode.

A ilustração abaixo mostra os comandos oninit e onmode. Entre cada comando, um onstat - é executado para mostrar o estado da instância. A mensagem "Shared memory not initialized for INFORMIXSERVER 'xxx'" significa que não existe nenhuma instância rodando com esse nome.

onmode -wf / -wm

Como mencionado anteriormente, o comando onmode pode ser usado para outras coisas também, incluindo a alteração dinâmica dos valores de alguns dos parâmetros onconfig. Isto é realizado com os comandos onmode -wf e onmode -wm. A maneira mais fácil de lembrar a diferença é que "f" significa file e "m" significa memory. Portanto, o comando onmode -wf muda a configuração atual na memória e muda o valor no arquivo onconfig. O comando onmode -wm somente altera o valor corrente em memória.

Nota: A partir do IDS 11.50, apenas um subconjunto limitado dos parâmetros onconfig pode ser alterado dinamicamente dessa maneira.

A sintaxe do comando é: onmode -wf <onconfig parameter>=<value> ou onmode -wm <onconfig parameter>=<value>.

Exemplo:

onmode -wf AUTO_CKPTS=0

onmode -wm RESIDENT=1

Se você tentar alterar um valor que não seja compatível com o comando onmode -wf/wm, você verá uma mensagem como essa:

"Configuration Parameter to be changed is not valid or not supported with this option."

SLES 12–Notas Gerais sobre Tunning do sistema

Estarei postando assim que possível, alguns tópicos sobre Tunning no SLES-12.

O objetivo é discutir como encontrar as razões para problemas de desempenho e fornecer meios para resolver esses problemas. Antes de começar a ajustar o sistema, certifique-se de ter descartado problemas comuns e ter encontrado a causa do problema. Deve-se também ter um plano detalhado sobre como ajustar o sistema, porque a aplicação de dicas de ajuste aleatório muitas vezes não vai ajudar e poderia piorar as coisas.

Abordagem geral ao ajustar um sistema

1. Especifique o problema que precisa ser resolvido;
2. Caso a degradação seja nova, identifique quaisquer alterações recentes no sistema;
3. Identificar por que o problema é considerado um problema de desempenho;
4. Especifique uma métrica que pode ser usada para analisar o desempenho. Essa métrica pode ser, por exemplo, latência, taxa de transferência, o numero máximo de usuários que estão logados simultaneamente ou o numero máximo de usuários ativos;
5. Medir o desempenho atual usando a métrica da etapa anterior;
6. Identificar o subsistema onde o aplicativo esta gastando mais tempo;
7. Monitorar o sistema e/ou o aplicativo, assim como analisar os dados, categorize onde o tempo esta sendo gasto;
8. Ajuste o subsistema identificado na etapa anterior;
9. Reavalie o desempenho atual sem monitoramento usando a mesma métrica como antes;
10. Se o desempenho ainda não for aceitável, volte a etapa 3 novamente.

Esteja Certo que problema resolver

Antes de começar a ajustar um sistema, tente descrever o problema da forma mais exata possível. Uma declaração como “O sistema é lento!” não é uma descrição útil do problema. Por exemplo, poderia fazer uma diferença se a performance do sistema precisa ser melhorada em geral ou apenas em horário de pico.

Além disso, certifique-se de que você pode aplicar uma medição ao seu problema, caso contrario você não será capaz de verificar se o ajuste foi um sucesso ou não . Você deve sempre ser capaz de comparar “antes” e “depois”. Quais métricas usar depende do cenário ou aplicativo que você esta procurando. As métricas de servidor Web relevantes, por exemplo, poderiam ser expressas em termos de:

Latência

o Tempo para entregar uma página.

Taxa de transferência

Numero de paginas atendidas por segundo ou megabytes transferidos por segundo.

Usuários Ativos

O numero máximo de usuários que podem baixar paginas enquanto ainda estão recebendo paginas dentro de uma latência aceitável.

Eliminar problemas comuns

Um problema de desempenho geralmente é causado por problemas de rede ou hardware, bugs ou problemas de configuração. Certifiques-e de descartar problemas como os listados abaixo antes de tentar ajustar seu sistema:

• Analise a saída do systemd journal;
• Analise (usando top ou ps) se um determinado processo se comporta mal por consumir quantidades incomuns de tempo de CPU e memoria.
• Analise se há problemas de rede /proc/net/dev.
• Em caso de problemas de I/O com discos físicos, certifique-se de que ele não é causado por problemas de hardware (verifique o disco com o smartmontools).
• Certifique-se de que os trabalhos em segundo plano estão programados para serem executados em períodos em que a carga do servidor é baixa. Esses trabalhos também devem ser executados com baixa prioridade definida via nice.
• Se o servidor  executar vários serviços utilizando o mesmos recursos, considere mover serviços para outro servidor.
• Por ultimo, verifique se o software está atualizado.

Procurando por gargalos

Encontrar gargalos muitas vezes é a parte mais difícil ao ajustar um sistema. O SuSE Enterprise Server, assim como todos os Linux/Unix, oferece muitas ferramentas para ajuda-lo nessa tarefa. Em posts futuros estarei passando mais informações detalhadas sobre as aplicações gerais de monitoramento do sistema e a analise do arquivo de log. Se o problema requer uma analise longa e profunda, o kernel do Linux oferece meios para realizar essa analise, vou estar abordando esse assunto também futuramente.

Depois de ter coletado os dados, ele precisa ser analisado. Primeiro, verifique se o hardware do servidor (memoria, CPU, barramento) e os I/Os (disco, rede) são suficientes. Se essa condição básica forem atendidas, o sistema poderá se beneficiar de um Tuning.

Passo a passo do Tuning

Certifique-se de planejar cuidadosamente o tuning em si. É de vital importância fazer um passo de cada vez. Só fazendo isso você será capaz de medir se a mudança forneceu uma melhoria ou mesmo teve um impacto negativo. Cada atividade de ajuste deve ser medido durante um período de tempo suficiente para garantir que você possa fazer uma analise com base em dados significativos. Se você não pode medir um efeito positivo, não faça mudança permanente. As possibilidades são, que poderia ter um efeito negativo no futuro.

Iniciando com SuSE

A maioria das versões de Linux, assim como Unix, define  o prompt de comando padrão como um sinal de dolar, $, para usuários comuns e para o root #). o SuSE, entretanto, define o prompt de comando padrão como um sinal de maior  (>), mas segue a convenção dos Linux usando o sinal de cerquilha ou libra # para o usuario root. Ao longo dos meus post, você vai ver $ para o prompt de shell para comandos que podem rodar como qualquer usuario (não querer privilegios especiais).

Voce pode customizar seu prompt da maneira que voce quiser, usando o comando abaixo:

$ export PS1=" [\u@\h \w]\\$ "
[amilcar@isis /root]$

Este comando configura o prompt com seu nome, @ o hostname corrente, com o diretorio de trabalho atual, tudo dentro dos colchetes, seguido pelo $ que é o prompt tradicional.

Encontrando Comandos

Alguns dos comandos que vou descrever em meus post, pode não ser encontrados na sua distribuição ou dependendo do usuario que você estiver logado, ou se digitar o comando errado, irá aparecer uma mensagem similar  a essa:

[amilcar@isis ~]$ comandoinexistente
bash: comandoinexistente: command not found

Algumas das razões para voltar essa mensagem de erro:

• Você pode ter digitado o comando errado;
• O comando pode não existir em seu PATH;
• Pode ser necessario do usuario root para executar o comando;
• O comando pode nao estar instalado no computador;

Abaixo alguns comandos para extrair informações do comandos que deseja usar:

[amilcar@isis ~]$ type mount   (Mostra o primeiro comando do PATH)
mount is /bin/mount
[amilcar@isis ~]$ ]

[amilcar@isis ~]$ whereis mount            (Mostra binarios, fontes e manuais)
mount: /bin/mount /sbin/mount.nfs /sbin/mount.cifs /sbin/mount.nfs4 /sbin/mount.ntfs /sbin/mount.ntfs-3g /usr/share/man/man2/mount.2.gz /usr/share/man/man8/mount.8.gz
[amilcar@isis ~]$

[amilcar@isis ~]$ which mount      (procura pelo comando em qualquer lugar da file system)
/bin/mount
[amilcar@isis ~]$

[amilcar@isis ~]$ rpm -qal |grep mount           (encontrar pelo comando em qualquer pacote instalado)
/usr/bin/mmount
/usr/share/man/man1/mmount.1.gz
/usr/share/zsh/4.3.6/functions/_fusermount
/usr/share/zsh/4.3.6/functions/_mount
/usr/share/zsh/4.3.6/functions/_showmount
/usr/lib64/hal/hal-storage-cleanup-all-mountpoints
/usr/lib64/hal/hal-storage-cleanup-mountpoint
/usr/lib64/hal/hal-storage-mount
/usr/lib64/hal/hal-storage-unmount
/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/linux/ncp_mount.ph
/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/linux/nfs4_mount.ph
/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/linux/nfs_mount.ph
/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/linux/smb_mount.ph
/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/rpcsvc/mount.ph
/usr/lib/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi/sys/mount.ph
/sbin/mount.nfs
/sbin/mount.nfs4
/sbin/umount.nfs
/sbin/umount.nfs4
…………………
…………………

[amilcar@isis ~]$ rpm -q --whatprovides tar   (procura pelo pacote que prove o comando)
tar-1.20-23.12.1
[amilcar@isis ~]$

Se o comando que voce procura nao estiver instalado, voce pode fazer a instalação do pacote usando o shell ou GUI:

• Instalação pelo Shell – digite yast na linha de comandoe siga as orientações do YaST2. Também pode ser instalado via zypper ou ainda com o rpm.
• Instalação via GUI – pode ser instalado pela versão grafica do YaST2, você vai precisar da senha do root para rodar a aplicação.

PAM–Plugglable Authentication Modules

Já faz alguns dias que venho quebrando a cabeça com o PAM, muito minucioso para configurar, porem muito eficiente para quem busca segurança. Já faz dias que estou vasculhando a Internet, procurando por documentos e dicas, participando de fóruns para tentar entender como realmente funciona o aplicativo para poder configurar dois servidores.

O meu objetivo com o PAM, é configurar uma autenticação segura, onde, por exemplo, se o usuário errar a senha por cinco vezes bloqueia o acesso, e somente é liberado se o root liberar, também configurar o comprimento da senha, que seria no caso de seis caracteres, porem teria que ter uma maiúscula e um numero formando essa senha, ate esse momento que estou escrevendo esse artigo não consegui sucesso ainda.

Mas o que é realmente o PAM?

O PAM é uma biblioteca que permite usuários autenticar em ambientes como o Linux ou Unix (HP-UX,
AIX, Solaris, entre outros). O grande objetivo do desenvolvimento do PAM deu-se devido ao problema encontrado quando era preciso fazer o login de um usuário, utilizando uma senha criptografada através de acesso remoto. Além disso, como cada programa possuía seu método próprio de login, caso fosse necessário mudar o método de autenticação, os programas teria que ser alterados para reconhecer este novo método. Foi neste momento, que a SUN MICROSYSTEMS criou o PAM, um aplicativo centralizador da tarefa de autenticação, com isso não seria mais necessário cada programa se preocupar com o papel de autenticador, pois esta seria a tarefa do PAM e casso fosse mudado o critério de autenticação, por questão de segurança, somente seria necessários alterar o método no próprio PAM.

Qual a Vantagem do PAM

A principal vantagem do PAM, além de centralizador das funções de autenticação do login e senha, é que ele é capaz de selecionar, se configurar para tal, os programas aos quais os usuários que fez o login pode ou não acessar. Desta forma, um usuário que quisesse usufruir de aplicativos de áudio e vídeo, por exemplo, remotamente, poderia ser bloqueado o que não aconteceria caso ele estivesse utilizando estes aplicativos localmente.

Configuração do Módulo PAM

Os arquivos de configuração do PAM, no Linux, normalmente estão localizados no diretório /etc/pam.d/.

Nestes arquivos, a linha de configuração é dada como:

Service-name module-type control-flag modulo-path args

Nome do Serviço

Esta associado ao nome do serviço a esta entrada. Por exemplo, ftpd, rlogind, su e outros.

Divisão dos Módulos – Module-Type

Como o próprio nome diz, o PAM é um conjunto de módulos, no qual cada um recebe uma ou mais funções especiais dentro do processo de autenticação. Essa função que cada modulo tem é determinado pelas divisões dos módulos do PAM, que são: AUTH, ACCOUNT, PASSWORD, SESSION.

AUTH

A divisão AUTH trata da autenticação, seja por login/senha ou autenticação biométrica (voz, retina, impressão digital, por exemplo).

ACCOUNT

Esta divisão, terá o papel de autorização ou não autorização para o uso de programas com base no login, determinando assim, o usuário apto a utilizar aquele programa ou não.

PASSWORD

É responsável pela troca de senha.

SESSION

Determina qual será o ambiente do usuário com base no seu login.

É importante salientar, neste momento, que o PAM é o conjunto de módulos e como tal, não precisa ter todos os módulos existentes e possíveis para funcionar, basta ter aqueles os quais o administrador acha necessário trabalhar, e que, alguns módulos possuem apenas uma das divisões acima citadas enquanto outros chegam a ter todas as divisões.

Controle das Flags – Control-flag

O control-flag é utilizado para indicar de que forma a biblioteca do PAM reagirá ao sucesso ou falha do módulo que esta associado. Outra função que a control-flag pode executar é dando prioridades a cada módulo, visto que eles podem ser empilhados.

Existem dois modos de sintaxe para o control-flag um mais antigo e tradicional que divide a sintaxe em: REQUIRED, REQUISITE, SUFFICIENT, OPTIONAL. O modo mais novo, mais elaborado e especifico separa da seguinte forma: VALUE=ACTION. A parte ACTION é nomeada como IGNORE, BAD, DIE, OK, DONE, RESET.

Controle de Sintaxe do Modo Tradicional

REQUIRED

Estabelece que: a falha do módulo utilizando a sintaxe REQUIRED, não será mostrada ao usuário até que todos os módulos estejam sendo executados.

REQUISITE

Parecido com o REQUIRED, porem no caso de falha, o controle é retornado direto a aplicação. Esta flag é muito utilizada para proteger um usuário que tente colocar sua senha quando o meio esta inseguro.

SUFFICIENT

A falha deste modulo não implica em falha da autenticação como um todo. Se o modulo falhar, o próximo da classe é executado. Se não houver próximo, então a classe retorna com sucesso. Se, por outro lado, o modulo terminar com sucesso, então os módulos seguintes dessa classe não serão executados. Este parâmetro é bastante usado no caso de usar LDAP para autenticação, por exemplo, ou outra fonte de dados.

OPTIONAL

Módulos marcados como ptional praticamente não influencia o resultado da autenticação como um todo. Eles terão alguma influencia somente caso os módulos anteriores da mesma classe não apresentem um resultado definitivo.

Exemplos de Modulos do PAM – Module Path

Existem muitos módulos disponíveis como: pam_access, pam_chroot, pam_cracklib, pam_deny, pam_env, pam_filter, pam_ftp, pam_group, pam_issue, pam_krb4, pam_lastlog, pam_limits, pam_listfile, pam_mail, pam_mkhomedir, pam_motd, pam_nologin, pam_permit, pam_pwdb, pam_radius, pam_rhosts_auth, pam_rootok, pam_securetty, pam_tally, pam_time, pam_unix, pam_userdb, pam_warn, pam_wheel, pam_tally2.

Porem, somente os módulos principais serão mostrados e explicados a seguir.

Securetty Module – pam_securetty

Module-Type: AUTH

Autor: Elliot Lee

Características: este modulo simplesmente verifica em qual terminal o root esta tentando fazer login, então a partir dele é possivel restringir os locais em que o root pode fazer login. Logo,a principal característica do pam_securetty é evitar o login do root em terminais inseguros. Vale ressaltar, que para o pam_securetty,nenhum terminal esta liberado para o login, o root que devera configurar este modulo para ele possa fazer o login em outro terminal.

Password Database Module – pam_pwdb

Module-Type: ACCOUNT, AUTH, PASSWORD, SESSION

Autores: Cristian Gafton e Andrew G. Morgan

Caracteristica: Este é o principal modulo do programa login, para tanto ele se encarrega de fazer a verificação do nome do usuário e senha, assim, autorizando o usuário ou não. Este modulo ainda aceita alguns parâmetros em sua configuração: shadow, nullok, md5, use_authtok.

Shadow: permite o uso de senhas shadow ou convencionais.

Nullok: permite o uso de senha em branco.

Md5: usa criptografia md5 em vez de cript padrão.

Use_authok: indica que o modulo deve usar a autenticação já fornecida para os módulos anteriores, para não interrogar o usuário novamente.

No-login Module – pam_nologin

Module-Type: ACCOUNT, AUTH

Autor: Michael K. Johnson

Caracteristica: este modulo é muito útil quando se deseja fazer a manutenção do sistema. Com ele funcionando, não será permitido a nenhum usuário fazer o login com exceção do root. É importante citar que, usuários que já estiverem feito o login não serão afetados com a adição deste modulo.

Cracklib pluggable password strength-checker – pam-cracklib

Module-Type: PASSWORD

Autor: Cristian Gafton

Caracteristica: este modulo fara a verificação da fragilidade de uma nova senha. Para isto, ele avalia algumas características como:

Polindrome: a nova senha é um palindrome da antiga?

Case change only: a nova senha é a antiga com apenas a diferença da caixa(maiúscula e minúscula)?

Simiar: a nova senha é similar a antiga? Ou seja, se existe caracteres repetidos. Ele estipula um numero mínimo para o uso dos mesmo caracteres da senha antiga.

Simple: a nova senha é muito pequena?

Rotated: a nova senha é a antiga, porem invertida?

Already used: a opção para nova senha já foi utilizada no passado?

Access Module – pam_access

Module-Type: ACCOUNT

Autor: Alexei Nogin

Caracteristica: verifica quais usuários podem fazer login e em qual local (terminal, remoto, domínio, etc.)

Resource Limits Module – pam_limits

Module-Type: SESSION

Autor: Cristian Gafton

Caracteristica: este modulo limita o uso dos recursos como : uso da CPU, memoria e outros. Sua linha de configuração de entrada é:

<domain> <type> <item> <value>

Domain: pode ser o nome de um usuário ou grupo.

Type: pode ser de dois tipos: hard ou soft. Para o hard o usuário não pode alterar os recursos pre-definidos, já para o modo soft o usuário é capaz de alterar os recursos, porem sem ultrapassar os limites do modo hard.

Item: pode ser cada um dos seguintes:

Core: tamanho máximo para arquivos core (KB)

Data: tamanho máximo do seguimento de dados de um processo de memoria

Fsize: tamanho máximo para novos arquivos.

Memlock: tamanho máximo de memoria que um processo pode bloquear na memoria física.

Nofile: quantidade máxima de arquivos abertos ao mesmo tempo

Rss: tamanho máximo que um processo pode manter na memoria física

Stack: tamanho máximo da pilha

Cpu: tempo máximo do uso da CPU

Nproc: quantidade máxima de processos disponíveis para um único usuário

As: limite de espaço de endereçamento

Maxlogins: quantidade máxima de logins para este usuário ou grupo

Priority: a prioridade com os processos deste usuário serão executados.

Value: determina o valor para opção do Item.

Argumentos – Args

Os args, argumentos, fazem parte de uma lista de símbolos que podem ser colocados ao final de cada modulo, se desejado. Estes argumentos são semelhantes aos argumentos disponíveis em um comando do Linux.

Manual - Linux-PAM (PAM_TALLY2)

NAME

pam_tally2 – Modulo contador de login (contagem)

SINOPSE

pam_tally2.so [file=/path/to/counter] [onerr=[fail|succeed]] [magic_root] [even_deny_root] [deny=n] [lock_time=n] [unlock_time=n] [root_unlock_time] [serialize] [audit] [silent] [no_login_info]

pam_tally2 [—file /path/to/counter] [—user username] [—reset[n]] [—quiet]

DESCRIPTION

Este módulo mantem uma contagem das tentativas de acessos, pode reiniciar a contagem com sucesso, pode negar acesso se muitas tentativas falham.

pam_tally2 divide-se em duas partes: pam_tally2.so e pam_tally2. O primeiro é o módulo do PAM e o segundo um programa stand-alone. pam_tally2 é um aplicativo (opcional) que pode ser usado para consultar e manipular o arquivo de contagem. O programa pode exibir a contagem do usuário, parametrizar contagem de usuário ou limpar todas as contagem. Parametrizações para fazer a contagem podem ser uteis para bloquear os usuários sem alterar suas senhas. Por exemplo, pode-se limpar todas as contagem a meia-noite usando-se o cron.

Normalmente, falhas de acesso com o usuário root não fara com que a conta root fique bloqueada, para evitar ataques de negação de serviço: se o seu usuários não recebe contas de shell e o root só podem fazer login via su ou no console da maquina (não telnet/rsh, etc), isso é seguro.

OPÇÕES

OPÇÕES GLOBAIS

Estas opções podem ser usadas no modulo auth e account.

onerr=[fail|succeed]

se algo estranho acontece (como não conseguir abrir o arquivo), retorna com PAM_SUCCESS se onerr=succeed é dado senão um código de erro do PAM.

file=/path/to/counter 

arquivo onde será mantida a contagem. o padrão é /var/log/tallylog.

audit

Irá registrar o nome do usuário no log do sistema se o usuário não for encontrado.

silent

não existe mensagens de informações.

no_log_info

não grava mensagens de log via syslog(3).

AUTH OPTIONS

Primeira fase de autenticação contra as tentativas de login e verifica se deve ser negado acesso ao usuário. Se o usuário é autenticado, o processo de login continua para o pam_setcred(3) e o contador é zerado.

deny=n

Nega o acesso se a contagem para este usuário excede n.

lock_time=n

Sempre negar n segundos após tentativas mal sucedidas.

unlock_time=n

Permite o acesso após n segundos após as tentativas de falhas.

magic_root

Se o módulo é chamado por um usuário com uid=0 o contador não é incrementado. O administrador de sistemas deve utilizar isso para usuários de serviços como o su, caso contrario, este argumento deve ser omitido.

no_lock_time

não utiliza o campo .fail_locktime no arquivo /var/log/faillog para este usuário.

even_deny_root

conta root pode tornar-se indisponivel.

root_unlock_time=n

Esta opção implica na opção even_deny_root. Permite o acesso após n segundos após as tentativas de falhas. Se esta opção for utilizada o usuário root será bloqueado para um periodo de tempo especificado depois que ele ultrapassou o seu máximo de tentativas permitidas.

serialize

serializar o acesso ao arquivo de registro usando bloqueios.

OPÇÃO ACCOUNT

Redefine tentativas do contador se o usuário não é root. Esta fase pode ser usado opcionalmente por serviços que não chamam o pam_setcred(3) corretamente ou se a reinicialização deve ser feito independentemente do fracasso de contas dos outros módulos.

magic_root

Se o módulo é chamado por um usuário com uid=0 o contador não é incrementado. O administrador de sistemas deve utilizar isso para usuários de serviços como o su, caso contrario, este argumento deve ser omitido.

VALORES RETORNADOS

PAM_AUTH_ERR

uma opção invalida foi dada, o módulo não foi capaz de recuperar o nome do usuário, nenhum arquivo counter válido foi encontrado, ou muitos logins falhos.

PAM_SUCCESS

tudo que foi bem sucedido

PAM_USER_UNKNOWN

usuário não conhecido

NOTA

pam_tally2 não é compatível com o formato de arquivo do antigo pam_tally. Isto é causado pela exigência de compatibilidade entre o formato de arquivo tallylog entre arquiteturas de 32bits e 64bits em sistemas multiarch.

 

EXEMPLOS

adicione as seguintes linhas ao arquivo /etc/pam.d/login para bloquear a conta após 4 tentativas de falhas no login. A conta do root também será bloqueada. As contas serão automaticamente desbloqueada após 20 minutos.

auth                       required                                 pam_securetty.so
auth                       required                                 pam_tally2.so deny=4 even_deny_root unlock_time=1200
auth                       required                                 pam_env.so
auth                       required                                 pam_unix.so
auth                       required                                 pam_nologin.so
account                required                                 pam_unix.so
password            required                                 pam_unix.so
session                required                                 pam_limits.so
session                required                                 pam_unix.so
session                required                                 pam_lastlog.so nowtmp
session                optional                                 pam_mail.so standard