Arquivo

Archive for the ‘Linux’ Category

Instalando o JIRA no Linux

24 de fevereiro de 2013 3 comentários

Olá gurizada,

Para quem não conhece, o JIRA é um bugtracker produzido pela Atlassian. É um software proprietário, e arrisco dizer que ele pode ser utilizado para controle de quase qualquer tipo de ocorrência. Existem licenças starter a partir de 10 dólares anuais para 10 desenvolvedores, mas o preço sobe para números maiores do que isso. Mesmo assim ainda vale a pena.

Como há anos não escrevo nada técnico por aqui, vou ensiná-los a fazer uma instalação básica do JIRA. Esse mesmo artigo pode ser utilizado para instalar o JIRA em algum outro UNIX que possua Oracle JDK. So sorry, NetBSD.

Esse mesmo artigo pode ser utilizado para instalação de qualquer versão moderna (e hoje, fevereiro de 2013, suportada) do JIRA. Isso é, 4.3.x, 4.4.x, 5.0.x, 5.1.x e 5.2.x.

Leia mais…

Anúncios
Categorias:Diversos, Linux

Razões para nem começar a usar o Scientific Linux

5 de abril de 2011 35 comentários

Hi guys,

Esse texto é uma carta aberta ao Henrique LonelySpooky a respeito do CentOS, distribuição que utilizo em meu desktop e meus servidores. Não é segredo pra quase todos que eu também estou deixando o CentOS. E esse texto do LonelySpooky brifa explica por alto alguns motivos que também o levaram abandonar essa distribuição. Mas o Scientific Linux, no meu caso, não será uma resposta, e sim uma pergunta. A resposta será “Não”. E eu explico o por quê.

Onde eu discordo da Opinião do LonelySpooky

De 2009 para cá, pouca coisa mudou na rea­li­dade: o Cen­tOS tem milha­res de usuá­rios, mas ape­nas “meia dúzia” de desen­vol­ve­do­res que deci­dem tudo. Não existe, de fato, uma Comu­nidade Cen­tOS por­que a Comu­ni­dade não par­ti­cipa efe­ti­va­mente na cons­tru­ção da dis­tro. Deta­lhes como papel de parede, tema, publi­ci­dade e empa­co­ta­mento se pas­sam pra­tica­mente às escu­ras ou dis­per­sos em pági­nas lúgu­bres e mal divulgadas.

Henrique, como bom usuário CentOS que és, você deveria lembrar que o desenvolvimento do CentOS realmente não é interativo via website ou fórum. No entanto a comunidade participa sim, através das listas de discussão onde todas essas coisas são debatidas. E nada disso é mal-divulgado, o problema é outro (explico mais pra frente).

Quando o Red Hat Enter­prise Linux 6 foi lan­çado eu já acom­pa­nhava ávida­mente as ver­sões de teste e creio que muita gente, assim como eu, acre­di­tava que um RHEL mais novo abri­ria um impor­tante leque de pos­si­bi­li­da­des; afi­nal de con­tas, o RHEL 5.x é base­ado no jurás­sico Fedora Core 6, com o qual diver­sas apli­ca­ções recen­tes são incompa­tí­veis.

Na verdade, as incompatibilidades nesse aspecto só são dos pacotes pra desktop. Quem usa RHEL/CentOS 5 sabe que, apesar do kernel ainda ser o 2.6.18, ele é muito bem patcheado para assegurar a compatibilidade com o hardware mais recente. Empresas desenvolvem software para outras empresas. Logo, nos softwares que continuam sendo desenvolvidos para o RHEL 5, não faz diferença a última versão do kernel, do GCC ou da GLibc.

Em vez de uma solu­ção, o RHEL 6 evi­den­ciou um pro­blema muito grave que a Comu­ni­dade Cen­tOS enfrenta. A redu­zida equipe de desen­vol­ve­do­res encontrou-se espre­mida entre duas rele­a­ses: RHEL 5.6 e RHEL 6.

Houve votação nas listas para eleição da prioridade. Inclusive, eu votei na prioridade de lançamento do CentOS 5.6 ao invés do CentOS 6, uma vez que precisarei homologar toda minha plataforma que hoje roda no CentOS 5.x para rodar no CentOS 6, enquanto o CentOS 5.6 é versão de continuidade, não de recomeço. 😉

Onde eu concordo com a opinião do LonelySpooky

De 2009 para cá, pouca coisa mudou na rea­li­dade: o Cen­tOS tem milha­res de usuá­rios, mas ape­nas “meia dúzia” de desen­vol­ve­do­res que deci­dem tudo. Não existe, de fato, uma Comu­ni­dade Cen­tOS por­que a Comu­ni­dade não par­ti­cipa efe­ti­va­mente na cons­tru­ção da dis­tro.

Eu concordo em parte com essa afirmação. Não acho que a equipe que desenvolve o CentOS é pequena, pelo contrário. Acho ela até abastada.

O que não gosto é que o desenvolvimento do CentOS me passa a impressão de ser feito “em panela”. Isso é, sempre as mesmas pessoas, e o ego das referidas é um tanto quanto exaltado. Isso não é uma exclusividade dos desenvolvedores do CentOS, mas sim um problema de TODAS AS DISTRIBUIÇÕES feitas em comunidade. No Debian é a mesma coisa, a diferença são as intermináveis votações.

Como atenuante, numa distribuição como o CentOS não são necessários tantos desenvolvedores, uma vez que o CentOS é basicamente um repackage do RHEL. As listas são abertas até certo ponto, e a burocracia para participar do desenvolvimento é tanta que eu optei por não distribuir os pacotes que eu já fiz nesses meios oficiais.

Diante da impa­ci­ên­cia da comu­ni­dade, que por várias vezes soli­ci­tou mais trans­pa­rên­cia sobre o sta­tus do Cen­tOS 6, a res­posta padrão é sem­pre a mesma: “O Cen­tOS 6 ficará pronto quando ficar pronto”

Isso, infelizmente, tem sido um problema seríssimo e dispensa comentários.

Razões para continuar no CentOS

Apesar disso tudo, o CentOS ainda tem um nome muito forte nos provedores da vida. Nome erguido por mérito. E existem pessoas que não estão inteiradas dos problemas que a comunidade CentOS está enfrentando. Pessoas essas cujos servidores continuarão funcionando e não tem interesse ou disponibilidade de ajudar na distribuição. Pessoas que não se importam em esperar e que não querem se envolver. Você é uma dessas pessoas? Ok, continue no seu CentOS. Admito que em muitos lugares também vou continuar.

Razões para não continuar no CentOS

Desde o lançamento oficial do RHEL 6, o desfile dos egos nas listas do CentOS tem se tornado extremamente desagradável. Me lembro da “data de lançamento” já ter sido marcada e descumprida umas quatro vezes. E ao invés de todos arregaçarem as mãozinhas e empacotar, o development team parece estar mais preocupado em discutir o sexo dos anjos nas listas da distribuição. Muitos questionam a entrega do CentOS 5.6 e 6, sugerem fusão entre o Scientific Linux e o CentOS ou uma colaboração mútua, oferecem ajuda, mas tudo vira motivo para a trollagem fluir. E o tempo passa. E nada do CentOS 5.6 e 6…

Minha história com o Scientific Linux

O Scientific Linux também é um clone do Red Hat Enterprise Linux com bastante qualidade. Assim como o CentOS, ele não é exatamente igual ao RHEL (se você, usuário CentOS, diz que o RHEL é idêntico ao CentOS, certamente você nunca usou o RHEL). Utilizei-o na versão 5.3 quando tirei o Fedora do meu desktop. Desde o momento que o instalei, reparei que o Scientific Linux é mais organizado que o CentOS, tem mais pacotes e tinha opção de usar XFS na / (que o RHEL só adicionou na versão 6!). A arte era mais feia – beeem mais feia – que a do CentOS, na minha opinião, mas troquei o papel de parede minutos depois.

Apesar de todas essas qualidades, percebi que a comunidade do Scientific Linux não levava as atualizações do sistema muito a sério, e algumas falhas que eram corrigidas bem em em tempo no CentOS acabavam demorando muitos dias mais para serem corrigidas no Scientific Linux. No ato da instalação, quando o fiz, a versão 5.3 havia acabado de ser lançada, e o CentOS 5.3 já estava em meia vida, com o RHEL 5.4 quase pronto. Isso me jogou um balde de água fria, e quando o CentOS 5.4 foi lançado, alguns meses depois, chutei o Scientific Linux 5.3 e voltei para o CentOS.

Essa demora extra no ciclo do Scientific Linux eu continuei acompanhando e confirmei nos releases seguintes. No entanto, o que parecia impossível, aconteceu com o CentOS. E nesses últimos dois releases, até o CERN/Fermilab (que também demoraram para lançar o Scientific Linux 6) conseguiram ser mais rápidos que o CentOS.

Mas, cansado da espera pelo novo CentOS 6, cogitei novamente a minha volta para o Scientific Linux.

A continuidade em outro clone do Red Hat Enterprise

Quando eu estava quase concretizando a instalação do Scientific Linux, li essa thread no LinkedIn onde outros usuários de CentOS reclamam da mesma questão que eu: Guerra de egos na disponibilização das versões, incógnita de tempo, demora exagerada e etc. E nessa mesma thread descobri o PUIAS Linux, outro clone do Red Hat mais antigo que o CentOS e mais fiel ao Red Hat original.

O PUIAS é desenvolvido pela universidade de Princeton, e desde que tenho o utilizado, o descobri como uma distribuição mais madura que o CentOS apesar de menor, que distribui rapidamente as atualizações do sistema operacional, e que ficou pronta bem antes do Scientific Linux 6.

O PUIAS não tem mídia de instalação (o usuário precisa cria-la se quiser instalar), ou realizar a instalação por rede como é meu costume. O fato de também ser desenvolvido por uma univerisade, que acima de tudo possui COMPROMISSO, me garantiu mais firmeza para experimentar, e estou a poucos passos de migrar meu desktop para o PUIAS 6. Basicamente só falta eu terminar de empacotar o KDE, cujo mesmo procedimento eu também precisei realizar no RHEL 6 e Oracle Unbreakable Linux 6.

Conclusões

Você está aguardando o CentOS 6 ou um bom clone do Red Hat Enterprise Linux 6? Se a resposta for a segunda alternativa, experimente o PUIAS, você não tem mais nada a perder mesmo…

Atenciosamente,
Lucas Timm.

Categorias:Linux, RedHat

Recreating the suse/RHEL/CentOS initrd file

23 de janeiro de 2011 10 comentários

Things change. In an enterprise enviroment, sometimes we’re surprised adding a new hardware component inside a server and the Linux won’t boot up properly. Or maybe you’re just virtualizating (by P2V) a server and faced this problem too, once the original hardware isn’t compatible with the virtual infrasctructure provided by your new hypervisor. And the “Kernel Panic: Unable to sync VFS“, or just a single-user shell with a incomplete Linux kernel waiting for your action (as you would do something!) is the only thing you’re getting.

suse problem

Luckily, it’s really easy to fix it.

The scenario

In my case I added a fibre channel card in some servers of my company. All the servers will now access my storage device, and the same storage is already configured to receive the servers’ requisitions.

All the servers will not boot from the storage device. They all will keep booting the OS from the local array and disks, but I need the lpfc.ko module loaded from boot to mount a few directories by fstab (a /usr/sag, a /u02 and a /u03 from an ADABAS and a Oracle servers).

I don’t need to reinstall the OS to solve this problem, I just need to recreate the initrd file and put the module inside it. To do this I will use the mkinitrd program, but the sintax is different to a Linux distribution from another…

So If I don’t update the initrd file, all the LUNs will be detected later by udev, and the respective services may crash by trying to start some applications without any data inside the pointed directories. And a disaster may occour.

The first system: A Suse Linux Enterprise Server 10.2

I think the suse’s mkinitrd it’s the easiest mkinitrd command I’d already tried. You can be sure by reading the manual with the “man mkinitrd” command. To do what we want, you need only to edit the /etc/sysconfig/kernel file using vi:

vi /etc/sysconfig/network

Now, look for the INITRD_MODULES line and add the module you need inside the quotes:

INITRD_MODULES=”lpfc ide-core ide-disk scsi-mod sd_mod scsi_transport_spi mptbase mptscsih mptspi piix  ata_piix processor thermal fan reiserfs edd”

Backup your current initrd file: check your /boot/initrd symlink and backup the original initrd ramdisk. Just recreate the initrd file with the command:

mkinitrd -d /dev/sda2

(where /dev/sda2 is your root device. Check your /etc/fstab file or “mount” command)

If the command finished well, it creates a /boot/initrd-your-kernel-version-and-patches.img file. Update your boot menu (usually in the /boot/grub/menu.lst file) and reboot your server to test if your new hardware device was now detected correctly at boot. Quite easy, a piece of cake!

The another systems: A RHEL 5.5 and a CentOS 5.5 and 5.4

Now I’d just finished my suse server, there’s still a Red Hat (and based) servers waiting for the same update. In RHEL/CentOS and Fedora, there’s no /etc/sysconfig/kernel to mkinitrd read. mkinitrd will read the /etc/modprobe.conf and /etc/modprobe.d/* files, and the sintax is a quite different.

When everything works well, you just need to append “alias your-module your-module”, “alias your-module some-alias” or “install your-module /bin/true” in this file (/etc/modprobe.conf). So re-create the initrd using the following command:

mkinitrd -v -f /boot/your-new-initrd-file.img $(uname -r)

Warning! Pay attention on the text output: Sometimes the module isn’t inserted as it should! If mkinitrd did it, you’ll need to specify this module to mkinitrd by hand:

mkinitrd -v -f /boot/new-initrd.img $(uname -r) –with=lpfc

According the manual, with the “–with” tag, mkinitrd command include the specified module to load after all the SCSI modules. This is what I want, but maybe you need to load a driver before the SCSI modules subsystem. So replace the “–with” parameter by “–preload“.

Now your new initrd file is ready. Update your /boot/grub/menu.lst file and reboot your server to check if everything worked fine.

That’s all, folks!
Lucas Timm

Categorias:Diversos, Linux, RedHat

Teste – Red Hat Enterprise Linux 6 Beta 1 e 2

27 de outubro de 2010 4 comentários

Eu sei, eu sei. O RHEL6 Beta 1 saiu em Abril, e se não me engano, foi no dia 21 (não googlei pra confirmar). O Beta 2 saiu em junho, com uma atualização em julho. Mas estou trabalhando demais, e somente agora tive tempo para experimentar (e fazer uma análise) daquilo que virá. Testei as duas versões. As imagens ainda são baixáveis no FTP da Red Hat, tanto o primeiro quanto o segundo, e não se sabe até quando (provavelmente até o último estágio dos RCs, mas não é confirmado). O mirror é lento, e por isso o download é demorado. Apesar de tudo, tenho me divertido bastante na distribuição. Não quero ser pego desprevenido quando adquirirmos a versão 6 final e quando o CentOS 6 for entregue. Afinal, muitas coisas aconteceram no mundo Linux desde o lançamento do Red Hat 5 (que foi em 2007) pra cá.

Deixando de lero-lero. Gimme the tech specs!

As especificações são praticamente as mesmas do Fedora 12. Estou testando o RHEL6 como servidor, então, não instalei nenhum pacote oriundo do Fedora ou de repositórios externos. Então, o que obtive foi:

Kernel: 2.6.32-19.
GCC: 4.4-3
GLIBC: 2.11
Gnome: 2.28.2
X: 7.5.6
Yum: 3.2.27-12

BETA1Instalação e primeiras impressões do RHEL6

Após o download, criei uma máquina virtual no VMware vSphere 4.1. Setei o tipo da máquina virtual como “Red Hat Enterprise Linux 6 64-bit”, com quatro processadores, 4GB Ram e 20GB em disco. A imagem de instalação estava na mesma LUN do storage. Nesta definição, por padrão, o vSphere setou o driver de disco da máquina pra “VMware Paravirtual” e o driver de rede pra “VMXNET3”, algo que estranhei. Afinal, paguei pra ver se o driver de disco seria detectado na instalação uma vez que o “VMware Paravirtual” só costuma ser detectado após a instalação do vmware-tools, bem como o VMXNET3, cuja ausência me impediria de realizar uma instalação por rede. Instalação por rede, agora, não era o caso, então azar. Mas, chegou a hora da instalação e… Batata! Disco não encontrado – e nem a rede. Então, reconfigurei a controladora da máquina virtual pra “LSI Logical SAS”, reinicializei-a e a instalação aconteceu normalmente. Comecei com o pé esquerdo…

Mesmo assim, após isso, a instalação aconteceu às mil maravilhas. Não pediu serial como nas versões oficiais. Gostei da nova versão (?) do Anaconda, uma vez que ele ficou mais limpo, mais organizado e com um tema mais bonito. Entretanto, o particionamento ficou mais confuso. Não experimentei as opções padrão, e (como sempre), selecionei “personalizar”. Afinal, julgo o particionamento como a etapa mais importante da instalação. Todo o resto você repara depois via sistema, mas se o particionamento for ineficaz, ainda que use LVM, é mais trabalhoso (e arriscado) uma recuperação posterior.

Minha primeira surpresa foi agradável: Pela primeira vez, é possível instalar o RHEL6 oficialmente em XFS. Parece que finalmente a Red Hat escutou os clientes nesse aspecto, apesar de agora já existirem file systems mais modernos que este. Por default o sistema de arquivos recomendado é o EXT4, que foi o que utilizei. Criei uma /boot com 100MB, um Volume Group denominado “system” com 19.8GB e mais dois Logical Volumes: Um denominado “Swap”, de 512MB e outro denominado “root”, com o resto dos quase 19.5GB para montar a /. Não especifiquei /home, /var, /tmp ou /usr, pois nesse caso, pelo servidor ser virtualizado, não haverá sobrecarga de um ou mais discos (todos os volumes estão no storage, com RAID5, compartilhados com outras máquinas virtuais).

Prosseguindo a instalação, também gostei muito da nova organização dos pacotes. Unificou-se aquela burra divisão “Base” / “System” existente no Red Hat 5. Existe uma enorme (enorme!) quantidade de pacotes direto do DVD de instalação, mas isso se dá, provavelmente, pela distribuição ainda estar no Beta 1. No produto final, com certeza haverá a costumeira divisão de pacotes baseada em tipo de instalação (Server, Workstation e Virtualization). O resto foi automático, bastando setar a senha de root, timezone, hostname e etc. O sistema foi instalado perfeitamente e não achei nenhum bug.

Utilização

A primeira coisa que pensei após instalar foi: O sistema dá uma impressão de agilidade maior que o Red Hat 5. No entanto, o Red Hat 6 perdeu o bonito RHGB que o acompanhava na série 5, e disponível no Fedora de 6 a 9. Isso já era esperado, e ele foi substituído pelo Plymouth, que é mais flexível e também é bonitão, mas não carrega mais o X como o RHGB fazia, coisa que era legal pra fazer WinLoser pirar (“meu sistema sobe em modo gráfico e interativo, e o seu?“).


É, não dá mais. (Clica que aumenta!)

O desktop do Beta 1 continua com cara de Fedora, porém mais atual. Também quisera, né! 3 anos…

Instalei o VMware Tools, como de costume, que compilou absolutamente sem problemas. (No Red Hat 5 e CentOS 5, os módulos já não são mais compilados, uma vez que o instalador já carrega os módulos prontos pro kernel utilizado por ambas).

Sobre o BTRFS

Eu queria experimentar o BTRFS já nessa instalação, e não foi possível. Porém, após ler o draft do Migration Guide, verifiquei que existe uma opção à ser informada ao kernel e que disponibiliza o módulo do BTRFS para instalação. O uso é experimental, mas como estou usando pra “brincar”, deixei pra testar no Beta 2. Não iria reinstalar o Beta 1 “só” por isso. Se tiver mais um ou dois curiosos por aí, basta digitar “linux icantbelieveitsnotbtr”(wtf!?) ao selecionar o kernel no início da instalação.

BETA2Instalação e segundas impressões

Após dois dias de testes, chegou a hora de baixar o Beta 2 e acompanhar as mudanças que ocorreram nesse meio tempo. Ao chegar no mirror, surpresa: A mídia de instalação já havia sido modificada, e já disponibilizada como Server e Workstation. Baixei ambas, em versão do dia 15 de julho de 2010, mas até o momento, só fiz a instalação da versão Server. A Workstation eu utilizarei em algum desktop que eu achar sobrando por aqui.

As mudanças nessa versão se tornaram mais evidentes que na anterior. A interface gráfica foi alterada e está mais bonita. Passei a opção “icantbelieveitsnotbtr” pra testar o BTRFS, como deixei pendente no Beta 1, mas ao chegar no particionador, ainda não estava disponível. 😦

O Anaconda também ficou mais “a cara” da Red Hat. No instalador ele já solicita o cadastro da Red Hat Network para quem possuir uma conta de avaliação. Eu não tenho, então pulei essa parte. Todo o resto foi sem surpresas e sem alterações. Não reaproveitei nem o anaconda-ks.cfg da instalação anterior pra verificar se alguma feature foi alterada, e com exceção da RHN, não houve nenhuma outra modificação funcional, somente a arte. O nome “BETA” já não está mais tão estampado como no Beta 1, o que passa um ar mais sério ao sistema (apesar do WARNING) no início da instalação.

A mídia Server não está mais tão enxuta quanto o da série 5. Em comparação ao Beta 1, notei falta apenas do OpenOffice (que no Beta 3, se houver, provavelmente será substituído pelo LibreOffice), e cuja ausência é normal numa mídia de instalação Server. O Plymouth, por padrão, veio com um tema bem mais insosso que o do Beta 1, pra não dizer mais feio: apenas um anel girando durante o carregamento do sistema. Samara Morgan mandou dizer que a-do-rou. Eu não.

Alguns pacotes também sofreram atualização desde o Beta 1 (mesmo?). As versões de alguns deles:

Kernel: 2.6.44-1.
GCC: 4.4.4-10
GLIBC: 2.12-1.4
Gnome: 2.28.2
X: 7.7-17
Yum: 3.2.27-12

BETA 2 – Utilização


(Seven days.)

Após a instalação, configurei o yum habilitando os repositórios pro RHEL6 Beta, e instalei mais alguns temas pro Plymouth. Boot feio aqui não! Diferente do Beta 1, as pastinhas do Gnome agora são azuis e tem relevo. Déjà Vu? As ferramentas que ficaram foram as seguintes:

– system-config-authentication
– system-config-lvm
– system-config-date
– system-config-network (mas ela chama a system-config-network-tui)
– system-config-firewall (muitas alterações, eu gostei)
– system-config-kdump
– system-config-printer
– system-config-keyboard
– system-config-printer-applet
– system-config-kickstart
– system-config-services
– system-config-language
– system-config-users

O sistema já tinha um update de kernel disponível, e agora foi atualizado pro 2.6.32-44.2. As configurações do Apache continuam seguindo o (ótimo) padrão da Red Hat, o que vai garantir uma atualização tranquila para aqueles que seguem essa hierarquia. Pelo menos do ponto de vista do servidor web. Também não encontrei o gdm-setup, front-end que configura o gdm, em ambos os Betas, o que dificultou a configuração de login remoto diretamente via X.

Quebrando o gelo – RHEL5 x RHEL6

A primeira diferença que senti no Beta 1 foi ao configurar a interface de rede: CADÊ O SYSTEM-CONFIG-NETWORK? É um mundo cão, mas sim. Eles tiraram. 😦 Rapidamente fui ao system-config-services, encontrei o serviço de rede (network) ativo, corri pro /etc/sysconfig/networking e não encontrei nenhuma configuração de dispositivo. Segundo o draft de migração do RHEL5 para RHEL6, confirmei o que eu não queria ter visto: O system-config-network foi substituído pelo NetworkManager e seu nm-applet. Isso gerou conflito com os usuários, e algumas pessoas reclamaram no bugzilla a ausência do utilitário. Não deu outra, a comunidade venceu e a Red Hat reinseriu o system-config-network novamente na árvore do RHEL6. 😀 Mas, no Beta 1, não teve jeito. Fiquei sem.

De acordo com o mesmo documento (que está desatualizado), outras ferramentas de configuração também foram retiradas. Uma regressão no meu humilde ponto de vista. E isso se aplicou ao:

– system-config-boot
– system-config-network
– system-config-cluster
– system-config-http
– system-config-lvm (apesar que no meu, está instalado e funcionando bem. Sempre foi uma ótima ferramenta)
– system-config-netboot
– system-config-nfs
– system-config-bind (ok, era cheio de bug e eu preferia fazer na mão. Entendo que deve ser um saco parsear configuração do Bind. Mas não seria melhor ter consertado? Era uma ferramenta com muito potencial)
– system-config-samba
– system-config-soundcard (obsoleto por que agora o sistema detecta as placas de som automaticamente? Com o PulseAudio? Garanto, ESSA VAI FAZER FALTA).
– system-config-switchmail (obsoleto por que, segundo o manual, o novo MTA padrão é o Postfix. Comigo isso só se comprovou no Beta 2. No Beta 1 ainda era o Sendmail).

E outras ferramentas que foram reagregadas:

– system-config-securitylevel (melhorou, unificado no system-config-firewall)
– system-config-rootpassword (melhorou, unificado no system-config-users)
– system-config-display (essa melhorou, foi substituído pelo XRandr, que tem se mostrado excelente de um ano pra cá)

Eu entendo algumas das mudanças aí realizadas, mas são poucas. Bem poucas. Concordo que o system-config-http, system-config-nfs, system-config-samba e system-config-boot eram ferramentas extremamente básicas e sua manutenção levava tempo. Mas, se o RHEL já tem uma interface gráfica confortável de usar, não seria mais racional o incremento dessas ferramentas visando uma melhor integração do sistema como um todo? “mimimi eu só uso o modo texto” – Eu sei Flipper (Marcellus®), eu também. Mas ferramentas gráficas fazem MUITA diferença, principalmente pra gerentes, pseudo-administradores e alguns outros cargos administrativos. Os faz pensarem que sabem realizar qualquer tipo de configuração, tira a impressão de “modo texto é coisa do passado” (aham, fala isso pra IBM, CISCO, Oracle, Sun e etc) e dá um peso uma feature a mais pro sistema.

Das configurações que realizei, gostei do syslog ter sido substituído pelo rsyslog e já ter o plugin de integração com o PostgreSQL direto da instalação, é um dos meus principais recursos de monitoramento. Há vários plugins do Yum também disponibilizados direto dessa mídia. Outra alteração já prevista foi a adoção do upstart, existente no Fedora desde a versão 9, e agora trazida por padrão no Red Hat 6. Eu não gosto, mas humildemente entendo que é um caminho sem volta. Assim como em outras distribuições, as configurações do upstart ficam no /etc/init e disponíveis no man 8 init, man 5 init, e no caso dos Red Hats, /etc/sysconfig/init.

Testes que ainda vou realizar

Das coisas que realmente quero experimentar no RHEL6 são os novos recursos de virtualização, com a criticada e elogiada substituição do Xen pelo KVM. Eu realmente estou ansioso para testar o RHEL6 como hypervisor, pois desde o princípio, “fui mais com a cara” do KVM do que do Xen. Os motivos que tenho para isso são completamente pessoais, nem adianta vir com mimimi se você prefere o Xen. Eu sei usar bem a ambos, mas prefiro o KVM pela excelente integração com o kernel Linux em si, coisa que não acontece com o Xen. Isso não pode ser feito numa máquina virtual, então não posso testar por agora, mas vou aproveitar algum IBM x3400 que tenho sobrando aqui no trabalho desde que foram substituídos e brincar com a virtualização.

Considerações finais

Nenhuma. Tudo o que foi descrito foram conclusões minhas. Ainda tenho muita coisa pra testar, provavelmente escreverei outras coisas relacionadas a essa distribuição. Se você ficou com vontade de experimentar, aproveite a disponibilidade e faça os testes que julgar necessário. 🙂

Stay safe,
Lucas Timm.

Categorias:Linux, RedHat

Considerações sobre a relação entre o Unix e o Linux

10 de janeiro de 2010 4 comentários

No artigo passado, deixei aberta uma questão importante, e foi proposital. Em alguns momentos comparei o Unix e o Linux indistintamente, visando um detalhamento futuro da relação entre os dois sistemas operacionais, que será explicado agora.

Pode ser que, ao ler algumas citações do artigo anterior, você tenha imaginado: Ah mas o Linux também serve pra isso, também roda nessas plataformas e etc. A verdade é que o Unix está em todo lugar. In everywhere. E “em todo lugar”, também inclui-se dentro do Windows (várias partes – principalmente dos descendentes atuais do antigo BSD) e dentro do Linux (várias partes do código, inserido nos últimos anos).

Porém, considerei como Unix apenas as vertentes modernas dos filhos tanto do BSD quanto do System V.

Então Lucas, explica essa relação

Sim. O Linux foi criado com base no Minix. O Minix era um sistema operacional multi-tarefa e Unix-Like (“igual ao Unix”), desenvolvido por Andrew Tannenbaun no final da déca de 80. A finalidade do Minix era educacional, unicamente para aprendizagem. Ele possuía as mesmas funções que o Unix, mas não foi feito a partir do código de fonte dos releases de Unix da época.

Quando o mr. Linus Torvalds se sentiu entediado o suficiente para sentar “um pouquinho” e programar seu próprio kernel, ele não o fez com base no Minix, mas sim como um projeto próprio. Na época o Linux ainda era imaturo suficiente a ponto de precisar do Minix para ser compilado. Assim como o Minix, o Linux também não foi criado com base em código de Unix – seja BSD ou System V.

Linus Torvalds, como todo nerd supremo, era uma pessoa extremamente exigente com os sistemas operacionais que utilizava. Se pra você, querido leitor, não bastarem os fatos dele ter programado o kernel Linux original sozinho (coisa que os GNU/programadores não conseguiram – até hoje) e até hoje ser o principal mantenedor do kernel Linux, existe um terceiro motivo que embasa esse meu comentário: O antigo quebra-pau entre Linus Torvalds e Andrew Tanenbaun sobre a questão kernel monolítico x micro-kernel.

O Solaris (na época: SunOS, BSD) era um sistema operacional que lhe atendia perfeitamente. Ele já era um ótimo programador. E usava Minix em seu 386. Porém, movido pelo gostinho de quero-mais, ele criou seu próprio kernel, e nem ele imaginava o quão grandioso esse sistema se tornaria, sendo um dia um “substituto” para o Unix em muitas aplicações.

Assim sendo, o Linux também é um SO Unix-like, que se comporta igual o Unix, com os mesmos algoritmos de gerenciamento e muitos recursos idênticos. Mas o Linux não é Unix. Solaris, AIX, BSDs, HP-Ux, Irix (R.I.P.), Tru64 (R.I.P.) sim – estes são Unices. O código do Linux também não foi feito com base em Unix BSD ou System V, assim como o Minix.

Sobre a GNU, o Unix e o Linux

O embrião da GNU (GNU is Not Unix) surgiu em 1983. Richard Stallman (quando ele ainda fazia alguma coisa era ciencista do MIT) se sentiu injustiçado pela quantidade de código criado por ele (e outros programadores) no Unix e sendo licenciado de maneira cretina pela AT&T para outras empresas gigantes. Em 1985 ele criou a FSF (Free Software Foundation), com o intuito de criar um sistema operacional livre, cujos conceitos de liberdade se resumia em que: Qualquer um poderia utilizar sem qualquer restrição desde que o código de fonte permanecesse aberto.

A partir de 1985, muitos programadores aderiram essa “causa”, e parecia que de fato esse maravilhoso sistema operacional sairia do forno. Os caras criaram quase tudo: Os aplicativos (vulgo comandos), o compilador, as bibliotecas, e muitos drivers. Só faltava o principal: O kernel! É, irônico que tudo isso fosse criado para rodar nos sistemas operacionais opressores e imperialistas das grandes corporações, mas foi assim durante algum tempo.

A proposta de sistema operacional da GNU, o GNU/HURD, ainda não está concluida – provavelmente só ficará pronta em Pasárgada, e será usado por Manoel Bandeira. Então, os GNUs resolveram partir pro óbvio: Ah, Linus Torvalds tem um kernel. A gente tem o resto. Que tal unir o útil ao agradável? Linus Torvalds concordou, e o Linux foi licenciado na GPL e passou a fazer parte do projeto GNU. O Linux Ganhou desenvolvedores, componentes e muito sucesso. E a GNU ganhou o kernel que faltava!

Muitos membros da GNU, incluindo Richard Stallman, dizem que o Linux foi programado para o GNU. Isso não é verdade. O “destino” permitiu que ambos se integrassem. Provavelmente o Linux não seria o que é hoje sem o projeto GNU, e o projeto GNU também não seria o que é hoje sem o Linux. E muitos membros do projeto GNU chamam o Linux de GNU/Linux, mas é algo mais pessoal do que técnico. Linus Torvalds, como eu, acha idiotice.

O Linux/Windows vão matar o Unix?

É verdade que, a partir do Windows 2000, os sistemas operacionais da Microsoft têm ganhado muito em estabilidade. Isso resultou em que, muitas aplicações antes usadas apenas em estações de alto desempenho movidas a Unix foram portadas para Windows, e aplicações que antes rodavam em hardware e software de primeira qualidade, foram gradativamente portadas para x86 e sistema operacional Windows (ou Linux). E quando falo de hardware de primeira qualidade, me refiro à processadores RISC, Unix 64 bits, 8GB Ram, 2 ou 4 processadores e HDs SCSI.

Humildemente acho que isso é uma regressão, mas em parte, justificado – visto que o x86 realmente evoluiu dos últimos anos pra cá. Por exemplo, o Windows “demorou” pra suportar mais que 4GB de memória Ram, e uma grande quantidade de processadores. O Unix já fazia isso há muito tempo atrás. Entretanto, essa debandada diminuiu bastante o número de aplicações específicas do Unix em comparação ao x86 (Linux/Windows) nas workstations. Versões de vários softwares (como o Maya) foram descontinuados em workstations Unix, e foram migrados para sistemas operacionais como o Red Hat Linux, ou mesmo o Windows Vista/Windows XP. Alguns (como o Catia) ainda permanecem para Unix, também com versão pra Windows, mas é difícil responder até quando isso permanecerá.

Entretanto, vários softwares comerciais que são multi-plataforma, como o Oracle, GIS Design, SAP, Natural/ADABAS, servidores de aplicação (Java), softwares de rede, e etc, continuam sendo desenvolvidos com versões para Unix em mainstream. Essas versões continuam sendo procuradas por empresas que buscam pela performance e estabilidade oferecidas pela plataforma quarentona. Cada um no seu quadrado, o Linux já matou o Unix onde ele podia. Bem como o Windows. Mas, o Unix continuará com suas aplicações específicas, pois embora mais restrito, continua sendo tecnologicamente mais “preparado” para aplicações críticas e de alto desempenho que o Linux e que o Windows. Pelo menos até o momento. 🙂

Stay safe,

Lucas Timm.

Categorias:Diversos, Linux, Unix Tags:, ,

Pequenas Sutilezas dos programas Open Source

25 de dezembro de 2009 1 comentário

Se tem uma coisa que eu realmente ADORO nos programas Open Source, ao contrário dos softwares chatos e sem-graça do Windows, são as pequenas sutilezas que determinados desenvolvedores incluem em seus programas. Isso também acontece no Mac OS X. Por exemplo: Hoje é natal, 25 de dezembro de 2009, e olhe com o quê eu fui surpreendido:

Provavelmente aconteceu o mesmo com a versão for Windows. Mas são coisas que não acontecem, por padrão, no SO da Microsoft. 🙂

Em tempo: Segundo o amigo Stomaz, o Kmess também o desejou feliz natal… 🙂

Stay safe,
Lucas Timm.

Categorias:Linux Tags:, ,

Ajude a BetterPlace.org e ganhe uma cópia gratuita do SoftMaker Office

19 de dezembro de 2009 1 comentário

Conhecia? Eu também não.

Após informações dos velhos amigos do IRC (valeu Caio_Cesar!), fui conferir a suíte de escritório SoftMaker Office. A suíte de escritório tem versão nativa para Linux E Windows (também tem pra Windows CE). O software é proprietário E pago, então, os usuários babacas de software livre podem parar de ler por aqui.

PlanMaker

Pros que continuaram: Os programas Planmaker (planilha eletrônica), Textmaker (editor de texto) e Presentation (slides) são de extrema qualidade, deram de 10 x 0 no desempenho e estabilidade ao manipular os documentos existentes no meu computador em comparação ao seu, digamos, concorrente. Tem formato próprio, além de suportar .doc/.xls/.pps, .rtf e ODF. Infelizmente NÃO suporta OOXML, nem tudo é perfeito. Também não é melhor que o Office 2007, que pra mim é absoluto. Mas pelo pouco que utilizei, concorre igualmente com o Office 2003. Suporta check-spelling em pt_BR e possui uma tradução DECENTE de TODOS os menus que testei. Nem é necessário reiniciar o programa ao mudar o idioma!

TextMaker

A versão pra Linux é um parágrafo a parte. Tem em RPM, é estável, rápida, elegante e bem integrada com o desktop. Abre em 2 segundos (JURO). Tem um visual meio KDE2, segundo o Caio_Cesar (eu não sou dessa época), mas o visual me agradou. É simples e intuitivo, com menus bem claros a respeito das opções. Tem alguns diálogos estilo Windows 9x/Wine, mas não sou fresco, e o que me importa é a funcionalidade.

O site da SoftMaker está com uma “promoção”. Qualquer pessoa pode se registrar gratuitamente e ganhar uma cópia gratuita do SoftMaker Office para uso perpétuo, ganha suporte gratuito e descontos no caso de upgrade para as próximas versões. Vale as versões pra Windows E pra Linux. De cada download realizado, a SoftMaker doará 10 centavos de Euro (não sei fazer o simbolozinho) para a BetterPlace.org, organização que ajuda uma penca de gente por aí (dá uma olhadinha no site, doa algo lá também!). Até o momento, 3.300.40 Euros já foram doados. Ou seja, tá fazendo sucesso. 🙂

Quer uma cópia participar? Clica aqui, cadastre-se, baixe, teste e divulgue. Aproveite antes que acabe, pois o FAQ não fala de datas!

Stay safe,
Lucas Timm.

Categorias:Diversos, Linux, RedHat