Guifi.net - Wiki Hispano - Páginas nuevas [es]

Manifiesto Tecnosoberano

2022-01-15T10:45:18Z

Al: Página creada con «El siguiente apartado es una propuesta a identificar las tecnologías que respetan lo que deberían ser todos los derechos de las usuarias y, por lo tanto fomentarla y, pre...»

El siguiente apartado es una propuesta a identificar las tecnologías que respetan lo que deberían ser todos los derechos de las usuarias y, por lo tanto fomentarla y, pretende ser, con la colaboración de las hacktivistas, una guía para las comunidades críticas con la tecnología en nuestros tiempos.

== Características deseables para tecnologías empoderadoras ==
El concepto de lo que significa software libre sigue siendo el definido en el año 1984 con la primera licencia de software libre. Las dos actualizaciones en la licencia que se han escrito mantienen la esencia que es garantizar la libertad a las usuarias para usar, modificar, distribuir copias exactas o modificadas de los programas.
Lo que ha cambiado es el propio concepto de software. En un ejemplo paradigmático podemos ver que la Free Software Foundation en marzo de 2016 empezó a tener en cuenta que muchos códigos Javascript iban mucho más allá de simplemente ofrecer funciones estéticas y se podían considerar software en sí mismos. Al intentar comprobar si muchos de esos programas podían ser usados, modificados, distribuidos y distribuir sus modificaciones identificaron que muchos de ellos no son libres<ref>https://www.gnu.org/philosophy/javascript-trap.es.html</ref>.
Por otro lado, como hacktivistas lo que aspiramos es a que las tecnologías no solo sean basadas en software libre, sino que, además, sean empoderadoras. Es decir la libertad en el software es un requisito indispensable para que una tecnología facilite un empoderamiento y, por lo tanto, un cambio social ético, pero ese requisito no es el único. Por ejemplo, el software libre corriendo en un servicio/servidor que espía a sus usuarias sin que éstas tengan opción de impedirlo (y, muchas veces, ni siquiera de conocerlo) es práctica común hoy día. La forma práctica que tenemos de impedirlo<ref>La forma teórica es comprobar que los programas que están corriendo en máquinas que no controlamos llevan la licencia GPL actualizada, la versión 3, con la clausula Affero, que puso a disposición la Free Software Foundation en 2007 cuando se identifió el problema y empezaba a a ser habitual encontrarlo.</ref> es correr tú tu software, de forma autónoma y autogestionada en tu propio servidor y securizarlo –en el caso que sea una tecnología que funciona según el modelo cliente/servidor– o tu propio dispositivo personal como computadora, teléfono,... –en el caso que sea una tecnología que funciona según el modelo P2P–, utilizando tu propia red y/o sistemas de cifrado y, para permitirte la interconexión con otras personas u organizaciones en otros servicios/servidores, utilizar formatos y protocolos estandarizados sobre los cuales poder decidir cuáles contenidos distribuyes al mundo, cuáles a tus contactos y cuáles no distribuyes en absoluto.
Vamos a extraer de lo anteriormente dicho las características que son requisitos indispensables para considerarlas tecnologías recomendables para el cambio social ético, empoderadoras:
Software Libre, Autonomía, Seguridad, Privacidad, Estandarización, Control sobre los contenidos. Y una forma transversal de valorarlas es preguntarse cómo de próxima y apropiada es la tecnología que estamos utilizando.

Pasemos brevemente a describir cada una de estas características.

=== Software Libre ===
Para una descripción detallada de qué es software libre:
https://www.gnu.org/philosophy/free-sw.es.html
Lo que sí que debemos mirar es cada software que corre la tecnología en concreto, es decir, comprobar que es Software Libre tanto del lado del cliente como del lado del servidor,
Por ejemplo, Telegram es software libre del lado del cliente, pero no del lado del servidor, por lo tanto, ya solo por este motivo no es una tecnología recomendable para el empoderamiento.
Para valorar si un programa libre es próximo y apropiado, a parte de comprobar que mantenga las 4 libertades debemos comprobar si puede ser ejecutado en hardware popular y/o económico o, por el contrario, necesita ser ejecutado en hardware muy potente y/o específico. Debemos comprobar si tiene documentación y ésta es entendible al colectivo al cual está dirigido el programa o si por el contrario la documentación es escasa o nula o es demasiado complicada o no está escrita en los idiomas que entienden las usuarias a los cuales va dirigido. Además, si se trata de un programa de uso social y/o que puede crear dependencia debemos comprobar también si la organización que hay detrás tiene unos valores éticos en términos de inclusión, igualdad, etc...<ref>Según estudios, existe un marcado sesgo de género en la aceptación o no de contribuciones externas llevadas a cabo por mujeres en ciertos proyectos de software libre que pueden ser identificados. Terrell et al. 2017 https://web.eecs.umich.edu/~weimerw/2019-481F/readings/genderpull.pdf</ref> De todas formas todas estas comprobaciones y las valoraciones que se extraen son útiles en tanto en cuanto haya que tomar decisiones en cuanto a cuál utilizar entre dos o más programas libres, no así si solo existe un programa software libre y su alternativa es uno privativo. Recordemos que, aun si el programa no es próximo y apropiado, puede llegar a serlo, dado que, al ser libre, la comunidad puede suplir estas carencias por sí misma.<ref>Ejemplo paradigmático fue el de la comunidad de Wikipedia en español, la cual al comprobar la deriva que llevaba Wikipedia hacia potencialmente convertirse en una punto com financiada con publicidad inicialmente llevó a cabo un fork el cual presionó a convertirse en una fundación sin ánimo de lucro https://es.digitaltrends.com/tendencias/rebelion-espanola-wikipedia-facebook/ </ref>

=== Autonomía ===
La autonomía en el campo de la tecnología social es la capacidad que tiene una persona o una organización voluntariamente constituida por sus miembros de tomar y ejecutar decisiones sin intervención ni influencia externa.
Esas decisiones incluyen cuestiones de infraestructura (qué hardware utilizar, dónde, qué redes,...), de funcionalidad (qué programas y de qué manera se utilizarán), de diseño, organizativas, etcétera...
Esas decisiones incluyen la capacidad de los miembros de una organización a abandonar la organización o la infraestructura y poder replicar la tecnología tal como la utilizaban en otra organización y/o infraestructura.
Por ejemplo, el conocido servicio de Signal está sustentado por software libre del lado del cliente. Y también publica como software libre una versión del servidor pero no es exactamente la que se utiliza en el servicio<ref>https://www.world-today-news.com/signal-messenger-is-no-longer-open-source/ </ref>, pero sobretodo no provee autonomía a sus usuarias dado que le requiere la intervención externa de usar un número de teléfono, el cual depende de una tecnología no basada en software libre, ni que, a su vez provee autonomía, ni privacidad.
Por supuesto, podrían abandonar la infraestructura y tomar el software publicado y hacer su propio sistema tecnológico totalmente autónomo, pero al no poder contectarse con el otro el sentido de ellos quedría en entredicho al tratarse este de una tecnología ideada para la comunicación con el mayor número de personas posible.
Las tecnologías históricas de Internet (como la web o el correo electrónico) funcionan según el modelo cliente-servidor y han requerido históricamente ordenadores más potentes de los que podían disponer personas particulares en sus casas y por eso un mismo servidor ha mantenido a muchas usuarias (muchas páginas web de muchas usuarias o muchas cuentas de correo eléctronico). En ese contexto, la gestión de esos servidores por parte de movimientos sociales han propiciado, en algunos casos, la creación de asambleas para administrar esos servidores, en otros casos ha sido llevado a cabo por personas que se han ofrecido a centralizar la administración de esos servidores, lo cual ha supuesto que no fueran realmente autogestionados por los miembros, incluso que las personas erigidas en administrarlos usaran su poder de forma jerárquica en algún momento. En estos casos podemos identificar una relación inversa entre la proximidad y la verdadera autonomía de las que disponen las personas y organizaciones que utilizan estas tecnologías. Ciertamente Internet facilita poder utilizar tecnologías que se pueden encontrar a mucha distancia física y lógica de las personas y también, en poco tiempo, puede producir cientos de miles de usuarias. Podríamos decir que una característica transversal a todas es preguntarse cómo de próxima es una tecnología hacias las personas que las están utilizando.
Otra manera de valorar cuánto de autonomía provee una tecnología en concreto es preguntarse si puede ser utilizada íntegramente en una Red Libre<ref>Utilizamos aquí la forma más difundida en español para hacer referencia a las redes de telecomunicaciones digitales TCP-IP creadas y pertenecientes a las usuarias (habitualmente a partir de las tecnologías WiFi). Otros nombres menos populares son “Red Ciudadana”, “Red Comunitaria”, “Red WiFi”, una combinación de estos adjetivos o la forma inglesa “Community Network”.</ref>. Cualquier servidor software libre puede instalarse en una Red Libre y por lo tanto las capacidades comunicativas pueden ser utilizadas independientemente de si las cualidades de conexión a la red de redes internet son precarias, intermitentes o incluso inexistentes. No es así de cualquier paquete de Software como Servicio. Ya sea del estilo de Instagram o Google Maps o el mencionado Signal.
Otra forma de conseguir autonomía en tecnología de comunicaciones es en base a las tecnologías P2P (Peer to Peer, entre pares) en la que directamente el programa que provee la comunicación y los datos están gestionado por cada persona y no por una organización (cada persona que tenga un dispositivo que soporte el programa). Es la tecnología de comunicación entre pares (normalmente el protocolo) la que hace las funciones de “organización” de forma ya previamente definida como conjunto de “normas”. Este caso, pues, es mucho más deseable en términos de autonomía dado que impide la corrupción o la supeditación de miembros a una asamblea.

=== Seguridad ===
La seguridad es el conjunto de tecnologías (o partes de tecnologías) que proporcionan protección para la información de las usuarias de manera que mantengan sus principios de disponibilidad, integridad y confidencialidad.

=== Privacidad ===
La privacidad (o la intimidad) en tecnología social son las características y habilidades que tiene una tecnología para preservar a una persona u organización del resto y que permitan a éstas expresarse selectivamente, es decir, permitir mantener la confidencialidad.
La confidencialidad es la propiedad de la información por la que se garantiza que esté accesible únicamente a personal autorizado a acceder a dicha información.
La seguridad es un requisito para el éxito de la privacidad.

=== Estandarización (por consenso) ===
En tecnología social la estandarización es el proceso por el cual se crea un modelo (por ejemplo un formato o un protocolo) en base a una necesidad y a partir del modelo se crean o se adaptan tecnologías que se adecuen a él.
Decimos que una tecnología está estandarizada cuando existe ese modelo. Hay varias formas de crear el modelo, definimos la estandarización por consenso en contraposición a la estandarización de facto. La estandarización es por consenso cuando se lleva a cabo a partir de una comunidad abierta a la participación de las personas y las organizaciones interesadas. La estandarización de facto es la que se produce cuando es un software en concreto el que acaba definiendo un modelo.
El resultado de un proceso de estandarización en tecnología social es la creación de estándares de protocolos o formatos sobre los cuales se pueden construir varias tecnologías (por ejemplo softwares) que van a permitir la interconexión entre ellas.
Es deseable que una tecnología tenga ya realizado un estándar por consenso (por ejemplo el correo electrónico) o esté en proceso de estandarización (si es muy nueva) porque nos garantiza por un lado que nuevas versiones de un mismo software serán compatibles con versiones anteriores y, por otro, que varios softwares se puedan comunicar entre ellos. Así las usuarias no son dependientes de un software en concreto o se pueden crear el suyo propio desde cero.
A su vez, permite y facilita procesos también deseables como la federación y, por todo ello repercute en el grado de autonomía y, por lo tanto, en el empoderamiento.

=== Control sobre los contenidos ===
En el campo de las tecnologías de la información y la comunicación los contenidos son los datos estructurados como información semántica (blogs, redes sociales, mensajería,…). El control de esta información es una moneda de cambio actual entre las grandes corporaciones de internet. Muchos servicios “gratuitos” piden que la usuaria acepte como condición de uso del servicio que el control de los contenidos pasen a ser gestionados por dicho servicio. Otros servicios se mantienen por siempre bajo control de las usuarias. Por ejemplo decimos que la comunidad de editores de Wikipedia tiene control sobre los contenidos porque puede hacer uso, modificación, copia y distribución de copias modificadas de los contenidos libremente y sin perder la autoría. El control sobre los contenidos bajo los cuales hay garantizada la privacidad permite decidir a la persona u organización creadora de un contenido (un artículo o un mensaje) cuándo y a quién hacer público ese mensaje. Por ejemplo con un servidor de archivos instalado por la propia usuaria en su espacio físico y con acceso por clave asimétrica es la usuaria la que decide a quién, cuándo y cuáles le da acceso a esos archivos.

== Proximidad, género, raza, alteridad,... Acceso al Conocimiento ==
A pesar de que el software libre, en el contexto de la ética hacker, cuestiona las formas de hacer y los valores del capitalismo, y aunque sus fundamentos son colaborativos y no competitivos, algunas de sus comunidades viven tensiones al estar inmersas en complejas relaciones de poder. Así pues, se observan relaciones de poder y meritocracias puntuales que pueden convertirse en jerarquías de larga duración. De igual forma, es evidente el desarrollo más veloz en los proyectos de software libre que obtienen más financiamiento o que les son más beneficiosos a la industria capitalista en la que se inscriben<ref>Un ejemplo de ello es el programa de modelado y animación 3D, Blender, el cual es software libre y que tuvo un desarrollo muy veloz debido al financiamiento de la industria del entretenimiento estadounidense, particularmente cine y videojuegos.</ref>.
El alejamiento de las mujeres del dominio de la técnica y por lo tanto, el despojo de cierto saber-hacer continúa hasta nuestros días, tanto fuera como dentro de la hegemonía tecnológica. Esto incluye el campo de la computación en general, las tecnologías de la comunicación. Pero incluso la participación de las mujeres en el movimiento de software libre es considerablemente menor que en el de software privativo, ya que “solo el 2% de las personas que trabajan en el desarrollo de tecnologías son mujeres, mientras que en la industria del software privativo, el porcentaje es de 28%” (Baroni, 2013:125). Si bien resulta paradójico que la participación de las mujeres que escriben código sea menor en un espacio aparentemente progresista, también es cierto que las reflexiones feministas han evidenciado que esto sucede en prácticamente todos los movimientos que pretenden la transformación social, aunque estos incorporen discursos de equidad de género. Asimismo, personas con identidades diversas, afrodescendientes, indígenas, transgénero, del área rural, etcétera, se encuentran ausentes o con poca participación.
En el contexto de este trabajo, las mujeres hacker son aquellas que desarrollan, diseñan y mantienen tecnología computacional dentro de las comunidades de software libre, mujeres en condición de excepcionalidad —y que gozan de ciertos privilegios, probablemente vinculados a su clase o raza— que a pesar del supuesto alejamiento tecnológico, marginalidad de saberes com plejos y desvalorización del saber-hacer del que hablé al principio, aunado a su poca participación en este...

== Dos ejemplos sobre gobernanza ==
{{en desarrollo}}
redes distribuidas a partir de software de enrutamiento dinámico (libremesh) vs guifi.net
retroshare vs servidores autogestionados

== Anotación sobre economía, gasto energético y hardware ==
{{en desarrollo}}
hablar de la blockchain
exceden el propósito de este manifiesto

== Propuesta: la identidad tecnosoberana ==
Lo que empezó como una broma ha mutando en herramienta útil y seria al generarse el corpus teórico de este documento.
Declararse tecnosoberano o tecnosoberana es llevar a cabo no solo un compromiso personal con la crítica hacia la tecnología y ser consciente de las repercusiones sociales y políticas de las tecnologías que estás utilizando sino que, además, y dado que estamos inmersas en relaciones sociales, económicas y políticas mediadas por tecnologías, en esta mediación podemos verbalizar que vamos a procurar llevar a cabo en medida de lo posible el uso de tecnologías que reúnan las características de libertad, autonomía, seguridad, privacidad, estandarización y control sobre los contenidos que son éticas y empoderadoras.
Ser tecnosoberano o tecnosoberana no es ni una imposición ni siquiera una identidad inmutable, tampoco, más allá de los propósitos de seguir y alimentar la broma, un dogma. Pero sí que es ponerle nombre identitario a un conjunto de prácticas que ya hace tiempo<ref>Por ejemplo nos encontramos el “Pringao HowTo” del año 2000 aprox</ref> que se están llevando a cabo en colectivos y personas y que muchas veces quedan injustamente invisibilizadas en las interaciones sociales, políticas y económicas bajo el aluvión de populares tecnologías privativas.
Ser tecnosoberano o tecnosoberana es utilizar, difundir y participar en el desarrollo únicamente de tecnologías digitales que tengan las seis características empoderadoras. Al mismo tiempo es visibilizar la importancia del uso crítico de la tecnología y participar de la creación de un ecosistema cómodo para la interacción de personas tecnosoberanas.

== El porqué del nombre ==
Un movimiento identitario necesita un nombre que quede anclado a campos semánticos anteriores, con fuerza y que permita recordarse fácilmente. El movimiento del software libre ha sido y sigue siendo la piedra angular de muchos movimientos por la soberanía y el empoderamiento y progresivamente va incluyendo también defensas por la autonomía9, la seguridad10, la privacidad11, la estandarización12 y el control sobre los contenidos13. Por ello la palabra softwarelibrana, freesoftwarer y similares fueron valoradas en un borrador de este documento, pero fueron descartadas por dos motivos: por ser larga y dificilmente traducible y porque el movimiento por la soberanía tecnológica adquirió un recorrido añadir trayectoria histórica del movimiento por la soberanía tecnológica. El problema de la expresión tecnosoberana es que, para ser concreta debería llevar a cabo el "apellido" digital, ya que es concretamente de las tecnologías digitales de las que estamos hablando, ya que son las más asequibles para obtener soberanía14. En cuanto a la creación del adjetivo que acaba de la misma manera que otras identidades conocidas y relativamente respetadas como “vegano” evoca que se es tecnosoberano o tecnosoberana no solo porque se utilice únicamente software libre (como los veganos no los son solo porque únicamente comen vegetales, si no porque eso entra dentro de una filosofía de vida que tiene que ver en evitar el sufrimiento animal). La identidad tecnosoberana no es descrita únicamente por utilizar solo software libre, sino es precisamente la suma de las 6 características. {{en desarrollo}}

== Notas ==
<references />
==Notes==
<references />

FAQ Basico

2017-02-23T18:26:20Z

Jibadia:

<h3 id="qué-hardware-necesito-como-mínimo-para-comenzar">¿Qué hardware necesito como mínimo para comenzar?</h3>
<h3 id="necesito-una-antena-y-un-router">¿Necesito una antena y un router?</h3>
<p>Depende de la proyección que quieras para tu punto de acceso:</p>
<ul>
<li><strong>¿Unicamente quieres conectarte tú?</strong> Necesitas ….</li>
<li><strong>¿Quieres que se conecte toda tu comunidad de vecinos?</strong> Necesitas ….</li>
<li><strong>¿Quieres poder facilitar el acceso a la red guifi a toda tu zona?</strong> Necesitas ….</li>
</ul>
<h3 id="qué-equipomarca-es-ella-más-recomendable-para-comenzar">¿Qué equipo/marca es el/la más recomendable para comenzar?</h3>
<h3 id="a-dónde-me-tengo-que-conectar">¿A dónde me tengo que conectar?</h3>
<h3 id="que-es-un-nodo">¿Que es un nodo?</h3>
<h3 id="que-es-un-supernodo">¿Que es un supernodo?</h3>
<h3 id="que-es-un-ap">¿Que es un Ap?</h3>
<h3 id="que-es-un-trasto">¿Que es un Trasto?</h3>
<h3 id="qué-significan-los-puntos-y-estrellas-del-mapa-de-conexión">¿Qué significan los puntos y estrellas del mapa de conexión?</h3>
<p>Los colores significan:</p>
<ul>
<li>Azul:</li>
<li>Amarillo:</li>
<li>Naranja:</li>
<li>Rojo:</li>
</ul>
<p>Los simbolos significan:</p>
<ul>
<li>Puntos:</li>
<li>Lineas:</li>
<li>Estrellas:</li>
</ul>
<h3 id="el-nodo-debe-estar-apuntando-hacia-mi-antena">¿El nodo debe estar apuntando hacia mi antena?</h3>
<h3 id="cómo-averiguo-si-el-nodo-que-está-cerca-de-mí-encara-hacia-mi-antena-y-puede-darme-una-buena-señal">¿Cómo averiguo si el nodo que está cerca de mí encara hacia mi antena y puede darme una buena señal?</h3>
<h3 id="qué-frecuencia-es-mejor-2.4-ghz-o-5-ghz">Qué frecuencia es mejor ¿2.4 Ghz o 5 Ghz?</h3>
<h3 id="puedo-conectar-mi-antena-de-5-ghz-a-un-nodo-de-2.4-ghz-o-al-revés">¿Puedo conectar mi antena de 5 Ghz a un nodo de 2.4 Ghz o al revés?</h3>
<h3 id="cómo-averiguo-el-tipo-de-antena-que-tiene-y-a-que-frequencia-trabaja-el-nodo-al-que-quiero-conectarme">¿Cómo averiguo el tipo de antena que tiene y a que frequencia trabaja el nodo al que quiero conectarme?</h3>
<h3 id="que-puede-hacer-un-instalador-por-mi">¿Que puede hacer un instalador por mí?</h3>

AUGM

2017-02-10T22:13:07Z

Oket: /* AUGM - Asociación de Usuarios Guifi.net Maestrat */

== ''AUGM - Asociación de Usuarios Guifi.net Maestrat ==

----

La Asociación guifinetMaestrat es una Asociación sin ánimo de lucro, ubicada en la zona norte de la provincia de Castellón,
tenemos la sede en la localidad costera de Vinarós.

Los objetivos de la Asociación son:

La promoción, investigación, mejora e innovación tecnológica de las redes abiertas, implantando tecnologías ya existentes en Internet,
incluso adaptándolas para mejor ajuste a su arquitectura, siempre en un entorno colaborativo de profesionales de diversos sectores,
que no busquen lucro, sino más bien un trueque de conocimientos y servicios técnicos. Tenemos una serie de proyectos en mente que sólo
tienen sentido si hay una comunidad de gente interesada en que se lleven a cabo, y es por esta razón que nace esta Asociación, realizamos
las actividades desde el voluntariado.

== Para conseguir estos fines la Asociación realiza las siguientes actividades: ==

1. Reuniones explicativas sobre la filosofía de guifi•net.

2. Talleres de formación técnica.

3. Mantenimiento y actualizaciones de la infraestructura de comunicaciones

4. Establecer convenios de colaboración con entidades públicas i privada.

http://guifinetmaestrat.net
https://es-es.facebook.com/GuifinetBaixMaestrat

Libre-mesh/Changelog

2016-08-08T00:28:47Z

Al:

== Changelog 17.06 ''Dayboot Rely'' ==
* based on LEDE 17.01.2
* build everything using LEDE SDK, via new lime-sdk cooker (instead of lime-build)
* use ieee80211s instead of adhoc
* reintroduced <code>firewall</code> package (to keep closer to upstream)
* lime-system: fix ieee80211s proto, correctly construct ifnames
* lime-system: sanitize hostname (transform everything into alphanumeric and dash)
* lime-system: new proto static
* lime-system: new wifi mode client
* lime-system: set <code>dnsmasq force=1</code> to ensure dnsmasq never bails out
* lime-system: explicitly populate <code>/etc/config/lime</code> with calculated values
* lime-webui: enable i18n, finally webinterface is available in Spanish
* lime-webui: Major rework by NicoPace, thanks!
** bmx6 node graph now uses colors in a clever way
** simple way to add "system notes" that are shown along with /etc/banner and webui
** luci-app-lime-location: fix google maps api key
** new read-only view: switch ports status
** alert luci-mod-admin users that their changes might get overwritten by lime-config
** fix batman-adv status webui
* new package available to install <code>lighttpd</code> instead of <code>uhttpd</code> (needed for an upcoming android app)
* added a <code>lime-sysupgrade</code> command: does a sysupgrade but only preserving libremesh configuration file
* added a <code>lime-apply</code> command: basically calls reload_config, but also applies hostname system-wide without rebooting
* lime-hwd-ground-routing: ground routing now supports untagged ports too
* lime-proto-anygw: unique mac based on ap_ssid (using <code>%N1</code>, <code>%N2</code>)
* lime-proto-anygw: integrate better into <code>/etc/config/dhcp</code> instead of <code>/etc/dnsmasq.d/</code>
* lime-proto-wan: allow link-local traffic over wan (useful for local <code>ping6</code> and <code>ssh</code>, without global exposure)
** lime-proto-batadv: set <code>batadv gw_mode=client</code> by default to counteract rogue DHCP servers
** lime-proto-bmx6: introduce <code>bmx6_pref_gw</code> option, adds priority (x10) to a specific bmx6 gateway
** lime-proto-bmx6: don't tag bmx6 packets over ethernet and so use at least <code>mtu=1500</code> everywhere
* lime-proto-bmx6: avoid autodetected wan interface use vlan for bmx6
* bmx6: doesn't flood log with some spurious warnings anymore (<code>syslog=0</code>)
* bmx6: sms plugin now enabled by default
* bmx6: daemon is now supervised by procd, so it is restarted in case of crashes
* bmx6: doesn't <code>configSync</code> by default anymore (no more "uci pending changes" because of auto-gw-mode)
* new bmx6hosts tool: maintain an <code>/etc/hosts</code> that resolves fd66: <-> hostnames.mesh
* watchping: convert to procd and add reload triggers
* safe-reboot: fix, use <code>/overlay/upper</code> instead of <code>/overlay</code>
* safe-reboot: add </code>discard<code> action
* ath9k: debugged some hangs (interface is deaf) and workaround it, with new package <code>smonit</code>
* set wifi default <code>distance</code> parameter to 1000 metres and make it configurable through webui
* alfred: fix bat-hosts facter, check for errors and don't nuke <code>/etc/bat-hosts</code> in case of failure
* introduce new lime-basic-noui metapackage
* new packages separated: lime-docs and lime-docs-minimal
* various Makefile dependency problems fixed

== Changelog 16.07 ''Community Chaos'' ==
* Based on OpenWrt Chaos Calmer 15.05.1
* Removed <code>firewall</code> package (which is included by default in vanilla OpenWrt/LEDE), since it's not really being used in LibreMesh setup. It can always be installed on a case-by-case basis using <code>opkg</code>.
* Removed <code>odhcpd</code> since we're not using it at the moment (we use <code>dnsmasq</code>)
* Removed <code>odhcp6c</code> since we're not using it at the moment (we still haven't solved how to deal with native IPv6 coming over WAN, i.e. propagate a delegated prefix over the mesh in a reasonable way)
* New default packages: <code>lime-hwd-openwrt-wan</code> and <code>lime-proto-wan</code>. This checks if there's a WAN port, and automatically configures as "wan" proto (<code>lime-proto-wan</code>). The "wan" proto let's you assign in <code>/etc/config/lime</code>, for example, 802.1ad VLANs over the WAN port.
* New default package: <code>lime-hwd-ground-routing</code>. Allows you to configure 802.1q VLANs on embedded switches, so that you can separate specific ports and put
* New default package: <code>bmx6-auto-gw-mode</code>, so that when a node detects (with watchping) it can ping 8.8.8.8 over WAN port, a bmx6 tunIn is created on-the-fly, and Internet is shared to the rest of the clouds.
* Workaround for an spurious log message caused by BATMAN-Adv (<code>br-lan</code>: received packet on bat0 with own address as source address"): a <code>dummy0" interface is created and added to <code>bat0</code>, with a slightly different MAC address
** https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-March/011839.html
* New available packages: <code>lime-proto-bgp</code>, allows to do BGP with bird daemon; and <code>lime-proto-olsr</code>, <code>-olsr2</code> and <code>-olsr6</code>, which add support for all versions of [[OLSR]].
* Some new settings possible in <code>/etc/config/lime-defaults</code>
** <code>wireless.htmode</code> lets you preset the htmode for any wireless radio (or <code>htmode_2ghz</code> and <code>htmode_5ghz</code> for specific bands)
** <code>wireless.distance</code> is the equivalent, for setting distance (and <code>distance_2ghz</code> / <code>_5ghz</code>)

Manual de Libre-mesh para guiferos

2016-08-08T00:05:44Z

Al: /* ¿Por qué tengo tantas interfaces de red? */

Este es un manual para entender cómo funciona [[Libre-mesh]] de forma práctica. Es de nivel técnico medio, está orientado a personas con conocimientos prácticos de redes inalámbricas, especialmente para personas que no están familiarizadas con el funcionamiento de los protocolos de enrutamiento dinámico [[BMX6]] y [[BATMAN-adv]], pero sí con [[BGP]] tal como se usa en Guifi.net.

=== Desarrollo de Libre-mesh ===

==== ¿Cómo tenéis organizado el desarrollo? ====

==== Entonces: ¿qué me recomendáis para montar una red con Libre-mesh en mi zona ahora? ====

==== ¿Cuál es la relación entre qMp y Libre-mesh? ====

=== Primer arranque ===

==== ¿Qué hace el router en el primer arranque después de flashearlo? ====
El script [https://github.com/libre-mesh/lime-packages/blob/master/packages/lime-system/files/etc/uci-defaults/91_lime-config /etc/uci-defaults/91_lime-config] es llamado por OpenWrt en el primer arranque. Entonces [https://github.com/libre-mesh/lime-packages/blob/master/packages/lime-system/files/usr/bin/lime-config /usr/bin/lime-config] genera los archivos de configuración para:

system:
* Le pone un nombre de máquina (<code>hostname</code>) en base a los tres últimos hexadecimales de la MAC
* Arranca el servidor web

wireless:
* Elimina la configuración de wireless que trae por defecto OpenWrt
* Detecta los dispositivos wireless ([[radio]]s) que tiene el router y si estos son capaces de funcionar a 5GHz y en modos ad-hoc y ap
* Crea el essid a partir de la los tres últimos hexadecimales de la MAC más .lime
* Configura los canales por cada una de las radios

network:
* Elimina la configuración de red que trae por defecto OpenWrt
* Detecta las interfaces de red que tiene el router
* Configura la primera IPv4
* Configura la primera IPv6
* Activa rp_filter (ignora paquetes que no son para su red) [http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html más información]
* Configura los protocolos BATMAN-adv y BMX6

firewall:
* crea un cortafuegas donde todos los paquetes son aceptados <ref>Hasta la versión 16.07 se eliminaba el cortafuegos por defecto de OpenWrt y se creaba otro, a partir de la 16.07 incluida el cortafuegos ya no se pone dentro de los paquetes.</ref>
* crea una regla que comprime el MSS al ancho del MTU que está definido en las interaces

Este script se borra él mismo después del primer arranque (aunque todavía puedes verlo en la ROM <code>/rom/etc/uci-defaults/91_lime-config</code> )

<references />

=== Comandos ===

==== ¿Cómo puedo comprobar que los nodos están enlazados y los protocolos están funcionando bien? ====

=== Contenido de los nodos ===

==== ¿Por qué tengo tantas interfaces de red? ====
Desde la linea de comandos del router si hacemos <code>ip address show</code> (que es la forma sustitutiva de hacer un <code>ifconfig</code>) vemos un listado de 23 interfaces de red en la versión 15.07 y 26 en la versión 16.07.

Si nos da palo contarlas nos puede salir el resultado con este comando:
echo $(($(ip link show|wc -l)/2))

Esas interfaces tienen funciones varias. Pasamos a explicar a continuación todas las existentes en la versión 26.07.

===== Interfaces =====
Nota: el .11 en el nombre de la interfaz virutal corresponde a la vlan

Cloudy paquetes repositorio

2015-09-15T16:44:28Z

Conxuro: Página creada con «'''''Nota: este artículo puede estar desactualizado y debería ser revisado. Ten precaución si sigues esta guía, y mejor pregunta antes en las listas de correo.''''' ...»

'''''Nota: este artículo puede estar desactualizado y debería ser revisado. Ten precaución si sigues esta guía, y mejor pregunta antes en las listas de correo.'''''

== Subir paquetes al repositorio de software de Cloudy (proyecto Clommunity) ==

Estamos preparados para subir paquetes al repositorio público de Cloudy http://repo.clommunity-project.eu.

Aquí requeriremos claves públicas para firmar y subir paquetes. Por supuesto, puedes editar los scripts y cambiar las rutas ''(paths)'' de acuerdo a tus necesidades.

El repositorio está auto-firmado con una clave llamada "gcodis Distro Development Team", más información en el mismo repositorio: http://repo.clommunity-project.eu. El auto-firmado previene que el repositorio permanezca no firmado si alguien sube paquetes sin firmar. Una firma para el repositio, que es añadida en el lado del cliente para permitir la instalación de la distro, y otra firma que depende del mantenedor o desarrollador para firmar el paquete.

=== Claves públicas ===

Para subir paquetes necesitamos conseguir '''tus claves''' públicas:

* El '''ID de la clave pública GPG, subido a gpg.mit.edu'''. Con esta clave podrás firmar las subidas.
* La '''clave publica SSH''', para subir paquetes. Necesaria para acceder remotamente a la máquina del repositorio.

Los paquetes son subidos por defecto a la rama ''unstable'' (usa el "log de cambios" ''(changelog)'' para ello). Nosotros utilizamos la herramienta de Debian <code>dput</code> para subir los paquetes y firmarlos. El repositorio está auto-firmado con otra clave.

Puedes '''enviar''' las claves públicas o IDs a la lista de correo del proyecto: ''clommunity-wp4''. De esta manera tendremos acceso a las claves públicas cuando sea necesario.

=== Archivos ===

El archivo de configuración es:

* <code>.dput.cf</code> es un archivo de configuración que tiene que ser copiado en el directorio ''home'' como <code>~/.dput.cf</code>. Utilizado para subir paquetes con la herramienta de Debian <code>dput</code>.

<code>
[repo.clommunity-project.eu]
fqdn = repo.clommunity-project.eu
method = scp
login = repo
incoming = /var/www/debian/mini-dinstall/incoming
post_upload_command = ssh repo@repo.clommunity-project.eu "mini-dinstall -b"
</code>

=== Creando paquetes ===

Mira algunas maneras para crear paquetes en http://www.debian.org/doc/manuals/maint-guide/build.en.html.

=== Subiendo paquetes ===

Puedes usar el comando <code>dput</code> de la siguiente manera:

<code>
$ dput repo.clommunity-project.eu cloudy-base_0.1.3.5_i386.changes
</code>

Recuerda guardar las versiones previas del archivo <code>~/.dput.cf</code> en tu directorio <code>$HOME</code>.

Es importante escribir el nombre del repositorio ''(repo.clommunity-project.eu)''.

=== Mejoras continuas ===

El repositorio se mejora para funcionar mejor cuando es necesario dar un mejor servicio.

Gracias por tus esfuerzos.

[[Categoría:Cloudy]]

Cloudy Alix

2015-09-11T02:32:28Z

Conxuro: Página creada con «Alix es una [https://es.wikipedia.org/wiki/Placa_computadora SBC] con un procesador AMD (x86) y varias interfaces de entrada-salida (serie, miniPCI, Ethernet, etc.). Es por...»

Alix es una [https://es.wikipedia.org/wiki/Placa_computadora SBC] con un procesador AMD (x86) y varias interfaces de entrada-salida (serie, miniPCI, Ethernet, etc.). Es por ello que se tiene que utilizar un sistema operativo preparado con los controladores ''(drivers)'' corresponendientes para hacer funcionar estas interfaces.

''Nota: esta guía se ha hecho con una Debian especialmente preparada para funcionar en Alix, pero es posible que con otra distribución basada en Debian funcione con pasos similares.''

== Conseguir Debian para Alix ==

Puedes [https://code.google.com/p/debian-for-alix/ descargar de esta página] una imagen especial de Debian lista para funcionar en placas Alix una vez grabada en una tarjeta CF.

=== Características/servicios incluidos ===

* Sistema de archivos de sólo lectura, protege contra fallos de corriente y aumenta sustancialmente la vida de la tarjeta.

* Servicios comunes disponibles en el primer arranque:
** serial terminal ( 38400n8 )
** dnsmasq ( servidores DNS y DHCP )
** iptables ( reglas firewall y compartición de Internet )
** samba ( compartición de archivos de Microsoft Windows )
** cups ( servidor de impresora )
** vsftpd ( servidor FTP )
** nginx with fastcgi ( servidor HTTP )
** minidlna ( servidor multimedia )
** openssh ( terminal y SFTP )
** stunnel ( motor SSL, soporte HTTPS pre-configurado para ''nginx'' y ''transmission'' )
** tinyproxy ( servidor proxy HTTP/HTTPS )
** pptpd ( servidor VPN, MS Windows tiene un cliente incorporado )
** snmpd ( servidor SNMP )
** openvpn ( servidor y cliente VPN )
** openconnect ( cliente VPN client, compatible con Cisco )
** external storage automount and sharing basic web admin panel performance monitor ( on web panel )

* Servicios adicionales disponibles:
** transmission ( torrent p2p )
** hostapd ( wireless access point / necesita tarjeta miniPCI o usb wifi )

* Sistema de mantenimiento a través de <code>apt-get</code>, úsalo para actualizar, instalar o eliminar aplicaciones y parches.

* Ten en cuenta que es una Debian i386, por lo que cualquier software disponible para esta arquitectura puede ser instalado, considerando las limitaciones de potencia.

* Los archivos de imagen están disponibles para descargar en GoogleDrive:
** debian-for-alix-v1.img.bz2 (debian 6 based) version 1 wiki page
** debian-for-alix-v2.img.bz2 (debian 6 based) version 2 wiki page
** debian-for-alix-v3.img.bz2 (debian 7 based) Debian instalación básica, sólo servidor SSH y utilidades básicas, también el terminal serie está preparado, pero no tiene el sistema de ficheros en sólo lectura ni otras características.

* La configuración por defecto es:
<code>eth0: DHCP</code>

<code>eth1: static 172.16.210.254</code>

<code>eth2: sin configuración</code>

<code>usuario: alix (root tiene el acceso bloqueado)</code>

== Instalar la imagen Debian en la CF ==

=== Identificar la CF ===

La tarjeta CF necesita ser formateada con ext2. Asegúrate de qué dispositivo es tu tarjeta, de lo contrario podrías borrar el S.O. de tu ordenador. En este ejemplo la CF está en <code>/dev/sdb</code>.

Puedes probar mirando en <code>/proc/bus/usb/devices</code>. Deberías ver una sección con una linea ''S:'' y el nombre de tu lector, y una linea ''I:'' con <code>Driver=usb-storage</code>. Si lo ves, es que el kernel reconoce el dispositivo.

Instalar el paquete <code>sg3-utils</code> si lo tienes ya (en Debian: <code>apt-get install sg3-utils</code>). Para comprobar tus dispositivos SCSI, ejecuta el comando:
sg_scan -i

Deberías ver algo como esto:
/dev/sg0: scsi0 channel=0 id=0 lun=0 [em] type=0
eUSB Compact Flash 5.09 [wide=0 sync=0 cmdq=0 sftre=0 pq=0x0]

Muestra que el dispositivo “raw” SCSI asociado con tu lector es <code>/dev/sg0</code>. Puedes confirmar que el ''driver'' está funcionando mirando el archivo <code>/proc/scsi/scsi</code>. Ahora, para determinar el dispositivo SCSI real asociado con tu lector ejecuta el comando:
sg_map

Verás una salida como esta:
/dev/sg0 /dev/sdb

Eso es todo, tu lector de tarjetas es <code>/dev/sdb</code>. La primera (y probablemente la única) partición es <code>/dev/sdb1</code>.

=== Copiar la imagen en la CF ===

Para instalar la imagen en la tarjeta CF puedes hacerlo con el siguiente comando:
bzcat debian-for-alix-v3.img.bz2 | dd of=/dev/sdb bs=16k

== Instalar Cloudy ==

Para instalar Cloudy puedes seguir las instrucciones para [[Cloudy_en_Debian|convertir una instalación básica de Debian en Cloudy]] añadiendo al sistema los archivos y herramientas específicas de la distribución.

Lo llamamos "cloudynizar".

Recomendamos usar un script para automatizar el proceso. Puedes saber cómo en la [[cloudynizar|página de esta wiki que explica cómo "cloudynizar"]].

[[Categoría:Cloudy]]

Cloudy Beaglebone

2015-09-10T20:19:52Z

Conxuro: Página creada con «Beaglebone es una [https://es.wikipedia.org/wiki/Placa_computadora SBC] con un procesador ARM y varias interfaces de entrada-salida. Es por ello que se tiene que utilizar u...»

Beaglebone es una [https://es.wikipedia.org/wiki/Placa_computadora SBC] con un procesador ARM y varias interfaces de entrada-salida. Es por ello que se tiene que utilizar un sistema operativo preparado para funcionar en esta arquitectura y con los controladores ''(drivers)'' corresponendientes para hacer funcionar estas interfaces.

''Nota: esta guía se ha hecho con la distribución Ubuntu, pero es posible que con otra distribución basada en Debian funcione con los mismos pasos.''

== Instalar el sistema ==

* Insertar la tarjeta microSD en el ordenador y observar que dispositivo se registra tecleado <code>ls /dev/sd</code>. Si no estas seguro, elimina la tarjeta y la entrada desaparecerá. Una vez sepas que dispositivo corresponde a tu tarjeta sigue las siguientes instrucciones reemplazando <code>/dev/sdX</code> por el de tu microSD en tu sistema.

* Empezar particionando la tarjeta microSD escribiendo <code>fdisk /dev/sdX</code>.
# Inicializar una nueva tabla de particiones seleccionando <code>o</code>, luego verifica que este vacía seleccionando <code>p</code> ''(print)''.
# Crear una partición de arranque ''(boot)'' seleccionando <code>n</code> ''(new)'', luego <code>p</code> para ''primary'', y <code>1</code> para especificar la primera partición. Pulsar ''enter'' para aceptar el primer sector por defecto y especifica <code>4095</code> para el último sector.
# Cambiar el tipo de partición a FAT16 seleccionando <code>t</code> ''(type)'' y <code>e</code> para ''‘W95 FAT16 (LBA)’''.
# Marcar la partición como arrancable selecionando <code>a</code> y luego <code>1</code>.
# Crear la partición de datos para el sistema de ficheros seleccionado <code>n</code> ''(new)'', luego <code>1</code> ''(primary)'' y <code>2</code> para especificar la segunda partición. Aceptar los valores por defecto para el primer y último sector pulsando ''enter'' cada vez (x2).
# Pulsar <code>p</code> para ‘imprimir’ la tabla de particiones.
# Finalmente, guardar los cambios seleccionando <code>w</code> para "escribir" ''(write)'' la tabla de particiones y salir de ''fdisk''.

* Formatear las particiones e instalar el sistema de arranque y el sistema raíz.
# Formatear la partición 1 como FAT escribiendo <code>mkfs.vfat /dev/sdX1</code>.
# Formatear la partición 2 como ext4 escribiendo <code>mkfs.ext4 /dev/sdX2</code>.
# Instalar ''u-boot'' en la tarjeta microSD.
wget http://s3.armhf.com/dist/bone/bone-uboot.tar.xz
mkdir boot
mount /dev/sdX1 boot
tar xJvf bone-uboot.tar.xz -C boot
umount boot
# Instalar el sistema raiz de ficheros deseado en la tarjeta microSD (Ubuntu Trusty en este ejemplo).
wget http://s3.armhf.com/dist/bone/ubuntu-trusty-14.04-rootfs-3.14.4.1-bone-armhf.com.tar.xz
mkdir rootfs
mount /dev/sdX2 rootfs
tar xJvf ubuntu-trusty-14.04-rootfs-3.14.4.1-bone-armhf.com.tar.xz -C rootfs
umount rootfs

La tarjeta microSD ya está lista para arrancar. Nótese que para esta instalación de Ubuntu, el userid de login es ''ubuntu'' y la contraseña es ''ubuntu''.

''Nota: la caché de paquetes ha sido vaciada para reducir el tamaño de la imagen. Ejecuta <code>apt-get update</code> después de iniciar para actualizar la caché de paquetes, luego ejecuta <code>apt-get upgrade</code> para instalar las actualizaciones.''

== Instalar Cloudy ==

Para instalar Cloudy puedes seguir las instrucciones para [[Cloudy_en_Debian|convertir una instalación básica de Debian en Cloudy]] añadiendo al sistema los archivos y herramientas específicas de la distribución.

Lo llamamos "cloudynizar".

Recomendamos usar un script para automatizar el proceso. Puedes saber cómo en la [[cloudynizar|página de esta wiki que explica cómo "cloudynizar"]].

[[Categoría:Cloudy]]

Cloudy en Debian

2015-09-10T17:41:33Z

Conxuro: Página creada con «Puedes convertir una instalación básica de Debian en Cloudy siguiendo estos pasos: 1. Entrar vía SSH como usuario root (o una vez logeado) o ejecuta los próximos coma...»

Puedes convertir una instalación básica de Debian en Cloudy siguiendo estos pasos:

1. Entrar vía SSH como usuario root (o una vez logeado) o ejecuta los próximos comandos con la herramienta ''sudo''.

2. Actualizar la fecha del servidor instalando un cliente NTP ''(opcional)''.

apt-get install ntp

3. Añadir los backports de Debian, y los repositorios de Clommunity y Guifi.
* Backports Debian:
echo "deb http://ftp.debian.org/debian wheezy-backports main contrib" > /etc/apt/sources.list.d/backports.list
* Repositorio Clommunity:
echo "deb http://repo.clommunity-project.eu/debian unstable/" > /etc/apt/sources.list.d/cloudy.list
gpg --keyserver pgpkeys.mit.edu --recv-key A59C5DC8 && gpg --export --armor A59C5DC8 | apt-key add -
* Repositorio Guifi:
echo "deb http://serveis.guifi.net/debian guifi/" > /etc/apt/sources.list.d/serveis.list
gpg --keyserver pgpkeys.mit.edu --recv-key 2E484DAB && gpg --export --armor 2E484DAB | apt-key add -

4. Instalar algunos paquetes de Debian.
apt-get update
apt-get upgrade
apt-get install -y openssh-server openssh-client getinconf-client curl unzip make avahi-utils tahoe-lafs mysql-server python2.7 g++ make checkinstall openjdk-6-jre locales php5 libssh2-php libapache2-mod-encoding

'''''Nota''': si aparece este error: "Error W: GPG error: http://ftp.debian.org wheezy-backports InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY8B48AD6246925553" usa este comando:
apt-get --allow-unauthenticated upgrade
''

5. Instalar los paquetes ''"non-Debian"'' de Cloudy.
curl "https://raw.githubusercontent.com/Clommunity/lbmake/master/hooks/getinconf-client.chroot" | sh -
curl "https://raw.githubusercontent.com/Clommunity/lbmake/master/hooks/avahi-ps.chroot" | sh -
curl "https://raw.githubusercontent.com/Clommunity/lbmake/master/hooks/cDistro.chroot" | sh -

g. Reiniciar.

Después de esto, podrás entrar a la interfaz web de usuario en http://IP_dispositivo:7000

[[Categoría:Cloudy]]

Modelos de gestión de tramos de red libre

2015-08-19T23:32:26Z

Al: Página creada con «El concepto de red abierta, libre y neutral hace referencia a la libertad de poder conectarse, saber cómo funciona la red, poder ampliarla y poder hacer fluir contenidos l...»

El concepto de red abierta, libre y neutral hace referencia a la libertad de poder conectarse, saber cómo funciona la red, poder ampliarla y poder hacer fluir contenidos libremente todo ello manteniendo el buen funcionamiento de la red para todo el mundo. Ahora bien, dentro de este concepto hay varios modelos que las personas usuarias han desarrollado para gestionar sus tramos de red. Estos modelos conviven dentro de la red abierta, libre y neutral entramándose unos con otros y la implementación de un modelo u otro depende tan sólo de la voluntad de las usuarias en función de sus intereses, recursos, tradición cultural, etcétera,... Ningún modelo es mejor que otro siempre y cuando todos respeten la licencia de la red abierta, libre y neutral.

== Modelo comunitario horizontal ==
Un grupo de personas normalmente de una misma ubicación geográfica determinada se organizan para diseñar, construir y mantener una red. Se autocapacitan entre ellas para tener los conocimientos para hacerlo, toman decisiones de forma asamblearia y compran-construyen los materiales y mantienen los gastos periódicos (conexión con otras redes, gastos eléctricos, reposición de supernodos,...) entre todas, ya sea a través de cuotas de las que ellas mismas deciden el precio o a través de gastos puntuales según necesidades puntuales. Pueden constituir o no una organización legal o no para llevarlo a cabo.

=== Submodelo comunitario cooperativa de consumo de abajo a arriba ===
A veces el modelo comunitario horizontal ya sea en sus inicios o a partir de un momento dado que la red requiere mucho mantenimiento, puede decidir (o no) mutar su modelos a un modelo de cooperativa de consumo (similar al de las cooperativas o grupos de consumo de alimentos ecológicos locales) en el que esas personas ya sea por falta de tiempo o por cualquier otro motivo deciden mantener las decisiones asamblearias pero la gestión técnica en manos de una especialista técnico (o unas pocas especialistas técnicas) que actúa como un profesional liberado en beneficio de toda la red. En este caso las aportaciones siempre son periódicas en la que se suman los gastos periódicos, puntuales y el sueldo de la persona o personas técnicas destinadas y se divide entre todas las unidades familiares o comunidades de vecinos que participan de la red.

== Modelo instalador altruista voluntario ==
A veces hay personas que por pasión, amor al proyecto, por aprender y mejorar, por hacer currículum o cualquier otro motivo dedica su conocimiento y parte de su tiempo a montar, reparar y/o mantener nodos de red libre a otras personas u organizaciones. A veces lo hace a partir del material pagado por esas personas u organizaciones o a veces incluso lo pone de su propio bolsillo. Estas personas, por supuesto, en cualquier momento pueden dejar de hacerlo (de hecho, es común que en algún momento suceda) y que esos tramos de red pasen a otro modelo de gestión o, desgraciadamente, queden sin uso o apagados o incluso algún espabilado los privatice, se los reapropie y las usuarias pierdan las libertades.

== Modelo emprendedor de arriba a abajo ==
Una persona o un conjunto de personas con conocimientos técnicos para la construcción y mantenimiento de tramos de red libre se anuncian abiertamente para la construcción y mantenimiento con tarifas muchas veces puntuales (por ejemplo coste por hora por montar un nodo y realizar la primera conexión) y en ocasiones también periódicas (por proveer de servicios de internet, telefonía, web, servidores, etcétera,...) a personas u organizaciones que quieren formar parte de la red libre. Normalmente esta persona o personas trabaja/n bajo el nombre de una organización empresarial o como autónomos.

== Modelo de libre conexión individualista ==
Como la red abierta libre y neutral mantiene por licencia toda la documentación de cada nodo de la red incluida su ubicación e IPs cualquier persona individual puede, leyendo la documentación on-line general de WiFi y/o fibra óptica y específica de la ubicación determinada, conectarse a un nodo de la red abierta, libre y neutral siguiendo los pasos y respetando la licencia. Podrá hacerlo sin necesidad de contactar con la/s persona/s si es directamente a un nodo en modo AP altruista abierto a la interconexión o un nodo en modo ad-hoc o tendrá la necesidad de contactar y ampliar físicamente el nodo de la otra ubicación llevando un nuevo trasto que le permita ampliar la red en su dirección.

== Conclusiones ==
Estos no son los únicos modelos posibles. Son tan sólo unos ejemplos de implementaciones reales. Pueden crearse otros según necesidades específicas o también existen modelos que mixturan varios de estos modelos. Siéntete libre de utilizar cualquiera de ellos siempre y cuando respetes la licencia. La existencia de estos modelos de gestión en una red determinada no garantizan tampoco que esa red sea abierta, libre y neutral. Por ejemplo un tramo de red que tiene unos gestores que te obligan a seguir uno de estos modelos no es una red abierta, libre y neutral.

[[Categoría:social]]

Cloudy Raspberry Pi

2015-07-21T20:14:20Z

Conxuro:

La Raspberry Pi es un pequeño y económico ordenador del tamaño de una tarjeta de crédito, creado principalmente para ser utilizada con fines educativos y en pequeños proyectos.

Esta placa tiene un procesador ARM y diversas interfaces de entrada-salida; vídeo, audio, Ethernet, USB, GPIO, etc. Es por ello que se tiene que utilizar un sistema operativo preparado para funcionar en esta arquitectura y con los controladores (''drivers'') corresponendientes para hacer funcionar estas interfaces.

En nuestro caso, para instalar Cloudy se preparará la Raspberry Pi con una distribución ya adaptada basada en Debian como es Raspbian, y una vez hecho esto se "cloudynizará" para añadir todo el contenido propio de Cloudy.

'''''Nota:''' Esta guia, así como diversas pruebas de instalación de Cloudy, se ha hecho con el S.O. Raspbian; pero es posible que con otra distribución basada en Debian funcione con los mismos pasos.''

== Descargar Raspbian ==

Vamos a la [https://www.raspberrypi.org/downloads/ página oficial] y descargamos la imagen ISO del sistema operativo que nos servirá de base.

Alternativamente se puede utilizar una variante de Raspbian, la [http://sirlagz.net/2013/07/19/raspbian-server-edition-2-5/ Raspbian Server Edition], que está preparada sin paquetes innecessarios (sistema gráfico, audio, etc.) para el uso de la Raspberry Pi como servidor.

== Instalar y configurar Raspbian ==

Grabamos la imagen en una tarjeta de memoria SD. Según el sistema operativo de tu ordenador puedes seguir una de estas guías (en inglés) para grabar imágenes ISO.

* [http://www.raspberrypi.org/documentation/installation/installing-images/linux.md Linux]
* [http://www.raspberrypi.org/documentation/installation/installing-images/mac.md Mac OS]
* [http://www.raspberrypi.org/documentation/installation/installing-images/windows.md Windows]

A continuación instertamos la tarjeta y encendemos la placa para comenzar el proceso de configuración con la herramienta <code>raspi-config</code>.

Básicamente lo que se recomienda hacer es:
# Expandir el sistema de ficheros para utilizar todo el espacio de la SD.
# Cambiar la contrasseña del usuario '''pi''' (por defecto).
# Cambiar la localización si queremos otro idioma, el uso horario (''timezone'') y el mapa de teclado.
# En opciones avanzadas; activar el servidor SSH, cambiar el ''hostname'' y actualizar la <code>raspi-config</code>.

Si quieres hacer más cambios, puedes encontrar más información en la [https://www.raspberrypi.org/documentation/configuration/raspi-config.md documentación de raspi-config].

No nos extenderemos más en explicar como se instala y configura Raspbian ya que está ampliamente documentado en Internet.

=== Opciones adicionales ===

Como se ha comentaado más arriba, hay una versión personalizada para funcionar como servidor, que elimina paquetes innecesarios. Ésta tendría que funcionar igual que la Raspbian original, pero es más recomendable hacer esta adaptación después de manera manual o automatizándolo con el ''script'' que desinstala los paquetes para dejar el sistema como la Raspbian Server Edition.

Podéis obtener más información y descargar este ''script'' en [http://sirlagz.net/2013/08/03/raspbian-server-edition-scripts/ la siguiente página].

== Instalar Cloudy ==

Para instalar Cloudy puedes seguir las instrucciones para [[Cloudy_en_Debian|convertir una instalación básica de Debian en Cloudy]] añadiendo al sistema los archivos y herramientas específicas de la distribución.

Lo llamamos "cloudynizar".

Recomendamos usar un script para automatizar el proceso. Puedes saber cómo en la [[cloudynizar|página de esta wiki que explica cómo "cloudynizar"]].

[[Categoría:Cloudy]]

Cloudy en nodo cliente

2015-07-17T15:35:06Z

Conxuro: Página creada con «Cloudy utiliza un sistema de publicación y búsqueda de servicios para compartirlos con otros Cloudys. Para hacer esto, actualmente se emplea [https://www.serfdom.io/ Serf...»

Cloudy utiliza un sistema de publicación y búsqueda de servicios para compartirlos con otros Cloudys. Para hacer esto, actualmente se emplea [https://www.serfdom.io/ Serf].

Este software abre un puerto TCP en el servidor (Cloudy) para escuchar peticiones y poder comunicarse con otros.

Por tanto, para que un Cloudy instalado en un nodo cliente pueda interactuar con los otros Cloudys es necesario hacer algunos pasos adicionales:

1. Saber la dirección IP pública del nodo (10.x.x.x); no la IP asignada a Cloudy sino la IP asignada al nodo cliente.
* Puedes ir a la página de [http://guifi.net Guifi] de tu nodo para saber cuál es la IP de éste.

2. Modificar un par de ficheros y declarar la IP pública del nodo. Tienes que añadir la IP a los ficheros de configuración para que el software pueda anunciar correctamente la IP pública y no la privada.
* Para hacerlo, con el usuario '''''root''''', entra por linea de comandos lo siguiente:
<pre>
root@cloudy:~# echo "ADVERTISE_IP=10.x.x.x" >> /etc/avahi-ps-serf.conf
root@cloudy:~# echo "PUBLIC_IP=10.x.x.x" >> /etc/getinconf-client.conf
root@cloudy:~# /etc/init.d/serf restart

(donde 10.x.x.x es la IP pública de tu nodo)
</pre>

'''Ejemplo:'''
En un nodo con dirección IP 10.1.2.3 los ficheros tendrían que ser como:
<pre>
/etc/avahi-ps-serf.conf
SERF_RPC_ADDR=127.0.0.1:7373
SERF_BIND=5000
SERF_JOIN=10.139.40.82:5000
ADVERTISE_IP=10.1.2.3

/etc/getinconf-client.conf
#!/bin/sh
# Automatically generate file
GTC_SERVER_URL=http://10.139.40.84/index.php
NETWORK_NAME=demo
NETWORK_KEY=demo
INTERNAL_DEV=eth0
# PORT=665
# GETINCONF_IGNORE=1
GETINCONF_IGNORE=1
PUBLIC_IP=10.1.2.3
</pre>

3. Hacer una redirección (''port forwarding'') del puerto 5000 (''Serf'') en el node. Y si quieres tener más servicios tendrás que redireccionar el puerto de cada uno de éstos.
* La configuración para hacer esto dependerá del dispositivo que tengas.

[[Categoría:Cloudy]]

Radioenlaces

2015-07-15T11:21:37Z

Pakito.oliva: Página creada con «En esta página se contará la experiencia con los distintos tipos de radioenlaces, el material utilizado y el resultado obtenido. ==Radioenlace de menos de 1 KM== ==Radi...»

En esta página se contará la experiencia con los distintos tipos de radioenlaces, el material utilizado y el resultado obtenido.

==Radioenlace de menos de 1 KM==

==Radioenlace de 1 a 5 Km==

==Radioenlace de 5 a 10 Km==

==Radioenlace de 10 a 20 Km==

==Radioenlace de más de 20 Km ==

Cloudynizar

2015-05-13T12:56:08Z

Chk: Fix typo on command

Una alternativa para instalar Cloudy es modificando un sistema Debian GNU/Linux, o basado en Debian, aplicando un ''script'' que convierte el sistema en un Cloudy.

Para hacerlo puedes ejecutar los siguientes comandos:

<pre>
git clone https://github.com/Clommunity/cloudynitzar && cd cloudynitzar
chmod +x cloudynitzar.sh
sudo ./cloudynitzar.sh
</pre>

[[Categoría:Cloudy]]

Cloudy 64bits

2015-05-13T12:37:31Z

Conxuro:

Actualmente sólo existe generada la versión de 32 bits, sin embargo, puedes crear la versió de 64 bits de la siguiente manera:

Primero, descarga el sistema de generación o "constructor" de imágenes ''(image builder)'':

<pre>
apt-get install build-essential live-build imagemagick curl debootstrap git unzip
git clone http://dev.cloudy.community/guifi.net/cloudy-image-builder.git
</pre>

A continuación modifica las siguientes variables del archivo ''Makefile'':

<pre>
ARCH ?= amd64
FLAVOUR ?= amd64
</pre>

Finalmente, puedes generar la imagen con el siguiente comando:

<pre>sudo make</pre>

Una vez la imagen ha sido creada, tendrás una versión Cloudy de 64 bits en <code>./devel/binary.hybrid.iso</code>

----

Alternativamente puedes "Cloudynizar" una Debian de 64 bits para convertirla en Cloudy.

Lee cómo en la página [[Cloudynizar]] de la wiki.

[[Categoría:Cloudy]]

Cloudy web UI

2015-05-12T18:49:46Z

Conxuro:

== Introducción ==

La inferfaz web de usuario (web User Interface (UI)) de Cloudy utiliza una aplicación llamada cDistro <ref name="cdistro">cDistro git repository: https://github.com/Clommunity/cDistro</ref>.

''(Añadir qué es)''

== Configuración ==

La configuración de cDistro se encuentra en <s>/etc/cdistro.conf</s> /etc/cloudy/cloudy.conf

Por defecto tiene el siguiente formato:

#cdistro config
SERVER="/usr/bin/php"
OPTS=""
BINDIP="0.0.0.0"
PORT="7000"
DOCROOT="/var/local/cDistro"
# SSHAUTH=1 <- check user with ssh2 connection http://www.php.net/manual/en/function.ssh2-auth-password.php (Require: libssh2-php)
SSHAUTH=1
# LOGIN="root"
## PASSWORD = md5(md5('secret')) => php -r 'echo md5(md5("secret"))."\n";'
#PASSWORD="7022cd14c42ff272619d6beacdc9ffde"
PORT_SSL=7443

=== SERVER ===

La ruta del ejecutable PHP.

'''Ejemplo:'''

* "/usr/bin/php" - en el caso de Cloudy (Debian).

=== OPTS ===

Opciones de PHP.

''(Añadir referencias o más info y ejemplo)''

=== BINDIP ===

La dirección IP donde el servicio estará escuchando.

'''Ejemplo:'''

* "127.0.0.1" - aceptará sólo peticiones desde localhost.
* "0.0.0.0" - aceptará peticiones desde cualquier dirección.

=== PORT ===

El puerto que abrirà el servicio para escuchar peticiones.

'''Ejemplo:'''

* "7000" - abre el puerto 7000

=== DOCROOT ===

La ruta del ejecutable de la aplicación cDistro.

'''Ejemplo:'''

* "/var/local/cDistro" - en el caso de Cloudy.

=== SSLAUTH ===

Parámetro que permite autenticación vía SSH2 en la aplicación, es decir, para utilizar las credenciales que permita el servidor SSH del sistema.

Puede ser 0 o 1.

'''Ejemplo:'''

* "1" - activa esta opción.
* "0" - desactiva esta opción (requerirá definir usuario y contraseña).

=== LOGIN ===

El nombre de usuario para autenticarse en la aplicación.

Ha de ser una cadena sin espacios.

'''Ejemplo:'''

* "cloudy" - este usuario podrá hacer log-in con la contraseña de PASSWORD.

=== PASSWORD ===

La contraseña del usuario definido en LOGIN.

Ha de ser un ''hash'' sobre ''hash'' MD5 (hexadecimal), es decir, un ''hash'' del ''hash'' de la contraseña: md5(md5("PASSWORD")).

'''Ejemplo:'''

* "46d934e0f59ff1e2272f9f5f7950e5d9" - ''hash'' correspondiente a la cadena de carácteres "PASSWORD".

'''Ejemplos de cómo generar este ''hash'' en un terminal:'''

$ php -r 'echo md5(md5("PASSWORD"))."\n";'
46d934e0f59ff1e2272f9f5f7950e5d9
$ printf "PASSWORD" | md5sum | awk '{printf $1}' | md5sum | awk '{print $1}'
46d934e0f59ff1e2272f9f5f7950e5d9

=== PORT_SSL ===

Puerto que utilizará Cloudy en la interfaz web con HTTPS (si SSL está instalado).

'''Ejemplo:'''

* "7443" - se accederá a la web https://IP_SERVIDOR:7443.

== Referencias ==

<references/>

[[Categoría:Cloudy]]

Cloudy plug-ins

2015-04-22T15:11:25Z

Conxuro:

== ¿Qué es un plug-in? ==

Cloudy es una distribución de Linux basada en Debian que proporciona a los usuarios una interfaz simple y cómoda para gestionar diferentes servicios que pueden usarse a través de una red comunitaria; en nuestro caso, Guifi.

Al mismo tiempo, Cloudy ofrece una serie de herramientas que permiten a un usuario añadir un servicio de su agrado sin tener grandes conocimientos sobre redes e informática en general. Automaticamente, estos servicios se publican mediante Avahi, de manera que todo el que utilice Cloudy podrá hacer uso de estos servicios.

Otra manera de llamar estos servicios que se pueden poner y quitar de forma sencilla es ''plug-in''. Por tanto, entendemos por plug-in a un programa o software que un usuario quiere añadir a la distribución y que puede ser gestionado de forma simple des de la interfaz web que provee Cloudy.

== Añadir servicios a Cloudy ==

=== Una pequeña introducción ===

Esta guía te enseñará el proceso para añadir un nuevo servicio en la distribución Cloudy.

Para serclaro y dar algunos ejemplos al mismo tiempo, integraremos un servicio bastante simple mostrando algunos trozos de código por el camino. Para seguir el tutorial con más facilidad o bien para integrar servicios más complejos, estaría bien tener algunos conocimientos de Bash<ref name="Bash">(http://www.tldp.org/LDP/Bash-Beginners-Guide/Bash-Beginners-Guide.pdf)</ref> y de PHP<ref name="PHP">(https://php.net/manual/es/index.php)</ref>.

Por simplicidad utilizaremos Pastecat<ref name="Pastecat">(https://github.com/mvdan/pastecat)</ref>. Es un buen candidato ya que:

* Es independiente y no se ''federa'' ni se comunica con otros nodos.
* Está hecho en Go, es facil de distribuir e instalar.
* No necesita archivos de configuración.
* No necesita muchos recursos.

=== Obtener el binario ===

Lo primero que hemos de investigar es como descargar e instalar el binario en Cloudy. La mayoria de software que podemos encontrar está por defecto en los paquetes de Debian, pero Pastecat no está. Si se diera el caso de que estuviera, solo tendríamos que ejecutar el comando <code>apt-get install pastecat</code> desde PHP.

Pero como este no es el caso, tendremos que obtener el binario por otro lado. Una opcion es coger el código fuente y compilarlo nosotros mismos, pero el problema de esto es que Cloudy necesitaria incluir muchas herramientas y librerias de desarrollo, y este no es el objetivo.

La mejor opción si un paquete de Debian no está disponible en los repositorios es descargar los binarios de otro lugar seguro. Podemos utilizar el servicio de ''"releases"'' de Github para ello. Las dos opciones nos dan un archivo ejecutable que tendríamos que ser capaces de ejecutar directamente sobre Cloudy.

En este caso en particular descargaremos los binarios desde el repositorio git con la siguiente linea de comandos:

<code>
wget https://github.com/mvdan/pastecat/releases/download/v0.3.0/pastecat_linux_386_v0.3.0
</code>

Nótese que en este caso en concreto estamos descargando una versión específica para Linux con arquitectura i386.

Fijaos que tener un servicio en los paquetes de Debian tiene muchas ventajas:

* Las actualizaciones son simples y no necesitan trabajo extra desde Cloudy.
* El paquete está compilado para Debian de manera segura.
* Los archivos de ''init.d'' ya vienen por defecto.
* Los paquetes de Debian suelen contener correciones.

=== Probarlo ===

Antes de añadir un servicio deberíamos configurarlo y probarlo nosotros directamente para ver cómo funciona y que realmente funciona. También hemos de entender qué opciones de configuración o de linea de comandos necesitamos para hacer uso de este servicio en particular y como lo gestionariamos una vez este funcionando.

=== Añadir el controlador ===

En <code>web/plug/controllers</code> tenenmos un archivo PHP para cada servicio, llamado controlador (o 'controller' en inglés). Este archivo contiene el codigo que se ejecutará cuando se visite la página de nuestro servicio desde la interfaz de Cloudy.

==== Añadir la función indice ====

Lo que queremos es que nuestro servicio esté integrado en la estructura web de Cloudy. Para ello, necesitamos crear unos cuantos ''scripts'' en PHP y añadirlos a nuestro sistema. De momento crearemos dos ''scripts'': <code>pastecat.php</code> y <code>pastecat.menu.php</code>. El primer archivo es el controlador, es decir, el ''script'' que renderiza la página y tiene toda la información tal como botones o redireccionamientos. El otro es el que permite que nuestro servicio se muestre en los menus superiores desplegables de Cloudy.

El código del menú será similar a esto:

<code php>
<?php
//peerstreamer.menu.php
addMenu('Pastecat','pastecat','Clommunity');
</code>

Por ahora, utilizaremos un ''script'' muy simple en PHP como controlador:

<code php>
<?php
//pastecat
$title="Pastecat";

function index(){
global $paspath,$title;
global $staticFile;

$page=hlc(t($title));
$page .= hl(t("Minimalist pastebin engine written in Go"),4);
$page .= par(t("A simple and self-hosted pastebin service written in Go").' '.t("Can use a variety of storage backends").' '.t(" Designed to optionally remove pastes after a certain period of time.").' '.("If using a persistent storage backend, pastes will be kept between runs.").' '.t("This software runs the").' '."<a href='http://paste.cat'>".t("paste.cat")."</a>". t(" public service."));

return(array('type' => 'render','page' => $page));
}
</code>

En nuestro sistema Cloudy estos archivos han de ponerse en los directorios dentro de <code>/var/local/cDistro/plug/</code>. El primero ha de ir en <code>menus</code> y el segundo en el directori <code>controllers</code>. Una vez hecho esto podemos ir a la web de nuestro Cloudy y acceder al nuevo menú Pastecat.

==== Hacer que el controlador instale nuestro servicio ====

Como se ha comentado anteriormente, este paso es mucho más sencillo de hacer si el servicio está entre los paquetes de Debian. Como que no es el caso de Pastecat, lo tendremos que hacer manualmente. Normalmente hacer este proceso manualmente incluye una combinación de los comandos <code>wget</code>, <code>mv</code> y <code>chmod</code>. En general, es buena idea mantener los archivos de este tipo de servicios en <code>/opt/SERVICENAME</code>.

En nuestro caso particular, lo primero que necesitamos es descargar el binario de la ''release'' de Github. Para ello utilizaremos el comando: <code>wget</code>. Dada una URL a un archivo, este comando permite descargar este archivo en nuestro sistema, i es lo que haremos con:

<code bash>
wget https://github.com/mvdan/pastecat/releases/download/v0.3.0/pastecat_linux_386_v0.3.0
</code>

Una vez tengamos el binario en nuestra máquina, lo moveremos al directorio /opt/pastecat/. Para mover los archivos por nuestro sistema usaremos el comando <code>mv</code>. Aun así, primero tendremos que crear el directorio donde pondremos el archivo. Para ello utilizaremos <code>mkdir</code> de la siguiente manera:

<code bash>
mkdir -p /opt/pastecat/
</code>

Una vez hayamos creado el directorio, es hora de mover el binario:

<code bash>
mv current_directory/pastecat_linux_386 /opt/pastecat/
</code>

Donde "current_directory" es el directorio donde previamente hemos descargado el binario. Como el nombre del binario depende de la arquitectura, para simplificar el código del controlador, cambiaremos el nombre del archivo ejecutable por algo más genérico y simple:

<code bash>
mv /opt/pastecat/pastecat_linux_386 /opt/pastecat/pastecat
</code>

Ahora nuestro binario se llama <code>pastecat</code> en lugar de <code>pastecat_linux_386</code>.

Estos pasos son los requisitos mínimos para instalar un servicio que no se ofrece directamente en los repositorios oficiales de Debian. Sin embargo, de cara a un usuario final, sería una pesadilla tener que hacer todos estos comandos en una consola conectado a través de <code>ssh</code> a su dispositivo, así que lo que haremos a continuación es crear un ''script'' en Bash que será llamado más adelante a traves de la interfaz web haciendo click en un botón.

Este ''script'' es la primera versión del controlador de Pastecat. Por ahora solo incluiremos una función para instalar Pastecat en nuestro dispositivo. Más adelante incluiremos otras funciones para proveer a nuestro ''script'' de más servicios:

<code bash>
#!/bin/bash
PCPATH="/opt/pastecat/"

doInstall() {
if isInstall
then
echo "Pastecat is already installed."
return
fi

# Creating directory and switching
mkdir -p $pcpath && cd $pcpath

# Getting file
wget https://github.com/mvdan/pastecat/releases/download/v0.3.0/pastecat_linux_386_v0.3.0

# Changing name so controller can invoke it generically
mv pastecat_linux_386 pastecat
chmod +x pastecat

cd -
}

isInstalled() {
[ -d $pcpath ] && return 0
return 1
}

case $1 in
"install")
shift
doInstall $@
;;
esac
</code>

Podemos ver como los últimos pasos se han concentrado en una misma función, permmiténdonos instalar el software en el dispositivo de una manera mas sencilla.

==== Hacer que el controlador utilitce Pastecat ====

===== Ejecutar el servicio =====

El paso siguiente es hacer que nuestro software se pueda utilizar desde la intarfaz web. Para ello incluiremos una nueva opción en nuestra página principal de Pastecat e incluiremos una nueva función en nuestro controlador para gestionar el binario. Añadiremos un botón en el código PHP de la siguiente manera:

<code bash>
$page .= addButton(array('label'=>t('Create a Pastecat server'),'href'=>$staticFile.'/pastecat/publish'));
</code>

Ha de ir justo después del mensaje <code>Pastecat is installed</code>. A continuación se ha de implementar la función <code>publish</code> en el mismo PHP. Esta función es la responsable de llamar a la función correspondiente desde el controlador y anunciar nuestro servicio utilizando Avahi. La diferencia con esta función es que requiere un formulario para introducir datos, así que al final acabaremos teniendo dos funciones: una ''get'' i una ''post'':

<code php>
function publish_get() {
global $pcpath,$title;
global $staticFile;

$page = hlc(t($title));
$page .= hlc(t('Publish a pastecat server'),2);
$page .= par(t("Write the port to publish your Pastecat service"));
$page .= createForm(array('class'=>'form-horizontal'));
$page .= addInput('description',t('Describe this server'));
$page .= addSubmit(array('label'=>t('Publish'),'class'=>'btn btn-primary'));
$page .= addButton(array('label'=>t('Cancel'),'href'=>$staticFile.'/peerstreamer'));

return(array('type' => 'render','page' => $page));
}

function publish_post() {
$port = $_POST['port'];
$description = $_POST['description'];
$ip = "";

<nowiki>$page = "<pre>";
$page .= _pcsource($description);
$page .= "</pre>";</nowiki>

return(array('type' => 'render','page' => $page));
}
</code>

Como podemos ver en la función <code>post</code> estamos invocando otra función. El motivo de hacer esto es escribir el código de manera más simple y modular. En esta última funcion por fin llamamos al script:

<code php>
function _pcsource($port,$description) {
global $pcpath,$pcprogram,$title,$pcutils,$avahi_type,$port;

$page = "";
$device = getCommunityDev()['output'][0];
$ipserver = getCommunityIP()['output'][0];

if ($description == "") $description = $type;

$cmd = $pcutils." publish '$port' '$description';
execute_program_detached($cmd);

$page .= t($ipserver);
$page .= par(t('Published this server.'));

$page .= addButton(array('label'=>t('Back'),'href'=>$staticFile.'/pastecat'));

return($page)
}
</code>

Lo siguiente que hemos de hacer es crear una función <code>publish</code> en el controlador, por lo que añadiremos una nueva función al controlador básico que tenemos en la sección '''3.2'''. Primero añadiremos un nuevo paámetro llamado ''publish'', asi que la primera parte en ejecutarse del ''script'' sera:

<code bash>
if [ $# -lt 1 ]
then
doHelp
fi

case $1 in
"install")
shift
doInstall $@
;;
"publish")
shift
doServer $@
;;
esac
</code>

Como se puede ver, cuando el primer argumento del ''script'' es <code>publish</code>, desplazamos (''shift'') el resto de argumentos y llamamos a la funcion <code>doServer</code>. En esta función hemos de poner en marcha el servicio con los argumentos correspondientes, así que lo primero queharemos será poner estos parámetros en variables locales. Una vez hecho esto lo más lógico sería lanzar la aplicación directamente, pero como el ''script'' se llama con permisos de "root" (no recomendable), hemos de lanzar Pastecat como usuario <code>nobody</code>. El problema es que el usuario <code>nobody</code> no tiene casi permisos y Pastecat necesita algunos persmisos para crear directorios y archivos de texto. Para permitir que <code>nobody</code> pueda hacerlo, primero crearemos un directorio con permisos a casi todos los usuarios. Para esto, utilizaremos el comando <code>chmod</code> de nuevo. Ahora el usuario puede crear archivos y directorios dentro de este mismo directorio, y en consecuencia podemos ejecutar Pastecat. Finalmente hay que mantener el PID en una variable en caso de que lo necesitemos más adelante (que ya os adelantamos que sí lo necesitaremos):

<code bash>
doServer() {
# Turning machine into a server

local port=${1:-""}
local description=${2:-""}
local ip=${3:-"0.0.0.0"}

# Creating directory with nobody permissions
mkdir -p "/var/local/pastecat"
chmod 777 "/var/local/pastecat" && cd "/var/local/pastecat"

# Running pastecat
cmd='su '$PCUSER' -c "{ '$PCPATH$PCPROG' -l :'$port' > '$LOGFILE' 2>&1 & }; echo \$!"'
pidpc=$(eval $cmd) # keeping PID for future needs...

cd -

# Using the PID, we could carry on process control so if the pastecat process die, we can also
# stop the avahi process to avoid "false connections"

return
}
</code>

Fijaos que ahora estamos utilizando algunas variables globales que no estaban definidas antes, como <code>PCUSER</code> y <code>LOGFILE</code>. Estas variables tienen los siguientes valores:

<code bash>
PCPATH="/opt/pastecat/"
PCPROG="pastecat"
LOGFILE="/dev/null"
PCUSER="nobody
</code>

===== Parar el servicio =====

En algún momento es posible que queramos parar nuestro servicio. Para esto crearemos un botón para hacerlo. Lo primero que hacer sería crear el botón, pero si pensamos un poco veremos que antes de crearlo necesitamos una manera de saber si nuestro servicio esta ejecutándose o no. Además, también necesitamos una manera de parar nuestro servicio. Como estamos ejecutando sobre Linux, podemos parar el servicio fácilmente utilizando el comando <code>kill</code>. El problema es que para utilizar este comando primero necesitamos saber el número de identificación del proceso (PID). Por suerte, ja nos quedamos con este número cuando creamos el servidor de Pastecat; en concreto con la linea <code>pidpc=$(eval $cmd)</code>.

Ahora que tenemos todo lo que necesitamos para matar nuestro proceso vamos a ver como lo hacemos para que PHP pueda saber si el servicio está ejecutándose o no. Una manera fácil y eficiente de hacerlo es almacenando algunos datos útiles en un archivo y borrarlo cuando se pare Pastecat. De esta manera nos aseguramos que el archivo sólo existe cuando Pastecat está activo. Este archivo lo crearemos desde el controlador aádiendo las siguientes lineas justo despues de la sentencia que hemos mencionado en el párafo anterior:

<code bash>
# Writting server info to file
info="$pidpc http://$ip:$port" # Separator is space character
echo $info > $PCFILE
</code>

Donde <code>$PCFILE</code> es una variable global que contiene <code>/var/run/pc.info</code>. Fijaos
que el contenido del archivo sera el PID del Pastecat y la dirección completa del servidor de este.

Ahora ya tenemos una manera de saber si el servicio está activo o no, de manera que añadiremos justo a continuación el botón 'stop' en la interfaz web. Modificaremos un poco el ''script'' PHP que teniamos antes, añadiendo un anuncio indicando si Pastecat se está ejecutando o no, y dos botones más cuando éste esté ejecutándose. Así pues, nuestra función índice contendrá el siguiente codigo dentro de la condición que comprueba si Pastecat está instalado o no:

<code php>
<nowiki>$page .= "<div class='alert alert-success text-center'>".t("Pastecat is installed")."</div>\n";
if ( isRunning() ) {
$page .= "<div class='alert alert-success text-center'>".t("Pastecat is running")."</div>\n";
$page .= addButton(array('label'=>t('Go to server'),'href'=>'http://'. getCommunityIP()['output'][0] .':'. $port));
$page .= addButton(array('label'=>t('Stop server'),'href'=>$staticFile.'/pastecat/stop'));
} else {
$page .= "<div class='alert alert-error text-center'>".t("Pastecat is not running")."</div>\n";
}
$page .= addButton(array('label'=>t('Create a Pastecat server'),'href'=>$staticFile.'/pastecat/publish'));</nowiki>
</code>

En este trozo de código podemos apreciar dos nuevas cosas. La priemra es una función de comprobación llamada <code>isRunning()</code>. Esta función se parece mucho a la funcion que utilizamos para comprar si Pastecat esta instalado o no:

<code php>
function isRunning() {
// Returns whether pastecat is running or not
global $pcfile;

return(file_exists($pcfile));
}
</code>

Es tan simple como parece, solamente comprueba que el archivo creado cuando se lanza el servidor de Pastecat aun existe. Lo segundo que podemos ver nuevo en nuestro codigo es la existencia de una nueva función llamada <code>stop</code>. Esta funcion invocará otra función en el controlador que parará el servidor de Pastecat:

<code php>
function stop() {
// Stops Pastecat server
global $pcpath,$pcprogram,$title,$pcutils,$avahi_type,$port;

$page = "";
$cmd = $pcutils." stop ";
execute_program_detached($cmd);

return(array('type'=>'redirect','url'=>$staticFile.'/pastecat'));
}
</code>

Para hacer que el controlador entienda esta orden tendremos que modificarla sentencia <code>case</code> y añadir la nueva función. En el <code>case</code> añadiremos lo siguiente debajo de la opción <code>install</code>:

<code bash>
"stop")
shift
doStop $@
;;
</code>

Esto llama a la función <code>doStop</code> dentro del mismo controlador. Esta función será similar a:

<code bash>
doStop() {
# Stopping pastecat server
pcpid=$(cat $PCFILE | cut -d' ' -f1)
kill $pcpid

# Removing info file
rm $PCFILE
}
</code>

Esta función coge el PID de Pastecat del archivo que hemos creado antes, mata el proceso y finalmente borra el archivo de manera que PHP pueda detectar que Pastecat se ha parado.

Ahora podemos crear un servidor de Pastecat y pararlo. Aun así, aun hay algo que falta: hacer que el resto de usuarios puedan ver nuestro servicio. Para esto usaremos Avahi.

=== Publicación de servicios Avahi ===

Una de las mejores cosas de Cloudy es la caracteristica de publicar nuestros servicios con Avahi, permitiendo a otros usuarios saber qué ofrecemos y que puedan unirse a nuestro servicio. Para hacer esto primero hemos de añadir algunas lineas de código en el controlador PHP, justo debajo de la llamada al controlador en Bash para activar el servidor Pastecat. Añadiremos las siguientes lineas:

<code php>
$description = str_replace(' ', '', $description);
$temp = avahi_publish($avahi_type, $description, $port, "");
$page .= ptxt($temp);
</code>

Aisí al final nuestra función quedará así:

<code php>
function _pcsource($port,$description) {
global $pcpath,$pcprogram,$title,$pcutils,$avahi_type;

$page = "";
$device = getCommunityDev()['output'][0];
$ipserver = getCommunityIP()['output'][0];

if ($description == "") $description = $type;

$cmd = $pcutils." publish '$port' '$description'";
execute_program_detached($cmd);

$page .= t($ipserver);
$page .= par(t('Published this server.'));
$description = str_replace(' ', '', $description);
$temp = avahi_publish($avahi_type, $description, $port, "");
$page .= ptxt($temp);

$page .= addButton(array('label'=>t('Back'),'href'=>$staticFile.'/pastecat'));

return($page)
}
</code>

Con este simple paso hemos anunciado nuestro servicio en la red de Avahi. Pero el trabajo no acaba aquí, queda aun una cosa mas por hacer: crear un botón y programarlo de manera que cuando se pulse nos redirija directamente a nuestro servidor de Pastecat.

Para hacer esto hay una carpeta llamada <code>avahi</code> dentro del directorio <code>plug</code>. Los ''scripts'' que definen la acción a llevar a cabo cuando se pulsan los botones estan en diferentes archivos dentro de este directorio. De este modo, crearemos un archivo llamado <code>pastecat.avahi.php</code> que contendrá:

<code php>
<?php
// plug/avahi/pastecat.avahi.php

addAvahi('pastecat','fpcserver');

function fpcserver($dates){
global $staticFile;

return ("<a class='btn' href='http://" .$dates['ip'] .":". $dates['port']."'>Go to server</a> ");
}
</code>

Esto creará un botón al lado del anuncio de Avahi que apuntará a nuestro servidor.

Ahora que ya tenemos nuestro servicio anunciado, queremos que este desaparezca una vez paremos el servidor de Pastecat. Este último paso es muy simple pero importante. Consiste en unas pocas lineas de código en la función 'stop' del ''script'' PHP. Hasta ahora, esta función solo llamaba al controlador Bash y paraba Pastecat, pero ahora también parará la publicación Avavhi y mostrará un breve comentario notificando que la llamada ha funcionado:

<code php>
$temp = avahi_unpublish($avahi_type, $port);
$flash = ptxt($temp);
setFlash($flash);
</code>

Estas lineas tienen que ser añadidas justo después de la sentencia <code>execute_program_detached($cmd)</code> en la función 'stop' de PHP.

=== Final ===

Finalmente añadir que todos los archivos implementados en este tutorial se pueden encontrar en un repositorio Github, que aparece en el apartado de Enlaces Externos, junto a este mismo tutorial en formato Markdown (md).

== Referencias ==

<references/>

== Enlaces externos ==

https://github.com/Clommunity/Doc/tree/master/plugins/pastecat

[[Categoría:Cloudy]]
[[ca:Cloudy_plug-ins]]
[[en:Cloudy_plug-ins]]