Configurar el comandament de la TV per a controlar Kodi

A l’entrada anterior he explicar (ja se que molt per damunt) que podiem controlar Kodi amb el ‘mando’ de la ‘tele’. El que passa es que anirem descobrint poc a poc el funcionament de cada tecla del mando. L’activació o reconeiximent dels dispositius CEC de cada TV és diferent així que no ho explicaré, ademés no hi ha tantes opcions en una TV, navegueu per elles i ja la trobareu. Des de la meua experiència vaig a explicar com assignar tecles del ‘mando’ a accions del Kodi.

Al provar en diferents marques de TV he vist que en la Samsung no fa falta cap modificació des del meu punt de vista, es pot controlar be. Però al provar en LG em vaig emportar una gran desil·lusió ja que la funció ‘arrere’ no anava des del comandament i damunt ho volia utilitzar per a aquesta TV! Així que mirant per ahí i provant ho he pogut canviar, és molt senzill i ho vaig a explicar.

El primer a tenir en compte és que la TV no envia per HDMI la informació de totes les tecles que apretes al ‘mando’. No se si depén de models, marques de TV o versions del HDMI però el que si que se es que en la LG que tinc no es pot configurar qualsevol tecla. Després, per a canviar la configuració de les tecles es pot editar a pel el fitxer de configuració o utilitzar un plug-in que ens facilita aquesta tasca. Com a mi m’ha funcionat el plug-in (add-on), explicaré aquest apartat i no l’altre més interessant jeje.

Instal·lem el add-on “Keymap editor”. Executem aquest add-on i en l’apartat global busquem l’acció que volem configurar: ‘arrere’ en aquest cas, pulsem enter i editar. Durant 5 segons està esperant el sistema que apretes una tecla, be siga del teclat, del ‘mando’,…En aquest punt tenim 2 opcions: la primera és anar apretant tecles fins que alguna responga o monitoritzar les tecles que la TV envia al Kodi i elegir una d’aquestes. Jo primer em vaig decantar per la primera ja que pensava que el botó ‘exit’ del ‘mando’ si que funcionava (i no funcionava), després els botons de color (i tampoc funcionaven), i al final vaig triar la segon opció.

Per a monitorizar les tecles que envia la TV a Kodi per HDMI s’habilita l’accés SSH al sistema (que si ho hem fet en la configuració inicial ja no fa falta habilitar-ho) i també habilitarem la opció de debug del Kodi, que s’habilita des de les opcions de sistema del Kodi. Hi ha dos opcions de debug, si actives les dos opcions es pot monitorizar encara que crec que sols fa falta activar la segon opció. En la part superior esquerra de la TV apareixerà informació on indicarà la ruta del fitxer de log del sistema.

Ara toca accedir amb un client SSH des d’un altre equip a openELEC (usuari:root pass:openelec) i executar ‘cat /ruta/del/arxiu.log’, ens fixem en l’hora de l’últim event, apretem una tecla del ‘mando’ i tornem a executar l’ordre anterior, ens fixem si s’ha registrat un nou event. La veritat es que aquesta opció també és ‘prueba-error’ però al menys tens on mirar per a comprovar si ‘fa algo’ o no el botó que s’apreta. Una vegada tenim identificada una tecla que creguem que no fa res, tornem a executar el Keymap editor, anem a l’acció a configurar i quan ens demane una tecla… apretem eixa tecla.

Clar? si no està clar sempre podeu preguntar. Per a accedir per SSH es pot utilitzar qualsevol client com putty per a windows. També es necessitarà la IP de l’equip per a poder accedir, la podem trobar a opcions del sistema de OpenELEC.

Hi ha moltes accions a configurar, pot ser entretés perdres per ahí, també veure que hi ha accions que estan tant en global com en altres seccions i supose que la global tindrà més pes que les altres, no se. Tampoc he comrpovat qué passa si configures una mateixa tecla per a dos accions, però crec que el que farà és executar les dos accions. No crec que comprove primer si eixa tecla està fent una altra acció, aixina que si vols canviar la acció de una tecla primer et toca anar a eliminar tecla del event anterior i després assignar-la al nou event.

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.

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

Projecte Carasol…aconseguit!!! (i II)

Quan uno té ganes mira que s’afanya a fer les coses! Anit li vaig cridar a Joan per a anar aquest matí a posar l’antena al màstil de la caseta, ell té l’escala de 4m que arribava be per a muntar-ho. El pas més complicat era el de llevar el cable d’antena que vaig posar fa 2 anys i passar el cable de xarxa, ha sigut el més complicat perquè ara no tenia la guia que vaig utilitzar per a passar el cable. Però hem lligat be els dos cables i precintat per a que no s’enganxara ningun fil en algun colze del recorregut i ha eixit sense cap problema, després li he passat el POE i he connectat l’AP per a veure si agarrava la senyal i… si! la senyal era casi igual de bona que amb el trípode, així que allí dalt de la teulada estavem Joan i jo celebrant-ho, ho he instal·lat i la antena que ha estat durant 2 anys allí dalt posada l’he llevat. Després li he connectat el Router i he fet algunes proves de rendiment de xarxa, com per exemple reproduïr una pel·lícula AVI enmagatzemada en l’ordinador de taula de casa sense cap problema, o copiar un arxiu gran.

Així que ara, a falta de que Picola vaja a canviar el màstil de l’antena en casa ma tia (que a saber quan serà) ja puc dir que el projecte ja ha finalitzat correctament.

Projecte Carasol

Ja he configurat amb èxit tot el circuit al laboratori de proves (casa ma tia), aplicant-li la seguretat de tallafocs, rutes estàtiques i VPN. Adjunte una nova imatge de la topologia que he seguit (es que des que he descobert DIA que no pare d’utilitzar-lo, no trau uns gràfics tant definits com el VISIO però és programari lliure):

Diagrama Carasol

  • R1: Router Broadband, el que dóna accés a internet.
  • Servidor VPN: El nom ja ho diu tot, amb 2 interficies de xarxa, separant físicament la LAN local de la resta.
  • PLC1 i PLC2: Encarregats de portar la xarxa pel cablejat elèctric.
  • R2: UBNT1, el punt d’accés (Nanostation2) que hi ha a la casa per a unir-se a wifi4t.
  • R3: UBNT2, el punt d’accés (Nanostation2) que hi ha a la caseta per a unir-se a wifi4t.
  • R4: Router final de la caseta, on es connectaran els pc via LAN o wifi

wifi4t

Com ja havia dit alguns posts anteriors, la xarxa wifi4t és lliure, no està encriptada, així s’aprofita millor l’ample de banda que en les distàncies fa falta, jeje. En un principi es pot connectar qualsevol persona a la xarxa, encara que no tindrà accés a internet, però per ara l’he feta una xarxa /30 fent que no es pugui connectar a nivell d’IP més de 2 hosts (els 2 AP’s). Quan estiga tot en marxa i funcionant perfectament ja ho canviaré a una /16.

Tallafocs

Servidor VPN

És l’encarregat d’unir qualsevol client VPN a la xarxa local de casa i, per tant, a Internet. Conté un tallafocs que sols deixa passar els ports necessaris per a la connecció VPN

UBNT1

Conté un tallafocs que no permet que ixca res per la xarxa LAN, tant sols els paquets dirigits als ports que s’utilitzen per a l’enllaç VPN i que vinguen de la IP del R4.

R4

Tallafocs per a no deixar entrar ningun tràfic que no haja sigut provocat des de dins de la LAN. NAT habilitat. Com en la caseta la xarxa creada per R4 (que serà tabé wifi) és privada, aquesta si que anirà xifrada i amb un mínim de seguretat.

Les xarxes creades que són punt a punt van totes amb la màscara /30 per a donar un poc més de protecció, la wifi4t és lliure i les altres són privades, i els punts d’accés estan configurats com a “punt d’accés WDS” el de casa i com “estació WDS” el de la caseta. La connexió a la xaraxa wifi4t ja l’habilitaré quan ja haja finalitzat aquest projecte.

Ara falta implantar el projecte a la vida real, ja he vist que al laboratori funciona perfectament però falta veure com actuen els AP’s amb la distància i si fa falta connectar les antenes que ja estan instal·lades o no. A veure si demà dissabte al matí puc fer alguna prova i ja contaré

P.D.: Qaunta cosa s’ha de fer per a poder tenir internet a la caseta, no és més còmode un módem USB 3G? jajaja

Nanostation I. Configurar les rutes

El Nanostation ve amb mini linux empotrat anomenat AirOS, porta una interficie web i per defècte porta la IP 192.168.1.20 i user ubnt/ubnt. Via web es pot configurar ‘casi tot’ però no tot, per exemple les rutes. La configuració de les rutes es pot fer de forma estàtica o mitjançant RIP o OSPF.

Per a la segona opció tant sols cal actualitzar el firmware a la versió de inveneo i i seguir els passos que s’indiquen en l’enllaç, encara que està millor explicat ací. En aquest enllaç també hi ha una referència a una altra web en la qual expliquen com poder fer una xarxa en topologia mesh

Per a la primera opció cal accedir al AP per SSH i crear un script amb el route i les seues opcions. EL AirOS té una carpeta anomenada /etc/persistent al qual es poden crear scripts, els quals al engegar-se la màquina s’executen. Els noms dels scripts són:

  • /etc/persistent/rc.prestart
  • /etc/persistent/rc.poststart
  • /etc/persistent/rc.prestop
  • /etc/persistent/rc.poststop

El fitxer a crear (perquè el més segur es que no estiga creat) és el rc.poststart. Per a crear-lo s’escriu a la consola (estaguent al directori correcte)

#vi rc.poststart

I s’edita amb l’editor vi, primer premer ‘a’ i després ja es pot escriure. Quan estiga tot escrit, premer ‘Esc’ i ‘:x’ per a guardar els canvis al fitxer. Ja en consola se li donen permisos d’execució:

#chmod +x rc.poststart

I finalment per a que els canvis no desapareguen en quan es reinicie la màquina:

#cfgmtd -w -p /etc/

I arreando! ja està, fàcil del tot. Ara pose un exemple de script de rutes estàtiques:

#! /bin/sh
route add -net 10.10.10.0 netmask 255.255.255.0 gw 192.168.2.101 dev eth0

Pàgines d’interés:

http://www.ubnt.com/wiki/index.php/Manual_Routes

http://wiki.ubnt.com/wiki/index.php/User:Skyhook#How_to_add_a_static_route

http://wiki.ubnt.com/wiki/index.php/Linux_Script_FAQ

http://www.dc.fi.udc.es/~afyanez/info-vi/index.html Manual de VI

ací

BACKUP’s (MySQL)

Hui done pas a un tema molt important en el manteniment dels servidors, són les copies de seguretat de les dades en altres servidors.

En aquest post explicaré com fer backups remots de les bd’s d’un servidor MySQL. Per a aquesta tasca recurrim a un script que es pot descarregar des d’ací.  Aquest script anomenat AutoMySQLBackup fa tota la feina automàticament i la seua configuració és molt fàcil, sols editar l’arxiu ja es veuen els comentaris de les opcions que té, nom d’usuari, password, bd’s a fer el backup, carpeta on es fan les còpies,… Per al correcte funcionament d’aquest script cal donar-li permisos d’execució (per exemple un chmod u+rwx) i deixar-lo a la carpeta /etc/cron.daily per a que el sistema faça la feina per nosaltres. Per a fer que funcione aquest script s’instal·larà també el paquet mysql-client i les seues dependències.

Aquest script crea dins de la carpeta on està configurat el backup 3 carpetes, una per a les còpies diaires, una altra per a les setmanals i una altra per als mensuals, en la carpeta diaria s’emmagatzemen fins a 7 còpies després es sobreescriuen, en la carpeta setmanal conserva fins a 5 còpies i en la mensual es sobreescriu mensualment la còpia que es desa.

Finalment, per a que aquest script s’execute en el servidor de backup amb una connexió externa cap al servidor MySQL s’ha de modificar el fitxer de configuració del MySQL que es troba a /etc/mysql/my.cnf i comentar la línia “bind-address = 127.0.0.1” i que l’usuari que s’utilitza per a fer la còpia tinga permisos d’accedir al servidor MySql des de l’exterior

I així ja estarà configurada la còpia de seguretat diariament

Enllaços:

AutoMySQLBackup para copias de seguridad MySQL

Conexion remota a mysql-server