Linux - Restore de volume group no mesmo servidor

Olá pessoal, tudo bem?

Podemos nos deparar com algumas situações complicadas em nosso dia a dia de trabalho e com certeza uma das mais complicados é quando perdemos algo, como um arquivo importante, um FS, um banco de dados ou até mesmo um servidor.

Temos que recorrer as nossas soluções de contorno como replicação, servidores que fazem pares e o mais comum, que é recorrer ao backup.

Mas e quando o backup não "funciona corretamente"?

Coloquei entre aspas, pois as vezes podemos nos deparar com cenários que deveriam funcionar sem problemas mas por alguma incompatibilidade seja pela versão do SO, ou do time de FS que estamos utilizando, dentre outras, pode impactar o restore de um determinado dado.

Pois bem...
Pensando no mundo virtual que temos hoje em dia, é muito comum vários ambientes rodarem em cima de virtualização.
E por consequência disso temos que ter soluções de backup que se adéquem ao nosso ambiente.

Temos soluções de backup que podem fazer snapshot de máquinas virtuais e voltar dados granulares, ou seja, de algum arquivo que precisamos e não do servidor todo.

Mas e se isso não funcionar?
Podemos subir um novo servidor e pegar os dados também?
Claro, podemos também.

Mas depois como eu copio o que preciso?
Muito provavelmente neste cenário aqui iremos utilizar rede e precisaremos de um IP temporário para este novo servidor e dependendo do time que cuida disso pode ser um tanto quanto demorado. Podemos esbarrar em problemas de regra de firewall, etc.

Vou mostrar aqui uma solução que pode ser seguida como uma alternativa.

Primeiro vamos ao cenário:

1 - Nos testes estou utilizando duas máquinas virtuais rodando em cima de Oracle Virtual Box;
2 - Cada servidor está instalado com CentOS, inicialmente para montar o ambiente cada servidor com um disco de 8GB adicional para APP, ambos com o mesmo nome de VG e LVs;
3 - Criado dados aleatórios para podermos ver os dados no servidor de destino;
4 - Por fim, o servidor que serial o meu "backup/snapshot", irá ser desligado e o disco dele apresentado para o servidor destino que irá fazer o restore e que está em produção;

Imaginando que o restore do snapshot tenha finalizado para um novo servidor, vamos desmontar os filesystems que compõem o VG em que estão e fazer o export do VG.

#umount /app1
#umount /app_bkp

#vgexport vg_app

Feito isso, o VG deve aparecer com o status de exported quando executarmos o comando vgdisplay.

Agora é só desligar o servidor.
#shutdown -h now

Através da console de administração do seu ambiente virtual, adicionar o disco no servidor que recebera o restore, lembrando que devemos selecionar o disco existente corretamente.

Feito isso, no servidor que será feito o restore dos dados, precisamos verificar se o disco foi reconhecido e suas configurações.
Claro que podemos ter o path dele alterado, como por exemplo, no servidor antigo estava como /dev/sdb1 e no novo aparecer como /dev/sdc1.

Rodando o comando vgdisplay, já podemos ver os dois VGs com o mesmo nome mas o que vamos utilizar no restore ainda com a informação de exported.

Como não é possível iniciarmos dois VGs com o mesmo nome, antes de tudo temos que alterar o nome do VG que está como exported. Para isso precisamos utilizar o VG UUID que é único:

#vgrename paOEZB-mqVS-3oHX-Gf5n-iAJ2-tLvG-zba1aD vg_app-RESTORE

Agora na saída do comando vgdisplay devemos ver o antigo VG com o nome vg_app-RESTORE.

Feito isso, podemos fazer o import do VG com o comando:
#vgimport vg_app-RESTORE

Agora o status do VG deve aparecer com o status de resizable.

Mas se já tentarmos montar os LVs deste VG, iremos receber um erro informando que não temos o LV em questão para montar.
Isso por que eles ainda estão inativos, como podemos ver com o comando:

#lvscan

A saída deste comando irá mostrar o status inactive.

Como não precisamos de todos os LVs neste exemplo, vamos escolher apenas o que vamos utilizar para o restore e habilitá-lo com o comando:

#lvchange -a y /dev/vg_app-RESTORE/lv_app_bkp

Feito isso o status do LV deve aparecer como ACTIVE.

Podemos montá-lo agora no path que queremos.
No meu caso eu criei um diretório com o nome de /restore

#mount /dev/vg_app-RESTORE/lv_app_bkp /restore/

E pronto, os dados que precisamos estão aqui.

Neste exemplo eu tentei demonstrar com uma necessidade de restore e devido a um problema da ferramenta de backup não conseguirmos fazer o restore de forma granular, mas isso se aplica em outros cenários também, onde precisaremos copiar dados ou utilizar os mesmos discos em um novo servidor visto que o antigo pode ter dado problemas.

Espero que essa dica ajude e seja útil.

Abraços
:wq!

openSUSE Leap 42.2 - Erro ao fazer atualização

Olá pessoal, tudo bem?

É... faz um tempo que não passo por aqui.
Isso é devido a correria dos meus dias e algumas mudanças que andaram acontecendo.
Mas vamos que vamos.

Depois de algum tempo sem atualizar minha distro openSUSE Leap 42.2, resolvi fazer isso no feriado e eis que me deparo com o erro para vários repositórios que utilizo:

                                (Erro em alguns repositórios durante atualização)

Ao que parece os repositórios estão com problema ou podem não existir mais.
Mais ou menos...

Antes de já sair removendo os repositórios ou até mesmo tentando achar novos, podemos fazer uma alternativa mais simples que consiste em limpar o cache gerado pelos repositórios.

Como fazia muito tempo que não atualizava nada, provavelmente ele geral alguma informação (cache) que existia no passado e agora mudou ou não existe para.

Com apenas um comando é possível fazer o refresh no cache dos repositórios e tentar instalar as atualizações novamente.

1. Vamos limpar o cache dos repositórios

lnv-opensuse:~ # zypper refresh Retrieving repository 'Packman' metadata ................................................................................................................................................................................................................................[done] Building repository 'Packman' cache .....................................................................................................................................................................................................................................[done] Repository 'adobe-flash-plugin' is up to date.                                                                                                                                                                                                 Repository 'google-chrome' is up to date.                                                                                                                                                                                                 Repository 'Emulators' is up to date.                                                                                                                                                                                                 Repository 'openSUSE-Leap-42.2-Non-Oss' is up to date.                                                                                                                                                                                                 Repository 'openSUSE-Leap-42.2-Oss' is up to date.                                                                                                                                                                                                 Retrieving repository 'openSUSE-Leap-42.2-Update' metadata ..............................................................................................................................................................................................................[done] Building repository 'openSUSE-Leap-42.2-Update' cache ...................................................................................................................................................................................................................[done] Repository 'openSUSE-Leap-42.2-Update-Non-Oss' is up to date.                                                                                                                                                                                                 All repositories have been refreshed.

Como podemos ver, se ainda assim algum repositório não existisse mais ou ainda assim apresentasse algum problema, muito provavelmente na hora de fazer o refresh ele iria apresentar erro novamente, dando assim a nossa missão de ver o que aconteceu com determinado repositório e procurar se o mesmo teve alguma alteração de nome, foi substituído ou algo do tipo.

Terminando isso é só atualizar.

2. Atualizando

lnv-opensuse:~ # zypper refresh Retrieving repository 'Packman' metadata ................................................................................................................................................................................................................................[done] Building repository 'Packman' cache .....................................................................................................................................................................................................................................[done] Repository 'adobe-flash-plugin' is up to date.                                                                                                                                                                                                 Repository 'google-chrome' is up to date.                                                                                                                                                                                                 Repository 'Emulators' is up to date.                                                                                                                                                                                                 Repository 'openSUSE-Leap-42.2-Non-Oss' is up to date.                                                                                                                                                                                                 Repository 'openSUSE-Leap-42.2-Oss' is up to date.                                                                                                                                                                                                 Retrieving repository 'openSUSE-Leap-42.2-Update' metadata ..............................................................................................................................................................................................................[done] Building repository 'openSUSE-Leap-42.2-Update' cache ...................................................................................................................................................................................................................[done] Repository 'openSUSE-Leap-42.2-Update-Non-Oss' is up to date.                                                                                                                                                                                                 All repositories have been refreshed.

Coloquei apenas um trecho pois a lista ficou muito grande depois de atualizar. :)

É isso.
Espero que essa dica ajude.

Abraço e até a próxima.
:wq!

EMC VPlex – Renomeando Initiators

Olá pessoal, tudo bem?

Uma tarefa um tanto quanto importante para os administradores de storage e principalmente para documentações e levantamento de informações nos storages e também na SAN, é dar nome aos bois (neste caso aos initiators :D).

Colocar seus respectivos nomes ajuda e muito na administração diária e até mesmo quando precisamos elaborar books executivos para nossos clientes ou mesmo internamente.

Dito isso e de comum acordo entre todos, convenhamos que durante a correria do dia-a-dia podemos esquecer ou até mesmo deixar este ponto passar batido para ganhar tempo ou fazer alguma entrega emergencial.

Mas e agora?!

Praticamente em todos os casos é possível fazermos este ajuste online sem nenhum impacto.

Hoje vou demonstrar como fazer isso no EMC VPlex…

Primeiro é necessário conectar no VPlex via SSH:

 #ssh service@ip_do_vplex

Embora já estamos na linha de comando, precisamos entrar na linha de comando VPlex que é onde faremos as configurações dos contextos, pois tudo no VPlex é encarado como contexto.

Para isso, vamos executar o comando vplexcli:

service@Vplex-7227:~>vplexcli

Será solicitado novamente usuário e senha. Inserir novamente o usuário service e sua respectiva senha.

Com isso um novo shell será aberto.

 VPlexcli:/>

Agora como vamos alterar o nome dos initiators, precisamos ir até o contexto initiator.

VPlexcli:/>cd /clusters/cluster-[1][2]/exports/initiator-ports/

Executando o comando ls dentro do contexto initiator-ports, teremos uma visão de todos os initiators que acessam o VPlex.

Para alterar o nome de cada um é necessário entrar no contexto de cada initiator e executar o comando set name. Vamos ao exemplo.

Vamos imaginar que eu tenho o initiator: 20:00:00:00:24:44:b1:0a

Entrando no contexto 20:00:00:00:24:44:b1:0a:

VPlexcli:/>cd 20:00:00:00:24:44:b1:0a/

Alterando o nome dele:

VPlexcli:/>set name SRV_PRD_01_hba0

Na verdade você  pode utilizar a convenção de nomes que achar mais adequada.

Neste exemplo, este initiator corresponde ao meu servidor SRV_PRD_01 e pertinente a hba0.

Feito isso, automaticamente já teremos o contexto que antes era o WWN alterado para o nome que configuramos:

VPlexcli:/>cd /clusters/cluster-[1][2]/exports/initiator-ports/20:00:00:00:24:44:b1:0a/ (Antes)

VPlexcli:/>cd /clusters/cluster-[1][2]/exports/initiator-ports/SRV_PRD_01_hba0/ (Depois)

E tudo isso sem perder ou gerar qualquer impacto para acesso aos discos.

Também é possível fazer essa alteração pela console do Unisphere, mas por ser mais lenta acaba demorando mais quanto à execução do procedimento que pela linha de comando é bem rápido.

Abs e até a próxima.

:wq!

Ferramentas da era Devops

Olá pessoal, tudo bem?

Hoje em dia fala-se muito sobre Devops, microserviços, ferramentas de automação, etc.

Devido essa tendência de ferramentas no mercado de TI nos dias de hoje, vou compartilhar uma lista com o nome das ferramentas e uma breve explicação do que é e faz cada uma.

Ansible:
- É um gerenciador de configurações. Tem a mesma funcionalidade que o Puppet, porém, para utilizar o Ansible não se faz necessário instalar um agente para fechar a comunicação entre cliente/servidor, fazendo a conexão com o cliente por SSH.

Docker:
- O que muito se confunde quando queremos falar de containers é utilizar o termo Docker. O Docker é uma ferramenta que tem como base o LXC que já existe no linux à muito tempo.
 O Docker é Open Source desenvolvida em GO. O GO é uma linguagem desenvolvida pelo Google.

Kubernetes:
- É também uma ferramenta Open Source utilizada para administração de cluster containers, tornando mais fácil a escalabilidade e monitoração.
 Permite também load balancer, deploy de containers, gerenciamento de volumes. Em resumo, ele serve para facilitar o trabalho com os containers.

Jenkins:
- Servidor desenvolvido em java que serve para fazer integração contínua.
 O Jenkins pode rodas em um único servidor na forma standalone como uma aplicação Web dentro de um servidor Web.
 Através de seus plugins é possível se conectar com outras ferramentas.

Openshift:
- Para ser mais objetivo, é o Docker da Red Hat.
 A ideia do Openshift é trazer praticidade na hora de criar seus aplicativos.

Nginx:
- Nada mais é do que um servidor HTTP.
 Pode ser utilizado também como um proxy de e-mail e reverso.
 A ideia de se utilizar hoje do Nginx no lugar do bom e velho Apache é a melhora no uso de memória, ou seja, o Nginx consome menos memória.

Chef:
- O Chef é um framework utilizado em sistemas e infraestruturas em nuvem (cloud).
 Consiste em criar ambientes de forma rápida e prática utilizando scritps pequenos, que são chamados de receitas.
 Existem também vários plugins prontos para integrações, o qual é chamado de cookbook.

Puppet:
- Tendo o mesmo conceito do Ansible, o Puppet serve para automação de recursos como gerenciamento de softwares e servidores bem como configuração que seja necessário fazer em grande escala.
 Um ponto que talvez dificulte na escolha do Puppet é sua linguagem e até mesmo todos os arquivos que são necessários de serem criados e elencados para criar uma automação.

É isso pessoal.
Existem ainda vários ferramentas.
Quando falamos em Devops o leque é muito grande e cada um atende mais de um propósito, fazendo as vezes a mesma coisa porém de forma um pouco diferente.

Abraço e até a próxima!
:wq!

Fim do war room? Talvez...

(Imagem da internet)

Olá pessoal, tudo bem?

Essa semana li uma matéria interessante no Linkedin e que ao meu ver faz muito sentido ainda mais nos dias de hoje.

Muito se fala de Cloud, microserviços, automação, serviços com auto-repair, etc.
Mas quando falamos de datas importantes para algumas companhias, não abandonamos o bom e velho war room (sala de guera em português).

Colocamos uma quantidade de funcionários, especialistas, pessoas de negócio, dentre outras funcionalidades, em uma sala no decorrer de todo evento, aguardando algo acontecer e para estarem prontas para atuação e gerar o menor impacto possível.

Com toda essa "novidade" dos dias mais atuais, o war room tende a não existir mais e ser mais uma coisa do passado em que os que estão ficando mais velhos podem colocar na conta para falar que viveram essa época.

Se todo o conceito que está em alta hoje realmente estiver bem implementado e testado, na prática teremos resiliência dos ambientes em caso de problemas sem necessitar de uma  intervenção de uma equipe esperando apenas isso.

A disponibilidade será ainda maior do ponto de vista dos serviços, os requisitos de negócio estarão sendo atendidos da melhor forma possível, a imagem da empresa com certeza estará em alta com os clientes, parceiros, investidores... resumindo, todo mundo.

- O que ganhamos com a extinção do war room?

• Tempo;
• Dinheiro;
• Economia nos gastos como hora extra, alimentação para o war room;
• Insumos de workplace, me referindo aos recursos como ar condicionado, energia elétrica, etc;
• Reembolso para quando se aplica;
• Menos estresse entre as pessoas envolvidas;

Claro que até podemos pensar e/ou elencar algumas coisas à mais nessa lista, mas o mais importante são os primeiros itens.

Se o novo vai durar muito tempo e se vai resolver todos os problemas, isso eu não sei... mas vale a pena ficarmos antenados com tudo o que está acontecendo e nos atualizarmos para continuarmos com o mercado de TI.

Agora um ponto mais importante do que tudo isso, é que a mentalidade de uma empresa que quer isso tem que mudar e acompanhar toda essa mudança no mercado de TI e da era digital. Os processos devem acompanhar tudo isso, a maturidade de seus dirigentes também.
Podemos ter tudo pronto, mas caso algum destes pontos que envolvem pessoas e mentalidade não mudar junto, nada vai adiantar.

#R.I.P_WarRoom

Abraços e até mais...
:wq!

Ataque Ransomware? Mas afinal o que é?

Boa dia pessoal, tudo bem?

Na última sexta-feira (12/05) e parte do sábado (13/05) muito se ouviu e se leu sobre a massa de ataques Ransomware, afetando principalmente empresas como Telefônica, Santander, Gas Natural, dentre muitas outras e principalmente espanholas.

Mas tirando a onda de ataques e o pânico causado no mundo todo, fazendo até mesmo algumas empresas a desligarem seus servidores para não serem atingidos, o que vem a ser um Ransomware?

"Ransomware" = Resgate

Através de um malware (código malicioso) normalmente enviado através de algum e-mail, conteúdo online, downloads de lugares duvidosos, etc, quando clicado permite que seja explorada uma falha no sistema e que este malware consiga bloquear desde o seu acesso inicial até mesmo a criptografia de dados importantes.

Através desta criptografia, aplicações importantes deixam de responder e sempre que o administrador tenta acessá-los recebe uma mensagem informando que o mesmo foi "capturado" e que para ser liberado é necessário o pagamento de um resgate, em sua maioria através da moeda virtual bitcoins, sendo que se o pagamento não for realizado os dados serão apagados.

A brecha foi encontrada em uma falha nos sistemas operacionais Windows (Ahhhh vá?!)... da Microsoft.

Independente de ter mais esta falha de segurança na conta, o maior problema é vermos que muitas empresas não possuem mecanismos de segurança ou mesmo soluções de contorno em casos de problemas como este.

Vide o exemplo de empresas terem que desligar seus computadores, parar suas atividades e rotinas até ver o que poderia ser feito.

Não que o Linux seja melhor ou até mesmo 100% seguro, mas com o passar do tempo e até mesmo desde quando comecei no ramo de TI e mais precisamento com Linux/Unix não me recordo de termos tais problemas como este e companhias que possuem seus sistemas em uma estrutura como está mostram seu potencial com disponibilidade e resiliência.

Segue abaixo algumas imagens que peguei pela internet apenas para ilustrar o tipo de mensagens que as "vítimas" recebem:

Independente de qualquer empresa, sistema operacional precisamos tomar cuidado e sempre pensar e tentar criar mecanismos que não nos deixe indisponíveis, afinal os negócios não podem parar!

#tango_down
:D

Abraços e até a próxima.
:wq!

Canonical - Fim do Unity no Ubuntu em 2018

Como se já não bastasse a notícia do fim do Ubuntu Phone...

A Canonical anunciou que na sua próxima versão estável (LTS) do Ubuntu irá voltar a utilizar o Gnome como interface gráfica padrão.

Isso por que estão descontinuando o Unity, que está presente nas versões do Ubuntu à um certo tempo.

Talvez algum grupo de comunidade tente continuar com o desenvolvimento ou até mesmo com algum modelo semelhante ao Unity, mas até sabermos se isso vai acontecer ou até isso acontecer, teremos que voltar a utilizar versões como KDE, Mate ou até mesmo o GNOME.

O fundador do Ubuntu, Mark Shuttleworth, colocou em seu blog que a ideia será focar em assuntos de Cloud, Internet das coisas e em servidores. 

Agora só podemos esperar e ver as coisas boas (ou não) que a Canonical pode lançar  no mercado para estas frentes e até mesmo o que pode vir com a nova versão do Ubuntu.

Oficialmente só em 2018...

Abraços
:wq!

Canonical anuncia fim do Ubuntu Phone

Fala pessoal, tudo bem?

Para os usuários e amantes do Ubuntu e de todos, ou quase todos, os serviços e recursos que a Canonical oforece, recebemos um notícia um tanto quanto triste.

A Canonical anunciou que em Junho terminará o suporte ao Ubuntu Phone.

Bom, para quem tinha esperança de ver este projeto vingar, fica agora apenas a saudade.

A empresa informou que irá investir em outras frentes de serviços como Cloud (serviços em nuvem que é um assunto quente no mercado de TI), Internet das coisas e também na parte de servidores.

Com certeza eles tiveram os mesmo problemas e dificuldades que o Windows Phone teve ao tentar competir em um mercado dominado pelo IOS da Apple e o Android do Google.

Com certeza nos dias de hoje  tentar entrar no mercado de smartphones já é um tremendo desafio, imagine entrar em um mercado domínio por apenas duas gigantes e com forte presença neste setor?!

O investimento deve ter sido muito pesado em relação ao retorno...

De qualquer forma, a Canonical continua sendo uma gigante e vai nos proporcionar ainda muitas coisas boas.

Abraço pessoal

:wq!

Linux - Habilitando serviços na inicialização - Derivados Red Hat/Fedora/CentOS... etc

Olá pessoal, tudo bem?

Que algumas coisas mudaram nas versões 7 tanto do Red Hat como do CentOS, é indiscutível.

E uma delas é a forma de habilitar serviços durante a inicialização do Sistema Operacional.

Antigamente utilizávamos o tradicional chkconfig... mas agora ficou um pouco diferente (para não falar completamente).

Vou mostrar como fazer...

Para verificar o serviço, precisamos rodar o comando:

#systemctl status nome_do_serviço

Exemplo:

[root@centos01 ~]# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
Loaded: loaded (/usr/lib/systemd/system/postfix.service; disabled; vendor preset: disabled)
Active: active (running) since Qua 2017-04-12 22:25:21 BRT; 2min 58s ago
Main PID: 975 (master)
CGroup: /system.slice/postfix.service
├─975 /usr/libexec/postfix/master -w
├─976 pickup -l -t unix -u
└─977 qmgr -l -t unix -u

Abr 12 22:25:11 centos01.localdomain systemd[1]: Starting Postfix Mail Transport Agent...
Abr 12 22:25:20 centos01.localdomain postfix/postfix-script[973]: starting the Postfix mail system
Abr 12 22:25:21 centos01.localdomain postfix/master[975]: daemon started -- version 2.10.1, configuration /etc/postfix
Abr 12 22:25:21 centos01.localdomain systemd[1]: Started Postfix Mail Transport Agent.
[root@centos01 ~]#

No exemplo acima o serviço postfix está desabilitado e em execução (running).

Após o servidor sofrer um reboot, podemos ver que o serviço não está mais no ar e continua com o status disabled:

[root@centos01 ~]# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
Loaded: loaded (/usr/lib/systemd/system/postfix.service; disabled; vendor preset: disabled)
Active: inactive (dead)
[root@centos01 ~]#

Vamos iniciar o serviço e colocá-lo para iniciar durante o boot:

# systemctl start postfix

[root@centos01 ~]# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
Loaded: loaded (/usr/lib/systemd/system/postfix.service; disabled; vendor preset: disabled)
Active: active (running) since Qua 2017-04-12 22:32:44 BRT; 13s ago
Process: 953 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
Process: 949 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
Process: 947 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)
Main PID: 1025 (master)
CGroup: /system.slice/postfix.service
├─1025 /usr/libexec/postfix/master -w
├─1026 pickup -l -t unix -u
└─1027 qmgr -l -t unix -u

Abr 12 22:32:43 centos01.localdomain systemd[1]: Starting Postfix Mail Transport Agent...
Abr 12 22:32:44 centos01.localdomain postfix/master[1025]: daemon started -- version 2.10.1, configuration /etc/postfix
Abr 12 22:32:44 centos01.localdomain systemd[1]: Started Postfix Mail Transport Agent.
[root@centos01 ~]#

Veja que o serviço está running, mas ainda disabled.

Habilitando...

#systemctl enable postfix

[root@centos01 ~]# systemctl enable postfix
Created symlink from /etc/systemd/system/multi-user.target.wants/postfix.service to /usr/lib/systemd/system/postfix.service.
[root@centos01 ~]#

Agora sim, serviço iniciado e habilitado para iniciar automaticamente:

[root@centos01 ~]# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor preset: disabled)
Active: active (running) since Qua 2017-04-12 22:32:44 BRT; 1min 48s ago
Main PID: 1025 (master)
CGroup: /system.slice/postfix.service
├─1025 /usr/libexec/postfix/master -w
├─1026 pickup -l -t unix -u
└─1027 qmgr -l -t unix -u

Abr 12 22:32:43 centos01.localdomain systemd[1]: Starting Postfix Mail Transport Agent...
Abr 12 22:32:44 centos01.localdomain postfix/master[1025]: daemon started -- version 2.10.1, configuration /etc/postfix
Abr 12 22:32:44 centos01.localdomain systemd[1]: Started Postfix Mail Transport Agent.
[root@centos01 ~]#

Parece uma dica um tanto quanto básica, mas as vezes os itens mais básicos são os que passam batidos durante um projeto, o start de um novo ambiente ou até mesmo para automatizar melhor questões que o próprio sistema operacional pode ajudar.

Espero que esta dica seja de grande ajuda.

Abraço!

:wq!

Instalando Spotify no OpenSuSe Leap

É comum hoje encontramos pessoas utilizando distros baseadas no Debian, mais precisamente Ubuntu, Mint, Kubuntu, dentre outras.

Elas são realmente mais fáceis e customizadas já para utilizar.

Vide a gama de recursos e componentes que já vem com o pacote .deb para instalar. Um exemplo disso é o recursos Warsaw, que serve como proteção para os recursos de internet bank (Itáu, Caixa Econômica).

Parece que alguns desenvolvedores se esqueceram de criar esses mesmos recursos para distros derivadas do Red Hat como Fedora, OpenSuse e todas as demais que se utilizam de pacotes .rpm.

Pois é... percebi isso agora usando o OpenSuse.

Um dos recursos mais utilizados hoje em dia principalmente pelo entretenimento é o spotify...
Eu mesmo uso bastante para poder escutar minhas músicas, criar e ouvir playlists criadas... Mas não tem um "pacote" nativo para distros baseadas em Red Hat.

Para instalar no OpenSuse, segue o procedimento:


1. wget https://raw.github.com/cornguo/opensuse-spotify-installer/master/install-spotify.sh
2. wget https://raw.github.com/cornguo/opensuse-spotify-installer/master/spotify-client.spec
3. chmod +x install-spotify.sh
4. sh install-spotify.sh

E pronto, agora é só acessar e entrar com sua conta no spotify.

OpenSuse Leap - Erro "Empty destination in URI"

Olá pessoal, tudo bem?

Depois de algum tempo utilizando Mac OS, depois Windows 10, estou me aventurando novamente a utilizar o Linux... mais precisamente a distro OpenSuse Leap 42.2.

Pois bem, depois de criar o pendrive bootavel, fazer toda parte de instalação, etc...

Ao tentar fazer o update do sistema, me deparei com o seguinte erro:

opensuse:~ # sudo zypper refresh Retrieving repository 'Packman' metadata ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- New repository or package signing key received: Repository:       Packman                     Key Name:         PackMan Project (signing key) <packman@links2linux.de> Key Fingerprint:  F8875B88 0D518B6B 8C530D13 45A1D067 1ABD1AFB         Key Created:      Mon Sep 15 19:18:00 2014                             Key Expires:      Thu Sep 12 19:17:21 2024                             Rpm Name:         gpg-pubkey-1abd1afb-54176598                         Do you want to reject the key, trust temporarily, or trust always? [r/t/a/? shows all options] (r): a Retrieving repository 'Packman' metadata ................................................................................................................................................................................................................................[done] Building repository 'Packman' cache .....................................................................................................................................................................................................................................[done] Empty destination in URI: hd:///?device=/dev/disk/by-id/scsi-1SanDiskCruzer_Blade-part2  
Esse erro está relacionado ao processo de instalação, onde o OpenSuse colocou o pendrive que utilizamos para instalação como um dos repositórios de pacotes.

Para remover basta fazer o seguinte:

opensuse:/ # yast2 repositories  

Na tela do Yast irá aparecer a lista de todos os repositórios utilizados. 
Procure pela linha que contém o device local (hd:///?device=/dev/disk/by-id/scsi-1SanDiskCruzer_Blade-part2)...

Clique em Delete.

Pronto, agora é só atualizar e instalar os pacotes se nenhum problema!

Abs e até a próxima.
:wq!

OpenSuSe - Erro ao montar partição Windows

Olá pessoal, tudo bem?

Estava usando a partição do windows 10 por conta do Corel Draw.
Pois bem, ao reiniciar o sistema para voltar ao OpenSuse, ele entrou no prompt de manutenção.
Suspeitando que poderia ser algo com a partição do windows, comentei a linha no fstab e mandei reiniciar novamente.
O sistema subiu normalmente.

Já com o sistema operando normalmente, tentei fazer o mount manual e me deparei com a seguinte mensagem de erro:

Ao que parece, se algo ficou aberto no windows ou se ele não encerrou direiro (para variar), ele tem uma proteção/um modo de hibernação. E devido à isso, esse erro aparece quando o Linux tenta montar a partição.

Como solução, basta executar o seguinte comando:

opensuse:~ # ntfsfix /dev/sda3 (informando a partição pertinente ao seu windows):

Depois é só montar novamente a partição do windows:

Alguns problemas de convivência entre os dois... Mas está valendo.
Abraço e até a próxima.

:wq!

O mercado de TI está mudando? Creio que sim...

Bom dia pessoal, tudo bem?

Venho acompanhando algumas mudanças no mercado de TI e com certeza mudanças que colocam em circunstância para onde vamos.

Isso mesmo. Para onde vamos? Onde queremos chegar?

Todo dia algo muda, tendências novas são criadas, inovações em alta e ao final disso tudo fica uma pergunta:

- Para que?

Sinto e vejo que algumas áreas tendem a não existir mais, recursos são cada vez menos necessários pois podemos vê-los como serviço.

Hoje em dia tudo é Cloud!

Para onde vamos?
-  Para Cloud.

Como vamos resolver isso?
- Resolvemos com Cloud.

Mas precisamos reduzir gastos, como vamos fazer isso?
Vamos fazer isso com Cloud.

E isso é só um pequeno exemplo.

A TI vem sofrendo com o mercado e com as variações das pessoas. E isso fez com que a TI entrasse em um ritmo frenético também.
Mal temos um sistema, que ainda convive com alguns bugs e precisa ser ajustado a medida que melhorias contínuas são necessárias e sai no mercado um novo sistema que faz a mesma coisa um pouco diferente ou com algum recurso agregado e pronto, vamos para este agora.
As vezes não largamos nem o supostamente "antigo".

Se a TI não tomar cuidado, ela tende a ser como o mercado... Algo bem rotativo, instável, com vários "sabores" e atendendo cada variação de humor e o poder de querer de alguém.

Inovação?

Não inovamos em nada. Muitas das tecnologias que são febre nos dias de hoje são conceitos já do passado, apenas com outro nome e outra forma de se fazer.

Por que precisamos inovar?

Por que hoje a TI está sendo vista como uma área que precisa inovar constantemente, caso isso não ocorra, não irá servir ou atender ao mercado.

Mercado de trabalho, mundo corporativo de certo modo virou um lugar "sujo", que atende apenas interesses comuns e políticos.
Hoje em muitos casos não se faz o necessário para as coisas rodarem e atenderem requisitos. Elas precisam atender interesses.

Desabafo à parte, vamos ver o que o mercado precisa e nos reinventar.
Afinal de contas, somos TI, somos capazes e temos que ser a Tropa de Elite que o mercado e as companhias precisam.

Bom fim de semana!
Abs
:wq!

Cisco UCS - Unified computing (Emulator)

Olá pessoal.

Para poder oferecer alto poder de processamento e recursos em larga escala, muitas empresas utilizam servidores sejam eles Dell, HP, IBM, Cisco e até recursos "montados" conforme necessidade. Ou como falamos aqui em São Paulo, servidores montados na Santa Efigênia. =)

O mais tradicional são servidores de poucos U's (unidade de medida de um servidor mediante ao espaço que ele irá ocupar em um rack no data center.
Nestes servidores temos discos que oferecem redundância para não termos a perda do SO ou mesmo para utilizar para o SO e recursos de aplicação. Fontes redundantes em caso de falha não iremos ter o servidor inacessível como um todo. Recursos de rede e em muitos casos controladores de disco SCSI ou HBA - FC para acesso à storage.

Para estruturas mais robustas e empresas que precisam otimizar tais usos de servidores, talvez seja muito mais fácil e melhor adquirir recursos de computação no modelo Blade.
A ideia de Blades são chassis ou caixas de recursos interligados em várias placas que possuem disco (nem sempre), processadores e memória com o conceito de ser umaCPU completa e ainda compartilhar recursos de network e SAN.

Neste formato podemos sacar uma única blade para fazer alguma atividade e não gerar nenhum impacto nas demais, exatamente como é possível fazer com os vários servidores em um único rack.

Hoje se fala muito em infraestrutura convergente, montando assim uma Cloud privada, pública ou até mesmo mista.
Tais recursos de blade ajudam e melhorar este cenário quando pensamos em montar uma caixa/data center para atender isso.

Os racks vBLOCK da VCE oferecem toda essa ideia na prática. Os recursos de computing são utilizados blades Cisco variando entre B-Series e C-Series.

Modelo B-Series

Modelo C-Series

O modelo C-Series é o convencional servidor.

O modelo B-Series pode varias com os modelos Full e Half Blade.

Dentre essa estrutura de blades é possível o uso de recursos de fabric interconnects. Switches que promovem conexão e compatibilidade de todos os chassis com os recursos de blade ou servidores c-series.

Possui uma central única de administração através de software java direto pelo IP de gerenciamento do UCS ou até mesmo um software UCS de gerenciamento centralizado incluindo análise de recursos de performance.

A facilidade do gerenciamento nos permite criar service profiles para cada servidor, assim fazendo com que cada um possua seu recursos, atribuições de wwns e mac address. O ideal quando falamos de ambientes de servidores homogêneos e principalmente ambientes de Hypervisor.

Possuindo conexão com storage, podemos fazer a instalação do SO direto no storage através do recursos boot from SAN. Em último caso, se ocorrer algum problema com a blade ou com o servidor garantimos que o SO estará seguro no lado do storage.

Sabendo que tais recursos não são muito comuns e nem tão fáceis quanto ao acesso para estudos, entendimentos e até mesmo para se ter uma ideia de como isso pode vir a ajudar nossa companhia antes da compra, temos o recursos que pode ser estudado subindo um Emulador em um virtualizador como VM Player.

Segue o link até o momento desta publicação para Download: Cisco UCS Emulator

É necessário  cadastro no site da Cisco para iniciar o download, mas até essa parte tudo sem problemas.

Segue o passo-a-passo para subirmos o Emulador:

• Abra o VM Player

• Selecionar o arquivo .OVA que fizemos o download:

• Escolher o local para onde a VM será importada:

• Aguardar até que o processo de import finalize para poder dar o PowerOn no UCS:

Como podemos ver no print abaixo, o Emulador é baseado no Linux CentOS =)

• Assim que terminar o auto-deploy das configurações, será exibida uma tela de login na console do VM Player com o user e password:

• Irá abrir um menu com as opções que são customizadas para este acesso. Teclando a letra "a", iremos ver os IPs que foram atribuídos:

• Para o acesso via Browser basta informar o IP do VIP:

Como este recurso utiliza o java, é possível que encontre algum problema. No meu caso, a mensagem se segurança do java quanto ao certificado do UCS bloqueou o processamento do console de acesso.

• Para liberar, é necessário informar o IP do UCS na parte de segurança do java:

• Feito a liberação, iremos chegar até a tela de login. Utilize o mesmo informado na console de acesso por linha de comando:

• E pronto!!! Estamos com acesso ao nosso UCS para dar os próximos passos:

Segue um vídeo com todo o processo: Cisco UCS Emulator - Install

Agora é só iniciar os estudos.

Até a próxima pessoal.

Abs

:wq!