Si pudiera me compraría tiempo a mi mismo, tiempo que he perdido y que estoy seguro que perderé tontamente en el futuro me gustaría tenerlo en otros momentos en los que no lo tengo. Alguno dirá “pues no pierdas ese tiempo y aprovechalo”, pero a veces no es posible, puesto que nos tenemos que adaptar a unas fechas y unos horarios, tanto nuestros como de los que nos rodean.

¿Y todo esto a que viene? Pues viene a que quiero acabar 2 proyectos antes de Septiembre y ando muy justo de tiempo. Si pudiera retrasar esa fecha comprando tiempo de despues de Septiembre, podría estar más relajado y no tendría que quedarme en casa trabajando todo el día, que mis amigos van a pensar que no quiero quedar con ellos…

La gente cercana conoce mi situación y me están apoyando, regalándome todo el tiempo que pueden. Me facilitan muchas tareas para que yo no tenga que hacerlas, de manera que yo dispongo de más tiempo para intentar sacar los proyectos adelante. A partir de Septiembre, voy a tener que regalarles mucho tiempo a ellos en compensación…

Un abrazo a todos los que me están ayudando a que mi tiempo se alargue más, muchas gracias por todo.

Este es un artículo que forma parte de un grupo de artículos para aprender a configurar un servidor web que te pueden interesar.

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

Este es un artículo que forma parte de un grupo de artículos para aprender a configurar un servidor web que te pueden interesar.

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

La opción “-c”, añade todos los ficheros a subversion (pero sin hacer commit)

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

Este es un artículo que forma parte de un grupo de artículos para aprender a configurar un servidor web que te pueden interesar.

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”

Este es un artículo que forma parte de un grupo de artículos para aprender a configurar un servidor web que te pueden interesar.

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

Este es un artículo que forma parte de un grupo de artículos para aprender a configurar un servidor web que te pueden interesar.

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

El “-d” del final es para lanzarlo como demonio, vamos que se queda como un proceso que no te molesta en tu terminal, y que no se muere cuando cierras el terminal.

El comando hay que lanzarlo desde la raiz de tu aplicación, “rails directory”.

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

OJO: La ruta completa y si queréis mas ayuda “mongrel_rails cluster::configure -h”

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

Este es un artículo que forma parte de un grupo de artículos para aprender a configurar un servidor web que te pueden interesar.

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

Este es un artículo que forma parte de un grupo de artículos para aprender a configurar un servidor web que te pueden interesar.

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

Este es un artículo que forma parte de un grupo de artículos para aprender a configurar un servidor web que te pueden interesar.

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

Para asegurarlo más, podemos copiar la clave pública nuestra en el server para acceder sin necesidad de escribir el pass cada vez. Ya lo escribí en otro Post [Acceder por SSH sin escribir clave (clave publica-privada)], por lo que no lo voy a repetir ahora.

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