With “literally all 15,000” packages being rebuilt in snapshot 20200826, openSUSE Tumbleweed roared back from a stability rating of 36 in the rebuild snapshot to a 95 rating in snapshot 20200901, according to the snapshot reviewer.

Each snapshot progressively increased in stability this week.

Snapshot 20200901 brought ImageMagick 7.0.10.28, which provided a patch for correct colospace and fixed paths for conversion of Photoshop EPS files. VirtualBox 6.1.13 arrived in the snapshot and updated the sources to run with versions above the 5.8 Linux Kernel with no modifications needed to the kernel. The library for rendering Postscript documents, libspectre 0.2.9, now requires Ghostscript 9.24 and fixed memory leaks and crashes to the program caused by malformed documents. One major version update to the game freecell-solver was made in the snapshot; version 6.0.1 had some code cleanup, minor bug fixes and the addition of a compile time option. openSUSE’s snapper package updated to 0.8.13 and fixed the Logical Volume Manager setup for volume groups and logical volumes with one character-long names. Other notable packages updated in the snapshot were xapian-core 1.4.17, openldap2 2.4.52 and qalculate 3.12.1.

Trending at a 87 rating, snapshot 20200831, brought less than a handful of updates. The packages updated in the snapshot were bind 9.16.6, libverto 0.3.1, permissions 1550_20200826, and suse-module-tools 15.3.4. The bind package, which implements the Domain Name System (DNS) protocols for the Internet, fixed several Common Vulnerabilities and Exposure including one that made it possible to trigger an assertion failure by sending a specially crafted large TCP DNS message.

Snapshot 20200829, which is likely to record a rating of 69, updated the Linux Kernel to 5.8.4. Some Advanced Linux Sound Architecture additions arrived in the kernel update. VLC player 3.0.11.1 fixed the handling of subtitles and fixed the HLS playlist that was unable to start. Fetchmail 6.4.8 plugged a memory leak where parts of the configuration overrode one another and the configuration now supports Python 3. Flatpak 1.8.2 provided a fix for seccomp filters on s390. GNU Compiler Collection 10 made some fixes and nano 5.2 made some changes that prevent a crash after a large paste in the text editor. Packages pango 1.46.1, lvm2 2.03.10 and mariadb 10.4.14 were also updated in the snapshot along with several other packages.

The 20200826 snapshot that rebuilt all the packages had a few updated versions and an update to the 5.8.2 Linux Kernel. The updates included Mesa 20.1.6, which dropped some dependencies and provided a note in the spec file to enable the dependencies when changing the defines. Several Python packages including python-setuptools were updated in the snapshot; python-setuptools 44.1.1 had a notable change referencing a fix for Python 4 in the changelog. Optimising Web Delivery, Squid improved Transfer-Encoding handling in version 4.13 and enforce token characters for field-names.

This tutorial will explain how to write a Group Policy Extension for Samba’s Winbind. Group Policy is a delivery mechanism for distributing system settings and company policies to machines joined to an Active Directory domain. Unix/Linux machines running Samba’s Winbind can also deploy these policies. Read my previous post about which Client Side Extensions and Server Side Extensions currently exist in Winbind.

Creating the Server Side Extension

The first step to deploying Group Policy is to create a Server Side Extension (SSE). There are multiple ways to create an SSE, but here we’ll only discuss Administrative Templates (ADMX). The purpose of the SSE is to deploy policies to the SYSVOL share. Theoretically, you could manually deploy any file (even plain text) to the SYSVOL and then write a Client Side Extension that parses it, but ADMX can be read and modified by the Group Policy Management Editor, which makes administration of policies simpler.

ADMX files are simply XML files which explain to the Group Policy Management Console how to display and store a policy in the SYSVOL. AMDX files always store policies in Registry.pol files. Samba provides a mechanism for parsing these, which we’ll discuss later.

Below is a simple example of an ADMX template, and it’s corresponding ADML file.

samba.admx:

<policyDefinitions revision="1.0" schemaVersion="1.0">
  <policyNamespaces>
    <target prefix="fullarmor" namespace="FullArmor.Policies.98BB16AF_01EE_4D17_870D_A3311A44D6C2" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  </policyNamespaces>
  <supersededAdm fileName="" />
  <resources minRequiredRevision="1.0" />
  <categories>
    <category name="CAT_3338C1DD_8A00_4273_8547_158D8B8C19E9" displayName="$(string.CAT_3338C1DD_8A00_4273_8547_158D8
B8C19E9)" />
    <category name="CAT_7D8D7DC8_5A9D_4BE1_8227_F09CDD5AFFC6" displayName="$(string.CAT_7D8D7DC8_5A9D_4BE1_8227_F09CD
D5AFFC6)">
      <parentCategory ref="CAT_3338C1DD_8A00_4273_8547_158D8B8C19E9" />
    </category>
  </categories>
  <policies>
    <policy name="POL_9320E11F_AC80_4A7D_A5C8_1C0F3F727061" class="Machine" displayName="$(string.POL_9320E11F_AC80_4A7D_A5C8_1C0F3F727061)" explainText="$(string.POL_9320E11F_AC80_4A7D_A5C8_1C0F3F727061_Help)" presentation="$(presentation.POL_9320E11F_AC80_4A7D_A5C8_1C0F3F727061)" key="Software\Policies\Samba\Unix Settings">
      <parentCategory ref="CAT_7D8D7DC8_5A9D_4BE1_8227_F09CDD5AFFC6" />
      <supportedOn ref="windows:SUPPORTED_WindowsVista" />
      <elements>
        <list id="LST_2E9A4684_3C0E_415B_8FD6_D4AF68BC8AC6" key="Software\Policies\Samba\Unix Settings\Daily Scripts" valueName="Daily Scripts" />
      </elements>
    </policy>
  </policies>
</policyDefinitions>

en-US/samba.adml:

<policyDefinitionResources revision="1.0" schemaVersion="1.0">
  <displayName>
  </displayName>
  <description>
  </description>
  <resources>
    <stringTable>
      <string id="CAT_3338C1DD_8A00_4273_8547_158D8B8C19E9">Samba</string>
      <string id="CAT_7D8D7DC8_5A9D_4BE1_8227_F09CDD5AFFC6">Unix Settings</string>
      <string id="POL_9320E11F_AC80_4A7D_A5C8_1C0F3F727061">Daily Scripts</string>
      <string id="POL_9320E11F_AC80_4A7D_A5C8_1C0F3F727061_Help">This policy setting allows you to execute commands, 
either local or on remote storage, daily.</string>
    </stringTable>
    <presentationTable>
      <presentation id="POL_9320E11F_AC80_4A7D_A5C8_1C0F3F727061">
        <listBox refId="LST_2E9A4684_3C0E_415B_8FD6_D4AF68BC8AC6">Script and arguments</listBox>
      </presentation>
    </presentationTable>
  </resources>
</policyDefinitionResources>

The meaning of the various tags are explained in Microsoft’s Group Policy documentation. Before the endless documentation and confusing XML scares you away, be aware there is an easier way!

ADMX Migrator

FullArmor created the ADMX Migrator to simplify the shift for system administrators from the old ADM policy templates to ADMX. Fortunately, this tool also serves our purpose for assisting us in easily creating these templates for our SSE. Unfortunately, the tool hasn’t seen any development in the past 8 years, and wont run in Windows 10 (or any Unix/Linux platform, for that matter). I had to dredge up a Windows 7 VM in order to install and use the tool (supposedly Vista works as well, but who wants to install that?).

Creating the Administrative Template

1. Open ADMX Migrator
2. Right click on ADMX Templates in the left tree view, and click New Template.
3. Give your template a name, and click OK.
4. Right click on the new template in the left tree view, and click New Category.
   
5. Give the Category a name. This name will be displayed in the Group Policy Management Editor under Administrative Templates. You can choose to nest template under an existing category, or simply add it as a new root.
   Note: You can also add sub-categories under this category. After clicking OK, right click the category you created and select New Category.
6. Next, create your policy by right clicking on your new category, and selecting New Policy Setting.
   
7. Because we’ll be applying these settings to a Linux machine, the Registry fields are mostly meaningless, but they are required. Your policies will be stored under these keys on the SYSVOL in the Registry.pol file. Choose some sensible Registry Key, such as ‘Software\Policies\Samba\Unix Settings’, and a Registry Value Name, such as ‘Daily Scripts’ (these are the values used for Samba’s cron.daily policy). The Display Name is the name that will be displayed for this policy in the Group Policy Management Editor. I usually make this the same as the Registry Value Name, but it doesn’t need to be.
8. Select whether this policy will be applied to a Machine, a User, or to Both in the Class field. In our example, we could potentially set Both, then our Client Side Extension would need to handle both cron.daily scripts (the Machine) and also User crontab entries. Click OK for your policy to be created.
9. Your new policy will appear in the middle list view. Highlight it, and you will see a number of tabs below for configuring the policy.
   
10. Select the Values tab and set the Enabled Value Type. In this case, we’ll use String, since our cron commands will be saved to the Registry.pol as a string. In the Value field, you can set a default enabled value (this is optional).
11. Select the Presentation tab, right click in the Elements view, and click New Element > ListBox (or a different presentation, depending on the policy). If you look at the samba.adml file from the previous section, you’ll notice that the presentationTable contains a listBox item. That’s what we’re creating here.
12. Choose an element Label, this will be the name for the list displayed in the Group Policy Management Editor.
13. Choose a Registry Key. This will be pre-populated with the parent Registry Key you gave when creating the policy. Append something to the key to make it unique. We’ll use ‘Software\Policies\Samba\Unix Settings\Daily Scripts’ for our cron.daily policy.
14. Navigate to the Explain tab, and add an explanation of what this policy is and what it does. This will be displayed to users in the Group Policy Management Editor.
15. Now right click on your template name in the left tree, and select Save As.
16. Finally, you’ll need to deploy your new policy definition to the SYSVOL. It should be saved to the Policies\PolicyDefinitions (the Group Policy Central Store) directory. These instructions from Microsoft can assist you in setting up your Group Policy Central Store.
    

Creating the Client Side Extension

The Client Side Extension (CSE) is the code that will be called by Samba’s Winbind to deploy our newly created policy to a client machine. CSEs must be written in Python3, and are deployed using the register_gp_extension() and unregister_gp_extension() samba functions.

#!/usr/bin/python3
# gp_scripts_ext samba gpo policy
# Copyright (C) David Mulder <dmulder@suse.com> 2020
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

import os, re
from samba.gpclass import gp_pol_ext, register_gp_extension, \
    unregister_gp_extension, list_gp_extensions
from base64 import b64encode
from tempfile import NamedTemporaryFile
from samba import getopt as options
import optparse

intro = '''
### autogenerated by samba
#
# This file is generated by the gp_scripts_ext Group Policy
# Client Side Extension. To modify the contents of this file,
# modify the appropriate Group Policy objects which apply
# to this machine. DO NOT MODIFY THIS FILE DIRECTLY.
#

'''

class gp_scripts_ext(gp_pol_ext):
    def __str__(self):
        return 'Unix Settings/Scripts'

    def process_group_policy(self, deleted_gpo_list, changed_gpo_list):

        # Iterate over GPO guids and their previous settings, reverting
        # changes made by this GPO.
        for guid, settings in deleted_gpo_list:

            # Tell the Group Policy database which GPO we're working on
            self.gp_db.set_guid(guid)

            if str(self) in settings:
                for attribute, script in settings[str(self)].items():
                    # Delete the applied policy
                    if os.path.exists(script):
                        os.unlink(script)

                    # Remove the stored removal information
                    self.gp_db.delete(str(self), attribute)

            # Commit the changes to the Group Policy database
            self.gp_db.commit()

        # Iterate over GPO objects, applying new policies found in the SYSVOL
        for gpo in changed_gpo_list:
            if gpo.file_sys_path:
                reg_key = 'Software\\Policies\\Samba\\Unix Settings'
                sections = { '%s\\Daily Scripts' % reg_key : '/etc/cron.daily',
                             '%s\\Monthly Scripts' % reg_key : '/etc/cron.monthly',
                             '%s\\Weekly Scripts' % reg_key : '/etc/cron.weekly',
                             '%s\\Hourly Scripts' % reg_key : '/etc/cron.hourly' }

                # Tell the Group Policy database which GPO we're working on
                self.gp_db.set_guid(gpo.name)

                # Load the contents of the Registry.pol from the SYSVOL
                pol_file = 'MACHINE/Registry.pol'
                path = os.path.join(gpo.file_sys_path, pol_file)
                pol_conf = self.parse(path)
                if not pol_conf:
                    continue

                # For each policy in the Registry.pol, apply the settings
                for e in pol_conf.entries:
                    if e.keyname in sections.keys() and e.data.strip():
                        cron_dir = sections[e.keyname]
                        attribute = '%s:%s' % (e.keyname,
                                b64encode(e.data.encode()).decode())

                        # Check if this policy has already been applied in the
                        # Group Policy database. Skip the apply if it's already
                        # been installed.
                        old_val = self.gp_db.retrieve(str(self), attribute)

                        if not old_val:

                            # Create a temporary file and store policy in it,
                            # then move the file to the cron directory for
                            # execution.
                            with NamedTemporaryFile(prefix='gp_', mode="w+",
                                    delete=False, dir=cron_dir) as f:
                                contents = '#!/bin/sh\n%s' % intro
                                contents += '%s\n' % e.data
                                f.write(contents)
                                os.chmod(f.name, 0o700)

                                # Store the name of the applied file, so that
                                # we can remove it later on unapply (see the
                                # first loop in this function).
                                self.gp_db.store(str(self), attribute, f.name)

                        # Commit the changes to the Group Policy database
                        self.gp_db.commit()

    def rsop(self, gpo):
        output = {}
        pol_file = 'MACHINE/Registry.pol'
        if gpo.file_sys_path:
            path = os.path.join(gpo.file_sys_path, pol_file)
            pol_conf = self.parse(path)
            if not pol_conf:
                return output
            for e in pol_conf.entries:
                key = e.keyname.split('\\')[-1]
                if key.endswith('Scripts') and e.data.strip():
                    if key not in output.keys():
                        output[key] = []
                    output[key].append(e.data)
        return output

if __name__ == "__main__":
    parser = optparse.OptionParser('gp_scripts_ext.py [options]')
    sambaopts = options.SambaOptions(parser)
    parser.add_option_group(sambaopts)

    parser.add_option('--register', help='Register extension to Samba',
                      action='store_true')
    parser.add_option('--unregister', help='Unregister extension from Samba',
                      action='store_true')

    (opts, args) = parser.parse_args()

    # We're collecting the Samba loadparm simply to find our smb.conf file
    lp = sambaopts.get_loadparm()

    # This is a random unique GUID, which identifies this CSE.
    # Any random GUID will do.
    ext_guid = '{5930022C-94FF-4ED5-A403-CFB4549DB6F0}'
    if opts.register:
        # The extension path is the location of this file. This script
        # should be executed from a permanent location.
        ext_path = os.path.realpath(__file__)
        # The machine and user parameters tell Samba whether to apply this
        # extension to the computer, to individual users, or to both.
        register_gp_extension(ext_guid, 'gp_scripts_ext', ext_path,
                              smb_conf=lp.configfile, machine=True, user=False)
    elif opts.unregister:
        # Remove the extension and do not apply policy.
        unregister_gp_extension(ext_guid)

    # List the currently installed Group Policy Client Side Extensions
    exts = list_gp_extensions(lp.configfile)
    for guid, data in exts.items():
        print(guid)
        for k, v in data.items():
            print('\t%s: %s' % (k, v))

The gp_pol_ext/gp_inf_ext Python Classes

Your CSE must be a class that inherits from a subclass of gp_ext. The gp_pol_ext is a subclass of gp_ext that provides simplified parsing of Registry.pol files. If you choose to store your policies in ini/inf files in the SYSVOL (instead of using Administrative Templates), then you can inherit from the gp_inf_ext instead.

If your class inherits from either gp_pol_ext or gp_inf_ext, it has a parse() function defined, which takes a single filename. The parse() function will parse the contents of the policy file and return it in a sensible format.

If for some reason you choose to store data on the SYSVOL in some other format (such as in XML, etc), you’ll need to subclass gp_ext, then implement a read() function, like this:

import xml.etree.ElementTree
class gp_xml_ext(gp_ext):
    def read(self, data_file):
        return xml.etree.ElementTree.parse(data_file)

The read() function is called by parse(), passing it a local filename tied to the systems SYSVOL cache. Then within process_group_policy() you can call parse() to fetch the parsed data from the SYSVOL.

Process Group Policy

The process_group_policy() function serves two primary purposes; it applies new policy, and it removes old policy. In the example, you’ll notice there are two main loops. The first loop iterates over the deleted_gpo_list, which are all the policies that should be removed. The second loop iterates over the changed_gpo_list, which are new policies which must be applied.

Deleted GPOs

for guid, settings in deleted_gpo_list:
    self.gp_db.set_guid(guid)
    if str(self) in settings:
        for attribute, script in settings[str(self)].items():
            if os.path.exists(script):
                os.unlink(script)
            self.gp_db.delete(str(self), attribute)
    self.gp_db.commit()

The deleted_gpo_list is a dictionary which contains the guids of Group Policy Objects, with associated settings which were previously applied. This list of applied settings is generated by the second loop (changed_gpo_list) while it is applying policy. The self.gp_db object is a database handle which allows you to manipulate the Group Policy Database.

The Group Policy Database keeps track of all settings that have been applied, and info on how to revert those applied settings. For example, in the smb.conf CSE, the attribute stored in settings could be client max protocol and the stored value could be NT1. If our GPO has applied a client max protocol set to SMB3_11, the Group Policy database keeps track of the previous value of NT1 for when it’s time to remove the SMB3_11 policy.

In our example cron script policy above, you can see that the stored value is a filename (the script variable). This is actually the name of the script we’ve applied, which will allow us to delete it later (therefore removing the policy). The scripts CSE is a special case, where we don’t need to keep track of an old value to restore, instead we’re keeping track of files to delete (since the ‘old value’ is that the script didn’t exist).

Changed GPOs

for gpo in changed_gpo_list:
    if gpo.file_sys_path:
        reg_key = 'Software\\Policies\\Samba\\Unix Settings'
        sections = { '%s\\Daily Scripts' % reg_key : '/etc/cron.daily',
                     '%s\\Monthly Scripts' % reg_key : '/etc/cron.monthly',
                     '%s\\Weekly Scripts' % reg_key : '/etc/cron.weekly',
                     '%s\\Hourly Scripts' % reg_key : '/etc/cron.hourly' }
        self.gp_db.set_guid(gpo.name)
        pol_file = 'MACHINE/Registry.pol'
        path = os.path.join(gpo.file_sys_path, pol_file)
        pol_conf = self.parse(path)
        if not pol_conf:
            continue
        for e in pol_conf.entries:
            if e.keyname in sections.keys() and e.data.strip():
                cron_dir = sections[e.keyname]
                attribute = '%s:%s' % (e.keyname,
                        b64encode(e.data.encode()).decode())
                old_val = self.gp_db.retrieve(str(self), attribute)
                if not old_val:
                    with NamedTemporaryFile(prefix='gp_', mode="w+",
                            delete=False, dir=cron_dir) as f:
                        contents = '#!/bin/sh\n%s' % intro 
                        contents += '%s\n' % e.data
                        f.write(contents)
                        os.chmod(f.name, 0o700)
                        self.gp_db.store(str(self), attribute, f.name) 
                self.gp_db.commit()

The second loop is a little more involved. When we iterate over changed_gpo_list, we’re actually iterating over a list of GPO objects. The attributes of the object are:

• gpo.name: The GUID of the GPO.
• gpo.file_sys_path: A physical path to a cache of GPO on the local filesystem.

There are other methods and attributes, but these are the only ones important to a CSE.

The primary purpose of this loop is to iterate over the GPOs, read their policy in the SYSVOL, then check the sections for the Registry Key we created in our Server Side Extension. If our policy Registry Key exists, then we read the entry and apply the policy.

In our example, we find the ‘Software\Policies\Samba\Unix Settings\Daily Scripts’ policy, then read the script contents from Registry.pol entry and write the script to a local file. In the example code, we write the script to a temporary file, then move the file to it’s permanent location in /etc/cron.daily.

We also have to make sure we set the name of the new script in our self.gp_db (Group Policy Database). This ensures that we can remove the policy when we delete the GPO. At the beginning of our loop, we also need to ensure we call set_guid() on our Group Policy Database, so it knows which GPO we’re operating on.

Resultant Set of Policy

The rsop() function in the extension is optional. It should return a dictionary containing key/value pairs of what our current policy will or has applied. The function is passed a list of GPO objects (similar to our changed_gpo_list), and we should parse the list similar to how we did in our changed_gpo_list loop. The difference is that the rsop() function does not apply any policy. It only returns what will be applied. This function enables the samba-gpupdate --rsop command to report on applied, or soon to be applied policy.

Registering/Unregistering a Client Side Extension

The final step is to register an extension on the host. While the example code provides a detailed example of how to register an extension, the basic requirement is simply to call register_gp_extension().

ext_guid = '{5930022C-94FF-4ED5-A403-CFB4549DB6F0}'
ext_path = os.path.realpath(__file__)
register_gp_extension(ext_guid, 'gp_scripts_ext', ext_path,
    smb_conf='/etc/samba/smb.conf', machine=True, user=False)

The extension guid can be any random guid. It simply must be unique among all extensions that you register to the host. The extension path is literally just the path to the source file containing your CSE.

You must pass your smb.conf file to the extension, so it knows where to store the list of registered extensions. You also must specify whether to apply this extension to the machine, or to individual users (or to both).

Unregistering the extension is simple. You call the unregister_gp_extension() and pass it the unique guid you previously chose which represents this CSE.

Conclusion

I hope this tutorial proves useful. Please comment below if you have questions! You can also reach me on freenode in the samba-technical channel (nic: dmulder).

Aunque el blog se centra en la Comunidad KDE también me interesa compartir todo aquello relacionado con el Conocimiento Libre. Es por ello que he participado en proyectos como la Wikipedia con mis alumnos o dedico esta entrada a cómo editar OpenStreetMap fácilmente con StreetComplete, mi descubrimiento de estas vacaciones con el que he colaborado con el mapa libre y compartido tiempo con mi hijo.

Cómo editar OpenStreetMap fácilmente con StreetComplete

Estas vacaciones las he disfrutado en un pequeño pueblo de montaña, con lo cual tenía tiempo de sobra para pasear con mi hijo y descubrir esos rincones tan mágicos que ocultan estas poblaciones.

Venía con la idea de aprovechar estos momentos para colaborar con la edición de OpenStreet Maps, el proyecto libre para cartografiar el mundo, pero la verdad es que hacerlo de memoria me parecía un poco árido y, sobre todo, «poco motivador» para mi hijo.

Así que fue todo un acierto descubrir StreetComplete, una aplicación Open Source para Android creada por Tobias Zwick que se encarga de encontrar errores, información incompleta o ampliable, preguntarla de forma clara y precisa al usuario y volcarla a OpenStreetMap. ¡Maravilloso!

En otras palabras, StreetComplete es una aplicación que en forma de juego te permite colaborar con el OpenStreetMap completando la información que todavía le falta, la cual es menos de lo que podríamos pensar.

La aplicación usa Tangram-ES para mostrar el mapa. el cual depende de Overpass API para encontrar las peticiones y las sube directametne vía API de OpenStreetMap. Su código fuente está alojado en GitHub y os recomiendo visitar la wiki del proyecto.

Cómo funciona StreetComplete

Quizás lo más destacado de la aplicación es su facilidad de uso. Para empezar a editar apenas requiere unos minutos y los pasos para hacerlo desde cero son los siguientes:

• Te descargas e instalas la aplicación de F-Droid o Google Play.
• Te registras con la cuenta de OpenStreetMap que tengas (o te creas una).
• La aplicación cargará retos de la zona en la que te encuentres y te los mostrará en pantalla.

• Simplemente pasea hasta el reto, pulsa en el mismo y responde a la pregunta que te plantea. Por ejemplo:
  • ¿De qué tipo es la calle? La aplicación te mostrará diversos tipos como asfalto, tierra, adoquines, hormigón, etcétera.
  • ¿Qué horario tiene el establecimiento? StreetComplete te permite de forma rápida introducir los días y las horas de apertura.
  • ¿Tiene iluminación la calle? Con respuesta binaria si/no.
  • ¿Tiene acera la calle? Y te mostrará un dibujo con la distribución de la misma.
• A medida que vayas contestando te dará estrellas a modo de puntuación y desbloqueará otros retos.

Todo ello con una interfaz muy cuidada y con la posibilidad de acceder a la Wiki de OpenStreetMap para afinar en tus decisiones. Además, la aplicación está destinada a ser utilizada en exteriores, funciona sin conexión a Internet y no consume demasiado saldo del móvil.

Mi experiencia con niños

El uso de esta aplicación ha sido fabulosa con mi hijo y mi sobrina de ocho años, nos hemos pateado el pueblo arriba y abajo contestando a las preguntas que nos iba planteando y averiguando cosas que desconocíamos de la población.

Al principio muy básicas y en pequeñas cantidades, del estilo tipo de pavimento de la calle o si había iluminación, pero a medida que «avanzábamos» en el uso de StreetComplete nos planteaba retos más precisos como el tipo de vivienda, el número de plantas o los horarios de los establecimientos.

Fueron unos días de exploración muy entretenidos y divertidos ya que la gamificación (término que significa introducir mecánicas de juegos como puntos o logros en actividades educativas) de la aplicación lograba que mis pequeño acompañantes estuvieran más que motivados para salir a pasear por el pueblo, debiendo mediar entre ellos en los turnos de búsqueda.

Además, y según mi experiencia de maestro y padre, propició que mi hijo y mi sobrina:

• Empezaran a orientarse con un mapa, aunque fuera virtual.
• Colaborar sin saberlo en mejorar un proyecto colaborativo como OpenStreetMap.
• Se animaran a la hora de hablar con las personas encargadas de los comercios.
• Identificaran carriles bicis, aceras, tipos de pavimentos, etc.
• Mejorara el conocimiento del pueblo y sus servicios, valorando incluso la belleza de algunas casas o edificios.
• Realizaran un ejercicio físico continuo (después del confinamiento se perdió esa costumbre).

Para finalizar el artículo comentar StreetComplete me parece una aplicación extraordinaria de código abierto para utilizar con nuestros alumnos para fomentar el conocimiento de su propio entorno y, al tiempo, colaborar con la Comunidad de OpenStreetMap.

De hecho me planteo que sería muy interesante para su incorporación en alguna que otra asignatura como Ciencias Sociales o Informática.

Tidak seperti Android atau Windows yang sudah diatur oleh pabrikan, factory reset di Linux bisa diatur seperti apa kita mau saat kita melakukan factory reset. Kita bisa mengubah konfigurasi atau memasang software yang jika komputer kita kembalikan ke factory reset, konfigurasi atau software tersebut tidak ikut hilang. Seperti pada tulisan minimal/custom install openSUSE, kita mengubah konfigurasi /etc/zypp/zypp.conf dan beberapa opsi repositori sebelum membuat factory reset. Pengaturan yang sudah diubah ini tidak akan kembali ke default jika kita melakukan factory reset.

Di tulisan tersebut juga disebutkan bahwa kita membuat factory reset sebelum memasang Desktop Environment/Window Manager dan Display Manager. Tujuannya supaya jika kita ingin mengganti Desktop Environment dengan yang lain atau dengan Window Manager, kita tidak perlu menghapus paket-paket dari Desktop Environment yang sudah terpasang beserta aplikasi-aplikasi pendukungnya. Cukup melakukan reset, semua yang terpasang akan langsung hilang. Karena jika kita menghapus paket-paket yang sudah terpasang, terutama Desktop Environment, mungkin akan menyisakan dependensi yang tidak ikut terhapus atau konfigurasi-konfigurasi dari Desktop Environment tersebut.

Persiapan

Jika Anda ingin membuat fitur factory reset di openSUSE, disarankan untuk tidak mengaktifkan Snapshot ketika membuat partisi Btrfs saat proses instalasi, karena kita akan membuat konfigurasi di subvolume yang lain. Sehingga nomor Snapshot akan serasi di semua konfigurasi jika membuatnya secara bersamaan, yang akan membuat manajemen Snapshot lebih mudah.

Atur konfigurasi yang diperlukan

Atur konfigurasi yang diperlukan, seperti mengubah beberapa opsi di /etc/zypp/zypp.conf dan opsi repositori seperti yang dilakukan di tulisan minimal/custom install openSUSE supaya kita tidak perlu mengatur lagi opsi-opsi tersebut setelah melakukan factory reset.

Pastikan Snapper terpasang

Di openSUSE, fitur factory reset bisa dibuat dengan menggunakan Snapper yang sudah tersedia di dalam installer. Jika Anda memasang openSUSE dengan cara minimal/custom install, pastikan memilih paket snapper di layar Software Selection and System Tasks. Jika Anda memasang openSUSE dengan cara standar, paket tersebut sudah otomatis ikut terpasang.

Jika saat instalasi Anda tidak memilih untuk memasang Snapper, pasang dari DVD installer. Login sebagai root untuk mempercepat proses. Jika sudah terlanjur masuk sebagai user standar, pindah ke root:

su -

Matikan semua repositori online:

zypper modifyrepo -dt

Aktifkan repositori dari installer:

zypper modifyrepo -el

Masukkan piringan DVD/flashdisk installer, lalu install Snapper:

zypper install snapper

Matikan lagi repositori dari installer:

zypper modifyrepo -dl

Aktifkan kembali repositori repo-oss, repo-non-oss, repo-update dan repo-update-non-oss:

zypper modifyrepo -e repo-oss repo-non-oss repo-update repo-update-non-oss

Matikan snapper-timeline.timer

Service snapper-timeline.timer dimaksudkan untuk membuat Snapshot setiap jam. Kita tidak ingin mempunyai Snapshot sebanyak itu, jadi kita perlu mematikannya sebelum membuat konfigurasi Snapper:

systemctl disable --now snapper-timeline.timer

Pastikan Kernel GA tidak akan terhapus

Periksa jika multiversion.kernels di /etc/zypp/zypp.conf sudah menyertakan oldest sebagai salah satu opsi. Ini juga sudah dibahas di tulisan minimal/custom install openSUSE. Lihat dengan grep:

grep -i 'multiversion.kernels' /etc/zypp/zypp.conf

Jika belum ada opsi oldest seperti ini:

multiversion.kernels = latest,latest-1,running

Tambahkan opsi oldest:

sed -i 's/,running/,running,oldest/' /etc/zypp/zypp.conf

Yang akan membuatnya berubah menjadi seperti ini:

multiversion.kernels = latest,latest-1,running,oldest

Membuat Snapshot

Kita akan membuat konfigurasi Snapper sesuai dengan subvolume yang tersedia, kecuali /tmp dan dua subvolume di dalam direktori /boot.

Lihat daftar subvolume

Setelah semua persiapan selesai kita bisa mulai membuat konfigurasi Snapper berdasarkan daftar subvolume yang dibuat saat instalasi openSUSE.

Lihat daftar Snapshot:

btrfs subvolume list /

Di layar akan muncul respon serupa dengan ini:

ID 256 gen 71 top level 5 path @
ID 258 gen 70 top level 256 path var
ID 259 gen 57 top level 256 path usr/local
ID 260 gen 58 top level 256 path tmp
ID 261 gen 57 top level 256 path srv
ID 262 gen 57 top level 256 path root
ID 263 gen 57 top level 256 path opt
ID 264 gen 57 top level 256 path home
ID 265 gen 57 top level 256 path boot/grub2/x86_64-efi
ID 266 gen 57 top level 256 path boot/grub2/i386-pc

Buat konfigurasi Snapper

Berdasarkan daftar di atas kita buat konfigurasi Snapper untuk @ (root), var, usr/local, srv, root, opt dan home:

snapper -c root create-config /

snapper -c var create-config /var

snapper -c local create-config /usr/local

snapper -c srv create-config /srv

snapper -c su create-config /root

snapper -c opt create-config /opt

snapper -c home create-config /home

Untuk subvolume /root beri nama su karena nama konfigurasi root sudah dibuat sebelumnya.

Jika setiap menjalankan perintah di atas muncul peringatan Failed to set locale. Fix your system. Abaikan saja untuk saat ini.

Lihat hasilnya:

snapper list-configs

Sesuaikan setelan konfigurasi

Untuk melihat setelan konfigurasi Snapper, jalankan:

snapper -c root get-config

Untuk melihat setelan semua konfigurasi:

for config in `. /etc/sysconfig/snapper; echo $SNAPPER_CONFIGS`; do snapper -c $config get-config; done

Sesuaikan konfigurasi yang dibutuhkan:

for config in `. /etc/sysconfig/snapper; echo $SNAPPER_CONFIGS`; do snapper -c $config set-config TIMELINE_CREATE=no TIMELINE_LIMIT_DAILY=7 TIMELINE_LIMIT_HOURLY=6 TIMELINE_LIMIT_MONTHLY=0 TIMELINE_LIMIT_WEEKLY=4 TIMELINE_LIMIT_YEARLY=0; done

TIMELINE_CREATE adalah opsi untuk membuat Snapshot setiap jam. Kita tidak ingin membuat Snapshot setiap jam, jadi opsi ini kita isi dengan no. Opsi TIMELINE_LIMIT adalah untuk membatasi jumlah Snapshot berdasarkan kalender. Anda bisa mengaturnya sesuai kebutuhan.

Buat Snapshot setiap komputer dinyalakan

Untuk mengganti Snapshot timeline yang dibuat setiap jam, kita lebih baik membuat Snapshot yang dibuat setiap kali komputer dinyalakan.

Snapper menyediakan sebuah service dengan nama snapper-boot.service dan snapper-boot.timer, tapi secara default tidak aktif. Kita perlu memodifikasi service ini karena dia hanya membuat Snapshot untuk konfigurasi root saja. Untuk meyakinkan, periksa apakah snapper-boot.timer berjalan:

systemctl status snapper-boot.timer

Jika berjalan, matikan:

systemctl disable snapper-boot.timer

Salin file /usr/lib/systemd/system/snapper-boot.service ke /etc/systemd/system/ untuk dimodifikasi:

cp -av /usr/lib/systemd/system/snapper-boot.service /etc/systemd/system/

Hapus opsi ExecStart untuk diganti yang baru:

sed -i '/ExecStart/d' /etc/systemd/system/snapper-boot.service

Buat ExecStart baru:

echo -e "ExecStart=/bin/bash -c 'for config in \`. /etc/sysconfig/snapper; echo \$SNAPPER_CONFIGS\`; do /usr/bin/snapper -c \$config create -c timeline; done'" >> /etc/systemd/system/snapper-boot.service

Kita akan buat snapper-boot.service berjalan mandiri, tanpa harus dipicu oleh snapper-boot.timer seperti sebelum dimodifikasi. Untuk itu kita perlu menambahkan bagian [Install]:

echo -e "\n[Install]\nWantedBy=multi-user.target" >> /etc/systemd/system/snapper-boot.service

Lihat hasilnya dengan perintah cat:

cat /etc/systemd/system/snapper-boot.service

Hasilnya seperti ini:

[Unit]
Description=Take snapper snapshot of root on boot

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'for config in `. /etc/sysconfig/snapper; echo $SNAPPER_CONFIGS`; do /usr/bin/snapper -c $config create -c timeline; done'

[Install]
WantedBy=multi-user.target

Aktifkan service tersebut:

systemctl enable snapper-boot.service

Periksa jika ada Snapshot yang sudah terlanjur dibuat oleh snapper-timeline.timer:

snapper list -a

Kita berharap hanya ada Snapshot 0 saja. Jika ada Snapshot lain, hapus:

for config in `. /etc/sysconfig/snapper; echo $SNAPPER_CONFIGS`; do snapper -c $config delete --sync 1

Perintah tersebut untuk menghapus Snapshot nomor 1. Jika ada Snapshot lain selain nomor 1, hapus juga dengan mengubah angkanya.

Jalankan ulang (reboot) komputer untuk membuat Snapshot pertama. Kita perlu membuat Snapshot saat komputer booting karena saat itu kita sedang tidak melakukan apa-apa di komputer, sehingga data yang diambil oleh Snapshot akan sempurna. Tidak akan ada yang terambil separuh karena sedang kita modifikasi misalnya.

Buat titik factory reset

Setelah komputer dijalankan ulang, periksa apakah Snapshot berhasil dibuat:

snapper list -a

Jika berhasil, seharusnya ada Snapshot nomor 1 di semua konfigurasi dengan kolom Cleanup berisi timeline. Modifikasi Snapshot tersebut supaya tidak terhapus:

for config in `. /etc/sysconfig/snapper; echo $SNAPPER_CONFIGS`; do snapper -c $config modify -c '' -d 'factory reset' -u 'reset=yes' 1

Periksa hasilnya:

snapper list -a

Jika berhasil, kolom Cleanup berubah menjadi kosong, kolom Description menjadi factory reset dan kolom Userdata menjadi reset=yes.

Selesai. Proses selanjutnya Anda tinggal memasang Desktop Environment/Window Manager dan Display Manager serta aplikasi-aplikasi lainnya untuk digunakan sehari-hari.

Cara melakukan factory reset

Untuk melakukan factory reset, Anda perlu boot ke Kernel pertama (Kernel yang dipasang saat instalasi openSUSE) dengan memilih opsi Advanced options for openSUSE Leap/Tumbleweed pada tampilan Grub2. Setelah opsi tersebut dipilih dengan menekan Enter, akan ada daftar Kernel yang terpasang. Arahkan pada pilihan Kernel paling bawah (tanpa tulisan recovery mode), lalu tekan e pada keyboard untuk mengubah parameternya. Arahkan ke teks bertuliskan linuxefi atau linux, tekan tombol End pada keyboard untuk mengarahkan kursor ke ujung teks. Tambahkan spasi dan angka 3, lalu tekan F10.

Ini akan membawa Anda ke Virtual Console (CLI). Login sebagai root, lalu jalankan:

for config in `. /etc/sysconfig/snapper; echo $SNAPPER_CONFIGS`; do snapper -c $config undochange 1..0; done

Reboot.

Mengembalikan perubahan tanpa factory reset

Service snapper-boot.service yang tadi kita modifikasi akan membuat Snapshot setiap kali komputer dijalankan. Ini berguna ketika kita ingin mengembalikan perubahan tanpa harus melakukan factory reset. Karena jika melakukan factory reset, Anda harus memulai lagi dari awal memasang Desktop Environment/Window Manager dan aplikasi-aplikasi lainnya.

Misalnya jika Anda mengalami error di komputer, cukup reboot dan masuk ke Virtual Console seperti pada proses akan melakukan factory reset di atas. Lalu jalankan snapper undochange ke nomor Snapshot sebelum error terjadi, misalnya:

for config in `. /etc/sysconfig/snapper; echo $SNAPPER_CONFIGS`; do snapper -c $config undochange 1234..0; done

Akan berguna juga jika kita ingin mencoba software, tapi ternyata kita tidak puas dengan software tersebut. Kita bisa meresetnya ke Snapshot sebelum software tersebut dipasang.

Pastikan Snapshot tetap serasi

Pastikan Anda rutin memeriksa nomor Snapshot supaya tetap sama di semua konfigurasi dengan:

snapper list -a

Jika ada salah satu konfigurasi Snapper yang nomor Snapshot-nya tidak sama dengan konfigurasi yang lain, buat Snapshot baru supaya jadi sama:

snapper -c <nama_konfigurasi> create -c timeline

Peringatan!

Karena subvolume /home dimasukkan ke daftar konfigurasi Snapper, jika kita melakukan factory reset, semua data yang ada di sana akan ikut hilang. Jadi disarankan untuk membuat partisi khusus untuk menyimpan data-data penting seperti halnya pengguna Windows biasa menyimpan data di drive D, E, F, dan seterusnya. Biarkan hanya file-file konfigurasi saja yang ada di direktori home atau data-data sementara/tidak penting yang Anda tidak akan menyesal kehilangannya.

Atau Anda bisa melakukan reset dengan mengecualikan konfigurasi home dengan perintah berikut:

for config in `. /etc/sysconfig/snapper; echo $SNAPPER_CONFIGS | sed 's/ home//'`; do snapper -c $config undochange 1..0; done

Dengan resiko konfigurasi-konfigurasi dari software yang direset yang berada di direktori home tidak akan ikut terhapus yang mungkin akan menyebabkan konflik dengan konfigurasi baru dari software yang dipasang kemudian. Seperti jika Anda mengubah Desktop Environment dengan Desktop Environment yang lain.

---

Tulisan ini bisa dibaca juga di: https://kikisyahadat.github.io/2020/09/03/membuat-fitur-factory-reset.html

What makes Matrix uniquely different from other messaging platforms is the ability to have bridges to other chat services. Matrix has all the signs of being the great chat unification platform that adequately reduces complexity in communication. Element feels complete, well polished and is enjoyable to use so using Element as my front-end, I should … Continue reading Send and Receive Text Messages SMS with Element →

Ένα πράγμα που με ρωτάνε πολλοί, ξανά και ξανά, είναι «Γιατί openSUSE;». Η έννοια της ερώτησης δεν είναι πάντα η ίδια. Μπορεί να σημαίνει: «Γιατί να το χρησιμοποιήσω;», «Γιατί πρέπει να συνεισφέρω στο έργο openSUSE;», «Γιατί το χρησιμοποιείς εσύ;», «Γιατί να μην χρησιμοποιήσω [βάλτε το όνομα κάποιας άλλης διανομής];», αλλά η ερώτηση καταλήγει πάντα στο «Τι ιδιαίτερο έχει η openSUSE;».

Είναι μια καλή ερώτηση, και η δυσκολία στην απάντηση δεν οφείλεται στην έλλειψη καλών λόγων, αλλά στην αφθονία τους, σε συνδυασμό με μια γενική τάση στην κοινότητά openSUSE, που είναι πολύ μετριόφρων.

Εδώ είναι μια προσπάθειά να δούμε μερικούς λόγους για τους οποίους εσείς, ο αναγνώστης, πρέπει να συνεισφέρετε στο έργο openSUSE και να χρησιμοποιείτε το λογισμικό που αναπτύσσει η κοινότητα.

1ος Λόγος: Δεν είμαστε (απλώς) μια διανομή Linux

Κανονικά, το πρώτο πράγμα που σκέφτονται οι άνθρωποι όταν ακούνε το openSUSE είναι η «Τυπική έκδοση της διανομής», όπως το openSUSE Leap (Λήψη ΕΔΩ)

Ωστόσο, το έργο openSUSE παράγει πολλά περισσότερα.

Για αρχή, δεν έχουμε μία, αλλά τεχνικά ΔΥΟ άλλες διανομές Linux που διατηρούμε.

openSUSE Tumbleweed - η εκπληκτική κυλιόμενη έκδοση που καταφέρνει να προσφέρει στους χρήστες του σταθερό, εύχρηστο, λειτουργικό σύστημα Linux, με συνεχή ενημέρωση λογισμικού.
Ιδανικό όχι μόνο για προγραμματιστές, αλλά και για όσους θέλουν το πιο πρόσφατο και καλύτερο λογισμικό, κορυφαίοι ειδικοί του Linux, όπως ο Greg Kroah-Hartman, έχουν δηλώσει ότι οι κυλιόμενες κυκλοφορίες όπως το Tumbleweed αντιπροσωπεύουν το «μέλλον» των διανομών Linux. Το openSUSE είναι το καλύτερο (Διαβάστε το άρθρο Γιατί να χρησιμοποιείσετε openSUSE Tumbleweed) μεταξύ των κυλιόμενων διανομων.
Στην περίπτωσή μου, προτιμώ το Tumbleweed τόσο για την σταθερότητά του αλλά και διότι ως ενεργός μεταφραστής του GNOME, θέλω να έχω πάντα την τελευταία έκδοση του GNOME ώστε να διορθώνω σφάλματα μετάφρασης, έτσι ώστε να επωφελούνται άλλες διανομές που χρησιμοποιούν GNOME.
Αν θέλετε να το δείτε μόνοι σας, κατεβάστε από το ΕΔΩ

openSUSE Leap - Η openSUSE Leap είναι ένας "καινούργιος" τρόπος κατασκευής της openSUSE και είναι ένας νέος τύπος υβριδικής διανομής Linux. Η Leap χρησιμοποιεί την πηγή από την SUSE Linux Enterprise (SLE), η οποία δίνει στην Leap ένα επίπεδο σταθερότητας απαράμιλλο από άλλες διανομές Linux και το συνδυάζει με τις εξελίξεις της κοινότητας για να δώσει στους χρήστες, προγραμματιστές και sysadmins την καλύτερη διαθέσιμη σταθερή εμπειρία Linux.
Η πρώτη κυκλοφορία της Leap ήταν στις 4 Νοεμβρίου 2015, με την κυκλοφορία της openSUSE Leap 42.1. Η Leap θα έχει μικρές κυκλοφορίες και οι χρήστες αναμένεται να κάνουν αναβάθμιση στην τελευταία δευτερεύουσα κυκλοφορία εντός 6 μηνών από τη διαθεσιμότητά της, οδηγώντας σε κύκλο ζωής 18 μηνών συντήρησης και με ενημερώσεις ασφαλείας ανά δευτερεύουσα κυκλοφορία. Η σειρά Leap 15 αναμένεται να επιτύχει περίπου 36 μήνες ενημερώσεων συντήρησης και ασφάλειας.

openSUSE Kubic: Η openSUSE Kubic είναι ένα έργο που συντηρεί πολλές τεχνολογίες που σχετίζονται με container ως μέρος του openSUSE.

Αυτό επικεντρώνεται κυρίως στο openSUSE Kubic, μια παραλλαγή openSUSE Tumbleweed που επικεντρώνεται στη φιλοξενία υπηρεσιών container. Η openSUSE Kubic αποτελείται επί του παρόντος από δύο βασικά στοιχεία:

* openSUSE MicroOS - ένα λειτουργικό σύστημα που βασίζεται στο openSUSE που παρέχει ενημερώσεις Transactional (Atomic) σε ένα σύστημα αρχείων btrfs root μόνο για ανάγνωση, σχεδιασμένο να φιλοξενεί containers με αυτοματοποιημένη διαχείριση και ενημέρωση κώδικα.
* kubeadm - ένα εργαλείο εκκίνησης συστοιχίας Kubernetes ενσωματωμένο ως μέρος της openSUSE Kubic για εκτέλεση πάνω από την openSUSE MicroOS.
Ο πηγαίος κώδικας για μεγάλο μέρος των εργαλείων που σχετίζονται με το Kubic βρίσκεται στο GitHub Project.

Λοιπόν, η openSUSE δεν είναι μόνο ΜΙΑ διανομή Linux, αλλά περιμένετε, υπάρχουν περισσότερα!

Το έργο openSUSE φιλοξενεί έναν ολόκληρο σωρό άλλων έργων λογισμικού, πάντα Open Source, τα οποία χρησιμοποιούμε στην κοινότητα αλλά και ενθαρρύνουμε τους άλλους να χρησιμοποιούν και να συνεισφέρουν. Αυτά περιλαμβάνουν:

Open Build Service - το εργαλείο κατασκευής, το οποίο δημιουργεί όλα τα πακέτα μας, καθώς και αυτά για SUSE Linux Enterprise, Arch, Debian, Fedora, Scientific Linux, RHEL, CentOS, Ubuntu και πολλά άλλα.

openQA - αυτοματοποιημένη δοκιμή για οποιοδήποτε λειτουργικό σύστημα, το οποίο μπορεί να διαβάσει την οθόνη και να ελέγξει τον κεντρικό υπολογιστή δοκιμής με τον ίδιο τρόπο που κάνει ένας χρήστης.

YaST - Το καλύτερο και ολοκληρωμένο εργαλείο ρύθμισης και εγκατάστασης συστήματος Linux.

KIWI - Δημιουργεί εικόνες Linux σε πραγματικό υλικό, αλλά και για συστήματα container όπως το Docker ή το podman.

Snapper - Δημιουργία, διαχείρηση και επαναφορά στιγμιοτύπων συστήματος. Επαναφέρετε το σύστημά σας χωρίς ταλαιπωρία σε προηγούμενο στιγιότυπο όταν μετά από ενημέρωση καταλήξετε με κατεστραμμένο σύστημα (πιθανότατα να είναι δικό σας λάθος, το Snapper μπορεί να σας δείξει τι άλλαξε μεταξύ των στιγμιότυπων).

OSEM - Διαχείριση Εκδηλώσεων Ανοιχτού Κώδικα. Πολλά έργα ανοιχτού κώδικα έχουν τα δικά τους συνέδρια και άλλες εκδηλώσεις. Έχουμε το δικό μας εργαλείο για τη διαχείριση προτάσεων για παρουσιάσεις, την οργάνωση προγραμμάτων, τη λήψη εγγραφών κ.λπ.

Και πολλά άλλα, πολλά από τα οποία μπορείτε να βρείτε στη σελίδα του έργου μας στο GitHub.

2ος Λόγος: Κατασκευάζουμε και χρησιμοποιούμε τα καλύτερα εργαλεία

Ίσως έχετε παρατηρήσει ένα κοινό θέμα ανάμεσα σε πολλά από τα έργα λογισμικού που αναφέρονται παραπάνω. Είμαστε ένα έργο που ενδιαφέρεται πολύ για τη χρήση του σωστού εργαλείου για τη κατάλληλη δουλειά.
Σε πολλές περιπτώσεις αυτό σημαίνει τη χρήση πολλών από τα ίδια εργαλεία που χρησιμοποιούν άλλα έργα, όπως είναι IRC, Git & GitHub, Φόρουμ, Λίστες αλληλογραφίας κ.λπ. Δεν είμαστε το είδος του έργου που θέλει να εφεύρει ξανά τον τροχό μόνο και μόνο επειδή δεν το κάναμε πρώτοι, αλλά όταν τα εργαλεία που βρίσκονται εκεί έξω δεν κάνουν τη δουλειά αρκετά καλά, σηκώνουμε τα μανίκια μας και προσπαθούμε να δημιουργήσουμε το καλύτερο εργαλείο για αυτήν την κάθε εργασία.

Εργαζόμαστε επίσης πολύ σκληρά για να παράγουμε εργαλεία που μπορούν και πρέπει να υιοθετηθούν από ένα πολύ ευρύτερο κοινό και όχι μόνο από την «κοινότητα του openSUSE».
Αυτό πιθανότατα τονίζεται καλύτερα μιλώντας για δύο από τα καλύτερα εργαλεία μας, το Open Build Service και το openQA.

Open Build Service - Όπως ήδη αναφέρθηκε, το εργαλείο κατασκευής δημιουργεί όλα τα πακέτα διανομής openSUSE, τα ISO κλπ.
Δημιουργεί και φιλοξενεί αποθετήρια για αυτά τα πακέτα.
Κατασκευάστηκε πάντα ως εργαλείο για χρήση από όλες τις διανομές, το οποίο είναι σε θέση να δημιουργήσει πακέτα για SUSE Linux Enterprise, Arch, Debian, Fedora, Scientific Linux, RHEL, CentOS, Ubuntu και άλλα.
Υπάρχει μια γραφική διεπαφή (μπορείτε να δείτε και να το χρησιμοποιήσετε ΕΔΩ) αλλά και το εργαλείο γραμμής εντολών osc (τεκμηρίωση ΕΔΩ). Ακόμα και κάποιος που δεν έχει εμπειρία κατασκευής πακέτων μπορεί εύκολα να δει τα περιεχόμενα οποιουδήποτε πακέτου στο OBS, να καταλάβει πώς δημιουργούνται, να το διακλαδώσει (να το κάνει fork, για να χρησιμοποιήσουμε τον ισοδύναμο όρο του github) στο δικό του Έργο-Αποθετήριο και να το επεξεργαστεί όπως νομίζει.
Επιτρέπεται η χρήση του OBS του openSUSE από οποιονδήποτε χωρίς χρέωση, έτσι ώστε να μπορεί να κατασκευάσει και να φιλοξενήσει τα πακέτα του στην υποδομή του openSUSE, δωρεάν (αν και τουλάχιστον, θα θέλαμε ως αντάλλαγμα να βεβαιωθούν ότι τα πακέτα για openSUSE λειτουργούν αβασάνιστα ;-) )
Το OBS χρησιμοποιείται ήδη από άλλες εταιρείες και έργα όπως το VideoLAN, η Dell, το HipChat και το ownCloud, αλλά αν είστε στον κλάδο δημιουργίας λογισμικού για Linux, πρέπει πραγματικά να αναρωτηθείτε «Γιατί δεν χρησιμοποιώ το OBS για την κατασκευή τα πακέτα μου;»

openQA - Ένα άλλο κόσμημα. Το openQA είναι ένα εργαλείο δοκιμών που σας επιτρέπει να δημιουργήσετε δοκιμές για οποιοδήποτε λειτουργικό σύστημα ή εφαρμογή. Σε αντίθεση με σχεδόν κάθε άλλο εργαλείο δοκιμών, το openQA δοκιμάζει το λογισμικό με τον ίδιο τρόπο που το κάνουν οι χρήστες. Κοιτάζει στην οθόνη και διασφαλίζει ότι ο χρήστης θα δει τι περιμένετε να δει. Στη συνέχεια, θα πατήσει τα ίδια κουμπιά πληκτρολογίου και ποντικιού με τα οποία ένας χρήστης θα εργαζόταν μέσω της εφαρμογής. Μπορείτε να το δείτε στη δράση ΕΔΩ.
Το openSUSE χρησιμοποιεί εκτεταμένα το openQA για την κατασκευή του Tumbleweed. Ο προτεινόμενος κώδικας για το Tumbleweed δοκιμάζεται από το openQA πριν γίνει αποδεκτός και δοκιμαστεί ξανά META την αποδοχή του (για να βεβαιωθούμε ότι ενσωματώνεται καλά με όλα τα άλλα πακέτα που έχουν συγχωνευθεί πρόσφατα).
Με αυτόν τον τρόπο μπορούμε να προσφέρουμε το Tumbleweed ως μια «σταθερή» κυλιόμενη έκδοση, γιατί χάρη στο openQA γνωρίζουμε ότι η διανομή λειτουργεί πριν σταλούν οι ενημερώσεις στους υπολογιστές των χρηστών. Εάν κάτι δεν δουλέψει, το openQA σταματά την κυκλοφορία και οι χρήστες δεν παρατηρούν προβλήματα, εκτός από ίσως μια μικρή καθυστέρηση στη λήψη νέων ενημερώσεων. Με την (εξαιρετικά σπάνια) πιθανότητα κάτι να ξεφύγει από το openQA, γίνεται μια νέα δοκιμαστική υπόθεση, οπότε δεν γινεται ποτέ το ίδιο λάθος δύο φορές.
Το openQA χρησιμοποιείται επίσης από την SUSE για τη δοκιμή της SUSE Linux Enterprise και το έργο Fedora ξεκίνησε πρόσφατα να το χρησιμοποιεί. Θα θέλαμε να δούμε περισσότερες διανομές να το χρησιμοποιούν.

3ος Λόγος: Θέματα μηχανικής

Γιατί επικεντρωνόμαστε στα εργαλεία; Πέρα από τα εργαλεία που χρησιμοποιούμε, ξοδεύουμε πολύ χρόνο, εγκεφαλικά κύτταρα και συζητήσεις, σηκώνουμε μανίκια και προσπαθούμε να βρούμε τον καλύτερο τρόπο για να δημιουργήσουμε το λογισμικό.

Αυτό οδήγησε στο openSUSE να πρωτοστατεί με πολλές καινοτομίες σε τομείς όπως η διαχείριση πακέτων. Το zypper και το libsolv σημαίνουν ότι, σε αντίθεση με άλλες διανομές Linux που βασίζονται σε RPM, το «χάλι με τις εξαρτήσεις» είναι κάτι παρελθόν για εμάς και καταφέρνουμε να σταθούμε δίπλα-δίπλα με Debian και Ubuntu, να δούμε τους διαχειριστές πακέτων τους και να πούμε «ωραία, μπορούμε να το κάνουμε αυτό και πολλά περισσότερα».

Επίσης, δεν μας ενδιαφέρει να είμαστε ένα άλλο έργο ανοιχτού κώδικα που να παίρνει τα πάντα από δεκάδες έργα και είτε να σφραγίζουμε το λογότυπό μας και να το ονομάζουμε δικά μας, είτε να αλλάζουμε πολλά πράγματα και να μην επιστρέφουμε έργο στην κοινότητα.
Δουλεύουμε σε συνεργασία με όλα τα γνωστά έργα ανοικτού κώδικα, είτε ο πυρήνας, το GNOME, το KDE, οτιδήποτε άλλο, για να δώσουμε τα ανατροφοδότηση, να στείλουμε τις διορθώσεις στον κώδικα, για το όφελος όλων.

4ος Λόγος: Κοινότητα, κοινότητα, κοινότητα

Η κοινότητα openSUSE είναι υπέροχη. Θα συνοψίσω μερικά πράγματα εδώ.

Πρώτον, λίγα λόγια για την SUSE. Η SUSE χρηματοδοτεί την κοινότητα openSUSE, και αποτελεί ένα σημαντικό μέρος της κοινότητας, απασχολώντας έναν μεγάλο αριθμό προγραμματιστών που συνεισφέρουν στο έργο openSUSE, συνεισφέρει δε στο έργο openSUSE τόσο με κώδικα, όσο και με προσωπικό αλλά και με χρήματα.
Από πολλές απόψεις είναι ο «προστάτης» του έργου openSUSE, έχοντας την εταιρία στην πλάτη μας όταν το χρειαζόμαστε, χωρίς όμως να σημαίνει ότι η εταιρία SUSE ελέγχει το έργο. Το έργο openSUSE είναι ανεξάρτητο, ελεύθερο να καθορίσει τη δική του κατεύθυνση.
Η SUSE βλέπει τον εαυτό της ως ίσο μέλος στην κοινότητα, συμμετέχοντας με τον ίδιο τρόπο όπως όλοι οι άλλοι, ενθαρρύνοντας τους μηχανικούς της να συμμετέχουν σε συζητήσεις και βοηθούν στον καθορισμό της κατεύθυνσης του έργου openSUSE μέσω υποβολής κώδικα, όπως όλοι οι άλλοι.
Ο ανοικτός κώδικας λειτουργεί καλύτερα όταν υπάρχει ελευθερία καινοτομίας, αυτή είναι η θέση στην οποία βρίσκεται το έργο openSUSE, η SUSE είναι μια εταιρεία που κατανοεί την βάση της - καθώς η τρέχουσα εκστρατεία της λέει ότι «Ο ανοικτός κώδικας είναι στα γονίδιά μας».

Αν λοιπόν η SUSE δεν είναι το «αφεντικό», τότε ποιος είναι; Προφανώς η κοινότητα. Αυτή αποφασίζει, και μάλιστα θέλουμε περισσότερα άτομα να μας βοηθήσουν να κάνουμε πολλά πράγματα! Είμαστε το είδος του έργου που είναι πολύ ανοιχτό σε όλους που θέλουν να συνεισφέρουν και προσπαθούμε σκληρά να διατηρήσουμε ένα πολύ χαμηλό «εμπόδιο» για την είσοδο.
Η κοινότητα openSUSE δεν είναι το είδος της κοινότητας που θα ορίσει να αποκτήσετε πολλές γνώσεις προτού σας επιτραπεί να κάνετε οτιδήποτε για το έργο openSUSE.
Εάν δείτε κάτι που χρειάζεται διόρθωση, μιλήστε με τα άτομα που εργάζονται στην επίλυση σφαλμάτων, διορθώστε το μαζί τους και υποβάλετε τις συνεισφορές σας. Αυτό ισχύει για τον κώδικα, τον ιστότοπο, το wiki, το μάρκετινγκ, οτιδήποτε και οπουδήποτε. Δεν είμαστε ένα έργο για το οποίο χρειάζεστε άδεια για να μπορέσετε να συμμετάσχετε.
Προσπαθούμε να διατηρήσουμε τις διαδικασίες μας λιτές, αλλά αυτές που έχουμε είναι στο Wiki μας, και όσον αφορά τη συνάντηση με υπάρχοντα μέλη που συνεισφέρουν, μπορείτε εύκολα να τους βρείτε στα κανάλια IRC και στις λίστες αλληλογραφίας μας.

Εάν είστε χρήστης και χρειάζεστε βοήθεια στην πραγματικότητα χρησιμοποιώντας το openSUSE αλλά δεν είστε έτοιμοι να εμπλακείτε με τη συνεισφορά στο έργο ακόμα, τότε έχουμε μια μεγάλη κοινότητα που βοηθούν τους ανθρώπους μέσω του IRC, του Φόρουμ και του Telegram (Αγγλικό) / Telegram (Ελληνικό).

Όταν όλοι ασχολούνται με όλα, δεν οδηγεί στο απόλυτο χάος; Οχι ακριβώς. Το μοντέλο ανοιχτού κώδικα λειτουργεί, με τις λίγες διαδικασίες που έχουμε στη διάθεσή μας να παρέχουν αρκετή δομή και ασφάλεια, ώστε οποιαδήποτε προβλήματα εμφανιστούν να αντιμετωπιστούν ως μέρος μιας διαδικασίας φυσικής ροής και μάθησης.
Όμως, δεν είναι ουτοπία, από καιρό σε καιρό φυσικά εμφανίζονται διάφορα και γι' αυτό το έργο openSUSE έχει το «Διοικητικό Συμβούλιο».
Η δουλειά του είναι να βοηθάει στη διατήρηση του έργου και της κοινότητας στο σωστό δρόμο, να μιλούν τα μέλη της κοινότητας μεταξύ τους, να επιλύει συγκρούσεις, και να είναι οι «τελευταίοι υπεύθυνοι λήψης αποφάσεων» εάν δεν υπάρχει κάποιος άλλος ικανός/κατάλληλος για να λάβει μια δύσκολη απόφαση που επηρεάζει το openSUSE.

Η δομή του «Διοικητικού Συμβουλίου» είναι επίσης μια ωραία αντανάκλαση του τρόπου δομής της υπόλοιπης κοινότητάς μας - από τις 5 εκλεγμένες έδρες του Διοικητικού Συμβουλίου, όχι περισσότερες από 2 θέσεις μπορούν να καταληφθούν από άτομα που απασχολούνται / ελέγχονται από τον ίδιο οργανισμό. Αυτό σημαίνει ότι καμία εταιρεία (ούτε καν SUSE) δεν μπορεί να έχει την πλειοψηφία των θέσεων στο Διοικητικό Συμβούλιο, διασφαλίζοντας ότι είναι υγιής και ισορροπημένη όπως και η υπόλοιπη κοινότητά μας.

Και τέλος, η κοινότητα openSUSE είναι απλώς μια μεγάλη ομάδα ανθρώπων. Ένα μεγάλο μέρος αυτής συναντιέται στα τακτικά συνέδρια του openSUSE. Στα συνέδρια γίνεται η συνδυασμός συναντήσεων των μελών της κοινότητας, συνομιλιών αλλά και διασκέδασης με πολλές πολλές μπύρες.

Και θυμηθείτε το σύνθημά μας...

Have a Lot of Fun!

Casi finalizando el verano y ya tenemos Disponible el decimonoveno número de la revista digital SoloLinux la cual, como siempre, podéis leer online o descargar para poder disfrutar en vuestro lugar de vacaciones si tenéis una conexión de internet limitada.

Disponible el decimonoveno número de la revista digital SoloLinux

La introducción es repetitiva, pero es que es interesante hacer un poco de historia. Hubo un tiempo en que las revistas sobre Linux digitales estuvieron de moda. Tenemos todavía publicándose Atix y Full Circle Magazine (en inglés, gracias Vampiro Nocturno), pero antes teníamos a Linux+, Papirux, Begins o TuxInfo, por citar algunas discontinuadas.

Desde hace un tiempo una revista digital SoloLinux tiene su entrada mensual en el blog, tener todas las alternativas posibles para compartir conocimiento es algo que caracteriza al Conocimiento Libre

En esta edición la introducción de sus creadores es corta pero interesante ya que se desvela el ganador del concurso del número anterior:

«Sin trampa ni cartón, lo prometido es deuda. En el número anterior de la revista sololinux, sorteamos un VPS entre los que dejaran un comentario. El ganador ya disfruta de su premio, enhorabuena Toni Hortal.«

Más información: Revista Sololinux N19

Así que, ya tenemos disponible el decimoctavo número de la revistas digital SoloLinux, el cual llega cargado de contenidos y con el siguiente índice.

MANUALES Instalar Conky y Conky manager en Ubuntu 20.04 Cómo agregar mi cuenta de Gmail en Thunderbird Verificar la instalación de Java y su versión en Linux Error: dpkg returned an error code (1), en Ubuntu Como crear un USB MultiBoot con Ventoy de forma rápida Como instalar el Kernel 5.8.1 en Ubuntu o Linux Mint Ocultar carpetas y archivos del administrador en linux Como reparar el archivo mtab en linux Configurar una ip estática en Ubuntu, CentOS y derivados Actualizar el kernel de Ubuntu es muy fácil con Mainline Instalar un servidor de correo en Ubuntu 20.04 con PostfixAdmin Instalar BigBlueButton en Ubuntu 16.04 LTS Habilitar snap en Linux Mint 20 Ulyana DISTROS LINUX Calculate Linux 20.6 – Una distribución linux sorprendente LMDE 4 – El Linux Mint con Debian SOFTWARE Instalar Genymotion en Linux sin problemas Instalar Xampp en Ubuntu 20.04 y otras distribuciones linux Instalar LibreOffice 7.0 en Ubuntu – Alternativa a MS Office Instalar Whatsapp en linux – Agosto del 2020 Descargar videos de youtube con Tartube en linux

HARDWARE Instalar el driver Realtek RTL8723DE en linux Consejos para ahorrar batería en linux Modificar la configuración de la CPU con cpufrequtils Diferencias entre raid 1 y raid 5 en un servidor Zram, Zswap o Zcache – Cuál debo utilizar en mi pc NOTICIAS Los mejores blogs de Linux en español – Encuesta de tictac Debian 8 Jessie dice adiós – Se acaba su soporte Qué es el software Open Source ¿Es Linux Mint la mejor distribución para comenzar en Linux? NOTICIAS Toshiba vende su división de portátiles a Sharp Nuevo Kernel para Ubuntu 16.04 LTS y derivados SEGURIDAD Proteger un servidor de ataques DDos con mod_evasive JUEGOS Como jugar a juegos de Android en Linux Instalar SuperTuxKart 1.2 en Ubuntu 20.04 LA OPINIÓN DEL LECTOR La opinión del Lector: Jaime Pons GANADOR SORTEO VPS El ganador es: Toni Hortal ENTREVISTAS Entrevista a Alexis Administrador de ESGEEKS Entrevista a Karla Administradora de KARLAPEREZYT y Youtuber en KARLASPROJECT

La revista puede ser descargada o simplemente visualizarla en línea, ya que se cuelga en diferente servicios como Calameo. A continuación os dejo los enlaces de descarga y visualización directa de los cuatro primeros números.

Además, recordar que desde el número anterior se ha abierto el canal oficial sololinux.es de Telegram: https://t.me/sololinux_es

Evidentemente, este proyecto no se centra en exclusivo a los contenidos de su web y está abierto a colaboraciones de todo tipo. De esta forma si estas interesado en insertar publicidad en nuestra revista, o quieres que publiquemos algún articulo que hayas escrito tu mismo, puedes contactar con «Adrián» por correo electrónico: adrian @ sololinux. com

Muchos ánimos en este nuevo proyecto ya que facilita la difusión del Software Libre de una forma que ya no es tan habitual en estos tiempos pero que es igual de válida.

Yet again the iterations to produce the default and complimentary wallpapers for 3.38 generated some variants that didn’t make the cut, but I’d like to share with fellow gnomies.

Tal y como estaba previsto en el calendario de lanzamiento de los desarrolladores, hoy martes xx de agosto la Comunidad KDE ha comunicado que ha sido lanzada la quinta actualización de Plasma 5.19. Una noticia que aunque es esperada y previsible es la demostración palpable del alto grado de implicación de la Comunidad en la mejora continua de este gran entorno de escritorio de Software Libre.

Lanzada la quinta actualización de Plasma 5.19

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las actualizaciones.

De esta forma, el martes XX de agosto ha sido lanzada la quinta actualización de Plasma 5.19, la cual solo trae (que no es poco) soluciones a los bugs encontrados en esta semana de vida del escritorio y mejoras en las traducciones. Es por tanto, una actualización 100% recomendable.

Más información: KDE

Las novedades básicas de Plasma 5.19

Como he dicho en la introducción esta versión de Plasma no ofrece muchas novedades y los desarrolladores se han dedicado más a pulir la versión anterior e ir mejorando la experiencia de uso.

No obstante, tal y como se comentó en la entrada que se realizó en el día de su lanzamiento, tenemos algunas novedades como las siguientes:

• Mejoras en los plasmoides: reescrito al pack de widgets de System Monitor o los de la bandeja del sistema, por poner un par de ejemplos.
• Completada la colección por defecto de avatares de usuarios.
• Mejoras en la consistencia entre módulos de las Preferencias del Sistema.
• Optimización de la herramienta de indexación de ficheros.
• Rediseñado KinfoCenter.
• Mejoras en Kwin, Wayland y Discover.

Más información: KDE

Ya está disponible la ISO para descargar y probar el proyecto openSUSE Jump en versión Alfa para acercar más SUSE Linux y openSUSE

Hace unos días en este mismo blog podías leer que pronto podrías probar la nueva versión de desarrollo de openSUSE Jump. Pues el día ha llegado, y ya hay imágenes ISO disponibles para descargar y probar esta prueba de concepto que acerca todavía más SUSE Linux Enterprise y la versión comunitaria openSUSE Leap.

Como ya has podido leer en este blog, openSUSE Jump es una prueba de concepto de lo que sería una distribución de openSUSE en el que compartiera los mismos binarios con SUSE Linux Enterprise.

Ya es posible descargar una primera imagen ISO, en versión Alfa, para poder testear tus paquetes, comprobar cómo funciona todo y reportar errores encontrados, participando así en este desarrollo del nuevo modo de trabajo que se prepara para próximas versiones de openSUSE Leap.

El trabajo está siendo bastante intenso y se está reportando en las listas de correo todos las reuniones que se están celebrando y todos los avances que se van consiguiendo para realizar el proyecto.

Si quieres descargar la imagen ISO de openSUSE Jump puedes hacerlo desde este enlace:

• https://download.opensuse.org/distribution/jump/15.2/

A día de hoy está en versión Alfa, por lo que no está aconsejado para instalarlo como sistema operativo principal y de uso diario, si no como banco de pruebas para testear y reportar errores.

Es una primera imagen en la que ver cómo se desarrolla este proyecto de unificación de binarios entre SUSE y openSUSE, y como sabes, Jump no tiene propósito de duración a largo plazo. Ya que el método de trabajo desarrollado en esta, será la que después se siga para desarrollar las siguientes versiones de openSUSE Leap.