La primera tarea que debemos abordar a la hora de comenzar a programar dentro de Magento es la creación de un módulo. Es muy práctico y sencillo atacar a los componentes de Magento desde simples scripts que importan el autocargador y así poder trabajar con los datos. Pero tarde o temprano necesitaremos integrarlo todo dentro de Magento y así quedará más limpio. Podremos modificar el comportamiento de Magento desde dentro, aumentando sus funcionalidades si es que lo necesitamos.
PHP 5.5 dejó de tener soporte en enero del 2016, las actualizaciones de seguridad acaban de dejarse en junio de 2016. Así que a partir de ahora julio del 2016 deberíamos mínimo de tener PHP 5.6 en cualquier servidor para mantenernos al día por lo menos en los parches de seguridad.
Todavía en Ubuntu 14.04 LTS tendrá soporte hasta el próximo 2019. Desde su lanzamiento en 2014, serán 5 años de Long Time Support (LTS). Los ciclos de vida de las librerías incluídas son otra cosa. Aunque se puede pensar que dado el fin del soporte de seguridad para PHP 5.5 se debería de traer ya de casa PHP 5.6 en Ubuntu 14.04. Pero sería forzar a los usuarios a migrar sus aplicaciones a la nueva versión y si hubiera alguna incompatibilidad sería forzar a compatilibilizarlo, algo que puede ser bastante complejo dependiendo de cada aplicación.
¡Hola de nuevo! Cada loco con su tema, así que yo sigo escudriñando cada día más las entrañas de Magento. Mientras voy compartiendo mis pequeños pinitos en el tema. Ahora traigo un pequeño HOWTO, un pequeño tutorial para recorrer los websites, stores y store views que tengamos en nuestro Magento.
Dentro de un Magento podemos tener varios sitios web, cada uno con su nombre de dominio. A su vez, dentro de cada website podemos tener varias tiendas, con su catálogo raíz de productos. Y a su vez también podemos tener dentro de cada tienda sus vistas de tienda, que normalmente se usan para traducir dichas tiendas.
Es decir, dentro de un mismo Magento, con un mismo panel de control, podemos tener varios dominios con distintos productos, distintas plantillas, distintas configuraciones, etcétera. Es algo que nunca había visto en ningún CMS y llevarlo hasta el extremo de que cada website, store o store view puede tener muchas de sus configuraciones independientes. Lo que quiero decir es que Magento es muy flexible lo mires por donde lo mires. Poder tener todos los productos, las ventas, centralizado en un mismo panel de control es muy práctico.
De gracias recibisteis, dad de gracia.. Compartir es vivir dicen otros.. Es habitual en el mundo del desarrollo del software que se compartan los conocimientos. Los pinitos personales de cada uno en el día a día. Esas cosas que tanto nos han costado alcanzar, tras búsquedas y búsquedas leyendo a compañeros del desarrollo y al final reuniendo toda la información acabas construyendo la solución que necesitas.
No os comparto código del trabajo, ya que seguro que no es tan interesante como este ejemplo general de aquí abajo. Para que construyas el script que necesitas 😉
Creo que nunca dejaré de aprender los entresijo de Magento. Ahora estoy recorriendo los pedidos para obtener informes. Esto está probado sobre un Magento 1.9, no debería de haber muchas diferencias con otras versiones.
Ya tenemos entre nostros Ubuntu 16.04 LTS, la versión con soporte para mucho tiempo de Ubuntu más nueva hasta la fecha. Me instalé en los ordenadores de escritorio la actualización que me los pasó de la versión 14.04 LTS a la 16.04 LTS sin ningún problema.
Ahora disfruto de todas las novedades y mejoras que trae Ubuntu 16. El problema me ha llegado cuando he querido actualizar un servidor de Ubuntu 14 al 16. Resulta que en las versiones de escritorio de Ubuntu tenemos una sencilla interfaz para actualizar el sistema, mientras que en los servidores no. En las versiones de escritorio nos sale prácticamente todos los días las nuevas actualizaciones que tenemos disponibles, se pueden instalar automáticamente o seguir las instrucciones. Cuando ha salido la nueva versión de Ubuntuo 16.04 LTS nos salió junto con las actualizaciones la actualización a Ubuntu 16.04, simplemente seguimos las instrucciones y a correr.
Este estupendo CMS orientado a la venta online de productos hace las delicias de los vendedores, de igual modo de los maquetadores, y cómo no, también de los programadores.
Como analista programador llevaba ya un tiempo queriendo meterle mano a las entrañas de Magento. Así que poco a poco, he ido cogiendo los manuales para el usuario, luego el del diseñador, y ahora tengo entre manos el del programador. Ahora según van surgiendo las necesidades voy haciendo incursiones cada vez más a fondo en el código fuente de esta humongous web application.
La verdad es que lo estoy disfrutando porque Magento está desarrollado con una buena estructura y sobre un gran framework de desarrollo PHP, el Zend Framework. Incorporando técnicas de programación que le dan una gran flexibilidad sin añadir demasiada complejidad.
Este es otro pequeño how to para hacer una tarea rutinaria. Simplemente, como indica el título de la entrada, se hace lo que dice, en este caso mediante PHP. Esta tarea se puede programar en línea de comandos para ejecutarse todos los días. Es algo habitualmente necesario, y ya que PHP es un lenguaje de scripting muy sencillo y a la par potente, vamos a ver cómo hacer esto sin complejos sistemas intermedios.
Para este manual se usa Linux, y se ha probado sobre Ubuntu 14.
Traigo una pequeña receta de Chef 12 que he usado para crear un servidor virtual usando una pila de OpsWorks. He tenido que pegarle unas cuantas vueltas ya que el proyecto estaba con la versión 11, y era mi primera AMI completa creada 100% desde OpsWorks. Después de unas horas navegando, comprendiendo cómo funciona todo esto. He conseguido comprender, como dice un colega de trabajo, «uno de los pilares básicos sobre los que se basa Amazon Web Services».
La idea es tener una pila completa de OpsWorks, que cree completamente un servidor desde cero. Le vamos instalando todo lo que vayamos a necesitar, desde actualizaciones a todas las herramientas para el proyecto. En la última receta de creación de la instancia se limpia la instancia, se para, y podremos guardar nuestra propia AMI para lanzarla desde otra pila de OpsWorks, EC2, etc..
Ahí va el código en ruby para la receta de Chef que tanta guerra me ha dado. En la documentación oficial me faltaban algunos detalles que hacían que no funcionara con Chef 12 al arrancar de nuevo la instancia en otra pila de OpsWorks. Esto se puede poner en la última receta:
También se puede ejecutar esto desde línea de comandos conectando por SSH a la instancia.
Como cita la documentación oficial, si no hacemos esto, la nueva AMI quedará con las configuraciones de Chef y del agente de OpsWorks desde el que fue lanzada. Esto hará que no pueda hacer el setup si la arrancamos desde otra pila de OpsWorks creando servidores desde una «Custom AMI».
¡Buenos días a todos! Voy a tratar de no perder las buenas costumbres, como esta de compartir en el blog mi granito de arena en todo esto de la informática. Hasta estos últimos días, que no he tenido la necesidad de mantener al día tantos servidores como últimamente. Estaba haciéndolo manualmente, a pelo como se suele decir, entrando en los servidores y aplicando actualizaciones, modificaciones, etc.. Todo esto es mucho tiempo así que delegar en un proveedor de hosting todo éste trabajo es una buena elección. Pero no siempre te va a valer y puede que necesites hacer configuraciones que un proveedor de hosting no te va a permitir. Administrar tu propio servidor no tiene que ser complejo.
Todo esto me ha llevado a investigar sobre paneles de control de servidores. Tenemos el gran Cpanel, Plesk, Zpanel, y un largo etcétera. Por temas laborales ya he probado algunos en los propios proveedores. Muchos funcionan de maravilla y son sencillos de gestionar. Pero no me voy a dedicar a alquilar hosts, sino que simplemente necesito mantener unos pocos servidores y no es viable comprar una solución comercial. Así que navegando y navegando al final me topé con Webmin.
Qué tiene
A grandes rasgos es una web desarrollada sobre Perl, que se instala en el puerto 10000 del servidor y se integra con el sistema operativo. Nos permite ver el estado del servidor, hacer configuraciones de red, actualizarlo, programar actualizaciones automáticas recibiendo informes a tu email. Te permite configurar usuarios, permisos, instalar bases de datos, servidor web, configurarlos. También hay módulos para instalar un servidor de correo electrónico. Puedes administrar Apache2, Mysql, Postgres, Postfix, Dovecod, etc, etc, etc.
La verdad es que te quedas mucho más tranquilo teniendo una herramienta de estas instalada en un servidor. No tienes más que entrar y de un vistazo puedes saber qué tal anda el sistema. Puedes aplicar las principales configuraciones y a correr que el tiempo es muy valioso.
Hay algunas tareas como la configuración hosts virtuales que haciéndolas a mano me he aclarado mejor. Pero deduzco que será cuestión de acostumbrarme al panel. Leo que hay extensiones de Webmin para configurar fácilmente hosts con varios dominios, permitiendo la lectura de correos a los usuarios proporcionándoles un panel de entrada al sistema.
Un detalle que me ha gustado mucho es la autenticación en dos pasos (multi-factor authentication, MFA). Con el que podemos tener por ejemplo en nuestro móvil el Google Authenticator, y tener un código de seguridad extra que se genere a cada 30 segundos, para poder entrar como en la imagen siguiente:
El theme, piel, o plantilla que podéis ver en las imágenes no es el original. Es el ‘Authentic theme’ que me ha gustado también mucho. Es totalmente sensible al dispositivo (responsive), con lo que también podemos aplicar configuraciones sobre nuestro servidor desde el móvil o tablet, cosa que se agradece en gran manera.
Aquí podemos ver lo sencillo que se hace mantener actualizado el sistema:
Aquí en la imagen se puede ver cómo configurar que todos los días se apliquen todas las actualizaciones del sistema, no sólo las de seguridad. Esto dispara cada día la instalación de todos los paquetes para actualizar y me envía un informe del resultado de la instalación a mi email. Ya os podéis hacer a la idea de que tiene muchas cosas, y lo tranquilo que me quedo con cada correo que recibo diciéndome que todo se ha actualizado correctamente.
Como buen usuario de Ubuntu, todas las pruebas y las imágenes que se ven son sobre Ubuntu. Me lo voy a anotar como indispensable en las nuevas instalaciones. Navegando y navegando por el menú lateral ya veo que no me lo voy a acabar, así que tendré que ver la documentación oficial de cada herramienta para ir más al grano en las tareas que se necesiten.
Es un proyecto alojado en Github, que por lo que veo se ve bien activo. Ahora mismo hace 4 horas que han subido una actualización, lo que denota que vamos a seguir teniendo actualizaciones frecuentemente, como todo buen proyecto Open Source.
Para el que quiera seguir investigando en esta joya de la informática, son interesantes los módulos Usermin y Virtualmin. No creo que tarde mucho en probarlos. De estos tenemos una versión gratuita y otra comercial, con las que vamos añadiendo más y más funcionalidades al panel de control.
¿Alguna sugerencia de otro programa similar para administrar servidores?
De todos las soluciones de tienda online que he conocido hasta la fecha, Magento es de lo más robusto y potente que he visto de código abierto. Estoy conociendo poco a poco los entresijos de Magento 1 en el trabajo, y es buen momento de ver las mejoras que trae Magento 2 y así cotejar.
Es un sistema de información dedicado a la venta robusto, flexible y muy personalizable. Alrededor de Magento se mueve todo un ecosistema de soluciones empresariales de la más alta gama. Todo esto es posible gracias a las características de Magento.
Para explicar todo lo que tiene Magento necesitamos mucho tiempo, terminaríamos antes buscando qué no tiene. Pero también encontrar qué no tiene va a ser difícil porque Magento es todo un referente mundial de las soluciones eCommerce existentes.
Un poco de historia
Nació como proyecto de código abierto en el 2007. Ya en el 2008 fue premiado como mejor nuevo proyecto de código abierto del año. En el año 2009 la empresa Varien lanzó la versión Enterprise con el modelo de negocio de suscripción anual. Ahora mismo es propiedad de Ebay, la cual es propietaria del 100% de la empresa.
Lanzaron también una versión Profesional, pero no debe de haber tenido mucho éxito esta segmentación porque ahora mismo sólo disponemos de la Community Edition y la Enterprise Edition.
Requisitos para la instalación
Se necesita de una buena máquina para correr Magento, por lo menos se recomiendan 2 Gigas de RAM y échale CPUs que cuantos
más mejor. Yo le he puesto una máquina virtual con Vagrant de 4 Gigas de RAM y 2 CPUs. Se ha dejado instalar después de preparar un poco el servidor sin demasiadas configuraciones.
Instalando
Haciendo unas pruebas jugueteando con Vagrant, me ha quedado un script bien sencillo. Ejecutando lo siguiente tenemos automatizada la instalación de todo lo necesario en un servidor Linux para poder instalar Magento 2. Dejo aquí el script para Ubuntu Server con todo en el mismo servidor, Apache y MySQL:
sudo sed -i «s/bind-address\s*=\s*127.0.0.1/bind-address = 0.0.0.0/» ${mysql_config_file}
# Permitir acceso como root desde cualquier host echo «GRANT ALL PRIVILEGES ON *.* TO ‘root’@’%’ IDENTIFIED BY ‘root’ WITH GRANT OPTION» | mysql -u root –password=root echo «GRANT PROXY ON »@» TO ‘root’@’%’ WITH GRANT OPTION» | mysql -u root –password=root
sudo service mysql restart
echo «CREATE DATABASE magento2» | mysql -u root –password=root
Hay quien preferiría Nginx porque en sus inicios ejecutaba en multiples hilos de ejecución las peticiones HTTP, es ligero y sencillo. Ha llovido mucho desde que Nginx era el servidor más rápido del mercado con creces, viendo las últimas estadísticas comparativas entre Apache2 y Nginx más o menos van a la par en la fecha en que les escribo. No es objetivo hacer una comparativa Nginx-Apache en esta entrada así que lo dejaremos para otro momento si cabe.
A partir de aquí ya tenemos el servidor web Apache configurado con PHP, y una base de datos MySQL con la base de datos magento2 ya creada que usaremos para instalar nuestro nuevo Magento. También tenemos instalado globalmente en el sistema Composer, que cuando recién descomprimamos el nuevo magento y vayamos a instalar nos va a pedir que instalemos todas las librerías de PHP.
Tras esto podemos ver conectándonos a la base de datos que partimos de las no pocas 308 tablas, para empezar. Esto nos da una idea de la magnitud del programa que tenemos entre manos ¿cierto?
Las tareas cron, cachés..
El cron del sistema es el programador de tareas. Cuando recién hemos hecho la instalación, el panel de control nos notificará que instalemos las tareas automáticas para que funcione Magento o que las lancemos manualmente.
Esto hace necesario que tengamos acceso como root, como administradores del sistema, para que podamos configurar estas tareas en el servidor. No podemos instalar Magento en cualquier alojamiento web. O mejor dicho, sí que podemos, pero el funcionamiento va a ser una castaña si no hacemos los ajustes necesarios.
Otro tema que hace necesario un host con acceso como root son las cachés. En un sistema web tenemos caché de base de datos, compilación a bytecodes de PHP, generación de páginas HTML a partir de vistas. Y el gran Varnish, otro elemento a instalar y configurar para sacar el máximo partido a las prestaciones de nuestro servidor, aunque no es imprescindible tenerlo (al contrario de lo que dicen muchos administradores de sistemas). Evitar Varnish si no es necesario, como escuché a un experto en Magento en el último Meet Magento en España, nos puede aliviar las configuraciones ya que a veces este proxy inverso se mete en medio necesitando de más y más configuraciones a medida que instalamos extensiones o personalizamos nuestro Magento.
El sistema de cifrado SSL
En el script de instalación se crea un certificado autofirmado y se guarda en /etc/ssl/. A fecha de hoy ya queda poco para poder crear nuestros propios certificados 100% funcionales, para el entorno de producción o desarrollo, tantos como queramos, con Letsencrypt, pero mientras este sistema nos servirá.
Es de buena costumbre poner el cifrado en la zona de administración (back-end) y en el front-end. Para ello tenemos que configurar las URL base seguras y no seguras poniéndole el https delante. Por defecto se cifrará toda la navegación desde el momento en que haya datos personales de los usuarios. En el back-end se cifrará en todo momento.
Si vas a instalarlo en producción asegúrate de que esté todo funcionando antes de activar SSL en todo el sitio. Tener SSL mejorará el posicionamiento del sitio en los buscadores, pero me ha pasado que una extensión te fastidie todo porque no funcione correctamente, así que más vale probar y probar antes de dejarlo activado definitivamente. Aquí dejo la información para el que le sirva 😉
Características principales
Las bondades de Magento son una larga lista de características así que de entre las principales tenemos:
Multi-sitio web (varios dominios), multi-almacén y multi-vista de almacén, todo con un mismo panel de administración.
Multi-idioma, con packs de idiomas disponibles para instalar como extensiones.
Gestión total del catálogo; categorías y productos.
Gestión muy potente de atributos de productos.
Filtrado de productos para mejorar la navegación basado en atributos y características muy avanzado.
Integración con pasarelas de pago para poder instalar como extensiones.
Registro detallado que nos informa del estado actual con todo lujo de detalles: últimas ventas, ingresos, productos más vendidos..
Gestión de datos de clientes, registro, modificación.
Gestión de los usuarios que acceden al panel de administración.
Herramientas de marketing como emails transaccionales configurables, reglas de precios de catálogo o de carrito, herramientas SEO integradas.
Gestión de promociones basadas en características de productos o de carritos de la compra. Se pueden utilizar atributos personalizados para las reglas de promociones.
Temas para instalar; sistemas de páginas estáticas, bloques y widgets para personalizar.
También tenemos inteligencia de negocio con muchos informes detallados listos para ver en tiempo real.
Un sistema de gestión de índices y caché.
Muchas extensiones para personalizar nuestro Magento en su marketplace.
Por supuesto, acceso para interconectar con otros sistemas mediante punto de entrada a una API.
Magento es enorme, parece el SAP de las soluciones eCommerce Open Source. Soy sincero, no conozco SAP en sus entrañas, pero ya sólo ver que tenemos 300 tablas para guardar los datos necesarios para funcionar me hice una idea. Entrar a detallar las características de cada zona de su panel de administración es una tarea interminable así que será mejor ir directamente a su funcionamiento, empaparse de su documentación, o ir buscando lo que necesites. Recomiendo dar una lectura rápida a las guías de usuario disponibles en su página oficial.
Terminando
Lo que destaca de esta solución eCommerce es su robustez y fiabilidad. Estoy viendo muchas mejoras en la versión 2 con respecto a la 1: aumento de velocidad, sistema totalmente cacheado, compatible con HHVM.. Destaca la integración de la herramienta de consola de Symfony. Tenemos disponible la integración con Odoo mediante la instalación de una extensión en Magento, se abre el acceso al Webservice, e instalando los módulos correspondientes en Odoo podremos sincronizar catálogo, stocks, clientes, pedidos, carros abandonados, etc.. esto último está disponible hasta para la versión 1.9, espero que pronto esté también para Magento 2 😉
Al instalar los códigos me sorprendió que me pidiera ejecutar un ‘composer install’ para comenzar a correr la aplicación. Composer es una herramienta que organiza las librerías PHP, algo que venía haciendo falta. Es una herramienta PHP muy nueva, que están usando frameworks de desarrollo de la talla de Symfony o Laravel. Esto me hace preveer que el código fuente de Magento 2 puede incorporar pronto muchas nuevas mejoras del mundo PHP. Estaremos atentos.
Si has estado probando soluciones como Virtuemart, WooCommerce o Prestashop. Esta solución de código libre es más que interesante. Habrá que valorar qué es lo que necesitas para tu caso, pero lo que si puedo asegurar es que Magento es una gran solución.
El único inconveniente que le veo es que, por lo menos aquí en Spain donde resido, hay muy pocos desarrolladores especializados en Magento. Así que toma el dato, si quieres asegurarte el trabajo, aprende a desarrollar para Magento y no te faltará el trabajo.
¡Hola! Este es un pequeño HOWTO para configurar los permisos de directorio de un proyecto web que está en un servidor Apache. Nos puede pasar que estamos editando los ficheros del proyecto, pero puede ser que Apache no pueda acceder correctamente a los nuevos ficheros, crearlos, modificarlos o borrarlos. También nos puede pasar que Apache cree ficheros y nosotros no podamos tocarlos. Vamos a evitarlo con unos sencillos pasos. Esto sirve para configurarlo en Ubuntu. También se puede aplicar a cualquier otro sistema operativo Linux.
El usuario por defecto de un servidor Ubuntu es ‘ubuntu’. El usuario de Apache es ‘www-data’, así que comenzamos dando permiso a Apache para que pueda usar nuestro directorio de trabajo donde desarrollamos la web. Por defecto Apache trabaja sobre con la página principal en /var/www/html pero este post es para configurar a nuestro gusto el destino el directorio donde vamos a tener la web.
Supongamos que tenemos nuestra web en desarrollo en:
/home/jaime/miweb/
Ahora bien vamos al directorio donde está nuestra web y damos permisos a Apache así:
cd /home/jaime/ sudo chown www-data:www-data -R miweb/
Doy por sentado que ya tenemos instalado Apache y que tenemos configurado el host. Ahora bien, queremos trabajar como usuario editando y viendo los resultados en el navegador. Añadimos a nuestro usuario al grupo www-data:
sudo adduser jaime www-data
Con esto ya podremos editar el contenido del directorio de la web en /home/jaime/miweb/. Antes no podíamos porque hemos dado la propiedad a www-data que es el usuario de Apache con el comando chown.
Ahora para que los nuevos archivos creados dentro del directorio de la web sigan siendo propiedad del mismo grupo www-data para que tanto Apache como el usuario (tú) podáis seguir trabajando ejecutamos lo siguiente para poner el ‘sticky-bit’ de grupo a los directorios:
Esto pone el directorio del proyecto con el sticky-bit de grupo y luego busca dentro todos los subdirectorios y también le ponemos el sticky-bit de grupo. Ahora cualquier archivo que crees dentro del directorio seguirá tendrá tu usuario de propietario, y de grupo www-data. Así Apache podrá seguir sirviendo los archivos sin problemas y podremos trabajar sin preocuparnos de dar permiso o propiedad a los archivos que ya no sean de www-data.
En mi caso, en el Centro de Software de Ubuntu, simplemente con buscar cortafuegos me sale como disponible. Se llama ‘Configuración del cortafuegos’ y es una interfaz gráfica para que podamos manejar las configuraciones de iptables con las que configuramos las reglas de nuestro cortafuegos.
Si no lo pudiéramos instalar así desde un terminal lo podemos instalar escribiendo:
$ sudo apt-get install gufw
Una vez arrancado veremos una ventana como la de la imagen. Con sólo elegir un perfil y activarlo ya tendremos una protección extra ante posibles servicios de nuestro sistema que estén abiertos. Estos servicios que estén escuchando la red pueden ser vulnerables y siempre va a ser mejor configurar su acceso.
Fundamentos
Es interesante saber que gufw simplemente es una interfaz gráfica que nos ayudará a establecer unas reglas o configuraciones sobre nuestro acceso a la red. Gufw trabaja sobre iptables, que es una capa de sofware que establece directamente las reglas o configuraciones que vemos en la interfaz. A su vez, iptables trabaja sobre netfilter.
Netfilter es un framework que ofrece el núcleo de Linux para trabajar sobre la red. Permite filtrar, modificar, redireccionar, bloquear, registrar, etc.. paquetes de red a nivel de núcleo. Es decir, el núcleo de Linux proporciona unas herramientas para hacer todo tipo de tareas relacionadas con los cortafuegos de red.
Todas estas configuraciones que podemos hacer sobre iptables, gufw nos las sirve bien fácil para configurar. Y no sólo eso, sino que también nos proporciona una serie de plantillas para configurar los programas más habituales.
A parte de esto, también hay otras soluciones que no son iptables para configurar los cortafuegos de núcleos Linux. Y también trabajan sobre netfilter.
Probando
Para verificar que de verdad está funcionando podemos hacer una sencilla prueba. Vamos a la sección de reglas y podemos crear una regla que nos impida conectar con nuestro router. Habitualmente el router está en 192.168.0.1, depende del fabricante. En mi caso, creo una regla que bloquee la conexión saliente hacia el router al puerto 80 y no me deja conectarme a:
http://192.168.0.1/
Se me queda el navegador pensando y no sale nunca la página del router. Ya está comprobado de que funciona, borro la regla y vuelvo a la normalidad.
Si en una regla le activas que guarde registro luego puedes ir al directorio /var/log en donde tendrás los logs. Como se trata de una regla que se ejecuta al nivel de kernel se guarda en el fichero /var/log/kern.log. Esto también se puede configurar. Para ello hay que entrar a configurar ficheros de registro para iptables.
Es muy sencillo de configurar, a nada que vayamos probando haciendo click en todos los botones seguro que llegaremos a la configuración que queremos. Ya sea para casa, trabajo, o redes públicas. Como ya decía en el post sobre el antivirus ClamAV y la interfaz ClamTK, todavía más seguro puedes estar en Linux si activas el cortafuegos 😉
