Probando Ubuntu 12.10

Esto iba a ser un tweet, pero me he dicho a mi mismo "eh, que tienes un blog, así sumas una entrada más". He estado probando Ubuntu 12.10 en el portátil, así que voy a poner a parir un poco a Ubuntu, pero también es extensible al resto en cierta medida.

Ayer el Windows 7 de mi portátil empezó a hacer cosas raras, ya le tocaba reinstalar y me dije, bueno, vamos a darle una oportunidad a Linux que ya lo hecho en falta. Revisando, revisando, vi que para el portátil lo mejor iba a ser un Ubuntu (o una Mint, pero no la he tocado mucho así que tire por lo conocido). ¿El porqué? Por el kernel de Linux, ya que para que funcione mi portátil medianamente bien, un Asus Zenbook ux31e, necesitaba el kernel 3.5 mínimo. En mi otro equipo tengo una Debian 7 que funciona a las mil maravillas, pero el kernel que tienen es el 3.2.0-4 y la verdad, no me apetece ponerme a recompilar un kernel en estos momentos... si, si, ya se que no es difícil, pero oye, hay que hacerlo.

Desde los foros de Ubuntu vi que tenían una sección dedicada a este portatil y ponian que funcionaba casi todo bien (y es mediocierto). Como siempre, me decidí por la última versión de Ubuntu, pese a no ser LTS ya que me gusta "vivir al límite" con cosas medio testeadas. Tras instalarlo y que por fin pudiese usar en una máquina el unity (hasta ahora no he tenido un equipo que lo soportase, bravo Ubuntu, y nos quejamos de Windows), me dije a mi mismo "¿Y esta mierda que es? Bueno, antes de quitarlo o meterle mano, vamos a hacer que funcione bien el portatil". Así que pongo el bifi, lo conecto a la red y... eso pierde más paquetes que otra cosa. Asi que nada, me dije vamos a buscar que seguro que le ha pasado a gente. ¿Solución? "Oye, mira, es que el kernel 3.5 no tiene aun bien los drivers..." No me jodas, ¿y pa eso pongo Ubuntu? Bueno, vamos a darle otra oportunidad, vamos a ver si alguien es amable y tiene un kernel más nuevo puesto en un deb aunque no sea oficial. Y buscando me tope con la web de www.upubuntu.com que van sacando unos pequeños scripts con los últimos kernels disponibles. Y bingo, instaldo el kernel 3.6.9 todo va mas o menos bien.

Así que una vez resuelto el tema de los drivers y hechas las modificaciones que indican en la web de ubuntu para mejorar un poco la duración de a batería me pongo a cotillear a ver que trae esto. Había leido de antemano que en la versión 12.10 habían metido mierda de Amazon en una cosa que se llaman Lens que no se ni que son, asi que he borrado el lens de amazon y el resto que he visto, total pa usar el Firefox, Filezilla, VLC y qBittotrrent no los necesito. Creo que el ubuntu One ese también lo he borrado, y si no, cuando me acuerde lo borro. Uso Google Drive asi que es repe, pero... anda, que no hay Google Drive para Linux (se supone que hay que decir aún... pero vamos). Así que buscando encontré un programa que se llama Grive que hace lo mismo pero manual, oye, algo es algo.

Volviendo al tema de Unity, intenté ver que dejaba tocar para modificarlo y ponerlo un poco más a mi gusto, ya que no me mola tener ahí la barra en la izquierda todo el rato por más que se empeñen desde Ubuntu que mola. No, no mola. Investigando, vi que por sí sólo no se puede hacer nada, si no te gusta cambia de escritorio. Entiendo que hay varios y mola poder elegir, pero coña, no me apetece poner KDE (me da sarpullido no se porque) y menos Gnome3, así que mis opciones eran o buscar alguna forma de toquetear el Unity o instalar xfce, pero oye, ya que tengo un portátil decente, puedo malgastar recursos con chorradas gráficas. Así que en un último intento, busque formas de modificar el Unity. Básicamente es instalar un programa unsettings que por lo menos me deja ocultar la barrita de los cojones. Y con eso ya soy feliz, sin barra molestando y con Linux en el portátil funcionando bien.

Entiendo que en distros como Debian, que tienen que testear todo hasta tenerlo perfecto o Centos que está orientada a servidores (señores, Fedora ya no es servidores aunque se pueda) se retrasen tanto con las actualizaciones de kernels y demás, aunque deberían mover un poco más el culo, pero Ubuntu, que está destinado a un público más "casual", deberían meter más caña a las actualizaciones para extender la compatibilidad con el hardware (dejarse de gilipolleces, que entre el Unity, los móviles y las tablets se les va mucho). Si la gente de Upubuntu publican los kernels rápido, ¿cómo es que Canonical no?* Si quereis ser una alternativa real de Windows o OSX hay que espabilar, que por mucho wubi que saquéis lo lleváis claro.

Como siempre en Linux, a quien hay que agradecer que las cosas funcionen es a la comunidad que tiene cada distro detrás. Bueno, a seguir que hay cosas que hacer y a ver cuanto aguanto con esto instalado en el portatil :P ¡Saludos!

* NOTA: he actualizado al kernel 3.8 con el script de upubuntu y veo que el kernel se lo descargan directamente desde la web de ubuntu, por lo que imagino que simplemente tardan en liberarlos.

PD: Al final he tenido que reinstalar Windows 7, insufrible el tema del wifi. Por lo que he leido es una mezcla de problemas de drivers y del NetworkManager y paso de complicarme la vida en el portatil... perezote que me da oye :P

Administración de Directadmin – Custombuild, Instalación de programas

Seguimos con otro post dedicado al Custombuild. Como vimos en el anterior post, dentro de /usr/local/directadmin/custombuild hay un archivo llamado options.conf que podremos editar para seleccionar versiones y programas que queramos instalar. En otro post nos pararemos a ver las secciones de apache, php y msql, ahora nos centraremos en las demás que aunque son menos importantes nos simplificarán la vida si queremos instalar un antivirus por ejemplo.
Veamos la sección de web apps:

#Web applications
phpmyadmin=yes
atmail=no
squirrelmail=yes
roundcube=yes
uebimiau=no

Atmail: Es un cliente web de correos. Da fallos con el php 5.3 que se pueden corregir con un htaccess que haga que no muestre los errores con la linea “php_flag display_errors off”.
Roundcube: Otro cliente web de correos. Funciona sin problemas y estéticamente está muy bien.
Squirrelmail: Más clientes webs de correos, pero este es feucho.
Uebimiau: Otro cliente web de correos, pero ya es un proyecto muerto por lo que no es seguro usarlo.
Para instalarlos/actualizarlos simplemente tendríamos que ponerlos a yes en el options.conf y hacer ./build roundcube o el cliente que sea.
En la sección del correo, nos centraremos en este caso en estas tres líneas:

clamav=no
mailman=no
spamassassin=no

El clamav es un antivirus que analizará los correos buscando bichos, cabe decir que es un proceso pesado y necesita un equipo decente si tienes un volumen considerable de correos diarios, ya que los escanea todos.
Mailman es una mailing list, no la he probado pero ya de por sí directadmin trae otra instalada llamada Majordomo.
El spamassassin es para bloquear spam, directadmin trae ya un bloqueador, pero tienes que poner manualmente los terminos a bloquear. El spamassassin también consume muchos recursos, he visto casos de llegar a bloquear servidores. Por contra el bloqueador de spam que trae de serie el DirectAdmin no consume apenas recursos.
Para instalar el que queramos, es ponerlo a yes en el options.conf y ./build clamav (o el que toque). En el caso del clamav, a instalarlo me falló:

Starting clamd: LibClamAV Error: cli_loaddb(): No supported database files found in /usr/share/clamav

La solución fue ejecutar “freshclam –v” y reiniciar el servicio clamd.
Para instalar el spamassassin primer hay que solucionar unas dependencias:

cpan -i Archive::Tar Digest::SHA Mail::SPF IP::Country Net::Ident IO::Socket::INET6 Compress::Zlib Mail::DKIM LWP::UserAgent HTTP::Date Encode::Detect ExtUtils::MakeMaker NetAddr::IP Mail::SpamAssassin::Plugin::Razor2 Razor2::Client::Agent IO::Socket::SSL DBI
Redhat-based: yum -y install perl-ExtUtils-MakeMaker perl-Digest-SHA perl-Net-DNS perl-NetAddr-IP perl-Archive-Tar perl-IO-Zlib perl-Digest-SHA perl-Mail-SPF perl-IP-Country perl-Razor2 perl-Net-Ident perl-IO-Socket-INET6 perl-IO-Socket-SSL perl-Mail-DKIM perl-DBI perl-Encode-Detect
Debian-based apt-get install perl-base perl-modules

Es posible que pregunte si estamos preparados para la configuración manual, evidentemente… NO. Así se ocupa de casi todo el cpan, solo peridrá confimar algunas cosas (y tarda un buen rato, asi que hay que estar pendientes de la consola). Una vez finalizada la instalación con ./build spamassassin ejecutamos “ps aux | grep spam” para comprobar que todo ha ido bien. Si no aparece nada, miramos en /var/log/maillog en busca de errores.
Y para acabar, podemos instalar también herramientas para estadisticas web. Tenemos awstat y webalizer. Lo mismo, editamos el options.conf y ./build webalizer.
Con esto, sólo nos falta revisar las partes de apache, php y mysql que tienen bastante importancia a la hora de actualizar de versiones.
¡Saludos!

Administración de Directadmin - Custombuild, actualizacion de paquetes.

Hoy vamos a meternos un poco en la administración de un servidor que corre DirectAdmin. Desde el propio panel nos ofrece bastantes opciones, editar DNS, creación de usuarios, etc... Pero una parte importante, actualizar el sistema, hay que hacerlo desde consola usando una herramienta llamada Custombuild. Pensemos en esa herramienta como una especie de repositorio que contiene los programas principales del servidor web como son el exim (correo), apache y php (web) y mysql (bases de datos). La ventaja de usar el Custombuild en vez de los repositorios de nuestra distro, a parte de ser obligartorio, es que en vez de bajar un paquete e instalarlo, nos descarga los binarios y lo recompila (excepto del mysql, que si usa paquete). Por eso, podremos cargar cualquier módulo que necesitemos y tener nuestro programa con lo necesario. Por norma general, si tenemos hecha ya una instalación previa, no tendremos problemas de dependencias (aunque a veces surgen, pero se suele solucionar instalando esa dependencia desde el repositorio).

En este post, vamos a ver como teniendo un sistema instalado podemos actualizar nuestro sistema con los últimos parches de seguridad que hay. Por norma general, no hace cambios de versiones que conlleven cambios drásticos (pasar de php 5.2 a 5.3, por ejemplo) por lo que no deberíamos tener problemas una vez actualizado. Es script de custombuild se encuentra en /usr/local/directadmin/custombuild y se llama build. Si ejecutamos el script sin ningún comando, nos mostrará todas las opciones disponibles que no son pocas.

# cd /usr/local/directadmin/custombuild
# ./build

En este caso para actualizar el sistema, tendíamos que hacer;

# ./build update
# ./build versions (Para ver como de desactualizamos vamos).
# ./buld update_versions

A partir de aquí empezará a recompilar todo sin apenas molestar (puede que pida alguna confirmación, depende de como ande de desactualizado el sistema). Una vez acabado, ya tendremos todo al día. Otra opción importante que tiene, es crear un cron para actualizar el sistema. Puede actualizar automaticamente el panel (da_autoupdate), las aplicaciones web (squirrelmail, roundcube, phpmyadmin, etc) (webapps_updates) y/o todo el sistema (updates). También se puede poner para que sólo nos avise de que existen actualizaciones (notifications), eso ya depende de cada uno. Para programar el cron, simplemente tenemos que editar el archivo options.conf y dejarlo así:

#Cron settings
cron=yes
cron_frequency=daily
[email protected]
notifications=yes
da_autoupdate=yes
updates=yes
webapps_updates=yes

Como vemos, las opciones que da son autoexplicativas. Evidentemente si queremos que nos avise al correo, tendremos que poner una cuenta válida. Una vez configurado, faltaría activarlo:

./build cron

Y listo. Comprobará diariamente si existen actualizaciones y las aplicará. Al ser parches de seguridad no deben introducir cambios que hagan que te dejen de funcionar las webs, pero podría pasar. Esto ya depende de lo que prefiera cada uno, pero como somos así, es cuando actualizamos que descubrimos que esa version no funciona con nuestra web. Yo por mi parte prefiero que actualice sólo ya que si no,
se me acaba pasando las actualizaciones.

Otro detalle importante del cron es que sólo nos va a actualizar aquellos programas que tengamos marcados en el options.conf, es decir, si tenemos "mysql_inst=no" no actualizará el php, lo mismo para otros como el dovecot o el exim. Revisad el archivo y decidir qué aplicaciones quereis que se actualicen y cuales no. Por otro lado, cuando actualizamos un programa con el custombuild, hay que tener cuidado de si hemos añadido algún módulo a la compilación anteriormente, ya que si no lo hemos metido en la carpeta custom nos cogerá la configuración predeterminada. Por ejemplo para el php en este enlace de la FAQ de DirectAdmin lo explican bien, aunque más adelante pondré cómo recompilar el php con algunos módulos útiles.

Con esto y con las actualizaciones del sistema con los repositorios de la distro, tendremos el sistema actualizado y parcheado para solucionar problemas de seguridad.