Thu, Dec 19th, 2024
Leap 15.5 Nears End of Life
The release of Leap 15.6 on June 12 set in motion the End of Life for maintenance and security for Leap 15.5, which will happen at the end of December.
Users should upgrade to openSUSE Leap 15.6 to continue to receive security and maintenance updates. Leap versions have a six-month end-of-life period after the release of a new version.
The openSUSE Project is in the development for stage forLeap 16.0 with the pre-Alpha version people can test.
Early adopters and contributors are encouraged to explore this release and provide feedback to shape the next Leap release, which will come with the Agama installer.
Visit get.opensuse.org to try an openSUSE distribution. For users seeking extended support, SUSE offers long-term support options through its subscription services.
Novedades de Dolphin en KDE Gear 24.12
Os presento las novedades de Dolphin en KDE Gear 24.12, el tercer artículo de la serie de la última actualización del ecosistema de aplicaciones de KDE, otro paso adelante en la mejora continua del proyecto. Nunca está de más recordar que Dolphin es el mejor explorador de ficheros que puedes utilizar, tanto en entornos libres como privativos.
Novedades de Dolphin en KDE Gear 24.12
Prácticamente todos los que prueban Dolphin opinan lo mismo: no tiene rival. Sus posibilidades tanto de gestión de ficheros, opciones de vistas, funcionalidades diversas, búquedas, filtros, amplicaciones con los Service Menu, etc. lo hacen imbatible… y sigue mejorando versión a versión.
Los últimos cambios realizados en el explorador y gestor de archivos de KDE para la versión de KDE Gear 24.12tienen mucho que ver con la accesibilidad* y la usabilidad.
Para empezar, la vista principal de Dolphin se ha revisado por completo para que funcione con lectores de pantalla y se ha mejorado la navegación con el teclado: al pulsar Ctrl+L se cambia de enfocar y seleccionar la ruta de la barra de ubicación a enfocar la vista. Al pulsar Escape en la barra de ubicación se cambia ahora el foco a la vista activa.
Además, la navegación con el teclado en la barra de herramientas también se ha mejorado: los elementos obtienen ahora el foco en el orden correcto.
POr otra parte, Dolphin ordena ahora los archivos de una forma más natural y «humana» en esta versión: por ejemplo, un archivo con el nombre «a.txt» aparecerá antes que un archivo con el nombre «a 2.txt». Además, también se pueden ordenar los vídeos por su duración.
Para velar por la seguridad y facilitar la comprobación de archivos, se ha renovado la pestaña de sumas de verificación y permisos en el diálogo de Propiedades de Dolphin. También podrás ver esta mejora en otras aplicaciones de KDE.
Por último… ¡Dolphin se ha hecho móvil! Dolphin incluye ahora una interfaz optimizada para dispositivos móviles en Plasma Mobile. Tras la incorporación de un modo de selección y mejoras de compatibilidad con pantallas táctiles, Dolphin funciona sorprendentemente bien en los teléfonos. Dicho esto, todavía se necesita más trabajo y se planea hacerlo a lo largo del tiempo para alinear mejor la interfaz de usuario con las expectativas típicas de las aplicaciones móviles.
Como vemos, han sido miuchas novedades, ya que se ha trabajado mucho en la accesibilidad en esta aplicación, y esto tiene una explicación ya que muchas de las mejoras han sido posibles gracias a la financiación proporcionada por el NGI0 Entrust Fund, un fondo creado por NLnet con el apoyo financiero del programa Internet de próxima generación de la Comisión Europea.
Más información: KDE Gear 24.12
La entrada Novedades de Dolphin en KDE Gear 24.12 se publicó primero en KDE Blog.
SSSD: Weaknesses in Privilege Separation due to Issues in Privileged Helper Programs
Table of Contents
- 1) Introduction
-
2) Issues in
krb5_child
Helper -
3) Issues in
sssd_pam
Helper - 4) Notes on the
selinux_child
Helper - 5) Notes on the
ldap_child
Helper -
6) Issues in the
sssd.service
Unit - 7) Further Observations
- 8) Suggested Fixes
- 9) Situation on Other Distributions
- 10) Timeline
- 11) References
1) Introduction
SSSD (System Security Services Daemon) is a suite of daemons dealing with user authentication based on mechanisms like LDAP, Kerberos and FreeIPA. This report is based on SSSD release 2.10.0.
SSSD supports setting up user privilege separation by specifying the build
time configure switch --with-sssd-user=...
. The default in many Linux
distributions is still to run SSSD as root
, though. When privilege
separation is enabled, then file based capabilities are assigned to a couple
of helper binaries shipped by SSSD:
/usr/libexec/sssd/sssd_pam root:sssd 0750 cap_dac_read_search=p
/usr/libexec/sssd/selinux_child root:sssd 0750 cap_chown,cap_dac_override,cap_setuid,cap_setgid=ep
/usr/libexec/sssd/krb5_child root:sssd 0750 cap_chown,cap_dac_override,cap_setuid,cap_setgid=ep
/usr/libexec/sssd/ldap_child root:sssd 0750 cap_chown,cap_dac_override,cap_setuid,cap_setgid=ep
Only members of the group of the dedicated sssd
account are allowed to
execute these privileged helpers. In SSSD before version 2.10.0 these helpers
(with the exception of sssd_pam
) had setuid-root bits. With commit
7239dd6791 this has been changed to using capabilities
instead.
Our openSUSE SSSD packagers enabled privilege separation for the first time in
conjunction with the update to version 2.10.0. This caused the privileged
helpers to pop up on our radar, and we reviewed them. We found that these
helper binaries do not currently provide proper privilege separation in SSSD.
Some of them offer attack vectors to escalate to root
again, or obtain
powerful capabilities. Also the systemd service unit of SSSD has issues when
privilege separation is active. The privileged helpers are not
world-accessible, so no immediate exploitation by local users beyond the
dedicated sssd
account is possible.
We privately reported the findings described below to the Red Hat Security team on Nov 15. A coordinated disclosure process was in place for about a month, until the SSSD developers decided that the issues are not security issues, based on the following reasons:
- the issues are not directly exploitable, but only affect defense-in-depth.
- the
sssd
user and group are powerful by design, since these daemons influence the outcome of authentication. - privilege separation has been introduced as additional hardening, not as a strong security layer.
- privilege separation was also introduced for some cosmetic purposes: “to allow running SSSD in restricted environment that do not support/allow running apps under uid=0/in user-ns (like restricted OCP profiles)”.
In our opinion, these issues are still security relevant. Consider for example
a scenario where a system administrator or packager would allow execution of
the privileged binaries to all users in the system, either by accident or by a
false expectation of security. While it is common practice to deny world
access to privileged binaries, in our experience this is usually done as a
hardening measure only, not to protect against known weaknesses in programs.
While the permissions of the helpers are correctly applied in SSSD’s
installation routine, there is no documentation found that these helpers are
security sensitive and must not be accessible to accounts other than sssd
.
We did not press for CVE assignments, although we believe that formally they
would still be justified. We recognize that it can still be an improvement to
run SSSD processes as non-root, even if the privileged helpers allow
escalation back to root
.
Upstream has nonetheless worked and still works on a range of fixes to address findings from this report. The individual issues we identified are discussed in the following sections.
2) Issues in krb5_child
Helper
Like most of the other helpers, this program accepts binary input on STDIN.
The krb5_child
helper reads the large and complex data structures struct
krb5_req
and struct pam_data
.
Interesting struct fields in this context are krb5_req.ccname
and
krb5_req.keytab
, which specify file paths to process.
The ccname
field is used in the code path
privileged_krb5_setup()
→
k5c_ccache_setup()
→
k5c_precreate_ccache()
. This ends up in a
loop that creates all the parent directories of the path
specified via STDIN, using uid
and gid
values also received from STDIN.
This proof-of-concept shows how to create arbitrary new
directories with arbitrary ownership this way. This very likely allows a full
local root exploit by skillfully creating directories under attacker control,
e.g. directories used during lookup for trusted system binaries or libraries,
or directories in /etc
that are used for trusted configuration files or
privileged services.
Upstream Fix
This specific escalation path has been addressed in the SSSD 2.10.1 bugfix release. Given the extensive interface offered by this helper program it is likely that further such escalation vectors exist. Since upstream does not consider this a strong security barrier, we have not looked any deeper into this component.
3) Issues in sssd_pam
Helper
This helper starts a server instance which offers a socket-based IPC interface
for passing PAM operation requests to it. This is the only helper that has
more limited capabilities, namely only CAP_DAC_READ_SEARCH
, which allows to
override any read-access permission checks.
In the code path server_setup()
→
confdb_init()
the following environment variables are
interpreted in ldb_init()
(which is part of Samba library code):
LDB_MODULES_PATH
LDB_MODULES_ENABLE_DEEPBIND
TDB_NO_FSYNC
The LDB_MODULES_PATH
variable allows the caller to specify a directory from
which arbitrary shared objects are loaded via dlopen()
. This
simple proof-of-concept shows how to exploit this situation
to gain access to the contents of /etc/shadow
.
Contrary to the other helper programs, sssd_pam
was not assigned setuid-root
bits previously. The CAP_DAC_READ_SEARCH
has only more recently been added
via commit 0562646cc261, to allow it to access
keytabs without having to run as root
.
Upstream Fix
There is a pending upstream pull request to clear the environment of this helper to prevent this specific privilege escalation path.
4) Notes on the selinux_child
Helper
We haven’t found any specific privilege escalation paths in this helper. The nature of this helper is to allow modification of SELinux MLS mappings, though. It accepts the new MLS range for arbitrary usernames via a binary protocol on STDIN. In an SELinux MLS managed system this is a pretty strong privilege for SSSD to have. Since this is likely by design, we suppose there is little that can be done about that, except for documenting the sensitive nature of the helper and that access to it must be well restricted.
The helper performs calls into shared SSSD library code and into libsemanage and libselinux. Luckily we couldn’t find any cases where overly problematic environment variables are interpreted (beyond the common variables listed in section 7.a).
This helper also changes its UID and GID to 0 early
on. When transitioning to UID 0, the kernel does not
assign the full set of capabilities to the process again. This means that the
process runs under restricted root privileges, having UID and GID 0 but
only the capabilities assigned to the selinux_child
binary. Additionally,
the SSSD processes run with the systemd hardening feature SecureBits=noroot
noroot-locked
, thus preventing the helper from using setuid binaries like
sudo
to regain full root privileges.
The security of restricted root privileges in Linux is lacking, though. The
Linux kernel uses capabilities for its permission checks, but userspace
utilities normally only rely on other process’s UID and GID credentials. Also
some APIs lack the possibility to express restricted root privileges,
e.g. in UNIX domain sockets the SO_PEERCRED
option is used to determine the
credentials of a peer process, which only provides a struct ucred
,
containing the peer process’s PID, UID and GID. Thus this helper runs with
privileges close to full root
.
5) Notes on the ldap_child
Helper
We couldn’t find any bigger problems in this helper, beyond the generic comments in section 7) that also apply to this helper.
6) Issues in the sssd.service
Unit
The sssd.service
systemd unit contains the following ExecStartPre
lines:
ExecStartPre=+-/bin/chown -f -R root:@SSSD_USER@ @sssdconfdir@
ExecStartPre=+-/bin/chmod -f -R g+r @sssdconfdir@
ExecStartPre=+-/bin/sh -c "/bin/chown -f @SSSD_USER@:@SSSD_USER@ @dbpath@/*.ldb"
ExecStartPre=+-/bin/chown -f -R @SSSD_USER@:@SSSD_USER@ @gpocachepath@
ExecStartPre=+-/bin/sh -c "/bin/chown -f @SSSD_USER@:@SSSD_USER@ @logpath@/*.log"
The directories /var/log/sssd
and /var/lib/sssd
are owned by the
unprivileged sssd
user. The chown
and chmod
lines above, which are run
as root
, allow a compromised sssd
user to stage symlink attacks and thus
gain ownership of, or access to, privileged system files.
This is a simple proof-of-concept demonstrating the issue:
# stage a symlink attack to gain ownership of /etc/shadow
sssd$ cd /var/log/sssd
sssd$ ln -s /etc/shadow my.log
# as root trigger a sssd (re)start
# sssd needs to be configured (i.e. /etc/sssd & friends need to exist) for this to work
root# systemctl restart sssd.service
root# ls -lh /etc/shadow
-rw------- 1 sssd sssd 889 Nov 13 11:40 /etc/shadow
As the directories that are affected by this are not world-writable and don’t
carry a sticky bit, the Linux kernel’s symlink protection does not come to the
rescue here. Path arguments that are named directly on the command line of
chown
or chmod
will be followed, if they’re symlinks, unless
--no-dereference
is passed. Passing this option is also the recommended fix
for this.
In our opinion such automatic permission “fixes” should be treated with care.
If this is to avoid any trouble with migration from older installations
(without privilege separation) then we would rather offer an explicit utility
for system administrators to run. This would make clear that the logic only
runs once and not every time sssd
is started. It also would prevent any
configuration errors from persisting or from being masked (e.g. other
components in the system that assign bad permissions to SSSD files, thus
fighting against the automatic permission fixes).
Upstream Fix
There is a pending upstream pull request to pass
--no-dreference
to the chown
invocations found in the systemd service unit.
7) Further Observations
7.a) Environment Variables
There are further environment variables interpreted by the helper programs:
-
TALLOC_FREE_FILL
: will cause memoryfree()
‘d viatalloc_free()
to be overwritten with the byte set in this variable. -
_SSS_DOM
: will influence systemd journal log messages and thus allow a bit of log spoofing.
While these variables have only minor influence on program execution, privileged programs should not allow arbitrary environment settings to affect their behaviour.
7.b) Dumpable Process Attribute Setting
All of the privileged helpers support a --dumpable
command line switch to
control whether the process will have the dumpable bit set or not. The default
for this even is to mark the process as dumpable (SUID_DUMP_USER
). This
somewhat unexpectedly overrides the sysctl setting fs.suid_dumpable
, which
is usually 0 or 2.
The dumpable setting of a process is a sensitive property that plays an
important role in the ptrace()
system call to determine whether tracing
another process is allowed. From man 2 ptrace
:
These checks are performed in cases where one process can inspect sensitive information about, or in some cases modify the state of, another process. The checks are based on factors such as the credentials and capabilities of the two processes, whether or not the “target” process is dumpable […]
We believe the only barrier left that prevents the unprivileged sssd
user
from being allowed to trace the privileged binaries is this (further excerpt
from man 2 ptrace
):
(5.2) Deny access if neither of the following is true: - The caller and the target process are in the same user namespace, and the caller’s capabilities are a superset of the target process’s permitted capabilities.
Attaching via ptrace()
is only denied because the target processes have
raised capabilities. However, this is only a kind of kernel security
extension, provided by the kernel security module
security_ptrace_access_check()
.
Besides this, the dumpable setting allows the unprivileged user to send
e.g. a SIGSEGV signal to the privileged processes and force them to dump core.
What happens from here depends on the core dump handler installed in the
system. systemd-coredump
safely handles such core dumps and the unprivileged
user cannot access them. If only core
is configured as a core pattern, like
it is the case on Debian Linux by default, for example, then the unprivileged
user can cause the core
file to be created in arbitrary directories, by
first changing into them, starting the privileged process, then killing
it. The core
file will not be readable for the unprivileged user, but it
still allows to clutter the file system and maybe even overwrite legit files
that are named core
.
7.c) Debugging Settings
The privileged programs also offer rich command line settings for enabling debugging output and redirecting it to various locations. Generally, privileged programs should be very careful about what kind of information is leaked to the caller. The debugging logs can contain information that weakens security features (like stack overflow protection) or leak privileged information that has been read in from privileged files.
8) Suggested Fixes
For privileged setuid-root-like binaries the usual precautions should be taken:
- change into a safe current working directory (CWD).
- apply a safe umask (this already happens)
- cleanse the environment from any untrusted variables, only keep a whitelist of vetted variables. E.g. also set a safe PATH.
- make sure none of the interfaces (command line parameters, STDIN data input) offers possibilities for the unprivileged caller to escalate their privileges beyond the scope of what the privileged program is supposed to do.
The last item will likely be the most difficult to realize for the programs in
question - especially in the krb5_child
helper we expect more attack surface
to exist, for example in the handling of the ccache
and keytab
files.
These are dealt with in various other code paths via krb5 library routines
that are unaware of the untrusted input. We suggested upstream to carefully
think through all the possible inputs and code paths and to tighten them.
We would furthermore strip down the supported command line switches, or limit
critical switches to callers that are root
, notably the switches that
influence debugging and logging as mentioned in section 7.c.
The dumpable
setting should be left unchanged in the privilege escalation
context.
Finally we suggest to clearly document what can be expected of the privilege separation feature and how the privileged helpers need to be packaged in order to achieve a safe installation (especially that they must not be world executable). This already happened in the description of the 2.10.1 bugfix release.
9) Situation on Other Distributions
We looked into a number of other Linux distributions and found that on Fedora, Debian and Ubuntu the SSSD privilege separation is not currently used. On Arch Linux the current 2.10.0 version is used together with privilege separation, though, which is affected by the issues covered in this report. Upstream informed us that there are plans for Fedora Linux to use the privilege separation feature soon as well.
10) Timeline
2024-11-15 | We reported the issues to the Red Hat Security Team. |
2024-12-04 | Red Hat Security assigned 3 CVEs for items 2), 3) and 6) (all later retracted). A coordinated release date (CRD) of 2024-12-18 has been suggested and agreed upon. |
2024-12-04 | SSSD developer Alexey Tikhonov responded to the report explaining that he doesn’t consider these findings CVE-worthy. |
2024-12-09 | Red Hat Security suggested to keep the 3 CVEs but to consider the issues very high complexity to exploit. |
2024-12-10 | After internal discussions Red Hat Security decided to retract the CVEs, not considering these findings to be flaws. |
2024-12-10 | Upstream published a bugfix release 2.10.1 containing a fix for issue 2) and a note hinting at the sensitivity of the helper’s permissions used in packaging. |
2024-12-13 | After some unclarity about whether the coordinated disclosure process should be continued, we agreed upon immediate publication. |
2024-12-13 | Upstream created a pull request containing further fixes addressing issues 3) and 6). |
11) References
Wed, Dec 18th, 2024
Duolingo Application on Linux
Actualización de diciembre_24 del mapa de usuarios KDE
Hace mucho tiempo publiqué el mapa generado en Google de los usuarios de KDE. Ese mapa era colaborativo y voluntario pero generado sobre Software Privativo. En varias ocasiones pedí que alguien lo cambiara a OpenStreetMap y mis súplicas fueron escuchadas. Ya casi había olvidado este proyecto pero este agosto lo recuperé, publicitándolo en el grupo de Telegram KDE – Cañas y Bravas y parece que el proyecto ha tomado impulso, así que he decidido seguir ppublicitándolo durante unos meses. Así que, tras un mes de descando, os doy la bienvenida a la actualización de diciembre_24 del mapa de usuarios KDE que, como vais a ver, se ha sigue llenand pero todavía no tenemos a nadie en Cáceres ,Lleida, Cuenca, Salamanca o Huesca, por poner algunas capitales de provincia. ¿No podemos solucionar este vacío?
Actualización de diciembre_24 del mapa de usuarios KDE
Si vais a ver el mapa de la Comunidad KDE de España marzo 2018, podréis ver una imagen estática de los usuarios que se habían puesto voluntariamente , y digo estática, porque alguien borró (queriendo o sin querer) los «pines» del mapa.
Ese incidente fue comentado en el grupo de Telegram KDE – Cañas y Bravas, y un usuario dijo que trabajaría en ello aprovechando que se debía empezar de nuevo el mapa.
Este compañero de grupo era @wakutiteo y creó, utilizando los servicios de uMap sobre OpenStreetMap el nuevo mapa de la usuarios KDE en España en el que podemos empezar a registrarnos.
En un principio había poca poca gente apuntada (mirad la entrada de junio de 2018) pero poco a poco se ha ido llenando, a pesar de la poca promoción que ha tenido. A ver si a partir de ahora voy dándole más cancha y el mapa crece . De momento pongo la captura de pantalla de este mes de agosto, la del mes de septiembre y la de este octubre del 2024 para que veamos la evolución, lenta pero constante.
Agosto 2024
Septiembre 2024
Octubre 2024
Diciembre 2024
Como vemos, siguen apareciendo poco a poco más usuarios, con una espectacular crecimiento en Andalucía, Galicia, todo el norte y este peninsular.
Pero seguimos sin usuarios en capitales de provincia como Cáceres, Lleida, Cuenca, Salamanca, Huelva, Ciudad Real, Albaceta, Zamora, Lugo, Soria, Teruel, Segovia, Tarragona, Girona, Alicante, Guadalajara, Santiago de Compostela, Pontevedra o Ávila, si no he mirado mal (que es posible).
Evidentemente, es voluntario y apuntaros es bajo vuestra propia responsabilidad. Os dejo también el mapa incrustado que se irá actualizando poco a poco.
Pincha para ver en pantalla completa
Y también os dejo un vídeo de cómo editar el mapa para poder apuntaros.
¿Qué es Umap?
Básicamente, con uMap puedes crear mapas con capas de OpenStreetMap en un minuto e incrustarlo en tu página web, de código libre. Con uMap puedes realizar las siguientes acciones:
- Elegir las capas de tu mapa
- Añadir PDIs: marcadores, líneas, polígonos…
- Elegir los colores y los iconos de los PDIs
- Gestionar opciones del mapa: mostrar un minimapa, localizar al usuario al cargar…
- Importar por lotes datos geoestructurados (geojson, gpx, kml, osm…)
- Elegir la licencia de tus datos
- Embeber y compartir tu mapa
La entrada Actualización de diciembre_24 del mapa de usuarios KDE se publicó primero en KDE Blog.
A semana mais insana de 2024, um cinema de papers.
Esta semana compramos muita pipoca na MultiCortex, pois foi um absoluto cinema de papers no setor de IA. Acreditamos que foi a semana mais insana de 2024 marcada por avanços significativos no campo da inteligência artificial, com a publicação de diversos artigos que abordam desde melhorias em arquiteturas de modelos até questões de segurança e eficiência. A seguir, a lista desses trabalhos:
- Byte Latent Transformer
- Training Large Language Models to Reason in a Continuous Latent Space
- Language Modeling in a Sentence Representation Space
- Phi-4 Technical Report – Best-of-N Jailbreaking
- Forking Paths in Neural Text Generation
- Refusal Tokens – [MASK] is All You Need
- Explore Theory-of-Mind
- Obfuscated Activations Bypass LLM Latent-Space Defenses
- The Pitfalls of Memorization
- How to Merge Your Multimodal Models Over Time?
- Machine Unlearning Doesn’t Do What You Think
- Understanding Gradient Descent through the Training Jacobian
- An Evolved Universal Transformer Memory
- Transformers Struggle to Learn to Search
- Transformers Can Navigate Mazes With Multi-Step Prediction
- Frontier Models are Capable of In-context Scheming
- Mixture of Monosemantic Experts for Transformers
- Learning to Merge LoRAs via Hypernetworks for Subject-Style Conditioned Image Generation
- Scalable Text and Image Conditioned Video Generation
- Hidden in the Noise: Two-Stage Robust Watermarking for Images
- Learned Compression for Compressed Learning
- Learning Flow Fields in Attention for Controllable Person Image Generation
- ProcessBench: Identifying Process Errors in Mathematical Reasoning
- Unraveling the Complexity of Memory in RL Agents
- Expanding Performance Boundaries of Open-Source Multimodal Models with Model, Data, and Test-Time Scaling
- APOLLO: SGD-like Memory, AdamW-level Performance
- Neural LightRig
Tue, Dec 17th, 2024
Cheers to 5 Years of openSUSE Bar
The openSUSE community will celebrate the 5-year anniversary of the openSUSE Bar on Dec. 19. Join people in the bar and celebrate this social space where open-source enthusiasts, developers and like minded individuals can come together to discuss open source and other topics.
The bar has become more than just a meeting place; it is a space to collaborate, connect and a welcoming atmosphere for sharing ideas. For years, the space has had countless informal meetups and networking events, celebratory moments after openSUSE milestones and is a place for openSUSE fans to gather.
People are invited to join in the celebration and to share memories or stories of their experience in the openSUSE Bar.
You can find a video about the beginning of the openSUSE Bar from a talk at openSUSE Conference 2022.
HTML para personas ahora también en Markdown y PDF
La web HTML para personas ahora también está disponible en formatos Markdown y PDF
Hace ya una semana que publiqué por el blog el proyecto en el que estaba enfrascado, que no es otro que HTML para personas.
La acogida ha sido genial, muchas gracias a todas las personas que me han hecho llegar su opinión y críticas, que siempre han sido buenas y positivas, me alegro.
Hoy quiero anunciar una novedad. El texto de la web está disponible en formato Markdown y en PDF.
Durante esta semana he estado trabajando en hacer posible que la web esté disponible también en estos dos tipos de formatos. Ha sido un proceso «casi» artesanal de revisión y comprobación. Espero que todo funcione como debe.
Y ya está disponible HTML para personas:
Están los enlaces también en el pie de la propia página para acceder desde ella.
Todo el código de la página, imágenes y estos dos documentos están disponibles desde su repositorio GitLab.
Y nada más que añadir…
Test syslog-ng on EPEL 10!
CentOS Stream 10 and EPEL 10 just became available, and as usual, I tried to build syslog-ng as soon as possible. For now it is available in my git snapshot repository, but I am also planning to make it available in EPEL 10 soon.
Read more at https://www.syslog-ng.com/community/b/blog/posts/test-syslog-ng-on-epel-10
Lanzador de aplicaciones Orbit Menu – Plasmoides para Plasma 6 (13)
Tras un parón debido al salto de Qt5/KF5 a Qt6/KF6 que realizó la Comunidad KDE hace ya más de seis meses decidí retomar esta sección aunque renombrándola ya que en ella solo hablaré de Plasmoides para Plasma 6. Así que hoy os presento el lanzador de aplicaciones Orbit Menu, el plasmoide número 13 de esta nueva serie.
Lanzador de aplicaciones Orbit Menu – Plasmoides para Plasma 6 (13)
Como he comentado en otras ocasiones, de plasmoides tenemos de todo tipo funcionales, de configuración, de comportamiento, de decoración o, como no podía ser de otra forma, de información sobre nuestro sistema como puede ser el uso de disco duro, o de memoria RAM, la temperatura o la carga de uso de nuestras CPUs.
Así que espero que le deis la bienvenida a un nuevo lanzador de aplicaciones Orbit Menu una creación del incombustible zayronXIO que nos ofrece otra variante de este tipo de plasmoides que destaca por la posición central del avatar del usuario y la barra inferior de acciones del sistema, algo poco habitual en este tipo de widgets.
Y como siempre digo, si os gusta el plasmoide podéis «pagarlo» de muchas formas en la 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.
La entrada Lanzador de aplicaciones Orbit Menu – Plasmoides para Plasma 6 (13) se publicó primero en KDE Blog.