# data[].attributes.body
Tutorial completo para crear y gestionar usuarios locales en Windows Server 2019

# data[].attributes.attachment_link.title
Gestionando Usuarios locales en Windows Server 2019

# data[].attributes.body
Guía paso a paso sobre usuarios y grupos en Windows Server

# data[].attributes.attachment_link.title
Curso de Windows Server 2019 - Crear usuarios y grupos locales

# data[].attributes.body
Diseño avanzado de grupos y asignación de permisos a recursos compartidos

# data[].attributes.attachment_link.title
07-05 DISEÑAR GRUPOS Y ASIGNAR PERMISOS A RECURSOS DE LA RED / Curso de Windows Server 2019 /

# data[].attributes.body
Documentación oficial de Microsoft sobre gestión de cuentas

# data[].attributes.attachment_link.title
Manage User Accounts in Windows Server Essentials

# data[].attributes.attachment_link.description
Learn about the Users page of the Windows Server Essentials Dashboard and how it centralizes information and tasks that help you manage the user accounts.

# data[].attributes.body
Configuración y aplicación de políticas de grupo en Windows Server

# data[].attributes.attachment_link.title
Como crear y administrar políticas de grupos en Windows Server 2019

# data[].attributes.body
Explicación completa sobre cómo funcionan, crear y asignar permisos

# data[].attributes.attachment_link.title
Usuarios, Grupos y Permisos en Linux || Ubuntu server 22.04

# data[].attributes.body
Tutorial sobre gestión de usuarios en Ubuntu 22.04

# data[].attributes.attachment_link.title
Gestión de USUARIOS y GRUPOS en Ubuntu 22.04 | Curso GNU/Linux | N° 11

# data[].attributes.body
Gestión de permisos de lectura, escritura y ejecución

# data[].attributes.attachment_link.title
Permisos por usuario y grupos en Ubuntu 22.04 | Curso GNU/Linux | N° 12

# data[].attributes.body
Guía paso a paso para crear grupos en Ubuntu 22.04 LTS

# data[].attributes.attachment_link.readable_text
Como ya hemos comentado el algún otro artículo, un grupo ofrece la posibilidad de que definamos características generales (permisos o privilegios) que luego heredarán aquellos usuarios a los que hagamos miembros del grupo.

Del mismo modo, cuando necesitemos retirarle los permisos o privilegios a un usuario, bastará con eliminarlo de la lista de usuarios miembros del grupo.

A pesar de todo, como ya te comentábamos hace unos días en el artículo Mejorar la administración de usuarios en Ubuntu 22.04 LTS con gnome-system-tools, desde Ubuntu 11.10 Oneiric Ocelot, la herramienta que permitía administrar grupos de usuarios de forma sencilla desapareció en favor de otra, mucho más simple, que sólo permitía administrar cuentas de usuario.

De cualquier modo, podemos seguir utilizando la herramienta que se incluía en las versiones anteriores, llamada gnome-system-tools, aunque antes deberemos instalarla.

Instalar gnome-system-tools

Como es lógico, antes de proseguir con el artículo de hoy, debes tener instalada en tu sistema la herramienta gnome-system-tools. Si no es así, y necesitas ayuda con el proceso de instalación, puedes echar un vistazo al artículo que te menciono más arriba.

Ejecutar gnome-system-tools

En la interfaz gráfica, encontraremos la herramienta gnome-system-tools bajo el nombre, más manejable, de Usuarios y grupos.

Para ejecutarla, comenzaremos haciendo clic sobre el elemento Mostrar aplicaciones.

Cuando se muestre el panel de actividades, debemos localizar el icono de Usuarios y grupos. Es tan sencillo como comenzar a escribir su nombre en la barra de búsqueda, cuando lo encontremos, hacer clic sobre él.

Si, se encuentra en la primera posición de la lista o, como en la imagen, es el único elemento encontrado, también puedes pulsar la tecla Intro.

Cuando se muestre la ventana Ajustes de usuarios, verás una lista, a la izquierda, con todos los usuarios registrados en tu sistema. A la derecha, aparecerán los datos del usuario seleccionado y debajo diferentes botones.

La ventana Ajustes de usuarios

Crear una nueva cuenta de grupo

Para comenzar a crear una nueva cuenta de grupo, bastará con hacer clic sobre el botón Gestionar grupos.

Hacemos clic sobre Gestionar grupos.

Al hacerlo, obtendremos una nueva ventana titulada Ajustes del grupo. A la izquierda tenemos una lista con todos los grupos que existen actualmente en el sistema y a la derecha botones para añadir o eliminar grupos y para editar sus propiedades.

De momento, hacemos clic sobre el botón Añadir.

Pero,como se trata de una tarea administrativa, el programa nos pide la contraseña antes de completar el trabajo.

La escribimos y pulsamos Intro (o hacemos clic sobre el botón Autenticar).

Así, conseguimos una nueva ventana titulada Grupo nuevo, donde podremos incluir los datos de grupo que pretendemos crear.

En la parte superior completaremos el campo Nombre de grupo. Debajo, aparece un identificador numérico único que identificará al grupo. Inicialmente, incluye un valor predeterminado, pero podrás cambiarlo por otro siempre que no coincida con un grupo que ya exista. Aún así, si no tienes una buena razón para ello, te recomiendo que lo dejes como está.

Por último, en la parte inferior dispones de una lista con los usuarios que tiene actualmente el equipo. Puedes marcar los que quieres que sean miembros del grupo.

Cuando termines, haz clic sobre el botón Aceptar.

Al hacerlo, volverá a mostrarse la ventana Ajustes del grupo.

Y en ella aparece el grupo que acabamos de crear.

Como es lógico, en cualquier momento podrás usar el botón Propiedades para acceder a la lista de usuarios miembros y añadir o eliminar cualquiera de ellos.

Hasta aquí el artículo de hoy. Espero que te resulte útil.

# data[].attributes.attachment_link.title
Crear un nuevo grupo de usuarios en Ubuntu 22.04 LTS - SomeBooks.es

# data[].attributes.attachment_link.description
Como ya hemos comentado el algún otro artículo, un grupo ofrece la posibilidad de que definamos características generales (permisos o privilegios) que luego heredarán aquellos usuarios a los que hagamos miembros del grupo. Del mismo Leer más...

# data[].attributes.body
Administración de permisos usando comandos chmod y chown

# data[].attributes.attachment_link.title
Cómo cambiar permisos y propietarios en Linux

# data[].attributes.attachment_link.description
¿Quieres cambiar los permisos y propietarios en Linux? Sigue este tutorial para aprender a hacerlo usando los comandos chmod y chown.

# data[].attributes.body
Cómo crear y mantener una buena documentación técnica

# data[].attributes.body
Guía oficial para comenzar con Git

# data[].attributes.attachment_link.title
Comenzar con Git - Documentación de GitHub

# data[].attributes.attachment_link.description
Obtén información sobre los conceptos básicos de Git trabajando en un escenario de ejemplo.

# data[].attributes.body
Tutorial sobre cómo iniciar un repositorio para tu proyecto

# data[].attributes.attachment_link.title
Como crear un repositorio de Git | Atlassian Git Tutorial

# data[].attributes.attachment_link.description
Configurar un repositorio de Git: el comando git init crea un nuevo repositorio, git clone copia un repositorio existente y git config configura tu instalación de Git desde la línea de comandos

# data[].attributes.body
Aprende Git y GitHub desde cero con este curso completo

# data[].attributes.attachment_link.title
Curso de GIT y GITHUB DESDE CERO Para Aportar a Proyectos

# data[].attributes.body
Cómo implementar un flujo de trabajo eficiente con Git

# data[].attributes.attachment_link.readable_text
El flujo de trabajo centralizado es un flujo de trabajo de Git estupendo para equipos que están realizando la migración desde Subversion (SVN). Al igual que SVN, el flujo de trabajo centralizado usa un repositorio central como punto de entrada de todos los cambios al proyecto. En lugar de trunk, la rama de desarrollo predeterminada se llama main (principal), y todos los cambios se confirman en dicha rama. Este flujo de trabajo no requiere ninguna rama más aparte de main.

La migración a un sistema de control de versiones distribuido puede parecer una tarea complicada, pero no tienes que cambiar tu flujo de trabajo existente para sacarle partido a Git. Tu equipo puede desarrollar proyectos del mismo modo en el que lo hacían con Subversion.

No obstante, usar Git para impulsar tu flujo de trabajo de desarrollo presenta algunas ventajas en comparación con SVN. En primer lugar, le brinda a cada desarrollador su propia copia local del proyecto completo. Este entorno aislado deja que cada desarrollador trabaje de forma independiente a todos los demás cambios de un proyecto; pueden añadir confirmaciones a su repositorio local y olvidarse por completo de los desarrollos posteriores hasta que los necesiten.

En segundo lugar, te proporciona acceso al sólido modelo de fusión y creación de ramas de Git. Al contrario que SVN, las ramas de Git se han diseñado para constituir un mecanismo de seguridad de integración de código y uso compartido de cambios entre repositorios. El flujo de trabajo centralizado es similar a otros flujos de trabajo en lo que respecta al uso de un repositorio remoto alojado en servidor al que los desarrolladores pueden realizar envíos e incorporar cambios. En comparación con otros flujos de trabajo, el flujo de trabajo centralizado no tiene solicitudes de incorporación de cambios o patrones de bifurcación. Un flujo de trabajo centralizado suele ser más adecuado para equipos que migran desde SVN a Git y otros de tamaño reducido.

Funcionamiento

Los desarrolladores empiezan por clonar el repositorio central. En sus propias copias locales del proyecto, editan archivos y confirman cambios como lo harían en SVN; no obstante, estas nuevas confirmaciones se almacenan de forma local, completamente aisladas del repositorio central. Esto permite que los desarrolladores aplacen la sincronización con los niveles superiores hasta que realicen una pausa.

Para publicar cambios en el proyecto oficial, los desarrolladores "envían" su rama main local al repositorio central. Este proceso equivale a svn commit, excepto porque añade todas las confirmaciones locales que no se han enviado todavía a la rama main central.

Incialización del repositorio central

En primer lugar, hace falta crear el repositorio central en un servidor. Si se trata de un proyecto nuevo, puedes inicializar un repositorio vacío. Si no es así, tendrás que importar un repositorio Git o SVN existente.

Los repositorios centrales deben ser siempre bare (vacíos, es decir, sin ningún directorio en funcionamiento), que se pueden crear de esta forma:

ssh user@host git init --bare /path/to/repo.git

Asegúrate de utilizar un nombre de usuario de SSH válido en user, el dominio o la dirección IP de tu servidor en host, y la ubicación en la que quieres almacenar el repositorio en /path/to/repo.git. Ten en cuenta que la extensión .git se sueñe añadir al nombre del repositorio para indicar que es un repositorio bare (vacío).

Repositorios centrales alojados

Los repositorios centrales se suelen crear mediante servicios de alojamiento de Git externos como, por ejemplo, Bitbucket Cloud. El servicio de alojamiento realiza por ti el proceso de inicializar un repositorio bare (vacío) que se ha explicado anteriormente. A continuación, dicho servicio de alojamiento proporcionará una dirección para acceder al repositorio central desde tu repositorio local.

Clonación del repositorio central

Acto seguido, cada desarrollador crea una copia local de todo el proyecto. Esto se consigue mediante el comando git clone:

git clone ssh://user@host/path/to/repo.git

Cuando clonas un repositorio, Git añade automáticamente un acceso rápido llamado origin que apunta al repositorio "principal", ya que da por sentado que querrás interactuar con él más adelante.

Aplicación de cambios y confirmaciones

Cuando el repositorio se clona de forma local, el desarrollador puede aplicar cambios mediante el proceso de confirmación estándar de Git: editar, preparar y confirmar. Si no te has familiarizado con el entorno de ensayo, debes saber que consiste en una forma de preparar una confirmación sin tener que incluir todos los cambios del directorio en funcionamiento. Esto te permite crear confirmaciones con un enfoque muy claro, incluso si has aplicado muchos cambios locales.

git status # View the state of the repo
git add <some-file> # Stage a file
git commit # Commit a file</some-file>

Recuerda que, como estos comandos crean confirmaciones locales, John puede repetir el proceso todas las veces que quiera sin tener que preocuparse por lo que esté sucediendo en el repositorio central. Esta característica puede resultar muy útil para funciones de gran tamaño que se tienen que desglosar en bloques más sencillos y reducidos.

Envío de nuevas confirmaciones al repositorio central

Una vez que se hayan aplicado cambios nuevos al repositorio local, se deberán enviar estos cambios para compartirlos con otros desarrolladores del proyecto.

Este comando enviará los nuevos cambios confirmados al repositorio central. Cuando envías cambios al repositorio central, es posible que las actualizaciones enviadas anteriormente por otros desarrolladores contengan código que entra en conflicto con las actualizaciones que tú quieres enviar. Git mostrará un mensaje en el que se indica este problema. En esta situación, tendrá que ejecutarse el comando git pull en primer lugar. Esta situación de conflicto se explica en profundidad en la sección siguiente.

Gestión de conflictos

El repositorio central representa el proyecto oficial, por lo que su historial de confirmación se debe tratar como algo sagrado e inmutable. Si las confirmaciones locales de un desarrollador difieren de las del repositorio central, Git rechazará el envío de cambios porque estos sobrescribirían las confirmaciones oficiales.

Antes de que el desarrollador pueda publicar una función, tiene que buscar y actualizar las confirmaciones centrales y reorganizar los cambios a partir de ellas. Es como decir "quiero añadir mis cambios a lo que los demás ya han hecho". El resultado es un historial perfectamente lineal, como las de los flujos de trabajo de SVN tradicionales.

Si los cambios locales entran en conflicto directo con las confirmaciones en niveles superiores, Git pondrá en pausa el proceso de fusión mediante cambio de base y te dará la oportunidad de resolver los conflictos de forma manual. Lo bueno de Git es que usa los mismos comandos, git status y git add, tanto para generar confirmaciones como para resolver conflictos de fusión. Esto facilita a los nuevos desarrolladores la gestión de sus propias fusiones. Además, si tienen problemas, Git hace que sea muy fácil anular por completo la fusión mediante cambio de base y volver a intentarlo (o ir a pedir ayuda).

Veamos un ejemplo general sobre cómo un equipo que suele ser pequeño puede colaborar mediante este flujo de trabajo. Hemos visto como dos desarrolladores, John y Mary, pueden trabajar en funciones separadas y compartir sus contribuciones mediante un repositorio centralizado.

John trabaja en su función

En este repositorio local, John puede desarrollar funciones mediante el proceso de confirmación estándar de Git: editar, preparar y confirmar.

Recuerda que, como estos comandos crean confirmaciones locales, John puede repetir este proceso tantas veces como desee sin tener que preocuparse por lo que está pasando en el repositorio central.

Mary trabaja en su función

Mientras tanto, Mary trabaja en su propia función y en su propio repositorio local con el mismo proceso de edición/preparación/confirmación. Al igual que a John, no le importa lo que esté sucediendo en el repositorio central y lo cierto es que tampoco le importa lo que John está haciendo en su repositorio local, ya que todos los repositorios locales son privados.

John publica su función

Cuando John haya terminado su función, deberá publicar sus confirmaciones locales en el repositorio central, de forma que otros miembros del equipo puedan acceder a ellas. Puede hacerlo con el comando git push de este modo:

Recuerda que origin es la conexión remota al repositorio central que Git creó cuando John lo clonó. El argumento main le indica a Git que intente hacer que la rama main de origin tenga el mismo aspecto que su rama main local. Como el repositorio central no se ha actualizado desde que John lo clonó, esta acción no creará ningún conflicto y el envío se realizará según lo previsto.

Mary intenta publicar su función

Veamos lo que pasa cuando Mary intenta enviar su función después de que John haya publicado con éxito sus cambios en el repositorio central. Puede usar el mismo comando push:

No obstante, como su historial local es distinto que el del repositorio, git rechazará la solicitud con un mensaje de error algo extenso:

error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Así se evita que Mary sobrescriba las confirmaciones oficiales. Tiene que incorporar los cambios de las actualizaciones de John a su repositorio, integrarlos con sus cambios locales y, a continuación, volver a intentarlo.

Mary realiza una reorganización a partir de las confirmaciones de John

Mary puede usar el comando git pull para incorporar a su repositorio cambios presentes en el repositorio remoto. Este comando se parece en cierto modo a svn update, ya que incorpora al repositorio local de Mary los cambios presentes en todo el historial de confirmaciones del repositorio remoto e intenta integrarlos con sus confirmaciones locales:

git pull --rebase origin main

La opción --rebase le pide a Git que mueva todas las confirmaciones de Mary al extremo de la rama main después de sincronizarla con los cambios del repositorio central, como se muestra a continuación:

La incorporación de cambios seguirá funcionando si se te olvida esta opción, pero es posible que tengas que realizar una confirmación de fusión cada vez que alguien tenga que realizar una sincronización con el repositorio central. Para este flujo de trabajo, siempre es mejor reorganizar en lugar de generar una confirmación de fusión.

Mary soluciona un conflicto de fusión

La fusión mediante cambio de base consiste en transferir todas las confirmaciones locales a la rama main de una en una. De este modo, descubrirás los conflictos de fusión de cada confirmación una por una, en lugar de tener que resolverlos todos con una confirmación de fusión masiva. Además, esto hace que tus confirmaciones mantengan un enfoque lo más claro posible, y hace que el historial del proyecto esté limpio. A su vez, también hace que resulte mucho más sencillo descubrir qué errores se han introducido y, si fuera necesario, revertir cambios con un impacto mínimo sobre el proyecto.

Si Mary y John trabajan en funciones que no están relacionadas, es poco probable que el proceso de reorganización genere conflictos. No obstante, si así fuera, Git pausará la reorganización en la confirmación actual y mostrará el siguiente mensaje, además de algunas instrucciones importantes:

CONFLICT (content): Merge conflict in <some-file>

Lo bueno de Git es que cualquiera puede resolver sus propios conflictos de fusión. En nuestro ejemplo, Mary solo tendría que ejecutar un comando git status para ver dónde está el problema. Los archivos en conflicto se mostrarán en la sección "Unmerged paths":

# Unmerged paths:
# (use "git reset HEAD <some-file>..." to unstage)
# (use "git add/rm <some-file>..." as appropriate to mark resolution)
#
# both modified: <some-file>

A continuación, editará los archivos según estime oportuno. Cuando esté contenta con el resultado, podrá preparar los archivos según el método habitual y dejar que git rebase se encargue del resto:

git add <some-file>
git rebase --continue

Y esto es todo lo que hay que hacer. Git continuará con la siguiente confirmación y repetirá el proceso con cualquier otra confirmación que genere conflictos.

Si llegas a este punto y te das cuenta de que no tienes ni idea de lo que está pasando, no entres en pánico. Solo tienes que ejecutar el siguiente comando y volverás al punto de inicio:

Mary publica correctamente su función

Después de terminar con la sincronización del repositorio central, Mary podrá publicar los cambios correctamente:

Hacia dónde ir

Como puedes ver, es posible replicar un entorno de desarrollo de Subversion tradicional con solo unos comandos de Git. Este método es perfecto para los equipos que están migrando de SVN, pero no le sacan partido a la naturaleza distribuida de Git.

El flujo de trabajo centralizado es estupendo para equipos pequeños. El proceso de resolución de conflictos explicado anteriormente puede provocar un cuello de botella a medida que tu equipo escale su tamaño. Si tu equipo se siente cómodo con el flujo de trabajo centralizado, pero quiere perfeccionar la colaboración, merece la pena analizar las ventajas del flujo de trabajo de ramas de función. Al dedicar una rama aislada a cada función, se pueden iniciar conversaciones en profundidad acerca de nuevas adiciones antes de integrarlas en el proyecto oficial.

Directrices

No existe un flujo de trabajo de Git universal. Como se ha indicado anteriormente, es muy importante desarrollar un flujo de trabajo de Git que suponga una mejora productiva para tu equipo. Además de la cultura del equipo, el flujo de trabajo debe complementar la cultura empresarial. Las funciones de Git, como las ramas y las etiquetas, deben complementar la planificación de publicación de tu empresa. Si tu equipo usa algún software de gestión de proyectos con seguimiento de tareas, quizá te interese usar ramas que se correspondan con las tareas en curso. Además, aquí presentamos algunas directrices que se deben tener en cuenta a la hora de decantarse por un flujo de trabajo:

Ramas transitorias

Cuanto más tiempo se desarrolle una rama de forma independiente a la rama de producción, mayor será el riesgo de que surjan conflictos de fusión y retos de implementación. Las ramas transitorias proporcionan fusiones e implementaciones más limpias.

Minimización y simplificación de reversiones

Es importante disponer de un flujo de trabajo que ayude de forma proactiva a evitar fusiones que se tengan que revertir. Un ejemplo de esto son los flujos de trabajo que realizan pruebas en las ramas antes de fusionarlas con la rama main. No obstante, es natural que se produzcan accidentes. Con esto en mente, conviene tener un flujo de trabajo que permita realizar reversiones sencillas que no interrumpan el flujo del resto de los miembros del equipo.

Cumplimiento de una planificación de publicación

Los flujos de trabajo deben complementar tu ciclo de publicación de desarrollo de software empresarial. Si tienes pensado realizar varias publicaciones al día, querrás que tu rama main se mantenga estable. Si tu planificación de publicación es mucho menos frecuente, quizá te convenga plantearte la opción de usar etiquetas de Git para asignar una rama a una versión.

# data[].attributes.attachment_link.title
Flujo de trabajo de Git | Atlassian Git Tutorial

# data[].attributes.attachment_link.description
Una rama de función de Git es una rama temporal que se utiliza con fines de desarrollo o pruebas. ¡Conoce la mejor manera de gestionarlas con esta guía!

# data[].attributes.body
Configuración de Ubuntu Server en Hyper-V

# data[].attributes.attachment_link.title
How to enable Hyper-V Linux Integration Service in Ubuntu 22.04 and 24.04? - Microsoft Q&A

# data[].attributes.attachment_link.description
Hello Experts,
I need to enable integration services in the Ubuntu 22.04 and 24.04 VM.
I found this document (https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/manage-hyper-v-integration-services) to enable Hyper-V…

# data[].attributes.body
Creación de Ubuntu Server VM en Proxmox con mejores prácticas

# data[].attributes.attachment_link.title
Proxmox Home Lab - Creating a Ubuntu Server VM with Best Pratices

# data[].attributes.body
Guía paso a paso para instalar Ubuntu Server en Hyper-V

# data[].attributes.attachment_link.title
Ubuntu Server Installation on Hyper-V | Step-by-Step Guide

# data[].attributes.body
Comparativa para entornos de virtualización en proyectos educativos

# data[].attributes.attachment_link.title
How to Install Ubuntu 20.04 Virtual Machine on Hyper-V Server

# data[].attributes.attachment_link.description
How to Install Ubuntu 20.04 Virtual Machine on Hyper-V Server. Today, hypervisors are more ubiquitous than ever, allowing you to run an operating system