Instal·lant linux a Netgear Stora MS2110-100PES

“Arrglant trastos” he trobat el NAS que havia retirat i m’ha vingut al cap que una vegada vaig llegir que es podia posar linux. La veritat que el firmware que porta no m’agrada gens: és prou llimitat, s’accedix per una web de netgear, i ja està una mica desfassat.
He buscat novament la web on indicava cóm posar el debian al NAS i vos explique els resultats:

La web que explica el procés és [aquesta], però jo ho he aconseguit instal·lar sense USB extern i en RAID1 ajudat d’altres webs que deixe al final del post. Fent el que indique es perdrà tota la informació que hi haja al NAS

Estem parlant d’una arquitectura arm, amb un bootloader anomenat U-BOOT el qual al arrancar el sistema et dona 3 segons per a interrompre l’arranc automàtic i interactuar amb ell. Ens connectem per serial per a poder interactuar amb el sistema. A la web hi ha un exemple de com utilitzar Arduino UNO per a ‘fer de pont’ entre el pc i el NAS, jo he utilitzat un convertor USB – SERIAL TTL per a comunicar-me (però el procés és el mateix).

El software que he utilitzat al Windows és el putty, que ja l’utilitze per a client SSH, per a linux es pot utilitzar l’utilitat ‘screen’ (a la web està explicat).

Instal·lant el sistema

Seguint la web, el primer pas és baixar-se al pc en local tots els arxius de l’adreça http://openstora.cablecat.dk/ (realment no s’utilitzen totes però aixina i tot jo les he baixat)

Per a poder carregar l’arranc de la instal·lació es necessita passar fitxers del nostre pc al NAS. Ho farem per tftp, el programa utilitzat és el pumpkin (que ens hem baixat). L’instal·lem i modifiquem la configuració per a definir el directori (on estan guardats els fitxers que ens hem baixat) i per a permetre qualsevol connexió:
post01

Ara ens connectem amb el Putty al NAS. Obrim putty, indiquem que és una connexió serial, indiquem el número del port i la velocitat de 115200.

Posem en marxa el NAS i començarem a veure ‘coses’ fins que mostra

Hit any key to stop autoboot:  3

Aleshores es pulsa qualsevol tecla per a parar el procés automàtic.

En aquest punt anem a fer un backup de les opcions configurades per defecte. Amb la funció printenv es mostra per pantalla tota la configuració (que copiarem a un txt i el guardarem)
Ara es configura unes opcions que no se que són, la IP del NAS, la IP del nostre equip (que fa de servidor tftp), es guarden els canvis i es reinicia:

setenv mainlineLinux yes
setenv arcNumber 2743
setenv ipaddr XXX.XXX.XXX.XXX   #This is the IP of your Stora
setenv serverip XXX.XXX.XXX.XXX #This is the IP of your TFTP server
saveenv
reset

(per conforme està la meva xarxa també he tingut que modificar la màscara, setenv netmask)

Es reinicia i es torna a parar l’arranc automàtic. Ara es carreguen els fitxers d’arranc de l’instal·lador:

tftpboot 0x200000 uImage.di
tftpboot 0x800000 uInitrd.di
setenv bootargs console=ttyS0,115200n8 base-installer/initramfs-tools/driver-policy=most
bootm 0x200000 0x800000

I comença la instal·lació! Jo he tingut bastants problemes amb la instal·lació. El primer problema es que aquesta versió de debian ha deixat de tindre suport i per tant s’ha retirat dels repositoris, deixant-lo sols al repositori ‘archive’. El problema d’aquest repositori es que la estructura de carpetes és diferent a la que espera el programa d’instal·lació i per tant no hi ha forma de seguir.
Mirant per internet he trobat posts on la gent posava un proxy pel mig, capturava la url i la modificava. Jo això no ho se fer, aixina que he buscat fins trobar un mirror on encara tinguera aquesta versió. També descartava instal·lar una nova versió com m’ho oferia l’instal·lador per por a que el kernel que s’instal·la després a ma no fos compatible (ho desconec).
Be el mirror que s’introduix manualment és:
Servidor: snapshot.debian.org
Carpeta: /archive/debian/20120402T153222Z/

Aquest servidor pareix que tinga snapshots de qualsevol dia, així que es pot provar a instal·lar un més vell

Altre problema que he tingut es que després de descarregar els primers paquets la pantalla es queda negra ‘i au’, no passa res més. Era perquè triava en la configuració que la localització era Espanya. Si es deixa totes les opcions per defecte si que funcionarà OK.

Pot mostrar varis errors com:
– No kernel modules were found.
– Software RAID not available
– Logical Volume Manager not available
– No installable kernel was found

Quan s’arriba a la partició s’indica que el format de la taula de particions és ‘msdos’ (perquè? per que he provat eixa i m’ha funcionat). En aquest cas com volia fer RAID i no volia liar-me amb les particions he posat que sols vull una partició on estiga tot.
Important en aquest punt que s’utilitze sols un dels discs i es creen particions primaries, a mi se m’ha creat la partició swap en lògic. No passa res però crec que per al RAID quea més ‘net’.
Al final no s’instal·la el GRUB perque indica que no es pot i intentarà reiniciar.

Instal·lació del kernel

Al reiniciar tornarem a cancelar l’autoarranc i carregarem els fitxers corresponents per a arrancar el nostre sistema:

tftpboot 0x200000 uImage
tftpboot 0x800000 uInitrd
setenv bootargs $(console) root=/dev/sda1
bootm 0x200000 0x800000

(pot ser que la vostra partició / no siga /dev/sda1, si és així es te que modificar)

una vegada ja ha arrancat el sistema s’instal·la el kernel amb les següents ordres:

aptitude update
aptitude -y install uboot-mkimage initramfs-tools ntpdate
ntpdate-debian
wget http://dl.dropbox.com/u/1397036/stora_di/linux-headers-2.6.32-6-kirkwood_2.6.32-6-kirkwood-10.00.Custom_armel.deb
wget http://dl.dropbox.com/u/1397036/stora_di/linux-image-2.6.32-6-kirkwood_2.6.32-6-kirkwood-10.00.Custom_armel.deb
wget http://dl.dropbox.com/u/1397036/stora_di/2.6.32.mach.tgz
dpkg -i linux-*-2.6.32-6-kirkwood_*.deb
ln -s /usr/src/linux-headers-2.6.32-6-kirkwood/ /lib/modules/2.6.32-6-kirkwood/build
tar xzf 2.6.32.mach.tgz -C /usr/src/linux-headers-2.6.32-6-kirkwood/arch/arm/

i ara es confiugura el kernel per a poder arrancar:

wget http://dl.dropbox.com/u/1397036/stora_di/stora-flash
chmod +x stora-flash
/root/stora-flash -i /boot/vmlinuz-2.6.32-6-kirkwood -r /boot/initrd.img-2.6.32-6-kirkwood

(les versions de vmlinuz i initrd poden variar)

En aquest punt ja tenim tot el sistema correcte a falta de configurar l’autoarranc per a que arranque linux. Primer fem una prova en manual per a comprovar que el sistema arranca sense problemes. Així que es reinicia, es torna a cancelar l’autoarranc i s’executen les següents ordres:

setenv bootcmd_ide 'ide reset; ext2load ide 0 0x200000 /boot/uImage; ext2load ide 0 0x800000 /boot/uInitrd'
setenv bootcmd 'setenv bootargs $(console) root=/dev/sda1; run bootcmd_ide; bootm 0x200000 0x800000'
boot

Si arranca sense problemes (com m’ha passat a mi) ja podem respirar tranquils, jejeje. Indicar que el linux no agarra l’hora del maquinari, instal·lar el paquet ntpdate-debian per a que actualitze l’hora. Sino es pot fer manual:

date --set "2016-10-07 14:35"

Aixina no ens eixiran missatges indicant que hi ha paquets que s’han creat al futur.

Seguint el que he fet jo, passem a configurar el RAID i després a actualitzar de debian 6 a debian 7. Però supose que es pot invertir l’ordre, primer actualitzar i després configurar el RAID

Amb aquesta instal·lació no es modifica res de l’anterior sistema d’arranc. Per a tornar a utilitzar el firmware del NAS el que es farà és tornar a posar els valors de les variables env al seu lloc (ixes que hem guardat abans!).

Instal·lació Debian al NAS:
http://www.openstora.com/wiki/index.php?title=How_to_install_Debian_Linux_on_NETGEAR_Stora

Moure partició arrel de SD a USB en la Raspberry

Després d’un temps utilitzant una raspberry amb el S.O. a la targeta SD ens podem trobar que aquest falla. Pel que he llegit ‘per ahí’ sol passar prou a sovint ja que en realitat la targeta SD no està preparada para tanta lectura/escriptura (això pareix). Però hi ha una solució per a aquest problema: Passar la partició arrel del S.O. a una unitat USB, és un canvi ben senzill però que depenent del tamany de la partició necessitarà més temps o menys (i estic parlant fins a varies hores).

El primer que es fa és identificar on està la nostra partició arrel, per a això es fa un df -h i localitzem la línia on indica que la partició és ‘/’:

Filesystem Size Used Avail Use% Mounted on
 rootfs 15G 1.9G 13G 14% /
 /dev/mmcblk0p2 15G 1.9G 13G 14% /
 devtmpfs 243M 0 243M 0% /dev
 tmpfs 49M 224K 49M 1% /run
 tmpfs 5.0M 0 5.0M 0% /run/lock
 tmpfs 98M 0 98M 0% /run/shm
 /dev/mmcblk0p1 56M 17M 40M 30% /boot

En aquest cas seria /dev/mmcblk0p2

Després identifiquem la nostra unitat USB, podem fer un ls /dev/sd* abans de connectar el nostre USB, connectar el nostre USB i tornar a fer un ls /dev/sd*, veurem que hi ha algun element nou. Imaginem que al nostre cas hem identificat el /dev/sda1 (sda és la unitat i el 1 és la partició, pot ser sda, sdb, sdc,…. i la partició 1, 2, 3,…).
Aleshores executem:

 sudo dd if=/dev/mmcblk0p2 of=/dev/sda1 bs=4M

Aquest comandament el que fa és fer una ‘foto’ de la partició arrel i plasmar-la a la partició que li hem indicat (borrant tot el que hi havia abans, per supost). Després es necessita revisar la nova partició en busca d’errors. Si no es fa no es podrà seguir al següent pas.

 sudo e2fsck /dev/sda1

Ara tenim una copia exacta de la partició de la SD en la unitat USB, però segurament la unitat USB té més espai i el estem desaprofitant. Per a ocupar tot l’espai possible executem:

 sudo resize2fs /dev/sda1

I ací podriem dir que acaba la primera part: la migració de dades. Ara comença la segona part: la configuració del S.O. per a iniciar amb la nova partició com a partició arrel.
Primer muntem la nova partició

 sudo mount /dev/sda1 /mnt

I editem el seu fitxer fstab

 sudo nano /mnt/etc/fstab

El que anem a fer és canviar el /dev/mmcblk0p2 que haviem vist al primer pas per el /dev/sda1 que és la nova partició (en aquest cas té aquest nom, recordeu al vostre cas pot tenir un altre nom)

Exemple:
Abans

 proc /proc proc defaults 0 0
 /dev/mmcblk0p1 /boot vfat defaults 0 2
 /dev/mmcblk0p2 / ext4 defaults,noatime 0 1
 # a swapfile is not a swap partition, so no using swapon|off...

Després

 proc /proc proc defaults 0 0
 /dev/mmcblk0p1 /boot vfat defaults 0 2
 /dev/sda1 / ext4 defaults,noatime 0 1
 # a swapfile is not a swap partition, so no using swapon|off...

Ara ja podem desmuntar la partició nova

 sudo umount /dev/sda1

I anem a editar un fitxer de configuració del boot

 sudo nano /boot/cmdline.txt

On modifiquem el root=/dev/mmcblk0p2 per root=/dev/sda1

Ara ja si que podem reiniciar i comprovar que estem a la nova partició. Ho podem comprovar amb un df -h per a veure les particions muntades i el tamany.

La partició vella la podem deixar ahí sense tocar, no se sap mai si algun dia es necessitarà per a alguna emergència com voler utilitzar la raspberry sense la unitat USB. Per a aquest cas sols fariem l’últim pass, tornant a posar el root=/dev/mmcblk0p2.

Aquesta informació l’he extret i mig traduït de:
http://travisred.github.io/using-a-usb-drive-as-os-root-on-a-raspberry-pi/

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 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

Enviar e-mail des de la consola (gmail, hotmail,…)

Bona vesprada!

Per al projecte que vull fer aquest mes necessite tenir un client de correu per a enviar correus, no m’apetix configurar el meu propi server amb el que comporta tota aquesta configuració tenint ja servidors de correus. I m’he ‘topat’ amb l’aplicació mutt per a linux clar.

Aquesta aplicació és fàcil de configurar i pot enviar correus amb una ordre o accedir a llegir els correus del teu compte. Primer que res és instal·lar el programa:

apt-get install mutt

He vist ‘per ahí’ que recomanen instal·lar els complements mailutils, libnet-ssleay-perl i libio-socket-ssl-perl, així que per si a cas….

apt-get install mailutils libnet-ssleay-perl libio-socket-ssl-perl

I ara a configurar el fitxer de configuració! Amb nano mateixa fem un nano ~/.muttrc i peguem aquestes línies:

set send_charset=”utf-8″
set from = "user@gmail.com"
set realname = "El teu nom"
set imap_user = "user@gmail.com"
set imap_pass = "password"
set folder = "imaps://imap.gmail.com:993"
set spoolfile = "+INBOX"
set postponed ="+[Gmail]/Drafts"
set header_cache =~/.mutt/cache/headers
set message_cachedir =~/.mutt/cache/bodies
set certificate_file =~/.mutt/certificates
set smtp_url = "smtp://user@smtp.gmail.com:587/"
set smtp_pass = "password"

Canviar user pel vostre nom d’usuari i password pel vostre password. Per si no ho sabeu, aquest fitxer es crearà/modificarà amb l’usuari que es vol utilitzar per a enviar els correus.

Ara toca dir-li a GMail que confie amb mutt, s’accedix a https://www.google.com/settings/security i habilitar Accés per a aplicacions menys segures, sino el GMail ens bloquetjarà l’accés i ens enviarà un correu indicant-nos que ha bloquetjat un intent d’inici de sessió.

Finalment ja si executem mutt tindrem un client d’e-mail en consola i si volem enviar correus per consola tenim les següents possibilitats:

Correu amb el cos a un arxiu:
mutt -s "Assumpte" destinatari@correu.com < axiu de text de l'email

Correu amb el cos escrit a la mateixa ordre:
mutt -s "Assumpte" destinatari@correu.com <<< "Missatge"

Correu amb el cos a un arxiu i amb un arxiu adjunt:
mutt -s "Assumpte" destinatari@correu.com < axiu de text de l'email -a /ruta_arxiu_adjunt/arxiu.extensio

Tota la info l'he trobat a:
http://www.taringa.net/posts/linux/7446631/Enviar-correos-de-cuentas-gmail-desde-la-consola.html
http://rsppi.blogspot.com.es/2013/01/envio-de-emails-desde-consola-y-con.html
http://blog.desdelinux.net/enviar-emails-por-consola-con-sendmail/

Instal·lar debian a la QNAP TS-110

Hui vaig a reaprofitar la primera nas que em vaig comprar (de sols un disc) i 1TB d’espai. Ara mateix la tenia amb l’última versió del seu firmware amb emule però eixa versió de firmware feia que anara prou lent. Així que revisant ‘per ahí’ m’he trobat amb el cas de Martin Michlmayr, que li ha posat un debian. I jo he pensat… i si ho faig jo també???? Aixina que… ale valent a per ell!!! Bàsicament el que trobareu ací és una traducció del que diu ell, amb algunes modificacions segons la meva experiència.

Primer que res saber que Debian suporta el processador que du la NAS (ARM) i que el que vaig a explicar, segons ell, es pot aplicar a QNAP TS-110, TS-112, TS-112P, TS-119, TS-119P+, TS-119P II, TS-120 or TS-121.

Per a poder instal·lar el debian el que es fa es posar una imatge a la memòria flash per a que arranque al reiniciar i fer la instal·ació per xarxa. Com no tenim monitor de sortida s’utilitzarà el ssh per a la instal·lació. Com he dit… tenim que modificar les dades que hi ha a la flash, així que primer farem un backup del que tenim a la memòria flash de la nas.

Seguint la guia que explica aquesta persona, el primer que fem és connectar una memòria USB a la NAS i per ssh vegem on s’ha muntat, per a això executem el següent codi

mount | grep external
/dev/sdi1 on /share/external/sdi type vfat [...]

i una vegada sabem on s’ha muntat, anem al seu directori i volquem la info de la flash amb CAT

cd /share/external/sdi
cat /dev/mtdblock0 > mtd0
cat /dev/mtdblock1 > mtd1
cat /dev/mtdblock2 > mtd2
cat /dev/mtdblock3 > mtd3
cat /dev/mtdblock4 > mtd4
cat /dev/mtdblock5 > mtd5
cd
umount /share/external/sdi

Aquestos arxius els guardem per si volem tornar arrere (qui sap!)

Ara ja podem baixar les imatges de debian dels seus servidors amb aquestos comandos:

cd /tmp
busybox wget http://ftp.debian.org/debian/dists/stable/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-119/initrd.gz
busybox wget http://ftp.debian.org/debian/dists/stable/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-119/kernel
busybox wget http://ftp.debian.org/debian/dists/stable/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-119/flash-debian
busybox wget http://ftp.debian.org/debian/dists/stable/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-119/model

Aquestos fitxers que s’han baixat són el kernel, l’instal·lador del ramdisk, fitxer amb info del model de QNAP i un script que copia el kernel a la flash (això diu ell, jo sols m’ho crec i au). Be ara ja toca ‘flashejar’ la memòria flash amb la següent instrucció:

sh flash-debian

Tardarà uns minuts (no vos preocupeu) i al final eixirà un missatge que diu que reiniciem la màquina

Updating MAC address...
Your MAC address is 00:08:9B:8C:xx:xx
Writing debian-installer to flash... done.
Please reboot your QNAP device.

I la reiniciem

reboot
exit

A partir d’ací ja comença la instal·lació. Com no es pot connectar la pantalla per a veure el procés d’instal·lació, el que es fa és connectar-se per ssh a la NAS. Per a això el sistema s’ha creat un usuari anomenat installer amb password install amb el qual ingressarem via ssh.
Un altre tema és la IP, si teniem configurada una IP estàtica aquesta es mantindrà, si és per DHCP ens tocarà connectar-nos al server DHCP per a veure quina IP li ha assignat a la seva MAC i finalment si la màquina no sap quina IP tindre es posarà per defecte la 192.168.1.100.

Així que finalment amb la IP que tinga s’accedix per SSH i ja es pot instal·lar el sistema ‘com tota la vida’

Una vegada s’ha instal·lat el primer que he fet és posar-li el server samba, web, ftp, sql, php, pnp, emule, webmin,… i crec que això és tot el que li he posat (el que per a mi és una instal·lació base per a un server polivalent, jeje)

Ah! cal actualitzar el paquet qcontrol que és el que s’encarrega de fer funcionar el ventiladoret, i les llumenetes ja que diuen que la versió que s’instal·la per defecte no es bona, falla. Per a realitzar açò seguim els següents passos:

Afegim a l’arxiu /etc/apt/sources.list la línea:

deb http://ftp.debian.org/debian/ wheezy-backports main

i després fem un:

apt-get update
apt-get install -t wheezy-backports qcontrol

i ja el tindrem actualitzat.

I això és tot xavals!

La web d’on he tret tota la info:

Guia ràpida: IP Forwarding amb IPTABLES

Ja fa temsp que no escric res així que he pensat en posar alguna coseta per a que no vaja oblidant-me d’aquest blog. Hui explicaré de forma ràpida com redirigir el tràfic rebut en un port cap a una altra IP:PORT. Per a que servix? doncs per exemple si tens un pc connectat directament a Internet i vols tenir un altre pc connectat al primer fent de servidor web per exemple (el que amb un router es fa ràpidament, anomenat NAT). També servix, com en el meu cas, per a accedir a serveis instal·lats a pcs que estàn en una xarxa diferent a la meva i el linux fa de passarela entre les dues xarxes (l’altra està aïllada, no tenen gateway ni res (si fas ping no contesten a no ser que estigues al seu rang).

Ho vaig a explicar per a deixar el routing fixe a debina/ubuntu, és a dir que quan es reinicie l’equip la configuració es quede guardada.

Primer es modifica a l’arxiu /etc/sysctl.conf la línia que diu net.ipv4.ip_forward deixant-ho a 1. Després es reinicia el servici amb /etc/init.d/procps restart
I ara ja es poden aplicar les regles de l’IPTABLES per a redirigir el tràfic. En aquest cas anem a suposar que volem donar servei web (port 80) al pc2 (IP: 192.168.0.2) que està connectat al pc1 (192.168.0.1), volem utilitzar el port per defecte de la web (80) per a que l’usuari que es vulga connectar no tinga que posar cap port al navegador web.

Aquesta és l’ordre a escriure per a aquest cas:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.0.2:80
I per a enmascarar també la resposta i ser un NAT complet després s’afegix la següent instrucció:
iptables -t nat -A POSTROUTING -j MASQUERADE
(aquesta última és general, es a dir que es poden configurar diferents redireccions de port i finalment posar aquesta ordre)

Per supost que aquestes ordres executades a la consola no es quedaran guardades si es fa un reinici del pc, així que ens queda crear un script amb aquestes ordres i afegir-lo a l’inici del sistema per a que s’execute. Fer l’script és fàcil, copiar i pegar a un arxiu i donar permisos d’execució (chmod +x nom_del_fitxer com a ROOT).

Per a afegir un script a l’inici del sistema s’ha de modificar el fitxer /etc/rc.local i posar la ruta del script abans del exit 0.

I ja està tot dit! Ho he extret dels següents enllaços:
http://blog.desdelinux.net/como-iniciar-reglas-de-iptables-automaticamente/
http://www.ducea.com/2006/08/01/how-to-enable-ip-forwarding-in-linux/
http://blog.desdelinux.net/como-iniciar-reglas-de-iptables-automaticamente/

Lliberar Samsung Galaxy Ace S5830

Vaig a obrir una nova secció al meu blog, aquesta va a dedicar-se a l’android, ja que en tinc un ja fa un parell d’anys i no li he dedicat temps per a trastejar amb ell.

Per a estrenar aquesta secció no vaig a parlar del meu telèfon (que igual prompte el canvie) si no que vaig a parlar com lliberar el telèfon Samsung Galaxy Ace S5830, que no se jo però serà paregut per als seus germans. Ja comence diguent que no servix aquest mètode per al HTC HERO (que és el que tinc jo per ara). Primer explique un poc el que es vol aconseguir i després ja ho explique com es fa.

Resulta que en aquest mòbil la informació del IMEI i del número de desbloqueig de xarxes està guardat en un fitxer imatge, així que el que es pretén fer és muntar aquest fitxer en un directori i accedir a eixa informació. Compodeu vore no hi ha complicació alguna en la explicació de la falla, així que passe a la part pràctica (però sense il·lustracions).

Per a poder entrar en mode escritura a les particions arrel primer tenim que ser ROOT, sino sols podem en mòde lectura, aixi que anem a ‘rootear’ l’android. Per a poder fer-ho es baixa l’aplicació One Click i s’instal·la el Samsung Kies (aquest és per a que el Windows tinga els drivers del mòbil i es puga detectar). Una vegada instal·lat el Kies i baixat el OneClick, executem el Oneclick (tenint el mòbil connectat al PC), clic al botó “root” i arreglat!

Ara passem a la segona part, en aquesta part s’instal·la la SDK de l’Android (a la seva pàgina oficial, gratuït) i una vegada instal·lat afegim el paquet “android platform tools”

Va que açò ja va arribant al final, ara que ja tenim tot el necessari és quan va de bo. S’obri una consola de windows (Inicio -> Ejecutar -> ‘cmd’) i s’escriu el següent:

set PATH=%PATH%;R_U_T_A

On R_U_T_A és la ruta on està instal·lades les platform-tools, en el meu cas és “C:\Program Files\Android\android-sdk\platform-tools”, depenent d’on s’instal·le serà una ruta o una altra. I ara ja a seguir en les següents comandes:

cd /
mount -o remount rw /
mkdir /efs
mount -o nosuid,ro,nodev -t vfat /dev/block/stl5 /efs
cat /efs/mits/perso.txt

i eixirà una informació pareguda a la següent:

Fixeu-se que en la consola aparega el símbol #, si apareix el $ aleshores abans del cd / executeu un su.

La explicació del que s’ha escrit és fàcil: Es passa al directori arrel, es modifiquen els permisos de muntatge a escritura/lectura, es crea un directori amb el nom efs, es munta l’arxiu imatge on està el número que busquem i finalment es mostra per pantalla la informació (clar? més clar aigua).

Ara s’apaga el telèfon i es canvia la targeta SIM, s’encen i després de posar el PIN ens demanarà el codi que hem obtés per a desbloquejar el terminal. Pot ser que al tornar a posar la SIM antigua ens torne a demanar aquest codi, es torna a posar i ja està.

 

Referències:

http://flashea.com/2011/08/liberar-samsunggalaxy-ace-s5830.html

http://forum.xda-developers.com/showthread.php?t=1204705