Friday

22 May, 2020

GitLab Issues, controla tus proyectos GitLab en Plasma – Plasmoides de KDE (144)

Hoy me toca una entrada muy fácil de hacer ya que hice una muy similar con GitHub Issues hace muy poco. Os presento GitLab Issues, el plasmoide 144 de la serie que nos permite controlar tus proyectos GitLab en Plasma , el escritorio de la Comunidad KDE.

GitLab Issues, controla tus proyectos GitLab en Plasma – Plasmoides de KDE (144)

De la mano de Zren, uno de los creadores más activos de plasmoides, nos llega GitLab Issues, un widget que nos permite tener información de los proyectos alojados en GitLab con las siguientes características (que son básicamente las misma que GitHub Issues):

  • Mostrar la primera página de las entradas de un repo de GitLab.
  • Mostrar Abierto, Cerrado o Todos las entradas + Solicitudes de subida.
  • Poder ordenar por Creado, Actualizado, y # Comentarios.
  • Enumerar el número de comentarios como página web.
  • Utilizar los mismos octiconos que la página web.
  • Ocultar el fondo cuando se usa como un widget de escritorio.
  • Ocultar el encabezado.
  • Cambiar el icono del panel.
  • La lista se almacena localmente, por lo que reiniciar el Plasmashell constantemente (por ejemplo: los desarrolladores de plasma) no es un problema.

Y como siempre digo, si os gusta el plasmoide podéis “pagarlo” de muchas formas en la fluida página de KDE Store, que estoy seguro que el desarrollador lo agradecerá: puntúale positivamente, hazle un comentario en la página o realiza una donación. Ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

 

Más información: KDE Store

¿Qué son los plasmoides?

Para los no iniciados en el blog, quizás la palabra plasmoide le suene un poco rara pero no es mas que el nombre que reciben los widgets para el escritorio Plasma de KDE.

En otras palabras, los plasmoides no son más que pequeñas aplicaciones que puestas sobre el escritorio o sobre una de las barras de tareas del mismo aumentan las funcionalidades del mismo o simplemente lo decoran.

Welcome PDF Quirk

How often have you scanned a letter, a certificate or whatever and looked for the right way to call $UTILITY to convert it to a PDF that can be shared via internet?

For this very common use case I could not find a tool to make that really easy for the Linux desktop. Given my mission to help making the Linux desktop more common in the small business world (do you know Kraft?) I spent some time starting this little project.

Please welcome PDF Quirk, the desktop app to easily create PDFs out of images from storage or directly from the scanner!

It is just what this screenshot shows: A one page app to pick images from either the harddisk or from a scanner if configured, and save it right away to a multi page PDF file. The only option is to have either monochrome or color scan. No further scan chi-chi, just nice PDFs within seconds.

Of course I did not want to spend too much time and reinvent the wheel. PDF Quirk uses ImageMagicks convert utility and the command line scan client scanimage of the SANE Project in the background. Both are welknown standard commands on Linux, and serve well for this purpose.

Maybe you find PDF Quirk useful and wanna try it. You find it on Github, or packages on the openSUSE Buildservice.

Contributions and comments are very welcome. It is a fun little project!

Voro, presidente de GNU/Linux València en Podcast Linux #104

Sigo con el repaso de los programas de los podcast de Juan Febles. En esta ocasión por he decidido dar un pequeño salto y situarme en el 104 ya que está dedicado a Voro, actual presidente de la Asociación GNU/Linux València, y un promotor del Software Libre a través de su canal de Youtube, la organización de eventos y realización de podcast.

Voro, presidente de GNU/Linux València en Podcast Linux #104

Voro, presidente de GNU/Linux València en Podcast Linux #104Tengo el placer de conocer personalmente a Voro y una cosa destaca de él: rezuma buen rollo y optimismo por lo cuatro costados. Y es que a los cinco minutos de conocerlo parece que lo conoces de toda la vida.

Entre esa característica y una voz grave, pausada y segura, el episodio 104 de Podcast Linux realizado codo a codo con Juan Febles es una delicia. Se trata de un episodio especialmente recomendado para aquellos que piensan que solo los programadores pueden desarrollar el Software Libre.

De esta forma, a lo largo de una hora, que pasa volando, Voro y Juan hablan de cómo introducir el Software Libre al público en general, de las aficiones de Voro, del trabajo de la Asociación GNU/Linux València (inicio, evolución , iniciativas como eventos y su servidor Jitsi abierto,y el actual estado de admisión de socios ¡a qué estáis esperando!), el auge del SL en la capital del Turia(gracias a Slimbook, Vant, Valencia Tech y Las Naves, entre otros) y muchos otros temas tangentes más.

Como siempre, os dejo los audios para que los podáis escuchar:

No quiero terminar el artículo son compartir los enlaces de interés de Voro:
Web: https://www.voromv.com
Twitter: https://twitter.com/VOROMV
Youtube: https://www.youtube.com/voromv
GNU/Linux Valencia: https://gnulinuxvalencia.org

Aprovecho para animaros a seguir Podcast Linux en algunos de los canales de comunicación que tiene:

Podcast Linux forma parte de la red de podcasting Avpodcast y esta alojado en Neodigit.net, un proveedor de confianza con instalaciones en España.

Thursday

21 May, 2020

Memasang Collabora Office (Snapshot) pada openSUSE Tumbleweed

Apa itu Collabora Office? Collabora Office adalah enterprise office suite dari LibreOffice, office suite Open Source yang paling banyak digunakan di dunia.

Apakah Anda pernah mencoba Collabora Office? Mari kita coba snapshot terbaru. Anda juga dapat mencobanya di openSUSE Leap.

  • Unduh dan impor kunci
    wget https://www.collaboraoffice.com/Collabora-Office-6.2-Snapshot/Linux/yum/repodata/repomd.xml.key && sudo rpm --import repomd.xml.key
    
  • Tanbah repositori
    sudo zypper addrepo 'https://www.collaboraoffice.com/Collabora-Office-6.2-Snapshot/Linux/yum' 'Collabora Office 6.2 Snapshot'
    
  • Segarkan
    sudo zypper ref
    
  • Pasang
    sudo zypper install collaboraoffice
    

Enjoy!

SUSE y Elecktrobit aliados para modelar el futuro de los coches autónomos y conectados

SUSE se asocia con la empresa Elektrobit para transformar el futuro de los coches inteligentes autónomos y conectados con sistemas operativos basados en Linux

La movilidad tal como la conocemos parece ser que está a punto de cambiar para siempre. Ya no suena futurista leer noticias relacionadas con vehículos autónomos, conectados y eléctricos.

Los vehículos (no sé si para bien o para mal) ya no son solo unos chásis propulsados por un motor. El futuro (si alguien puede predecirlo) parece ser el replantearse ese patrón que hasta ahora conocíamos.

Por eso SUSE se ha asociado con la empresa Elektrobit para juntos ofrecer una alternativa potente y segura para ese nuevo futuro de la innovación automovilística con sistemas operativos basados en Linux.

Combinando la experiencia de Elektrobit dentro de la automoción y la experiencia de SUSE en el campo de Linux, juntos tratarán de ofrecer una plataforma de software para automóviles que satisfaga los requerimientos clave que necesitan.

Aspectos clave como la seguridad, la fiabilidad, la transparencia, la posibilidad de actualizaciones al día, sistemas fiables, son las prioridades cuando se adaptan soluciones de código abierto a las necesidades que requieren los automóviles.

Todas esas caracterísiticas son cruciales cuando se tratan de un coche, y deben ser soluciones en las que el usuario final pueda confiar.

Los vehículos definidos por software traen nuevas experiencias y retos tanto a fabricantes como a los conductores. Estos ya no necesitarán sentarse para actualizar el firmware.

Las actualizaciones ya no deberían ser algo a realizar de manera puntual en un servicio técnico, si no algo que se realice de manera transparente para el usuario final que debería disfrutar de sistemas abiertos, actualizados y parcheados.

Los coches autónomos significan coches conducidos y gestionados por software, y Linux debería ser el centro neurálgico que asegure el rendimiento y la seguridad de ese software esencial.

Pero todos sabemos que hasta el software más probado y comprobado, necesita ser actualizado y mantenido. Se necesitan corregir errores nuevos que se encuentran o solucionar problemas de seguridad que se reporten.

SUSE tiene experiencia en hacer eso con el software que desarrolla y aporta, por lo que puede poner esa experiencia en crear soluciones basadas en Linux adaptadas al automóvil y las nuevas tecnologías que están por llegar.

Este es el comienzo en el que empezar a utilizar tecnologías y software abierto para trabajar en contextos donde la seguridad es tan importante y quizás empezar a utilizarla en otros aspectos como la sanidad, la tecnología aeroespacial o más allá. En aspectos de la ciencia ya es algo usual ver equipos con Linux en el epicentro de las tareas más importantes.

Espero que este giro hacia tecnologías abiertas, tenga más respeto por la libertad y la privacidad de los usuarios al utilizar estos elementos conectados.

Más información:

Reverse Image Search – Service menu para KDE (12)

Decidido, a partir de  esta entrada voy a numerar los Service Menu que voy presentando en el blog. Así que el número 12, que seguramente no será el número exacto de los compartidos, corresponder al Reserve Image Search, un Service Menu para Plasma que nos permite buscar imágenes similares a la que tenemos en nuestro disco duro.

Reverse Image Search – Service menu para KDE (12)

La idea de los Service Menu es simple, añadir al botón derecho de Plasma en Dolphin la opción de realizar cualquier acción que se nos ocurra. Algunos de ellos pueden ser incorporados a las acciones por defecto de Dolphin.

Hoy me complace presentar Reserve Image Search, un Service Menu de Eusonig (cuyo nick oculta a una persona más que conocida en el mundo KDE España y que admiro por sus conocimientos) con el que podemos hacer la búsqueda de imágenes similares a la que tenemos en nuestro ordenador utilizando los servicios de Bing, Google, TinEye y Yandex.

Reverse Image Search - Service menu para KDE (12)

 

Hay que insistir que al programador de este Reverse Image Search le encantará que le deis me gusta en la KDE Store y que le comentéis como os funciona. Os recuerdo que ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day 2017 de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

Más información: KDE Store

¿Qué son los Dolphin Service Menu?

La personalización de KDE y Plasma está más que demostrada y prueba de ello son los Dolphin Service Menu, que no son más que la posibilidad de disponer un menú auxiliar en el gestor de archivos Dophin o en Konqueror que se activa con el botón derecho del ratón.
Con ellos tendremos nuevas acciones como:

Y muchos más como hemos explicado en varias ocasiones en el blog. Puedes encontrar estos servicios se pueden encontrar en la sección Dolphin Service Menu en la Store de KDE.

openSUSE Talks at SUSECON Digital

SUSECON Digital 2020 starts today and it is free to register and participate in SUSE’s premier annual event. This year features more than 190 sessions and hands-on training from experts.

There are less than a handful of openSUSE related talks. The first openSUSE related talk is about openSUSE Kubic and takes place on May 20 at 14:00 UTC. In the presentation, attendees will receive an update about the last year of openSUSE Kubic development and see a demonstration on deploying Kubernetes with Kubic-control on a Raspberry Pi 4 cluster. Attendees will see how to install new nodes with YOMI, which is the new Salt-based auto installer that was integrated into Kubic.

The next talk is about open-source licenses. The talk will focus on the legal review app used by SUSE lawyers and the openSUSE Community. The app called Cavil was developed as an open source application to verify the use of licenses in open source software that help lawyers to evaluate risk related to software solutions. The talk scheduled for June 3 at 13:00 UTC will explain the ease of use for the lawyers and how the model significantly increases the throughput of the ecosystem.

The last openSUSE related talks centers on openSUSE Leap and SUSE Linux Enterprise. The talk will take place on June 10 at 13:30 UTC. Attendees will learn about the relationship between openSUSE Leap and SUSE Linux Enterprise 15, how it is developed and maintained and how to migrate instances of Leap to SLE.

The event as a whole is a great opportunity for people who are familiar with open-source and openSUSE. People who just want to learn more about the technology free of cost also have a great opportunity to experience the openness of SUSE and the event.

Figuring out where a message arrived, and other syslog-ng 3.27 tricks

Version 3.27 of syslog-ng has brought many smaller, but useful features to us. The new Sumo Logic destination was already covered in an earlier blog. You can now also check exactly where a message arrived on a network source (IP address, port and protocol). Rewriting the facility of a syslog message was also made easy. For a complete list of new features and changes, check the release notes at https://github.com/syslog-ng/syslog-ng/releases/tag/syslog-ng-3.27.1

Before you begin

To test these features, you need to have syslog-ng 3.27 or later. There is a good chance that this version is not yet available as an official package for your Linux distribution. Luckily, there are third party repositories available for the most popular distros that might already carry 3.27. Check https://syslog-ng.com/3rd-party-binaries for further details. I did my tests on FreeBSD as a syslog-ng server and Linux as a client, but the examples below should work everywhere else with minimal modifications.

Where did the message arrive?

Many people stick to the KISS principle (https://en.wikipedia.org/wiki/KISS_principle) when it comes to configuring syslog-ng. In essence: have a network source combining all incoming messages from TCP and UDP connections into a single source, and process them together. While it works perfectly well in most situations, sometimes you might need to know exactly where a message arrived and process it accordingly.

Using the following source in your configuration, when log messages arrive from the same host using both TCP and UDP, they will look exactly the same:

source src { system();
             udp(); tcp(port(514)); internal();
};

Here are the commands I used to generate test messages:

logger -n 172.16.167.151 -P 514 -d --rfc3164 this is a UDP test
logger -n 172.16.167.151 -P 514 -T --rfc3164 this is a TCP test

When you check the logs, you can see that the only difference is the text I entered, but otherwise the logs would look identical:

May 19 12:32:21 172.16.167.141 root: this is a UDP test
May 19 12:32:40 172.16.167.141 root: this is a TCP test

This is where the new DESTIP/DESTPORT/PROTO macros can come in handy. These can show you where the log messages actually arrived. Here is a configuration snippet that uses the above defined source, does some minimal filtering to lessen the noise, and stores messages in a file using a template that utilizes the new macros:

destination d_bla {
    file("/var/log/bla" template("destip=$DESTIP destport=$DESTPORT proto=$PROTO message=$MSG\n"));
};
log { source(src); filter(f_notice); destination(d_bla); };

As you can see from the logs below, even if the IP address and the port are the same, the protocol is different:

destip=172.16.167.151 destport=514 proto=17 message=this is a UDP test
destip=172.16.167.151 destport=514 proto=6 message=this is a TCP test

Using the new if/else syntax of syslog-ng, you can keep the convenience of a single source and still easily treat part of the logs differently when necessary. You can find a number of examples in my blog about analyzing Suricata log messages, and also a simple example below.

Rewriting the syslog facility

If you filter based on the syslog facility associated with a log message, sometimes you might need to change the facility of a log message. It can be easily done now, using the new set-facility() rewrite function of syslog-ng 3.27. The example below does not make much sense, but at least it is easy to re-create it in your own environment and use it as a starting point. In this log, statement logs from “sudo” are set to facility “mail” and stored together with the rest of your mail logs.

log {
    source(src);
    if (program("sudo")) {
      rewrite { set-facility("mail"); };
    };
    filter { facility("mail"); };
    destination { file("/var/log/myemail"); };
};

In the configuration snippet above, we use the default local log source, called “src” in case of the default syslog-ng configuration on FreeBSD. Next, we filter on the program name “sudo”, and rewrite the facility to “mail” when there is a match. Before writing the logs to disk, we filter on the “mail” facility. Let’s take a look at the logs of an unsuccessful sudo attempt:

# tail /var/log/myemail
May 19 14:02:01 fb121 sudo[1649]:   czanik : user NOT in sudoers ; TTY=pts/0 ; PWD=/usr/home/czanik ; USER=root ; COMMAND=/bin/sh
May 19 14:02:01 fb121 sendmail[1652]: 04JC21JJ001652: from=root, size=223, class=0, nrcpts=1, msgid=<202005191202.04JC21JJ001652@fb121>, relay=root@localhost
May 19 14:02:01 fb121 sendmail[1652]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 19 14:02:01 fb121 sm-mta[1653]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 19 14:02:01 fb121 sm-mta[1653]: 04JC213F001653: from=<root@fb121>, size=474, class=0, nrcpts=1, msgid=<202005191202.04JC21JJ001652@fb121>, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
May 19 14:02:01 fb121 sendmail[1652]: 04JC21JJ001652: to=root, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30223, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (04JC213F001653 Message accepted for delivery)
May 19 14:02:01 fb121 sm-mta[1654]: 04JC213F001653: to=<root@fb121>, ctladdr=<root@fb121> (0/0), delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30762, relay=local, dsn=2.0.0, stat=Sent

As you can see, right after the unsuccessful sudo attempt, there is also an e-mail alert about the event. Log messages from sudo are now stored together with e-mail logs.

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.

Convertir un archivo en Markdown a html con el editor #Vim

Veamos cómo Vim puede “traducir” un archivo en formato Markdown a un formato html

Recientemente tuve la necesidad de tener que convertir un archivo que estaba en formato markdown a un formato html y pensé que seguro que con Vim se podría hacer de alguna manera… y la hay!!

Este artículo viene a formar parte de la serie de artículos sobre Vim que desde hace meses vengo escribiendo en mi blog. Los puedes encontrar recopilados en estos enlaces:

Seguro que ha complementos para Vim que realizan esta tarea de conversión de markdown a html, pero veamos cómo realizar esta tarea con Vim y Markdown.

Lo primero que tenemos que hacer es descargar markdown, descomprimir, dar permisos de ejecución y ubicar en alguna ruta de nuestro $PATH de nuestro sistema GNU/Linux. Yo por ejemplo lo tengo en:

/usr/local/bin/

Si quieres saber en qué ruta lo puedes meter, ejecuta:

echo $PATH

y mete el paquete en alguna carpeta en las rutas que se muestran

Ahora abrimos en Vim nuestro archivo en Markdown, y ejecutamos el siguiente comando:

:%! /usr/local/bin/markdown --html4tags

Y “automágicamente” en Vim se cambiará el formato a html. Deberemos revisar si todo el documento se ha “traducido” correctamente y después añadir cabeceras de documento html, llamadas a css y otras cosas que queramos…

Pero si esta tarea es algo que realizamos frecuentemente, lo mejor es asignarle un atajo de teclado con la tecla “leader” que ya aprendimos qué es y cómo asignarla.

Para ello añadimos en nuestro archivo .vimrc

"Markdown a HTML
nmap <leader>md :%!/usr/local/bin/markdown --html4tags <cr>

Así cuando tengamos un archivo en markdown que queramos convertir simplemente presionaremos:

<leader>+md

¡y se hará la magia! Espero que te haya resultado interesante ¿usas algún complemento para realizar esta tarea de conversión? compártela en los comentarios.

Wednesday

20 May, 2020

Cloud based workers for openQA

Cloud based workers for openQA

For those who do not know openQA, this is an automated test tool for operating systems and the engine at the heart of openSUSE’s automated testing initiative. It’s implemented mainly in Perl and uses QEMU, by default, for starting and controlling the virtual machines and OpenCV for fuzzy image matching. The general architecture is split in 2:

  • One openQA server, aka openQA web UI
  • Multiple openQA workers, which run the tests

If you want to know more about openQA, please check the documentation.

openQA workers, which run the tests, are generally on the same network as the openQA web UI server which is fine most of the time, but if some additionnal hardware must be added, they must be sent physically and only few people can take care of it, which can be problematic. One solution to this problem is to use cloud based machines, which are by definition on a separate network and accessible through Internet.

The good news is openQA supports such setups by using a local cache service on the worker. This service downloads the assets (ISO, HDD images, etc.) on demand through the openQA API via HTTPS, instead of using the legacy NFS mount method. Tests and needles are already in git repositories so they can be fetched from the remote git repositories directly instead of using them from the NFS share.

First tests have been done on local workers connected to openqa.opensuse.org (o3 for short), where NFS share has been replaced by the cache service. But this was still on the same network.

Then, more tests have been performed with additionnal aarch64 workers on:

SolidRun HoneyComb LX2K

RPi3 and SabreLite

The only caveat is the developer mode which requires the worker to be reachable from the openQA web UI server at specific ports, so here, reachable on the Internet. Unfortunately, this is not the case with current aarch64 remote workers.

For qemu based tests KVM enabled systems are highly recommended otherwise you will get very poor performances with runtimes about 10x slower compared to KVM enabled systems. So, you need to use bare metal instances or nested virtualization when available.

Now, we will detail specific configurations to setup a remote cloud worker which has access only to the openQA API.

Setup

Install required software on the worker

As any other openQA worker, you need to install some packages. You likely want to use the latest version of openQA and thus use the binaries from devel:openQA and devel:openQA:Leap:15.1 projects (adjust the URL, if you do not use Leap 15.1):

sudo zypper ar -f https://download.opensuse.org/repositories/devel:/openQA/openSUSE_Leap_15.1/devel:openQA.repo
sudo zypper ar -f https://download.opensuse.org/repositories/devel:/openQA:/Leap:/15.1/openSUSE_Leap_15.1/devel:openQA:Leap:15.1.repo

If you use SLE15-SP1, you need to enable the matching repositories and also PackageHub:

sudo zypper ar -f https://download.opensuse.org/repositories/devel:/openQA/SLE_15_SP1/devel:openQA.repo
sudo zypper ar -f https://download.opensuse.org/repositories/devel:/openQA:/SLE-15/SLE_15_SP1/devel:openQA:SLE-15.repo
sudo SUSEConnect -p PackageHub/15.1/aarch64

Now, you can install required packages:

sudo zypper install openQA-worker os-autoinst-distri-opensuse-deps

Get API keys from openQA web UI host

Create a new set of API keys from openQA web UI or ask someone with admin permissions to create a set for you.

Setup worker to use API keys and cache

With a remote worker, you cannot NFS mount /var/lib/openqa/cache from the openQA server as only the openQA API is reachable. Instead, you must use the cache service as described below.

Update /etc/openqa/workers.ini with:

[global]
HOST = http://openqa.opensuse.org http://myotheropenqa.org
CACHEDIRECTORY = /var/lib/openqa/cache
CACHELIMIT = 50 # GB, default is 50.
CACHEWORKERS = 5 # Number of parallel cache minion workers, defaults to 5

Update /etc/openqa/client.conf with the key generated from web UI:

[openqa.opensuse.org]
key = 0123456789ABCDEF
secret = FEDCBA9876543210

Start and enable the Cache Service:

sudo systemctl enable --now openqa-worker-cacheservice

Enable and start the Cache Worker:

sudo systemctl enable --now openqa-worker-cacheservice-minion

Synchronize tests and needles

Tests and needles are not part of the cache services, but are hold in GIT repositories, so you need to setup an auto-update of those repos. Currently, the easiest way is to use the fetchneedles script from openQA package to fetch Git repos and create a cron job to update it often enough (say, every minute).

Install required package and run the fetch script a first time.

sudo zypper in --no-recommends openQA system-user-wwwrun
sudo /usr/share/openqa/script/fetchneedles

Also, if you plan to run MicroOS tests:

cd /var/lib/openqa/share/tests
sudo ln -s opensuse microos
cd /var/lib/openqa/share/tests/opensuse/products/microos
sudo ln -s ../opensuse/needles/ 

Now, add a cron job to fetch tests and needles every minute /etc/cron.d/fetchneedles:

 -*/1    * * * *  geekotest     env updateall=1 /usr/share/openqa/script/fetchneedles

And restart the service:

sudo systemctl restart cron

Enjoy your remote worker

Now you can (re)start your worker(s):

sudo systemctl enable --now openqa-worker@1

And, your remote worker should be registered on the openQA server. Check the /admin/workers page from the openQA web UI. Enjoy!

Have a lot of fun!