Skip to content

Gecoscc:desarrollo

Jump to bottom
Alfonso E.M edited this page Jul 11, 2018 · 2 revisions

Manual del desarrollador del Centro de Control

1. Repositorios de Código

Los repositorios de desarrollo se encuentran en Github.

1.1 Interfaz de usuarios y sincronizadores (GCC)

Repositorio Descripción Tag
gecoscc-ui Interfaz de usuario del GCC 2.1.8
gecos-ad-sync Sincronizador de Directorio Activo con GCC 0.2.0
gecos-ldap-sync Sincronizador de LDAP con GCC 0.1.0

1.2 Instalador y cookbooks (GCC)

Repositorio Descripción Tag
gecoscc-chef-server-repo Repositorio con todos los componentes necesarios para instalar un GCC 0.7.0
cookbook-gecosccui Cookbook de instalación de la interfaz de usuario GCC 0.7.0
gecoscc-chef-server-cookbook Cookbook de instalación del servidor de chef 0.1.1
gecos-workstation-management-cookbook Cookbook para administrar puestos. Configuraciones de red, escritorio, repositorios, etc 0.3.9
gecos-workstation-ohai-cookbook Cookbook para obtener los datos de un puesto: RAM, CPU, distribución, etc 1.9.5

1.3 Paquetes de asistentes

Repositorio Descripción Tag
gecosws-config-assistant Paquete que contiene el asistente para vincular un puesto gecos a un centro de control 0.8.0-0gecos4
gecosws-firstart Paquete que contiene el asistente de primer arranque 0.10-0gecos1
gecosws-chef-snitch Paquete que contiene el demonio de actualizaciones automáticas 1.0gecos15trusty23

1.4 Paquetes distro

Repositorio Descripción Tag
gecosws-meta Paquete que contiene todas las dependencias para instalar un sistema gecos completo 2.0gecos58trusty72
gecosws-light-meta Paquete que contiene todas las dependencias para instalar un sistema gecos lite completo 2.0gecos36trusty44
gecosws-system-conf Paquete que contiene las configuraciones del sistema 2.0gecos7trusty9
java-nss-fix Paquete que soluciona un error de NSS de Java 2.0gecos1trusty4
gecosws-mdm-theme Paquete que contiene el tema de MDM 2.0gecos11trusty4
gecosws-skel-conf Paquete que contiene el esqueleto del home de un usuario 2.0gecos12trusty13
gecosws-xdg-ruby Paquete que contiene la gema xdg de ruby 2.0gecos10trusty10
gecosws-ubiquity Paquete que contiene personalizaciones del instalador (ubiquity) del SO 1.0gecos8trusty8
gecosws-cinnamon-conf Paquete que contiene las personalizaciones realizadas al escritorio cinnamon 2.0gecos10trusty24
gecosws-light-artwork Paquete que contiene las personalizaciones de artwork de la versión lite 2.0gecos31trusty29
gecosws-mint-artwork-cinnamon-conf Paquete que contiene las personalizaciones de artwork para el escritorio cinnamon 2.0gecos17trusty20
gecosws-light-lxde-common-conf Paquete que contiene las personalizaciones del escritorio lxde (versión lite) 2.0gecos3trusty2
gecosws-mint-artwork-common-conf Paquete que contiene modificaciones del artwork de Linux Mint 2.0gecos6trusty6
gecosws-icon-theme Paquete que contiene el tema de iconos 2.0gecos7trusty9
gecosws-mint-x-icons-conf Paquete que contiene las personalizaciones del paquete mint-x-icons 2.0gecos4trusty4

2. La interfaz web

Tras una petición de creación, modificación o borrado de un conjunto de objectos, por cada uno de ellos, el GCC-UI hará lo siguiente:

- Backend
    - Escribir en mongo (insert, update o delete)
        - Mandar invalidaciones (websockets activados)
    - Devolver conexión al front-end
- Celery
    - Identificar máquinas afectadas
    - Por cada una de las máquinas afectadas:
        - Pedir nodo (json) al servidor de Chef
        - Actualizar el nodo con los cambios
            - Por cada cambio crear una tarea
        - Guardar el nodo en el servidor de Chef
        - Actualizar tareas automáticamente
- Backend
    - Recibir Callback de que cada una de las máquinas actualizadas. Por cada uno de las tareas creadas anteriormente habrá un informe que establezca si la tarea se ha ejecutado correctamente o ha habido algún error.
        - Actualizar estado de las tareas
        - Actualizar tareas en la UI (websockets activados)
    - Devolver conexión al puesto

2.1 Frameworks

Framework Uso
Pyramid Framework Python usado para back-end del centro de control: CRUD, gestión de usuarios, informes, etc
Celery Framework Python usado para comunicar el back-end del centro de control con el servidor Chef
Backbonejs Framework JS usado para front-end del centro de control para crear las vistas y modelos
Marionettejs Framework JS usado para front-end del centro de control como extensión de backbone, envolviendo este último
Bootstrap 3 Framework CSS usado para front-end del centro de control para estilos, modales, etc

2.2 Lenguajes

Lenguaje Uso
Python Usado en el back-end y en celery
JavaScript Usado en el front-end

2.3 Esquema de permisos. Visibilidad.

Ver en Visibilidad de los elementos

2.4 Modificaciones y ampliaciones: Informes.

Todo lo relacionado a los informes se encuentran en el archivo reports

Ver más en Informes

2.5 Internacionalización

Lo primero que tenemos que hacer antes de empezar a traducir es identificar si nuestra cadena es un literal proveniente de los catálogos de traducciones de la UI, un literal de una política emisora, o un literal de una política (no emisora)

2.5.1 Internacionalización de literales de GCC-UI

Para las i18n en el GCC-UI usamos Gettext, el cual crea catálogos //.po//

En nuestro sistema tenemos dos catálogos con lo que el literal que queramos traducir debe de estar en uno de ellos (o en los dos):

Una vez encontrado solo tendremos que cambiar el //msgstr// asociado y ejecutar el comando compilemessages

./compilemessages.sh

Si hemos añadido un nuevo literal a nuestro GCC, por ejemplo porque hayamos creado una nueva página, deberemos ejecutar el comando makemessages:

./makemessages.sh

Y tras esto volver a realizar el proceso anterior: buscar el literal en los catálogos, rellenar el //msgstr// asociado y ejecutar el comando compilemessages

2.5.2 Internacionalización de las políticas

La i18n de las políticas al igual que su esquema viene en el metadata, en los campos title, title_es, description y description_es.

Lo óptimo es cambiar estas cadenas en este archivo, subirlas al Chef Server y luego importarlas al centro de control, Ver el apartado de Políticas y Recetas.

2.5.3 Internacionalización de las políticas emisoras (y perfil de software)

Hay cuatro políticas especiales: Impresoras disponibles, Repositorios disponibles, Almacenamientos disponibles y Perfiles de Software disponibles.

px

En las políticas emisoras se seleccionan nodos del árbol (impresoras, repositorios y almacenamientos), pero después en Chef se guardan los datos de estos, con lo que los literales que se muestran en estas políticas son totalmente diferentes a los que podemos encontrar en el metadata.

Con la política de Perfiles de Software disponibles, pasa exactamente igual. Aunque no utilice nodos del árbol, se seleccionan perfiles y después en Chef se guarda una lista de paquetes.

Con lo que lo más sencillo si queremos cambiar un literal es cambiarlo directamente en el importador de políticas y ejecutar después una importación ([Ver más](https://github.com/gecos-team/gecos-doc/wiki/Instalaci%C3%B3n_GECOSCC#Importación de políticas)):

$GECOSCC_HOME/bin/pmanage $GECOSCC_HOME/gecoscc.ini import_policies -a admin -k /etc/chef-server/admin.pem

3. Políticas y Recetas

El sistema de GECOS se basa en Chef para poder aplicar remotamente las políticas. Chef es un sistema de gestión de configuraciones que permite aplicar configuraciones a distintos clientes de manera remota, éste está escrito en el lenguaje de programación Ruby.

Para saber más de Chef es muy aconsejable leer la documentación que aporta Opscode, donde explican ampliamente su uso.

En GECOS cuando tratamos una política esta se ve reflejada en Chef como un recurso, a continuación veremos esto de forma más extendida y cómo funciona.

3.1 Esquema del cookbook gecos_ws_mgmt

En nuestro caso concreto de GECOS, tenemos por detrás un único recetario (cookbook) el cual contendrá toda la inforamción de todas las políticas, éste se llama gecos_ws_mgmt.

La estructura de un cookbok es la siguiente:

  • files
    • Esta carpeta contendrá los ficheros estáticos que cada política usará para dejar finalmente en el puesto
  • templates
    • Esta carpeta contendrá los ficheros dinámicos que cada política usará para dejar finalmente en el puesto
  • resources
    • Esta carpeta contendrá la definición de cada uno de las políticas
  • attributes
    • Esta carpeta contendrá los atributos por defecto que tiene que usar cada una de las políticas
  • recipes
    • Esta carpeta contendrá las recetas, que son la ejecución de las políticas agrupadas y siguiendo un orden
  • providers
    • Esta carpeta contendrá la programación de cada una de las políticas
  • metadata.rb
    • Este fichero contendrá la definición de la política para que GECOS CC sea capaz de pintar el formulario con los datos pertinentes, para ésta escribir éstas definiciones usamos JSON Schema

3.2 Creación de una nueva política

Para crear una política tenemos que crear un recurso de Chef, para ello es necesario crear y modificar varios ficheros.

3.2.1 Recurso

Lo primero que haremos es crear el recurso, para ello creamos en la carpeta resources el fichero con el nombre de nuestra política, por ejemplo tz_date.rb, en esta tenemos que definir los atributos que usará nuestra política, así como unos atributos necesarios para el funcionamiento correcto con el Centro de Control.

Además de los atributos también es necesario definir las acciones que podemos tener en nuestra política, en el caso de GECOS siempre tendremos una única acción llamada setup

<code ruby resources/tz_date.rb>

actions :setup

attribute :server, :kind_of => String attribute :job_ids, :kind_of => Array attribute :support_os, :kind_of => Array

Los atributos necesarios para el funcionamiento correcto y que deben de ir en todas las políticas son:

  • job_ids: Este atributo es usado por las políticas y el Centro de Control para realizar la comunicación de si la ejecución a sido satisfactoria o no
  • support_os: Este atributo se usa para ejecutar o no la política en el puesto dependiendo de si su sistema operativo esta soportado o no, ésto se indicará más adelante en los atributos por defecto del cookbook

3.2.2 Proveedor

En este caso también tenemos que generar el proveedor, que es el fichero que contendrá el código de ejecución de nuestra política.

Hay que tener en cuenta que para el caso concreto de GECOS es necesario tener una estructura común para todos los providers de políticas, ésta estructura es la siguiente:

<code ruby provider/new_policy.rb> action :setup do begin os = lsb_release -d.split(":")[1].chomp().lstrip() if new_resource.support_os.include?(os)

#Código de la política

else
  Chef::Log.info("This resource is not support into your OS")
end

# Comunicación de que la política se ha ejecutado correctamente
job_ids = new_resource.job_ids
job_ids.each do |jid|
  node.set['job_status'][jid]['status'] = 0
end

rescue Exception => e Chef::Log.error(e.message) # Comunicación de que la política se ha ejecutado dando error job_ids = new_resource.job_ids job_ids.each do |jid| node.set['job_status'][jid]['status'] = 1 if not e.message.frozen? node.set['job_status'][jid]['message'] = e.message.force_encoding("utf-8") else node.set['job_status'][jid]['message'] = e.message end end ensure # Borrado de los jobids gecos_ws_mgmt_jobids "new_policy_res" do provider "gecos_ws_mgmt_jobids" recipe "policy_recipe" end.run_action(:reset) end end

Esta estructura está determinada por un bloque begin..rescue..ensure donde tratamos cualquier error producido, con esto evitamos que la ejecución de las políticas que vienen a posterior no se vean frenadas por el error.

Además al principio de la política comprobamos que se totalmente compatible con el sistema operativo donde se está ejecutando.

Con ésto el código de nuestra política de ejemplo sería

<code ruby providers/tz_date.rb>

action :setup do begin os = lsb_release -d.split(":")[1].chomp().lstrip() if new_resource.support_os.include?(os) package 'ntpdate' do action :nothing end.run_action(:install)

  ntp_server = new_resource.server

  unless ntp_server.nil? or ntp_server.empty?
    execute "ntpdate" do
      command "ntpdate-debian -u #{ntp_server}"
      action :nothing
    end.run_action(:run)
    template '/etc/default/ntpdate' do
      action :nothing
      source 'ntpdate.erb'
      owner 'root'
      group 'root'
      mode 00644
      variables ({
        :ntp_server => new_resource.server
      })
    end.run_action(:create)
  end
else
  Chef::Log.info("This resource is not support into your OS")
end


job_ids = new_resource.job_ids
job_ids.each do |jid|
  node.set['job_status'][jid]['status'] = 0
end

rescue Exception => e Chef::Log.error(e.message) job_ids = new_resource.job_ids job_ids.each do |jid| node.set['job_status'][jid]['status'] = 1 if not e.message.frozen? node.set['job_status'][jid]['message'] = e.message.force_encoding("utf-8") else node.set['job_status'][jid]['message'] = e.message end end ensure gecos_ws_mgmt_jobids "tz_date_res" do provider "gecos_ws_mgmt_jobids" recipe "misc_mgmt" end.run_action(:reset) end end

Almacenando ésta en providers/tz_date.rb

3.2.3 Atributos

Es necesario definir los valores de los atributos por defecto, para ello es necesario editar el fichero attributes/default.rb, el cual tiene todos los valores por defecto de todas las politicas.

<code ruby attributes/default.rb>

default[:gecos_ws_mgmt][:misc_mgmt][:tz_date_res][:server] = "" default[:gecos_ws_mgmt][:misc_mgmt][:tz_date_res][:job_ids] = [] default[:gecos_ws_mgmt][:misc_mgmt][:tz_date_res][:updated_by] = {} default[:gecos_ws_mgmt][:misc_mgmt][:tz_date_res][:support_os] = ["GECOS V2", "Gecos V2 Lite"]

  • gecos_ws_mgmt: Es el nombre del cookbook
  • misc_mgmt: Es el nombre de la receta donde se ejecuta la política
  • tz_date_res: Es el nombre de la política, siempre se le añade _res

3.2.4 Receta

Debemos añadir nuestra nueva política a la receta que corresponda, para ello debemos editar la receta guardada en recipes, para nuestro caso concreto es la receta misc_mgmt.rb

<code ruby recipes/misc_mgmt.rb> gecos_ws_mgmt_tz_date 'localtime' do server node[:gecos_ws_mgmt][:misc_mgmt][:tz_date_res][:server] job_ids node[:gecos_ws_mgmt][:misc_mgmt][:tz_date_res][:job_ids] support_os node[:gecos_ws_mgmt][:misc_mgmt][:tz_date_res][:support_os] action :setup end

Tenemos que añadirla de ésta forma, el bloque de código siempre empieza con el nombre del cookbook seguido del nombre de la política, después un texto donde indicaremos nombre descriptivo de dicha política.

Dentro del bloque irán definidos los atributos y su valor, así como la acción que vamos a ejecutar de la política (recordar que como indicamos anteriormente siempre será :setup)

3.2.5 Metadata

Para finalizar, es necesario crear un esquema de la receta en el metadata.rb para que el Centro de Control sea capaz de enterarse que existe una nueva política

Todo esquema se almacena en una variable con el nombre de la política más _js, en este caso el esquema de la política que tenemos de ejemplo sería

tz_date_js = { title: "Administration Date/Time", title_es: "Administración fecha/hora", type: "object", required: ["server"], properties: { server: { type: "string", title: "Server NTP", title_es: "Servidor NTP", description: "Enter the URI of an NTP server", description_es: "Introduzca la URI de un servidor NTP" }, support_os: support_os_js.clone, job_ids: { type: "array", minItems: 0, uniqueItems: true, items: { type: "string" } }, updated_by: updated_js } }

Todo esquema es necesario que tenga los atributos support_os, job_ids y update_by en el apartado #metadatos|Metadata se explicará más a fondo ésto.

Además debemos indicarle al Centro de Control que SO son soportados, para ello tenemos que añadir la siguiente línea tz_date_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"]

Para finalizar el metadata contiene todas las recetas y que recursos ejecuta cada una, con lo cual nuestro recurso es necesario ponerlo en la receta concreta, en este caso es la receta ‘’misc_mgmt’’

....

} }, misc_mgmt: { type: "object", required: ["tz_date_res", "scripts_launch_res", "local_users_res", "local_groups_res", "local_file_res", "local_admin_users_res", "auto_updates_res","power_conf_res","remote_shutdown_res","cert_res"], properties: { tz_date_res: tz_date_js, scripts_launch_res: scripts_launch_js, local_users_res: local_users_js, ....

3.2 Nomenclatura

En este apartado explicaremos un poco la nomenclatura típica que usamos en GECOS.

  • Todas las recetas finalizarán con ‘’_mgmt’’
  • Todos los recursos finalizarán con ‘’_res’’

3.3 Recetas en Chef

Poemos ver la relación completa de recetas de Chef que hemos diseñado para GECOS en esta página:

https://github.com/gecos-team/gecos-doc/wiki/Politicas:indice

Aparte de éstas también tenemos las siguientes recetas:

  • default: Receta que se encarga de importar las demás recetas
  • local: Receta encargada de ejecutar recurso para configurar la vinculación del puesto contra el Centro de Control

3.4 Metadatos

El metadata.rb es una parte muy importante del proyecto ya que es la forma que tiene el Centro de Control de saber que políticas hay y cómo son éstas.

Para definir cada una de las políticas usamos http://json-schema.org/|JSON Schema.

El metadata contiene lo siguiente:

... attribute 'json_schema', :display_name => "json-schema", :description => "Special attribute to include json-schema for defining cookbook's input", :type => "hash", :object => complete_js

Donde describimos un poco el atributo que leerá el Centro de control, y definimos la variable complete_js como la estructura del JSON Schema con toda la información de todas las políticas.

... complete_js = { description: "GECOS workstation management LWRPs json-schema", description_es: "Estación de trabajo de gestión GECOS LWRPs json-schema", id: "http://gecos-server/cookbooks/#{name}/#{version}/network-schema#", required: ["gecos_ws_mgmt"], type: "object", properties: { gecos_ws_mgmt: { type: "object", required: ["network_mgmt","software_mgmt", "printers_mgmt", "misc_mgmt", "users_mgmt"], properties: { network_mgmt: { type: "object", required: ["network_res","forticlientvpn_res","mobile_broadband_res"], properties: { network_res: network_resource_js, forticlientvpn_res: forticlientvpn_js, mobile_broadband_res: mobile_broadband_js #sssd_res: sssd_js } }, misc_mgmt: { type: "object", required: ["tz_date_res", "scripts_launch_res", "local_users_res", "local_groups_res", "local_file_res", "local_admin_users_res", "auto_updates_res","power_conf_res","remote_shutdown_res","cert_res"], properties: { tz_date_res: tz_date_js, scripts_launch_res: scripts_launch_js, local_users_res: local_users_js, local_file_res: local_file_js, auto_updates_res: auto_updates_js, local_groups_res: local_groups_js, power_conf_res: power_conf_js, local_admin_users_res: local_admin_users_js, remote_shutdown_res: remote_shutdown_js, cert_res: cert_js } }, software_mgmt: { type: "object", required: ["software_sources_res","package_res", "app_config_res","package_profile_res"], properties: { software_sources_res: software_sources_js, package_res: package_js, package_profile_res: package_profile_js, app_config_res: app_config_js } }, printers_mgmt: { type: "object", required: ["printers_res"], properties: { printers_res: printers_js } }, users_mgmt: { type: "object", required: ["user_apps_autostart_res", "user_shared_folders_res", "web_browser_res", "email_client_res", "file_browser_res", "user_launchers_res", "desktop_menu_res", "desktop_control_res", "folder_sharing_res", "screensaver_res","folder_sync_res", "user_mount_res","shutdown_options_res","desktop_background_res","user_alerts_res"], properties: { user_shared_folders_res: user_shared_folders_js, web_browser_res: web_browser_js, email_client_res: email_client_js, file_browser_res: file_browser_js, user_alerts_res: user_alerts_js, user_launchers_res: user_launchers_js, desktop_background_res: desktop_background_js, desktop_menu_res: desktop_menu_js, desktop_control_res: desktop_control_js, user_apps_autostart_res: user_apps_autostart_js, folder_sharing_res: folder_sharing_js, screensaver_res: screensaver_js, folder_sync_res: folder_sync_js, user_mount_res: user_mount_js, user_modify_nm_res: user_modify_nm_js, shutdown_options_res: shutdown_options_js } } } } } }

...

Donde definiremos cada una de las recetas y los recursos que ejecuta cada una de ellas.

Por otro lado tenemos una lista del atributo support_os para cada una de las políticas, de la siguiente forma

...

network_resource_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] tz_date_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] scripts_launch_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] local_users_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] local_file_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] auto_updates_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] local_groups_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] power_conf_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] local_admin_users_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] software_sources_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] package_js[:properties][:support_os][:default]=["GECOS V2","Ubuntu 14.04.1 LTS","Gecos V2 Lite"] package_profile_js[:properties][:support_os][:default]=["GECOS V2","Ubuntu 14.04.1 LTS","Gecos V2 Lite"] app_config_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] printers_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] user_shared_folders_js[:properties][:support_os][:default]=["GECOS V2"] web_browser_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] email_client_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] file_browser_js[:properties][:support_os][:default]=["GECOS V2"] user_launchers_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] desktop_background_js[:properties][:support_os][:default]=["GECOS V2"] desktop_menu_js[:properties][:support_os][:default]=[] desktop_control_js[:properties][:support_os][:default]=[] user_apps_autostart_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] folder_sharing_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] screensaver_js[:properties][:support_os][:default]=["GECOS V2"] folder_sync_js[:properties][:support_os][:default]=["GECOS V2"] user_mount_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] user_alerts_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] remote_shutdown_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] forticlientvpn_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] user_modify_nm_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] shutdown_options_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] cert_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"] mobile_broadband_js[:properties][:support_os][:default]=["GECOS V2","Gecos V2 Lite"]

...

Como todas las políticas deben de llevar unos atributos obligatorios que son necesarios para poder funcionar y comunicarse correctamente con el Centro de Control, por eso definimos dos variables con los trozos de JSON Schema necesarios para éstos atributos

... updated_js = { title: "Updated by", title_es: "Actualizado por", type: "object", properties: { group: {title: "Groups", title_es: "Grupos", type: "array", items: {type:"string"}} , user: {type:"string"}, computer: {type:"string"}, ou: {title: "Ous", title_es: "Ous", type: "array", items: {type:"string"}}

} }

support_os_js = { title: "Support OS", title_es: "Sistemas operativos compatibles", type: "array", minItems: 0, uniqueItems: true, items: { type: "string" }

} ...

support_os_js es una variable que se encarga de definir el atributo de los sistemas operativos compatibles update_js es una variable usada por el Centro de Control de manera interna

Un punto importante a tener en cuenta es que cuando es una política de usuarios hay que tener un esquema especifico que será de la siguiente manera

user_mount_js = { title: "User mount external units", title_es: "Montaje de unidades externas", type: "object", required: ["users"], properties: { users: { title: "Users", title_es: "Usuarios", type: "object", patternProperties: { ".*" => { type: "object", title: "Username", title_es: "Nombre de usuario", required: ["can_mount"], properties: { can_mount: {type: "boolean", title: "Can Mount?", title_es: "¿Puede montar?", description: "User can mount external units", description_es: "El usuario podra montar unidades externas"}, updated_by: updated_js } } } }, support_os: support_os_js.clone, job_ids: { type: "array", minItems: 0, uniqueItems: true, items: { type: "string" } } } }

Todas las políticas de usuarios tendrán una propiedad users que ha su vez se ha de definir como un objeto cuya clave es variable, de ahí que tengamos que añadir el literal patternPropoerties

3.5 Importación

Ver en [Importación de políticas](https://github.com/gecos-team/gecos-doc/wiki/Instalaci%C3%B3n_GECOSCC#Importación de políticas)

3.6 Depuración

Para depurar código de ejecución de Chef en GECOS, no es posible realizar puntos de ruptura con lo cual debemos de depurar mediante la impresión en logs de los datos necesarios.

Para ello dentro del proveedor concreto deberemos de insertar el siguiente código Chef::Log.error(variable o "texto")

Una vez realizados estos cambios es necesario que el cookbook sea de nuevo subido al servidor Chef mediante knife

Tras esto, en el puesto podremos ver los valores de dichas variables en el log de Chef.

También es importante tener en cuenta que los datos estén guardados en el nodo en el servidor de Chef, para ello es necesario abrir la webui de Chef e inspeccionar el nodo concreto.

3.7 Cambios de esquema

Los cambios en los esquemas implican tener en cuenta ciertas cosas, para ello las numeraremos a continuación.

  • Añadir atributo nuevo: Añadir un atributo nuevo a una política en su esquema implica que es necesario realizar una importación de las políticas para el el Centro de Control tenga en cuenta éste nuevo atributo. También es necesario implementar la política de forma que mantenga coherencia con los datos antiguos ya que éstos no tendrán este atributo nuevo.
  • Eliminar atributos: Simplemente es necesario realizar una importación de las políticas
  • Creación de una nueva política: Cuando se genera una nueva política es necesario realizar una importación de las políticas y además de esto ejecutar en los puesto una sincronización contra el Centro de Control, de no ser así el Centro de Control dará error a la hora de almacenar los datos de la política para éstos puestos.
  • Eliminación de una política: Simplemente es necesario realizar una importación de las políticas
  • Creación de una nueva receta: La implicación es la misma que la de realizar una nueva política

4. Sincronizadores con sistemas anteriores

Hay dos sincronizadores realizados: uno para Directorio Activo y otro para LDAP. Estos sincronizadores pueden ejecutarse tanto para cargar datos de estos sistemas anteriores al GCC, como del GCC a estos.

Es recomendable ejecutar estos sincronizadores en modo mantenimiento, dado que estos pueden sobrecargar mucho el servidor.

4.1 Directorio activo

4.1.1 De AD a GCC

Para exportar los nodos de un AD al GCC editamos el comando ad-export

Parametros Descripción
$GecosCCAPIUrl URL de la API del centro de control que recibe un zip con todo el árbol del AD
$GecosCCAPIUsername Nombre de usuario de un administrador en el GCC
$GecosCCAPIPassword Contraseña del administrador anterior puesto
$GecosCCAPIDomainId Id del dominio donde importar los datos
$GecosCCAPIMaster Indica quien es el sistema que va a mandar tras la importación
$SystemType Indica el sistema del cual se ha importado. Es un prefijo.
.\ad-export.ps1

Para exportar las políticas de un AD al GCC editamos el comando gpo-export

Parametros Descripción
$GecosCCAPIUrl URL de la API del centro de control que recibe un zip con todo el árbol del AD
$GecosCCAPIUsername Nombre de usuario de un administrador en el GCC
$GecosCCAPIPassword Contraseña del administrador anterior puesto
$GecosCCAPIDomainId Id del dominio donde importar los datos
$GecosCCAPIMasterPolicies Indica que políticas solo van a ser en modo lectura en el GCC
.\gpo-export.ps1

Las políticas que ahora mismo es capaz de convertir el GCC son las siguientes:

4.1.2 De GCC a AD

Para importar los nodos del GCC a un AD editamos el comando mongo2AD

Parametros Descripción
mongo_id_root Id del dominio desde donde importar los datos
mongo_host Host donde se encuentra el mongodb
mongo_db Nombre de la base de datos mongo
mongo_port Puerto de la base mongo
data_types Tipos de datos a importar
ldap_host Host del AD (habla LDAP)
ldap_port Puerto donde el AD habla LDAP
ldap_auth Usuario para autenticarnos en el AD
ldap_pw Contraseña del usuario anterior
ldap_treebase Base del AD

Instalamos dependencias:

bundle

Y ejecutamos el comando:

ruby mongo2AD.rb # 4.2 LDAP #

4.2.1 De LDAP a GCC

Para exportar los nodos de un LDAP al GCC podemos editar el comando export_ldap

Parametros Descripción
GECOSCC_API_URL URL de la API del centro de control que recibe un zip con todo el árbol del LDAP
GECOSCC_API_USERNAME Nombre de usuario de un administrador en el GCC
GECOSCC_API_PASSWORD Contraseña del administrador anterior puesto
GECOSCC_API_DOMAIN_ID Id del dominio donde importar los datos
GECOSCC_API_MASTER Indica quien es el sistema que va a mandar tras la importación
SYSTEM_TYPE Indica el sistema del cual se ha importado. Es un prefijo.
LDAP_SERVER_EMG Indica donde se encuentra el LDAP
BIND_DN Indica el bind dn del LDAP para autenticarse.
BIND_PASS Indica la contraseña del bind dn anterior
BASE_DN Indica el base dn
SEARCH_SCOPE Indica el ambito de búsqueda

Instalamos dependencias:

easy_install requests==2.5.0 easy_install python-ldap==2.4.18 python export_ldap.py

O podemos instalar el paquete python:

python setup.py install

Y tras esto invocar al comando:

export_ldap -l ldap://localhost:389 -p 1234 -g http://localhost/api/ad_import/ -i 5491381100251c0e08621114 -u admin -w admin -m
Parametros Descripción
GECOSCC_API_URL URL de la API del centro de control que recibe un zip con todo el árbol del LDAP
-u o --gecoscc-username Nombre de usuario de un administrador en el GCC
-w o --gecoscc-password Contraseña del administrador anterior puesto
-i o --gecoscc-domain-id Id del dominio donde importar los datos
-m o --gecoscc-master Indica quien es el sistema que va a mandar tras la importación
-t o --system-type Indica el sistema del cual se ha importado. Es un prefijo.
-l o --ldap-url Indica donde se encuentra el LDAP
-d o --ldap-bind-dn Indica el bind dn del LDAP para autenticarse.
-p o --ldap-bind-pass Indica la contraseña del bind dn anterior
-b o --ldap-base-dn Indica el base dn
-s o --ldap-search-scope Indica el ambito de búsqueda

4.2.2 De GCC a LDAP

Para importar los nodos del GCC a un LDAP editamos el comando mongo2AD

Parametros Descripción
mongo_id_root Id del dominio desde donde importar los datos
mongo_host Host donde se encuentra el mongodb
mongo_db Nombre de la base de datos mongo
mongo_port Puerto de la base mongo
data_types Tipos de datos a importar
ldap_host Host del LDAP
ldap_port Puerto donde el LDAP
ldap_auth Usuario para autenticarnos en el LDAP
ldap_pw Contraseña del usuario anterior
ldap_treebase Base del LDAP

Instalamos dependencias:

bundle

Y ejecutamos el comando:

ruby mongo2ldap.rb

5. Comandos de testing

Hemos desarrollado tres comandos los cuales nos pueden servir para comprobar que el GCC funciona correctamente.

Nota: para facilitar las siguientes acciones guarde la ruta a su instalación de gecoscc-ui en la variable de entorno GECOSCC_HOME. Ejecute el comando export GECOSCC_HOME=/opt/gecosccui-2.X.X indicando su versión de gecoscc-ui.

5.1 Creación de N-nodos

Con este comando podremos crear en el GCC-UI y en Chef una cantidad grande de nodos de manera muy sencilla y rápida.

El comando hace una copia de un puesto de trabajo ya creado en el GCC tantas veces como indiquemos. Además por cada uno de los puestos se crearan y vincularán dos usuarios.

$GECOSCC_HOME/bin/pmanage $GECOSCC_HOME/gecoscc.ini create_nodes -n 10 -c 54900adc00251c18edb8464d -o 5492a5df00251c18b0fd76c8 -s admin -p admin -u http://localhost -r prefix1
Parámetro Descripción
-n o --number Número de nodos a crear
-c --copy-computer-id Id del nodo a copiar. Este debe de estar recién vinculado, sin políticas
-o o --organisational-unit-id Id de la unidad organiza donde se van a crear
-s o --gecoscc-username Nombre de usuario de un administrador superusuario en el GCC
-p o --gecoscc-password Contraseña del administrador anterior puesto
-u o --gecoscc-url URL del GCC-UI (sin / al final)
-r o --prefix Prefijo de los nuevos nodos

5.2 Test política de puesto

Este comando añade la política de paquetes a una unidad organizativa y comprueba que todos sus estaciones hijas la tienen puesta en Chef. No tiene en cuenta prioridad de políticas.

$GECOSCC_HOME/bin/pmanage $GECOSCC_HOME/gecoscc.ini test_add_policy_package_to_ou -o 5492a5df00251c18b0fd76c8 -s useremergya2 -p useremergya2 -u http://localhost test_add_policy_package_to_ou
Parámetro Descripción
-o o --organisational-unit-id Id de la unidad organiza donde se van a crear
-s o --gecoscc-username Nombre de usuario de un administrador superusuario en el GCC
-p o --gecoscc-password Contraseña del administrador anterior puesto
-u o --gecoscc-url URL del GCC-UI (sin / al final)

5.3 Test política de usuario

Este comando añade la política de permisos para compartir a una unidad organizativa y comprueba que todos sus usuarios hijos (vinculados a un puesto) la tienen puesta en Chef. No tiene en cuenta prioridad de políticas.

$GECOSCC_HOME/bin/pmanage $GECOSCC_HOME/gecoscc.ini test_add_policy_sharing_permission_to_ou -o 5492a5df00251c18b0fd76c8 -s useremergya2 -p useremergya2 -u http://localhost test_add_policy_package_to_ou
Parámetro Descripción
-o o --organisational-unit-id Id de la unidad organiza donde se van a crear
-s o --gecoscc-username Nombre de usuario de un administrador superusuario en el GCC
-p o --gecoscc-password Contraseña del administrador anterior puesto
-u o --gecoscc-url URL del GCC-UI (sin / al final)
Clone this wiki locally