Bastille is a container management system for FreeBSD, similar to Docker or Podman on Linux. The historical name of containers on FreeBSD is jail, and they appeared a lot earlier than containers on Linux. Managing jails was not always easy. When I started to use this technology in production in 2001, nothing was automated. Using Bastille, you can easily create, configure, or update jails at scale. It has a template system to install applications in containers and there is a template also for syslog-ng.

From this blog, you can learn how to get started with Bastille and how to create and run a syslog-ng jail using the freshly released 0.8 version of Bastille.

Before you begin

First of all, to use Bastille, you need FreeBSD installed. I used FreeBSD 12.2 on AMD64, but it also works on CURRENT and on any platform supported by FreeBSD, including the Raspberry Pi. Bastille 0.8, the release I’m describing in my blog, was released after the latest quarterly package release. It means, that by the time of writing this blog article, you can install it only using an up-to-date ports snapshot or following the latest PKG builds, instead of the quarterly PKG release.

Installing Bastille

The easiest way to install Bastille is to use the pkg command:

pkg install bastille

And depending on your Internet connection, it will be installed within a few seconds. You can also install it from ports:

cd /usr/ports/sysutils/bastille/
make install clean

There are no extra dependencies when you install Bastille. There is one exception, even if it is not hardcoded into the Makefile in ports: you need to install Git to be able to use the template system.

pkg install git

Configuring Bastille

Bastille supports many different FreeBSD features, like ZFS or VNET. However, these need extra planning, stronger hardware, and more control over the network. So, in this blog, I go with the easiest configuration possible, which works anywhere: on your local network or somewhere in a public cloud as well. For more choices and advanced functionality, check the Bastille documentation at https://bastille.readthedocs.io/en/latest/

The commands below enable Bastille, create and start an internal network interface for jails and also enable the PF firewall. Run each of these commands from a terminal.

sysrc bastille_enable="YES"
sysrc cloned_interfaces+=lo1
sysrc ifconfig_lo1_name="bastille0"
service netif cloneup
sysrc pf_enable="YES"

The next step is to set up the PF firewall. The configuration below should go into /etc/pf.conf and you should replace “em0” on the first line with your actual network interface name. This configuration makes sure that jails can reach the Internet through NAT and Bastille can create rules to access services in jails without editing the firewall configuration manually.

ext_if="em0"

set block-policy return
scrub in on $ext_if all fragment reassemble
set skip on lo

table <jails> persist
nat on $ext_if from <jails> to any -> ($ext_if)

rdr-anchor "rdr/*"

block in all
pass out quick modulate state
antispoof for $ext_if inet
pass in inet proto tcp from any to any port ssh flags S/SA modulate state

You can now restart the pf service for these rules to take effect. Note, that if you work over an SSH connection, you might be kicked off from the system when you hit Enter. In this case, reconnect and continue your work:

service pf restart

Finally, bootstrap the release of your choice (not more recent than what the host is running):

bastille bootstrap 12.2-RELEASE

It downloads and extracts the given release. You are now ready to create your first jail!

Creating your first jail

The first step is to create a jail. “bastille create” expects a few parameters from you. One is a name for the jail. In the example below, we use “alcatraz”, but in real life, you will most likely use names that remind you of the function of the jail, for example: centralsyslog. You also need a FreeBSD release name and finally an IP address. Use a different IP address if your host is on a 10.0.0.0/8 network.

bastille create alcatraz 12.2-RELEASE 10.17.89.50

Unlike previous releases, version 0.8 of Bastille starts the freshly created jail automatically. I prefer this way, but not everyone is happy with this change, so it might change in future releases.

Now, bootstrap the syslog-ng template. It uses Git to download the template from a repository on GitLab.

bastille bootstrap https://gitlab.com/BastilleBSD-Templates/syslog-ng

Apply the template to the jail. As you can see, we refer to the jail by its name, so choose jail names wisely!

bastille template alcatraz BastilleBSD-Templates/syslog-ng

Finally configure the PF firewall with a bastille command, and redirect the external 514 port to the 514 port of the freshly created jail on the internal network:

bastille rdr alcatraz tcp 514 514

And your second jail

The commands below create a second jail with a slightly different name and IP address. You do not have to bootstrap the syslog-ng template again, just apply it to the jail. And as port 514 on the host is already redirected to the first jail, here we redirect the external 515 port to the 514 port of the jail.

bastille create alcatray 12.2-RELEASE 10.17.89.51
bastille template alcatray BastilleBSD-Templates/syslog-ng
bastille rdr alcatray tcp 515 514

Testing

You can check the logs from both jails with the following command:

tail -f /usr/local/bastille/jails/alcatraz/root/var/log/messages /usr/local/bastille/jails/alcatray/root/var/log/messages

You should see two sets of log messages from the two jails. The -f option means that you do not get back the command prompt, but tail follows the files.

Now open another terminal and from another system use telnet to connect to port 514 and 515 of your FreeBSD host. In both cases, enter some test messages.

czanik@czplaptop:~> telnet 172.16.167.138 515
Trying 172.16.167.138...
Connected to 172.16.167.138.
Escape character is '^]'.
this is a test
^]
telnet> quit
Connection closed.
czanik@czplaptop:~> telnet 172.16.167.138 514
Trying 172.16.167.138...
Connected to 172.16.167.138.
Escape character is '^]'.
this is another test
^]  
telnet> quit
Connection closed.

On the other terminal, you should see log messages about the connection and the test messages as well:

Jan 22 10:03:13 alcatraz syslog-ng[1120]: syslog-ng starting up; version='3.30.1'
Jan 22 11:52:52 alcatraz syslog-ng[1120]: Syslog connection accepted; fd='23', client='AF_INET(172.16.167.1:50212)', local='AF_INET(0.0.0.0:514)'
Jan 22 11:52:56 172.16.167.1 this is another test
Jan 22 11:53:01 alcatraz syslog-ng[1120]: Syslog connection closed; fd='23', client='AF_INET(172.16.167.1:50212)', local='AF_INET(0.0.0.0:514)'

If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @Pczanik.

Just in case, if you’ve ever wondered how to stop cron from sending empty emails, a quick look at man mail will give you the answer you’re looking for (if you know what you’re searching for):

    -E

    If an outgoing message does not contain any text in its first or only message part, do not send it but discard it silently,
    effectively setting the skipemptybody variable at program startup. This is useful for sending messages from scripts started 
    by cron(8).

I got this after visiting couple of forums, and some threads at stack exchange, however this one nailed it

So all you need to do is, fire up that crontab -e and make your script run every five minutes, without fear of the noise

*/5 * * * * /usr/local/bin/only-talk-if-there-are-errors-script |& mail -E -r $(hostname)@opensuse.org -s "[CRON][monitoring] foo bar $(date  --iso-8601='minutes')"  do-not-spam-me@example.com

Et voilà, ma chérie!

A few tweets ago, openSUSE Mauritius mentioned using YaST to configure the timezone on a machine with just a few clicks.

YaST is a system setup & configuration tool. It was developed by SuSE in the mid-90s. YaST is an acronym for Yet another Setup Tool. It is a handy tool for administrators to install software, configure hardware, connect to a network, etc.

It is written in Ruby. It has both a GUI and is available as a command-line utility through a text-based user interface using ncurses.

To run the ncurses-based YaST version, run sudo yast2 using the terminal. Then, use the tab & arrow keys to navigate and press the enter button to select an item. Menu items and buttons can be triggered by using the Alt + Hightlighted Letter. For example, to quit the screen as in the above screenshot, one would press Alt  + Q.

Software Management

YaST can be used to install software packages. Both the GUI & yast2 command can be used to search for packages and install them. YaST uses the Zypp package management engine which is also used by the zypper command-line tool, to manage software.

YaST Modules

Additional modules can be installed to extend YaST's capabilities. For example, installaling the yast2-docker package provides a module that allows YaST to manage Docker containers. The YaST website provides a list of available modules.

Documentation

SUSE has excellent documentation on YaST. The administration section of the Leap documentation refers to using YaST for various configuration tasks.

Contributing

YaST is developed in the open. Its source code is available on GitHub. The YaST Team has made it easy for volunteers to to find their way to contribute code.

VICE (Versatile Commodore Emulator) es un emulador del popular Commodore 64 que podemos instalar en nuestro sistema GNU/Linux

Mis primeros pinitos fueron con Basic y Cobol hace ya muchos años. Pero la primera vez que recuerdo ver un ordenador fue un Commodore 64 que tenía un primo mío y con el que jugué en alguna ocasión.

La verdad es que no recuerdo gran cosa de aquel ordenador, simplemente su color marrón, un lío de cables para conectarlo a una televisión y la espera para jugar a juegos “con gráficos increíbles”.

No sé qué más se podría hacer con aquel equipo que para la época y para el jugo que se le podía sacar supongo que era bastante caro. Tiempo después compré mi 8086 con MS-Dos.

Ahora podemos recrear ese Commodore 64 y otros modelos gracias al emulador VICE (Versatile Commodore Emulator) publicado bajo una licencia libre, instalándolo en nuestro sistema GNU/Linux, concretamente en openSUSE Tumbleweed.

Para instalar Vice en nuestro openSUSE, deberemos añadir el repositorio Emulators. Para eso abrimos YaST y en el apartado Software → Repositorios de Software

Damos sobre el botón añadir, y especificamos la siguiente url, en el caso de que sea openSUSE Tumbleweed:

• https://download.opensuse.org/repositories/Emulators/openSUSE_Tumbleweed/

Si es otra versión, pincha en este enlace y obtén la url correspondiente de la versión de openSUSE que estés ejecutando:

• https://download.opensuse.org/repositories/Emulators/

Guardamos los cambios, aceptamos la clave con la que van firmados los paquetes y ya podremos instalar vice desde los repositorios.

Una vez finalizada la instalación, ya podremos abrir nuestro lanzador de aplicaciones y ejecutar cualquiera de los emuladores que se nos han instalado. Porque no solo es el Commodore 64, si no que tenemos otras opciones disponibles.

A la hora de escribir este artículo, en Tumbleweed está la versión 3.5 que es la versión más reciente publicada el pasado 24 de diciembre de 2020.

Utilizan librerías GTK, a la hora de mostrar los menús y diferentes opciones que tiene Vice. Lo he instalado hoy mismo y todavía estoy familiarizándome con la cantidad de opciones y posibilidades de configuración que ofrece este emulador de Commodore 64.

Puede ser una buena opción para volver a disfrutar de los juegos de entonces en tu equipo, o para otros proyectos que tengas en mente.

¿Tuviste un Commodore 64 y quieres volver a recordarlo? Este es el emulador perfecto con el que puedes hacerlo. Comparte en los comentarios del blog tus recuerdos de retroinformático.

Enlaces de interés

• https://vice-emu.sourceforge.io/
• https://vice-emu.sourceforge.io/vice_toc.html
• https://www.c64-wiki.com/wiki/C64-Commands

Hoy inicio una serie de artículos que nos van a ir informando de las novedades que nos esperan en la nueva versión del escritorio Plasma de la Comunidad KDE. Así que bienvenidos a «Camino a Plasma 5.21 (I): nuevo lanzador de aplicaciones» donde hablaremos de este importante cambio que se avecina: el nuevo kickoff.

Camino a Plasma 5.21 (I): nuevo lanzador de aplicaciones

El pasado 21 de enero fue lanzado la beta de Plasma 5.21, una versión no apta todavía para el usuario domésticos, y que se libera para ir solucionando errores.

En el artículo del pasado jueves ya hablé por encima de sus novedades pero hoy quiero describir más a fondo una de ellas: el nuevo lanzador de aplicaciones.

Plasma 5.21 nos ofrecerá un nuevo lanzador de aplicaciones que contará con una interfaz de usuario de doble panel, mejoras en la navegación con el teclado y el ratón, mejor accesibilidad y compatibilidad con los idiomas con escritura RTL (es decir, de izquierda a derecha como la árabe, la china, la japonesa o la coreana)

El nuevo lanzador incluye una vista alfabética de «Todas las aplicaciones», una vista de favoritos al estilo de una cuadrícula y acciones de poder visibles por defecto con sus etiquetas.

Por último, pero no por ello menos importante, hemos corregido la mayoría de los errores reportados por los usuarios, garantizando un acceso más fluido a todas tus cosas.

Por otra parte, es destacable que el antiguo lanzador de aplicaciones Kickoff sigue estando disponible en store.kde.org.

Más información: KDE.org

Pruébalo y reporta errores

Todas las tareas dentro del mundo del Software Libre son importantes: desarrollar, traducir, empaquetar, diseñar, promocionar, etc. Pero hay una que se suele pasar por alto y de la que solo nos acordamos cuando las cosas no nos funcionan como debería: buscar errores.

Desde el blog te animo a que tú seas una de las personas responsables del éxito del nuevo lanzamiento de Plasma 5.20 de la Comunidad KDE. Para ello debes participar en la tarea de buscar y reportar errores, algo básico para que los desarrolladores los solucionen para que el despegue del escritorio esté bien pulido. Debéis pensar que en muchas ocasiones los errores existen porque no le han aparecido al grupo de desarrolladores ya que no se han dado las circunstancias para que lo hagan.

Para ello debes instalarte esta beta y comunicar los errores que salgan en bugs.kde.org, tal y como expliqué en su día en esta entrada del blog.

2021 is here and it doesn’t look like it’s going to be a boring year… at least in the YaST side! The YaST team just restarted the work a couple of weeks ago and we already have some development news to share with you, including some improvements our users requested through the openSUSE’s End of the Year Community Survey.

• Writing NetworkManager configuration during system installation
• Refining the mechanism to reuse existing EFI partitions
• Using more stable and consistent names to reference devices in the bootloader
• Improving AutoYaST behavior when no product has been specified
• Updating the roles offered by yast2-vm
• Many more small improvements here and there

Let’s start with an installer improvement quite some people was waiting for. Both openSUSE and SUSE Linux Enterprise can use either wicked or NetworkManager to handle the system’s network configuration. Only the former can be fully configured with YaST (which is generally not a problem because there are plenty of tools to configure NetworkManager). Moreover, during the standard installation process, wicked is always used to setup the network of the installer itself. If the user decides to rely on wicked also in the final system, then the configuration of the installer is carried over to it. But, so far, if the user opted to use NetworkManager then the installer configuration was lost and the network of the final system had to be be configured again using NetworkManager this time. Not anymore!

That’s not the only installer behavior we have refined based on feedback from our users. In some scenarios, the logic used to decide whether an existing EFI System Partition (ESP) could be reused was getting in the way of those aiming for a fine-grained control of their partitions. That should now be fixed by the changes described in this pull request, that have been already submitted to Tumbleweed and will be part of the upcoming releases (15.3) of both openSUSE Leap and SLE.

We also fine-tuned how hibernation is configured during installation. To be precise, we improved the corresponding resume= parameter passed to the kernel by the bootloader. From now on, that parameter will use a device name that will be fully consistent with the names used in other parts of the installer and that will be often based on the swap UUID.

As usual, AutoYaST also got its quota of love during this sprint. This time on form of an usability improvement. As you may know, SUSE Linux Enterprise offers a whole set of products for different needs. When using AutoYaST to upgrade a system using a multiproduct repository, it’s necessary to specify the concrete product in the AutoYaST profile. When that was not correctly done, the system failed in a not-exactly-elegant way. In upcoming versions of products of the SLE family, that will be handled in a much nicer way.

And apart from the installation and auto-installation process, we also introduced several small fixes and improvements in other parts of YaST. Like bringing up-to-date the options offered by yast2-vm, speeding up the process of reading the network devices in s390 mainframes, improving the usability when the hostname needs to be adapted… and many other things you can check in Github or the Open Build Service if you want to know more.

As you can see, the new year has not diluted our enthusiasm to keep improving YaST bit by bit. So now it’s time to go back to work, hoping to meet you again in a couple of weeks with more news. Have a lot of fun!

The first session of the openSUSE Project’s meetup regarding the End of the Year Survey Results on Jan. 23 is already starting produce some actionable items from contributors.

View Meeting Minutes

The session on openSUSE’s Jitsi instance had engagement from about 20 people from around the globe.

Topics discussed in the two-hour session focused on addressing pain points, transferring knowledge and promoting openSUSE projects.

Members of the “let’s improve the openSUSE learning experience” shared statics and analysis from the survey and attendees engaged in generating ideas and actions to enhance and improve the above mentioned items.

Actions to take voiced during the session were enhancing the project’s websites to better direct visitors to appropriate communication mediums, documenting easier “getting started” guides and coming up with monthly or quarterly workshops.

The discussions during the meetup lead to other topics like having more surveys to extract greater information about hardware difficulties and other pain points. Discussions also talked about enhancing the wording and live images on software.opensuse.org.

Most of the ideas were captured on https://etherpad.opensuse.org/p/EOY2020Meetup.

The next sessions will start at 13:00 UTC on openSUSE’s Jitsi instance on Jan. 30.

Topics to be discussed in the Jan. 30 session include:

• Tools driving switchers to openSUSE (Where are users coming from)
• Discuss flagship project/s
• Expanding global users
• Increasing diversity
• Increase usage with people under 34

The meetup will take place at https://meet.opensuse.org/EOY2020.

More details about the End of the Year Community Survey results can be found on the openSUSE Wiki.

Tumbleweed es una distribución “Rolling Release” de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

openSUSE Tumbleweed es la versión “rolling release” o de actualización continua de la distribución de GNU/Linux openSUSE.

Hagamos un repaso a las novedades que han llegado hasta los repositorios estas semanas.

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este enlace:

• • http://dominique.leuenberger.net/blog/2021/01/opensuse-tumbleweed-review-of-the-week-2021-03/

Desde la anterior revisión semanal, 6 son las snapshots nuevas que han llegado a los repositorios de openSUSE Tumbleweed (0114, 0115, 0118, 0119, 0120 y 0121).

Los cambios más destacables que han traído esas snapshots son:

• Linux kernel 5.10.7
• GNOME 3.38.3
• Mozilla Tunderbird 78.6.1
• Mesa 20.3.3
• openSSH 8.4p1
• Tcl/Tk 8.6.11
• Bash 5.1.4
• PHP 8 was added
• Wine 6.0
• Múltiples versionde de python 3 instalables de manera paralela.

Algunos de los cambios que están siendo testados para incluirse en próximas snapshots son:

• Postfix: cambia la base de datos predeterminada de lmdb a BerkleyDB.
• icu 68.1
• Rust 1.49
• Automake 1.16.3
• Autoconf 2.70
• Migración a LUA 5.4 como interpretador principal de lua.

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• • • ¿Por qué deberías utilizar openSUSE Tumbleweed?
    • zypper dup en Tumbleweed hace todo el trabajo al actualizar
    • ¿Cual es el mejor comando para actualizar Tumbleweed?
    • Comprueba la valoración de las “snapshots” de Tumbleweed
    • ¿Qué es el test openQA?
    • http://download.opensuse.org/tumbleweed/iso/
    • https://es.opensuse.org/Portal:Tumbleweed

——————————–

Hoy me salgo un poco de los temas kdeeros y quiero presentaros PosteRazor, una aplicación online que convierte una imagen en un mosaico de varias hojas. Y es que la he descubierto esta semana y es de esas aplicaciones que creo que interesa tener a mano.

Convierte una imagen en un mosaico de varias hojas con PosteRazor

Me encanta pensar que todo aquello que puede hacerse en informática de forma manual pero que puede resultar muy pesado tiene asociada una aplicación que lo simplifica.

Por simple cuestión de usuarios y empresas, este tipo de aplicaciones específicas tienen segura su versión en Windows, pero poco a poco el mundo de GNU/Linux no se queda atrás.

Y no solo eso, ya que el auge de las aplicaciones online en algunas ocasiones se puede realizar de esta forma y evitarnos el problema de la instalación del Software.

Justo eso me pasó el pasado jueves: para el día de la Paz en el colegio, que se celebra el 30 de enero, se nos ocurrió imprimir el famoso cuadro del «Guernika» casi a tamaño real utilizando folios A3.

En otras palabras, debíamos aprender cómo convertir una imagen en un mosaico de varias hojas, en nuestro caso en folios de tamaño A3.

Tras realizar una búsqueda por la red encontré algunas alternativas windoseras pero al final llegué a la mejor solución ya que se trata de una aplicación online basada en Qt: PosteRazor.

Leyendo la definición que hacen sus creadores,

«El PosteRazor corta una imagen en trozos que pueden imprimirse en una impresora y unirse para formar un póster.
Como imagen de entrada, se admiten archivos rasterizados de varios formatos de archivo de imagen. En lugar de imprimir directamente el póster, PosteRazor produce un archivo PDF de varias páginas que contiene las piezas del póster.
Es un programa de código abierto que depende de otros proyectos de código abierto. El PosteRazor está alojado en posterazor.sourceforge.net.«

De esta forma, simplemente debes seguir las instrucciones que te muestra la minimalista página web de Posterazor y que se pueden resumir en: subir imagen, decidir en cuantas partes quieres dividir la imagen y crear un pdf.