[mini] Hello, my little ol’ Arch Server

Durante os últimos dias venho brincando um pouco com configurações de servidores. Não é a parte mais prazerosa de se administrar ou programar um sistema, admito. Mas tem lá seus méritos.

Bem, eis alguns pedaços de conhecimento registrados aqui.

Vanilla vs Patched: você talvez se lembre de que uma vez eu inventei de instalar ubuntu, centos, apache e opensuse, e aquilo era mais para ter uma visão “big picture” da coisa. Atualmente estou testando configurações apenas no arch e no debian, e são dois sistemas suficientemente diferentes porém que se completam para que eu não precise testar em mais nenhum. A questão principal aqui é: no Arch, os pacotes são minimamente alterados (usualmente, não são alterados); isto é, eles são empacotados da mesma forma que upstream quer que esteja. Isso é muito bom para você aprender como as coisas funcionam de maneira pura, e também para perceber como várias distros tentam resolver várias coisas por você; às vezes isso é bom, às vezes isso é ruim; no entanto, é melhor você se expor aos problemas para entender como eles funcionam, na minha visão.

Por exemplo, ao instalar o apache e o php e tentar integrá-los – note que um simples teste pode ser feito através do seguinte documento, chamado (por exemplo) de index.php –,

<?php phpinfo(); ?>

percebemos que no debian tudo isso já funciona out-of-the-box (isto é, o Apache já vem pré-configurado); enquanto que, no Arch, é necessário fazer umas pequenas configurações (10 minutos se você quiser tentar entendê-las sem nunca tê-las feito; 2 minutos se já sabe o que fazer), coisa de descomentar algumas linhas ou acrescentar outras. Isso não é feito às escuras, tudo é muito bem documentado na ArchWiki, para a qual eu tenho o orgulho de contribuir.

Outra diferença é em relação à localização padrão do DocumentRoot: no Arch (logo, upstream) é /srv/http, no debian era (se não me engano) /var/www, e no XAMPP é em /opt/lampp/htdocs. Nenhum padrão, isso dá dor de cabeça às vezes.

Também estou realizando alguns testes com o nginx. Minha conclusão é que o nginx é bem mais KISS do que o apache (e alguns dizem que ele é mais rápido também). De fato, ele parece ser mais confortável de se trabalhar. Porém, ainda estou tendo um pouco de dor de cabeça para integrá-lo com o PHP, através de FastCGI e php-fpm. Provavelmente deixei escapar algum detalhe, alguma linha de configuração, mas estou quase lá.

Outro aspecto legal é o PHPMyAdmin. Não é nada mal poder configurar todas as suas tabelas de MySQL (ou MariaDB, se estiver no Arch, tecnologia iuhul) através de uma interface intuitiva. O PhpMyAdmin vem pré-configurado tanto no Arch quanto no Debian, o que me diz que ele realmente foi feito para facilitar a vida de um administrador de sistemas.

Por outro lado, não achei absolutamente difícil utilizar a linha de comando do mysql / mariadb. Pela pouca experiência que tenho hoje com MySQL, mas somada com a minha boa experiência com linha de comando em geral, posso dizer que a interface CLI do MySQL/MariaDB é bastante intuitiva. O problema é que você precisa saber o que está fazendo (isso não é um problema, é?), precisa saber a sintaxe dos comandos e tudo o mais, coisa que não é tão essencial no PhpMyAdmin. Mas, ainda assim, não tem nada demais, só questão de se acostumar mesmo.

Apesar de toda a vibe e estabilidade do MySQL, estou considerando seriamente em utilizar alguma tecnologia NoSQL para um futuro projeto. Acredito que sua flexiblidade combine mais com meu modo de pensar do que o do MysQL, mas, cada tecnologia possui seus méritos, tirarei minhas próprias conclusões acerca disso no futuro.

Conectar o PHP com o MySQL é bastante fácil. Só questão de descomentar o módulo correto no /etc/php/php.ini. Por sinal, tem bastantes módulos interessantes por lá.

Vejamos…ah sim, usuários e permissões; é bom tomar bastante cuidado com isso! É um assunto que pode dar dor de cabeça. Cada distro tem seus próprios usuários para a web, e seus próprios conjuntos de permissões para que tudo funcione corretamente (e para que o seu sistema não fique tão exposto para o mundo). Posso dizer que se você não usar o chmod, chgrp ou chown sem querer, e deixar os defaults quietos, provavelmente tudo vai correr bem. Isso assume que você não vai fazer nada de anormal, o que…bem, pode nem sempre ser verdadeiro.

Mais uma coisa: use senhas seguras! Isso pode evitar dores de cabeça no futuro. Por outro lado, cuidado para não utilizar senhas seguras demais e depois se esquecer das mesmas. Se você utilizar algum software para administrá-las, certifique-se de que a senha master dele seja ENORME, REALMENTE ENORME. E, se possível, utilize algum método adicional para protegê-lo (2-factor auth, key, etc).

É uma boa prática utilizar 100% da linha de comando para administrar o seu server. Talvez com a exceção do PhpMyAdmin, eu acho que todo bom administrador deveria saber fazer tudo pela linha de comando.

Bem, acho que até aqui isso resume parte da minha brincadeira. É claro que eu não falei sobre uma porção de coisas, tem SSH, tem os arquivos de configuração, tem LAMP/LEMP, tem todos os cenários mais extravagantes que você puder criar. Mas esse é um começo. Para quem disse que ia começar a ler e estudar sobre o assunto , sinto que estou no caminho certo e que comecei bem. Agora, o restante desse caminho depende o que é que eu vou fazer com isso.

Até breve.

(Por sinal, o blog deve continuar congelado. Com exceção de posts como esse, para marcar determinado badge/meta, o tempo de férias é curto, então não vou tomá-lo para inventar posts que não precisam ser inventados)

Advertisements
[mini] Hello, my little ol’ Arch Server

Server Challenge – Instance #1: Installation of Distros

Today I’m covering the installation process of the following distros: Arch, Ubuntu Server, CentOS and openSUSE (as promised); together with the VirtualBox set up.

Let’s begin with the virtualization decisions. We are not creating any real applications, we just want a testing area. So, a virtual machine is the perfect place to poke around. The two obvious options for Linux (my Host/base system is Arch Linux, no surprise) are VirtualBox and VMWare (the free option). Actually, there’s QEMU also, but it is a little advanced (more advanced than I need now).

I opted for VirtualBox. Personally I have familiarity with both VBox and VMWare, but the last one is commercial and closed-source, and I want FOSS as much as possible.

Okay, and what about the decisions?

  • 16 GB for each virtual drive. That’s more than sufficient. 10-12 GB would probably be enough (we are not creating full-featured or storage servers).
  • 512 MB of RAM for each virtual machine. Just one exception: I chose 768 MB for openSUSE, because I knew it would start X by default (sounds like a bad thing for a server…maybe SLES doesn’t behave this way?)

Now, second things second: about downloading the ISOs. There was a good design about them: for every distro, the download was just two clicks away from their home pages.

We need to define a comparison framework to rank the distros. I’ll keep it simple: the best ones will be colored with blue (or green, that depends on my humor), the poor ones with red. If I do not have anything to say about them, I’ll just leave them away, with their default color.

  • Ubuntu: pretty straightforward. You quickly find the download page, either with Google or heading to www.ubuntu.com.
  • Arch:  no trouble, right? www.archlinux.org. There is only one ISO, but if you are considering Arch, you should probably knew that it defaults to a minimal installation environment.
  • CentOS: okay too. www.centos.org. A little hard to find the minimal ISO.
  • openSUSE: http://www.opensuse.org/ you might get confused at first. Which version would you download, the live or the one about network? ‘Network’ sounds like a server, right? I thought that too. But the problem is the description (see below): it does not mention anything related to servers; instead, it sounds more like a minimal ISO, better suited for upgrades.
Downloads the installation system and all packages from online repositories.Suitable for installation or upgrade.

Next: size of the ISOs.

  • Arch: ~500MB. Pretty good. Downside: if you want your favorite software already bundled with the ISO, you’ll be disappointed. Only the core components are included.
  • Ubuntu: ~650MB, nice, nice!
  • CentOS: ~4GB. Damn…unless you spot the minimal ISO: ~400MB.
  • ~950MB (KDE Live). Unless you notice the version you want is the ‘network’ one (it is not). ~300MB.

Now you just noticed I have committed one error. I simply downloaded the wrong (=full-featured) version of CentOS. More errors are to come! Just wait (Great…).

[I ended up with the DVD version of CentOS (because I only discovered the minimal version after the DVD one was installed; and with the KDE Live version of openSUSE — I got trouble with the network ISO. I say it wouldn’t be hard to get it right, but I’m managing 4 distros, besides my own system and my own life, so I do not want to waste my time with a virtual machine I know I’ll dispose a few days from here]

Then…what? Let’s install these beasts! Do not expect me to include screenshots. First, my design decisions:

  • There will be / and swap partitions. Swap will occupy the same as memory (512 MB; 768 MB for openSUSE). The rest will be owned by /. No /home.
  • Ext4 filesystem.
  • LVM! It would be too boring to setup only the classic MBR partition scheme.

Now, here is a brief overview of the installations:

  • Ubuntu: pretty standard ncurses-based setup. I liked it. There is only a little inconvenience: you have to get your options right since the beginning. If you change your mind later, after the installation, about a setup idea, you’ll have trouble figuring out what to do. I’ll repeat: the installer is good, but be sure of what you want. Want an example? Suppose you have set up the wrong timezone, or the wrong keyboard. How do you correct it after the installation? You’ll have to search how to do it, sure. Problem is: now you’ll use the command line. There will be no ncurses-based let-me-undo-my-previous-choice(s)-please. Using the command line is not a problem; the problem is the inconsistency of the pre- and pos-installation. If at least you could know what command the installer issued while you opted for a option with ncurses, it would be fine. But you don’t know. I’m saying hiding commands from the future sysadmin is not a good idea. It might be less scary for the inexperient/newbie learning about servers, but it is not for the I-know-how-to-handle-my-system guy.
  • CentOS: hated. Period. But it at least is intuitive. Problem: chose LVM by default. What if I didn’t want it?
  • openSUSE: I used the KDE Live version, but booted straight to the installation (not to the live environment). The openSUSE installer is amazing. Period. The best installer ever. You can customize (with an intuitive user interface) almost everything you want. For example, it would be ridiculously easy to choose btrfs for my server: the installer would take care of all trouble. So you should expect I had no trouble setting up LVM here. But it has the same flaw as Ubuntu: you don’t know what is happening behind the scenes.  Furthermore, this installer used X (with a mouse interface and everything). Also, after you reboot your VM, openSUSE begins its post-installation. It is the only one (at least, of my 4 distros) which does that.
  • Arch: no installer. I won’t color it red because this is part of the Arch design. The benefits are clear: you have full control over what your system will be. You are the master who controls (almost) every aspect, tweaking and customization of it. And you know exactly what commands you have entered. Now, this might be a problem too. But the problem is between the computer and the chair. If you lack the knowledge of some aspect of the installation (for example, I didn’t know how to setup LVM manually), the installation will take some time, because you’ll have to learn how to do it. But the ArchWiki is amazingly and vastly well documented, therefore you have no excuses. Bottom line: if you are able to set up an Arch server just by yourself, I expect you know what you were doing (GLaDos would be proud. Now, back to testing). Believe me: this is a rare skill. Of course you don’t need to set up Arch to be a skilled person, you can prove yourself an expert with (for example) Ubuntu too. What I’m saying is: using automatic installers is good to save time, but bad to acquire knowledge.

What’s next?

I still have to set up LVM on my Arch VM. I’ll make the following decision: there will be no Arch VM. I’ll use my own system (/ desktop) to play with an Arch server. Why? No need to duplicate effort. Buuuuuuuut I’ll create a VM just to learn (and correctly set up!) about LVM. At least I should to that.

Then, for the next post, there are two possibilities: a) how to set up LVM on Arch (maybe, with a description about LVM in general) or b) I have to think about this. What about LAMP? It looks like the next thing I should to. LAMP stands for Linux-Apache-MySQL-<insert_your_favorite_scripting_language_here>. P could be PHP, Python or Perl. Or Ruby, then we will have LAMR :). So, for b), I think Apache is the best continuation.

Until the next post, people. Comments about your own experiences with these distros are welcome.

Server Challenge – Instance #1: Installation of Distros

Server Challenge – Instance #0

Hey there. So, after the ‘openbox challenge‘ (October 2013), this challenge thing simply became frozen. Now I want to start a new one, about servers. Well, apparently servers are more interesting for people than window managers: that’s right, and also applies to me.

Here is the proposal: I’ll learn about setting up web servers. Period. Which servers?

First things first. One of the things I’ll cover is related to which (free) distros are best for web servers. That’s it, sorry RHEL and SLES (suse). I’ve quickly created a list, these are the distros I’ll cover:

  • My beloved Arch Linux! People say Arch is not a good thing for servers, maybe I’ll prove it wrong. Vanilla packages and full control over your package manager (therefore, your packages) are killer features;
  • Ubuntu LTS (currently, 12.04). Supports end only in 2017. Why not non-LTS versions? Only 9 months of support, sorry. I’d say non-LTS editions are good for desktops, but not for servers.
  • CentOS — well, we need at least one member of the family of RPM-based distros.
  • openSUSELast time I tried it I screamed over it, calling it ‘package hell’. Well, let’s give it another chance. I feel I still like openSUSE, not really sure why.

And Debian? If I’m trying Ubuntu, I’ll say there is no need to try out Debian. There would be only minor differences between them.

So, 4 distros. Do you really think I’ll spend that much of my time setting up virtual machines? Yes and no. In the beginning, yes. After a while, I’ll probably give up on two of them (I guess openSUSE will be one of them).

What is missing? Oh, yes, I need a plan (=”syllabus”) and a schedule.

The plan for the next post/sub-challenge will be always posted in the end of its previous post. Now, I’m saying the next (actually, the first!) step will be the installation process and virtual machine set up (@VirtualBox, sure, it’s open source) of these 4 distros.

And what about the schedule? Let’s see, the openbox challenge one was daily. It was fast, so this decision made sense. But do not expect me to daily create a new post about servers, it would be overkill. Instead, I’ll leave this undefined, scaled according with my spare time (can’t say free time, it is always short!).

Lastly, what’s the purpose of this? Again, you’ll probably find the answer along the openbox challenge post series. Briefly:

  • Self-learning. This is the major reason.
  • But, nowadays, self-learning alone is so lame. I like to share what I learn. This increases day after day, whenever I discover a new amazing open source community. But I always endorse that sharing knowledge does not mean you’ll learn a topic from simply reading what I write. You won’t. At least, not as much as if you studied the topic too. That’s why I encourage you to contribute with this challenge, sharing in the comments what you learn outside here.
  • Documentation. If well written, these posts might be useful for a random person or for my future me.

Always for the knowledge, always for the challenge, always for the sharing with the community.

I guess the previous phrase could become the motto of this ‘challenge’ column.

Until soon (soon could mean a few days, a week, or a few weeks. Let’s hope not a few months).

Server Challenge – Instance #0