OpenSolaris, parte 15

Transcrição

1 OpenSolaris OpenSolaris, parte 15 Desbravando o framework de serviços no OpenSolaris. por Alexandre Borges TUTORIAL 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. Log individual para cada serviço. 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

2 TUTORIAL OpenSolaris OpenSolaris. Dificilmente o leitor visualizará este status, pois ele ocorre apenas na subida do sistema; Offline: Neste status, o serviço está habilitado para rodar, mas Listagem 1: Serviços do OpenSolaris Listagem 2: Milestones 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; # svcs -a more legacy_run 16:38:14 lrc:/etc/rc2_d/s20sysetup legacy_run 16:38:15 lrc:/etc/rc2_d/s47pppd legacy_run 16:38:15 lrc:/etc/rc2_d/s72autoinstall legacy_run 16:38:15 lrc:/etc/rc2_d/s73cachefs_daemon legacy_run 16:38:16 lrc:/etc/rc2_d/s81dodatadm_udaplt legacy_run 16:38:16 lrc:/etc/rc2_d/s89preserve legacy_run 16:38:16 lrc:/etc/rc2_d/s98deallocate disabled 16:37:35 svc:/network/physical:default disabled 16:37:35 svc:/system/device/mpxio-upgrade:default disabled 16:37:35 svc:/system/metainit:default disabled 16:37:36 svc:/system/svc/global:default disabled 16:37:38 svc:/network/smb/client:default disabled 16:37:38 svc:/system/metasync:default disabled 16:37:38 svc:/system/console-login:vt2 disabled 16:37:38 svc:/system/console-login:vt4 disabled 16:37:38 svc:/system/console-login:vt3 disabled 16:37:38 svc:/system/vtdaemon:default disabled 16:37:38 svc:/system/console-login:vt5 disabled 16:37:38 svc:/system/console-login:vt6 disabled 16:37:40 svc:/network/ipv6-forwarding:default disabled 16:37:40 svc:/network/ipv4-forwarding:default disabled 16:37:40 svc:/network/device-discovery/printers:snmp disabled 16:37:41 svc:/network/dns/server:default disabled 16:38:15 svc:/network/rexec:default disabled 16:38:15 svc:/network/ftp:default disabled 16:38:15 svc:/network/stdiscover:default disabled 16:38:15 svc:/network/login:eklogin disabled 16:38:15 svc:/network/login:klogin disabled 16:38:15 svc:/network/login:rlogin disabled 16:38:16 svc:/network/shell:default disabled 16:38:16 svc:/network/shell:kshell 16:37:35 svc:/system/svc/restarter:default 16:37:36 svc:/network/loopback:default 16:37:36 svc:/network/datalink-management:default 16:37:38 svc:/system/filesystem/root:default 16:37:42 svc:/network/ipsec/ipsecalgs:default 16:37:46 svc:/system/boot-archive:default 16:37:54 svc:/system/filesystem/usr:default 16:37:54 svc:/system/device/local:default 16:37:55 svc:/system/filesystem/minimal:default 23:39:24 svc:/milestone/network:default 23:39:26 svc:/milestone/devices:default 23:39:26 svc:/milestone/single-user:default 23:39:27 svc:/milestone/name-services:default 23:39:36 svc:/milestone/sysconfig:default 23:39:40 svc:/milestone/multi-user:default 23:39:42 svc:/milestone/multi-user-server:defaul Online: Este é o mais simples de todos. O serviço está sendo executado e todas as dependências foram satisfeitas; Degraded: 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; Disabled: 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; Maintenance: 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 :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 68

3 OpenSolaris TUTORIAL system 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 Open- Solaris 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). Perceba que existem diversos milestones e alguns deles tem certo grau de relacionamento com os antigos runlevels: single-user é equivalente ao runlevel s ; multi-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 Listagem 3: Serviços NFS 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 # svcs -a grep nfs disabled 23:39:09 svc:/network/nfs/cbd:default disabled 23:39:09 svc:/network/nfs/client:default 23:39:35 svc:/network/nfs/mapid:default 23:39:36 svc:/network/nfs/status:default 23:39:37 svc:/network/nfs/nlockmgr:default 23:39:42 svc:/network/nfs/rquota:default 23:39:42 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 next_state none state_time Thu Apr 22 23:39: 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 () dependency require_all/none svc:/milestone/name-services () Listagem 5: Serviços dependentes do Cron # svcs -D cron 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 23:39:40 svc:/milestone/multi-user:default 69

4 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 23:39:27 svc: /system/cron:default Listagem 6: Serviços de milestones Listagem 7: Milestones multi-user-server # svcs -d svc:/milestone/devices:default 23:39:22 svc:/system/device/local:default 23:39:26 svc:/system/device/fc-fabric:default # svcs -d svc:/milestone/network:default 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 23:39:08 svc:/network/loopback:default 23:39:10 svc:/network/physical:nwam 23:39:13 svc:/network/ipsec/ipsecalgs:default 23:39:24 svc:/network/ipsec/policy:default # svcs -D svc:/milestone/multi-user:default 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 23:39:40 svc:/system/intrd:default 23:39:42 svc:/milestone/multi-user-server:default 23:39:49 svc:/application/graphical-login/gdm: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 serviç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 Open- Solaris 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 23:39:27 svc:/ milestone/name-services:default 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 antes que o serviço desejado 70

5 OpenSolaris TUTORIAL esteja, 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: O pid (process id) do cron é 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 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 Restaurar o serviço é simples: Para reiniciar um serviço que já está no ar (comando stop seguido de start), faça: # svcadm restart <fmri do Em Unix, quando é preciso que um serviço releia seus arquivos de configuração associados, é comum usar pkill -HUP <. Usando SMF do OpenSolaris isto é realizado assim: # svcadm refresh <fmri do 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: # svcs -x cron svc:/system/cron:default (clock daemon (cron)) State: since Fri Apr 23 01:55: 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 1:55:58 svc:/system/ cron:default 1:55: cron # svcadm enable <fmri do 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 Sobre o autor # svcadm mark maintenance <fmri do Objetivando tirar um serviço de manutenção e colocá-lo novamente, utiliza-se o comando: # svcadm clear <fmri do Se o serviço continuar em manutenção é porque ainda há alguma coisa errada com ele. n Alexandre Borges (alex_sun@terra.com.br, é 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: 71