Kodi (XBMC) i Rpi (Raspberry)

Bon dia! Hui toca parlar del Kodi. Si, si Kodi, el que tota la vida ha sigut XBMC però ara ha canviat de nom. El canvi de nom és perquè en un principi aquest reproductor es va crear per a la XBox: Primer es deia Xbox Media Player, després va passar a Xbox Media Center (XBMC) i ja al final el nom s’ha quedat obsolet per a la funció que fa. Així que a partir de la v14 passa a ser Kodi.

Després d’aquesta xicoteta introducció anem a seguir…Kodi està disponible per a múltiples plataformes però ens centrem en Raspberry. Hi ha dos distribucions (que jo conega) amb aquest software: OpenELEC i OSMC, de les quals m’he decidit per OpenELEC. Aquesta elecció no ha sigut per res en especial, simplement perquè m’ha paregut veure més info al respecte o perquè porta més temps ‘al mercat’ i per a mi això suposa més estabilitat.

La instal·lació d’aquesta distro és molt senzilla, anar a la seva web oficial, baixar-se la imatge corresponent i ‘cremar-la’ a la SD. IMPORTANT: Rpi i Rpi2 no utilitzen la mateixa imatge. Com la funció d’aquest dispositiu és reproduïr imatge/música/video del NAS no ens importa molt la capacitat de la SD, en poder ‘cremar’ la imatge ja és suficient.

Anem al tema: Tot açò és per a poder veure per una TV sense connectivitat el contingut multimèdia del NAS. Si tens una Smart TV no fa falta que seguixques llegint més, si tens una TV capaç de reproduïr contingut via upnp val la pena que seguixques llegint ja que aquest ‘aparatet’ et servirà per a més (com per exemple escoltar radio via internet, veure TV online, youtube, evernote, jugar a emulador de mame/nes,…) ara que he comentat aquestes utilitats igual si tens Smart TV també voldràs canviar jeje.

La connectivitat entre Rpi i TV està clara: connectar el cable HDMI entre Rpi i TV, si tens un port USB lliure a la TV pots alimentar la Rpi amb aquest port.
La connectivitat entre Rpi i la xarxa: Pots utilitzar el cable ethernet o posar-li un adaptador Wifi USB, jo he provat un xicotet de Belkin i el OpenELEC l’ha reconegut sense fer jo res. Després s’accedix a les opcions de sistema de OpenELEC (hi ha que diferenciar entre opcions de sistema de OpenELEC i opcions de sistema de Kodi), es tria la xarxa que es vol i es configura (si tens una clau de xarxa que tinga simbols extranys com per exemple un % pot ser no et connecte, a mi m’ha passat i ho he tingut que canviar).

Ara ja tenim la Rpi connectada a la TV, la TV en marxa i vegent per pantalla el Kodi. Ja està! No, encara no. Com ‘maneje’ ara això? Es pot interactuar amb Kodi de 3 formes diferents (que jo conega):

  • Teclat: Li claves un teclat USB i a rodar!
  • Mòbil: Hi ha aplicacions per a aindroid i iphone que controlen el Kodi via wifi, no ho he provat però supose que serà connectar-se a la mateixa xarxa, configurar el dispositiu a controlar (via IP o automàticament) i a rodar!
  • ‘Mando a distancia’: Segurament és aquesta la opció que ens quedem, un teclar per damunt la taula no queda be, tenir que dependre del mòbil no està mal però no acaba d’agradar molt, però tindre el ‘mando’ si! En aquest punt podem diferenciar 2 subapartats:
    • ‘Mando’ dedicat: La TV té un ‘mando’, el DVD/Homecinema/… en té un altre, aleshores la Rpi en tindrà un altre, (no va a ser menys!). Hi ha receptors IR USB per la xarxa compatibles per a Kodi, podeu buscar a Google però jo he descartat aquesta opció perquè no m’ha fet falta.
    • ‘Mando’ de la TV: Controlar el Kodi amb el ‘mando’ de la TV seria la millor opció, no? Doncs si que es pot! A la versió 1.0 del HDMI (si no m’enganye de versió) va apareixer el CEC, amb el qual la comunicació HDMI ha passat a ser bidireccional: La TV rep la senyal de video i so però també envia senyal (les tecles que es presionen al ‘mando’).

Després d’aquesta explicació hem escollit interactuar amb Kodi mitjantçant el comandament de la TV. Qualsevol TV que tinga HDMI segurament serà compatible amb CEC. Segons la marca de la tele el CEC es nombra de forma diferent (LG:SYMLINK, SAMSUNG:ANYNET, SONY:BRAVIA LINK,…) però fan la mateixa funció. Per a comprovar si està configurat correctament sols tenim que pulsar els cursors del comandament i veure si es mou el menú del Kodi, si es mou es que per defecte està activat, si no es mou es que ho tens que activar. He provat en LG i automàticament ho reconeix, en canvi en Samsung he tingut que activar aquesta opció pulsant el botó de SYMLINK i seleccionar el dispositiu.

Ara el primer pas és comprovar si tenim connectivitat a la xarxa accedint a les propietats del sistema de OpenELEC, si tenim wifi la tindrem que configurar. Ja que estem en aquest apartat també va be habilitar l’accés SSH al sistema (després ens farà falta). Es pot canviar el nom del dispositiu, fer un backup, restaurar,…

El següent pas és configurar els accesos als continguts. Al NAS està configurat el servici de UPNP/DLNA (no és el mateix un protocol que l’altre, el segón deriva del primer i és un poc més restrictiu en alguns temes però per a un usuari normal casi que podriem que si no és el mateix… es pareix prou), aleshores el Kodi l’utilitzarem com a client upnp. Afegim els accesos upnp tant a la música com al video o imatge, no ho explique perquè és bastant fàcil.

L’últim pas és comprovar que funciona correctament!

Aquesta ha sigut una explicació ‘per damunt’ o poc tècnica del tema, ho he intentat encarar més a entendre de que va açò que a l’apartat tècnic del ‘açò’.

No ho he comentat però crec que el millor és utilitzar un teclat USB per a la primera vegada que es posa en marxa el sistema, així podem configurar més ràpidament els accesos, la configuració de la wifi, configuració del sistema,…. jo no ho he fet i he invertit més temps configurant la wifi, els accesos,…

Per a apartats més tècnics sempre tenim les wikis:
– Kodi: http://kodi.wiki/
– OpenELEC: http://wiki.openelec.tv/index.php/Main_Page

Preparant el nostre equip (WinXP) per a programar app’s per a smartphones amb Cordova

Bones! Quí no ha sentit parlar de Cordova? I no dic la ciutat d’Andalusia, sino l’entorn de programació que ens dona la possibilitat de compilar una mateixa app tant per a iOS, Android, Firefox, Windows phone,…. Cordova té un germà (per ara encara és un germà bessó) anomenat Phonegap. En qué es diferèncien? doncs per ara en res, solament en que Phonegap és d’Adobe i Cordova si no em falla la memòria és d’Apache (o està baix la llicència d’Apache). La historia és que Cordova ho va crear l’empresa Nitobi i més tard ho va comprar Adobe amb la condició que sigués lliure i així aparegueren les dues rames del projecte. Per ara són igual, però igual al cap d’uns anys comencen a eixir les primeres diferències.

A part Adobe té una ferramenta de compilació on-line: Adobe PhoneGap Build, a la qual et pots registrar gratuïtament amb opció de tenir un projecte a l’àmbit privat i tots els següents de forma pública. Si vols tenir més projectes privats ja tens que anar en diners per davant 😛

El que no he dit abans és el llenguatge de programació: El necessari per a programar una pàgina web, exacte! Tu dissenyes una web amb HTML5 + CSS3 + Javascript i Cordova ho empaqueta per a que ho pugues executar al smartphone. Bàsicament és un webview, no té més història si no fos perquè es pot interactuar amb el dispositiu. Em referisc a que es pot utilitzar la càmera, bluetooth, gps, comprovar l’estat del dispositiu,… amb plugins que han creat tant el mateix equip de Cordova/Phonegap com terceres persones.

No he programat mai en llenguatge natiu per a Android però supose que les seves diferències tindrà programar en llenguatge natiu i utilitzar aquesta plataforma, de forma nativa segurament les aplicacions seran més ràpides, ocuparan menys espai, millor interacció amb el dispositiu, menys consum de recursos,… en canvi d’aquesta forma tens homogeneïtat a l’hora de programar per a diferents dispositius ja que programes sols amb un llenguatge i una vegada. Depen del que necessites fer al teu projecte serà o no una bona opció per a tindre en compte.

Adobe PhoneGap Build

Ara continuaré amb la opció més senzilla, Adobe PhoneGap Build. Per a empaquetar la teva aplicació primer la tens que dissenyar amb el teu software preferit (notepad, atom, dreamviewer,…), crear un arxiu que s’anomenarà config.xml en l’arrel del teu projecte amb una estructura com aquesta:

<?xml version="1.0" encoding="UTF-8" ?>
<widget xmlns = "http://www.w3.org/ns/widgets"
    xmlns:gap = "http://phonegap.com/ns/1.0"
    id        = "com.phonegap.example"
    version   = "1.0.0">

<name>Aplicacio comunicacio</name>

<description>
Aplicacio que comunica
</description>

<author href="https://example.com" email="you@example.com">
Your Name
</author>
<gap:plugin name="org.apache.cordova.device" version="0.2.12" />
</widget>

i després comprimir-ho tot a un arxiu ZIP (RAR no, donarà error), pujar aquest arxiu i automàticament es posarà a compilar.Si utilitzes una aplicació pública sols pots actualitzar via github, indiques la URL i phonegap ja s’ho agarra d’allí. És important posar al fitxer config.xml els camps amb valors nostres, el id sol ser com.nom_empresa.nom_aplicacio i després del </author> és on van posant-se el plugins que s’utilitzaran.

El que no he comentat és que en aquest mon de les app’s cada ‘creador’ necessita tindre un certificat/id per a poder publicar les seves app’s. Així que si no en tens cap (cada plataforma necessita el seu), sols es podrà compilar per a windows phone i per a Android en mode debug, l’aplicació és totalment funcional però no la podràs posar al google play/market,… en iOS no es podrà empaquetar. Si puc, més endavant publicaré un post explicant com treure aquestos ID’s o certificats (ara mateixa jo tampoc ho se encara, poc a poc jeje).

Plugins a Adobe PhoneGap Build

Si vols utilitzar algun plugin, el primer que faràs és veure quins plugins hi ha i la seva documentació. Per a això s’accedix a l’apartat del plugins i es busca el que més ens interesse, per exemple posem el de la orientació de la pantalla. En aquest cas ens indica que és un plugin compatible amb Android i iOS, i en Usage Instructions ens indica qué hem de fer per a poder utilitzar aquest plugin. En aquest cas és copiar

<gap:plugin name="net.yoik.cordova.plugins.screenorientation" version="1.3.1" />

al nostre fitxer de configuració config.xml, i en l’enllaç de la documentació ja ens indica com cridar a les funcions d’aquest plugin. A partir d’ací ens queda definir les nostres funcions javascript per a poder interactuar amb el plugin. Per exemple definir a l’acció de fer clic a un botó per a que cride a una funció del plugin i que el resultat el mostre per pantalla (amb un alert(resultat); per exemple).

En aquest cas obviarem els apartats de la documentació on ens indica que per a instal·lar el plugin hem d’executar el comandament ‘cordova‘, aquesta part és per a Cordova/Phonegap en local.

Instalar Cordova en local

Com m’agrada tenir un entorn net solc utilitzar prou les màquines virtuals, tenin una màquina per a un proposit (sempre que els requisits em deixen), així separe entorns de programació que no necessite que estiguen junts, faig backup del SO acabat de configurar,…. i això he fet també en aquest cas. No he triat linux (llèstima!) sino Windows XP, si! XP perquè consumix menys recursos que les següents versions. Així que passe a explicar com preparar el terreny per a empaquetar en local. Requisits:

  • Java
  • Apache Ant
  • SDK d’Android
  • Node.js
  • Cordova

Java

Anem a la web de Java i ens instal·lem l’última versió de Java (ara és la 1.8.60), la qual al instal·lar-la al XP ens avisa que possiblement no funcione OK però s’instal·la sense cap problema

Apache Ant

Fem el mateix en Apache Ant, descarreguem l’última versió i la descomprimim on ens vinga be. Després en la variable de sistema PATH afegim la ruta a c:\ruta_on_esta\bin

SDK d’Android

Ací jo m’he baixat el Android Studio sencer(exactament aquest enllaç), però no se si també funcionarà sense instal·lar-lo (quí sap si més endavant l’utilitze!). Una vegada instal·lat, afegim a la variable del sistema PATH la ruta dels platform-tools i de les tools. En aquest cas ho he instal·lat tot a C:\Archivos de programa i he afegit a PATH les rutes C:\Archivos de programa\Android\sdk\platform-tools;C:\Archivos de programa\Android\sdk\tools. Si modifiques les rutes d’instal·lació a C:\Archivos de programa, apareix una advertència indicant que l’usuari necessita accés de lectura/escriptura en aquesta ruta.

Node.js

Anar a la web, baixar, instal·lar i afegir el path (segurament C:\Archivos de programa\nodejs\) a la variable de sistema PATH.

Cordova

Executar a una finestra de comandament (cmd) el comandament

npm install -g cordova

I ‘arreando’!

És important definir correctament les rutes a la variable de sistema PATH. Aquesta variable és la que ens ajuda a executar aplicacions en rutes diferents a les seves. Per exemple si volem executar l’aplicació ‘android.exe’ no és necessari anar a la ruta on ho hem instal·lat (al meu cas C:\Archivos de programa\Android\sdk\tools), sino executar-ho directament on estem al comandament.

Finalment, per a comprovar que s’ha instal·lat correctament executem

cordova -version

I ens indicarà la versió, ara és la 5.3.1, quan tu ho lliges i ho instal·les no se quina podrà ser jeje. Com pots observar sols he indicat com configurar-ho per a Android, per a iOS es necessita Mac OS (més motiu per a no entrar al mon de la poma rosegada).

Creant aplicacions

Ara ja anem a tirar de ‘comandos’, comandaments que memoritzarem i al final els utilitzarem sense pensar. Els que més es gasten són pocs: crear, afegir plataforma, afegir plugin, compilar, emular.

Crear aplicació

cordova create carpeta id nom_aplicació
cordova create hello com.example.hello HolaMon

Ens crea una carpeta en la ruta on estem amb els fitxers necessaris per a programar però no està definit en quines plataformes compilarem aquesta aplicació

Definir plataformes

cordova platform add ios
cordova platform add wp8
cordova platform add windows
cordova platform add amazon-fireos
cordova platform add android
cordova platform add blackberry10
cordova platform add firefoxos

Poc puc dir ací, sols que ios sols funciona en un Mac i wp8 sols en windows (supose que a partir de windows 8)

Instal·lar plugin

En aquest cas cada plugin ens indica com instal·lar-lo, al plugin que he utilitzat abans ens indicaba en el readme que executarem el següent comandament:

cordova plugin add net.yoik.cordova.plugins.screenorientation

Sempre sol ser cordova plugin add.

Compilar

cordova build

per a especificar una plataforma

cordova build android

(al final del empaquetament ens indica on està guardada l’aplicació)

Instal·lar els paquets corresponents de la API seleccionada en l’aplicació a compilar

A mi la primera vegada que vaig compilar em va donar un error perquè no tenia instal·lat correctament els paquets del SDK, en la versió de cordova que tinc jo es necessita la versió 22 del API del Android. Segurament es pot canviar la configuració (he vist per ahí que es pot indicar la versió màxima i mínima que es necessita), però per ara no he tingut necessitat de empaquetar per a android menor de la versió 4 (canvieu-se el mòbil per favor, a no ser que el vulgau reutilitzar com jo).

Per a instal·lar els paquets corresponents executar android i apareixerà una finestra on pots escollir els paquets que vulgues. Tria els de la API 22.

Emular

cordova emulate android

En aquest apartat es pot obviar la plataforma però aleshores ens intentarà emular en totes les plataformes disponibles i segurament el nostre pc no ho aguante, així que millor indicar en quina plataforma vols emular-ho.

Per ara jo no utilitze molt la emulació, em costa menys compilar i instal·lar l’aplicació al dispositiu de proves que veure com queda a l’emulador, però això ja és a gust de cadascú.

Configurar un emulador d’android

Si mai has utilitzat un emulador d’android segurament no el tingues configurat i per això quan intentes executar l’emulador et done error. Per a configurar l’emulador pots executar android avd, en aquesta finestra podràs crear l’entorn virtual que necessites, indicant tamany de la pantalla RAM a utilitzar, disc a utilitzar, processador,…

No tinc temps per a més (ni per a posar alguna imatge!). Així queda el post, com una especie de resum/esquema del tema. Indicar que una de les diferències de programar en Adobe Phonegap Build i en Cordova és la estructura de carpetes. En APB sols hi ha una carpeta arrel (que nosaltres podem crear dins més carpetes), els plugins s’instal·len quan s’empaqueta a la web mentre que en Cordova ens crea un arbre de carpetes on nosaltres sols programarem en la WWW, dixant la resta com estan (en Cordova si que s’instal·len els plugins al projecte que estem fent).

Un altre dia profundiré més en com crear projectes.

Enllaços d’interés:

Configurar connexions VPN client CISCO (VPNC)

Per a hui… com connectar-se a un servidor Cisco al qual en windows (i també en linux) ens connectem a través del VPN Client de Cisco. Al Debian 8 + Gnome 3 és prou fàcil (una vegada ja saps, jeje).

Primer instal·lem el paquet necessari per a fer la connexió VPN amb aquest protocol: network-manager-vpnc-gnome
Si volem utilitzar un altre protocol, instal·larem el seu corresponent. Amb un apt-cache search network-manager* ens mostrarà el llistat disponible.

Després executem nm-connection-editor amb l’usuari que voldrem utilitzar la connexió VPN.

imatge1Li donem a ‘afegir’ i elegim el protocol que volem.

imatge2Ens obrirà una altra finestra on configurar les dades de la connexió que tenim guardades al fitxer *.pcf

imatge3

– El nom de la connexió és el nom que volem que aparega en l’apartat connexions (com la de Wi-fi, Ethernet,….)

– La passarel·la és el gateway, “Host” al fitxer pcf.

-El nom d’usuari/contrasenya d’usuari són el nom d’usuari/pass que utilitzarem.

– El nom de grup/contrasenya del grup són els que estan configurats al fitxer pcf com a “GroupName” i “GroupPwd”. Si en compte de “GroupPwd” tenim el “enc_GroupPwd”, podem decodificar aquest ‘rastre de caracters’ a la web https://www.unix-ag.uni-kl.de/~massar/bin/cisco-decode.

I si volem que s’aplique a qualsevol usuari, en la pestanya general marcarem aquest ‘tic’. És precís ‘ticar-lo’ si executem aquest asistent com a root. També avise que si es guarda qualsevol contrasenya al intentar connectar amb un altre usuari, el sistema tornarà a preguntar per ella la primera vegada.

imatge4

Finalment reiniciem l’administrador de xarxes del Gnome sudo /etc/init.d/network-manager restart. I ara al panel de connexions ja ens apareixerà la nova connexió de xarxa amb el nom que li hem assignat

Aquesta info l’he trobada per varies webs, ara mateixa no recorde quines són però agraixc que existixquen jeje. També he vist que molta gent li passava el mateix que a mi. La solució com es veu és primer crear la connexió i després reiniciar el manager, sino no apareixerà fins al pròxim reinici d’equip.

Entendre el programador de tasques de linux (CRON)

El programador de tasques per exelència al mon linux és l’anomenat CRON. Aquest és un servici (dimoni) que està presenc a totes les distribucions de linux (crec que és així). Jo no vaig a extendre’m molt explicant cóm funciona ja que es pot complicar bastant la configuració que es vulga aplicar en l’execució d’una tasca (que si vull que s’executi cada 10 minuts de tal a tal hora i sols tal i tal dia de la setmana….). Sols vaig a explicar breument cada columna i possibles configuracions.

Per a poder editar el fitxer de configuració del cron s’executa l’ordre
sudo crontab -e
L’editor és un editor en mode text. Igual hi ha alguna ordre ja posada o no, però siga com siga explique les columnes que hi ha:

# Exemple de definició de cron:
# .---------------- minut (0 - 59)
# | .------------- hora (0 - 23)
# | | .---------- dia del més (1 - 31)
# | | | .------- mes (1 - 12) O jan,feb,mar,apr ...
# | | | | .---- dia de la setmana (0 - 6) (diumenge=0 or 7)
# | | | | |
# * * * * * comandament

  • En la primera columna indiquem a quin minut volem que s’execute.
  • En la segon columna indiquem a quina hora volem que s’execute.
  • En la tercera columna indiquem quin dia del mes volem que s’execute el comandament.
  • En la quarta columna indiquem en quin mes volem que s’execute.
  • En la quinta columna indiquem en quin dia volem que s’execute (0 = diumenge, 1 = dilluns,…, 6 = dissabte, 7 = diumenge).
  • En l’última columna indiquem qué volem executar.

El caràcter comodí * indica que no es definix res en eixa columna i sols s’admet en les primeres cinc columnes
Si volem posar varies unitats de temps en una mateixa columna, per exemple que s’execute a les 12 i a les 19, separarem els valors per una ‘,‘: 12,19
Si volem indicar un rang de valors consecutius (que s’execute a cada hora des de la 1 fins a les 5) utilitzarem el ‘‘:1-2
Si volem indicar “executar cada X temps”, utilitzarem el ‘/‘ per exemple executar cada 5 minuts: */5

Un exemple de com complicar la cosa seria aquest:
0-30/5 9,12 1-7 * 1 Executar durant 5 minuts els primers 30 minuts de les 9 i les 12 del primer dilluns de cada mes

  • A la primera columna indiquem primer el rang de temps en minuts (0-30) i després que volem que s’execute cada 5 minuts (/5).
  • A la segona columna li indiquem que s’execute a les 9 i les 12 (9,12).
  • A la tercera columna li indiquem que s’execute del dia 1 al 7 del mes.
  • La quarta la deixem al caracter comodí, que significa ‘per a qualsevol’ mes.
  • La quinta columna li indiquem que volem que s’execute el dilluns, aquesta columna condiciona a la tercera columna fent que sols s’execute quan coincideixquen les 2 columnes (dia del mes entre 1 i 7 i que ademés siga dilluns).

Com es pot observar… es pot complicar. Aquest exemple l’he tret de la xarxa i l’he complicat un poc més

I ara un exemple un poc més pràctic:
30 18 * * * rm /home/someuser/tmp/*

(tots els dies a les 18:30 es borra el contingut de la carpeta /home/someuser/tmp)

Ah! pel que he pogut observar, abans també existia 2 columnes més on s’indicava l’usuari i l’any que es volia executar. Ara ja no apareixen i si es vol programar alguna tasca com a usuari X el que es fa és fer un crontab -e en la sessió d’aquest usuari

http://www.adminschoice.com/crontab-quick-reference
http://www.pantz.org/software/cron/croninfo.html
http://www.nncron.ru/help/EN/working/cron-format.htm

Configurar RSYNC III

Bones!

Ara explicaré com poder automatitzar el rsync tant si s’utilitza el protocol rsync com si s’utilitza el del ssh. Com en les altres publicacions primer explique la part menys laboriosa i després la resta.

Protocol RSYNC

Per a poder fer un rsync sense que ens demane el password el que farem és guardar eixe password en un fitxer i passar-li aquest fitxer com a paràmetre al rsync:
echo el_meu_password > /ruta/password.meu
chmod 700 /ruta/password.meu

I ara a l’ordre que he utilitzat en les altres entrades afegim – -password-file /ruta/password.meu
rsync -avz --password-file /ruta/password.meu /ruta/oritge rsync://backup_user@servidor_destí:port/BACKUP
Fent que no ens demane cap password, el que tindrem clar és que al fitxer password.meu sols té accés l’usuari owner i que l’ordre s’executarà des d’aquest usuari ja que sino no podrà accedir al fitxer a llegir el password

Protocol SSH

Per a aquest protocol, com realment és una capa que es posa baix del RSYNC, utilitzarem tant l’opció del password de rsyn com el que anem a fer ara.

Realment el que es fa és generar en el pc client una clau parell privada – pública i passar-li al pc servidor de backup la clau pública, així quan el pc client intente connectar-se al servidor aquest comprovarà que és una connexió fiable (fiable perquè nosaltres li hem indicat abans que confie en aquesta clau).

PC Client

Generem una nova clau, aquesta clau es generarà amb l’usuari el qual executarà el backup (que pot ser diferent al que indiquem al servidor SSH):
ssh-keygen -b 4096 -t rsa
Li donem permisos totals sols al owner del fitxer de la clau privada (molt important ja que la clau privada d’un usuari sols la té que tindre eixe usuari.
chmod 700 /ruta/de/la/clau/generada/id_rsa
I finalment copiem la clau pública al servidor, normalment es copia a la carpeta .ssh de l’usuari amb el qual es connecta al servidor:
scp /ruta/de/la/clau/generada/id_rsa.pub @:/home//.ssh/
Fixeu-se que estem passant la clau id_rsa.pub (pública) i no la id_rsa (privada).

PC Servidor

En aquest pc el que anem a fer és incloure aquesta clau pública al fitxer d’autoritzacions anomenat authorized_keys. Aquest arxiu per defecte no està creat, així que primer el crearem:
touch /home//.ssh/authorized_keys
I després importem des del fitxer de la clau pública a aquest fitxer el contingut de la clau pública:
cat /home//.ssh/id_rsa.pub >> /home//.ssh/authorized_keys

Amb aquesta acció el que hem definit és que quan el servidor detecte un intent de connexió via ssh des d’un altre equip el qual tinga la clau privada corresponent a la clau pública definida en authorized_keys, aquest acceptarà la connexió sense demanar password ja que explícitament li hem indicat que és de fiar. Per això la importància de fer el chmod 700 a la clau privada al pc client per a prevenir que no ‘furten’ aquest fitxer i el posen en altres màquines o en altres usuaris.

Ara per a poder executar des del pc client el rsync via SSH sols cal executar la següent línia:
$rsync -avz --password-file /ruta/password.meu --rsh 'ssh -p port -l user_ssh' --rsync-path="sudo rsync" /ruta/oritge backup_user@servidor_destí::BACKUP

El que s’ha afegit a l’ordre del rsync via ssh és simplement el – -password-file /ruta/password.meu per a que rsync no demane password. Recordeu el que explique en aquest post sobre aquest tema, que executant aquesta odre s’introdueixen dos contrasenyes diferents: una correspon a ssh i l’altra al rsync. Doncs be, la del ssh no fa falta definir-la perquè ja l’hem definit amb el parell de claus privada – pública i s’aplica a qualsevol connexió ssh que fem (sftp, ssh, rsync per ssh,…) mentre tingam la clau privada al nostre usuari. Aleshores sols definim la introducció de la contrasenya rsync com hem fet amb el primer exemple.

Com se m’ha fet bastant extens aquest post (com sempre!) deixaré un altre post per a explicar com automatitzar les còpies de backup.

http://blog.desdelinux.net/ssh-sin-password-solo-3-pasos/
http://www.ubuntufacil.com/2014/01/generar-y-anadir-claves-ssh-para-acceso-sin-contrasenia/

Configurar backup des de Synology a servidor RSYNC

Synology té un assistent que facilita la configuració de la còpia de seguretat i després la possible programació d’aquesta si es que volem. Però té un parell de llimitacions (les que jo he trobat, igual hi ha més!):

  • No es pot posar l’usuari que es vulga si es vol habilitar la transferència xifrada (per SSH), en la documentació oficial ho diu, he intentat fer-ho de totes les formes però no he pogut (tenen raó!). Es necessita configurar un superusuari, i jo de normal sols en tinc un (root).
  • Accions pre-xfer post-xfer: Depén del que es vulga fer es podran utilitzar o no. Rsync utilitza aquestes opcions per a poder executar un script abans de la còpia i un altre després de la còpia, el que passa és que quan DSM llança la còpia no ho tracta com una sol ordre rsync, sino varies. No se a ciència certa de que depén però crec que dependrà del número de carpetes, és més, quan fa comprovació dels mòduls configurats també executa aquestos scripts. Així que si el que es vol es fer un punt de muntatge, copiar i després desmuntar… segurament hi haurà problemes.

Primer es configura les dades per a poder connectar-se al servidor rsync: direcció, usuari, contrasenya, port (si no és el de per defecte). I després ja es pot clicar al desplegable per a que es connecte al servidor i seleccionar el mòdul que volem utilitzar per a fer la còpia de seguretat, si no saps que és un mòdul o no saps configurar-lo i també eres administrador del servidor de backup pots revisar aquesta entrada on ho explique.
01

02

03

04
En la següent pantalla es selecciona les dades a copiar, recordeu seleccionar sols les necessaries.

05

En la següent es pot seleccionar les configuracions d’algunes de les aplicacions instal·lades al Synology.

07

Finalment es configura les opcions de còpia i la possibilitat de programar-ho. En aquesta pantalla si l’usuari no es root l’opció de transferència per SSH estarà deshabilitada.

08

Una vegada creada la tasca, Synpology crea uns arxius a la ruta del mòdul al servidor. Aquestos arxius són importants i s’han de mantindre,sinó les còpies no es realitzaran (cada tasca té els seus arxius de configuració).

Després de creada es pot modificar, si s’ha utilitzat un usuari diferent de root es pot veure que l’opció de transferència per SSH ja està habilitada i es pot seleccionar, però si es selecciona i s’intenta executar la còpia, aquesta ens retornarà un error en la connexió.
09

10

Es poden configurar vàries còpies de seguretat a diferents servidors, mòduls… o tots al mateix servidor i mòdul ja que cada tasca es crea la seva pròpia carpeta per a guardar el backup.

Personalment per al que jo vull fer se’m queda curt aquest asistent, així que voré com es fa per script que no pareix tant difícil i interactuaré directament jo amb el rsync. El problema es que no podré guardar la configuració de les aplicacions i del propi dispositiu.

Augmentar la potència dels USB’s de la Raspberry B+

Una vegada ja instal·lat tot a la raspberry tire a connectar el meu disc USB i no té prou alimentació per a funcionar. Pel que he llegit els ports sols donen una potència de 600mA per port, és a dir que amb un cable amb doble connexió (com els que hi havia abans) si que em funcionaria. Però no és el cas perquè no tinc cable així. Aixina que he continuat navegant i he trobat diverses webs on expliquen com poder augmentar l’amperatge fins a 1200mA.

Aquesta configuració pot ser perillosa per a la placa ja que li donem massa canya i pot ser no acabe be la cosa, així que ho feu baix la vostra responsabilitat encara que si sols li connectes un disc dur i res més pels ports USB no tindràs cap problema. Ja vos diré més endavant jeje.

També dir que per a que funcione be la configuració l’alimentador que tinga deu ser d’una potència d’uns 2A (2000mA).

Per a habilitar aquesta funcionalitat cal editar el fitxer /boot/config.txt com a root i afegir la línia
safe_mode_gpio=4
Aquesta vegada no vos puc explicar qué vol dir, sols se que funciona. A la web on ho he vist també comenta que estaria be també afegir la línia
max_usb_current=1
No ens explica per a que és però supose que serà per a llimitar el número de dispositius alimentats per USB

Finalment cal reiniciar el dispositiu per a que faça efecte la nova configuració

http://www.element14.com/community/community/raspberry-pi/raspberry-pi-bplus/blog/2014/07/19/home-network-with-just-the-raspberry-pi-b-and-a-usb-external-hdd

 

Edite(2015/09/14):

Val la pena comprar un HUB alimentat externament per a alimentar els periferics que no aguante la raspberry. Després d’uns mesos sense para “l’aparatet” comença a funcionar mal (en el meu cas, clar). El que m’ha passat és que s’ha fotut el xip que controla els USB’s i que també controla la interfície de xarxa, fallant aleatòriament. Per tant ja no la puc utilitzar per al que jo vull i me’n he tingut que comprar una altra i configurar des de 0.

Instal·lació bàsica del Raspbian a Raspberry Pi B+ (i A+)

Al final m’he fet amb una Raspberry Pi B+, ja que per al tema de les còpies de seguretat de RSYNC que he anat comentant necessitava un pc amb USB i el servidor que tinc no em fa eixa funció. I com en la feina m’ho comentaven el tema de la Raspberry, he pensat que estaria be fer-se amb un aparell d’aquestos a veure que fa.

L’he comprat de PC Componentes i te l’envien amb una caixeta. Realment és menut, més o menys com un disc de 2’5″ i no porta cap accesori (ni carregador, ni res de res). Així que he tirat ma de telèfons retirats per a aconseguir alimentador (utilitza el mateix tipus d’USB que els telèfons d’ara, si si ixe que és xafadet!) i també per a aconseguir una microSD per a instal·lar el sistema, encara que si després vas a connectar-li un disc dur per USB i deixar-ho sempre així no és necessari perquè pots particionar el disc dur i aprofitar un trocet per al sistema.

He estat mirant per la web de la Raspberry quins sistemes se li pot instal·lar, i com jo estic acostumat al Debian i totes les seves versions he vist que la que millor m’anava a mi es la de Raspbian.

Revisant els mètodes d’instal·lació he vist que per regla general existix una imatge, que la “cremes” al disc i arreando! Clar com el hardware és sempre el mateix… en tenir una imatge creada ja no fa falta res mes. Aquestes imatges, al menys la del raspbian, ocupen uns 8Gb descompreses i ve un sistema complet amb el seu entorn gràfic i tot.

Aquest era per a mi el problema, que porta massa coses instal·lades. Jo ho vull per a utilitzar-ho com a ‘miniservidoret’ i no necessite tants programes corrent. He vist també que la gent es desinstal·la l’entorn gràfic però vulgues o no sempre es queden paquets instal·lats ocupant espai i/o memòria RAM. He revisat una mica més per la web oficial de Raspbian, allí explica com fer la instal·lació, també hi ha gent que ha fet el seu “unattended installation” i m’ha agradat un que sols fa una instal·lació bàsica i ademés instal·la un servidor SSH per a poder connectar-te. Altre punt a favor es que en compte d’ocupar 8Gb, aquesta cap en 512Mb

Aquesta instal·lació és ben senzilla: Es copia els fitxes que s’indiquen a la targeta microSD, es posa la targeta a la Raspberry i es connecta aquesta a la xarxa elèctrica i a la ethernet. També es pot connectar per HDMI a la televisió i connectar també un teclat però no és necessari, al iniciar buscarà un servidor DHCP per a que li done IP i es connectarà al servidor dels repositoris per a baixar-se el sistema.

Per a copiar els fitxers primer es formata la targeta en FAT32, després d’ací es baixa l’arxiu, que descomprimim el contingut a la targeta. I ja està tot! Ara posar la targeta a la Raspberry, enxufar-la i esperar més o menys 30 minuts. Realment no recorde el que m’ha tardat a mi però en 30 minuts ja està, és més, en la web diu que en 15 minuts ja pots tenir accés SSH (depenent de la teva connexió a internet).

Una vegada acabada la instal·lació es podrà accedir per SSH al ‘aparatet’, la direcció IP la podem averiguar connectant-nos al nostre servidor DHCP (casi sempre el router) i veure la nova concessió.

En la web ens recomana que el primer a fer després de connecar-se per SSH és deshabilitar l’usuari “pi” i canviar la contrasenya de root (per defecte “raspbian”), després configurar el locale (pel tema de configuració regional, teclat,…) i finalment el fús horari. I tot açò es fa d’aquesta manera:
passwd root (per a canviar la contrasenya de root)
dpkg-reconfigure locales (per a reconfigurar el locale)
En aquesta triarem es-ES UTF8
dpkg-reconfigure tzdata (per a configurar el fús horari)
Per a millorar l’administració de la memòra recomanen també instal·lar el següent paquet:
apt-get install raspi-copies-and-fills

Customitzar la instal·lació

També podem definir paràmetres com la IP (per si no tenim servidor DHCP o per si volem assignar-la manualment des d’un principi), la contrasenya de root, fús horari, mirror del repositori…. A la web ho expliquen, simplement és crear un fitxer a l’arrel de la targeta amb el nom de installer-config.txt i després incloure el que volem modificar. A continuació mostre tots els paràmetres que es poden modificar i els seus valors per defecte

preset=server
packages= # comma separated list of extra packages
mirror=http://mirrordirector.raspbian.org/raspbian/
release=wheezy
hostname=pi
domainname=
rootpw=raspbian
cdebootstrap_cmdline=
bootsize=+50M # /boot partition size in megabytes, provide it in the form '+M' (without quotes)
rootsize= # / partition size in megabytes, provide it in the form '+M' (without quotes), leave empty to use all free space
timeserver=time.nist.gov
ip_addr=dhcp
ip_netmask=0.0.0.0
ip_broadcast=0.0.0.0
ip_gateway=0.0.0.0
ip_nameservers=
online_config= # URL to extra config that will be executed after installer-config.txt
usbroot= # set to 1 to install to first USB disk
cmdline="dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 elevator=deadline"
rootfstype=ext4
rootfs_mkfs_options=
rootfs_install_mount_options='noatime,data=writeback,nobarrier,noinit_itable'
rootfs_mount_options='errors=remount-ro,noatime'

I això és tot! vos deixe les URL’s d’interés

Pàgina oficial de la Raspberry Pi
Pàgina oficial de Raspbian
Pàgina oficial de la instal·lació

Configurar RSYNC II

En aquesta segona entrada anem a fer segura la connexió entre client i servidor. Ara que ja hem aconseguit fer connexió ‘a pèl’ i comprovar que funciona be, ens toca configurar la seguretat. Per a encriptar la informació que enviem s’utilitza SSH ja que rsync no té encara opció de fer-ho (però si opció d’ajudar-se amb ssh).

El que fa rsync amb ssh és connectar les dues màquines pel protocol segur (amb usuari/password) i una vegada establida la connexió és quan s’executa l’odre del rsync, que demanarà el password de l’usuari del rsync. Ací ja venen diversos errors com confondre usuaris o passwords, que l’usuari que s’utilitza al ssh tinga accés a la carpeta del rsync al servidor,…..que si seguim aquesta configuració desapareixeran.

Com acabem de veure, realment posem en marxa dues aplicacions i les dues necessiten usuari/password, que no tenen perque coincidir els usuaris a les dues connexions (ni els passwords tampoc, clar).

Aleshores, per a començar tenim dos usuaris diferents: Un per a la connexió ssh, que serà un usuari del servidor, i l’altre l’usuari per a la connexió rsync, que estarà configurat a rsync (i no té perquè existir al sistema del servidor). Però recordem que el que volem és copiar els arxius i preservar els seus atributs, owners,… (el que significa executar rsync com a super usuari ja que el uid l’hem posat com a root). La forma més ràpida (i perillosa) és connectar-se per ssh com a root, amb el perill que comporta ‘deixar’ el password de root d’una màquina a un usuari d’una altra. L’altra forma és fer-ho ben fet: al servidor habilitar que el nostre usuari que utilitzarem per a ssh puga executar rsync amb drets de super usuari i sense que ens demane password (aquest últim requisit no és per gust sino perquè rsync no admet interacció amb sudo, l’apicació que utilitzarem).

Per supost anem a fer la segona opció! Primer anem a instal·lar l’aplicació sudo, que al debian no està i s’instal·la fent un #apt-get install sudo i després anem a configurar per a que l’usuari que anem a utilitzar a ssh puga executar rsync com a super usuari sense que ens demane password. Exactament anem a indicar el que acabe d’escriure, solament podrà executar aquest programa com a super usuari sense que demane password, eixe i solament eixe. És més, si no es configura com a usuari sudoer (que no anem a fer-ho) no podrà executar ninguna aplicació més com a super usuari encara que siga demanant password. Insistixc molt per a que es veja que és molt més segur la segona opció que la primera. Ale va! a configurar:

#nano /etc/sudoers

i afegim al final aquesta línia:

user_ssh ALL= NOPASSWD:/usr/bin/rsync

    Explicació

  • user_ssh: És l’usuari que utilitzarem per a fer login a ssh.
  • ALL: indiquem que des de qualsevol màquina.
  • NOPASSWD: indiquem que no fa falta introduïr password.
  • /usr/bin/rsync: És la ruta on està l’executable rsync ( si és una altra ruta, es posa l’altra ruta).

Ara com ja ho tenim configurat anem a fer la còpia utilitzant ssh:

$rsync -avz --rsh 'ssh -l user_ssh' --rsync-path="sudo rsync" /ruta/oritge backup_user@servidor_destí::BACKUP

    En aquesta ordre hem introduït nous elements que explique ara mateix:

  • –rsh ‘ssh -l user_ssh’: Indica que la remote shell serà ssh i que l’usuari per a ssh serà user_ssh.
  • –rsync-path=”sudo rsync” aquesta opció s’utilitza per a indicar on està rsync si no està al seu lloc per defecte però es pot utilitzar per a fer el que nosaltres volem, indicant-li que el path és “sudo rsync”. Aleshores quan es faça la connexió ssh, rsync executarà l’odre sudo rsync com al usuari user_ssh (que ja hem indicat que no necessita password per a executar rsync), aconseguint dret de super usuari per a l’aplicació i poder mantindre els seus atributs, owners,…

Si ara el que volem és fer una connexió però a un port ssh diferent (podem observar que ara no utilitzem el port del rsync sino el del ssh), ho executem de la següent forma:

$rsync -avz --rsh 'ssh -p port -l user_ssh' --rsync-path="sudo rsync" /ruta/oritge backup_user@servidor_destí::BACKUP

El :: és correcte i també es pot canviar –rsh per -e, és la mateixa opció però amb el mètode abreviat

Per a finalitzar dir que al executar aquesta ordre primer demana el password del usuari ssh i després el del usuari rsync, si es passa la primera autenticació però no s’arriba a la segona es que hi ha un error amb l’usuari ssh, una vegada ja s’ha posat el password de l’usuari de rsync… ja el problema està a la teulada del rsync.

I ja està acabat el segon post sobre el tema, prompte el tercer! on vorem com fer que no ens demane passwords el rsync i poder posar al cron per a que s’execute automàticament

Configurar RSYNC I

Bon dia!

Hui vaig a explicar com configurar un servidor rsync per a que des d’un client rsync es puguen fer còpies de seguretat. Primer vaig a fer-ho senzill, després aniré complicant un poc més la coseta fins que se’ns quede ‘una cosa be’. Vaig a escriure-ho perquè m’he vist en la necessitat de fer-ho i pensant-me que hi hauria molta informació al respecte m’he equivocat: al principi costa bastant arrancar, si busques a la xarxa veus molts problemes diferents que donen els mateixos errors i exemples de configuració que a mi no m’han funcionat. Així que jo explique el meu cas, pot ser que a vosaltres tampoc vos vaja be (qui sap!) però espere que al menys vos ‘despeje’ dubtes.

Primer vaig a aclarir unes definicions que diuen per ahí per la xarxa: PULL i PUSH, que si ho traduïm és com les etiquetes de les portes de les tendes “ESTIRAR” i “EMPUJAR”, és adir que en la primera “estires” la informació i en la segona “espentes” la informació:

PULL és quan el directori oritge és extern (una altra màquina) i el directori destí és local. Exemple: Tens un servidor on es configuren totes les tasques de còpies de seguretat dels demés servidors i va copiant de les demés màquines a local

PUSH és quan el directori orige és local i el directori destí és extern (una altra màquina). Exemple: En aquest cas cada servidor tindria la seua tasca de còpia de seguretat apuntant al servidor de còpies.

Depén de situacions serà millor un sistema o un altre, depen de l’accés que es tinga a les màquines, accés de xarxa, enrutament,… Per exemple si eres administrador de totes les màquines i estan connectades a la mateixa xarxa igual és millor centralitzar les còpies i utilitzar PULL, per contra si sols eres administrador de la teua màquina i t’han passat els paràmetres per a connectar-te al servdor de còpies o no estan les màquines en una mateixa xarxa privada (accés per internet) o moltes altres possibilitats, es possible que vulgues utilitzar PUSH. Jo vaig a utilitzar PUSH, però si vols utilitzar PULL tan sols has de canviar les rutes. De totes formes a veure si tinc un ratet i faig també una entrada utilitzant configuració PULL. Ara anem al lio!

La instal·lació a debian és molt senzilla: apt-get install rsync, i ja està!

Ara falta crear el fitxer de configuració, de passwords i habilitar el servei per a que arranque automàticament. El fitxer de configuració és ben senzill, es diferèncien dues parts: la part global i la part dels mòduls, cada mòdul és una configuració per a fer còpies (on es còpia, permisos, comentaris, accions a realitzar, canviar paràmetres globals per a aquest mòdul en concret,…). Ací deixe un petit exemple:


#nano /etc/rsyncd.conf
lock file = /var/run/rsync.lock
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid

[BACKUP]
uid = backup_user
gid = backup_user
path = /mnt/backup
comment = Copia de backup
auth users = backup_user
read only = no
list = yes
secrets file = /etc/rsyncd.pass

La part global és la inicial, i la part de cada mòdul começa amb els comentaris entre [], en aquest cas hi ha un sol mòdul, el [BACKUP]. Els primers tres paràmetres són importants però no necessaris per al funcionament (si els lleves funcionen igual, jeje). El lock i el pid és per a controlar les execucions de l’aplicació i el log per a tenir un registre general del programa. També va be posar el llímit d’usuaris per a no saturar el servidor, aquest paràmetre és el max connections. Com ja he comentat, qualsevol paràmetre pot estar en global o al mòdul (al menys els que jo he provat).

Ara passem al mòdul d’aquest exemple:
– Primer indiquem el usuari:grup (uid i gid respectivament) que serà el owner (l’amo) de les dades que van a copiar-se al servidor, si al orige és un altre… al copiar-se al destí es canviarà per l’indicat ací.
– Es definix la ruta destí al servidor (path). Important que l’usuari definit abans tinga accés rw a aquesta ruta, sino dona error i no funciona. Feu-me cas que ja he estat ‘peleant’ pensant que havia donat permisos i resulta que no ho havia fet 🙁
Comment: un xicotet comentari per a saber de que va
– Indiquem que no és soles lectura (per a poder escriure també) amb el read only
– El següent paràmetre si no està no passa res, és per a que aquest mòdul siga visible a l’hora de llistar els mòduls disponibles al servidor, crec que per defecte està habilitat encara que no es configure.
– I finalment una part important (i crec que sense ella no funcionaria el rsyncd): El fitxer on es guarda la relació user:pass, aquest fitxer és un fitxer pla (es pot llegir perfectament per una persona, no està encriptat) i he vist que si no se li fa un chmod 600 com a root a aquest fitxer, no es pot llençar backups com a un usuari normal des del client. Al log ix un error com aquest:

[4834] secrets file must not be other-accessible (see strict modes option)
[4834] continuing without secrets file
[4834] auth failed on module NAS from nom_ip_que_he_ocultat (ip_que_he_ocultat): missing secret for user "backup_user"

Recordem: l’usuari que indiquem com a owner dels fitxers que van a copiar-se té que tindre accés de rw a la ruta que es posa en path. Ademés s’ha d’especificar un screts file i com a root fer-li un chmod 600. Important perquè sino donarà bastants errors. Ah! i no va mal definir un fitxer de log per a revisar els possibles errors que apareguen a la part del server.

Tot seguit passem a crear el fitxer de passwords, la configuració d’aquest fitxer és senzilla: en cada línia una parella de usuari:password. Aleshores fem un

#nano /etc/rsyncd.pass

I posem a la primera línia: backup_user:pass_back

Amb aquesta línia estem definint l’usuari backup_user amb password pass_back (que és el que hem indicat que té accés al mòdul BACKUP al fitxer de configuració del rsyncd.

Finalment anem a habilitar el servidor de rsync:

#nano /etc/default/rsync

i la línia que diu: RSYNC_ENABLE=false, la canviem per RSYNC_ENABLE=true

Amb aquesta configuració ja es pot fer una còpia de backup des del client amb el següent comandament:

$ rsync -avz /ruta/oritge rsync://backup_user@servidor_destí/BACKUP

Amb aquesta ordre es fa una còpia amb els paràmetres avz, que ho explicaré més endavant, de la ruta actual al servidor amb nom servidor_destí i al mòdul BACKUP, utilitzant l’usuari backup_user que hem definit al /etc/rsyncd.pass. El port per defecte del servici rsyncd és el 873, si pel que siga l’hem canviat al servidor l’ordre a executar seria:

$ rsync -avz /ruta/oritge rsync://backup_user@servidor_destí:port/BACKUP

Cal recordar que amb aquesta ordre el que fem és sustituïr el owner original dels fitxers copiats (els de backup) pel que hem indicat a la configuració. Modificant els paràmetres del uid i el gid a root ens solucionarà aquest problema.

Passem a explicar les opcions que hem posat al rsync:

  • -a: equival a -rlptgoD, que vol dir: recursiu, còpia enllàços simbòlics, preserva els permisos, guarda el temps, preserva el grup, preserva el owner i preserva els device files. Com hem vist, el tema de preservar permisos, temps, usuari i companyia sols ho fa si hem definit com a root el uid.
  • -v: verbose, necesari per al log
  • -z: transmitir la informació comprimint-la.

Hi ha més opcions però podem dir que ‘aquestes són les normals’. Respecte a l’opció -z he fet proves i he tingut els següents resultats:

  • Sense compresió: sent 27368118 bytes received 4818 bytes 71376.63 bytes/sec total size is 27839822 speedup is 1.02
  • Amb compresió: sent 24222524 bytes received 5007 bytes 72429.09 bytes/sec total size is 27839822 speedup is 1.15

Es pot veure que si que millora amb compresió.

Fins ara no han aparegut nous possibles errors que no haja comentat ja. Però si volem fer una còpia a través de internet a un altre servidor d’un amic (per exemple) tindrém en compte que:

  • Tenim resposta Ok del ping.
  • Té el port disponible (el que és per defecte o un altre que ens dirà per a configurar-lo). Ací entra que al router que tinga en casa estiga ben configurat la redirecció (fordwarding) del router a la IP del servidor rsyncd.
  • Primer heu provat a la seua xarxa (que no té cap intermediari) i ha funcionat OK.

Cal tenir en compte que la velocitat de còpia no serà la mateixa, els exemples que he posat jo corresponen a còpies petites a traves de la Internet. Si vos fixeu, he fet una còpia de 26Mb i pico a una velocitat de 70’73kb/s en el cas més ràpid tardant 6 minuts 18 segons. Ara fem càlculs i 1Gb tarda 4.20h, 500Gb ja són 87 dies (o el que és el mateix… casi 3 mesos!). Hem de tenir en compte el tema de volum, estic parlant d’un ADSL de 10mb, no res de fibra i coses d’ixes rares que no arriben al meu poble. En aquestos cas jo crec que és millor portar el client on estiga el server i fer la còpia en xarxa local, i després ja la incremental fer-la a distància.

I fins ací arriba el primer post parlant sobre la configuració del RSYNC