el blog de txurdi » Servidor-web

La Porra sigue creciendo

txurdi — Tue, 02 Jun 2009 16:47:51 +0000

En Febrero del año pasado, con intención de aprender la API de facebook y meterme en el mundillo del desarrollo de aplicaciones, creé junto a Tabi, una aplicación de la que ya he hablado en este Blog, La Porra

La temporada del 2007-2008, acabó con 841 usuarios registrados, que hicieron 2534 apuestas.

Esta temporada, la 2008-2009, el número de visitas a crecido mucho más. Ha habido más de 8000 usuarios registrados, que han hecho más de 16.000 apuestas en más de 100.000 visitas y han dejado más de 500 comentarios.

Además, durante esta temporada se nos ha unido Pello, y nos han llamado de varias empresas para ofrecernos colaboración, que puede que el año que viene haga crecer más a nuestra pequeña.

Cualquier idea que se os ocurra para hacer mejorara la aplicación, siempre es bien venida…

Compártelo

MySQL, PHP, fechas e idiomas, vaya lio…

txurdi — Sat, 30 Aug 2008 13:09:09 +0000

Como comenté en el POST anterior, ya hemos lanzado La Porra, pero ahora quiero escribir aquí algunas conclusiones técnicas que he sacado respecto al tema de las diferencias horarias y los idiomas de las fechas tanto en MySQL como en PHP.

El servidor que uso es un Solaris, creo (Joyent me lo dio gratis y configurado), y no sabía como cambiar la hora del sistema ni el idioma. Como no quería andar haciendo pruebas en el servidor de producción y no quería andar reiniciándolo, pensé en cambiar las configuraciones de PHP y MySQL. Aquí os dejo como lo he hecho:

En Bilbao, usamos el uso horario CET ([bilbainada*] y el resto de centro Europa nos copia[/bilbainada]) en invierno y CEST en Verano.
CET: Central European Time (GMT+2) (30 de Marzo – 26 de Octubre)
CEST: Central European Summer Time (GMT+1) (26 de Octubre – 30 de Marzo)
En el listado de usos horarios standar suele llamarse “Europe/Madrid”.

Pues bien, para cambiar el uso horario en PHP, en tiempo de ejecución, podemos hacerlo con date_default_timezone_set:

date_default_timezone_set('CET');//o 'Europe/Madrid', pero yo no lo he conseguido hacer funcionar así, a ver que pasa cuando cambie el uso...

Y para cambiar el idioma en que se escribe la fecha, usamos setlocale:

setlocale(LC_ALL,'es_ES.UTF-8); //es_ES.UTF-8 tiene que estar en el sistema.

Cuando hemos cambiado setlocale, para que nos escriba Martes en vez de Tuesday, tenemos que usar la función strftime():

// %A - nombre completo del día de la semana de acuerdo a la localidad actual
// %B - nombre completo del mes de acuerdo a la localidad actual
// %d - día del mes como un número decimal (rango 01 a 31)
// %g - como %G, pero sin la centuria.
// %G - El año de 4-dígitos correspondiente al número de semana ISO (vea %V). Éste tiene el mismo formato y valor que %Y, con la excepción de que si el número de semana ISO pertenece al año siguiente o previo, ese año es usado en su lugar.
// %H - hora como un número decimal usando un reloj de 24 horas (rango 00 a 23)
// %I - hora como número decimal usando un reloj de 12 horas (rango 01 a 12)
// %j - dúa del año como un número decimal (rango 001 a 366)
// %m - mes como un número decimal (rango 01 a 12)
// %M - minuto como un número decimal
// %S - segundo como un número decimal
// %u - día de la semana como un número decimal [1,7], en donde 1 representa Lunes
// 'l, d \d\e F H:i'  ==>  '%A, %d de %B %H:%M'
echo strftime('%A, %d de %B %H:%M',$tiempo); //donde tiempo es un UNIX-TIMESTAMP
// Escribirá: sábado, 30 de agosto 14:45

Con eso, ya he podido ver la fecha-hora que aparece en pantalla en castellano, además de que la hora actual esté en la hora de aquí. Pero si en MySQL hago “now()” me sigue saliendo la hora del sistema. Para cambiar eso:

SET GLOBAL time_zone = 'Europe/Madrid';

(Puede que haya que reiniciar MySQL, o por lo menos salir y entrar de nuevo) Para ver si lo hemos cambiado bien:

SELECT @@global.time_zone, @@session.time_zone;

Donde pongo “Europe/Madrid”, se pueden poner otros time-zones cargados en Mysql.
Cuando yo hice esto, no funcionó a la primera porque MySQL no tenía cargados los timezones, por lo que tuve que cargarlos desde el sistema, con un comando de MSQL:

mysql_tzinfo_to_sql "directorio_de_tz" | mysql -u root -p mysql

["directorio_de_tz" en mi caso era: "/usr/share/lib/zoneinfo"]
Mas información sobre MySQL y este tema en la documentación de MySQL (9.7. MySQL Server Time Zone Support).

¿conocéis otra manera de hacer esto? ¿tendré problemas más adelante? ¿que pasará cuando cambie el horario de verano? Iré actualizando este POST, tranquilos…

Compártelo

Capitulo VIII: Resumen y listado de artículos de ayuda

txurdi — Tue, 17 Jun 2008 18:25:05 +0000

Artículos seguidos para realizar este articulo:

http://articles.slicehost.com/2008/4/25/ubuntu-hardy-setup-page-1
http://articles.slicehost.com/2008/4/25/ubuntu-hardy-setup-page-2
http://articles.slicehost.com/2008/4/30/ubuntu-hardy-ruby-on-rails
http://articles.slicehost.com/2008/5/9/ubuntu-hardy-mongrel-and-mongrel-clusters
http://articles.slicehost.com/2008/4/25/ubuntu-hardy-installing-apache-and-php5
http://articles.slicehost.com/2008/5/9/ubuntu-hardy-apache-rails-and-mongrels
http://articles.slicehost.com/2007/9/5/introduction-to-svnserve
http://articles.slicehost.com/2007/9/5/using-ssh-with-svnserve
http://articles.slicehost.com/2007/9/6/multiple-projects-and-subversion
http://articles.slicehost.com/2007/9/6/multiple-repositories-and-subversion

Otros Artículos de ayuda:

Para aprender la configuración de Apache2 (a2dissite, a2ensite, a2dismod, a2enmod):

http://articles.slicehost.com/2008/4/28/ubuntu-hardy-apache-config-layout

Para configurar Apache2 de manera más optima:

http://articles.slicehost.com/2008/4/28/ubuntu-hardy-apache-configuration-1
http://articles.slicehost.com/2008/4/28/ubuntu-hardy-apache-configuration-2

Virtual Hosts en Apache:

http://articles.slicehost.com/2008/4/29/ubuntu-hardy-apache-virtual-hosts-1
http://articles.slicehost.com/2008/4/29/ubuntu-hardy-apache-virtual-hosts-2

Conceptos sobre como funcionan las llamadas cliente servidor, y como tener multiples dominios (vhosts):

http://articles.slicehost.com/2008/5/28/how-to-serve-multiple-domains

Copias de seguridad:

http://articles.slicehost.com/2007/10/11/automating-a-daily-rsync-backup
http://articles.slicehost.com/2007/10/10/rsync-exclude-files-and-folders
http://articles.slicehost.com/2007/10/9/backing-up-your-files-with-rsync

Subversion:

http://articles.slicehost.com/subversion

Capistrano:

http://articles.slicehost.com/2008/1/17/capistrano-series-local-setup-and-capistrano

Capítulo anterior: Capitulo VII: Capistrano el “deployador”
Resumen: Configurar un servidor web

Compártelo

Capitulo VII: Capistrano el “deployador”

txurdi — Tue, 17 Jun 2008 18:24:53 +0000

Vamos a por el siguiente paso, el que nos ayuda a “deployar”: Capistrano
Antes de nada, creamos la app Rails en nuestro proyecto:

rails project1 -c

Ok, ahora, vamos a decirle a Subversion que ignore algunos ficheros que no queremos que gestione en las versiones:

cd project1
svn commit -m "Initial commit of project"
svn propset svn:ignore "*" log/
svn propset svn:ignore "*" tmp/
svn commit -m "added ignore to tmp and log"

Vale, tenemos el Proyecto preparado, ahora, instala Capistrano:

sudo gem install capistrano

Para ver la versión de Capistrano instalada:

cap -V

Capistrano v2.1.0

Lo primero que hay que hacer es decirle al proyecto que use Capistrano, ¿o a Capistrano que gestione el proyecto?, es lo mismo, “capifiar” el proyecto: (desde el root de tu aplicación)

capify .

Esto genera dos archivos en nuestro proyecto, que tenemos que añadir a Subversion:

svn status

?      Capfile
?      config/deploy.rb

svn add Capfile
A         Capfile

svn add config/deploy.rb
A         config/deploy.rb

svn commit -m "yay, I capified it..."

Vamos a preparar el archivo de configuración de capistrano “config/deploy.rb”
Por defecto es más o menos así:

set :application, "set your application name here"
set :repository,  "set your repository location here"

# If you aren't deploying to /u/apps/#{application} on the target
# servers (which is the default), you can specify the actual location
# via the :deploy_to variable:
# set :deploy_to, "/var/www/#{application}"

# If you aren't using Subversion to manage your source code, specify
# your SCM below:
# set :scm, :subversion

role :app, "your app-server here"
role :web, "your web-server here"
role :db,  "your db-server here", :primary => true

Tenemos que rellenarlo con nuestros datos de servidor:

set :application, "domain.com"
set :user, "demo"
set :repository,  "svn+project1ssh://123.45.67.890/home/demo/repository/project1"
set :port, 30000
set :deploy_to, "/home/demo/public_html/#{application}"
set :location, "domain2.com"
role :app, location
role :web, location
role :db,  location, :primary => true

Suficiente, vamos a probarlo, cruza los dedos y escribe:

cap deploy:setup

Si todo ha ido bien, tendremos una carpeta nueva en nuestro public_html del servidor, preparada para servir. Dentro de esa carpeta hay dos subcarpetas; “releases” donde se guardara la versión de producción (y las copias de seguridad de cada deploy) y “shared” donde se guardan los ficheros que no cambian (logs, pids y informaciones de systema).
Ya que nuestro repositorio está en el mismo servidor que el Apache, vamos a poner las cosas un poco más simples: (cambia esto en el deploy.rb)

set :deploy_via, :copy

Y si quieres que el usuario encargado de parar y reiniciar los Mongrels sea diferente:

set :runner, user

Pero todavía nos queda explicarle como iniciar los Mongrel: (desde nuestro PC)

touch script/spin
svn propset svn:executable on script/spin

En el fichero creado ay que escribir lo siguiente:

/home/demo/public_html/domain.com/current/script/process/spawner -p 8000 -i 2 -e production

Y subirlo:

svn add script/spin
svn commit -m "added script/spin"

Todo preparado para el primer deploy:

cap deploy:cold

Jur jur… Si todo va bien, este comando ha hecho lo siguiente:

Descarga la última versión del repositorio
La comprime en un archivo temporal
La sube al servidor
La descomprime
Copia el código donde debe y crea algunos enlaces simbólicos y demás. (lo prepara)
Inicia los Mongrels definidos en “script/spin”

Recuerda hacer un vhost, que tenga las siguientes URLs:

access_log --> /home/demo/public_html/domain.com/shared/log/access.log;
error_log --> /home/demo/public_html/domain.com/shared/log/error.log;
root --> /home/demo/public_html/domain.com/current/public/

Capítulo anterior: Capitulo VI: Gestión de versiones con Subversion
Siguiente capítulo: Capitulo VIII: Resumen y listado de artículos de ayuda

Compártelo

Capitulo VI: Gestión de versiones con Subversion

txurdi — Tue, 17 Jun 2008 18:22:32 +0000

Empecemos con el gestor de versiones: Subversion:

sudo aptitude install subversion

vamos a poner el repositorio en el mismo servidor:

mkdir /home/txurdi/repositorio
svnadmin create /home/txurdi/repositorio/project1

Esto ya lo expliqué en otro POST, por ahora lo enlazo, y cuando tenga tiempo lo edito y lo personalizo más:
Que es eso de los repositorsios SVN?
Usar SVN en una aplicación web (RoR)

Ahora, desde tu PC, puedes descargarte el código y empezar a trabajar:

svn co svn+project1ssh://123.45.67.890/home/txurdi/repository/project1

Capítulo anterior: Capitulo V: Apache y PHP
Siguiente capítulo: Capitulo VII: Capistrano el “deployador”

Compártelo

Capitulo V: Apache y PHP y RoR

txurdi — Tue, 17 Jun 2008 13:43:44 +0000

Ahora, instalemos Apache:

sudo aptitude install apache2 apache2.2-common apache2-mpm-prefork apache2-utils libexpat1 ssl-cert

En la instalación, dará una pequeña advertencia:

apache2: Could not reliably determine the server's fully qualified domain name,
using 127.0.0.1 for ServerName

No te preocupes, vamos a solucionarlo. Abre el archivo de configuración de Apache:

sudo nano /etc/apache2/apache2.conf

Y al final del archivo escribe lo siguiente:

ServerName txurdi

Guarda el fichero y reinicia apache (reiniciando de esta manera no mata posibles conexiones abiertas)

sudo apache2ctl graceful

Ya está, si pones tu IP (http://123.45.67.890) en ~~Internet Explorer~~ tu navegador favorito (firefox o safari), podrás ver la página por defecto de Apache.
Breve inciso para instalar postfix:

sudo aptitude install postfix -y

Vamos a instalar también PHP (si no necesitas saltate este paso)

sudo aptitude install libapache2-mod-php5 php5 php5-common php5-curl php5-dev php5-gd \
php5-imagick php5-mcrypt php5-memcache php5-mhash php5-mysql php5-pspell php5-snmp \
php5-sqlite php5-xmlrpc php5-xsl

Hemos instalado unos cuantos módulos que igual no necesitas, quitalos a tu antojo.
Recargamos Apache:

sudo /etc/init.d/apache2 reload

OK, vamos a probar con una nueva aplicación de RoR:

cd ~/public_html
rails railsapp

Vamos a aprobechar ahora para activar algunos módulos de Apache que suelen ser útiles:

sudo a2enmod proxy
sudo a2enmod proxy_balancer
sudo a2enmod proxy_http
sudo a2enmod rewrite

y reiniciamos Apache:

sudo /etc/init.d/apache2 force-reload

Vamos a crear un cluster (como hemos aprendido antes)

cd ~/public_html/railsapp
mongrel_rails cluster::configure -e production -p 5000 -N 3 -c /home/txurdi/public_html/railsapp -a 127.0.0.1

Si miramos el archivo “config/mongrel_cluster.yml”:

cwd: /home/txurdi/public_html/railsapp
log_file: log/mongrel.log
port: "5000"
environment: production
address: 127.0.0.1
pid_file: tmp/pids/mongrel.pid
servers: 3

Creamos el enlace simbólico para que se lance al reiniciar y lo lanzamos nosotros manualmente ahora:

sudo ln -s /home/txurdi/public_html/railsapp/config/mongrel_cluster.yml /etc/mongrel_cluster/railsapp.yml
mongrel_cluster_ctl start

Y vamos a crear un Virtual Host en Apache:

sudo nano /etc/apache2/sites-available/txurdi.net

Escribimos lo siguiente (+o-):


  ServerName txurdi.ner
  ServerAlias www.txurdi.net

  DocumentRoot /home/txurdi/public_html/railsapp/public

  RewriteEngine On

    BalancerMember http://127.0.0.1:5000
    BalancerMember http://127.0.0.1:5001
    BalancerMember http://127.0.0.1:5002
  

  # Redirect all non-static requests to thin
  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
  RewriteRule ^/(.*)$ balancer://mongrel1%{REQUEST_URI} [P,QSA,L]

  ProxyPass / balancer://mongrel1/
  ProxyPassReverse / balancer://mongrel1/
  ProxyPreserveHost on

    Order deny,allow
    Allow from all
  

  # Custom log file locations
  ErrorLog  /home/txurdi/public_html/railsapp/log/error.log
  CustomLog /home/txurdi/public_html/railsapp/log/access.log combined

Activamos el Virtual Host que acabamos de crear y recargamos Apache para que lo conozca:

sudo a2ensite txurdi.net
sudo /etc/init.d/apache2 reload

Si ahora accedes via navegador a tu dominio (en nuestro caso era txurdi.net), verás la página por defecto de Rails

Ok, ya tenemos el server funcionando, pero ¿como hacemos modificaciones en la página? Puf, vaya liada, conectarnos por SSH y cambiar directamente con Vim o Nano. O también podríamos montarnos la carpeta principal en nuestro PC… No, no, no… eso no sería muy prudente. Vamos a ver otras posibilidades: Subversion y Capistrano.

Capítulo anterior: Capitulo IV: Mongrel
Siguiente capítulo: Capitulo VI: Gestión de versiones con Subversion

Compártelo

Capitulo IV: Mongrel

txurdi — Tue, 17 Jun 2008 13:26:33 +0000

Instalemos Mongrel [Web oficial de Mongrel] (que es una gema, osea que simple):

sudo gem instal mongrel

Nos instalará alguna otra gema necesaria si no la tenemos ya instalada.
Mongrel tiene 3 instrucciones básicas (start, stop y restart), pero se puede combinar con muchos parámetros; por ejemplo, si queremos lanzar un Mongrel escuchando en el puerto 6000, y que esté en el entorno de producción:

mongrel_rails start -e production -p 6000 -d

Vamos a ir un poco más lejos instalando un cluster de Mongrels, que son un grupo de Mongrels que funcionan en común.
Primero instalamos:

sudo gem install mongrel_cluster

Para lanzar un cluster de 2 Mongrels empezando en el puerto 8000, sería algo así:

mongrel_rails cluster::configure -e production -p 8000 -N 2 -c /home/demo/public_html/testapp -a 127.0.0.1

El comando genera un archivo en formato YAML, que puedes configurar a tu gusto si no quieres lanzarlo otra vez. El fichero queda algo como esto:

cwd: /home/demo/public_html/testapp
log_file: log/mongrel.log
port: "8000"
environment: production
address: 127.0.0.1
pid_file: tmp/pids/mongrel.pid
servers: 2

Para iniciar, parar o reiniciar el cluster, desde la raiz de la aplicación:

mongrel_rails cluster::start
...  o ...
mongrel_rails cluster::restart
...  o ...
mongrel_rails cluster::stop

Vamos a crear un script de inicio para que se lance el cluster cuando reiniciamos el servidor:
Primero, creamos un enlace: (uno por cada aplicación que tengamos instalada)

sudo mkdir /etc/mongrel_cluster
sudo ln -s /home/demo/public_html/testapp/config/mongrel_cluster.yml /etc/mongrel_cluster/testapp.yml

Ahora, copiamos el script de inicio de la gema en init.d, lo hacemos ejecutable y le aplicamos el runlevel:

sudo cp /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.5/resources/mongrel_cluster /etc/init.d/
sudo chmod +x /etc/init.d/mongrel_cluster
sudo /usr/sbin/update-rc.d -f mongrel_cluster defaults

Debe ser más fácil con “thin” o “mod_rails”, pero los tengo en mi lista de TO-DO
Entonces, ahora, para iniciar, parar o reiniciar:

mongrel_cluster_ctl start
...
mongrel_cluster_ctl stop
...
mongrel_cluster_ctl restart

Y para ver si está todo ok:

mongrel_cluster_ctl status

Lo que nos da algo como:

Checking all mongrel_clusters...
mongrel_rails cluster::status -C testapp.yml
found pid_file: tmp/pids/mongrel.8000.pid
found mongrel_rails: port 8000, pid 2343

found pid_file: tmp/pids/mongrel.8001.pid
found mongrel_rails: port 8001, pid 2346

Capítulo anterior: Capitulo III: Instalar Ruby on Rails
Siguiente capítulo: Capitulo V: Apache y PHP

Compártelo

Capitulo III: Instalar Ruby on Rails

txurdi — Tue, 17 Jun 2008 13:16:32 +0000

Instalemos ruby y sqlite:

sudo aptitude install ruby1.8-dev ruby1.8 ri1.8 rdoc1.8 irb1.8 libreadline-ruby1.8 libruby1.8 libopenssl-ruby sqlite3 libsqlite3-ruby1.8

Necesitamos crear algunos simlinks:

sudo ln -s /usr/bin/ruby1.8 /usr/bin/ruby
sudo ln -s /usr/bin/ri1.8 /usr/bin/ri
sudo ln -s /usr/bin/rdoc1.8 /usr/bin/rdoc
sudo ln -s /usr/bin/irb1.8 /usr/bin/irb

Veamos que version de ruby tenemos:

ruby -v
...
ruby 1.8.6 (2007-09-24 patchlevel 111) [x86_64-linux]

Vamos a instalar rubygems desde el codigo fuente, porque es importante tener la última versión estable (y porque lo dice en el manual que traduzco

mkdir ~/sources
cd ~/sources

Descargamos la última versión (en el momento que escribo esto, dicen que la 1.1.0).
Y desempaquetamos:

wget http://rubyforge.org/frs/download.php/34638/rubygems-1.1.0.tgz
tar xzvf rubygems-1.1.0.tgz
cd  rubygems-1.1.0

Compilamos y creamos un enlace simbólico:

sudo ruby setup.rb
...
sudo ln -s /usr/bin/gem1.8 /usr/bin/gem

Para ver la versión de gemas que acabamos de intalar:

gem -v
...
1.1.0

Actualizamos un poco:

sudo gem update

OJO, si tenéis un slice de poca memoria, no hagáis un ~~“sudo gem update –system”~~, porque actualizaría a la 1.1.1 que os va a dar problemillas de memoria…
Bueno, para ahorrar memoria, al instalar RAILS, lo vamos a hacer sin instalar la documentación:

sudo gem install rails --no-rdoc --no-ri

Podemos ver la lista de gemas instaladas así:

sudo gem list

Comprobemos que está todo bien:

irb
#irb(main):001:0>
require 'sqlite3'
=> true
#irb(main):002:0> exit

Si no dice “true”, la has pifiado, vuelve para arriba…
Si dice true, perfecto, ya está Ruby on Rails funcionando!!

Capítulo anterior: Capitulo II: Actualizacion del SO y ponerlo bonito
Siguiente capítulo: Capitulo IV: Mongrel

Compártelo

Capitulo II: Actualizacion del SO y ponerlo bonito

txurdi — Tue, 17 Jun 2008 13:13:09 +0000

Para revisar la versión que estamos usando (en nuestro caso Ubuntu 8.04 Hardy):

cat /etc/lsb-release

Lo que nos dará algo así:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu 8.04"

Para revisar la memoria usada:

free -m

Que nos dará algo así:

.                  total       used       free     shared    buffers     cached
Mem:             254       43         211          0          3            74
-/+ buffers/cache:       26         228
Swap:            511        0           511

Como usaremos bastante el terminal, vamos a ponerle colorines atractivos y a añadir algunos aliases a estos comandos:

nano ~/.bashrc

Aquí os dejo algunos colorines y aliases bastante chulos que me dejó un amigo, podéis actualizarlos a vuestro gusto:

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color)
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
    ;;
*)
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
    ;;
esac

# Comment in the above and uncomment this below for a color prompt
if [ $(whoami) == "root" ] ; then
        PS1='${debian_chroot:+($debian_chroot)}\[\033[01;35m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
        PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
fi

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD/$HOME/~}\007"'
    ;;
*)
    ;;
esac

# enable color support of ls and also add handy aliases
if [ "$TERM" != "dumb" ]; then
    eval "`dircolors -b`"
    alias ls='ls --color=auto'
    #alias dir='ls --color=auto --format=vertical'
    #alias vdir='ls --color=auto --format=long'
fi

# some more ls aliases
alias ll='ls -lF -h'
alias la='ls -lFa -h'
alias l='ls -CF -h'

alias ..='cd ..'
alias cd..='cd ..'

alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'

alias upd='aptitude update'
alias dist='aptitude dist-upgrade'
alias qwea='aptitude search'
alias asda='aptitude show'
alias zxca='aptitude install'
alias qwe='apt-cache search'
alias asd='apt-cache show'
alias zxc='apt-get install'

alias apagar='shutdown -h 0'
alias reiniciar='shutdown -r 0'

alias syslog='tail -f /var/log/syslog'

Echamos un vistazo a los repositorios que tenemos:

sudo nano /etc/apt/sources.list

Tenemos los básicos, que por ser un servidor de producción nos son suficientes.

deb http://archive.ubuntu.com/ubuntu/ hardy main restricted universe
deb-src http://archive.ubuntu.com/ubuntu/ hardy main restricted universe

deb http://archive.ubuntu.com/ubuntu/ hardy-updates main restricted universe
deb-src http://archive.ubuntu.com/ubuntu/ hardy-updates main restricted universe

deb http://security.ubuntu.com/ubuntu hardy-security main restricted universe
deb-src http://security.ubuntu.com/ubuntu hardy-security main restricted universe

Actualicemos todo:

sudo aptitude update

Configuremos el LOCALE (el idioma del servidor):

sudo locale-gen es_ES.UTF-8
...
sudo /usr/sbin/update-locale LANG=es_ES.UTF-8

Y miremos a ver si hay algo que upgradear:

sudo aptitude safe-upgrade
sudo aptitude full-upgrade

Y ahora que estamos al día, vamos a instalar algunas “cosillas esenciales”:

sudo aptitude install build-essential

Capítulo anterior: Capitulo I: Configuraciones iniciales
Siguiente capítulo: Capitulo III: Instalar Ruby on Rails

Compártelo

Capitulo I: Configuraciones iniciales

txurdi — Tue, 17 Jun 2008 12:48:57 +0000

Lo primero de todo, tienes que entrar al servidor por SSH.

ssh root@123.45.67.89

Entramos como usuario root como excepción, será la única vez que lo hagamos, luego quitaremos acceso root al servidor.
Una vez dentro, lo primero, cambiar la contraseña de root:

passw

y añadir un usuario que usaremos como principal

adduser txurdi

Ahora, quitaremos acceso ssh al usuario root y daremos permisos al usuario txurdi, además de configurar algunas cosas para mayor seguridad:

visudo

Añadimos al final del todo:

txurdi   ALL=(ALL) ALL

nano /etc/ssh/sshd_config

Y cambiamos estos valores a nuestro gusto:

Port 30000                           <--- Usa un puerto diferente si quieres
Protocol 2
PermitRootLogin no
PasswordAuthentication no       <-- Esto sólo si hacemos lo de la clave pública-privada
X11Forwarding no
UsePAM no
UseDNS no
AllowUsers txurdi

Ok, ahora vamos a configurar un poco las iptables. Si no lo entendéis muy bien (como yo) hacer un copy-paste y confiad en PickledOnion que es quien escribió el artículo original en inglés.
Guardamos las reglas existentes en un archivo por si acaso:

iptables-save > /etc/iptables.up.rules

Podemos ver las reglas existentes de la siguiente manera:

iptables -L

Para modificarlas, creamos un fichero de texto nuevo:

nano /etc/iptables.test.rules

En el que escribimos +o- lo siguiente:

*filter

#  Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT

#  Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#  Allows all outbound traffic
#  You can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

#  Allows SSH connections
#
# THE -dport NUMBER IS THE SAME ONE YOU SET UP IN THE SSHD_CONFIG FILE
#
-A INPUT -p tcp -m state --state NEW --dport 30000 -j ACCEPT

# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Reject all other inbound - default deny unless explicitly allowed policy
-A INPUT -j REJECT
-A FORWARD -j REJECT

COMMIT

Y con esta sentencia, aplicamos los cambios:

iptables-restore < /etc/iptables.test.rules

Si volvemos a mirar las reglas, vemos que han cambiado un poquito...

iptables -L

Si todo es correcto, guardamos las reglas descritas arriba:

iptables-save > /etc/iptables.up.rules

Ahora, hagamos que se apliquen las reglas cada vez que reiniciemos el servidor:

nano /etc/network/interfaces

Solo hace falta añadir una línea para que quede +o- así:

...
auto lo
iface lo inet loopback
pre-up iptables-restore < /etc/iptables.up.rules

# The primary network interface
...

Ahora que ya tenemos todo, vamos a hacer que se aplique toda la configuración de SSH reiniciando su demonio:

/etc/init.d/ssh reload

No salgas todavía, primero abre otro terminal y prueba que puedes acceder al servidor, no vaya a ser que hayamos hecho algo mal...

ssh -p 30000 txurdi@123.45.67.890

Si todo ha ido bien, podrás loguearte al server, si no, la hemos pifiado en algún punto, repasa todos los pasos. Si sales de la consola de root, y no puedes loguearte por ssh, puedes usar la consola AJAX que ofrece slicehost desde el panel de administración de tu slice.

Capítulo anterior: Configurar un servidor web
Siguiente capítulo: Capitulo II: Actualizacion del SO y ponerlo bonito

Compártelo