24/05/2018

Switch virtual interface (SVI)

     Geralmente, switches gerenciáveis permitem a criação de interfaces virtuais criadas no software para fornecer um meio de acesso via rede usando IPv4/6, denominadas de SVI, as quais se comportam como interfaces físicas, possindo inclusive um endereço MAC.
     Em geral, cada switch é fornecido com um SVI padrão definida como interface vlan 1, sendo necessário realizar a configuração de rede para permitir acesso remoto.

Configuração SVI

     A sequência de comandos a seguir foi executa da em um switch Catalyst da Cisco e habilita administrativamente e atribui um endereço IP a interface Vlan 1, tornando possível assim o acesso via rede
switch(config)#interface vlan 1
switch(config-if)#ip address 192.168.1.10 255.255.254.0
switch(config-if)#no shutdown
%LINK-5-CHANGED: Interface Vlan1, changed state to up
switch(config-if)#
     Assim como aplicada a Vlan 1, interfaces virtuais podem ser criadas para outras Vlans que estejam presentes no equipamento, sendo necessário também a criação da Vlan, pois a criação da interface para uma Vlan não existente não realiza a criação da Vlan de forma automática.
     Essas configurações permitem que o equipamento seja encontrado na rede através de um endereço IP, sendo necessário configurações adicionais para que seja realizado um acesso remoto, tal como a definição do gateway, configurações de uplink entre switches, configurações de Vlan entre outros. 
   

Teste de configuração

     Dentre os vários testes que podem ser realizados para verificar o funcionamento da configuração aplicada, um deles que não necessita de gateway, por estar na mesma rede, consiste em:
  1. configurar um computador na mesma rede
  2. conectar em uma porta do switch que esteja em modo access e na vlan 1
    • OBS: caso tenha configurado a interface virtual em outra Vlan, a porta access deve estar na Vlan na qual foi configurado o IP.
  3. utilizar o comando ping para testar.

Referências

  • https://www.grandmetric.com/knowledge-base/design_and_configure/how-to-create-svi-interface-cisco/ 
  • https://www.ppgia.pucpr.br/~jamhour/Download/pub/RSS/old/VLANs.pdf

02/05/2018

XenServer - Adicionando template do Ubuntu 18.04 LTS

     Um template é um modelo partir do qual se pode provisionar rapidamente uma nova VM. Mais detalhadamente, consiste em um arquivo com todas as informações de uma VM, tais como CPU, memória, tamanho do disco e recursos de rede. Em outras palavras, um template consiste em uma VM encapsulada com todas as suas informações.
      O Xen já disponibiliza templantes a serem escolhidos no momento da criação de uma nova VMs, os quais, além de conterem as definições básicas, auxiliam na definição de como ocorrerá a virtualização, se totalmente virtualizado o se paravirtualizada, dentre outros. Ademais, eles também não contam com sistema operacional instalado. 
     Já os templates criados a partir de VMs configuradas, possuem a vantagem de serem totalmente configurados, de acordo com quem realizou a preparação da sua VM de origem.
     Este post aborda o primeiro tipo de template, que é necessário ser criado geralmente quando ocorrem lançamento de novas versões de SOs que somente serão incluídas nas próximas versões do XenServer, tal como o Ubuntu Server 18.04 LTS, no XenServer 7.2.

Passo a passo:

1. Obter o UUID do template da versão anterior.
UUID=`xe template-list name-label="Ubuntu Xenial Xerus 16.04" params=uuid --minimal`
2. Clonar o template da versão anterior para um novo template, já com o nome da nova versão
NEW_UUID=`xe vm-clone uuid=$UUID new-name-label="Ubuntu Bionic Beaver 18.04"`
3. Setar como um template default
xe template-param-set uuid=$NEW_UUID other-config:default_template=true

Referências

  • https://tecadmin.net/add-ubuntu-16-04-lts-template-on-xenserver/ 
  • https://www.techhapa.com/2016/08/adding-ubuntu-1604-lts-template-in.html
  • http://ports.marllus.com/2016/02/17/entendendo-templates-xenserver-6-5/

24/04/2018

XenServer - Níveis de usuáros


     O XS (XenServer) apresenta por padrão cinco (5) Roles (níveis de usuários), denominados Pool Admin, Pool Operator, VM Power Admin, VM Admin, VM Operator ou Read-Only.  Estas roles são, com um conjunto de permissões que possibilitam garantir acesso total ou restringir  acessos mais específicos a cada usuário, conforme descrito a seguir.

  • Pool Admin: maior nível de acesso, permitindo controle total a todas as funções e configurações do XS, incluindo o acesso a console do host, tendo permissão para executar comandos como root.
  • Pool Operators: permite a execução de ações no nível do pool, como configurações de storage, gerenciamento de patches e a criação de resource pool. Também permite a configuração de Hight Availability, Workload Balancing, não tendo acesso a ações como inclusão de usuários e acesso console.
  • VM Power Admin: os usuários pertencentes a esta role tem permissão para gerenciar máquinas virtuais, templates, snapshots, recurso de Dynamic Memory Control e definição de Home Server.
  • VM Admin: permite o gerenciamento de VMs e templates sem acesso ao Dynamic Memory, snapshots e definição do Home Server.
  • VM Operators: possuem permissão para gerenciar uma VM em questão, realizando algumas atividades básicas, não sendo possível alterar as propriedades daPolls máquinas virtuais, como memória e CPU.
  • Read-Only: grupos associados a essa role terão acesso total somente leitura, não sendo permitido nenhuma modificação em todo o ambiente.
     É importante ressaltar que a inclusão de um usuário em uma role, permite que ele execute as funcionalidades a partir do XenCenter, sendo necessário a existência de um usuário na VM para que seja realizado o acesso ao SO.

Referências

  • https://docs.citrix.com/en-us/xencenter/6-5/xs-xc-users/xs-xc-rbac-roles.html
  • https://www.safaribooksonline.com/library/view/citrix-xenserver-60/9781849686167/ch02s04.html
  • https://www.packtpub.com/mapt/book/virtualization_and_cloud/9781849686167/2/ch02lvl1sec20/roles-and-permissions
  • https://cleristononline.wordpress.com/2015/02/19/testando-os-niveis-de-acesso/

18/04/2018

Mensagens de Log nos switches CISCO

     Os registros de logs podem ser usados para notificação de falhas, análise forense e auditoria de segurança. As mensagens de logs dos equipamentos Cisco podem ser tratadas de 5 maneiras diferentes, gerando registros de log:
  • do terminal: similar ao do console, mas mostra mensagens de log nas linhas VTY. Não é habilitado por padrão.
  • de console:  por padrão, todas as mensagens de log são enviadas para sua porta console. Portanto somente os usuários que estão fisicamente conectados à porta console pode ver essas mensagens.
  • de buffer: tipo de log que usa a memoria RAM para o armazenamento das mensagens de log. O buffer tem um limite fixo para garantir que o log não irá esgotar memória valiosa do sistema, deletando mensagens antigas do buffer assim como novas mensagens vão entrando.
  • do servidor Syslog: as mensagens de log podem ser encaminhadas para um servidor externo para o armazenamento.
  • de trap SNMP: mensagens de log podem ser enviadas para servidores SNMP através da configuração de traps.

Níveis de informação

     O tratamento das mensagens de log é realizado através da definição do nível de informação das mensagens, sendo dividida em 7 níveis, onde a definição de um nível faz com que todas as mensagens dos níveis inferiores sejam também enviadas.

Formatação dos logs

     O formato dos logs pode variar de acordo com o modelo do equipamento, mas nos switches da linha Catalyst 2960, são exibidos conforme exemplo:

     Alguns exemplos de configuração para registro de logs que poderiam ser aplicados são:
  • logging on: habilita o log para todos os destinos;
  • logging console 3: define o nível de informação das mensagens exibidas quando realizado acesso via console, fazendo com que sejam exibidas somente mensagens de status de erro ou de maior importância;
  • logging trap 7: define o nível de informação das mensagens armazenadas no buffer e enviadas para algum servidor Syslog, caso exista.
  • logging buffered 100000: definir o tamanho do buffer de log para ser armazenado no switch. O nível dos logs é definido com o parâmetro trap;
  • service sequence-numbers: habilita números sequenciais nos logs;  
  • service timestamps log datetime localtime: define o horário do log para o mesmo horário do equipamento, que por sua vez já foi configurado para ser sincronizado via NTP; 
  • show logging: não é uma configuração mas serve para exibe o buffer local com os eventos de log;
     A aplicação em um switch é meramente a transposição dos comandos em negrito para o console
switch(config)# logging on
switch(config)# logging console 3
switch(config)# logging trap 7
switch(config)# logging buffered 100000
switch(config)# service sequence-numbers
switch(config)# service timestamps log datetime localtime
switch(config)# end
switch# show logging
    Uma configuração de log adicional por ser obtida com o comando archive que habilita o log das alterações realizadas pela linha de comando, salvando informações da sessão, tais como login e comando realizado.
switch(config)# archive
switch(config-archive)# log config
switch(config-archive-log-cfg)# logging enable
switch(config-archive-log-cfg)# logging size 500
switch(config-archive-log-cfg)# end
switch#
     O comando show archive log config all é utilizado para exibir os logs das alterações realizadas, informando mais especificamente os comandos executados, os usuários e a linha de console utilizada para tal.
switch# show archive log config all
idx   sess           user@line      logged command
    1    20          admin@console  |logging on
    2    20          admin@console  |logging console 3
    3    20          admin@console  |logging trap 7
    4    20          admin@console  |logging buffered 100000
    5    20          admin@console  |service sequence-numbers
    6    20          admin@console  |service timestamps log datetime localtime
    7    20          admin@console  |archive
    8    20          admin@console  | log config
    9    20          admin@console  |  logging enable
   10    20          admin@console  |  logging size 500
switch#

Referências