segunda-feira, 11 de março de 2019

Smartwatch Xiaomi - Amazfit Pace

Salve pessoal, tudo bem?

Já faz um tempo que venho testando e usando todos os dias o smartwatch da Xiaomi.
O modelo que adquiri é o Amazfit Pace! Eu nunca fui muito ligado em smartwatch, mas depois de ver algumas integrações e uso durante o dia-a-dia fiquei tentado a pegar um.




Já foi antes de fazer meus comentários confirmado que recomendo!!!

Vou colocar as especificações (podem sofrer variações dado o local que os vende bem como a data de publicação do artigo, ok?).

Especificações:
Marca: Xiaomi
Modelo: Amazfit, Versão em Inglês (não possui Português)
Chip: Dual core, 1.2GHz
Memória: 512MB + 4GB
Compacibility: Android 4.4 ou acima dos telefones com BT4.0
Modo de operação: Touch Screen
Compatível com os OS: Android, IOS
Classificação à prova d'água: IP67

Bateria:
Tipo de Bateria: Lithium polymer battery
Capacidade da Bateria: 280mAh
Modo de relógio: Cerca de 11,6 dias
Modo de execução: Cerca de 5 dias

Recursos:
Rastreador Saúde: Monitor da frequência cardíaca
Música Bluetooth
Tempo
Sensor PPG sensor do ritmo cardíaco
Sensor de aceleração
Giroscópio
Sensor geomagnético
Sensor de luz
Tipo de alerta: Vibração

Conexão:
Versão Bluetooth: V4.0BLE
WiFi

Dimensões e Peso:
Tipo de Tela: 1,34 polegadas, capacitivo
Resolução: 320 * 300 pixels
Método de operação: tela de toque
Material Dial: C, orning gorilla glass
Material da Caixa: Cerâmica com Policarbonato + Zirconia
Largura: 22 mm
Peso: 53.7g
Pulseira TPU (Borracha)



Vamos agora para minhas impressões...

O maior problema que escutei pessoas reclamarem de smartwatches é em relação ao tempo de duração da bateria.
Bem no caso do Amazfit Pace, dependendo muito do uso ele pode durar até uma semana até zerar completamente a bateria.

Quando a bateria está ficando praticamente zerada, funciona apenas a função relógio. Ou seja, você não consegue utilizar nenhuma outra função.

Os recursos para quem pratica esportes é bem legal podendo fazer acompanhamento de exercícios como caminhada, corrida, ciclismo, elíptico (simulador de caminhada), tênis, futebol, dentre alguns outros.
Possui também um plano de treinamento que você pode cadastrá-lo.

Possui um controle de atividades e também análise de clima/tempo.

Controle de música do celular e do Spotify. É possível passar as músicas, ver o nome das que estão em execução no momento.

Tem a função de controle do sono, timer.

Além de poder instalar novos apks e até mesmo instalar temas diferentes dos que ele baixa pelo aplicativo de controle do Amazfit Pace pelo smartphone.

O aplicativo para controle do smartwatch você pode baixar pela loja de aplicativos do seu aparelho. É o Amazfit Watch.

Fora algumas integrações já com estes recursos do smartphone, é possível selecionar uma lista de aplicativos que vão aparecer no visor do Amazfit Pace quando receber alguma notificação. Por exemplo:

- SMS;
- Whatsapp;
- Aplicativos de investimentos / Finanças;
- Aplicativos de redes sociais (testei apenas com o Linkedin);
- Skype;
- YouTube (para quando marcamos que queremos receber notificação de vídeo novo de um determinado canal);
- Jogos;

Em resumo, ele mapeia todos os apps que você tiver instalado, mas a funcionalidade pode varias de acordo com a integração que ele consegue fazer.

Existe a possibilidade de abrir chamado na comunidade de suporte da Xiaomi. Nunca precisei usar, então não tenho como avaliar.

Em resumo:

- Preço dele é muito mais acessível do que os outros smartwatches como Apple e Samsung;
- Os recursos dele são fantásticos e funcionam muito bem;
- É confortável e fica muito bom no pulso;
- Tempo de bateria é ótimo (pelo menos para minha forma de uso);
- É possível trocar os temas (skins) e pulseira também. Lembrando que estes itens você mesmo consegue locais para baixar e sites que vendem;
- A luz dele até que é OK (poderia ter uma resolução melhor);
- Atende ou rejeita ligações;

O único contra que consigo mencionar agora é em relação aos textos de mensagem e whatsapp... Algumas vezes dado o tamanho da mensagem o texto não fica linear. É possível perceber uma "certa bagunça" na altura das letras/palavras.
Outro contra, é que ele não lê o catálogo dos seus endereços quando recebe ligações. Aparece apenas os números.

Mas creio que isso é corrigido em breve com alguma atualização ou até incomodar mais pessoas! :)

Novamente, recomendo!!!



Abs e até mais...
:wq!

terça-feira, 20 de novembro de 2018

Mount point Windows no Linux - Sem permissão de escrita

Olá pessoal, tudo bem?

A dica hoje vai para quem utiliza dual boot em seu computador (contendo Windows e Linux), e já se deparou com o erro de escrita na partição NTFS do Windows.

No meu caso, eu crio links simbólicos para minhas pastas de documentos, músicas, vídeos, etc que estão no Windows.
Isso facilita e muito para não ter que ficar reiniciando toda hora o computador para pegar um arquivo que está no Windows ou que está no Linux.

No entanto eu recebi as seguintes mensagens de erro quando tentei criar uma máquina virtual e quanto tente remontar a partição do Windows:




Este erro acontece pois em algum momento em que estava utilizando o Windows ele não foi desligado corretamente.
Nem sempre temos esse hábito de desligar o computador. Normalmente eu apenas o coloco para hibernar, já reinicio para fazer alguma outra coisa, etc. Mas isso não é um problema... Afinal, os sistemas tem que aprender a lidar com essas questões (minha opinião :D).

Para resolver este problema de dentro do Linux basta rodar os seguintes comandos:

- Primeiro, desmontar o ponto de montagem que criamos para o Windows
$sudo umount /windows

- Segundo, executar o comando que irá limpar o "cache" que está fazendo o lock na partição do Windows
$sudo ntfsfix /dev/sda3

- Terceiro, fazer o "remount" do device do Windows como rw
$sudo mount -o rw /dev/sda3

- Quarto, montar novamente a partição do Windows
$sudo mount /windows

Depois disso será possível escrever novamente na partição NTFS do Windows pelo Linux.

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

segunda-feira, 18 de dezembro de 2017

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!

quarta-feira, 15 de novembro de 2017

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



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



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!

terça-feira, 15 de agosto de 2017

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!

sábado, 3 de junho de 2017

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!

sexta-feira, 2 de junho de 2017

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!

segunda-feira, 15 de maio de 2017

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!

quarta-feira, 26 de abril de 2017

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!

quarta-feira, 12 de abril de 2017

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!

segunda-feira, 27 de fevereiro de 2017

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:

 

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:

 

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!

sábado, 25 de fevereiro de 2017

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!

sábado, 4 de fevereiro de 2017

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!