wiki da nuvem - Contribuições do(a) usuário(a) [pt-br]

RedesAutonomasLogEfeefe

2013-05-12T18:07:13Z

FelipeFonseca:

[[Página principal]] > [[Redes Autônomas (Felipe Fonseca e Vincenzo Tozzi-Brasil)]]

== 05/11/12 ==

Passamos algumas horas hoje brincando com rasppi (não subiu wifi), com o laptop onde fica a nuboteca (que não subiu a rede em modo ap). Tem uma beagleboard também, mas acabei voltando para a casinha onde estamos ficando, e vou testar com o nc10. NC10 é um netbook da samsung comprado em 2009 e usado por quase dois anos. Deu problema no cooler e no teclado, e acabei trocando por outro. Mas ele aparentemente ainda pode dar um bom servidor, com a vantagem de ter uma bateria com duração razoável.

Abri o NC10 para instalar um dos cartões wifi mini pci que trouxe. Escolhi um atheros, que costuma ser mais bem suportado por várias distros. Por enquanto arranquei também o teclado, que não funciona bem. Estou com um teclado USB da Nuvem, deve dar conta. Voltei para meu computador, abri o unetbootin para criar um disco de boot. Tentei usar um cartão SDHC de 16G, mas o unetbootin não deixou. Deve ter seus motivos (mais tarde percebi que o cartão SD está com problemas). Acabei fazendo um pendrive de 2Gb com a imagem do debian-6.0.6-i386.

Subindo o disco de boot. Optei pela instalação padrão. Configurei idioma e teclado. Configuração de rede, não preciso agora. Nome da máquina (uaifai), senha de root (lanovale), meu usuário e senha. Particionamento: assistido, usar o disco inteiro. Partição /home separada. Escrever as mudanças no disco.
No tasksel, optei por não instalar o ambiente gráfico, e escolhi servidor web, sql, ssh, laptop e utilitários standard de sistema. Grub? Sim. Reiniciando.
Sistema subiu. Mas testando com a wifi, não deixou setar modo master. Desliguei, tirei esse cartão (um atheros ar5bxb63). Tentei com outro (um mini pci express, ath ar5b95). Também nada. Terceira tentativa (e última à mão), um rtl 8187b. Nada. Beco sem saída?

Tentando com um zd1211, USB. "Unable to enumerate USB device on port 6". Procurando na web, parece uam incompatibilidade de velocidade de interface USB. Gambiarra, solução meio capenga, aqui: http://www.geekdevs.com/2010/04/solved-unable-to-enumerate-usb-device-disabling-ehci_hcd/

Consegui plugar, reconheceu como wlan3. E nada de modo master. Em último caso, amanhã tiro o pci da alix e instalo no samsung.

Enquanto isso, copiando a imagem do debian (i386, DVD) para o cartão de memória. O plano é levar para o samsung, então montar como unidade em loop, copiar os debs do /pool para um diretório local e então montar um repositório, seguindo isso aqui:

https://odzangba.wordpress.com/2006/10/13/how-to-build-local-apt-repositories/

Deu pau na cópia (alguma merda no cartão de memória travou minha máquina, acho).

Encontrei um chinês buscando coisas parecidas:
http://old.nabble.com/zd1211B-for-AP-mode-td31868516.html

Dali, parece que o hostapd resolve o lance. A ver.

Configurei meu celular como roteador, criando uma rede sem encriptação. Acessei pelo nc10, iwconfig, fácil. Mexi na sources.list (adicionei deb http://ftp.debian.org/debian/ squeeze main). Update, install dnsmasq, hostapd e hostap-utils. Amanhã continuo, na Nuvem.

==06/11/12==

De volta à Nuvem. Tentei subir a rede uaifai a partir do samsung nc10 usando as configurações do hostapd sacadas da alix. Não deu, reclamou que não podia setar o modo master. Agora vou tirar o wifi da alix e colocar no nc10. Vamos ver se funciona.

Hm, não deu. O cartão na alix é pci express, não minipci express como no laptop. Vou testar com a outra atheros (ainda menor, prendi com fita crepe).

Não rolou. Depois fiz uma série de tentativas com as diferentes opções de wifi usb que temos disponíveis aqui. A R8188 deixa modo master, mas não é suportada pelo hostapd. A prism não funciona em modo ap. A outra, nada.

Voltando a pensar na atheros. Baixando o madwifi para refazer a interface como ap. A ver. Começar tentando do jeito mais fácil, adicionando contrib e non-free no sources.list. Não encontrou. Adicionando repositório backports. Update. Nada. Seguindo então as instruções do wiki do madwifi-project para compilar.

Não encontrou o source do madwifi. Baixei o 0.9.4-current. Compilou ok mas não encontrou o device. Tentando agora habilitar o modo ap no ath9k e recompilá-lo:
http://linuxwireless.org/en/users/Drivers/ath9k#Get_the_latest_ath9k_driver

Compilado ok, mas não reconheceu a placa.

==07/11/12==

Ontem ainda encontrei um patch que dizem resolver para habilitar o madwifi a funcionar com a placa atheros (mini).

http://madwifi-project.org/ticket/2391

É para uma revision específica do source. Subversion -r 4174. Deixei baixando durante a noite.

Aplicando o patch: na pasta madwifi, patch -p1 < patch

# make
# make install.
# reboot

ath0 rodou. Não deixou modo ap. Mandei a linha:

# wlanconfig ath0 destroy
# wlanconfig ath create wlandev wifi0 wlanmode ap

E pronto, modo ap funcionando!

Brincando com o roteador TP-Link AR743ND. Baixando a versão do openwrt para ele:

http://downloads.openwrt.org/snapshots/trunk/ar71xx/openwrt-ar71xx-generic-tl-wr743nd-v1-squashfs-factory.bin

Error code: 18005

Upgrade unsuccessfully because the version of the upgraded file was incorrect. Please check the file name.

Tentar então por tftp.

----

Saí para almoçar com as meninas. Enquanto isso, Vince encontrou uma imagem do dd-wrt para esse roteador e instalou. Ele já cria automaticamente alias de DNS com o hostname das máquinas que pedem DHCP. Depois de substituir o roteador antigo com esse rodando dd-wrt, todas as máquinas já podem acessar a nuboteca (e outras máquinas) pelo hostname de cada uma, sem precisar saber seu IP.

----

Trabalhei mais um pouco no samsung nc10, o "uaifai". Copiei as configurações de rede da alix. As mais importantes são:

O script de inicialização da interface de rede (/etc/network/interfaces):

auto ath0
iface ath0 inet static
address 12.34.56.78
network 12.34.56.0
netmask 255.255.255.0
broadcast 12.34.56.255
wireless-mode Master
wireless-essid zasf
up /usr/bin/hostapd /etc/hostapd/hostapd.conf

(precisei só mudar o caminho do hostapd para /usr/sbin/hostapd e o essid para uaifai)

A configuração do dnsmasq (/etc/dnsmasq.conf), contendo:
dhcp-range=12.34.56.80,12.34.56.254,3h

A configuração do hostapd (/etc/hostapd/hostapd.conf), contendo:
interface=ath0
driver=madwifi
ssid=zasf (que mudei para uaifai)

Ao fim da tarde, consegui fazer funcionar a rede uaifai com essas configurações.

----

Fizemos uma "oficina". Falei sobre os quatro esquemas que estamos experimentando (alix, roteador dd-wrt + máquina nuboteca, raspberry pi, samsung). Depois fui mostrar algumas possibilidades que já estão funcionando na alix (web com wiki e hotglue, servidor irc, etc.). Enquanto Vince demonstrava o git-annex, terminei de instalar algumas coisas adicionais na nuboteca: ngircd (servidor irc), ushare (servidor upnp/dlna) e icecast. Modifiquei nas configurações o seguinte:

/etc/ushare.conf

USHARE_NAME=nuboteca
USHARE_IFACE=wlan0
USHARE_DIR=/var/www/nuboteca

Não habilitei o DLNA.

E consegui acessar o UPNP pelo aplicativo de DLNA no meu celular ;). Vídeos são sempre complicados, mas as imagens eu consegui acessar tranquilo.

O icecast me perguntou algumas coisas durante a própria instalação. Mantive as senhas padrão. Depois ainda mexi o nome na config:

/etc/icecast2/icecast.xml
<hostname>nuboteca</hostname>

Adicionei à home do apache na nuboteca o link para a interface web do icecast:

http://nuboteca:8000/status.xsl

E fiz um stream live com o idjc a partir da minha máquina para testar ao vivo com o pessoal. Funcionou ;)

==08/11/12==

Configurei mais algumas coisas na nuboteca: mexi mais com o icecast, instalei o mpd e o ampache (mas ainda não consegui fazer funcionar direito). O plano é subir um hotglue e acho que vou instalar um drupal+openlayers pra galera do silêncio. Copiei para o Desktop da nuboteca os arquivos recebidos pelo form via web e os dumps de sites que eu peguei.

Travei na uaifai, por enquanto vamos fazer com outro roteador e deixar a máquina como cliente, daquele jeito…

Instalando o dd-wrt no outro roteador TP-LinkWR743ND. Liso. Ficou essid VemnuVemnu e IP 192.168.2.1.

Voltando à nuboteca. Vince está experimentando com sincronização de instalações do hotglue. Eu vou instalar um drupal para o pessoal da autonomia do silêncio, que quer um site local para trabalhar com mapas. Baixei o drupal7 e os módulos admin e openlayers.

==09/11/12==

Copiando mais coisas para a Nuboteca: contribuições enviadas pelo form na web, algumas coisas do meu acervo pessoal, etc.

Tivemos (ff, vince, isabel, javier, lula) uma reunião sobre a estrutura de organização das pastas do acervo. Isabel propôs outra estrutura de organização, baseada mais no conteúdo do que no formato dos arquivos. Falei sobre as limitações da metáfora de desktop, que supõe que cada arquivo só esteja em uma pasta de cada vez. Falamos sobre alguma maneira menos estruturada de organizar acervos. Por outro lado, pensando em sincronizar redes distribuídas como é o caso da realidade da rede Mocambos, é bom ter uma organização mais estruturada para facilitar as coisas. Sugeri que talvez tenhamos dois caminhos paralelos a trabalhar: um deles é pensar uma solução genérica para sincronização de redes, a outra é encontrar uma solução local para o acervo da Nuvem.

Logo depois nos reunimos com os tutores para dar uma geral. Brazileiro acabara de voltar, então contei um pouco sobre o que fizemos nos últimos dias. Conversamos sobre o que já conseguimos fazer e possibilidades de desenvolvimento na sequência. Fiquei de documentar melhor o que fazer para uma máquina virar uma rede autônoma. Amanhã vou a Ubatuba levar as meninas, vou concentrar nisso e ver algumas referências (sistemas de gestão de documentos, e ver o projeto que ganhou o ars electronica que leslie sugeriu: tools for the next revolution).

Voltando aos testes: o segundo roteador, com a rede VemnuVemnu, está funcionando. O Samsung (que agora não se chama mais uaifai, e sim tecanubo) pegou o IP por dhcp, mas não informou ao roteador seu hostname. Achei que mais eficaz do que entender por quê seria encontrar uma solução. Atribuí um IP fixo ao samsung (192.168.2.10) e vou mexer no dnsmasq do roteador para encaminhar tudo que for "tecanubo" pra lá.
Segui isso aqui: http://cybernetnews.com/local-internal-dns-ddwrt/. Aparentemente funcionou.

Mudei alguns detalhes na configuração do ngircd, servidor IRC da nuboteca. Só detalhes, em /etc/ngircd.

Baixei o código do etherpad-lite (deixei em /media/nuboteca-ext4/ferramentas). Tentei rodar, mas antes preciso instalar algumas coisas. Vai ficar durante a noite.

$sudo apt-get install gzip git-core curl python libssl-dev pkg-config build-essential

Documentaçao do etherpad aqui https://github.com/Pita/etherpad-lite/wiki

Aa noite, reuniao geral. Ideias de conexao entre projetos...

==12/11/12==

Voltei de Ubatuba. Fiz rodar o etherpad (ver documentação em [[RedesAutonomasServicosWeb]]). Demorou um pouco para baixar as dependências, e o script de inicialização como serviço não rolou. Mas está funcionando. Fiz testes com o asterisk na minha máquina. O servidor parece subir, mas não consegui me acertar com a configuração do sip: não consegui logar um usuário. Parece que rola instalar o asterisk direto no dd-wrt (http://www.dd-wrt.com/wiki/index.php/Asterisk e http://g300nh.blogspot.com.br/2010/06/asterisk-voip-server-on-dd-wrt.html). Vou também experimentar com outras soluções de voip.

==13/11/12==

Criei um script temporário para rodar o etherpad ($etherpad-lite). Instalando o omeka, para ver se serve de alguma coisa. Instalei também o abiword. Acabei de importar um PDF para dentro do pad, rodou legal. Exportei depois para PDF também.

Estudando na minha máquina outras opções de voip. Instalei o kamailio, fork do openser. Mexendo nas configurações. Ele vem com um programinha para gerenciar, kmactl. O kamailio.cfg é confuso, tem um monte de esquemas de DB e coisas assim. Habilitei o uso do mysql no /etc/kamailio/kamctlrc, mas ele não populou o db. Procurando na web (paciência). Tutorial aqui: http://kb.asipto.com/kamailio:skype-like-service-in-less-than-one-hour. Depois de mexer nas configs, rodar o $sudo kamdbctrl create. Depois criei usuários, $sudo kmactl add usuario senha. Consegui logar no pidgin, mas não consegui fazer uma conexão entre usuários. Pelo kamailio.cfg que baixei do link, ele não roda. Vou instalar o rtpproxy antes de sair mexendo. Instalei, rodei e nada. Insisti mais um pouco, mas vou deixar para depois. Encontrei aqui um relato sobre usar o kamailio (para gerenciar registros) junto com o freeswitch: http://nil.uniza.sk/sip/kamailio-33-and-freeswitch-122-interconnection-voicemail-and-conference-services-debian-squeeze-60-64bit-tutorial.

Voltando a insistir com o Siremis, interface web para gerenciamento do kamailio. As [http://siremis.asipto.com/install/ instruções] estão quase certas, exceto nas modificações necessárias à configuração do apache:

Alias /siremis/ "/var/www/siremis-x.y.z/siremis-web/"
<Directory "/var/www/siremis-x.y.z/siremis-web/">
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
RedirectMatch ^/siremis/$ /siremis/bin/
<Files ~ "\.inc$">
Order allow,deny
Deny from all
</Files>
</Directory>

Comigo ficou assim:

Alias /siremis/ "/var/www/siremis-3.0.3/siremis/"
<Directory "/var/www/siremis-3.0.3/siremis/">
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
<Files ~ "\.inc$">
Order allow,deny
Deny from all
</Files>
</Directory>

E consegui continuar com a instalação. $make prepare e $make chown, e o resto pelo browser.

==14/11/12==

Apresentamos o projeto hoje pela manhã: serviços na rede local, organização do acervo, experimentos de sincronização e algumas ideias derivadas. À tarde ficamos algum tempo sem eletricidade. Agora há pouco instalei o supybot na nuboteca, via apt. Configurei usando o supybot-wizard. Chamei o bot de "vapor", e ativei alguns plugins. Deixei o arquivo de configuração em /opt/supybot/vapor.conf e fiz um script em /usr/local/bin chamando o supybot com essa configuração. Testado, ok. Documentação dos plugins aqui:

http://supybot.fr.cr/doc/use/plugins/index.html

==24/11/12==

Saí do Interactivos pilhado em continuar as experiências com wifi e redes locais. Passei alguns dias totalmente fora da internet, num sítio em Cunha. Configurei a rede local na Alix, montei uma rádio local e mostrei algumas coisas pra galera. Montei um sitezinho no hotglue. O pessoal no sítio demandou uma maneira de compartilhar fotos, e acabei montando um site em drupal (drupal 7, testando mais a sério pela primeira vez) no meu computador (a alix não estava com o mysql instalado). De volta a Campinas, instalei o mysql na alix e espetei ela direto na rede aqui em casa. A ideia é ir aprimorando os sistemas e em dezembro levar de novo para Cunha. Configurei um direcionamento pelo no-ip para minha rede local e configurei o roteador para mandar tudo que entrasse ali para a alix (como DMZ). Tentei acessar de fora, e aparentemente o virtua está bloqueando a porta 80. Mas o ssh continua funcionando, então consegui configurar para outra porta, 8008. Funcionou por um tempo, mas depois caiu e não consegui mais acessar (mas o SSH continuou).

Hoje deixei transmitindo uma playlist por icecast, e aproveitei para brincar um pouco com a raspberry pi. Baixei o raspbian wheezy (http://www.raspberrypi.org/downloads), gravei no cartão SD e liguei, com a saída HDMI ligada na tv. Não tinha teclado, então entrei por ssh e derrubei o raspi-config que já estava rodando na tela. Mexi um pouco no raspi-config, depois voltei pro terminal e instalei o mplayer. Mandei ele tocar o stream que saía da minha máquina e se espalhava através da alix: funcionou bem, mandando a saída de som direto pelo cabo HDMI para a TV. Já tinha pirado lá na nuvem com a ideia de usar a raspi pra fazer aparelhos estilo radinho de pilha, pra escutar automaticamente streams via icecast. Massa.

RedesAutonomasMontandoRedeAutonoma

2013-03-23T17:17:02Z

FelipeFonseca:

[[Página principal]] > [[Redes Autônomas (Felipe Fonseca e Vincenzo Tozzi-Brasil)]]

==Montando uma Rede Autônoma==

A analogia servidor/cliente, frequentemente usada para descrever a comunicação entre computadores, costuma levar a alguns equívocos de interpretação. O mais grave desses equívocos é as pessoas pensarem que seus próprios computadores só servem para acessar informação ou serviços disponíveis "na internet". A rede vira um não-lugar mistificado, uma espécie de ambiente espectral sem margens definidas onde as coisas acontecem de forma algo mágica. No entanto, toda rede tem uma materialidade: surge de processos que rodam em um ou mais computadores conectados. Esses processos compõem o que podemos chamar serviços de rede. A maioria desses serviços se baseia em uma arquitetura distribuída fundada em protocolos livres e abertos, o que significa que no limite qualquer computador ou dispositivo conectado em rede é um servidor em potencial. Isso também quer dizer que qualquer rede local, mesmo que não esteja conectada à internet, pode hospedar diversos serviços de armazenamento, compartilhamento e circulação de informação.

Este tutorial tem por objetivo demonstrar algumas dessas possibilidades, com especial ênfase na criação de serviços de rede locais com o uso de software livre. Supomos que você tenha uma familiaridade básica com o terminal de linha de comando. Vamos tratar de alguns cenários específicos:

* Transformar um computador em servidor local a partir do sistema operacional Ubuntu Linux (ou qualquer outro sistema operacional, com as devidas adaptações).
* Criar uma rede local autônoma, utilizando um sistema operacional alternativo (dd-wrt) no roteador.
* Explorar possibilidades de sincronização de arquivos em diferentes redes.

==1. Transformando seu computador em um servidor==

São inúmeros os serviços que podem ser implementados em uma rede local. Vamos tratar aqui dos que nos parecem ter um maior potencial para utilização em uma rede autônoma. Partimos do princípio de que você está em um computador rodando Ubuntu Linux. Para fazer essas primeiras configurações, você precisará uma conexão à internet, ou então de acesso a um repositório local. Uma vez que os serviços estejam configurados, a internet não será mais necessária. Também estamos considerando que já existe uma rede local, conectada a um hub ou roteador, para que outras pessoas possam acessar os serviços.

Antes de começar, rode o comando abaixo para atualizar seus repositórios:

$ sudo apt-get update

Costumamos também instalar alguns softwares como o Aptitude para facilitar a instalação de outros softwares, o SSH para acessar remotamente o computador via linha de comando e alguns softwares que podem ser úteis para monitorar e diagnosticar a rede.

$ sudo aptitude install aptitude ssh nmap iptraf wavemon

O computador vai baixar, instalar e configurar esses softwares. Você não precisa fazer mais nada.

===1.1. Servidor LAMP===

A web, ou WWW, é um dos mais versáteis serviços de rede, e justamente por isso foi uma das maiores responsáveis pela popularização da internet. Permite que se disponibilizem arquivos que podem ser acessados por qualquer navegador de internet (como o Firefox, Chrome e outros). A web baseia-se em uma linguagem estruturada chamada HTML. O servidor web mais utilizado no mundo é um software livre e aberto chamado Apache. Sua funcionalidade pode ser expandida de forma virtualmente infinita com softwares adicionais como o interpretador de hipertexto PHP e o servidor de banco de dados MySQL (esse conjunto de softwares é conhecido como LAMP - linux, apache, mysql, php). Vamos começar instalando esses softwares.

$ sudo aptitude install apache2 php5 php5-mysql mysql-server

Finalizada a instalação, você pode verificar se tudo deu certo abrindo o Firefox ou outro browser, clicando na barra de endereços dele e digitando "http://localhost" ou o IP de sua máquina (descubra o IP pelo terminal, digitando "ifconfig"). Normalmente, você será direcionado a uma página dizendo que a instalação deu certo, como "It works" ou algo parecido.

A partir do servidor LAMP, uma infinidade de serviços podem ser utilizados. Alguns exemplos são diversos sistemas livres de gestão de sites. Entre os mais conhecidos, estão:

* http://wordpress.org
* http://drupal.org
* http://mediawiki.org

Outros sistemas interessantes pela versatilidade ou porque usam poucos recursos do servidor são:

* http://wikkawiki.org
* http://hotglue.org
* http://pmwiki.org

Alguns desses sistemas necessitam configurações específicas do seu servidor LAMP (bibliotecas adicionais como php5-gd ou módulos como o mod_rewrite). Consulte a documentação dos sistemas a esse respeito.

===1.2. Servidor uPNP/DLNA===

O uPNP e o DLNA são um tipo de serviço web que permite o compartilhamento e a reprodução de arquivos multimídia. Novas gerações de televisores, videogames e outros aparelhos já trazem clientes uPNP instalados. Smartphones também contam com aplicativos específicos para acessar conteúdo via uPNP. Vamos usar o ushare para montar uma espécie de biblioteca multimídia baseada em uPNP no Linux.

$ sudo aptitude install ushare

São necessárias algumas configurações "manuais", no arquivo /etc/ushare.conf

$ sudo gedit /etc/ushare.conf

No editor, insira um nome para a biblioteca.

USHARE_NAME=nuboteca

Especifique também qual é a interface de rede pela qual o servidor se conecta. O padrão é eth0, a placa de rede física. Aqui na Nuvem, usei a placa wifi wlan0:

USHARE_IFACE=wlan0

Também é necessário informar onde os arquivos de mídia estão armazenados. No nosso caso, é:

USHARE_DIR=/home/zasf/zasf

Salve o arquivo e depois reinicie o servidor:

$sudo service ushare restart

===1.3. Servidor de bate-papo===

O IRC foi um dos primeiros formatos de bate-papo via internet a se popularizar. Por usar pouca banda de transferência de dados, funciona muito bem em lugares com conexão lenta ou instável. Os servidores de IRC também costumam exigir pouco processamento e memória, e podem ter suas funcionalidades estendidas com chatbots e outros softwares. Vamos usar o ngircd como servidor:

$sudo aptitude install ngircd

Ele já funciona por padrão, mas é interessante personalizar algumas opções, editando o arquivo de configuração.

$gksudo gedit /etc/ngircd/ngircd.conf

Vamos mudar o nome da rede, que precisa ter um ponto no meio:

Name = nuboteca.local

E também as informações de Admin:

AdminInfo1 = Nuvem
AdminInfo2 = Nuvem.tk
AdminEMail = nuvem@nuboteca

Também é interessante uma descrição sobre o servidor IRC.

Info = Servidor IRC da Nuvem

Salve o arquivo de configuração.

O ngircd tem também o MOTD (frase do dia), uma mensagem de boas-vindas aos usuários, que pode ser editada assim:

$ gksudo /etc/ngircd/ngircd.motd

Depois de salva a configuração, reinicie o servidor:

$ sudo service ngircd restart

Para testar o servidor IRC, instale algum cliente em sua máquina. O irssi, por exemplo, roda em linha de comando:

$ sudo aptitude install irssi

Já o Xhat funciona em modo gráfico:

$sudo aptitude install xchat

Testando: abra o software cliente de IRC. Vamos começar conectando ao servidor IRC. Digite:

/server localhost

Entre em uma sala de teste, digitando simplesmente

/join #teste

Qualquer outra pessoa em sua rede local já pode entrar no servidor IRC, trocando o endereço do servidor localhost pelo seu número de IP. Existem clientes de IRC para virtualmente todas as plataformas de computação. Além dos já citados para GNU/Linux, há o KVIrc para Mac OS e o próprio Xchat para Windows.

===1.4. Rádio online===

O Icecast é um software de stream multimídia, que pode ser usado para transmissões ao vivo de áudio ou vídeo. Instale o servidor com:

$sudo aptitude install icecast2

A configuração do Icecast fica em um arquivo XML. Vamos editá-la:

$gksudo gedit /etc/icecast/icecast.xml

É bom mudar as senhas que vêm por padrão:


<source-password>novasenha</source-password>

<relay-password>novasenha1</relay-password>


<admin-user>admin</admin-user>
<admin-password>novasenha2</admin-password>

Mude também o hostname para coincidir com o nome de seu computador:

<hostname>nuboteca</hostname>

Em geral, não é necessário criar uma configuração complexa com nomes de usuário acessados a transmissões específicas. Se for necessário, consulte os comentários no próprio arquivo de configuração, na seção <mount>.

Depois de salvar o arquivo de configuração, reinicie o servidor icecast com

$sudo service icecast2 restart

O Icecast possui uma interface web, acessível pelo browser em http://localhost:8000.

A transmissão via Icecast exige softwares específicos. Alguns exemplos são o darkice (em linha de comando, muito leve), darksnow (interface gráfica simples) e idjc (solução mais complexa, com gerenciamento de playlists e outros recursos). Consulte os tutoriais publicados pelo estudiolivre sobre a transmissão via Icecast: [http://www.estudiolivre.org/tiki-index.php?page=Darksnow+e+Darkice%3A+Tutorial+de+uso Darksnow+Darkice], [http://www.estudiolivre.org/tiki-index.php?page=IDJC IDJC]

O Icecast também pode ser usado para transmissão de vídeo. Para isso, utilize algum software como o Theorur: http://theorur.sarava.org

===1.5. Outros serviços===

Com os softwares citados acima, já temos um pacote de serviços de rede bastante abrangente: web, acesso a acervo multimídia, bate-papo e transmissão ao vivo. Havendo interesse podem ser implementados muitos outros sistemas, como o editor colaborativo de documentos Etherpad, o gerenciador e reprodutor de música MPD, o servidor de telefonia sobre IP Asterisk, etc. O interessante é que esse conjunto de serviços seja adequado às necessidades locais da rede.

==2. A rede local==

Como mencionado antes, a internet se estrutura a partir de uma série de protocolos abertos que lhe garantem uma arquitetura distribuída. O mais importante entre eles é o Conjunto de Protocolos da Internet, conhecido como TCP/IP. Ele é composto de duas partes: o [https://pt.wikipedia.org/wiki/Transmission_Control_Protocol TCP] (Protocolo de Controle de Transmissão)e o [https://pt.wikipedia.org/wiki/Protocolo_de_Internet IP] (Protocolo Interredes). O TCP divide em pequenos pacotes de dados a informação a ser transmitida entre computadores, enquanto o IP realiza a identificação, localização e entrega desses dados. Qualquer situação que envolva a conexão de um ou mais computadores a uma rede local ou à internet se baseia na atribuição de endereços IP a cada equipamento envolvido. Quando seu computador está em uma rede ele recebe um endereço IP, uma sequência de quatro séries de números como 192.168.10.108, por exemplo. Esse é o endereço de seu computador na rede, a maneira pela qual os outros computadores podem encontrá-lo. O roteador ou o modem também têm seus próprios endereços IP, e é dessa forma que seu computador vai enviar e receber dados da internet. O mesmo se repete com os IPs em uma rede local: cada computador tem um endereço IP, através do qual os outros computadores podem encontrá-lo.

Voltemos à nossa experiência com um servidor local. Uma vez instalados os serviços em alguma máquina, eles podem ser acessados diretamente pelo IP daquela rede desde qualquer outra máquina. Por exemplo, se o IP da máquina é 192.168.10.10, é esse endereço (http://192.168.10.10) que você vai digitar no navegador de internet em qualquer outra máquina da rede para acessar o servidor LAMP dela. Da mesma forma, é esse IP que você vai usar para se conectar pelo seu cliente de IRC (/server 192.168.10.10) e para verificar pelo navegador se existe alguma transmissão acontecendo pelo Icecast (http://192.168.10.10:8000).

2.1. DNS

O conjunto de protocolos TCP/IP funciona muito bem entre máquinas, porque assegura que a informação seja transferida do computador X para o Y. Mas para humanos ele tende a ser muito complexo. Seria muito trabalhoso se, por exemplo, precisássemos decorar o endereço IP de cada site que costumamos acessar. Inicialmente, quando os servidores conectados em rede eram em relativamente poucos, se resolvia essa situação com o arquivo HOSTS.txt. Era um arquivo de texto simples, contendo um atalho legível para cada um em uma lista de servidores do mundo inteiro. Quando um computador se conectava à internet, ele baixava a versão mais recente do arquivo HOSTS de um servidor predeterminado. Até hoje, grande parte dos sistemas operacionais ainda conta um arquivo HOSTS local. Com a gradual multiplicação dos servidores na internet, entretanto, essa solução se comprovou inviável, porque dependia em demasiado de um único ponto. Para estabelecer uma solução escalável, foi criado o Sistema de Nomes de Domínio ([https://pt.wikipedia.org/wiki/Domain_Name_System DNS]. Ele atribui a cada endereço IP um atalho legível, com base em uma convenção internacional gerenciada pela Corporação de Nomes e Números Atribuídos da Internet (ICANN). A estrutura de nomes de domínio atribui um código para cada país, e subcódigos para tipos de sites. Por exemplo, sites brasileiros podem usar domínios terminados em .br, chilenos terminam em .cl, espanhóis em .es e por aí vai. Da mesma forma, um site comercial pode usar um domínio terminado em .com.br, enquanto um blog pode usar um endereço .blog.br. São definições algo arbitrárias: para garantir sua confiabilidade, o sistema DNS tem uma estrutura hierárquica que precisa ser definida em consenso entre diversos atores institucionais. Ainda assim, usar o sistema DNS é mais fácil do que memorizar cada IP, além de oferecer outras vantagens.

No caso de uma rede autônoma, a utilização de endereços IP pode funcionar em determinados contextos. Entretanto, se a ideia é envolver pessoas que não tenham necessariamente um perfil técnico, trabalhar com o sistema DNS pode facilitar as coisas. Isso pode ser feito de várias formas. Antes de mais nada, precisamos nos assegurar de que o servidor sempre vai utilizar o mesmo IP. Isso é chamado "IP estático", em oposição ao "IP dinâmico" (quando o computador pede um endereço IP ao roteador e recebe um endereço aleatório a cada vez que se conecta). O IP estático pode ser configurado manualmente no servidor, ou então pode-se configurar o roteador para sempre atribuir a ele o mesmo endereço IP. É necessário saber de antemão algumas informações da rede local, como faixa de IPs normalmente utilizada, endereço do gateway (o computador ou roteador que faz a conexão com a internet) e máscara de rede. Aqui na nossa rede local, sabemos que o roteador costuma atribuir endereços IP na faixa 192.168.10.*, que o gateway é 192.168.10.1 e a máscara de rede é 255.255.255.0. Vamos definir que o endereço do servidor é 192.168.10.10. Para isso, clicamos no ícone de redes (próximo ao relógio do sistema) e logo em "definições de rede". Escolha a opção "com fio" (supondo que o servidor está conectado ao roteador por um cabo de rede), "opções" e depois "configurações de IPv4". Em "método", escolha Manual. Em "endereços", clique em "adicionar" e digite 192.168.10.10 no endereço, 255.255.255.0 em máscara de rede e 192.168.10.1 no gateway. O servidor DNS geralmente é o mesmo do gateway, 192.168.10.1.

2.1.1. /etc/hosts

Como comentamos acima, mesmo com a adoção do sistema DNS, em geral todo computador ainda tem um arquivo HOSTS. A maneira mais simples de criar atalhos para endereços IP é mexendo na definição de HOSTS nas máquinas da rede local. Isso só funciona em redes pequenas, com poucos computadores fixos. É uma solução adequada para laboratórios de informática em escolas, para telecentros e lan houses.

No caso do GNU/Linux, o arquivo fica em /etc/hosts. Vamos dizer que queremos atribuir o atalho "nuboteca" ao computador que utiliza o endereço 192.168.10.10. Para isso, precisamos ir a cada uma das máquinas da rede e editar o arquivo.

$gksudo gedit /etc/hosts

Adicione a seguinte linha em algum lugar do arquivo:

192.168.10.10 nuboteca

E pronto. Nesse computador, você já deve conseguir acessar o servidor simplesmente usando o atalho "nuboteca". Para testar, abra o navegador de internet e digite "http://nuboteca" no endereço.

2.1.2. DNS

Em redes mais dinâmicas, às quais diferentes pessoas se conectem com seus computadores, smartphones ou tablets, configurar o arquivo hosts em todos começa a ficar complicado. A solução é recorrer ao DNS. A configuração de DNS costuma ser complexa, mas existe um software chamado DNSmasq que aplica regras locais antes de encaminhar chamadas de DNS para um servidor de nomes propriamente dito. Em outras palavras, ele permite criar uma lista de nomes a endereços de IP específicos dentro de uma rede local. Os nomes podem ser definidos pelo próprio DNSmasq, ou pelo nome particular de cada máquina. Todos os pedidos de endereços que não estejam nessa lista de nomes são encaminhados a um servidor de DNS.

Não vamos detalhar a configuração do DNSmasq em um servidor local, porque isso envolveria de qualquer forma modificar a configuração do roteador que informa aos computadores que se conectam qual é o servidor DNS indicado pela rede local. Isso pode ser feito, mas optamos por aprofundar as mofidicacoes ao roteador, na próxima seção. Quem preferir trabalhar com o DNSmasq no próprio servidor local pode checar a [http://www.thekelleys.org.uk/dnsmasq/doc.html documentação do próprio software].

2.1.3. Roteador

Os roteadores usados corriqueiramente para conectar redes locais à internet têm frequentemente um grande potencial que é limitado artificialmente. Em outras palavras, são equipamentos que permitem fazer muito mais do que seus fabricantes permitem. Para habilitar essas possibilidades, existem sistemas operacionais (também chamados de firmwares) alternativos. Os mais conhecidos são o OpenWRT e o DD-WRT. Aqui vamos trabalhar com o DD-WRT. Não é qualquer roteador que permite a instalação de firmware alternativo, então recomendamos verificar a compatibilidade no site do [http://dd-wrt.com DD-WRT].

Os roteadores que utilizamos aqui na Nuvem eram da marca TP-Link, modelo WR743ND. Depois de encontrar na internet e baixar o arquivo de instalação do DD-WRT, tratamos de instalá-lo no roteador. Abrimos o painel de administração (no nosso caso, disponível pelo navegador de internet no endereço http://192.168.1.1), e lá encontramos a opção de atualização de firmware. Escolhemos o arquivo, fizemos o upload e pronto.

Depois de um ou dois minutos reiniciando, o roteador já criou uma nova rede wifi, aberta. Conectamos por cabo para acessar o novo painel de controle (no mesmo endereço acima). Na guia Setup, modificamos o nome do roteador e seu hostname. Na guia Wireless, definimos as configurações da rede sem fio (no nosso caso, uma rede sem criptografia chamada NuvemNuvem). Na guia Services, habilitamos as opções "DNSMasq", "Local DNS" e "No DNS Rebind". Depois de salvar e aplicar as configurações, a rede já estava devidamente configurada. O roteador passou a atribuir o hostname (nome particular de cada computador) como atalho de IP via DNS. Dessa forma, nosso servidor já pode ser acessado dentro da rede simplesmente com o nome "nuboteca".

No caso em que não haja acesso à Internet "real", é muito comum querer que todos as tentativas de ver sites sejam direcionados para o nosso servidor. Assim, uma pessoa tentando acessar http://nytimes.com ou http://google.com ou qualquer outro site, será direcionado para http://nuboteca. Para isso, basta uma linha de configuração do dnsmasq no servidor:
<pre>address=/#/nuboteca</pre>

O # representa qualquer site, e nuboteca é o endereço para qual os pedidos são redirecionados.

Uma consequência não muito desejável desse redirecionamente é que o browser continua com o endereço pedido, ou seja, mesmo ao navegar a nuboteca, o endereço na caixinha de endereços continua como http://google.com. Para resolver isso, a página index.html - onde vão parar todos os pedidos - faz um redirecionamento imediato para http://nuboteca/index.php. Assim o endereço no browser passa a ser http://nuboteca/ Abaixo está o código usado no arquivo index.html

<pre>
<html>
<header>
<meta http-equiv="refresh" content="0;url=http://nuboteca/index.php">
</header>
<body>
Você está sendo redirecionado...
</body>
</html>

</pre>

—-

'''TODO:''' Rede verdadeiramente autônoma com Modo AP. Mesh + OSLR. Ressalvas e limitações.

RedesAutonomasServicosWeb

2012-11-14T21:51:55Z

FelipeFonseca: /* IRC */

[[Página principal]] > [[Redes Autônomas (Felipe Fonseca e Vincenzo Tozzi-Brasil)]]

Serviços instalados na nuboteca:

==Rede NuvemNuvem, servidor "nuboteca"==

===Web===

Servidor LAMP: apache + php5 + mysql

CMSs, por enquanto: [http://nuboteca/interactivos wiki interactivos], [http://nuboteca/interactivos hotglue silencios].

Acervo da Nuvem disponível em http://nuboteca/nuboteca/.

Estudando com Ricardo Brazileiro um protótipo de site com nodejs para listar e buscar nos arquivos do acervo.

TODO: maneiras simples para acessar o conteúdo. Pode ser útil isso: como criar webapps para android (inclui dicas de CSS para plataformas móveis: http://ofps.oreilly.com/titles/9781449383268/index.html )

===uPNP===

Servidor uPNP disponibilizando o conteúdo do HD externo.

===Sync===

Git-annex. Repositório disponível para clonagem. Seguir as instruções [http://nuboteca/interactivos/index.php/Redes_Aut%C3%B4nomas_%28Felipe_Fonseca_e_Vincenzo_Tozzi-Brasil%29#Copiando.2FClonando_um_repositorio aqui].

===IRC===

Servidor (ngircd) rodando. Clientes para linux, mac e windows disponíveis [http://nuboteca/nuboteca/ferramentas/irc_clientes/ aqui].

====Ircbot====

Um bot de IRC (supybot) chamado "vapor" está configurado para se conectar ao canal #nuvem do servidor IRC local. Para ativá-lo, é só rodar $vapor. Ele já está com alguns plugins ativados.

===Icecast===

Stream de áudio (e vídeo também, em tese).

====Documentação adicional do Icecast====

Icecast http://www.estudiolivre.org/tiki-index.php?page=Icecast&highlight=icecast
IDJC http://www.estudiolivre.org/tiki-index.php?page=IDJC&highlight=idjc
Darksnow e Darkice http://www.estudiolivre.org/tiki-index.php?page=Darksnow+e+Darkice%3A+Tutorial+de+uso&bl

===Etherpad===

Editor de texto colaborativo. Disponível em http://nuboteca:9001

(precisa ser chamado pelo terminal: $etherpad-lite)

===Testes e experimentação===

* MPD + Ampache. MPD instalado, mas não consegui acessar direito nem pelo Ampache (http://nuboteca/ampache/) e nem pelo gmpc.
* Omeka, sistema de gerenciamento de acervos. Instalado, mas pareceu engessado demais. Está em http://nuboteca/sites/omeka/.
* Servidores de voz sobre IP. Testes com asterisk (pouco ou nada), kaimilo, antigo openser (registro de usuários ok, ligação não). Tentando gerenciar o kaimilo com a GUI para web, Siremis. Nem rodou ainda.

==Rede VemnuVemnu, servidor "tecanubo"==

Não pegou o hostname automaticamente, mas configurei um IP fixo para o servidor (192.168.2.10) e configurei o Dnsmasq do roteador para apontar para ele.

Acesso ao servidor: tecanubo (192.168.2.10), root//lanovale.

===Web===
Apache, PHP5, Mysql

===Sync===
Git-Annex

RedesAutonomasPlanejando

2012-10-30T23:00:01Z

FelipeFonseca:

Debulhando um plano tentativo:

'''Hardware''' (estação) – configuração de sistema e testes básicos. De 2 a 5 de novembro. Implementar estações-base sem fio, em modo infraestrutura e com servidor DHCP, na ''raspberry PI'' da Nuvem. Testar a estabilidade do sistema, consumo de energia e condições de reinicialização em caso de queda de energia.

Posteriormente, se houver tempo também podemos configurar o ambiente em:
* beagleboard da Nuvem
* um computador usado (efeefe está levando um laptop velho)
* servidor web em celular android, viável?
efeefe também vai levar (no domingo, dia 4) uma estação já configurada rodando em um hardware Alix3d3.

'''Software'''. 4 a 8 de novembro. Configurar serviços nas estações-base.
* captura de tráfego via DNSmasq
* servidor web com site local (Django, Hotglue, HTML puro) + versões mobile
* servidor IRC.
* ircbots, etc.
* Servidor multimídia: DLNA/uPnP
* voz/telefonia
* rádio (icecast)
* sincronização de conteúdo entre estações remotas (git-annex)
* repositórios debian

'''Clientes'''. 7 a 10 de novembro.
* definir, empacotar e disponibilizar em versão estática softwares necessários para acessar os serviços da Alix em todas as plataformas possíveis.

'''Curadoria de conteúdo''' relacionado a autonomia. 2 a 12 de novembro.
* artigos, ebooks, tutoriais
* vídeos
* programas de rádio
* software + documentação
* dump em texto da wikipedia (viável?)

'''Outras atividades'''
* montagem das versões finais das estações-base. 10 a 17 de novembro.
* integração via software com outros projetos acontecendo durante o Interactivos: rede de sensores, etc.
* Ritualística de troca e sincronização entre estações. 1 a 17 de novembro.
* Transformação das estações em objetos (físicos) ritualísticos.

RedesAutonomasPlanejando

2012-10-30T22:56:48Z

FelipeFonseca:

Debulhando um plano tentativo:

'''Hardware''' (estação) – configuração de sistema e testes básicos. De 2 a 5 de novembro. Implementar estações-base sem fio, em modo infraestrutura e com servidor DHCP, na ''raspberry PI'' da Nuvem. Testar a estabilidade do sistema, consumo de energia e condições de reinicialização em caso de queda de energia.

Posteriormente, se houver tempo também podemos configurar o ambiente em:
* beagleboard da Nuvem
* um computador usado (efeefe está levando um laptop velho)
* servidor web em celular android, viável?
efeefe também vai levar (no domingo, dia 4) uma estação já configurada rodando em um hardware Alix3d3.

'''Software'''. 4 a 8 de novembro. Configurar serviços nas estações-base.
* captura de tráfego via DNSmasq
* servidor web com site local (Django, Hotglue, HTML puro) + versões mobile
* servidor IRC.
* ircbots, etc.
* Servidor multimídia: DLNA/uPnP
* voz/telefonia
* rádio (icecast)
* sincronização de conteúdo entre estações remotas (git-annex)
* repositórios debian

'''Clientes'''. 7 a 10 de novembro.
* definir, empacotar e disponibilizar em versão estática softwares necessários para acessar os serviços da Alix em todas as plataformas possíveis.

'''Curadoria de conteúdo''' relacionado a autonomia. 2 a 12 de novembro.
* artigos, ebooks, tutoriais
* vídeos
* programas de rádio
* software + documentação
* dump em texto da wikipedia (viável?)

Outras atividades
* montagem das versões finais das estações-base. 10 a 17 de novembro.
* integração via software com outros projetos acontecendo durante o Interactivos: rede de sensores, etc.
* Ritualística de troca e sincronização entre estações. 1 a 17 de novembro.
* Transformação das estações em objetos (físicos) ritualísticos.

RedesAutonomasPlanejando

2012-10-30T22:53:41Z

FelipeFonseca:

Debulhando um plano tentativo:

'''Hardware''' (estação) – configuração de sistema e testes básicos. De 2 a 5 de novembro. Implementar estações-base sem fio, em modo infraestrutura e com servidor DHCP, na ''raspberry PI'' da Nuvem. Testar a estabilidade do sistema, consumo de energia e condições de reinicialização em caso de queda de energia.

Posteriormente, se houver tempo também podemos configurar o ambiente em:
* beagleboard da Nuvem
* um computador usado (efeefe está levando um laptop velho)
* servidor web em celular android, viável?
efeefe também vai levar (no domingo, dia 4) uma estação já configurada rodando em um hardware Alix3d3.

'''Software'''. 4 a 8 de novembro. Configurar serviços nas estações-base.
* captura de tráfego via DNSmasq
* servidor web com site local (Django, Hotglue, HTML puro) + versões mobile
* servidor IRC.
* ircbots, etc.
* Servidor multimídia: DLNA/uPnP
* voz/telefonia
* rádio (icecast)
* sincronização de conteúdo entre estações remotas (git-annex)
* repositórios debian

'''Clientes'''. 7 a 10 de novembro.
* definir, empacotar e disponibilizar em versão estática softwares necessários para acessar os serviços da Alix em todas as plataformas possíveis.

'''Curadoria de conteúdo''' relacionado a autonomia. 2 a 12 de novembro.
* artigos, ebooks, tutoriais
* vídeos
* programas de rádio
* software + documentação (efeefe está baixando um mirror dos repositórios do raspbian e das versões i386 e amd64 do debian stable)
* dump em texto da wikipedia (viável?)

Outras atividades
* montagem das versões finais das estações-base. 10 a 17 de novembro.
* integração via software com outros projetos acontecendo durante o Interactivos: rede de sensores, etc.
* Ritualística de troca e sincronização entre estações. 1 a 17 de novembro.
* Transformação das estações em objetos (físicos) ritualísticos.

RedesAutonomasPlanejando

2012-09-28T16:11:51Z

FelipeFonseca:

# Hardware (estação) – configuração e testes básicos. 3 a 5 de novembro. Implementar estações-base via wifi em modo infraestrutura e com servidor DHCP, em:
## um computador usado
## alix (já pré-configurada)
## beagleboard da Nuvem
## raspberry PI, se conseguirmos uma
## servidor web em celular android, viável?
# Software. 5 a 10 de novembro. Configurar os serviços nas estações-base.
## captura de tráfego via DNSmasq
## servidor web com site local (Django, Hotglue, HTML puro) + versões mobile
##servidor IRC
## ircbots, etc.
## Servidor multimídia: DLNA/uPnP
## voz/telefonia
## rádio (icecast)
## sincronização de conteúdo entre estações remotas
# Clientes. 8 a 10 de novembro.
definir, empacotar e disponibilizar em versão estática softwares necessários para acessar os serviços da Alix em todas as plataformas possíveis.
# Curadoria de conteúdo relacionado a autonomia. 1 a 12 de novembro. Será precedido de uma chamada online lançada em outubro, para sugestões de inclusão de conteúdo.
## artigos
## vídeos
## programas de rádio
## software + documentação
## dump em texto da wikipedia (viável?)
# montagem das versões finais das estações-base. 10 a 17 de novembro.
# Ritualística de troca e sincronização entre estações. 1 a 17 de novembro.
# Transformação das estações em objetos (físicos) ritualísticos.

RedesAutonomasPlanejando

2012-09-28T16:08:43Z

FelipeFonseca: Criou página com ' 1) Hardware (estação) – configuração e testes básicos. 3 a 5 de novembro. Implementar estações-base via wifi em modo infraestrutura e com servidor DHCP, em: um comp...'

1) Hardware (estação) – configuração e testes básicos. 3 a 5 de novembro. Implementar estações-base via wifi em modo infraestrutura e com servidor DHCP, em:
um computador usado
alix (já pré-configurada)
beagleboard da Nuvem
raspberry PI, se conseguirmos uma
servidor web em celular android, viável?
2) Software. 5 a 10 de novembro. Configurar os serviços nas estações-base.
captura de tráfego via DNSmasq
servidor web com site local (Django, Hotglue, HTML puro) + versões mobile
servidor IRC
ircbots, etc.
Servidor multimídia: DLNA/uPnP
voz/telefonia
sincronização de conteúdo entre estações remotas
3) Clientes. 8 a 10 de novembro.
definir, empacotar e disponibilizar em versão estática softwares necessários para acessar os serviços da Alix em todas as plataformas possíveis.
4) Curadoria de conteúdo relacionado a autonomia. 1 a 12 de novembro. Será precedido de uma chamada online lançada em outubro, para sugestões de inclusão de conteúdo.
artigos
vídeos
programas de rádio
software + documentação
dump em texto da wikipedia (viável?)
5) montagem das versões finais das estações-base. 10 a 17 de novembro.
6) Ritualística de troca e sincronização entre estações. 1 a 17 de novembro.
7) Transformação das estações em objetos (físicos) ritualísticos.

Projetos Interactivos Nuvem

2012-09-28T16:04:00Z

FelipeFonseca: /* Redes Autônomas (Felipe Fonseca e Vincenzo Tozzi-Brasil) */

''ATENÇÃO: a sugestão do perfil de colaboradorxs mencionada aqui não é excludente. Cada colaboradorx poderá escolher as propostas do seu interesse, independentemente dos seus conhecimentos técnicos.''

== '''Bioconstrução - Grupo Fora (Bruna Maresch, Camila Argenta e Gabriel Scapinelli-Brasil)''' ==

A proposta de trabalho a ser realizada durante a residência em Visconde de Mauá consiste na criação de estruturas orgânico-vegetais a partir de técnicas de bio-construção, formando praças ajardinadas inspiradas em um estudo de elementos animais/vegetais da região. Da mesma forma, criar dispositivos de compartilhamento destes espaços, tornados sensíveis, a partir de tecnologias móveis.

'''Perfil dos colaboradores:''' Pessoas com disposição para explorar o local, trabalhar com a terra, escavar/plantar, com conhecimentos em edição, programação de sites.

== '''Redes Autônomas (Felipe Fonseca e Vincenzo Tozzi-Brasil)''' ==

O projeto trata do desenvolvimento protótipos para a criação de redes autônomas, que possibilitem a troca de conteúdos digitais em áreas isoladas ou com pouca conectividade. Está articulado nos eixos hardware, software, acesso e conteúdo. Relaciona-se com projetos correntes dos autores (ZASF e Rede Mocambos).

[[RedesAutonomasPlanejando]]

'''Perfil dos colaboradores:''' É interessante ter pelo menos 1 colaboradorx com perfil mais técnico, com conhecimento de administração de sistemas GNU/Linux,
shell scripting, sistemas embarcados e afins. Habilidades esperadas de outrxs colaboradorxs são conhecimento de web(sistemas e front-end), e pesquisa/compilação/redação de conteúdo.

== '''Cybercoria (Lot Amorós-Espanha)''' ==

La anemocoria (anemo=viento; coro=alejarse, cambiar de lugar) es el fenómeno de dispersión de semillas por la acción del viento, otorgando a las plantas la libertad de conquistar nuevos ambientes. El proyecto Cybercoria rescata técnicas de la cibernética y la robótica a través de vehículos aéreos
no tripulados para la dispersión de semillas. ¿Pueden los robots voladores entrar en simbiosis y extender las capacidades de reproducción de las plantas? ¿Pueden transformar el paisaje en un territorio ciborg?

'''Perfil dos colaboradores:''' Personas interesadas en: Drones o vehículos aéreos no tripulados; botánica, biología, agricultura de precisión; sistemas cibernéticos y orgánicos; integrar la tecnología en la naturaleza.

== '''Shadow Dance (Mikko Lipiäinen-Finlândia)''' ==

Shadow Dance is a tool that helps adjusting dynamically the lighting conditions for garden plants to perform optimal photosynthesis by luring humans to cast shadows in garden space. A device to be developed measures the amount of light energy during the day and expresses the plants need of shadow/light by an intuitively understandable signal. The lesser the need for shadow/light the weaker the signal. The intuitive and playful nature of the signal lures humans to adjust lighting conditions.

'''Perfil dos colaboradores:'''-gardener/biologist with a knowledge of photosynthesis and experience on measuring it with variety of methods
-electronics engineer/maker with experience of Arduino microcontroller and Pure Data programming.

== '''Sistema de monitoramento ambiental do-it-together (Sibel Deren Guler-Estados Unidos/Turquia)''' ==

I propose to create a system of do-it-together environment monitoring modules that indicate and log data about properties such as water, soil and air quality. The modules will be powered by rechargeable batteries and can be charged by a hand-powered device (with solar panel backup power), located in a public venue for everyone to access. When the power station is not used for the batteries it can charge low power appliances such as cell phones. The system will empower citizens with the ability to measure the quality of their environment and create sustainable communication of this information.

'''Perfil dos colaboradores:'''I will be working with lab mates at Carnegie Mellon and partners at Harvard to do preliminary research and testing for the project. I may need help from some local builders and makers. I also have a few friends in Brazil who have offered to help me figure out what I would need.

== '''Projeto local convidado: Autonomia do silêncio (Mariana Quinteiro-Brasil)''' ==

Este trabalho busca associar duas formas de autonomias envolvendo comunicação e geração de energia. A primeira versa sobre a autonomia pessoal da escuta, através da valorização do silêncio, em locais de grande altitude e silêncio absoluto, de fundamental importância para a compreensão do modo de vida na roça, com conexão com os ciclos naturais. A segunda incorpora a autonomia de um estúdio de gravação musical ao ar livre, utilizando o benefício dessas formações rochosas de excelente amplificação, efeito e retorno que propiciem a gravação de músicos da região.

'''Perfil dos colaboradores:'''Moradores locais com bom empenho em auxiliar no perfil da montagem dos equipamentos de áudio-vídeo, no esúdio rústico de gravação ao ar livre e na filmagem e edição do material final de audiovisual.