Comparando SuSE com outras distribuições Linux

Usando openSuSE pode ser a melhor maneira de aprender Linux se você tiver a intenção de se tornar um profissional Linux. Com seu foco no desenvolvimento comunitario, voce pode ter certeza que voce esta recebendo alguns dos mais recentes e melhores software de codigo aberto disponivel. Utilizando o openSuSE voce ganhara habilidades em niveis de ambientes empresariais.

Alem da Novell, Red Hat Inc. é outra grande corporação que distribui Linux no mercado. Os Sistemas Operacionais da Red Hat segue o mesmo modelo dual de distribuição, com o Red Hat Enterprise Linux (RHEL) sendo uma distribuição comercial e o Fedora como um sistema Livre.

Debian é considerado uma distribuição Linux de altissima qualidade, com um forte compromisso com os ideiais do software de código aberto. Alguns derivados de distribuição Linux, como o popular Linux Ubuntu e o KNOPPIX são baseado no Debian. E embora o Debian é bom para utilizar-se em pequenas empresas, o projeto não tem uma infra-estrutura de empresas como (treinamento, suporte, documentação e assim por diante) que é construida em torno do SuSE Enterprise Linux e Red Hat Enterprise.

Sobre SuSE, Novell e Linux

SuSE (pronuncia-se SOO-zuh) é um Sistema Operacional Linux de propriedade da Novell, Inc. SuSE representado pela empresa de Software Alemã System-Entwicklung. o SuSE foi baseado no Slackware Linux, e tornou-se oficialmente uma distribuição independente em 1996, quando foi lançada a sua primeira versão:

SuSE  foi, e permanece, uma das distribuições de Linux mais popular da Europa.

Em novembro de 2003, a Novell adquriu o SuSE e incorporou a distribuição em seus projetos. Hoje existem 3 edições para o SuSE:

• SuSE Linux Enterprise Desktop (SLED) edição comercial, baseado em assinatura, produzido pela Novell, Inc. cujo objetivo é fornecer um ambiente de Desktop empresarial, oferecendo suporte, treinamentos, documentações, certificações de hardware, entre outros produtos.
• SuSE Linux Enterprise Server (SLES) tambem uma edição comercial, porem uma edição focada em servidores.
• openSuSE, uma versão de codigo aberto do SuSE, livre, e sem as opções de suporte ofertada pela Novell, foi iniciada pela Novell em 2005. openSuSE é uma comunidade do sistema operacional que é distribuida livremente e tornou-se conhecida pela sua estabilidade e suporte a hardware.

SuSE Linux

Depois que você ja teve alguma experiencia com linux, você nao precisa de alguem dizendo a você para clicar no botão ajuda ou para arrastar um arquivo para a lixeira para exclui-lo . O que você precisa é de um bom livro ou um site que mostrem comandos poderosos e as opções que permitem você controlar seu sistema Linux, como os processos, usuarios, media de armazenamento, recursos de redes, e serviços do sistema associados com tudo isso.

Como podem perceber sou um adpto da SuSE, gosto muito dessa distribuição, talvez por usar e acompanhar toda a sua evolução desde 1994 quando surgiu a versão 1.0 baseada no Slackware. Vou tentar nos proximos dias ou proximos meses quem sabe, passar varios conceitos e comandos do OpenSuSE e do SuSE Linux da Novell para ajudar a você a se tornar um usuario avançado em Linux. Se você é um administrador de Sistemas ou um usuario comum, esses artigos vai mostrar-lhes comandos para criar sistemas de arquivos, solucionar problemas de redes, aumentar o nivel de segurança, e mostrar muita coisa que você gostaria de saber sobre o seu sistema Linux.

Quem me inspiriou a escrever esse artigo foi Christopher Negus e Françõis Caen, que escreveram um livro chamado SUSE LINUX TOOLBOX (1000+ Commands for OpenSuSE and SUSE Enterprise, li o livro e gostei muito, eles estão de Parabens pela iniciativa, esse livro foi publicado nos Estados Unidos da America em Indianopolis e Simultaneamente no Canada, para os interessados na aquisição do Livro, procure no Amazon.com pelo ISBN: 978-0-470-08292-9.

Os artigos que vou escrever, foi inspirado nesse livro, e vai ser focado em comandos de linhas de comandos do openSuSE.

Uma breve historia da Novell’s com o SuSE

para saber mais, vá ate o link do wikipedia http://pt.wikipedia.org/wiki/OpenSUSE

O mais interessante da historia e poucos sabem é que existe um acordo de cooperação entre a Novell e a Microsoft que teve inicio em 2006 e com termino em 2011, porem ja foi renovado por mais 4 anos. O acordo previa a colaboração entre as duas empresas para que trabalhassem em direção ao suporte e interoperabilidade entre os sistemas operacionais Windows e Linux. É bom deixar claro que a Microsoft não contribui para o desenvolvimento do SuSE e tambem esse acordo não se extende ao OpenSuSE, somente ao SuSE Linux Enterprise da Novell.

Então até os proximos artigos,

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

Entendendo e Configurando o PAM

por Vishal Srivistava, Associate Software Engineer, IBM

Conceitos básicos sobre o Pluggable Authentication Module e como configurá-lo e gravar um aplicativo de login

Resumo:  A API do Pluggable Authentication Module (PAM) expõe um conjunto de funções que os programadores de aplicativos usam para funções relacionadas à segurança, como autenticação do usuário, criptografia de dados, LDAP, etc. Neste artigo, você terá um guia básico para o modelo do PAM no Linux, aprenderá a configurar o PAM e a designar um aplicativo de login do PAM de amostra em 10 etapas bem fáceis.

Para usuários Linux, compartilhar arquivos certamente é uma tarefa trabalhosa. Por exemplo, exige demais ter que lembrar de várias senhas e redesignar os aplicativos de acesso do sistema (como login, su, password, ftp , etc.) é demorado. Somando a essa dificuldade está o processo de autenticação, em que um sistema identifica um usuário e fornece controle de acesso ideal para esse usuário.

Um histórico do uso do PAM

O PAM é uma API que cuida da autenticação de um usuário para um serviço. Antes do PAM, aplicativos como login (e rlogin, telnet, rsh) procuravam pelo nome do usuário em /etc/passwd e depois comparavam os dois e autenticavam o nome digitado pelo usuário. Todos os aplicativos usavam esses serviços compartilhados, embora os detalhes da implementação e a autoridade para configurá-los não fossem compartilhados.

Em seguida, os desenvolvedores do aplicativo tentavam codificar seus próprios processos. Com isso veio a necessidade de separar o aplicativo e o módulo de segurança (um módulo de segurança comum pode ser compartilhado por aplicativos e ser configurado conforme necessário).

O mecanismo PAM integra vários esquemas de autenticação de nível inferior em uma API de nível superior que permite que os programas que dependem da autenticação sejam gravados independentemente do esquema de autenticação subjacente. O principal recurso do PAM e a configuração dinâmica da autenticação através de um arquivo /etc/pam.d ou /etc/pam.conf.

O PAM pode ser configurado para impedir que determinados programas autentiquem os usuários e para avisar quando determinados programas tentam fazer a autenticação. Os programas do PAM usam os módulos do PAM (módulos de autenticação): Eles são anexados aos aplicativos no tempo de execução para funcionar.

A Figura 1 mostra o fluxo básico do modelo do PAM.

Quais sistemas operacionais suportam o PAM?

O PAM foi desenvolvido primeiramente pela Sun Microsystems em 1995 e é suportado pelas seguintes versões de sistemas operacionais (e superior):

• RedHat 5.0
• SUSE 6.2
• Debian 2.2
• Mandrake 5.2
• Caldera 1.3
• TurboLinux 3.6

O PAM também é suportado por versões recentes do Solaris™, AIX®, HP-UX e Mac OS® X. Mais tarde, ele foi padronizado como parte do processo de padronização X/Open UNIX® (na arquitetura X/Open single sign-on service (XSSO)).

Que tipo de PAM posso obter?

Embora eles não sejam estritamente classificadas, podemos dizer que há três tipos de PAM:

1. Linux-PAM: O Linux-PAM abrange todo o PAM discutido neste artigo. A arquitetura principal do PAM em qualquer plataforma Unix é semelhante à versão PAM do Linux.
2. OpenPAM: O OpenPAM é outra implementação do PAM desenvolvida pelos laboratórios Dag-Erling Smorgrav em NAI como parte do programa de pesquisa DARPA-CHATS. Por ser um software livre, ele é usado principalmente pelo FreeBSD, NetBSD e por aplicativos (além do Mac OS X).
3. Java™ PAM ou JPam: O PAM é basicamente um módulo de autenticação padrão que suporta Linux e UNIX. O JPam atua como uma ponte entre a parte Java e o PAM comum. Ele permite o uso dos módulos ou recursos do PAM (como auth, account, passwd, session , etc.) pelos aplicativos baseados em Java. Ele fornece o JAAS e APIs diretas e suporte para a maioria dos sistemas operacionais e arquiteturas do Unix.

Embora esses sejam PAMs diferentes, a funcionalidade principal permanece a mesma.

Como são os módulos do PAM?

A instalação do PAM é um processo etapa por etapa. Consulte Recursos para obter instruções de instalação.

Os módulos do PAM são classificados por tipo de módulo. Qualquer módulo fornecido deve implementar pelo menos uma das quatro funções de tipo de módulo:

1. O módulo de autenticação é usado para autenticar usuários ou configurar/cancelar credenciais.
2. Os módulos de gerenciamento de conta executam ações relacionadas ao acesso, à expiração de conta e de credencial, restrições/regras de senha, etc.
3. O módulo de gerenciamento de sessão é usado para inicializar e terminar sessões.
4. O módulo de gerenciamento de senha executa ações relacionadas à alteração/atualização de senha.

O PAM fornece recursos funcionais diferentes, como autenticação de conexão única, controle de acesso, etc. A implementação de cada um é manipulada por módulos diferentes. A seguir há alguns dos principais módulos:

• pam_access fornece o controle de acesso de login log-daemon-style usando nome de login/domínio, dependendo das regras predefinidas no arquivo /etc/security/access.conf.
• pam_cracklib verifica as senhas em relação às regras de senha.
• pam_env sets/unsets verifica as variáveis de ambiente a partir de /etc/security/pam_env_conf.
• pam_debug depura o PAM.
• pam_deny bloqueia os módulos do PAM.
• pam_echo imprime as mensagens.
• pam_exec executa um comando externo.
• pam_ftp é o módulo para acesso anônimo.
• pam_localuser requer que o usuário seja listado em /etc/passwd.
• pam_unix fornece autenticação de senha tradicional de /etc/passwd.

Há vários outros módulos (pam_userdb, pam_warn, pam_xauth), que usam um conjunto de valores que eles retornam. (Os detalhes desses módulos podem ser obtidos no guia de administração do PAM em Recursos.)

Configurando o PAM

A configuração do PAM é geralmente implementada no arquivo de configuração que reside em /etc/pam.d ou /etc/pam.conf (para versões antigas).

A Estrutura do Arquivo de Configuração

Para cada serviço que usa o PAM, há um arquivo correspondente no diretório, que contém as regras ou as instruções sobre como as informações de autenticação e de conta devem ser obtidas para esse serviço. Geralmente há uma regra por linha.

Os campos nos arquivos de configuração do PAM incluem:

• Service_name Especifica o nome do serviço/aplicativo. (O padrão é OTHER.)
• Module_type especifica o tipo de módulo (auth/account/session/passwd) para o serviço correspondente no campo Service_name.
• Control_flag especifica o comportamento de pilha do módulo. Os seguintes valores podem ser usados: requisito, necessário, suficiente e opcional.
• Module_path especifica o nome do caminho para o objeto de biblioteca que implementa o módulo. Ele é configurado para /lib/security por padrão.
• Module_options/module_args (campos opcionais) especificam as opções ou os argumentos que podem ser passados para os módulos de serviços.

Os módulos são chamados na ordem em que eles são listados no arquivo de configuração, dependendo do que o Control_flag para cada entrada permite. Os valores de control_flag incluem:

• Requisite: Todos os módulos necessários em uma pilha devem ser aceitos como um resultado com êxito. Se um ou mais dos módulos necessários falharem, todos os módulos necessários na pilha serão implementados, mas o primeiro erro será retornado.
• Sufficient: Se um módulo sinalizado como suficiente obtiver êxito e nenhum módulo anterior ou suficiente falhar, todos os módulos restantes na pilha serão ignorados e o êxito será retornado.
• Optional: Se nenhum dos módulos na pilha for necessário e nenhum módulo suficiente obtiver êxito, pelo menos um módulo opcional do serviço/aplicativo precisa obter êxito.

Exemplos de Arquivos de Configuração do PAM

A Tabela 1 mostra alguns exemplos de arquivos de configuração do PAM em vários sistemas operacionais.

Sistema	Encontrado em …	Tipo	Controle (Flag)	Módulo
Red Hat	/etc/pam.d	auth	requerid	/lib/security/pam_unix.so
Red Hat	/etc/pam.d	account	sufficient	/lib/security/pam_unix.so
Red Hat	/etc/pam.d	session	required	/lib/security/pam_limit.so
AIX	/etc/pam.conf	auth	requerid	/usr/lib/security/pam_aix
AIX	/etc/pam.conf	account	required	/usr/lib/security/pam_aix
AIX	/etc/pam.conf	password	required	/usr/lib/security/pam_aix
zSUSE 64-bit | 32-bit	/etc/pam.conf	auth	required	/lib64/security/pam_unix.so | /lib/security/pam_unix.so
zSUSE 64-bit | 32-bit	/etc/pam.conf	account	required	/lib64/security/pam_unix.so | /lib/security/pam_unix.so
zSUSE 64-bit | 32-bit	/etc/pam.conf	session	required	/lib64/security/pam_unix.so | /lib/security/pam_unix.so
Solaris	/etc/pam.conf	auth	required	/usr/lib/security/pam_unix.so.1
Solaris	/etc/pam.conf	account	required	/usr/lib/security/pam_unix.so.1
Solaris	/etc/pam.conf	password	required	/usr/lib/security/pam_unix.so.1
HP-UX	/etc/pam.conf	auth	required	libpam_unix.so.1
HP-UX	/etc/pam.conf	account	required	libpam_unix.so.1
HP-UX	/etc/pam.conf	password	required	libpam_unix.so.1

 

O "Outro" Arquivo do PAM

O arquivo de configuração padrão do PAM /etc/pam.d é usado por todos os outros serviços que não são explicitamente configurados e talvez seja o arquivo padrão mais simples e robusto do qual o PAM depende. O conteúdo é semelhante ao seguinte:

/etc/pam.d/other File

auth        required     pam_warn.so
auth        required     pam_deny.so
account     required     pam_warn.so
account     required     pam_deny.so
password    required     pam_warn.so
password    required     pam_deny.so
session     required     pam_warn.so
session     required     pam_deny.so

O arquivo é muito simples. Para todos os tipos de módulo, Control_flag é o mesmo: required. Dois módulos são chamados: 

1. Primeiro, pam_warn.so é chamado para registrar informações sobre a tentativa em progresso.



2. Em seguida, pam_deny.so é chamado apenas para retornar uma falha e impedir que qualquer tipo de conexão ou de autenticação seja executado.

Portanto, qualquer serviço que use o PAM deve ser configurado explicitamente para permitir a autenticação, caso contrário, as tentativas falharão.

Dez etapas para designar um Aplicativo de Login Simples do PAM

Essas 10 etapas ajudam a implementar seu próprio aplicativo PAM e a entender as funções de uma sessão do PAM:

1. Inclua os arquivos de cabeçalho para a implementação PAM (por exemplo, pam_appl.h, pam_misc.h).



2. Na função main , inicialize a biblioteca do PAM libpam.so (que carrega os módulos especificados no arquivo de configuração para o aplicativo) usando um manipulador exclusivo.



3. Tente autenticação para todos os módulos e manipule os cenários de falha.



4. Verifique os detalhes de credencial e de conta do usuário.



5. Abra uma nova sessão do PAM.



6. Configure o ambiente para o usuário usando as credencias.



7. Quando o usuário estiver concluído, remova a configuração do ambiente do usuário.



8. Feche a sessão do PAM.



9. Saia da biblioteca libpam.so com o valor do identificador.



10. SAIR.

Conclusão

Depender do PAM para ajudar a lutar pelos esforços de autenticação de nível inferior em um todo mais gerenciável é uma maneira de simplificar esse mecanismo de segurança. Neste artigo, você aprendeu:

• A arquitetura básica do PAM



• Como configurar os módulos do PAM



• A descrição de um aplicativo de login do PAM como um guia para entender como eles funcionam.

Configuração do arquivo PAM

Quando um aplicativo PAM é iniciado, ele ativa o PAM-API.

Esta ativação realiza uma série de tarefas, sendo a mais importante a leitura do arquivo de configuração: /etc/pam.conf. alternativamente, este pode ser o conteúdo do diretório /etc/pam.d. A presença deste diretório fará com que PAM ignore o arquivo /etc/pam.conf.
Esses arquivos do PAM é que vai fazer as tarefas de autenticação.

Visão Geral do PAM

Para quem não conhece, nós começaremos por um exemplo. Uma aplicação que concede alguns serviços para os usuários; login é um programa. O Login faz duas coisas, ele primeiro verifica se o usuário solicitante é quem ele diz ser e segundo lhe fornece o serviço solicitado: no caso do login o serviço é um comando Shell (bash, tcsh, zsh, etc.) rodando com a identidade do usuário.

Tradicionalmente, o primeiro passo é realizado através da aplicação de Login que solicita ao usuário uma senha e então verifica se a autenticação confere com o sistema, se o usuário é quem diz ser, o sistema vai para o segundo passo. Esta é a tarefa que é delegada ao Linux-PAM.

Do ponto de vista do programador da aplicação (neste caso, a pessoa que escreveu a aplicação de Login), Linux-Pam cuida dessa tarefa de autenticação – verificar a autenticação do usuário.

A flexibilidade do Linux-PAM é que você, o administrador de sistema, tem a liberdade para estipular qual o esquema de autenticação será usado. Você tem a liberdade para configurar o esquema  para um ou todas aplicações PAM do seu Linux.

Isto é, você pode autenticar de qualquer coisa desde confiança simples (pam_permit) à algo paranoico como uma combinação de escaneamento de retina, autenticação por voz e uma simples senha.

Pam lida com quatro tipos distintos de gestão. Estes são: gerenciamento de autenticação; gerenciamento de contas; gerenciamento de sessão e gerenciamento de senhas.

A associação de gestão preferencial com o comportamento de uma aplicação é feita com entradas no arquivo de configurações do PAM.

A associação do sistema de gestão preferencial com o comportamento de uma aplicação é feita com entradas no arquivo de configuração relevantes Linux-PAM. As funções de gerenciamento são realizadas por módulos específicos no arquivo de configuração.

As funções de gestão são realizadas por módulos especificados no arquivo de configuração.

Abaixo uma ilustração que a organização geral do PAM:

+--------------------+
| Aplicação: X    |
+--------------------+           /   +------------+      +=============================+
|Autenticação-  [---->—\—]  Linux –  |—< |   Arquivo de Configuração PAM  |
|            +             [----<—/—]  PAM       |      |=============================|
| conversation()[—+      \   |                |      | X auth …… a.so                               |
+--------------------+    |          +-n—n-----+      | X auth …… b.so                               |
|                           |    |              |    |              |                                               _____ /
|     Usuário        |    A             |    |               |                                      -----‘   
|                           |     |             V   A               |_________________´
+--------------------+     + ---------|---|--------------------+----------------+-----------------+
                                           +----u---u--------+              |                      |                      |
                                           |   auth…           |--------[ a ]-------------[ b ]-------------[ c ]
                                           +------------------+
                                           |     acct …          |-------[ b ]--------------[ d ]
                                           +------------------+
                                           |   password    |--------[ b ]--------------[ c ]
                                           +------------------+
                                           |   session        |--------[ e ]--------------[ c ]
                                           +------------------+     

A titulo de explicação,  a esquerda da figure representa à aplicação; aplicação X. Tal interface de aplicativos com a biblioteca Linux-PAM e não conhece nenhuma das especificidades de seu método de autenticação configurado. A biblioteca Linux-PAM (no centro) consulta o conteúdo do arquivo de configuração do PAM e carrega os módulos que são apropriados para a aplicação X. Esses módulos dividem-se em um dos quatros grupos de gestão (inferior-centro) e são empilhados na ordem em que aparecem no arquivo de configuração. Estes módulos, quando chamado pelo PAM, executa tarefas de autenticação de diferentes aplicações. Informações textuais, exigidos ou oferecidos aos usuários, podem ser trocados através do uso do aplicativo fornecido pela função conversation.

Se um programa vai usar o PAM, então ele tem que ter funções PAM explicitamente codificadas no programa. Se você tem aceso aos código fontes você pode adicionar apropriadamente as funções PAM. Se você não tem acesso ao código fonte, e os binários não incluem funções do PAM, então não é possível usar o PAM.

Introdução ao PAM para Linux

Linux-PAM (Pluggable Authentication Modules for Linux) é uma coleção de bibliotecas compartilhadas que permite ao administrador de sistema escolher como a aplicação autentica os usuários.

Em outras palavras, sem recompilar uma aplicação adaptada ao PAM, é possível alternar entre o mecanismo de autenticação que ele usa. De fato, pode-se atualizar inteiramente o sistema de autenticação local em afetar os próprios aplicativos.

Historicamente uma aplicação exige que um determinado usuário seja autenticado, e para isso a aplicação teve que ser compilado para usar um mecanismo de autenticação específico. Por exemplo, no caso dos UN*X tradicionais, a identidade do usuário é verificada por uma senha que o usuário digita corretamente. Essa senha, depois de ter sido prefixada por duas vezes, é criptografada (com crypt). O usuário é então autenticado, se essa senha encriptada é idêntica ao segundo campo de entrada do usuário no banco de dados de senha do sistema (o arquivo /etc/passwd).  Na maioria dos sistemas UNIX se não todas, as formas de privilégios são feito com base neste sistema de autenticação único. Esse tipo de autenticação vem na forma de um identificador único de usuário (UID) e membros de vários grupos.
Serviços e aplicações são autenticados baseados na identificação (UID) e no grupo (GID) do usuário. Tradicionalmente, os membros dos grupos são baseado nas entradas do arquivo /etc/group.

Este é o objetivo do Projeto Linux-PAM para separar o desenvolvimento de permissões de privilégio de software do desenvolvimento de redes seguras e esquemas de autenticação apropriadas.  Isto é realizado através de uma biblioteca de funções que um aplicativo pode usar para solicitar que um usuário seja autenticado. Esta biblioteca PAM é configurada localmente com um arquivo de sistema, /etc/pam.conf (ou uma serie de arquivos locais em /etc/pam.d/) para autenticar uma solicitação do usuário dos módulos de autenticação disponíveis localmente. Os módulos são geralmente localizados no diretório /lib/security ou /lib64/security e toma a forma de arquivos de objetos carregável dinamicamente.

Informix–Conexão Segura

Pode-se administrar a segurança das conexões do servidor do banco de dados usando a autenticação e os processos de autorização.

Um usuário deve ser autenticado com uma instalação segura fornecendo um ID de usuário válido e uma senha segura que correspondam  as credenciais de uma conta de usuários do sistema operacional de onde esta instalado o Informix. Um tipo de método de autenticação é baseada no próprio sistema operacional, em que um ID de usuário e senha são passadas diretamente para o sistema operacional para verificação. Podemos também configurar as autenticações de conexões usando módulos de autenticação. Dependendo do sistema operacional, podemos usar um dos seguintes tipos de módulos de autenticação:

• Autenticação pelo PAM para Informix rodando em UNIX ou Linux. Podemos utilizar esse modulo para implementar mecanismos alternativos de autenticação. Você pode usar os módulos para implementar um mecanismo de autenticação alternativa que você cria para uma aplicação especifica.
• Suporte de autenticação à Lightweight Directory Access Protocol (LDAP) para Windows. Utilize o módulo LDAP  quando quiser utilizar a autenticação do informix pelo LDAP.

Usuários autenticados devem especificar um banco de dados ao qual se conectar. Um usuário pode executar ações em determinados banco de dados ou acessar objetos, desde que tenham sido autorizados pelo DBA. Por exemplo, usuários com privilégios de CONNECT pode se conectar a um banco de dados e executar consultas, enquanto que usuários com privilégios RESOURCE podem criar objetos.

Você pode garantir que senhas de autenticação de conexão são seguras, criptografando usando um módulo de suporte de comunicação (CSM).  O CSM com senha simples (SPWDCSM) fornece criptografia de senha.  SPWDCSM esta disponível para todas as plataformas.

Se quiser pode-se autenticar por um ambiente Single Sign-On  (SSO), pode-se usar também o Generic Security Services CSM (GSSCM) para implementar uma autenticação Kerberos. Além disso, o protocolo Kerberos tem vários recursos internos que podem proporcionar benefícios de segurança, mesmo que simples e senhas CSM criptografadas. Autenticação SSO verifica a identidade de um usuário,

SSO autenticação verifica a identidade de um usuário e facilita o gerenciamento centralizado de usuários e senhas. Se os serviços de confidencialidade e integridade estão habilitados no GSSCSM, o Kerberos criptografa as transmissões de dados e assegura que a troca de dados entre o usuário e o servidor de banco de dados seja uma conexão segura.

Conexões com o HDR não podem usar esses módulos de autenticações, mas pode funcionar com estes módulos, restringindo as portas de rede específica para a replicação e conexões de alta disponibilidade.

Pode-se configurar o IBM Informix para verificar se o ID do usuário que está executando o programa corresponde ao ID do usuário que está tentando se conectar ao banco de dados.

Você pode configurar o IBM Informix para verificar se o ID do usuário que está executando o programa corresponde ao ID do usuário que está tentando se conectar ao banco de dados.

Você pode limitar os ataques de negação de serviço para impedir que conexões legítimas para o servidor de banco de dados seja bloqueada.

Abaixo mais detalhes sobre a autenticação PAM

 

Pluggable authentication modules para sistemas rodando no UNIX ou Linux

O Pluggable Authentication Module (PAM) é uma estrutura de módulos muito bem definidas para suportar diferentes tipos de autenticação, originalmente desenvolvido pela Sun Microsystems. PAM é suportado em ambas plataformas de 32 e 64 bits, nos sistemas Solaris, Linux, HP-UX e AIX.

Administradores de Sistema pode usar o PAM para implementar diferentes mecanismos de autenticação para diferentes tipos de aplicações. Por exemplo, a autenticação de login no UNIX pode ser diferente da autenticação de um servidor de banco de dados. PAM permite muitos cenários em uma única maquina, porque os serviços de autenticação são aplicadas em camadas.

Administradores de Sistema pode usar o PAM para habilitar um aplicativo para selecionar o método de autenticação conforme exigido,

PAM para habilitar um aplicativo para selecionar o autenticação conforme exigido e empilhamento do modulo. Alguns módulos podem ser empilhados um após o outro, permitindo assim que a aplicação será autenticado de varias maneiras, antes de conceder acesso. PAM fornece um conjunto de APIs para suportar a autenticação, gerenciamento de contas, gerenciamento de sessões e gerenciamento de senhas.

O Administrador de Sistema pode habilitar ou desabilitar o uso do PAM.Por padrão, o servidor de banco de dados utiliza o mecanismo de autenticação tradicional do Informix ( que se baseia no mecanismo BSD – rhosts) a fim de evitar mudanças importantes para os utilizadores.

Para utilizar o PAM com o IBM Informix:

• O Banco de dados Informix deve estar em um Sistema Operacional que suporta o PAM.
• Aplicações Clientes deve ser escrito com um versão mais recente do SDK.
• O serviço do PAM deve estar devidamente configurado no Sistema Operacional.
• Deve-se decidir qual o método de autenticação que o PAM vai prover: conexão do cliente através de password, digitando uma senha correta em prompt ( por exemplo, um servidor de autenticação RADIUS) ou ambas as combinações.
• Linux somente: Quando configurar o PAM para exigir senha e autenticação baseada em resposta,  o serviço do PAM sempre ignora a senha enviada na solicitação de conexão do cliente e pede a senha uma segunda vez.
• Você deve garantir que a Replicação e clusters de alta disponibilidade não serão afetadas pela autenticação PAM.
• Deve-se modificar o arquivo sqlhosts no servidor, tanto para a aplicação quanto para o servidor de bando de dados;

O serviço PAM

O serviço PAM identifica o módulo PAM.

O módulo PAM tipicamente esta localizado no diretório /etc/security e seus parâmetros são listados no arquivo /etc/pam.conf.

No Linux, o arquivo /etc/pam.conf pode ser substituído por um diretório chamado /etc/pam.d, onde há um arquivo para cada serviço. Se /etc/pam.d existe, /etc/pam.conf é ignorado pelo Linux.

Métodos de autenticação com o módulo PAM

O módulo PAM determinará se um usuário poderá autenticar-se fornecendo uma senha, respondendo corretamente a um desafio ou ambos.

A implementação PAM no IBM Informix tira proveito do fato de que as solicitações de conexão explicita, o cliente envia uma senha para o servidor. Pode-se configurar o PAM para fazer esta senha o único requisito para autenticação no servidor.

Quando configurar o PAM para usar o protocolo baseado em resposta, a autenticação é concluída depois que o usuário digita a resposta correta para uma pergunta ou outra. Com este modo de autenticação um aplicativo deve ser projetado para responder ao desafio corretamente antes de conectar ao servidor de banco de dados. Pode-se configurar a autenticação do PAM para utilizar somente o modo baseado em resposta, de forma que o PAM ignore as senhas de conexão do cliente.

Linux somente:  Se o PAM é configurado para utilizar o protocolo baseado em resposta, a senha vindo dos clientes são sempre ignoradas. O serviço PAM no Linux pede a senha do usuário uma segunda vez se ambos os modos de autenticação estão habilitados.

Tamanho necessário da pilha para o PAM

Pode-se customizar o tamanho das pilhas disponíveis para o módulos do PAM.

O PAM carrega recursos do Sistema Operacional ou módulos do PAM fornecidos por terceiros (bibliotecas compartilhadas) para as threads do Informix. Os requisitos do tamanho das pilhas não podem ser previsto. Para uma instancia, no Linux alguns módulos exigem mais do que 128 KB de espaço de pilha. Use o parâmetro de configuração PAM_STACKSIZE para modificar o valor.

Por exemplo, configure o parâmetro PAM_STACKSIZE no arquivo onconfig como abaixo:

PAM_STACKSIZE 64        # Stack size needed for the PAM modules (Kbytes)

No UNIX, o valor padrão do PAM_STACKSIZE é 32 KB.

No Linux, o valor padrão é 128 KB mais o valor do STACKSIZE.

Configurando um servidor de banco de dados para utilizar o PAM

Para configurar um servidor para utilizar o PAM, o administrador de sistemas devera saber:

• O nome do modulo PAM;
• Se o módulo PAM esta utilizando o método baseado em respostas além de aceitar um nome de usuário e senha.

Abaixo um exemplo do arquivo sqlhosts configurado para utilizar a autenticação PAM baseado em resposta:

prdsoc onsoctcp isis prdsrv s=4, pam_serv=(pam_cha1), pamauth=(challenge)

Abaixo um exemplo do arquivo sqlhosts configurado para utilizar a autenticação PAM baseado em autenticação com senhas:

prdsoc onsoctcp isis prdsrv s=4, pam_serv=(pam_pass), pamauth=(password)

Processadores PA-RISC ( Precision Architeture Risc)

Todos os HP 9000 da serie 800 utilizavam a tecnologia “Precision Architecture Risc (PA-Risc)”. O PA-RISC esta construído dentro dos princípios de Reduced instruction Set Computing (RISC) o que implica a implementação de poucos componentes fornecendo uma confiabilidade superior que quando comparado com sistemas CISC (Complex Instruction Set Computer).

Os estudos mostram que equipamentos CISC gastavam 80% do tempo executando instruções simples (soma, subtração, etc) e os restantes 20% em operações complexas, fazendo uso ainda dos microcódigo (microcódigo: ocorre o acesso à instrução e dentro do processador tem um código que acessa o hardware). No Risc isso não acontece porque tudo já é executado em hardware (elimina microcódigo) as instruções complexas ficam por conta do compilador e todas as operações são feitas em registradores.

A base do PA-RISC é um set de instruções contendo 140 instruções de formato fixo cuidadosamente selecionadas.

O paralelismo de instruções, pipelining (técnica que sobre passa o processamento de instruções, de modo que uma instrução pode iniciar sua execução antes que a anterior tenha terminado) é utilizado eficientemente pelo HP PA-RISC em 5 estágios, aliados a compiladores otimizados e ao seu projeto Load/Store, melhoram a execução de instruções em um único ciclo e expandem a performance do sistema.

O PA-RISC utiliza o sistema operacional HP-UX que é o sistema operacional SYSTEM V da AT&T com implementações desenvolvidas pela Hewlett-Packard como: gráficos, suporte a linguagem nativa e algumas construções do Unix BSD.

O Hardware do PA-Risc

Certas operações do sistema, como o boot, podem necessitar da especificação do endereço de hardware. Portanto, é interessante que os administradores de sistemas conheça a configuração de seu hardware com os respectivos endereços.

Cada periférico possui um único endereço de hardware que identifica a path de conexão da CPU para o device propriamente dito. Essa path é composta pelo endereço de todos os elementos que aparecem entre a CPU e o periférico.

SPU – System Processing Unit. São as unidades de processamento do sistema, sendo basicamente a CPU e memoria.

BUS – São circuitos através do qual os dados trafegam entre os módulos do hardware (CPU, Memoria, Chanel Adapter, device adapter). As placas dos periféricos são conectadas no bus. As maquinas de BUS HP-PB (HP-Precision Bus) com exceção da 890, utilizam somente um BUS, já o modelo 890 utiliza 2 estruturas de BUS; PMB (Processor Main Bus) para processador e memória e HP-PB para I/O.

SLOTS – Local físico onde serão conectados as placas. Cada slot tem um número/letra. Nas maquinas HP-PB, todos os slots são conectados no Bus de precisão.

Device Adapter – É a interface que liga o Bus ao periférico, são conhecidos também I/O cards. Os principais devices adapters são:

• SCSI – Small Computer System Interface. Tecnologia nova que trabalha com conect/desconect para o Bus, permitindo que periféricos de velocidade diferentes sejam conectados a mesma placa (Discos, Fitas, DVDs, etc).
  Pode-se conectar até 7 devices SCSI para cada adaptador (endereçados de 0 a 6): O ultimo device SCSI deve ter um terminador. O comprimento do cabo não deve exceder 6m.
• HP-IB – HP Interface Bus – Suporta Discos, Fitas, drivers DVD-ROM, impressoras e ploters. Este Device Adapter tem função para aqueles que possuem periféricos HP-IB antigos e querem aproveita-los. Uma desvantagem deste Device Adapter é o fato de não permitir a conexão de periféricos com velocidades diferentes ( Discos e Fitas por exemplo).
  Pode-se conectar até 4 discos HP-IB. O comprimento do cabo não deve exceder 20m, para interface de velocidade padrão e 15m, para alta velocidade.
  Um extensor pode ser utilizado para transmissões a distancia entre SPU e o periférico atingido, até 1.25km (exceto para discos).
• MUX – Suporta qualquer ligação serial RS-232, plotters, Access Port e alguns podem ligar modems. Podem ser de 8 e de 16 saídas. O comprimento do cabo pode estar entre 5 e 15 m.
• LAN – Local Área Network. Conecta redes padrão Ethernet e IEEE 802-3.
• GPIO – General Purpose I/O. Device Adapter utilizado para Conectar periféricos específicos.
• PSI – Placa programável onde se carrega os protocolos IBM SNA ou X25.

Processadores Itanium

Tambem Conhecido como IA-64 foi desenvolvido pela Intel e HP, para plataformas SMP de 64 bits “puro-sangue”.

A tecnologia Itanium não usa a arquitetura RISC nem CISC, na verdade a Intel criou uma nova arquitetura chamada de EPIC. Aqui se inicia a 8ª Geração de Processadores.

Esse processador é incompatível com Sistemas Operacionais desenvolvidos para os processadores da linha X86-64, pois estes são compatíveis com 32 e 64 bits.

Fontes de Pesquisas: wikipedia.org, clube do hardware, documentos do site da HP e Intel

Historia do Itanium

História

Desenvolvimento: 1989-2000

Em 1989, a HP determinou que as arquiteturas reduced instruction set computer (RISC) estavam se aproximando do limite de processamento de uma instrução por ciclo.

A HP começou a estudar  uma nova arquitetura, mais tarde nomeado Explicitly Parallel instruction Computing (EPIC).

Essa arquitetura permite que o processador execute múltiplas instruções em cada ciclo de clock. Essa arquitetura de very long instruction word (VLIW), em que uma única palavra de instrução contém instruções múltiplas. Com a EPIC, o compilador determina antecipadamente quais instruções podem ser executadas ao mesmo tempo, tão simplesmente o microprocessador executa as instruções e não precisa definir mecanismos para determinar quais as instruções executar em paralelo.

O principal objetivo desta abordagem é primeiramente permitir uma mais profunda inspeção do código, identificando oportunidades adicionais para execução paralela, e, depois, para simplificar o design do processador e reduzir o consumo de energia, eliminando a necessidade de circuitos de programação para o tempo de execução.

A HP determinou que já não era rentável para os sistemas individuais corporativos das empresas, como ela própria, desenvolver microprocessadores proprietários, então a HP buscou uma parceria com a Intel em 1994 para desenvolver a arquitetura IA-64, que derivou da EPIC. Intel estava disposta a empreender um esforço de desenvolvimento muito grande na IA-64, na expectativa de que o microprocessador resultante seria utilizado pela maioria dos fabricantes de sistemas das empresas. A HP e a Intel deram início a um grande esforço de desenvolvimento conjunto com a meta de entregar o primeiro produto, Merced, em 1998. Durante o desenvolvimento, Intel, HP e analistas da indústria previram que IA-64 iria dominar servidores, workstations e desktops high-end, e eventualmente suplantar as arquiteturas RISC e complex instruction set computer (CISC) para todos os aplicativos de uso geral. A Compaq e Silicon Graphics decidiu abandonar desenvolvimento das arquiteturas Alpha e MIPS, respectivamente, com intenção de migrar para IA-64. Vários grupos desenvolveram sistemas operacionais para a arquitetura, incluindo Microsoft Windows, Linux e variantes UNIX, tais como HP-UX, Solaris, Tru64 UNIX, e Monterey/64 (as três últimas foram canceladas antes de chegar ao mercado). Em 1997, tornou-se evidente que a arquitectura IA-64 e o compilador eram muito mais difíceis de implementar do que se pensava inicialmente, e a entrega de Merced começou a escorregar. As dificuldades técnicas incluindo o transistor de altas contagens necessárias para apoiar as largas instruções e os caches de grandes dimensões. Houve também problemas estruturais no âmbito do projecto, como os dois elementos da equipe conjunta utilizarem métodos diferentes e terem diferentes prioridades. Desde que o Merced foi o primeiro processador EPIC, o esforço de desenvolvimento encontrou mais problemas imprevistos do que a equipe estava acostumada. Além disso, o conceito EPIC depende de capacidade do compilador que nunca haviam sido implementadas antes, de forma que mais investigação era necessário. A Intel anunciou o nome oficial do processador Itanium, em 4 de outubro de 1999. Em poucas horas, o nome Itanic havia sido cunhado em um newsgroup da Usenet, uma referência ao Titanic, o "transatlântico inafundável" que afundou em 1912. Itanic desde então tem sido frequentemente utilizado por The Register, Scott McNealy, e outros[o que implica que o investimento multibilionário no Itanium e à enorme expectativa precoce seria seguido por sua morte relativamente rápida.

Itanium (Merced): 2001

Até o momento que o Itanium foi lançado em junho de 2001, seu desempenho não era superior aos concorrentes processadores RISC e CISC. O Itanium competiu no low-end (principalmente 4-CPU e sistemas menores) com servidores baseados em processadores x86, e em high-end com arquitetura IBM, POWER e a Sun Microsystems com arquitetura SPARC. A Intel reposicionou o Itanium para focalizar no negócio high-end e computação HPC, na tentativa de duplicar o sucesso horizontal do x86 no mercado (isto é, única arquitetura, vários fornecedores de sistemas). O sucesso desta versão do processador inicial foi limitada a substituir PA-RISC em sistemas HP, Alpha em sistemas Compaq e MIPS em sistemas SGI, embora a IBM também entregou um supercomputador baseado neste processador. POWER and SPARC manteve-se forte, enquanto a arquitetura 32-bit x86 continuou a crescer para dentro do espaço da empresa. Com as economias de escala, alimentada pela sua enorme base instalada, x86 manteve-se o eminente "horizonte" na arquitetura em computação empresarial. Apenas alguns milhares de sistemas que usam o processador Itanium original “Merced” foram vendidos, devido ao desempenho relativamente fraco, alto custo e disponibilidade de software limitado. Reconhecendo que a falta de software poderia ser um problema sério para o futuro, a Intel fez milhares destes primeiros sistemas disponíveis para os fornecedores de software independentes (ISVs) para estimular o desenvolvimento. HP e Intel trouxe a próxima geração do processador Itanium 2 ao mercado um ano depois.

Itanium 2: 2002-presente

Itanium 2 em 2003

O processador Itanium 2 foi lançado em 2002, e foi comercializado para servidores corporativos e não para toda a gama de computadores high-end. O primeiro Itanium 2, com o codinome de McKinley, foi desenvolvido em conjunto pela HP e Intel. Ele aliviava muitos dos problemas de desempenho do processador Itanium original, que foram causados por um subsistema de memória ineficiente. McKinley continha 221 milhões de transistores, dos quais 25 milhões foram para a lógica, medido 19,5 milímetros de 21,6 mm (421mm 2)e foi fabricadas em 180 nm, volume de processamento CMOS com seis camadas de metalização de alumínio. Em 2003, a AMD lançou o Opteron, que implementou a sua arquitetura de 64-bit (x86-64). Opteron ganhou rápida aceitação no mercado de servidores corporativos porque forneceu uma atualização fácil de x86. A Intel respondeu através da implementação da arquitetura x86-64 em seus microprocessadores Xeon em 2004. A Intel lançou um novo Itanium 2 membro da família, codinome Madison, em 2003. Madison usava um processo de 130 nm e foi a base de todos os novos processadores Itanium até Montecito ser lançado em junho de 2006. Em março de 2005, a Intel anunciou que estava trabalhando em um novo processador Itanium, codinome Tukwila, a ser lançado em 2007. Tukwila teria quatro núcleos de processador e substituirá o BUS do Itanium com uma nova interface comum de sistemas, que também seria usado por um novo processador Xeon. Mais tarde naquele ano, a Intel revisa a data de entrega do Tukwila para final de 2008. Em novembro de 2005, os principais fabricantes de servidores Itanium se juntaram com a Intel e um número de fornecedores de software para formar o Itanium Solutions Alliance para promover a arquitetura e acelerar a portabilidade de software. A Aliança anunciou que seus membros iriam investir US $ 10 bilhões em soluções Itanium no final da década. Em 2006, a Intel entregou o Montecito, um processador dual-core, que praticamente dobrou o desempenho e diminuiu o consumo de energia por cerca de 20 por cento. A Intel lançou a versão Itanium atual, codinome Montvale, em novembro de 2007. Em maio de 2009, o cronograma para Tukwila, e seu acompanhamento foi novamente revisto, com liberação para OEMs prevista para o primeiro trimestre de 2010. Em comparação com a família de processadores Xeon Server, Itanium não é um produto de alto volume para Intel. A Intel não divulgou o número de produção, mas um analista da indústria estima que a taxa de produção foi de 200.000 processadores por ano em 2007. Segundo o Gartner, o número total de servidores Itanium vendidos por todos os fornecedores em 2007 foi de cerca de 55.000. Isso se compara com os 417.000 servidores RISC (espalhados por todos os vendedores RISC) e 8,4 milhões de servidores x86. De 2001 a 2007 a IDC reporta que um total de 184.000 sistemas baseados em Itanium foram vendidos. Para o mercado de sistemas, o combinado POWER / SPARC / Itanium, em um relatório da IDC informa que o POWER captou 42% e SPARC captou 32%, enquanto as receitas baseadas no sistema Itanium chegaram a 26% no segundo trimestre de 2008. De acordo com um analista da IDC, em HP 2007 representou, talvez, 80% das receitas sistemas Itanium. Segundo o Gartner, a HP em 2008 representaram 95% das vendas Itanium.

A Intel tem amplamente documentado o conjunto de instruções de processadores e microarquitetura, e da imprensa técnica forneceu revisões. A arquitetura foi renomeado várias vezes durante sua história. HP inicialmente chamou-PA-WideWord. Intel mais tarde chamou IA-64, depois de processadores Itanium Architecture (IPA), antes de se estabelecer em Intel Itanium Architecture, mas ainda é amplamente referido como IA-64. É uma arquitetura de 64 bits, totalmente paralela rica em registros. A base da palavra de dados é de 64 bits, byte endereçável. O espaço de endereçamento lógico é 2 64 bytes. A arquitetura implementa pressuposição, especulação, e previsão de desvio. Ele usa um mecanismo de hardware para renomeação de registro, em vez de simples registo de janelas para a passagem de parâmetro. O mesmo mecanismo também é utilizado para permitir a execução paralela de loops. Especulação, previsão, pressuposição, e renomeação estão sob o controle do compilador: cada instrução inclui bits extras para isso. Esta abordagem é a característica distintiva da arquitetura. A arquitetura implementa 128 registros inteiros, 128 registros de ponto flutuante, 64 pressuposição de um bits, e oito registros derivados. Os registros de ponto flutuante de 82 bits preserva a precisão dos resultados intermediários.

Execução da instrução

Cada instrução 128-bit contém três instruções, e a busca do mecanismo pode ler as duas instruções por clock do cache L1 no pipeline. Quando o compilador pode tirar o máximo proveito deste, o processador pode executar seis instruções por ciclo de clock. O processador tem trinta unidades de execução funcional em onze grupos. Cada unidade pode executar um subconjunto específico do conjunto de instruções, e cada unidade é executado a uma taxa de uma instrução por ciclo de execução, a menos barreiras à espera de dados. Embora nem todas as unidades de participação em um grupo executam subconjuntos idênticos do conjunto de instruções, instruções comuns podem ser executadas em várias unidades.

Os grupos de unidade de execução incluem:

• Seis ALUs de propósito geral, duas unidades integras, uma unidade de mudança
• Quatro unidades de dados de cache
• Seis unidades de multimídia, duas unidades de deslocamento paralelo, um multiplicador paralelo, uma contagem de população
• Duas unidades com ponto flutuante de 82-bits com acumulação-múltipla, Duas unidades com ponto flutuante SIMD com acumulação-múltipla (duas operações de 32-bit cada)
• Três unidades derivadas

O compilador pode freqüentemente agrupar instruções em conjunto de seis que podem ser executadas ao mesmo tempo. Desde que a unidades de ponto flutuante implemente uma operação de acumulação-múltipla, uma instrução de um único ponto flutuante pode executar o trabalho de duas instruções quando a aplicação requer uma multiplicação seguido por um acréscimo (Isto é muito comum em processamento científico). Quando isso ocorre, o processador pode executar quatro FLOPS por ciclo. Por exemplo, a 800 MHz Itanium tiveram uma avaliação teórica de 3,2 g FLOPS e os mais rápidos processadores Itanium 2, a 1,67 GHz, foi avaliado em 6,67 GFLOPS.

Arquitetura de Memória

De 2002 a 2006, os processadores Itanium 2 compartilhavam uma hierarquia de cache comum. Eles tinham 16 KiB de cache L1 de instruções e 16 KiB de Nível 1 cache de dados. A cache L2 foi unificada (tanto de instruções e dados) e é de 256 KiB. A cache de nível 3 também foi unificada e varia em tamanho de 1,5 MiB a 24 MiB. Os 256 KiB de cache L2 contém lógica suficiente para lidar com operações de semáforo sem perturbar a unidade lógica aritmética principal (ALU). A memória principal é acessada através de um BUS para uma off-chip chip set. O Itanium 2 BUS foi inicialmente chamado de McKinley BUS, mas agora é normalmente referido como o Itanium BUS. A velocidade do BUS vem aumentando com lançamentos novos processadores. As transferências de BUS 2 × 128 bits por ciclo de clock, então a 200 MHz BUS McKinley transfere 6,4 GiB / s), e os 533 MHz BUS Montecito transfere17,056 GiB / s Alterações de arquitetura Processadores Itanium lançado antes de 2006 tinha suporte de hardware para o IA-32 arquitetura para permitir suporte para aplicativos de servidor legado, mas o desempenho para o código IA-32 era muito pior do que para o código nativo e também pior do que o desempenho dos processadores x86 contemporâneos. Em 2005, a Intel desenvolveu o IA-32 Execution Layer (IA-32 EL), um emulador de software que fornece um melhor desempenho. Com Montecito, da Intel, portanto, eliminado suporte de hardware para IA-32 do código. Em 2006, com o lançamento do Montecito, a Intel fez uma série de melhorias para a arquitetura do processador de base, incluindo:

• Hardware multithreading: Cada núcleo do processador mantém contexto para duas linhas de execução. Quando uma barreira de contexto aparece durante o acesso a memória, o outro segmento pode executar. Intel chama isso de “coarse multithreading” para distingui-lo da tecnologia hiper-threading, A Intel integra em alguns processadores x86 e x86-64. “Coarse multithreading” está bem adaptado à arquitetura Intel Itanium e resulta em um ganho de desempenho significativo.
• Suporte de hardware para virtualização: Intel adicionou Intel Virtualization Technology (Intel VT), que fornece ao hardware assistências para funções de virtualização do núcleo. A virtualização permite que um software “hypervisor” para executar várias instâncias do sistema operabcional do processador simultaneamente.
• Melhorias Cache: Montecito acrescentado um cache L2 dividido, que incluí 1 cache L2 dedicado MiB para obter instruções. O original 256 KiB de cache L2 foi convertido para um cache de dados dedicado. Montecito também incluídos até 12 MiB de cache on-die L3.

Suporte de Hardware

A partir de 2009 Vários fabricantes oferecem sistemas Itanium, incluindo HP, SGI, NEC, Fujitsu, Hitachi, e Groupe Bull. Além disso, a Intel oferece um chassi que podem ser usados por integradores de sistema para construir sistemas Itanium. A HP, o único dos principais fabricantes da indústria de quatro servidores para oferecer sistemas baseados em Itanium, hoje, produz pelo menos 80% de todos os sistemas Itanium. A HP teve 7200 sistemas vendidos no primeiro trimestre de 2006. A maior parte dos sistemas vendidos são servidores corporativos e máquinas para a computação em larga escala técnica, com um preço médio de venda por sistema extra de E.U. $ 200.000. Um sistema típico utiliza oito ou mais processadores Itanium.

Chipsets

A Interface BUS Itanium se comunica com o restante do sistema através de um chipset. Fabricantes de servidores Enterprise diferenciam seus sistemas através da concepção e desenvolvimento de chipsets que a interface do processador de memória, interligações, e os controladores de periféricos. O chipset é o coração do sistema de arquitetura de nível para cada projeto do sistema. Desenvolvimento de um chipset custa dezenas de milhões de dólares e representa um importante compromisso para a utilização do Itanium. A IBM criou um chipset em 2003, e a Intel em 2002, mas nenhum deles desenvolveu chipsets para suportar novas tecnologias como DDR2 ou PCI Express... atualmente, existem chipsets modernos para sistemas de apoio às tecnologias, como são fabricados pela HP, Fujitsu, SGI, NEC e Hitachi. O próximo processador Itanium (Tukwila) foi desenhado para compartilhar um chipset comum com o processador Intel Xeon EX (processador Intel Xeon projetado para quatro processadores e servidores maiores). O objetivo é agilizar o desenvolvimento do sistema e reduzir os custos para OEMs de servidor, muitos dos quais desenvolvem tanto para servidores Itanium quanto para Xeon.

O mais novo processador Intel Itanium série 9300 (Tukwila)

Os servidores baseados em Itanium fornecem desempenho escalável e poderoso para ambientes de UNIX e mainframe, e também excelente disponibilidade para as suas aplicações mais críticas. Esses sistemas são ideais para as cargas de trabalho mais intensas de hoje, como aplicações de banco de dados, inteligência corporativa e planejamento de recursos corporativos (ERP).

O mais novo processador Intel Itanium série 9300 fornece mais do dobro do desempenho da geração anterior, além de até seis vezes mais largura de banda de memória, até nove vezes mais largura de banda de interconexão e até oito vezes mais capacidade de memória. Fornece uma incrível escalabilidade e uma base poderosa, flexível e com maior eficiência energética para virtualização, consolidação e gerenciamento de carga de trabalho do data center.

Configuração de Clusters

Para configurar seu sistema  como um cluster de alta disponibilidade, você deve tomar as seguintes ações:

• Conheça os requisitos de Hardware e Sistema Operacional;
• Conheça os requisitos do Banco de Dados;
• Conheça os requisitos do Servidor de Banco de dados;
• Configuração da Conectividade.

 

Cada item desses tópicos serão explicados abaixo.

Você pode configurar seu sistema para usar o protocolo SSL (Secure Sockets Layer), um protocolo de comunicação que garante a privacidade e integridade dos dados transmitidos através da rede, para comunicação HDR. Você pode usar o protocolo SSL para conexão entre o servidor primário e secundário e para conexões com RS (Remote Standalone) e SD (Shared Disk) de servidores secundários em uma configuração de alta disponibilidade. Para obter informações de como usar o protocolo SSL, veja a sessão “Secure Sockets Layer Communication Protocol Encryption” do IBM Informix Security Guide.

 

Requisitos de Hardware e Sistema Operacional

Para o funcionamento do cluster de alta disponibilidade, o hardware deve atender certos requisitos.

O hardware deve atender aos seguintes requisitos:

• O servidor primário e secundário deve ser capaz de executar a mesma imagem do IBM Informix, mesmo que eles não tenha hardware ou o sistema operacional idêntico.  Por exemplo, você pode usar servidores com diferentes sistemas operacionais Linux de 32 bits, porque esses sistemas operacionais pode executar a imagem do Informix. Nessa situação, você não pode adicionar um server com um Linux 64-bit porque esse sistema operacional requer uma imagem de Informix diferente. Cheque o arquivo “machine notes”: você pode usar qualquer combinação de hardware e sistema operacional listado nesse arquivo.
• O hardware que roda como primário e secundário deve suportar redes.
• A quantidade de espaço em disco alocado para os dbspaces no servidor primário e secundário devem ser iguais. O tipo de espaço em disco é irrelevante; você pode usar uma mistura de raw device com file system.
• Os chunks em cada servidores devem ter os mesmos caminhos. Links simbólicos são permitidos para a plataforma UNIX, mas não para a plataforma Windows.

Requisitos do Banco de Dados

O Banco de dados deve atender os seguintes requisitos:

• Todos os dados devem ser logged.
  Todos os bancos de dados que vai ser replicado devem estar em modo transacional.
  
  Este requisito é importante  porque o servidor de banco de dados secundário usa registros de logical-log vindo do servidor primário para atualizar os dados que ele gerencia. Se o banco de dados gerenciado pelo servidor primário não esta em modo transacional, para esse banco de dados não será gerado registros de logs,  sendo assim o servidor de banco de dados secundário não terá meios para atualizar os dados.
• Os dados devem residir no mesmo dbspace ou sbspaces.
  Se o seu banco de dados primário tem objetos armazenados em blobspaces, modificações nos dados dentro desses blobspaces não é replicado como parte normal do processamento HDR. No entanto, objetos grandes mas simples são replicados.
  Objetos grandes, que são armazenados em sbspaces, são replicados. Os sbspaces devem estar em modo transacional. Tipos definidos por usuários (UDTs) são replicados, a menos que estejam armazenados em arquivos do sistema operacional. Tipos de dados com out-of-row são replicados se os dados estão armazenados em sbspace ou em uma tabela diferente no mesmo servidor de banco de dados.
• O servidor secundário não pode usar compressão de disco.
  Se você usar o recurso do Informix de compressão de disco, dados que são comprimidos na tabela de origem vão ser comprimidos nas tabelas de destino. Você não pode executar compressão no HDR secundário, RS secundário ou SD secundário, porque o HDR destino deve ter as mesmas configurações de dados e físico como o servidor de origem
  

Requisitos do Servidor do Banco de Dados

Para um par cluster de servidores de alta disponibilidade funcionar, você deve configurar totalmente cada um dos servidores. Você pode então usar os aspectos relevantes para configurar os pares de servidores.

Estes tópicos descrevem as considerações de configuração a seguir para os pares de cluster:

• Versão do Banco de dados;
• Configuração do dbspace e chunk;
• Tamanhos de paginas não padrão em um ambiente HDR;
• Espelhamento;
• Configuração do Physical-log;
• Dbspace e dispositivo de backup para logical-log;
• Configuração do Logical-log
• Parâmetros de configurações do HDR;

Versão do Banco de dados

As versões do Informix no servidor primário e secundário deve ser idêntica.

Configuração do dbspace e chunk

o numero de dbspaces, o numero de chunks, seus tamanhos, seus caminhos e seus offsets devem ser idênticos no servidor de banco de dados primário e secundário. Além disso, a configuração deve conter pelo menos um dbspace temporário se o servidor HDR secundário for usado para criação de relatórios de atividades.

Somente no UNIX:

Você poderá usar links simbólicos para os chunks.

Importante: Se você não utilizar links simbólicos para os chunks, você não poderá alterar os caminhos facilmente

Os seguintes parâmetros no ONCONFIG deve ter o mesmo valor em cada servidor de banco de dados:

• ROOTNAME
• ROOTOFFSET
• ROOTPATH
• ROOTSIZE

Tamanhos de paginas não padrão em um ambiente HDR

O tamanho de paginas de um dbspace e as especificações de buffer são automaticamente propagadas a partir do servidor primário para o secundário. Embora ambos os servidores devem ter o mesmo buffer pools, o numero de buffer no buffer pool não precisam corresponder.

Espelhamento

Você não deve configurar o parâmetro MIRROR  para o mesmo valor nos dois servidores de banco de dados; você pode habilitar espelhamentos em um servidor de banco de dados e desabilitar o espelhamento no outro. Entretanto, se você especificar um chunk espelho para um chunk root do servidor primário, você deve também especificar um chunk espelho para o chunk root do servidor secundário. Portanto, os seguintes parâmetros do ONCONFIG devem ser configurados com o mesmo valor em ambos os servidores:

• MIRROROFFSET
• MIRRORPATH

Configuração do Physical-log

O Physical-log deve ser idêntico em ambos os servidores. Os seguintes parâmetros do ONCONFIG devem ter os mesmos valores em cada servidores:

• PHYSBUFF
• PHYSFILE

Dbspace e dispositivo de backup para logical-log

Você pode especificar diferentes dispositivos para o servidor primário e secundário.

Se você usar o ON-Bar, configure os parâmetros de configuração do ON-Bar com os mesmos valores em ambos os servers. Para informações dos parâmetros do ON-Bar veja o IBM Informix Backup and Restore Guide.

Se você usa o ontape, o tamanho e o bloco do dispositivo devem ser idênticos. A seguir os parâmetros do ONCONFIG que devem ser o mesmo valor em ambos os servidores:

• LTAPEBLK
• LTAPESIZE
• TAPEBLK
• TAPESIZE

Configuração do Logical-log

Todos os registros de logs são replicados para o servidor secundário. Você pode configurar o mesmo numero de Logical-log e também com o mesmo tamanho em ambos os servidores. A seguir os parametros do ONCONFIG que devem ser o mesmo valor em ambos os servidores:

• LOGBUFF
• LOGFILES
• LOGSIZE
• DYNAMIC_LOGS

Logical-logs que são adicionados dinamicamente no servidor primário são replicados automaticamente para o servidor secundário. Embora o valor de DYNAMIC_LOGS no servidor secundário não tem nenhum efeito, DYNAMIC_LOGS mantem em sincronia com os valores do servidor primário.

Parâmetros de configurações do HDR

Os seguintes parâmetros de configuração do HDR devem ser definidos com valores iguais em ambos o servidores:

• DRAUTO
• DRINTERVAL
• DRTIMEOUT

Para servidores secundários em cluster de alta disponibilidade HDR, RSS e SDS, Logical-log  em tabelas temporárias devem sempre ser desativado, definindo o parâmetro de configuração TEMPTAB_NOLOG a 1.

A Arquitetura Multithreaded

O que é uma Thread?

Uma Thread é uma sequencia de instruções sendo executadas em um programa.

Antes, observaremos a arquitetura do servidor, pois é útil examinar o conceito usual de uma thread.

Uma thread pode ser interpretada como uma sequencia de instruções sendo executadas em um programa. Quando múltiplas thread são executadas em uma mesma entidade (no nosso caso, um processo), ela é chamada de multithreading.

Single-Threaded vs. Multithreaded

 

Um processo regular UNIX que não implementa threads pode ser pensado como um processo single-threaded, apesar de não ser chamado assim. Uma sequencia de instruções é executada para este processo, e o sistema operacional é responsável por agendar e executar esses processos.

Multithreading é um método de muitas execuções repetidas de um processo para diferentes usuários sem ter que formar muitas instancias daquele processo ao nível do sistema operacional.

Um processo multhreaded pode ter threads múltiplas pesquisando dentro de um processo UNIX, cada um executando sequencialmente e dando o controle para outras threads em um ponto especifico de tempo. A forma como uma arquitetura multithread é executada é o que difere de uma arquitetura de single-thread recebendo e executando solicitações de um processo de um único usuário.

Multithreading é um conceito ao nível do sistema por onde os programas realmente executam instruções ao nível da maquina para manipular os processos, então esse é executado para vários usuários ao invés de apenas um. O programa executa estas instruções totalmente ao nível do usuário, e não nível do Kernel do UNIX. Longe de afetar o UNIX, um processo em arquitetura multithread é um processo único, como qualquer outro processo.

Um programa Single-Threaded

Considerar como o UNIX trabalha com multiprocessamento.

Cada processo UNIX tem um espaço de endereço consistindo em três segmentos: text, data e stack. O segmento text contem a instrução da maquina que gera o programa de codificação executável. Os segmentos stack contem variáveis locais usada pelos programas funcionais. Finalmente, o segmento data contem o programa global e as variáveis estáticas, strings, array e outros dados.

Em uma maquina monoprocessada que esteja executando 1000 processos, somente um processo esta sendo executado pelo UNIX em algum momento. Cada processo esta sendo executado dentro de uma quantidade especifica de tempo antes dele ser pré-desocupado (interrompido) pelo kernel de maneira que o próximo processo agendado possa ser executado. Quando um processo em execução é pré-desocupado, devem ser salvas informações suficientes de maneira que o processo possa ser reiniciado mais tarde. Esta informação é chamada de context do processo. O context consiste basicamente dos seguintes componentes:

• O program counter, o qual especifica o endereço das próximas instruções a serem executadas.
• O stack pointer, o qual contem o endereço atual da próxima entrada no stack.
• O general purpose registers, os quais contem os dados gerados pelo processo durante essa execução.

Existem outros componentes do context do processo UNIX, chamado de system level context, porem não vamos abortar, pois não são críticos para a compreensão de multithreading.

Um Context Switch (Alternância de Contexto)

Em UNIX, um context switch ocorre quando um processo em execução é interrompido pelo sistema operacional. Para fazer isto, o sistema operacional salva, correntemente, o context do processo em execução em estruturas de dados pré-alocadas em memoria e carrega o contexto do próximo processo agendado.

Carregar o context envolve restauração do program counter, o stack pointer e todos os general purpose registers para os valores salvos pelo sistema operacional na ultima vez que o processo em execução foi pré-desocupado. Uma vez completo, o processo continua sua execução a partir da linha de código especificada pelo program counter.

Um processo Multithreaded

O processo multithread, cada thread tem o seu próprio context, isto é, seu próprio local no código ( program counter ) e suas próprias variáveis de dados. Um processo multithread trabalha muito parecido com o sistema operacional na maneira da troca de um context de uma thread para outra.

O próprio processo executa instruções de maquinas para realizar uma copia da thread executada no momento e trazer a próxima thread agendada. Isto permite basicamente o mesmo resultado que o sistema operacional alcança fazendo um context switch. O resultado é que o program counter aponta para uma nova instrução dentro do segmento text, o stack pointer aponta para uma diferente área de memoria  e os general purpose register são restaurados para os valores previamente salvados por este context. No caso do IDS Multithreading, o stack de uma thread é mantido em shared memory para se mover entre os processos do servidor (virtual processors). O tamanho padrão de stack é 32 kilobytes por cada userthread. O servidor verifica o overflow do stack e automaticamente expande o tamanho stack.

Uma vez que o processo multithread age como um mini sistema operacional, ele é responsável por manter coisas do tipo:

• Agendamento: a thread  atual decide quando ceder controle de um processo e transferir controle para outra thread. A thread atual tambem decide qual a próxima thread que será executada baseado em mecanismo de prioridade interno.
• Troca de Context: quando a thread atual decide que é a hora de executar outra thread, ele deve executar instruções de maquina para efetuar a troca de context entre as threads.

Agendamentos e a troca de context ainda são efetuados pelo UNIX normalmente. O processo multithread efetua agendamento e a troca de context de threads. Mantenha estes dois conceitos separados.

Virtual Processors

Os processos que compõe o database server são conhecidos para Virtual Processors. Cada VP pertence a um virtual processor class. Um VP class é um grupo de processos responsáveis por um conjunto especifico de tarefas (na forma de threads), como, por exemplo, gravar para o logical log ou ler dados do disco. Isto quer dizer que um VP de uma certa classe pode somente pesquisar thread de uma mesma classe. Uma classe de VP pode ter um ou mais VPs, a qual na maior parte dos casos é configurada pelo administrador do sistema. O nome de um VP executável é oninit. Todos os VPs de todas as classes são exemplos de mesmo programa, oninit.

Executando uma Thread

Uma Thread esta sendo executada em um processador particular, ou esta em uma de uma serie de filas. As filas ready (ready queues) mantem os contexts de threads esperando para executa-los em um processador. Quando um processador esta livre, ele obterá o context de uma thread de uma ready queue. Ha um mecanismo de prioridade interno que determina qual thread o processador obterá da fila. O processador os substitui o context atual com o context da nova thread e continua o processamento daquela thread.

As ready queues são compartilhadas entre processadores de mesma classe de modo que uma thread possa migrar entre vários processadores durante sua existência (apesar do server tender em manter a execução de uma thread em um mesmo processo). Este mecanismo mentem o trabalho balanceado entre os processos e garante que uma thread será executada se algum processador estiver disponível.

Passando o controle para outra Thread

A um ponto especifico de execução, a thread cede o controle do processador para outra thread. Algumas ações comuns que poderiam fazer a thread ceder são:

• Aguardando por uma operação de leitura ou de gravação no disco;
• Aguardando por uma solicitação do processo de aplicação;
• Aguardando por um lock ou outro recurso;
• Não há mais trabalho a fazer.

Uma thread tambem poderia ceder o controle por nenhuma razão, além de dar a uma outra thread uma chance de ser executada.

Quando um thread cede controle, ela é responsável pela colocação de seu próprio context em uma de muitas filas de espera (wait queue) ou uma fila de aguardo (sleep queue). As wait queue são usadas basicamente para esperar uma operação. As sleep queues são usadas por threads que necessitam ser reativadas depois de um período de tempo.

O processador, então, pega o context de uma thread qualquer de uma ready queue e a substitui seu context com a nova thread. O processador continua a execução com o novo context.

Vantagens das Threads do Servidor

Algumas das vantagens do server threads são listadas abaixo:

• São necessários poucos processos para fazer o mesmo trabalho. Este é particularmente eficiente em um ambiente OLTP quando há um grande numero de usuários. Você pode pensar nisto como fan-in, onde há um grande numero de processos de aplicação com um pequeno numero de processos do database server suportando suas solicitações. Uma vantagem adicional é que um sistema que pode suportar mais usuários porque ha menos processos que necessitam ser suportados pelo sistema operacional.
• Além das capacidades fan-in, o server tambem oferece uma capacidade fan-out. Múltiplos processos do database server podem fazer o trabalho por uma aplicação.
• A arquitetura multithreaded substitui muito a troca do context feito pelo sistema operacional com a troca do context feitos pelos processos dentro do database server. Uma troca de context é mais rápido quando feito dentro de um processo porque ha menos informações para trocar.
• O processo do database server faz o seu próprio agendamento de thread. Isto dignifica que o DBMS, a frente do que o sistema operacional determina a prioridade de tarefas.
• Algumas características oferecidas por um sistema multi-processado fazem deste tipo de arquitetura, muito mais eficiente. Por exemplo, nós poderíamos dar um importante processo do database server direitos exclusivos para usar um processador em partilhar.

Fan-out

Uma das vantagens do server está em suas capacidades fan-out. Isto significa que usuários podem levar vantagens de múltiplos processadores do database server (e múltiplos CPUs, se disponível) trabalhando simultaneamente para fazer o trabalho deles.

o Server criará múltiplas threads que farão o trabalho de um usuário para as operações seguintes:

• Ordenação
• Indexação
• Recuperação