Page 1

OpenSolaris

TUTORIAL

OpenSolaris, parte 15 Desbravando o framework de serviços no OpenSolaris. por Alexandre Borges

A

Sun Microsystems, com o lançamento do Solaris 10, mudou radicalmente a maneira de gerenciar os serviços do sistema e esta alteração foi, sem dúvidas, para melhor. Isto fez com que o OpenSolaris também fosse concebido com este novo modelo de tratamento de serviços. Serviços estes, que em muitas tarefas, facilita a vida do administrador. O novo framework, SMF (Service Management Facility) incorpora comandos mais fáceis e intuitivos para analisar e operar os serviços, economizando muito tempo de administração. Algumas das melhorias adicionadas nesta nova infraestrutura de serviços são: Repositório centralizado para configuração do comportamento de cada serviço, assim como para armazenamento do status deste.

Linux Magazine #68 | Julho de 2010

 og individual para cada serviço. L Mecanismo mais simples para descobrir as dependências entre os serviços. Informação mais detalhada dos serviços, motivos de não funcionamento ou má configuração. Mecanismos de “restart” associado: se um serviço parar por razão não determinada, é reiniciado automaticamente. Possibilidade de serviços multiinstanciais, ou seja, com mais de uma cópia do mesmo na memória. Maior facilidade operacional na administração dos serviços.

O novo framework de serviços tem como origem de operação a daemon svc.startd que é iniciada no boot da máquina, mais precisamente, é o script /etc/init que a chama através do arquivo /etc/inittab.

Os serviços, que já se enquadram no modelo do Solaris 10 assim como no formato System V (Solaris 7, 8 e 9) podem ser visualizados em uma máquina com OpenSolaris (listagem 1). Nesta listagem dos serviços (reduzida para fins didáticos) aparecem quatro colunas, onde é possível visualizar os conceitos de serviços. A primeira coluna expõe o status de cada serviço. É curioso notar que, logo no início, há um status bem estranho chamado “legacy_run”. Este status está indicando que o serviço é legado, ou seja, não está no padrão SMF e sim no padrão System V. Qualquer outro serviço que não esteja neste status é um serviço já adaptado dentro do SMF. Os outros status possíveis para serviços são: Uninitialized: Este é o status inicial de todo o serviço no 67


TUTORIAL  | OpenSolaris

OpenSolaris. Dificilmente o leitor visualizará este status, pois ele ocorre apenas na subida do sistema; O ffline: Neste status, o serviço está habilitado para rodar, mas

ainda não está em execução ou não está disponível para ser executado. O administrador não consegue colocar nenhum serviço neste status apenas o próprio OpenSolaris;

Listagem 1: Serviços do OpenSolaris # svcs -a | more STATE STIME legacy_run 16:38:14 legacy_run 16:38:15 legacy_run 16:38:15 legacy_run 16:38:15 legacy_run 16:38:16 legacy_run 16:38:16 legacy_run 16:38:16 disabled 16:37:35 disabled 16:37:35 disabled 16:37:35 disabled 16:37:36 disabled 16:37:38 disabled 16:37:38 disabled 16:37:38 disabled 16:37:38 disabled 16:37:38 disabled 16:37:38 disabled 16:37:38 disabled 16:37:38 disabled 16:37:40 disabled 16:37:40 disabled 16:37:40 disabled 16:37:41 disabled 16:38:15 disabled 16:38:15 disabled 16:38:15 disabled 16:38:15 disabled 16:38:15 disabled 16:38:15 disabled 16:38:16 disabled 16:38:16 online 16:37:35 online 16:37:36 online 16:37:36 online 16:37:38 online 16:37:42 online 16:37:46 online 16:37:54 online 16:37:54 online 16:37:55

FMRI lrc:/etc/rc2_d/S20sysetup lrc:/etc/rc2_d/S47pppd lrc:/etc/rc2_d/S72autoinstall lrc:/etc/rc2_d/S73cachefs_daemon lrc:/etc/rc2_d/S81dodatadm_udaplt lrc:/etc/rc2_d/S89PRESERVE lrc:/etc/rc2_d/S98deallocate svc:/network/physical:default svc:/system/device/mpxio-upgrade:default svc:/system/metainit:default svc:/system/svc/global:default svc:/network/smb/client:default svc:/system/metasync:default svc:/system/console-login:vt2 svc:/system/console-login:vt4 svc:/system/console-login:vt3 svc:/system/vtdaemon:default svc:/system/console-login:vt5 svc:/system/console-login:vt6 svc:/network/ipv6-forwarding:default svc:/network/ipv4-forwarding:default svc:/network/device-discovery/printers:snmp svc:/network/dns/server:default svc:/network/rexec:default svc:/network/ftp:default svc:/network/stdiscover:default svc:/network/login:eklogin svc:/network/login:klogin svc:/network/login:rlogin svc:/network/shell:default svc:/network/shell:kshell svc:/system/svc/restarter:default svc:/network/loopback:default svc:/network/datalink-management:default svc:/system/filesystem/root:default svc:/network/ipsec/ipsecalgs:default svc:/system/boot-archive:default svc:/system/filesystem/usr:default svc:/system/device/local:default svc:/system/filesystem/minimal:default

Listagem 2: Milestones online online online online online online online

68

23:39:24 23:39:26 23:39:26 23:39:27 23:39:36 23:39:40 23:39:42

svc:/milestone/network:default svc:/milestone/devices:default svc:/milestone/single-user:default svc:/milestone/name-services:default svc:/milestone/sysconfig:default svc:/milestone/multi-user:default svc:/milestone/multi-user-server:defaul

O nline: Este é o mais simples de todos. O serviço está sendo executado e todas as dependências foram satisfeitas; D egraded: Neste status o serviço está rodando, porém sua capacidade está limitada, ou seja, ele não está oferecendo tudo que poderia oferecer de suas vantagens; D isabled: O serviço não está rodando ou foi desabilitado pelo administrador. Quando isto ocorre, o serviço é paralisado na hora e também não rodará nos próximos boot; M aintenance: Certamente este é o pior status, pois o serviço está habilitado, mas não é capaz de rodar devido a algum problema de configuração ou dependência não atendida por outros serviços.

O segundo campo, STIME (start time), indica o horário que o serviço foi iniciado. Se o início do serviço não ocorreu nas últimas 24 horas, será indicada a data da ocorrência. O terceiro campo, FMRI (fault management resource identifier), é o mais importante. Ele funciona como um tipo de localizador para o serviço, muito similar a ideia da URL para a Internet. A estrutura de uma FMRI é a seguinte: svc://<categoria>/<nome do serviço>:instância

O prefixo svc indica que o serviço é gerenciado pelo SMF. A categoria indica a classificação daquele serviço. As categorias existentes mais comuns são:

legacy application milestone network platform site

http://www.linuxmagazine.com.br


OpenSolaris | TUTORIAL

s ystem device

Eventualmente há a ocorrência de subcategorias de serviço, todavia a ideia é exatamente a mesma da afirmada em categoria. E a instância? A ideia da instância é a mesma de quando um programador trabalha com o conceito de classes em linguagens como o Java e que são orientadas a objetos: cria-se uma classe representando um objeto e seus atributos, sendo que esta classe serve como um “template”. Depois, instancia-se esta classe, criando de fato o objeto. Com serviços é a mesma coisa, sendo que a maioria dos serviços tem apenas uma instância chamada “default”. Com objetivo de exemplificar, seguem dois exemplos de FMRI que representam serviços: svc:/network/ftp:default

Esta fmri representa o serviço de ftp, que pertence a categoria de serviço network e que tem apenas uma instância: default. No segundo exemplo, vamos mostrar um caso de serviço multiinstância, ou seja, com mais do que uma instância: svc:/system/console-login:vt2 svc:/system/console-login:vt4 svc:/system/console-login:vt3

Neste caso, a categoria é system, o nome do serviço é console-login, e existem 3 instâncias: vt2, vt3 e vt4 que na verdade, como vimos anteriormente, são cópias deste serviço na memória. Já revelamos antes que no OpenSolaris não se fala mais em “runlevel” e sim em “milestone” e estes milestones são, de fato, uma categoria de serviço. Sendo desta forma, o OpenSolaris trabalha com diversos milestones (listagem 2).

Linux Magazine #68 | Julho de 2010

Perceba que existem diversos milestones e alguns deles tem certo grau de relacionamento com os antigos runlevels:

single-user é equivalente ao runlevel “s”; m ulti-user é equivalente ao runlevel “2”; multi-user-server é equivalente ao runlevel “3”.

Os demais milestones são responsáveis por segmentos de serviços específicos do sistema e o nome de cada milestone já explicita seu

segmento. Neste conceito de milestone, note que o OpenSolaris trata algumas área do sistema operacional como montagem de filesystems (svc:/milestone/devices:default), placas de rede/firewall (svc:/milestone/network:default) e serviços de nome tais como ldap, nis, nisplus – todos na parte cliente (svc:/milestone/name-services:default) sendo como um serviço também. Estes milestones listados não são os únicos presentes no OpenSolaris mas os criados por padrão. Nos próximos tutoriais de OpenSolaris veremos sobre xVM Hypervisor e

Listagem 3: Serviços NFS # svcs -a | grep nfs disabled 23:39:09 disabled 23:39:09 online 23:39:35 online 23:39:36 online 23:39:37 online 23:39:42 online 23:39:42

svc:/network/nfs/cbd:default svc:/network/nfs/client:default svc:/network/nfs/mapid:default svc:/network/nfs/status:default svc:/network/nfs/nlockmgr:default svc:/network/nfs/rquota:default svc:/network/nfs/server:default

Listagem 4: Serviços Cron # svcs -l cron fmri svc:/system/cron:default name clock daemon (cron) enabled true state online next_state none state_time Thu Apr 22 23:39:27 2010 logfile /var/svc/log/system-cron:default.log restarter svc:/system/svc/restarter:default contract_id 39 dependency require_all/none svc:/system/filesystem/local (online) dependency require_all/none svc:/milestone/name-services (online)

Listagem 5: Serviços dependentes do Cron # svcs -D cron STATE STIME disabled 23:39:11 disabled 23:39:11 disabled 23:39:11 disabled 23:39:11 disabled 23:39:11 online 23:39:40

FMRI svc:/system/filesystem/zfs/auto-snapshot:frequent svc:/system/filesystem/zfs/auto-snapshot:hourly svc:/system/filesystem/zfs/auto-snapshot:daily svc:/system/filesystem/zfs/auto-snapshot:weekly svc:/system/filesystem/zfs/auto-snapshot:monthly svc:/milestone/multi-user:default

69


TUTORIAL  | OpenSolaris

com isso surgirá outro milestone, o svc:/milestone/xvm. Avançando um pouco mais na parte operacional do SMF, vamos explorar o comando svcs cuja finalidade é sempre verificar algum tipo de informação/status relacionado aos serviços e o comando svcadm que altera o status dos serviços. Ao invés de nos atermos à sintaxe, estamos mostrando as opções dos comandos junto com algum serviço real. A tarefa mais usual é verificar se algum serviço específico está funcionando. A melhor maneira de fazer isto é usando o comando svcs: # svcs -a | grep cron online 23:39:27 svc: /system/cron:default

Repare que o filtro grep, neste caso é a melhor opção, pois podem haver diversos serviços cujo nome tem a palavra cron e com isto, fica simples apontar o status do serviço que realmente queremos. É claro que, no caso do cron, só existe uma única fmri com esta string, mas no caso do nfs, isto não é verdade , como você pode ver nas listagens 3 e 4. Esta saída é bastante esclarecedora, pois mostra que o serviço de cron tem um arquivo de log próprio (/var/svc/log/system-cron:default. log), um restarter associado (svc:/ system/svc/restarter:default) e dois outros serviços de que o cron depende para funcionar. Todos os logs dos serviços do OpenSolaris estão localizados sob o diretório /var/svc/log, com cada ser-

Listagem 6: Serviços de milestones # svcs -d svc:/milestone/devices:default STATE STIME FMRI online 23:39:22 svc:/system/device/local:default online 23:39:26 svc:/system/device/fc-fabric:default # svcs -d svc:/milestone/network:default STATE STIME FMRI disabled 23:39:07 svc:/network/physical:default disabled 23:39:07 svc:/network/ipfilter:default disabled 23:39:08 svc:/network/ipsec/manual-key:default disabled 23:39:08 svc:/network/ipsec/ike:default online 23:39:08 svc:/network/loopback:default online 23:39:10 svc:/network/physical:nwam online 23:39:13 svc:/network/ipsec/ipsecalgs:default online 23:39:24 svc:/network/ipsec/policy:default

Listagem 7: Milestones multi-user-server # svcs -D svc:/milestone/multi-user:default STATE STIME FMRI disabled 23:39:11 svc:/system/filesystem/zfs/auto-snapshot:frequent disabled 23:39:11 svc:/system/filesystem/zfs/auto-snapshot:hourly disabled 23:39:11 svc:/system/filesystem/zfs/auto-snapshot:daily disabled 23:39:11 svc:/system/filesystem/zfs/auto-snapshot:weekly disabled 23:39:11 svc:/system/filesystem/zfs/auto-snapshot:monthly online 23:39:40 svc:/system/intrd:default online 23:39:42 svc:/milestone/multi-user-server:default online 23:39:49 svc:/application/graphical-login/gdm:default

70

viço tendo seu próprio log. Também boa parte dos serviços têm associado um restarter cuja função é reiniciar este serviço caso algo estranho pare ou paralise o mesmo. Faremos um teste interessante. Em um terminal, abra o log do cron da seguinte forma: # tail -f /var/svc/log/systemcron:default.log

Em um segundo terminal, tente parar o serviço utilizando o comando pkill: # pkill cron

Podemos observar no primeiro terminal, que o restarter do OpenSolaris que está associado ao cron reinicia o serviço. Esta não é a maneira mais adequada de encerrar o cron (apesar de ser assim que fazíamos em sistemas com serviços no modelo System V). Não existe apenas este restarter no OpenSolaris, porém ele é o mais comum. Se o leitor executar diversas vezes, de forma bem rápida, o comando pkill cron, o restarter vai notar que algo errado está ocorrendo com o cron e, ao invés de reiniciálo, irá colocá-lo em manutenção (maintenance). Ainda no comando svcs -l, note que as duas últimas linhas mostram quais são os serviços precisam estar no ar para que o cron seja iniciado. Existe outra maneira de fazer a mesma coisa: # svcs -d cron STATE STIME FMRI online 23:39:27 svc:/ milestone/name-services:default online 23:39:27 svc:/system/ filesystem/local:default

Descobrir quais são as dependências de um serviço ou seja, quais outros são necessários que estejam online antes que o serviço desejado

http://www.linuxmagazine.com.br


OpenSolaris | TUTORIAL

esteja online, tornou-se uma tarefa muito fácil e útil. Se invertermos a lógica: quais serviços dependem do cron? Aí o comando é o mostrado na listagem 5. Já estes dois comandos trazem uma perspectiva ótima, pois podemos analisar quais são os serviços que compõem um milestone (listagem 6). E, de maneira mais instrutiva, entender que o milestone multi-user (equivalente ao runlevel 2) vem antes do milestone multi-user-server (runlevel 3 da listagem 7). Outros argumentos também são valiosos para o comando svcs como a opção -x, usada abaixo com o serviço cron, e que traz mais informações sobre o mesmo em caso de problemas e quais man pages verificar para informações completas do serviço: # svcs -x cron svc:/system/cron:default (clock daemon (cron)) State: online since Fri Apr 23 01:55:58 2010 See: cron(1M) See: crontab(1) See: /var/svc/log/systemcron:default.log Impact: None.

É possível ainda rodar o mesmo comando, entretanto sem explicitar o serviço e, neste caso, o OpenSolaris traz uma relação de quais são os serviços que estão enfrentando problemas: # svcs -x

O número do processo do cron pode ser obtido usando: # svcs -p cron STATE TIME FMRI online 1:55:58 svc:/system/ cron:default 1:55:58 1071 cron

Linux Magazine #68 | Julho de 2010

O pid (process id) do cron é 1071. Até este ponto foi demonstrado como obter informações sobre os serviços. A partir de agora, veremos como alterar seus status. Para parar um serviço de maneira definitiva, isto é, agora e nos próximos boots, utiliza-se: # svcadm disable <fmri do serviço>

Não é necessário os sinais de maior/menor, aqui apenas foi utilizado para apontar que é necessário colocar a FMRI do serviço desejado. Se a intenção for paralisá-lo apenas agora, mas permitindo ele reiniciar normalmente no próximo boot: # svcadm disable -t <fmri do serviço>

Restaurar o serviço é simples: # svcadm enable <fmri do serviço>

Se o serviço não iniciar, pois há dependências que ainda estão desabilitadas, é possível habilitar o serviço de forma recursiva, ou seja, fazendo com que primeiro suas dependências iniciem e depois o próprio serviço seja colocado no ar: # svcadm enable -r <fmri do serviço>

Para reiniciar um serviço que já está no ar (comando stop seguido de start), faça: # svcadm restart <fmri do serviço>

Em Unix, quando é preciso que um serviço releia seus arquivos de configuração associados, é comum usar pkill -HUP <serviço>. Usando SMF do OpenSolaris isto é realizado assim: # svcadm refresh <fmri do serviço>

Embora seja usual o sistema operacional colocar um serviço em manutenção quando o mesmo apresenta algum tipo de problema (de configuração ou dependência), o administrador também consegue fazer o mesmo de forma a sinalizar alguma dificuldade de operação com o serviço: # svcadm mark maintenance <fmri do serviço>

Objetivando tirar um serviço de manutenção e colocá-lo online novamente, utiliza-se o comando: # svcadm clear <fmri do serviço>

Se o serviço continuar em manutenção é porque ainda há alguma coisa errada com ele.  n

Sobre o autor Alexandre Borges (alex_sun@terra.com.br, twitter: @ale_sp_brazil) é Especialista Sênior em Solaris, OpenSolaris e Linux. Trabalha com desenvolvimento, segurança, administração e performance desses sistemas operacionais, atuando como instrutor e consultor. É pesquisador de novas tecnologias e assuntos relacionados ao kernel.

Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br Este artigo no nosso site: http://lnm.com.br/article/3601

71

http://www.linuxmagazine.com.br/images/uploads/pdf_aberto/LM_68_67_71_05_tut_opensol  

http://www.linuxmagazine.com.br/images/uploads/pdf_aberto/LM_68_67_71_05_tut_opensol.pdf